zkEVM
zkEVM(영지식 이더리움 가상 머신)은 이더리움 가상 머신(EVM)과 호환되는 스마트 계약을 실행하고, 영지식 기술을 사용하여 이러한 실행에 대한 암호화 증명을 생성하는 가상 머신입니다. 이는 이더리움 메인 네트워크를 활용하여 높은 수준의 보안을 유지하면서 트랜잭션 처리량을 늘리고 비용을 절감하는 것을 목표로 하는 이더리움 확장 솔루션으로 설계되었습니다. zkEVM은 수많은 트랜잭션을 묶어 오프체인에서 실행한 다음 메인 블록체인에 간결한 유효성 증명을 게시함으로써, 모든 네트워크 노드가 트랜잭션을 재실행할 필요 없이 계산 결과를 검증할 수 있도록 합니다. [1] [2]
Overview
The primary motivation behind zkEVM development is to address the scalability bottleneck of the Ethereum network. In Ethereum's standard model, every validator node must re-execute every transaction within a block to verify its validity, a process referred to as "N-of-N execution." This redundant computation limits the network's capacity and is a contributing factor to high gas fees during periods of high demand. [3]
zkEVMs propose a "1-of-N" model, where a single specialized entity, known as a "prover," executes a block of transactions and generates a succinct cryptographic proof (a ZK-proof) confirming the correctness of the execution. Network validators then only need to verify this computationally inexpensive proof instead of re-running the entire block. This paradigm shift dramatically reduces the computational load on the network, enabling higher throughput and more affordable fees. [4]
While earlier ZK-Rollups provided scalability benefits, they often did so at the cost of EVM compatibility, limiting their use to specific applications and requiring developers to learn new languages or tooling. zkEVMs are a significant evolution because they aim to be compatible or equivalent with the EVM, allowing developers to deploy existing Ethereum smart contracts and decentralized applications (dApps) onto a more scalable layer with minimal to no code modifications. This approach allows projects to tap into Ethereum's extensive ecosystem of developers, tools, and infrastructure. [1] [5]
The technology is applied in two primary contexts: as Layer 2 rollups that operate on top of Ethereum, and in a more ambitious proposal to integrate a zkEVM directly into Ethereum's Layer 1 protocol to scale the mainnet itself. [6]
zkEVM의 작동 원리
zkEVM 아키텍처는 기본적으로 온체인 검증과 함께 오프체인 연산을 용이하게 하는 세 가지 핵심 구성 요소로 이루어져 있습니다. [2]
핵심 구성 요소
- 실행 환경 (Execution Environment): 이 구성 요소는 Ethereum 가상 머신을 복제하여 Solidity와 같은 언어로 작성된 스마트 컨트랙트가 실행될 수 있는 공간을 제공합니다. 현재의 블록체인 상태를 가져와 사용자가 제공한 트랜잭션 배치를 처리하고, 업데이트된 새로운 상태를 계산합니다. EVM과의 호환성 덕분에 기존 dApp들을 원활하게 이식할 수 있습니다. [2]
- 증명 회로 (Proving Circuit): 이것은 zkEVM의 암호화 엔진입니다. 트랜잭션 실행을 관찰하고 일반적으로
zk-SNARK또는 zk-STARK인 영지식 증명을 생성합니다. 이 증명은 초기 상태에서 새로운 상태로의 상태 전환이 유효하며, 모든 연산이 EVM의 규칙에 따라 올바르게 수행되었음을 암호학적으로 증명합니다. 증명은 기본 트랜잭션 데이터 자체를 공개하지 않고 생성됩니다. [5] [2] - 검증자 컨트랙트 (Verifier Contract): 이것은 기반이 되는 레이어 1 블록체인(예: Ethereum)에 배포된 스마트 컨트랙트입니다. zkEVM 롤업은 생성된 유효성 증명과 업데이트된 상태 데이터를 이 컨트랙트에 제출합니다. 검증자 컨트랙트의 유일한 기능은 암호화 증명을 확인하는 것입니다. 증명이 유효하면 새로운 상태가 수락되고 레이어 1 체인에서 확정됩니다. 이 검증 프로세스는 매우 효율적이며 모든 레이어 1 노드가 트랜잭션을 재실행할 필요가 없도록 합니다. [2]
증명 과정
zkEVM 시스템에서 증명자(prover)는 블록을 "무상태(statelessly)"로 실행합니다. 즉, 전체 블록체인 상태의 전체 복사본을 유지할 필요가 없습니다. 대신, 처리되는 트랜잭션에 필요한 상태 데이터가 "위트니스(witness)"라고 불리는 입력값으로 공급됩니다. 이 입력값에는 부모 블록의 알려진 상태 루트에 대해 무결성을 검증하는 머클 증명(Merkle proofs)이 동반됩니다. [4]
확장성 측면에서 "zk"(영지식)라는 용어는 부분적으로 오해의 소지가 있을 수 있다는 점에 유의해야 합니다. 이 기술은 프라이버시를 위해 사용될 수 있지만, zkEVM은 주로 SNARK와 같은 영지식 증명 시스템의 "간결성(succinctness, 증명 크기가 작음)"과 "무결성(integrity, 증명이 계산적으로 견고함)" 특성을 활용합니다. 프라이버시를 보장하려면 추가적인 복잡성과 증명 비용이 발생하기 때문에, 트랜잭션 세부 정보를 반드시 숨기지 않고도 연산이 올바르게 실행되었음을 증명합니다. [6]
zkEVM의 유형
이더리움(Ethereum) 공동 창립자 비탈릭 부테린(Vitalik Buterin)은 zkEVM을 이더리움(Ethereum)과의 호환성 수준에 따라 여러 유형으로 분류하는 시스템을 제안했습니다. 이 시스템은 근본적인 절충 관계를 강조합니다. 호환성이 높을수록(낮은 번호의 유형) 기존 인프라를 사용하기 쉽지만 증명 속도가 느리고 비용이 많이 드는 반면, 호환성이 낮을수록(높은 번호의 유형) 이더리움(Ethereum) 표준에서 벗어나는 대신 더 빠른 증명 시간을 달성할 수 있습니다. [2]
유형 1 (완전한 이더리움 등가성)
유형 1 zkEVM은 이더리움(Ethereum)과 타협 없이 완전히 동일한 것을 목표로 합니다. 해시 함수(Keccak 등), 상태 트리 또는 기타 합의 로직을 포함하여 이더리움(Ethereum) 시스템을 전혀 변경하지 않습니다.
- 장점: 모든 이더리움(Ethereum) dApp 및 인프라와 완벽하게 호환됩니다. 블록 익스플로러 및 실행 클라이언트와 같은 도구를 수정 없이 재사용할 수 있습니다.
- 단점: 이더리움(Ethereum) 프로토콜의 특정 부분이 ZK 친화적이지 않기 때문에 증명 생성 속도가 매우 느립니다.
- 사례: 이는 레이어 1 통합을 위한 이더리움 재단(Ethereum Foundation)의 zkEVM 프로젝트가 내세우는 목표입니다. [2] [3]
유형 2 (완전한 EVM 등가성)
유형 2 zkEVM은 개발자 관점에서는 완전히 동일하지만, 증명 생성을 가속화하기 위해 다른 상태 트리 구조를 사용하는 등 기본 이더리움(Ethereum) 아키텍처를 미세하게 수정합니다.
- 장점: 대부분의 기존 애플리케이션과 호환되며, 유형 1보다 빠른 증명 시간을 제공합니다.
- 단점: 일부 사용 사례에서는 증명 시간이 여전히 병목 현상이 될 수 있습니다.
- 사례: 폴리곤(Polygon) zkEVM과 스크롤(Scroll)은 이 수준의 등가성을 목표로 하는 프로젝트입니다. [5] [2]
유형 2.5 (가스 비용을 제외한 EVM 등가성)
이는 유형 2의 변형으로, ZK 회로 내에서 증명하기 특히 어려운 특정 작업에 대한 가스 비용을 인상합니다. 이 수정을 통해 최악의 경우의 증명 시간을 개선할 수 있지만, 정확한 가스 비용 계산에 의존하는 개발자 도구 및 스마트 컨트랙트가 제대로 작동하지 않을 수 있습니다. [2]
유형 3 (거의 EVM 등가성)
유형 3 zkEVM은 개발을 더욱 단순화하고 증명 성능을 향상시키기 위해 완벽한 EVM 호환성을 희생합니다. 특정 프리컴파일드 컨트랙트(precompiled contracts)와 같이 ZK 회로에서 구현하기 특히 어려운 기능은 생략할 수 있습니다.
- 장점: 구축이 더 쉽고 유형 2보다 빠른 증명 생성을 제공합니다.
- 단점: 일부 애플리케이션은 배포를 위해 코드 수정이 필요할 수 있습니다. 현재 폴리곤(Polygon) zkEVM과 스크롤(Scroll)의 구현은 종종 이 유형에 더 가까운 것으로 간주됩니다. [2]
유형 4 (고급 언어 등가성)
유형 4 시스템은 EVM 바이트코드 수준에서의 직접적인 호환성을 목표로 하지 않습니다. 대신 솔리디티(Solidity)나 Vyper와 같은 고급 언어로 작성된 스마트 컨트랙트 소스 코드를 ZK 친화적인 언어나 명령어 세트로 직접 컴파일합니다.
- 장점: 증명 생성 시간을 대폭 단축할 수 있습니다.
- 단점: 바이트코드 수준의 불일치로 인해 디버깅 도구, 컨트랙트 주소 및 수동으로 작성된 EVM 바이트코드를 사용하는 애플리케이션에서 문제가 발생할 수 있습니다.
- 사례: zkSync Era는 유형 4 zkEVM의 대표적인 사례입니다. [5] [2]
장점 및 도전 과제
장점
- 보안 확장성: zkEVM은 속도를 위해 오프체인에서 트랜잭션을 실행하지만, 유효성 증명을 제출하여 레이어 1에서 정산합니다. 이를 통해 상위 체인의 보안성과 탈중앙화 특성을 상속받으면서도 더 높은 처리량으로 운영될 수 있으며, 잠재적으로 Ethereum의 초당 약 30건(TPS)인 트랜잭션 용량을 2,000 TPS 이상으로 늘릴 수 있습니다. [2] [1]
- 저렴한 비용: 수천 개의 트랜잭션을 일괄 처리하고 단일 온체인 증명 비용을 이들에 분산함으로써, zkEVM은 가스비를 실질적으로 낮출 수 있습니다. 트랜잭션당 비용을 거의 1달러에서 1센트 미만으로 줄일 수 있습니다. [7] [1]
- 빠른 최종성: zkEVM의 트랜잭션은 Layer 1의 검증자 컨트랙트가 유효성 증명을 수락하는 즉시 최종적인 것으로 간주됩니다. 이는 옵티미스틱 롤업(Optimistic Rollups)에서 요구되는 1~2주의 이의 제기 기간을 피할 수 있게 해주어, 특히 출금 시 자본 효율성과 사용자 경험을 개선합니다. [2]
- 개발자 경험: EVM 호환성 또는 동등성은 주요한 이점으로, 개발자가 기존 dApp을 마이그레이션하고 구축된 Ethereum 개발자 생태계와 도구를 거의 변경 없이 활용할 수 있게 해줍니다. 이는 거대한 네트워크 효과를 활용하고 개발자의 학습 곡선을 줄여줍니다. [7]
개발 도전 과제
- 증명 비용 및 복잡성: 영지식 증명 생성은 종종 특수하고 강력한 하드웨어를 요구하는 계산 집약적인 프로세스로, 이는 병목 현상이자 비용 발생 요인이 될 수 있습니다. [5]
- 아키텍처 불일치: EVM은 ZK 증명을 염두에 두고 설계되지 않았습니다. 스택 기반 아키텍처, 복잡한 옵코드(예:
CALL), Keccak과 같은 ZK 비친화적 해싱 함수의 사용은 실행 증명을 생성할 때 상당한 기술적 과제와 비용을 발생시킵니다. [2] - 호환성 대 성능의 절충: zkEVM 유형에서 상세히 다루었듯이, 완전한 Ethereum 호환성을 달성하는 것과 증명을 효율적으로 생성할 수 있는 시스템을 설계하는 것 사이에는 본질적인 긴장 관계가 존재합니다. [5]
- 탈중앙화 우려: 증명 생성을 위해 고가의 특수 하드웨어에 의존하는 것은 잠재적인 중앙화 우려를 낳습니다. 자원이 풍부한 소수의 엔티티만이 증명자(prover) 또는 시퀀서(sequencer)로 참여할 수 있기 때문입니다. [5]
보안 고려 사항
레이어 2 또는 레이어 1에서 zkEVM을 이더리움 생태계에 통합하는 것은 새로운 보안 고려 사항과 잠재적인 공격 벡터를 도입합니다. 이더리움 재단의 연구는 수많은 우려 영역을 식별했습니다. [6]
시스템 다양성
주요 우려 사항은 단일 장애점(single point of failure)의 위험입니다. 생태계가 증명을 위해 단 하나 또는 두 개의 실행 레이어(EL) 클라이언트에 의존하거나 단일 기본 zkVM 구현에 의존하게 된다면, 해당 지배적인 소프트웨어의 버그가 전체 네트워크를 중단시키거나 손상시킬 수 있습니다. 제안된 완화책은 "다중 증명 전략(multiproofs strategy)"으로, 여러 개의 다양한 zkEVM 시스템으로부터 증명을 받은 후에만 블록을 유효한 것으로 간주하는 방식입니다. [6]
게스트 프로그램 및 컴파일
EL 클라이언트를 "증명 가능"하게 만드는 과정에 상당한 위험이 존재합니다. EL 클라이언트는 캐시 및 시스템 호출과 같은 기능을 갖춘 복잡한 CPU를 위해 설계되었지만, zkVM의 제한된 환경에는 이러한 기능이 없습니다. 이러한 환경 간의 불일치는 고차원적인 우려 사항입니다. 또한, 클라이언트를 수정할 때 버그가 발생할 수 있으며, zkVM에서 사용되는 RV32IM과 같은 틈새 명령어 집합 구조(ISA)용 컴파일러는 주류 컴파일러보다 검증이 덜 되었습니다. Keccak 해싱과 같이 ZK에 친화적이지 않은 작업의 속도를 높이기 위해 사용되는 맞춤형 "zkVM 프리컴파일(precompiles)" 또한 복잡성을 더하고 자체적인 공격 표면을 생성합니다. [6]
증명자 및 회로의 정확성
zkEVM의 가장 중요한 구성 요소는 VM의 규칙을 정의하는 산술 회로와 기본 암호화 프로토콜입니다. 둘 중 하나라도 버그가 있으면 치명적일 수 있으며, 잠재적으로 악의적인 증명자가 유효하지 않은 상태 전환에 대해 유효해 보이는 증명을 생성하여 자금 도난으로 이어질 수 있습니다. 이러한 결함은 소스 연구 논문, 사양의 모호함 또는 구현 중 오류에서 비롯될 수 있습니다. 다른 구현 위험으로는 잘못된 "위트니스(witness)" 생성, 프로그램 형식 간의 트랜스파일링 버그 또는 프로토콜의 입증된 보안 보장을 벗어나는 안전하지 않은 "최적화" 등이 있습니다. [6]
완화 전략
이러한 위험을 해결하기 위해 생태계는 공식 검증(수학을 사용하여 코드의 정확성을 증명), 표준화된 테스트 스위트(이더리움 실행 사양 테스트 등)에 대한 광범위한 테스트, 독립적인 보안 감사, 화이트햇 해킹을 장려하기 위한 버그 바운티, 다중 증명 전략과 같은 아키텍처 설계를 포함한 여러 전략에 의존합니다. [6]
공식 검증 이니셔티브
보안을 강화하기 위해 이더리움 재단은 "버그 없는 zkEVM"을 만드는 것을 목표로 전체 zkEVM 스택에 공식 검증 방법을 적용하는 생태계 전반의 노력인 **zkEVM 공식 검증 프로젝트(zkEVM Formal Verification Project)**를 시작했습니다. 2026년 말까지 진행될 예정인 이 프로젝트는 zkEVM의 정확성과 보안을 보장하기 위한 도구, 표준 및 프로세스 개발을 목표로 합니다. [8]
이 이니셔티브는 세 가지 주요 집중 분야 또는 "트랙(Tracks)"으로 구성됩니다. [8]
- RISC-V zkVM 트랙: RISC-V 기반 zkVM의 다항식 제약 조건이 공식 RISC-V 명령어 의미론을 올바르게 구현하는지 검증하는 데 집중합니다.
- EVM 트랙: RISC-V 아키텍처에서 실행되는 EVM 구현이 공식 EVM 사양의 올바른 구현임을 증명하는 것을 목표로 합니다.
- 암호화 트랙: 기본 암호화 증명 시스템 및 프리미티브의 사양, 보안 증명 및 구현을 검증합니다.
이 프로젝트는 이러한 과제들을 해결하기 위해 다양한 팀에 자금을 지원하는 보조금 프로그램을 통해 운영됩니다. 지원되는 작업에는 Lean 증명 보조 도구 내의 형식화된 암호화 증명 라이브러리인 ArkLib 개발, Lean에서 회로를 작성하기 위한 도메인 특화 언어(DSL)인 cLean, 그리고 영지식 언어를 위한 통합 중간 표현인 LLZK가 포함됩니다. 이러한 노력은 차세대 Ethereum 확장 솔루션을 확보하기 위한 커뮤니티 중심의 개방적이고 방법론적으로 다양한 접근 방식을 강조합니다. [8]
역사 및 주요 프로젝트
dYdX 및 Loopring과 같은 초기 zk-Rollups은 확장을 위한 ZK 기술의 위력을 입증했지만, 일반적인 EVM 호환성이 부족했습니다. zkEVM의 개발은 ZK 증명과 EVM의 프로그래밍 가능성을 결합하려는 주요한 시도를 나타냅니다. [1]
초기 개발 및 메인넷 출시
2023년 3월에 첫 번째 공개 zkEVM 메인넷이 가동되었으며, 이는 이더리움(Ethereum) 확장에 있어 중요한 이정표가 되었습니다.
- zkSync Era: Matter Labs에서 개발한 zkSync Era는 2023년 3월 24일에 공개 메인넷을 출시했습니다. Type 4 zkEVM으로서, 더 빠른 증명 시간을 위해 Solidity 및 Vyper 코드를 ZK 친화적인 형식으로 컴파일합니다. [1] [5]
- Polygon zkEVM: Polygon은 2023년 3월 27일에 zkEVM 메인넷(Mainnet) 베타를 출시했습니다. 오픈 소스라는 점이 특징이며, 첫 번째 트랜잭션은 이더리움(Ethereum) 공동 창립자인 비탈릭 부테린(Vitalik Buterin)에 의해 전송되었습니다. 일반적으로 Type 2 또는 Type 3 zkEVM으로 분류됩니다. zkSync와 Polygon 팀 모두 출시 당시 이 기술이 초기 단계임을 인정했습니다. [1]
Polygon zkEVM의 진화
2024년 내내 Polygon zkEVM 메인넷(Mainnet) 베타는 "Etrog", "Elderberry", "Eggfruit" 업데이트를 포함하여 여러 업그레이드를 거쳤으며, 이를 통해 cdk-erigon 시퀀서와 같은 기능이 도입되었습니다. 그러나 전략적 전환의 일환으로, Polygon Labs는 2026년 1월에 Polygon zkEVM 메인넷(Mainnet) 베타를 중단할 계획이라고 발표했습니다. 이 프로젝트의 기술과 교훈은 개발자가 자신만의 ZK 기반 체인을 출시할 수 있게 해주는 Polygon 체인 개발 키트(CDK)와 같은 다른 생태계 제품에 통합되고 있습니다. [7]
기타 프로젝트
- Scroll: 이더리움 재단(Ethereum Foundation)의 개인정보 보호 및 확장성 탐구(PSE) 그룹과 협력하여 개발된 Type 2로 분류되는 zkEVM 프로젝트입니다. [5]
- Linea: 이더리움(Ethereum) 생태계의 선도적인 소프트웨어 기업 중 하나인 Consensys에서 개발한 zkEVM입니다. [1]
- Taiko: 이더리움(Ethereum) 확장을 위한 zkEVM 솔루션을 개발하는 또 다른 프로젝트입니다. [1]
이더리움 재단의 L1 이니셔티브
이더리움 재단(Ethereum Foundation)은 Type 1 zkEVM을 이더리움(Ethereum)의 기본 레이어에 직접 통합하는 연구를 진행하고 있습니다. 목표는 12초의 슬롯 시간 내에 전체 이더리움(Ethereum) 블록에 대한 ZK 증명을 생성하는 "실시간 증명(Real-Time Proving, RTP)"을 달성하는 것입니다. 이를 통해 사용자가 별도의 레이어 2로 마이그레이션할 필요 없이 전체 네트워크가 ZK 확장의 혜택을 누릴 수 있게 됩니다. 이 프로젝트의 지침 원칙은 "완전하고 타협 없는 EVM 등가성"입니다. [3]
"우리의 목표는 완전하고 타협 없는 EVM 등가성입니다." [3]
2026년 초 현재, 이 이니셔티브에는 OpenVM 및 RISC0와 같은 zkVM 구현에 대한 지속적인 벤치마킹과 Reth 및 Geth와 같은 이더리움(Ethereum) 클라이언트를 증명 기반 검증과의 잠재적 통합을 위해 준비하는 작업이 포함됩니다. [3]