zkSync 2.0 메인넷 출시를 앞두고 다양한 zkEVM 분석
이더리움의 발전 로드맵은 점점 모듈형 블록체인(Modular Blockchain) 방향으로 기울고 있으며, 이는 본질적으로 Layer1의 데이터 샤딩(data sharding)과 Layer2의 롤업(Rollups) 확장성을 결합한 모듈화 아키텍처를 의미하며, 이를 통해 이더리움이 '월드 컴퓨터(World Computer)'라는 초창기 비전을 실현하고자 한다.
이러한 롤업 기술 경로 선택에서 ZK 롤업(ZK Rollup)은 이더리움 확장성의 궁극적 목표로 여겨진다.
ZK 롤업
ZK 롤업의 핵심 작동 메커니즘은 체인 상의 사용자 상태를 머클 트리(Merkle tree)에 압축하여 저장하고, 사용자 상태의 변경 작업을 오프체인에서 수행하는 동시에, zksnark/zkstark 증명을 통해 해당 오프체인 상태 변경 과정의 정확성을 보장하는 것이다. 쉽게 말해, ZK 롤업은 zksnark 또는 zkstark를 활용해 선형적인 수준의 명령어를 아예 선형적이지 않은 방식으로 검증할 수 있게 해주는 기술이다. 예를 들어, 1,000개의 명령어를 검증하려면 검증자가 단 10번만 확인하면 되고, 10,000개의 명령어도 단 11번의 검증만 필요하다. 결과적으로 ZK 롤업은 이더리움의 확장성을 실현할 수 있다.
ZK 롤업의 일반적인 블록체인 거래 처리 과정은 다음과 같다:
-
사용자는 자신의 자산을 L1 상의 zk 롤업 스마트 계약에 예치한다;
-
사용자는 이러한 자산 관련 거래를 L2에 제출하고, L2 내 특정 역할(Sequencer, 초기 대부분의 프로젝트는 중심화된 구조였지만 일부는 탈중앙화 방식 도입 시도 중)이 규칙에 따라 이들 거래를 순서가 정렬된 배치(batch)로 집계하며, 각 배치마다 유효성 증명(zksnark/zkstark)과 집계된 상태 업데이트를 생성한다;
-
이러한 상태 업데이트와 증명은 L1의 zk 롤업 스마트 계약에 제출되어 검증되며, 검증 후 L1 블록체인에 반영된다;
-
사용자는 이러한 L1 상태(다양한 데이터 가용성 메커니즘에 따라 달라짐)를 이용해 자신의 자산을 회수할 수 있으므로 완전한 자기 관리(self-custody)가 가능하며, 따라서 zk 롤업은 이더리움의 보안성을 그대로 계승했다고 평가된다.
zkEVM의 필요성
众所周히, 1세대 ZK 롤업은 EVM을 지원하지 않아 프로그래밍 가능성 및 조합성이 낮았으며, 특정 용도로만 제한되었다. 예를 들어 Loopring은 결제(Payments) 및 스왑(Swaps)에 국한되었고, Immutable은 NFT 민팅, 거래, 게임 등에만 사용되었으며, zksync 1.0 역시 zkEVM을 지원하지 않았다. 즉, 범용성이 부족했다.
이후 주요 ZK 롤업 프로젝트들은 ZK 롤업 위에서 EVM 바이트코드를 실행 가능한 환경을 개발하기 시작했으며, 이를 통해 기존 이더리움 상의 스마트 계약을 새로 작성하지 않고도 ZK 롤업으로 이전할 수 있게 되었다.
EVM은 2015년 출시된 최초의 튜링 완전(turing-complete) 블록체인 가상 머신이며, 지금까지 가장 오랫동안 검증된 블록체인 가상 머신이자 이더리움의 매우 중요한 스마트 계약 인프라스트럭처이다. 다른 블록체인을 논할 때도 EVM 호환 여부를 하나의 평가 기준으로 삼는데, 그 이유는 EVM 호환이 단순히 스마트 계약 실행 환경을 넘어서, 사용 가능한 이더리움 생태계와 툴셋을 의미할 뿐 아니라 무시할 수 없는 네트워크 효과를 나타내기 때문이다. 따라서 ZK 롤업 프로젝트들도 이 부분을 간과할 수 없었다.
zkEVM은 스마트 계약 엔진으로서 EVM을 ZK 롤업 내에서 실행한다고 이해할 수 있다. zkEVM의 목표는 롤업의 성능 장점을 잃지 않으면서도 이더리움 경험 그 자체를 L2로 완전히 가져오는 것이다.
현재까지 zkSync2.0, Polygon Hermez2.0, Scroll 등 주요 범용 ZK 롤업 프로젝트들은 이미 zkEVM 테스트넷을 차례로 출시했으며, StarkNet은 이미 알파 메인넷 단계에 진입했다.
zkEVM의 호환성 분류
현재의 ZK 롤업에서 제공하는 zkEVM은 이더리움 자체와 완벽하게 호환되는 것은 아니며, 더遑론 "이더리움 동등(Ethereum-equivalent)"이라는 궁극적 비전에도 미치지 못한다. 이에 따라 이더리움 자체의 업그레이드 로드맵도 롤업 친화형 설계로 전환되고 있으며, 각 ZK 롤업 프로젝트들도 지속적으로 이더리움과의 호환성 문제를 해결하려 노력하고 있다.
비탈릭(Vitalik)은 기존 EVM 인프라와의 호환 정도에 따라 zkEVM 범용 ZK 롤업을 4가지 유형으로 분류했다:
Type-1: 이더리움과 완전 동등
Type-1 zkEVM은 이더리움과 완전하고 타협 없는 동등성을 추구한다. 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일(prec ompiles), 또는 기타 합의 로직을 포함해 이더리움 시스템의 어떤 부분도 변경할 필요가 없다. 요컨대 Type-1 zkEVM은 이더리움과 완전히 동일하다.
Type-1 zkEVM은 이더리움처럼 이더리움 블록을 검증할 수 있거나, 적어도 실행 레이어(모든 트랜잭션 실행, 스마트 계약, 계정 로직 포함, 비콘체인 합의 로직 제외)를 검증할 수 있다.
Type-1 zkEVM은 이더리움이 궁극적으로 필요로 하는 것이며 롤업의 이상적인 선택지이다. 한편으로는 Type-1 zkEVM이 롤업이 이더리움 실행 클라이언트(Ethereum Execution Clients), 블록 탐색기(Block Explorers), 블록 생성(Block Production) 등의 많은 인프라를 재사용할 수 있도록 해주며, 다른 한편으로는 이더리움 L1 자체의 확장성을 높이는 데 기여한다. Type-1 zkEVM에서 시도되는 일부 수정사항이 장기적으로 이더리움 자체에 도입될 수도 있기 때문이다.
물론 Type-1 zkEVM에도 단점이 있다. 이더리움은 처음부터 ZK 친화적으로 설계된 것이 아니므로 프로토콜의 많은 부분이 ZK 증명을 위해 막대한 계산량을 요구한다. Type-1은 이더리움과 동일하게 이러한 비효율성을 완화하지 못하므로 증명 생성에 시간이 오래 걸린다. 이 문제에 대한 현재의 산업 솔루션은 주로 **증명의 대규모 병렬화**(massive parallelization of proofs) 또는 ZK-SNARK **ASIC을 통한 하드웨어 가속**을 활용하는 것이다.
현재 Type-1 ZK-EVM 개발을 시도 중인 주요 팀은 **Privacy and Scaling Explorations 팀**과 **Taiko** 두 팀이다.
Type-2: EVM과 완전 동등
Type-2 zkEVM은 EVM과 완전히 동등하되, 이더리움 전체와는 완전히 동등하지 않다. 기존 애플리케이션과도 완전히 호환되지만, 개발의 용이성과 증명 생성 속도 향상을 위해 이더리움에 소규모 수정이 필요하다.
Type-2 zkEVM은 블록 구조나 상태 트리 같은 데이터 구조에 일부 수정을 가한다. 그러나 이러한 구조는 EVM이 직접 접근할 수 없는 것이므로 이더리움에서 실행되는 앱들은 거의 그대로 Type-2 zkEVM 롤업에서 동작할 수 있다. 기존 이더리움 실행 클라이언트를 원본 그대로 사용할 수는 없지만 일부 수정을 거쳐 사용 가능하며, EVM 디버깅 툴과 대부분의 개발 도구 역시 활용할 수 있다.
불필요하거나 ZK에 불리한 이더리움 스택 일부를 제거함으로써 Type-2 zkEVM은 Type-1보다 증명 생성 시간이 더 빠르다. 이러한 수정은 증명자의 효율성을 크게 향상시키지만 근본적으로 증명 속도가 느리다는 문제를 해결하지는 못한다. 결국 Type-2의 증명 시간 역시 여전히 느리다.
Type-3: 거의 EVM 동등
Type-3 zkEVM은 거의 EVM과 동등하지만 호환성 면에서 일부 타협을 하며, 대신 개발이 더 쉬운 형태를 지향한다.
Type-3 zkEVM은 zkEVM 내에서 구현하기 어려운 일부 기능(예: 사전 컴파일)을 삭제하고, 스마트 계약 코드, 메모리 또는 스택 처리 방식을 조정함으로써 동등성 측면에서 일부 타협을 하지만 검증 시간을 단축하고 EVM 개발을 더욱 용이하게 한다.
호환성 면에서 타협한 만큼, Type-3 zkEVM이 제거한 사전 컴파일을 사용하는 애플리케이션은 일부 코드를 다시 작성해야 한다.
현재 Scroll과 Polygon이 Type-3에 속한다. 물론 장기적으로 어느 zkEVM 팀도 Type-3에 영원히 머무르겠다고 공개적으로 밝힌 곳은 없다. Scroll과 Polygon Hermez 모두 Type-2 방향으로 나아가고 있으며, 아직 구현되지 않은 복잡한 사전 컴파일들이 남아 있지만.
Type-4: 고급 언어 수준 동등
Type-4는 사실상 zkVM에 해당한다. Type-4 시스템은 고급 언어(Solidity, Vyper)로 작성된 스마트 계약 소스 코드를 받아, ZK-SNARK에 특화된 언어로 컴파일하여 동작한다.
장단점이 뚜렷하다. 매우 빠른 검증 시간을 갖는데, 이는 Type-4가 모든 EVM 실행 단계별 구성 요소에 대해 ZK 증명을 수행하지 않고, 고차원 코드에서 바로 시작하기 때문에 비용이 낮고 검증 속도가 빠르다. 다만 호환성은 떨어지며, Type-4 시스템에서의 계약 주소가 EVM과 다르고, 수작업으로 작성된 EVM 바이트코드 사용이 어렵다. 또한 디버깅 인프라 대부분을 계승할 수 없는데, 이는 해당 인프라가 EVM 바이트코드 위에서 동작하기 때문이다.
결국 Type-4는 언어 수준에서의 동등성만 제공하며, 바이트코드 수준의 동등성과 비교하면 호환성에서 큰 격차를 보인다. 비탈릭의 견해에 따르면 현재 Zksync가 Type-4에 속하며, 시간이 지남에 따라 EVM 바이트코드 호환성을 추가할 가능성도 있다. 또한 Nethermind의 Warp 프로젝트는 Solidity에서 Starkware의 Cairo로의 컴파일러를 개발 중이며, 이는 StarkNet을 Type-4로 만들게 된다.
각종 zkEVM 비교
이러한 zkEVM들 사이에는 절대적인 우열이 존재하지 않는다. 단지 호환성과 속도 사이의 트레이드오프일 뿐이며, Type-1 zkEVM은 이더리움과의 호환성이 가장 높지만 증명 속도가 느리고, Type-4 zkEVM은 이더리움과의 호환성이 낮지만 검증 속도가 빠르다. 또한 우리는 ZK 롤업의 주요 프로젝트들—Zksync, StarkNet, Polygon, Scroll 등—이 대부분 Type-4/Type-3처럼 이더리움과의 호환성이 높지 않은 zkVM/zkEVM 유형임을 알 수 있다.
비탈릭은 장기적으로 zkEVM 개선과 이더리움 자체의 개선이 결합되어 결국 모든 zkEVM이 Type-1이 되기를 희망한다. 이렇게 되면 여러 zkEVM이 ZK 롤업뿐 아니라 이더리움 체인 자체의 검증에도 활용될 수 있는 이점이 있다(미래 이더리움은 ZK-SNARK에 더욱 친화적이게 될 것임).
비탈릭의 주장은 일반적으로 산업 전반의 합의에 도달하기 쉽고, 저 역시 매우 동의한다. Type-1 zkEVM 프로젝트는 이더리움 생태계 내에서 자연스럽게 가장 인기가 많으며 이더리움 L1과 가장 잘 맞는다. 그러나 Type-4 zkVM 역시 실행 레이어 프로젝트의 좋은 기술적 선택지가 될 수 있다.
주된 이유는 두 가지다:
-
모듈형 블록체인 서사 안에서 zkVM은 다른 L1과 연결하기가 더 용이하다. 단순히 이더리움 생태계의 L2 역할만 하는 사고방식을 벗어나, 바이트코드 수준에서 이더리움 가상머신과 호환되지 않도록 하고 zkVM을 선택한다면, 오히려 미래에 다른 L1 합의 레이어와 연동하기 쉬워질 수 있다;
-
현재 ZK 롤업의 성능 한계는 증명 생성 속도에 의해 제한되며, Type-4 zkVM은 여기서 강점을 가진다. 실행 레이어의 증명 생성 속도는 매우 중요하며, L2가 실행 레이어의 성능을 극한까지 끌어올리는 것도 나쁜 전략이 아니다. ASIC 하드웨어 가속을 통해 향후 증명 생성 효율을 높일 수 있을지 모르지만 그 효과는 불확실하므로, Type-4 zkVM의 빠른 증명 생성 속도는 중요한 이점이다.
물론 zkEVM의 호환성과 속도는 개발자가 어떤 ZK 롤업을 기반으로 앱을 개발할지를 결정하는 유일한 기준이 아니다. 다른 많은 요소들도 선택에 영향을 미친다:
-
비용: 어떤 토큰으로 수수료를 지불하는지, L2 수수료가 얼마나 낮아지는지도 매우 중요한 고려 사항이나, 대부분의 범용 ZK 롤업 프로젝트가 아직 테스트넷 단계이므로 비교는 어렵다;
-
증명 생성 규칙: 누구를 Prover로 허용하는지, 심지어 증명 생성 가속을 위한 하드웨어 종류 선택도 포함;
-
L2 트랜잭션 정렬 규칙: 단일 Sequencer 사용 여부 또는 탈중앙화 방식 채택 여부;
-
자기 관리(Self-custody): L2에서 사고 발생 시 L1에서 여전히 사용자 자산을 복구할 수 있는 명확한 메커니즘이 있는지;
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
