비탈릭: 다양한 유형의 ZK-EVM의 미래

원문 제목：《The different types of ZK-EVMs》

저자：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 롤업을 구축하는 것입니다. 그러나 이러한 프로젝트 간에는 미묘한 차이가 있으며, 실용성과 속도 간의 균형이 존재합니다. 이 글에서는 EVM 동등성의 다양한 「유형」을 분류하고, 각 유형을 구현하는 것의 장점과 비용을 설명하려고 합니다.

개요 ( 차트 형식 )

유형 1（이더리움과 완전 동등）

첫 번째 유형의 ZK-EVM은 이더리움과 완전하고 타협 없는 동등성을 추구합니다. 이들은 증명을 생성하기 쉽게 하기 위해 이더리움 시스템의 어떤 부분도 변경하지 않습니다. 해시, 상태 트리, 트랜잭션 트리, 프리컴파일 또는 기타 합의 논리를 대체하지 않으며, 그 어떤 것이든 주변적일지라도 말입니다.

장점: 완벽한 호환성

우리의 목표는 현재와 같이 이더리움 블록을 검증할 수 있는 것이며, 최소한 실행 레이어를 검증하는 것입니다 (따라서 신호 체인 합의 논리는 포함되지 않지만 모든 거래 실행 및 스마트 계약 및 계정 논리는 포함됩니다).

유형 1: ZK-EVM은 이더리움 1층 자체를 더 확장 가능하게 만드는 것입니다. 장기적으로 유형 2 또는 유형 3 ZK-EVM에서 테스트된 이더에 대한 수정 사항이 이더 자체에 도입될 수 있지만, 이러한 재설계는 자체적인 복잡성을 동반합니다.

유형 1: ZK-EVM은 또한 집계의 이상적인 선택입니다. 왜냐하면 이들은 집계가 많은 기본 인프라를 재사용할 수 있도록 허용하기 때문입니다. 예를 들어, Etherum Execution 클라이언트는 ROLLUP 블록을 생성하고 처리하는 데 원래대로 사용될 수 있습니다 (또는 최소한, 추출이 구현된 후에는 재사용될 수 있으며, 이 기능은 ROLLUP에 저장된 ETH를 지원하기 위해 재사용될 수 있습니다), 따라서 블록 리소스 관리 도구, 블록 생산 등의 도구는 매우 쉽게 재사용될 수 있습니다.

단점: 검증 시간

이더리움은 처음부터 zk 친화성을 염두에 두고 설계되지 않았기 때문에 이더리움 프로토콜의 많은 부분은 zk를 검증하기 위해 많은 계산을 필요로 합니다. 유형 1의 목표는 이더리움을 완전히 복제하는 것이므로 이러한 비효율성을 완화할 방법이 없습니다. 현재 이더리움 블록의 증명은 생성하는 데 몇 시간이 걸립니다. 이러한 상황은 교묘한 엔지니어링을 통해 대규모로 검증기를 병렬화하거나, 장기적으로는 ZK-SNARK 전용 집적 회로를 통해 완화될 수 있습니다.

제작자는 누구인가?

개인 정보 보호 및 확장 탐색 팀 ZK-EVM이 유형 1 ZK-EVM을 구축하고 있습니다.

유형 2 ( 완전 동등 EVM )

두 번째 유형의 ZK-EVM은 EVM과 완전 동등하지만 이더리움과는 완전 동등하지 않습니다. 즉, 내부적으로는 이더리움처럼 보이지만, 외부적으로는 블록 구조 및 상태 트리와 같은 데이터 구조에서 약간의 차이가 있습니다.

그 목표는 기존 애플리케이션과 완전히 호환되지만, 이더리움을 약간 수정하여 개발을 더 쉽게 하고 증명을 더 빠르게 생성하는 것입니다.

장점: 가상 머신 수준에서 완전한 동등성 구현

유형 2 ZK-EVM은 이더 상태 등을 저장하는 데이터 구조를 변경합니다. 다행히도 이러한 구조는 EVM 자체가 직접 접근할 수 없으므로 Etherum에서 작동하는 애플리케이션은 거의 항상 유형 2 ZK-EVM 집계에서 작동합니다. Etherum Execution 클라이언트를 원래대로 사용할 수는 없지만, 약간의 수정으로 사용할 수 있으며, 여전히 EVM 디버깅 도구와 대부분의 다른 개발자 인프라를 사용할 수 있습니다.

하지만 몇 가지 예외가 있습니다. 역사적 이더 블록의 Merkle 증명을 검증하여 역사적 거래, 영수증 또는 상태에 대한 진술을 검증하는 애플리케이션에서는 비호환성이 발생합니다 (예: 브리지가 가끔 이렇게 합니다). Keccak을 대체하는 다른 해시 함수를 사용하는 ZK-EVM은 이러한 증명을 깨뜨릴 것입니다. 그러나 일반적으로 이러한 방식으로 애플리케이션을 구축하지 않는 것이 좋습니다. 왜냐하면 미래의 이더 변경 (예: Verkle Trees)조차도 이더 자체에서 이러한 애플리케이션을 파괴할 수 있기 때문입니다. 이더리움 자체에 대해 더 나은 대안은 미래에 신뢰할 수 있는 역사적 접근 프리컴파일을 추가하는 것입니다.

단점: 검증 시간이 개선되었지만 여전히 느림

유형 2 ZK-EVM은 유형 1보다 더 빠른 검증 시간을 제공하는데, 이는 주로 불필요한 복잡성과 비우호적인 ZK 암호화에 의존하는 이더 스택의 일부를 제거함으로써 이루어집니다. 특히, 이들은 Etherum의 Keccak 및 RLP 기반 Merkle Patricia 트리를 변경할 수 있으며, 블록 및 수신 구조도 변경할 수 있습니다. 유형 2 ZK-EVM은 Poseidon과 같은 다른 해시 함수를 사용할 수 있습니다. 또 다른 자연스러운 수정은 상태 트리를 수정하여 코드 해시와 keccak을 저장하여 EXTCODEHASH 및 EXTCODECOPY 작업 코드를 처리하기 위해 해시를 검증할 필요가 없도록 하는 것입니다.

이러한 수정은 검증 시간을 크게 향상시키지만 모든 문제를 해결할 수는 없습니다. EVM 고유의 비효율성과 zk에 대한 비우호성으로 인해 EVM을 원래대로 증명하는 과정은 여전히 느립니다. 간단한 예로 메모리를 들 수 있습니다: MLOAD는 "정렬되지 않은" 블록(시작과 끝이 32의 배수가 아닌 경우)을 포함하여 모든 32바이트를 읽을 수 있기 때문에 MLOAD는 단순히 블록을 읽는 것으로 해석될 수 없습니다; 대신, 두 개의 연속 블록을 읽고 결과를 결합하기 위해 비트 연산을 수행해야 할 수 있습니다.

제작자는 누구인가?

Scroll의 ZK-EVM 프로젝트는 유형 2 ZK-EVM 방향으로 발전하고 있으며, Polygon Hermez와 마찬가지입니다. 즉, 이 두 프로젝트는 아직 완료되지 않았습니다 (ZKEVM 작업이 완료되지 않음); 특히, 많은 더 복잡한 프리컴파일이 아직 구현되지 않았습니다. 따라서 현재 두 프로젝트 모두 유형 3을 고려하는 것이 가장 좋습니다.

유형 2.5 ( EVM과 동등하지만 가스 비용 제외 )

최악의 경우 검증 시간을 크게 개선하는 한 가지 방법은 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이 다르게 처리하는 경계 사례에 대한 미세한 의존성 때문에 재작성해야 할 수 있습니다.

제작자는 누구인가?

Scroll과 Polygon은 현재 모두 유형 3 형태이지만, 시간이 지남에 따라 호환성을 개선할 것으로 기대됩니다. Polygon은 ZK를 사용하여 내부 언어 zkASM을 검증하고, zkASM을 사용하여 ZK-EVM 코드를 해석하는 독특한 설계를 가지고 있습니다. 이러한 구현 세부 사항이 있음에도 불구하고, 저는 여전히 이를 진정한 유형 3 ZK-EVM이라고 부릅니다; 여전히 EVM 코드를 검증할 수 있지만, 이를 완료하기 위해 약간 다른 내부 논리를 사용합니다.

오늘날 ZK-EVM 팀은 유형 3이 되고 싶어하지 않습니다; 유형 3은 단지 프리컴파일의 복잡한 작업이 완료될 때까지의 과도기일 뿐이며, 프로젝트는 유형 2.5로 전환할 수 있습니다. 그러나 미래에는 유형 1 또는 유형 2 ZK-EVM이 자발적으로 유형 3 ZK-EVM이 될 수 있으며, 새로운 ZK-SNARK 친화적 프리컴파일러를 추가하여 개발자에게 낮은 검증 시간과 가스 비용의 기능을 제공할 수 있습니다.

유형 4 ( 고급 언어에 해당 )

유형 4 시스템의 작동 방식은 고급 언어로 작성된 스마트 계약 소스 코드를 (예: SOLIDITY, VYPER 또는 두 언어 모두 컴파일되는 중간 언어) 가져와서 ZK-snark 친화적으로 명확하게 설계된 언어로 컴파일하는 것입니다.

장점: 검증 시간이 매우 빠름

각 EVM 실행 단계의 모든 다양한 부분을 증명하기 위해 ZK를 사용하지 않고 더 높은 수준의 코드에서 직접 시작함으로써 많은 오버헤드를 피할 수 있습니다.

이 장점은 이 글에서 단 한 문장으로 설명되었지만 (아래의 호환성과 관련된 단점의 대규모 목록과 비교하여), 이는 가치 판단으로 해석되어서는 안 됩니다! 고급 언어에서 직접 컴파일하는 것은 실제로 비용을 크게 줄일 수 있으며, 증명자를 더 쉽게 만들어 분산화에 도움을 줄 수 있습니다.

단점: 더 많은 비호환성

Vyper 또는 Solidity로 작성된 "정상적인" 애플리케이션은 컴파일될 수 있으며 "정상적으로 작동"하지만, 많은 애플리케이션이 "정상적으로 작동"하지 않는 몇 가지 중요한 측면이 있습니다:

• 유형 4 시스템에서 계약의 주소는 EVM에서의 주소와 다를 수 있습니다. CREATE2 프로토콜 주소는 정확한 바이트코드에 따라 달라지기 때문입니다. 이는 아직 배포되지 않은 "반사 계약", ERC-4337 지갑, EIP-2470 단일 인스턴스 및 많은 다른 애플리케이션에 의존하는 애플리케이션을 깨뜨립니다.
• 수동으로 작성된 EVM 바이트코드는 사용하기 더 어렵습니다. 효율성을 높이기 위해 많은 애플리케이션은 특정 부분에서 수동으로 작성된 EVM 바이트코드를 사용합니다. 유형 4 시스템은 이를 지원하지 않을 수 있지만, 이러한 사용 사례를 충족하기 위해 제한된 EVM 바이트코드 지원을 구현하는 방법이 있을 수 있습니다. 이는 완전한 유형 3 ZK-EVM이 되기 위한 노력을 필요로 하지 않습니다.
• 많은 디버깅 인프라는 계속 사용할 수 없습니다. 이러한 인프라는 EVM 바이트코드에서 실행되기 때문입니다. 즉, "전통적인" 고급 또는 중간 언어에서 디버깅 인프라에 더 많이 접근함으로써 이 단점이 완화됩니다 (예: LLVM).

개발자는 이러한 문제에 주의해야 합니다.

제작자는 누구인가?

ZKSync는 유형 4 시스템이며, 시간이 지남에 따라 EVM 바이트코드에 대한 호환성을 증가시킬 수 있습니다. NetherMind의 Warp 프로젝트는 Solidity에서 Starkware의 Cairo로 컴파일하는 컴파일러를 구축하고 있으며, 이는 StarkNet을 사실상의 유형 4 시스템으로 만들 것입니다.

여러 유형의 ZK-EVM의 미래

이러한 유형은 다른 유형보다 명확하게 "더 좋다"거나 "더 나쁘다"고 할 수 없습니다. 반대로, 이들은 균형 공간에서 서로 다른 점입니다: 코딩 난이도가 낮은 유형은 기존 인프라와 더 호환되지만 속도가 느리고; 코딩 난이도가 높은 유형은 기존 인프라와 덜 호환되지만 속도가 더 빠릅니다. 전반적으로 이러한 모든 유형은 탐색 중이며, 이는 이 분야에 건강한 영향을 미칩니다.

• ZK-EVM은 유형 3에서 시작하여 특별히 어려운 ZK 증명의 기능을 포함하지 않기로 결정할 수 있습니다. 이후 시간이 지남에 따라 이러한 기능을 추가하고 유형 2로 전환할 수 있습니다.
• ZK-EVM은 유형 2에서 시작하여 전체 이더 호환 모드에서 실행되거나 더 빠르게 증명할 수 있는 수정된 상태 트리를 사용할 수 있는 가능성을 제공하여 혼합형 2/유형 1 ZK-EVM으로 변할 수 있습니다. Scroll은 이 방향으로 발전하는 것을 고려하고 있습니다.
• 유형 4에서 시작하는 시스템은 시간이 지남에 따라 유형 3으로 발전할 수 있으며, 이후 EVM 코드 처리 기능이 추가될 수 있습니다 (비록 여전히 개발자가 비용과 검증 시간을 줄이기 위해 고급 언어에서 직접 컴파일하는 것이 권장됩니다).
• 만약 이더리움 자체가 수정 사항을 채택하여 ZK에 더 친화적으로 노력한다면, 유형 2 또는 유형 3 ZK-EVM은 유형 1 ZK-EVM이 될 수 있습니다.
• 유형 1 또는 유형 2의 ZK-EVM은 프리컴파일러를 추가하여 ZK-SNARK 친화적 언어에서 코드를 검증함으로써 유형 3 ZK-EVM이 될 수 있습니다. 이는 개발자가 이더 호환성과 속도 간의 선택을 할 수 있게 하며, 이는 유형 3이 되기 때문에 완벽한 EVM의 동등성을 깨뜨리지만, 실제 목적과 목적에서 유형 1 및 유형 2의 많은 이점을 가질 것입니다. 주요 단점은 일부 개발자 도구가 ZK-EVM의 맞춤형 프리컴파일을 이해하지 못할 수 있다는 점이지만, 이는 수정할 수 있습니다: 개발자 도구는 프리컴파일을 포함한 EVM 코드 동등 구현의 구성 형식을 지원하여 일반 프리컴파일 지원을 추가할 수 있습니다.

개인적으로, 저는 시간이 지남에 따라 모든 것이 유형 1로 발전하기를 바라며, ZK-EVM을 개선하고 이더리움 자체를 개선하여 ZK-Snark에 더 적합하게 만들기를 바랍니다. 그런 미래에는 여러 ZK-EVM 구현이 존재하여 ZK 롤업과 이더리움 자체를 검증하는 데 사용될 수 있습니다. 이론적으로, 이더리움은 L1에서 사용할 단일 ZK-EVM 구현을 표준화할 필요가 없습니다; 서로 다른 클라이언트는 서로 다른 증명을 사용할 수 있으므로 우리는 코드 중복의 이점을 계속 누릴 수 있습니다.

그러나 우리는 그러한 미래에 도달하기 위해 상당한 시간이 필요합니다. 그동안 우리는 이더리움을 확장하고 이더리움 기반 ZK 집계의 다양한 경로에서 많은 혁신을 목격할 것입니다.