이더리움 이코노믹 존(EEZ): 롤업을 다시 하나로 묶는 시도

[이더리움 이코노믹 존(EEZ): 롤업을 다시 하나로 묶는 시도] 이더리움의 스케일링을 목표로 하는 롤업들은 현재 그 목적을 달성하는 데에 어느 정도 성공했지만, 그 대가로 수십 개의 L2가 각자의 유동성과 브리지를 가진 섬으로 쪼개졌습니다. EEZ는 Gnosis, Zisk, 이더리움 재단이 이 파편화를 풀기 위해 함께 추진하는 L1↔L2 프레임워크로, 쪼개진 롤업들을 다시 "하나의 체인처럼" 쓰게 만드는 것을 목표로 합니다. 이들이 풀려고 하는 문제는 다음과 같습니다. 롤업 A에 자산이 있는데, 쓰려는 DEX는 롤업 B에 있다면, 지금은 여러 스텝을 거쳐야만 합니다. A에서 브리지로 자산을 넘기고, 도착을 확인한 뒤, 그제서야 B에서 스왑해야 하죠. 써드 파티 브릿지를 사용하면 빠르기는 하나 보안이 롤업 공식 브릿지만 못하고, 롤업 공식 브릿지를 쓰면 이 모든 과정이 7일 이상도 걸릴 수 있습니다. EEZ가 하려는 건, 트랜잭션 하나에 ‘A에서 이걸 하고, 그게 B의 기능을 호출하고, 결과를 받아 A에서 계속한다’를 통째로 담아 한 블록 안에서 처리하는 것입니다. 마치 A와 B가 원래 같은 체인이었던 것처럼 말입니다. 결과는 항상 전부 되거나 전부 안 되거나 둘 중 하나이고, ‘A는 됐는데 B는 안 된’ 중간 상태가 없습니다. 이를 동기적 컴포저빌리티(synchronous composability)라 부릅니다. [토대: 실시간 증명과 하나의 빌더] 이게 가능하려면, 다음 두 가지 조건을 만족해야 합니다. 첫째, 같은 슬롯에서 여러 체인을 동시에 만드는 블록 빌더가 한 명 있다는 것. EEZ에서는 한 빌더가 롤업 A/B 블록을 동시에 만듭니다. 한 사람이 양쪽을 다 보고, 각 트랜잭션의 결과를 모두 알고 있으니 체인 간 호출을 한 트랜잭션에 안전하게 엮을 수 있는 것이죠. 둘째, 실시간 증명입니다. 블록을 만드는 거의 동시에 ‘이 블록은 규칙대로 실행됐다’는 수학적 증명(ZK 증명)을 뽑아낼 만큼 빨라야 합니다. 과거엔 너무 느려 불가능했지만, 최근 기술 발전으로 현실적인 수준까지 올라온 것으로 보입니다. EEZ는 Zisk라는 증명 엔진을 기반으로 하며, 이더리움 블록 하나를 GPU 여러 대로 수 초 안에 증명할 만큼 빠른 속도를 자랑합니다. EEZ의 롤업들은 트랜잭션 데이터와 증명을 동시에 제출하니 증명이 없으면 블록 자체가 없는 것으로 취급됩니다. [1. EEZ에서 L2끼리의 상호작용] 그렇다면, 실제로 EEZ에서 L2 간의 동기적인 크로스체인 트랜잭션이 어떻게 이뤄지는지 알아보겠습니다. 트랜잭션이 들어오면, 빌더는 먼저 이를 자기 머신에서 끝까지 시뮬레이션합니다. A를 돌리다 "B의 기능 Y를 호출"하는 지점이 나오면, 빌더는 B 체인에서 Y를 실제로 실행해 결과를 얻고, 그걸 다시 A에 넣어 끝까지 마칩니다. 이 시점에 빌더는 A/B가 어떻게 바뀌는지, Y가 뭘 반환했는지 모든 중간값을 알고 있습니다. 그리고 ‘A는 이렇게 바뀐다’, ‘B는 이렇게 바뀐다’, ‘전부 규칙대로 실행됐다는 증명’을 하나의 단위로 묶어 이더리움에 올립니다. 이 모든 것이 한 덩어리로 올라가니, 통째로 받아들여지거나 통째로 거부되고, 중간만 적용되는 일이 구조적으로 불가능합니다. 여기엔 영리한 트릭이 하나 더 있습니다. 직관적으로는 A의 증명 안에 ‘B의 Y가 이 값을 반환한다’를 보증해야 하니, 롤업 A의 증명 안에서 B의 실행 내역을 통째로 다시 증명해야 할 것 같지만, 롤업이 수십 개면 사실상 그렇게 하는 것이 불가능합니다. 그래서 EEZ는 ‘일단 가정하고 나중에 대조’하는 방식을 씁니다. A를 증명할 땐 "Y가 이 값을 반환했다"고 가정만 하고 그 가정을 공용 장부에 +로 적고, B를 증명할 때 실제 실행 결과를 같은 장부에 −로 적습니다. 마지막에 모든 증명을 합치며 ‘장부의 합이 0인가’만 검사하죠. 빌더가 거짓 결과를 가정했다면 합이 0이 안 되어 전체가 무효가 됩니다. 각 롤업이 서로의 상태를 통째로 들 필요 없이, 이 한 번의 검사로 아귀를 맞춥니다. [2. EEZ에서 L1과 L2의 동기적 컴포저빌리티] 진짜 까다로운 건 메인넷(L1)이 끼는 경우입니다. L2끼리는 빌더가 둘다 체인 노드를 돌리며 양쪽 상태를 정해 증명하면 그만이지만, L1은 마음대로 못 할 수 없기 때문입니다. 더 큰 문제는 L1이 실행되는 시점에 롤업 상태를 전혀 모른다는 것입니다. L1 컨트랙트가 ‘롤업 R의 컨트랙트를 호출하고 싶다’고 해도, L1은 R의 상태도 모르고 R의 컨트랙트를 실행할 능력도 없습니다. EEZ는 이를 두 장치로 해결합니다. 대리인(프록시)과 답안지(실행 테이블)입니다. 프록시는 L1 위에 미리 세워둔, 롤업을 대변하는 창구입니다. L1 컨트랙트는 롤업 R을 직접 못 부르니, 대신 프록시를 호출하는 것이죠. L1 입장에선 평범한 L1 컨트랙트를 호출하는 것뿐이라, 별도의 하드 포크가 필요하지도 않습니다. 실행 테이블은 빌더가 미리 작성해 L1에 깔아두는 표입니다. 빌더는 트랜잭션을 먼저 시뮬레이션하며 ‘L1이 롤업 내 컨트랙트를 부르면 → 롤업의 상태가 이렇게 바뀌고 → 반환값은 이거다’를 모든 크로스체인 호출에 대해 미리 뽑아 표로 만들고, ‘이 표대로 실행한 게 정확하다’는 증명을 붙입니다. 실제 실행 때 L1 컨트랙트가 프록시를 부르면, 프록시는 롤업을 직접 실행하는 대신 이 테이블에서 해당 줄을 찾아 그대로 답을 돌려줍니다. 덕분에 L1 노드는 롤업 상태를 끝내 몰라도, 검증된 테이블을 보고 결과를 재생하기만 하면 됩니다. 자연히 떠오르는 의심 두 가지에 답이 있습니다. 빌더가 답안지에 거짓을 적으면? 못 합니다. 답안지 각 줄에 적힌 "호출 직전 R의 상태"를 창구가 소비 시점에 실제 상태와 다시 대조하고, 표 전체의 증명이 모든 줄의 정확성을 이미 보증하기 때문입니다. 미리 돌려본 L1 상황과 실제가 달라지면? 어긋나는 만큼 무효가 됩니다. 답안지에 없는 호출이 일어나면 트랜잭션이 통째로 실패하고, 표의 줄을 실제로 안 밟으면 그 줄은 버려지죠. 손해 보는 건 빌더이고, 사용자가 잘못된 상태를 떠안는 일은 없습니다. 정리하면 L2끼리는 ‘가정 후 장부로 대조’, L1↔L2는 ‘미리 답안지를 깔고 대리 창구가 대조’하는 방식으로 같은 원자성을 달성합니다. [남는 숙제] 가장 자주 지적되는 건 빌더에 대한 권력 쏠림입니다. 답안지를 만들려면 정확한 L1 상황 파악 + 전체 시뮬레이션 + 증명 생성을 다 할 수 있어야 하는데, 이를 갖춘 건 사실상 타이탄이나 빌더넷과 같은 대형 빌더뿐이라 권력이 그쪽으로 몰리며, 이들이 MEV 등의 기회를 모두 얻는다면 빌더 중앙화가 더욱 심화될 수 있습니다. 또한 기존 롤업들이 시퀀서를 운영하며 얻는 수익이나, 사용자들에게 줄 수 있는 UX 이점 등을 어느 정도 포기하고 EEZ에 옵트인할 동기가 적다는 점을 고려할 때, 초기 생태계 부트스트래핑이 어려울 수 있습니다. 결국 EEZ를 포함한 크로스체인 솔루션들은, 각자만의 롤업을 운영하는 것보다 그게 하나로 이어졌을 때 사용자들에게 얼만큼의 이점을 가져다줄 수 있는지를 직접 증명해야 하는 입장이기에, EEZ가 이를 어떻게 해내갈지도 지켜볼 만 한 것 같네요. 마침 이번 주부터 독일에서 열리는 베를린 이더리움 데이 행사에서 관련 발표가 예정돼 있으니, 참석하시는 분들은 직접 들어보셔도 좋겠습니다! 출처