zkSync2.0 메인넷 런칭을 맞아 다양한 zkEVM 분석

저자：IOBC Capital

이더리움의 발전 경로는 점점 모듈형 블록체인으로 기울어지고 있으며, 본질적으로 Layer1의 데이터 샤딩과 Layer2의 롤업 확장을 결합하여 모듈화된 아키텍처로 발전하고 있습니다. 이를 통해 이더리움은 "세계 컴퓨터"라는 초기 목표를 실현하고자 합니다. 롤업의 기술 경로 선택에서 ZK 롤업은 이더리움 확장의 궁극적인 목표로 여겨집니다.

ZK 롤업

ZK 롤업의 핵심 작업 메커니즘은 체인上的 사용자 상태를 머클 트리에 압축 저장하고, 사용자 상태의 변화를 체인 외부에서 처리하며, zksnark/zkstark 증명을 통해 체인 외부의 사용자 상태 변화 과정의 정확성을 보장하는 것입니다. 쉽게 이해하자면, ZK 롤업은 zksnark 또는 zkstark를 통해 아선형 처리를 사용하여 선형 수의 문장을 검증하는 것으로 이해할 수 있습니다. 예를 들어, 1000개의 문장은 10번의 검증자가 검토해야 하고, 10000개의 문장은 11번의 검증자가 검토해야 합니다. 따라서 결과적으로 ZK 롤업은 이더리움의 확장을 실현할 수 있습니다.

ZK 롤업의 대략적인 블록체인 거래 처리 과정은 다음과 같습니다:

1. 사용자가 L1의 zk 롤업 스마트 계약에 자산을 잠급니다;
2. 사용자가 이 자산과 관련된 거래를 L2에 제출하면, L2의 특정 역할(시퀀서, 초기 다수의 프로젝트는 중앙화된 방식이었으며, 일부 프로젝트는 탈중앙화 방식을 채택하기 시작했습니다)이 이러한 거래를 특정 규칙에 따라 수집하여 정렬된 배치로 만들고, 각 배치에 대해 유효성 증명(zksnark/zkstark)과 집계 상태 업데이트를 생성합니다;
3. 이 상태 업데이트와 증명이 L1의 zk 롤업 스마트 계약에 제출되고 검증되면, L1의 블록체인에서 업데이트됩니다;
4. 사용자는 이러한 L1 상태(다양한 데이터 가용성 메커니즘에 따라)로 자산을 검색할 수 있어 완전한 자가 관리가 가능하므로 zk 롤업은 이더리움의 보안을 계승한 것으로 여겨집니다.

zkEVM의 필요성

잘 알려진 바와 같이, 1세대 ZK 롤업은 EVM을 지원하지 않으며, 프로그래머블성과 조합성이 떨어져 특정한 시나리오에만 제한됩니다. 예를 들어, Loopring은 Payments&Swaps와 같은 시나리오에만 제한되며; Immutable은 NFT 민팅&트레이딩&게임과 같은 시나리오에만 제한됩니다; zksync1.0은 사실 zkEVM을 지원하지 않습니다. 일반성이 없습니다.

이후, 주요 ZK 롤업들은 ZK 롤업에서 EVM 바이트코드를 지원하는 코드 실행 환경을 개발하기 시작하여 이더리움의 스마트 계약이 이더리움에서 ZK 롤업으로 이전할 수 있도록 하였습니다.

EVM은 2015년에 출시된 최초의 튜링 완전 블록체인 가상 머신입니다. 현재까지 가장 검증된 블록체인 가상 머신이며, 이더리움의 중요한 스마트 계약 인프라입니다. 다른 블록체인에 대해 이야기할 때도 EVM 호환 여부가 평가 기준으로 사용되며, EVM 호환성은 단순히 스마트 계약 실행 환경을 넘어 이더리움 생태계와 도구 세트를 포함하며, 무시할 수 없는 네트워크 효과를 나타냅니다. 따라서 ZK 롤업도 이 부분을 간과할 수 없었습니다.

zkEVM은 EVM을 스마트 계약 엔진으로 하여 ZK 롤업에서 실행하는 것으로 이해할 수 있습니다. zkEVM의 목표는 롤업의 성능 이점을 잃지 않으면서 이더리움 경험을 L2로 완전히 가져오는 것입니다.

현재까지 zkSync2.0, Polygon Hermez2.0, Scroll 등 주요 범용 ZK 롤업 프로젝트는 zkEVM 테스트넷을 출시하였으며, StarkNet은 이미 알파 메인넷 단계에 들어섰습니다.

zkEVM의 호환성 분류

현재 ZK 롤업의 zkEVM은 이더리움 자체와 완전히 호환되지 않으며, "이더리움 동등성"의 궁극적인 비전은 더욱 멀어 보입니다. 따라서 이더리움 자체의 업그레이드 계획이 롤업 친화적으로 진행되고 있을 뿐만 아니라, 각 ZK 롤업 프로젝트도 이더리움과의 호환성 문제를 해결하기 위해 지속적으로 노력하고 있습니다.

Vitalik은 기존 EVM 인프라와의 호환성 정도에 따라 zkEVM 범용 ZK 롤업을 4가지 유형으로 분류하였습니다:

Type-1: 이더리움과 완전히 동등

Type-1형 zkEVM은 이더리움과 완전히 동등하고 타협하지 않으려 합니다. 이더리움 시스템의 어떤 부분도 변경할 필요가 없으며, 해시, 상태 트리, 거래 트리, 프리컴파일 또는 기타 합의 논리를 대체할 필요가 없습니다. 간단히 말해, Type-1형 zkEVM은 이더리움과 완전히 동등합니다.

Type-1형 zkEVM은 이더리움처럼 이더리움 블록을 검증할 수 있으며, 최소한 실행 계층 단에서(모든 거래 실행, 스마트 계약 및 계정 논리를 포함하되, 신호 체인 합의 논리는 제외) 검증할 수 있습니다.

Type-1형 zkEVM은 이더리움이 궁극적으로 필요로 하는 것이며, 롤업의 가장 이상적인 선택입니다. 한편으로는 Type-1형 zkEVM이 롤업이 많은 인프라를 재사용할 수 있게 하며(예: Ethereum Execution Clients, Block Explorers, Block Production 등), 다른 한편으로는 Type-1형 zkEVM이 이더리움 Layer1 자체를 더 확장 가능하게 만듭니다. Type-1형 zkEVM에서 탐색된 이더리움에 대한 일부 수정 사항은 미래에 이더리움 자체에 도입될 수 있습니다.

물론 Type-1형 zkEVM에도 단점이 있습니다. 이더리움은 처음부터 ZK 친화적으로 설계되지 않았기 때문에, 이더리움 프로토콜의 많은 부분이 ZK 증명을 수행하기 위해 많은 계산을 필요로 합니다. Type-1형은 이더리움과 마찬가지로 이 문제에서 비효율성을 완화할 수 없습니다(증명 생성에 오랜 시간이 걸립니다). 이 문제에 대한 현재 업계에서 제안된 해결책은 주로 병렬 증명을 대규모로 수행하거나 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 zkEVM보다 더 빠릅니다. 이러한 수정은 증명자의 효율성을 크게 향상시켰지만, 증명 시간이 느린 문제를 근본적으로 해결하지는 못했습니다. 요약하자면, Type-2의 증명 시간은 여전히 느립니다.

Type-3: 거의 EVM과 동등

Type-3형 zkEVM은 거의 EVM과 동등하며, 호환성 측면에서 일부 희생이 있지만, EVM은 개발하기 더 쉽습니다.

Type-3형 zkEVM은 zkEVM에서 구현하기 어려운 기능(예: 프리컴파일)을 제거하고, 계약 코드, 메모리 또는 스택 처리에서 조정을 통해 전반적으로 동등성 측면에서 일부 희생을 하여 더 많은 검증자 시간을 확보하고 EVM을 더 쉽게 개발할 수 있게 합니다.

호환성 측면에서 희생이 있으며, 일부 애플리케이션이 Type-3형 zkEVM에서 제거된 프리컴파일을 사용하고 있기 때문에, 이러한 애플리케이션은 일부를 다시 작성해야 합니다.

현재 Scroll과 Polygon은 Type-3에 해당합니다. 물론 장기적으로는 어떤 zkEVM 팀도 Type-3에 오랫동안 머물겠다고 공개적으로 밝힌 바는 없습니다. Scroll과 Polygon Hermez는 Type-2형 zkEVM 방향으로 발전하고 있으며, 아직 구현되지 않은 복잡한 프리컴파일이 많이 남아 있습니다.

Type-4: 고급 언어 동등

Type-4는 실제로 zkVM에 해당합니다. Type-4 시스템은 고급 언어(Solidity, Vyper)로 작성된 스마트 계약 소스 코드를 가져와 ZK-SNARK 친화적으로 설계된 특정 언어로 컴파일하여 작동합니다.

장단점이 뚜렷합니다. Type-4는 각 EVM 실행 단계의 모든 다양한 부분에 대해 ZK 증명을 수행하지 않기 때문에 매우 빠른 검증 시간을 가지며, 더 높은 수준의 코드에서 시작하여 비용을 줄이고 더 빠른 검증 시간을 얻습니다. 호환성은 떨어지며, Type-4 시스템에서의 계약 주소는 EVM에서의 주소와 다릅니다; 수동으로 작성된 EVM 바이트코드는 사용하기 더 어렵고; 많은 디버깅 인프라는 상속될 수 없습니다. 왜냐하면 이러한 인프라는 EVM 바이트코드에서 실행되기 때문입니다.

요약하자면, Type-4는 언어 수준 동등성에 해당하며, 바이트코드 수준 동등성과 비교할 때 호환성 측면에서 큰 차이가 있습니다. Vitalik의 관점에 따르면, 현재 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 유형에 속한다는 것을 발견할 수 있습니다.

Vitalik은 시간이 지남에 따라 zkEVM의 개선과 이더리움 자체의 개선이 결합되어 궁극적으로 모든 zkEVM이 Type-1이 되기를 희망합니다. 이러한 이점은 미래에 여러 개의 zkEVM이 존재하여 ZK 롤업에도 사용되고 이더리움 체인 자체를 검증하는 데에도 사용될 수 있다는 것입니다(미래의 이더리움은 ZK-SNARK에 더 친화적일 것입니다).

Vitalik이 제안한 관점은 일반적으로 전체 산업의 합의를 쉽게 이끌어낼 수 있으며, 저도 매우 동의합니다. Type-1형 zkEVM 프로젝트는 이더리움 생태계에서 자연스럽게 가장 인기가 많고, 이더리움 L1과 잘 맞습니다. 그러나 Type-4형 zkVM도 실행 계층 프로젝트의 좋은 기술 솔루션 선택이 될 수 있습니다. 주로 두 가지 이유가 있습니다:

1. 모듈형 블록체인 내러티브 하에 zkVM은 다른 L1과의 연결이 더 용이합니다. 단순히 이더리움 생태계 L2를 만드는 사고에서 벗어나, 바이트코드 수준에서 이더리움 가상 머신과 호환되지 않고 zkVM을 선택하면, 오히려 미래에 다른 L1 합의 계층과의 연결이 더 용이할 수 있습니다;
2. 현재 ZK 롤업의 성능 한계는 증명 생성 속도에 의해 제한됩니다. Type-4형 zkVM은 이점이 있습니다. 실행 계층의 증명 생성 속도는 여전히 매우 중요하며, L2가 실행 계층의 성능을 극대화하는 것도 좋은 접근 방식이 될 수 있습니다. 비록 미래에 ASIC 하드웨어 가속을 통해 증명 생성 효율성을 높일 수 있을지라도, 그 효과는 미지수이며, Type-4형 zkVM의 증명 생성 속도가 빠른 것은 중요한 장점입니다.

물론 zkEVM의 호환성과 속도는 실제로 개발자가 어떤 ZK 롤업을 기반으로 애플리케이션을 개발할지 고려하는 유일한 지표가 아닙니다. 그들의 선택에 영향을 미치는 많은 다른 요소들이 있습니다. 예를 들어:

• 비용: 어떤 토큰으로 비용을 지불할지, L2 비용의 감소 정도도 매우 중요한 고려 요소입니다. 그러나 대부분의 범용 ZK 롤업 프로젝트는 아직 테스트넷 단계에 있어 비교할 수 없습니다;
• 증명 생성 규칙: 어떤 사람들이 증명자로 지원되는지, 심지어 어떤 하드웨어를 사용하여 증명 생성을 가속화하는지;
• L2 거래 정렬 규칙: 단일 시퀀서를 사용할지 아니면 탈중앙화 방식을 사용할지;
• 자가 관리: L2에서 사고가 발생했을 때 L1에서 사용자 자산을 복구할 수 있도록 보장하는 명확한 메커니즘이 있는지;
• 데이터 가용성: 완전한 데이터 가용성 비용은 자연스럽게 더 높으며, 일부 ZK 롤업이 채택한 낮은 비용의 데이터 가용성 모델을 수용할 수 있는지.

요약하자면, 각 ZK 롤업의 zkEVM은 여러 성능 간의 타협이 있으며, 실제로 절대적인 우열이 없습니다.