Vitalik: 다양한 유형의 ZK-EVM의 미래
작자: Vitalik
번역: Block unicorn, Foresight News
최근 여러 "ZK-EVM" 프로젝트가 주목할 만한 발표를 했다. 폴리곤(Polygon)은 그들의 ZK-EVM 프로젝트를 공개했고, ZKSync는 ZKSync 2.0 계획을 발표했으며, 비교적 새로운 스크롤(Scroll) 역시 최근 ZK-EVM을 출시했다. 또한 프라이버시와 확장성 탐구 팀과 니콜라스 리오촌(Nicolas Liochon) 등의 팀이 EVM에서 스타크웨어(Starkware)의 zk 친화적인 언어인 카이로(Cairo)로의 알파 컴파일러 개발을 지속하고 있으며, 물론 내가 놓친 프로젝트들도 있을 것이다.
이 모든 프로젝트의 핵심 목표는 동일하다. 즉, ZK-SNARK 기술을 사용해 이더리움과 유사한 트랜잭션 실행에 대한 암호학적 증명을 생성함으로써 이더리움 체인 자체를 검증하기 쉽게 만들거나, 이더리움과 거의 동일한 기능을 제공하면서도 확장성이 더 뛰어난 zk 롤업(zk rollup)을 구축하는 것이다. 그러나 이러한 프로젝트들 사이에는 미묘한 차이점들이 존재하며, 실용성과 속도 사이에서 각기 다른 절충안을 선택하고 있다. 본 글은 EVM 동등성(EVM equivalence)의 다양한 '유형'에 대한 분류를 시도하고, 각각의 유형을 구현하려는 장점과 비용을 설명하고자 한다.
개요 (차트 형태)
유형 1 (이더리움과 완전히 동등)
제1유형 ZK-EVM은 이더리움과 완전하고 타협 없는 동등성을 추구한다. 이들은 증명 생성을 더 쉽게 하기 위해 이더리움 시스템의 어떤 부분도 변경하지 않는다. 해시, 상태 트리, 트랜잭션 트리, 사전컴파일(precompiles), 또는 어떤 합의 로직이라 할지라도 가장 말초적인 부분조차 바꾸지 않는다.
장점: 완벽한 호환성
목표는 현재처럼 이더리움 블록을 검증하거나, 적어도 실행 계층(execution layer)을 검증하는 것이다. (따라서 비컨체인 합의 로직은 포함되지 않지만, 모든 트랜잭션 실행 및 스마트 계약과 계정 로직은 포함된다.)
유형 1 ZK-EVM은 궁극적으로 이더리움 1단계(Layer 1) 자체를 더욱 확장 가능하게 만들기 위해 필요한 것이다. 장기적으로 보면, 유형 2 또는 유형 3 ZK-EVM에서 테스트된 이더리움 수정사항들이 이더리움 자체에 도입될 수 있지만, 이러한 재설계는 고유의 복잡성을 동반한다.
유형 1 ZK-EVM은 롤업에도 이상적인데, 기존 인프라를 대량으로 재사용할 수 있기 때문이다. 예를 들어, 이더리움 실행 클라이언트를 그대로 사용하여 롤업 블록을 생성하고 처리할 수 있다. (또는 추출 기능이 구현되면 재사용 가능하며, 이 기능은 롤업 내 ETH 입금을 지원하는 데에도 활용될 수 있다.) 따라서 블록 탐색기, 블록 생성 도구 등은 매우 쉽게 재사용할 수 있다.
단점: 검증 시간
이더리움은 처음부터 zk 친화성을 염두에 두고 설계된 것이 아니므로, 이더리움 프로토콜의 많은 부분은 zk로 검증하기 위해 상당한 계산이 필요하다. 유형 1의 목표는 이더리움을 완전히 복제하는 것이므로 이러한 비효율을 완화할 방법이 없다. 현재로서는 이더리움 블록의 증명 생성에 몇 시간씩 소요된다. 이러한 문제는 정교한 엔지니어링을 통해 검증기를 대규모로 병렬화하거나, 장기적으로는 ZK-SNARK 전용 회로(ZK-SNARK ASIC)를 통해 완화할 수 있다.
누가 개발 중인가?
프라이버시와 확장성 탐구 팀의 ZK-EVM이 유형 1 ZK-EVM을 개발하고 있다.
유형 2 (EVM과 완전히 동등)
제2유형 ZK-EVM은 EVM과 완전히 동등하되, 이더리움과는 완전히 동등하지 않다. 즉, "내부적으로"는 이더리움과 완전히 같아 보이지만, 블록 구조나 상태 트리 같은 데이터 구조와 같은 외부적인 면에서 약간 다를 수 있다.
기존 애플리케이션과 완전한 호환성을 유지하면서도, 개발을 용이하게 하고 증명 생성 속도를 높이기 위해 이더리움에 작은 수정을 가하는 것을 목표로 한다.
장점: 가상 머신 단계에서의 완전한 동등성
유형 2 ZK-EVM은 이더리움 상태 등을 저장하는 데이터 구조를 변경한다. 다행히도 이러한 구조들은 EVM이 직접 접근할 수 없으므로, 이더리움에서 작동하는 애플리케이션은 거의 언제나 유형 2 ZK-EVM 롤업에서도 작동한다. 하지만 이더리움 실행 클라이언트를 그대로 사용할 수는 없으며, 일부 수정을 거쳐야 사용할 수 있고, EVM 디버깅 도구와 대부분의 기타 개발자 인프라는 여전히 사용할 수 있다.
그러나 몇 가지 예외가 있다. 과거 트랜잭션, 영수증 또는 상태에 관한 주장을 검증하기 위해 과거 이더리움 블록의 메르클 증명(Merkle proof)을 검증하는 애플리케이션에서는 호환성 문제가 발생한다. (예: 브릿지가 이를 수행할 수 있음.) Keccak을 다른 해시 함수로 대체한 ZK-EVM은 이러한 증명을 깨뜨릴 것이다. 그러나 나는 일반적으로 이런 방식으로 앱을 개발하는 것을 권장하지 않는다. 미래의 이더리움 변경(예: Verkle Trees)조차도 이더리움 자체에서 이러한 앱들을 무력화시킬 것이기 때문이다. 이더리움 자체에 대해서는, 역사적 정보 접근을 위한 신뢰 가능한 사전컴파일을 추가하는 것이 더 나은 대안이다.
단점: 검증 시간 개선되었지만 여전히 느림
유형 2 ZK-EVM은 유형 1보다 더 빠른 검증 시간을 제공하는데, 이는 불필요하게 복잡하고 zk 친화적이지 않은 이더리움 스택의 일부를 제거하기 때문이다. 특히, 이더리움의 Keccak 및 RLP 기반 메르클 패트리샤 트리를 변경할 수 있으며, 블록과 영수증 구조도 마찬가지로 변경할 수 있다. 유형 2 ZK-EVM은 Poseidon과 같은 다른 해시 함수를 사용할 수도 있다. 또 하나의 자연스러운 수정은 코드 해시와 keccak을 저장하도록 상태 트리를 수정하여 EXTCODEHASH 및 EXTCODECOPY 오퍼코드 처리 시 해시 검증이 필요하지 않게 만드는 것이다.
이러한 수정은 검증 시간을 크게 향상시키지만, 모든 문제를 해결하지는 못한다. EVM 자체의 고유한 비효율성과 zk에 대한 비우호성 때문에 원본 EVM을 증명하는 과정은 여전히 느리다. 간단한 예로 메모리가 있는데, MLOAD는 32바이트의 임의 블록을 읽을 수 있으므로 (시작과 끝이 32의 배수가 아닌 "정렬되지 않은" 블록 포함), MLOAD는 단순히 하나의 블록을 읽는 것으로 설명될 수 없다. 오히려 연속된 두 개의 블록을 읽고 비트 연산을 수행해 결과를 결합해야 할 수 있다.
누가 개발 중인가?
스크롤(Scroll)의 ZK-EVM 프로젝트와 폴리곤 헤레즈(Polygon Hermez) 모두 유형 2 ZK-EVM을 향해 나아가고 있다. 다만, 아직 두 프로젝트 모두 완료되지 않았으며 (ZKEVM 작업이 완료되지 않음); 특히 많은 복잡한 사전컴파일들이 아직 구현되지 않았다. 따라서 현재로서는 두 프로젝트 모두 유형 3로 간주하는 것이 더 낫다.
유형 2.5 (EVM과 동등하지만 가스 비용 제외)
최악의 경우 검증 시간을 크게 개선하는 한 가지 방법은 ZK-EVM에서 증명하기 어려운 특정 작업에 대해 가스 비용을 크게 늘리는 것이다. 이는 사전컴파일, KECCAK 오퍼코드, 호출 규칙 또는 메모리, 스토리지, 리턴 데이터 접근 패턴에 적용될 수 있다.
변화하는 가스 비용은 개발자 도구의 호환성을 낮추고 일부 애플리케이션을 깨뜨릴 수 있지만, 일반적으로 "더 깊은" EVM 변경보다 위험이 적다고 여겨진다. 개발자는 트랜잭션에서 요구되는 가스 양이 블록 용량을 초과하지 않도록 하고, 하드코딩된 가스 양을 호출하지 않도록 주의해야 한다. (이미 오랫동안 개발자들에게 권장되어 온 표준 조언이다.)
유형 3 (거의 EVM과 동등)
제3유형 ZK-EVM은 거의 EVM과 동등하지만, 완전한 동등성을 이루기 위해 일부 타협을 감수하여 검증 시간을 더 빠르게 하고 EVM 개발을 더 쉽게 만든다.
장점: 개발이 더 쉬우며 검증 시간이 더 빠름
유형 3 ZK-EVM은 ZK-EVM 구현에서 특히 어렵게 구현되는 기능을 제거할 수 있다. 여기서 사전컴파일이 대개 우선 순위에 오르며, 때때로 유형 3 ZK-EVM은 계약 코드, 메모리 또는 스택을 처리하는 방식에서도 미묘한 차이를 가질 수 있다.
단점: 더 많은 비호환성
유형 3 ZK-EVM의 목표는 대부분의 애플리케이션과 호환되며, 나머지는 최소한의 재작성이 필요하도록 하는 것이다. 즉, 유형 3 ZK-EVM이 제거한 사전컴파일을 사용하거나, EVM과 다르게 처리되는 에지 케이스에 미묘하게 의존하는 일부 애플리케이션은 재작성이 필요하다.
누가 개발 중인가?
현재로서는 스크롤과 폴리곤 모두 유형 3이며, 시간이 지남에 따라 호환성을 개선할 것으로 기대된다. 폴리곤은 자신들의 내부 언어인 zkASM을 ZK로 검증하고, zkASM을 사용해 ZK-EVM 코드를 해석하는 독특한 설계를 갖고 있다. 이러한 구현 세부사항에도 불구하고, 나는 여전히 이를 진정한 유형 3 ZK-EVM이라고 부른다. 그것은 여전히 EVM 코드를 검증할 수 있으며, 다만 다른 내부 로직을 사용해 이를 수행할 뿐이다.
현재로선 어떤 ZK-EVM 팀도 유형 3가 되기를 원하지 않는다. 유형 3는 단지 사전컴파일 추가 작업이 완료되고 프로젝트가 유형 2.5로 전환되기까지의 일시적인 단계일 뿐이다. 그러나 미래에는 유형 1 또는 유형 2 ZK-EVM이 새로운 zk-SNARK 친화적인 사전컴파일을 추가함으로써 자발적으로 유형 3 ZK-EVM이 될 수 있다. 이렇게 하면 개발자들이 낮은 검증 시간과 가스 비용으로 기능을 이용할 수 있게 된다.
유형 4 (고급 언어와 동등)
유형 4 시스템은 고급 언어(예: Solidity, Vyper 또는 둘 다가 컴파일하는 중간 언어)로 작성된 스마트 계약 소스 코드를 가져와, 명시적으로 zk-snark 친화적으로 설계된 언어로 컴파일하는 방식으로 작동한다.
장점: 매우 빠른 검증 시간
각 EVM 실행 단계의 모든 부분을 zk로 증명하는 대신 고급 코드에서 바로 시작함으로써 많은 오버헤드를 피할 수 있다.
본문에서 이 장점을 단 한 문장으로만 설명했지만(아래의 호환성 관련 단점 목록과 비교하면), 이것은 가치 판단으로 받아들여져서는 안 된다! 고급 언어에서 직접 컴파일하는 것은 실제로 비용을 크게 줄이고, 증명자가 되는 것을 더 쉽게 만들어 분산화를 도울 수 있다.
단점: 더 많은 비호환성
Vyper나 Solidity로 작성된 "일반적인" 애플리케이션은 컴파일되어 "정상적으로 작동"할 수 있지만, 많은 애플리케이션이 "정상적으로 작동하지 않는" 중요한 측면들이 있다:
- CREATE2 주소 결정 방식은 정확한 바이트코드에 의존하므로, 유형 4 시스템에서의 계약 주소는 EVM에서의 주소와 다를 수 있다. 이는 아직 배포되지 않은 "반사실적 계약(counterfactual contracts)", ERC-4337 지갑, EIP-2470 싱글톤 등에 의존하는 애플리케이션을 깨뜨린다.
- 수작업 EVM 바이트코드 사용이 어려워진다. 효율성을 높이기 위해 많은 애플리케이션은 일부 부분에 수작업 EVM 바이트코드를 사용한다. 유형 4 시스템은 이를 지원하지 않을 수 있지만, 이러한 용례를 위해 전체 유형 3 ZK-EVM이 되지 않고도 제한된 EVM 바이트코드 지원을 구현하는 방법들이 있다.
- 많은 디버깅 인프라가 계속 작동하지 않는다. EVM 바이트코드에서 작동하기 때문이다. 다만, 더 전통적인 고급 또는 중간 언어(예: LLVM)에서 디버깅 인프라에 접근함으로써 이 단점은 어느 정도 완화될 수 있다.
개발자는 이러한 문제들에 주의해야 한다.
누가 개발 중인가?
ZKSync는 유형 4 시스템이며, 시간이 지남에 따라 EVM 바이트코드 호환성을 추가할 수도 있다. 네더마인드(NetherMind)의 Warp 프로젝트는 Solidity에서 스타크웨어의 카이로(Cairo)로 컴파일하는 컴파일러를 개발하고 있으며, 이는 스타크넷(StarkNet)을 사실상 유형 4 시스템으로 만들 것이다.
다양한 유형의 ZK-EVM의 미래
이러한 유형들은 명백하게 다른 유형보다 '더 좋다'거나 '더 나쁘다'라고 할 수 없다. 오히려 이들은 서로 다른 절충점의 지점에 있다. 즉, 코딩 난이도가 낮은 유형은 기존 인프라와 더 호환되지만 속도는 느리고, 코딩 난이도가 높은 유형은 기존 인프라와의 호환성은 낮지만 속도는 빠르다. 전반적으로 이러한 모든 유형들이 탐구되고 있다는 점은 이 분야에 건강한 현상이다.
- ZK-EVM은 일부 특별히 zk 증명이 어려운 기능을 포함하지 않기 위해 유형 3에서 시작할 수 있다. 이후 시간이 지나면서 이러한 기능을 추가해 유형 2로 전환할 수 있다.
- ZK-EVM은 유형 2에서 시작해, 전 이더리움 호환 모드로 실행하거나 더 빠르게 증명할 수 있는 수정된 상태 트리를 사용할 수 있는 가능성을 제공함으로써 혼합형 2/유형 1 ZK-EVM이 될 수 있다. Scroll은 이러한 방향을 고려하고 있다.
- 유형 4에서 시작한 시스템은 EVM 코드를 처리할 수 있는 기능을 나중에 추가함으로써 유형 3이 될 수 있다. (비록 개발자들에게는 여전히 고급 언어에서 직접 컴파일할 것을 권장해 비용과 검증 시간을 줄이도록 하겠지만.)
- 이더리움 자체가 ZK 친화성을 높이기 위해 수정을 채택한다면, 유형 2 또는 유형 3 ZK-EVM은 유형 1 ZK-EVM이 될 수 있다.
- 유형 1 또는 유형 2 ZK-EVM은 ZK-SNARK 친화적인 언어로 작성된 코드를 검증하는 사전컴파일을 추가함으로써 유형 3 ZK-EVM이 될 수 있다. 이는 개발자들이 이더리움 호환성과 속도 사이에서 선택할 수 있도록 해줄 것이다. 이는 완벽한 EVM 동등성을 깨뜨리므로 유형 3이 되지만, 실제 목적과 관점에서 보면 유형 1과 유형 2의 많은 장점을 갖게 된다. 주요 단점은 일부 개발자 도구가 ZK-EVM의 맞춤형 사전컴파일을 이해하지 못할 수 있다는 점인데, 이는 수정 가능하다. 개발자 도구는 사전컴파일을 포함한 EVM 코드의 등가 구현을 지원하는 구성 형식을 추가함으로써 일반적인 사전컴파일 지원을 추가할 수 있다.
개인적으로 나는 시간이 지남에 따라 모든 것이 유형 1이 되기를 바란다. 즉, ZK-EVM의 개선과 이더리움 자체의 ZK-SNARK에 적합하도록 개선을 통해 말이다. 그런 미래에는 ZK 롤업뿐만 아니라 이더리움 자체를 검증하는 데에도 여러 ZK-EVM 구현이 있을 것이다. 이론적으로 이더리움 L1에서 사용하는 단일 ZK-EVM 구현에 표준화할 필요는 없다. 서로 다른 클라이언트가 서로 다른 증명을 사용할 수 있으므로, 우리는 여전히 코드 중복성의 이점을 누릴 수 있다.
그러나 그러한 미래에 도달하기까지는 상당한 시간이 필요하다. 그 동안 우리는 이더리움 및 이더리움 기반 ZK-롤업의 확장 경로에서 다양한 혁신들을 목격하게 될 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@VitalikButerin
