Vitalik 블로그 포스트 해석: 이더리움 내장 ZK-EVM의 가능성을 탐구하다

2023.12.14

Vitalik 블로그 포스트 해석: 이더리움 내장 ZK-EVM의 가능성을 탐구하다

이더리움은 앞으로 ZK-EVM을 단순한 부가 기능으로만 보지 않을 수도 있다.

2023.12.14 - 05:42:02

ZK-EVM以太坊

Web3 심층 보도에 집중하고 흐름을 통찰

이더리움은 앞으로 ZK-EVM을 단순한 부가 기능으로만 보지 않을 수도 있다.

글: TechFlow

어제 Vitalik은 자신의 블로그에 <What might an “enshrined ZK-EVM” look like?>이라는 제목의 글을 게재하며, 이더리움이 ZK-EVM을 통합하는 것의 가능성, 방법 및 기대 효과 등을 체계적으로 설명했다.

EVM의 미래 발전은 종종 인프라와 관련된 다양한 서사나 방향성 변화와 연결되어 있으며, 우리는 이를 읽고 연구할 가치가 있다.

다만 해당 글에는 너무 많은 기술적 세부 사항이 포함되어 있어, 중국어 미디어와 커뮤니티에서 제공되는 대부분의 자료는 단순 번역에 그쳐, 글의 맥락과 핵심 관점을 파악하기 어렵다.

따라서 TechFlow는 해당 글을 심층 해석하여, 보다 쉬운 언어로 Vitalik의 사고 흐름과 견해를 재구성하고자 한다. 독자 여러분께 참고 자료를 제공하고자 함이다.

제목의 단어에서 드러난 의미: ZK-EVM을 '정통'으로 삼기

직역된 번역본만 본다면 영어 어휘가 지닌 뉘앙스나 자연스러운 표현을 이해하기 어렵다.

Vitalik의 이 글 제목에서는 자주 사용되지 않는 영어 단어인 "enshrined"가 등장한다.

GPT나 영어 사전을 간단히 조회하면 다음과 같은 정의를 확인할 수 있다:

"Enshrined"는 원래 '신성시하다', '봉안하다'라는 의미로, 어떤 사물이나 사람의 지위, 중요성 또는 가치를 매우 높은 수준으로 승격시키는 것을 묘사할 때 쓰이며, 마치 신성하거나 보호받는 위치에 두는 것처럼 말이다.

법률이나 종교 문서에서 "enshrine"은 특정 원칙, 권리 또는 신조를 공식적이고 존중하는 방식으로 기록하거나 유지하는 것을 의미한다.

기술 또는 소프트웨어 분야에서는 "enshrined"가 특정 기술, 기능 또는 원칙을 시스템, 프레임워크 또는 프로토콜에 공식적이고 중요하게 통합하는 것을 나타낸다. 이는 일반적으로 해당 기술이나 기능이 기초적이며 핵심적이거나 필수적이라고 여겨져 공식적이고 지속적으로 시스템에 포함됨을 의미한다.

따라서 우리는 이 글의 제목만으로도 Vitalik의 의도를 빠르게 파악할 수 있다:

제로지식 증명(ZK) 기반의 이더리움 가상 머신(EVM)을 이더리움 프로토콜의 핵심 또는 공식 구성 요소로 통합할 가능성을 탐색하는 것

즉, 향후 이더리움은 ZK-EVM을 단순 부가 기능으로 보기보다는 핵심 프로토콜의 일부로 다룰 수 있음을 시사한다.

ZK-EVM의 과거: L2 형태의 '외장형 모듈', 비원생 구조

이더리움 EVM과 관련 L2 솔루션에 익숙하지 않은 독자라면, Vitalik이 ZK-EVM을 메인넷의 공식 부분으로 논의한다는 점에서 다음 질문이 자연스럽게 떠오를 수 있다:

그동안 ZK-EVM과 이더리움은 어떤 관계였는가? 왜 지금까지 ZK-EVM이 이더리움의 '공식 구성 요소'가 아니었는가?

매우 간략하고 빠른 개요를 제공하자면:

이더리움 가상 머신(EVM): 이더리움 네트워크의 핵심으로, 스마트 계약 코드를 실행하는 역할을 한다. 이더리움에서 작동하는 모든 스마트 계약은 EVM을 통해 실행된다.
제로지식 증명(ZK): 한 당사자(증명자)가 다른 당사자(검증자)에게 어떤 진술이 참임을, 그 진술 외의 정보를 전혀 노출하지 않고 증명할 수 있도록 하는 암호화 기술이다. 이 기술은 암호화폐 및 블록체인 분야에서 거래의 프라이버시와 보안을 강화하는 데 활용된다.
ZK-EVM의 역할: EVM의 기능과 제로지식 증명의 프라이버시 보호 특성을 결합한 것이다. 거래 데이터를 비공개로 유지하면서도 그 유효성을 검증할 수 있게 하며, 즉 거래 내용을 공개하지 않더라도 해당 거래가 스마트 계약 및 블록체인 규칙에 부합함을 입증할 수 있다.
ZK-EVM과 이더리움 메인넷의 관계: ZK-EVM은 EVM과의 호환성을 유지하면서 제로지식 증명을 도입함으로써 거래의 프라이버시를 보호하고 확장성을 제공하는 솔루션이다. 초기에는 주로 2단계(Layer 2) 솔루션으로 등장하였으며, 이더리움 메인넷 위에 구축되어 추가적인 프라이버시 보호 및 확장성 기능을 제공하였다.

현재 대부분의 ZK-EVM은 L2 형태로 존재하며, 이더리움 L1 설계에 직접 내장되어 있지는 않다. 쉽게 말해 외장형 모듈이라 할 수 있다.

유명한 ZK-EVM 솔루션들은 모두 잘 알고 있듯이 Starknet, zkSync, Polygon Hermez, Scroll 등이 있다.

이러한 배경 지식을 바탕으로 하면, 이제 Vitalik의 블로그 내용을 이해하는 것이 훨씬 쉬워진다.

왜 이더리움에 원생 ZK-EVM을 내장해야 하는가?

위의 논리를 따라가다 보면 자연스럽게 이런 의문이 생길 수 있다: 현재 ZK-EVM의 L2 솔루션이 잘 작동하고 있는데, 왜 Vitalik은 ZK-EVM을 이더리움의 핵심 설계에 직접 통합하는지를 고민하는가?

Vitalik은 매우 간결하게 답변했다:

대규모 코드베이스 의존성: 현재의 Layer 2 솔루션들, 예를 들어 Optimistic Rollups와 ZK Rollups는 EVM 검증에 의존한다. 이는 방대한 코드베이스를 신뢰해야 함을 의미한다. 만약 코드베이스에 취약점이 존재한다면, 이러한 VM은 해킹 위험에 직면할 수 있다.
거버넌스 문제: L1 EVM과 완전히 동등한 ZK-EVM조차도, L1 EVM의 변경 사항을 자체 EVM 구현에 복제하기 위해某种 형태의 거버넌스 메커니즘이 필요하다. 이는 복잡성을 증가시키고 잠재적인 불일치 위험을 초래한다.
기능 중복: Layer 2 프로젝트는 이미 이더리움 프로토콜에 존재하는 기능을 복제한다. 이더리움 거버넌스는 이미 업그레이드와 버그 수정을 책임지고 있다. ZK-EVM이 본질적으로 수행하는 작업은 L1 이더리움 블록을 검증하는 것과 동일하다.
미래의 라이트 클라이언트 발전: 라이트 클라이언트가 점점 더 강력해지면서 곧 ZK-SNARKs를 사용해 L1 EVM 실행을 완전히 검증할 수 있게 될 것이다. 이 경우 이더리움 네트워크는 사실상 내장된 ZK-EVM을 갖게 되는 셈이다. 그렇다면 rollup에도 이러한 원생 ZK-EVM을 제공하지 않을 이유가 무엇인가?

이러한 문제들을 통해 Vitalik은 ZK-EVM을 이더리움 핵심 설계에 통합하려는 동기를 명확히 했다 — 외부 코드베이스 의존성의 위험을 해결하고, 거버넌스를 단순화하며, 기능 중복을 줄이고, 이더리움 네트워크 자체가 갖춘 능력을 활용하기 위해서이다.

내장형 ZK-EVM은 어떤 모습이어야 하나?

그렇다면 이더리움이 ZK-EVM을 내장하려면 어떤 기능과 특성을 가져야 할까? Vitalik은 여기에 대해 더 깊이 있는 아이디어를 제시했다:

기본 기능: ZK-EVM의 핵심 기능은 이더리움 블록을 검증하는 것이다. 즉, 전 상태 루트(pre-state root), 블록, 후 상태 루트(post-state root)를 입력으로 받아, 후 상태 루트가 실제로 해당 블록 실행 결과임을 검증할 수 있어야 한다.
다중 클라이언트 철학과의 호환성: ZK-EVM은 단일 증명 시스템에 국한되지 말고, 다양한 클라이언트가 서로 다른 증명 시스템을 사용할 수 있도록 해야 한다. 이는 데이터 가용성 요구사항과 함께, 증명이 EVM 및 블록 데이터 구조로부터 독립적으로 존재해야 한다는 점을 고려해야 함을 의미한다.
감사 가능성: 어떤 실행이 증명되었다면, 문제가 발생했을 때 사용자와 개발자가 이를 검토할 수 있도록 기본 데이터가 이용 가능해야 한다.
업그레이드 가능성: 특정 ZK-EVM 방식에 취약점이 발견되었을 경우, 하드포크 없이도 신속하게 수정할 수 있어야 한다.
거의 동일한 EVM(almost-EVMs) 지원: ZK-EVM은 실행 수준의 혁신과 EVM 확장을 지원해야 한다. 특정 L2의 VM이 EVM과 약간 다르더라도, 원생 프로토콜 내 ZK-EVM을 사용해 EVM과 동일한 부분을 처리하고, 차이 나는 부분은 자체 코드에 의존하도록 해야 한다.

여기서 almost-EVMs라는 개념이 낯선 독자도 있을 것이다. 실제로 Vitalik은 이전에도 유사한 견해를 밝힌 바 있는데, 일부 ZK-EVM 솔루션이 실행 시 EVM과 완전히 일치할 필요 없이, '거의 유사한' 형태를 가져도 된다고 주장한다.

Vitalik이 제안한 ZK-EVM 프레임워크에서 almost-EVMs를 지원한다는 것은, ZK-EVM이 다양한 요구와 시나리오에 더 유연하게 대응할 수 있음을 의미한다. 이는 ZK-EVM이 표준 EVM 사양을 따르는 애플리케이션뿐 아니라, 약간의 조정을 필요로 하거나 원하는 시스템도 지원할 수 있음을 보여준다.

내장형 ZK-EVM, 다양한 이더리움 클라이언트에서 어떻게 동작하는가?

논리를 따라가다 보면 Vitalik의 원문에서 갑자기 클라이언트 이야기가 나오는 데 혼란스러울 수 있다.

앞서 살펴본 논리를 되짚어보면, Vitalik의 논리 전개는 매우 명확하다:

"나는 ZK-EVM을 이더리움 내장 컴포넌트로 만들고 싶다 → 왜 그렇게 해야 하는가? → 어떤 기능을 갖춰야 하는가?"

따라서 다음 논의 포인트는 자연스럽게 "그렇게 하면, 실제 구현 시 다양한 클라이언트에서 어떻게 동작하는가?"로 이어진다.

Vitalik은 두 가지 방향을 제시했다: 오픈형 다중 클라이언트 시스템에서 실행하거나, 클로즈드형 다중 클라이언트 시스템에서 실행하는 것이다.

오픈형 시스템: 이더리움의 탈중앙화 및 혁신 정신에 더 부합하며, 커뮤니티가 필요에 따라 새로운 증명 기술을 개발하고 채택할 수 있게 한다.
클로즈드 시스템: 관리 및 유지보수가 더 쉬울 수 있으나, 장기적인 적응성과 혁신 가능성을 제한할 수 있다.

또한 이후 문단에서 Vitalik은 ZK-EVM 구현 시 증명 생성 속도의 중요성도 언급했다. ZK-EVM이 빠르게 증명을 생성할 수 있다면, 네트워크 성능 요구와 사용자 경험 기대를 더 잘 충족할 수 있어 메인 프로토콜에 통합되기 더욱 적합하다고 본다.

그러나 이를 실현하려면 상당한 기술적·공학적 도전을 극복해야 한다. Vitalik은 이 부분에서 이러한 도전들을 명확히 하고, 가능한 해결책과 접근 방식을 제시했다.

ZK-EVM을 이더리움에 어떻게 구현할 수 있는가?

Vitalik은 ZK-EVM의 가능한 구현 방식도 제시했다.

그는 새로운 거래 유형인 'ZK-EVM 선언 거래(ZKEVMClaimTransaction)'를 제안하며, 이더리움 네트워크에서 이러한 거래를 처리하고 검증하는 방법을 설명했다.

이 부분은 기술적으로 매우 복잡하므로, 기초가 없는 독자는 기술적 디테일을 건너뛰는 것을 권장한다. 핵심 설계 아이디어와 개요만 살펴보자:

ZK-EVM 관련 선언을 네트워크에서 전달하기 위한 컨테이너 유형 도입.
합의 계층에서 새 규칙 도입: 클라이언트가 각 선언에 대한 유효한 증명을 확인한 후에만 블록을 수락.
사용자는 ZK-EVM 증명에서 실행 클라이언트를 교체할 수 있으나, 실행 클라이언트는 여전히 증명 생성, 블록 구축, 노드 저장 및 데이터 색인을 위해 사용됨.
다양한 ZK-EVM 구현이 서로 다른 증명 방법을 채택할 수 있지만, 모두 서로의 증명을 검증하고 수용할 수 있음.

또한 Vitalik은 “almost-EVMs” (거의 EVM과 동일한 시스템) 지원에 대해서도 논의했는데, 이는 ZK-EVM 기능의 기대 목표 중 하나다.

이러한 시스템은 새로운 사전컴파일된 컨트랙트, 오퍼코드, 컨트랙트 작성 옵션(예: 표준 EVM 또는 아비트럼 Stylus처럼 완전히 다른 VM에서 작성 선택 가능), 또는 동기화된 크로스 커뮤니케이션을 지원하는 병렬 EVM 여러 개와 같은 추가 기능을 내장할 수 있다.

또한 Vitalik Buterin은 ZK-EVM 내에서 상태를 갖는(stateful) 검증자를 지원하는 방법과 그 이점에 대해서도 논의했다:

왜 상태 검증자를 지원해야 하는가?

데이터 효율성: 상태 검증자는 데이터 압축 효율을 높일 수 있다. 완전 무상태 시스템은 매번 거래 시 모든 데이터가 필요하므로 데이터 중복과 낭비가 발생할 수 있다. 반면 상태 검증자는 이전 상태 정보를 저장함으로써 전송 및 처리해야 할 데이터량을 줄일 수 있다.
데이터 중복 감소: 어떤 데이터 조각이 이전 블록 또는 거래에서 이미 제공되었다면, 이후 증명에서 다시 제공할 필요가 없다. 이미 '알려진' 정보이기 때문이다.
시스템 성능: 상태 정보를 갖춘 시스템은 알려진 정보를 활용할 수 있으므로, 매번 처음부터 시작하지 않고도 더 효율적인 계산과 검증이 가능하다.

어떻게 지원하는가는 원문에서 너무 많은 기술적 세부사항을 포함하고 있어 깊이 있는 해설이 어렵다. 다만 핵심은 다음과 같다:

"상태 검증자 지원"은 ZK-EVM에 시스템이 이전 상태를 기억하고 활용할 수 있는 메커니즘을 도입하는 것을 의미하며, 매번 작업 시 완전 무상태로 시작하지 않고도 시스템 전반의 성능을 높이고, 필요한 데이터 전송을 줄이며, 더 효율적인 계산을 가능하게 한다. 이것은 ZK-EVM 설계의 확장이며, 현실 세계 적용에서의 실현 가능성과 효율성을 높이기 위한 목적을 가지고 있다.

ZK-EVM이 내장되면, 기존 ZK 기반 L2는 어떻게 되는가?

글의 마지막 부분에서 Vitalik은 엄격한 기술 논의를 잠시 접어두고, 또 다른 질문을 던진다. 만약 ZK-EVM이 이더리움 L1에 내장된다면, 기존의 ZK 기반 L2 프로젝트들의 역할은 어떻게 변화할 것인가?

Vitalik의 구상에 따르면, 실제로 그렇게 된다면 L2는 앞으로 더 보조적인 역할을 맡게 되며, 다음과 같은 몇 가지 측면에서 보완 기능을 수행할 가능성이 높다:

빠른 사전 승인: 싱글 슬롯 최종성(single-slot finality)은 Layer 1의 처리 속도를 느리게 할 수 있다. 반면 Layer 2 프로젝트는 Layer 2 자체의 보안 메커니즘을 기반으로 훨씬 짧은 지연 시간으로 빠른 사전 승인 서비스를 제공할 수 있다. 이러한 서비스는 계속해서 Layer 2만의 고유한 책임이 될 것이다.
최소 추출 가능 가치(MEV) 완화 전략: 암호화된 메모리풀, 평판 기반 정렬기 선택, 그리고 Layer 1이 도입하기 꺼리는 기타 기능들이 포함될 수 있다. Layer 2는 이러한 전략을 시행하여 MEV가 사용자 거래에 미치는 영향을 줄일 수 있다.
EVM 확장: Layer 2 프로젝트는 EVM에 중대한 확장을 도입하여 사용자에게 큰 가치를 제공할 수 있다. 여기에는 "거의 EVM"(almost-EVMs) 버전 지원 또는 WASM 기반 아비트럼 Stylus, SNARK 친화적인 Cairo 언어와 같이 완전히 다른 접근 방식이 포함될 수 있다.
사용자 및 개발자 편의성: Layer 2 팀은 사용자와 프로젝트를 생태계로 유치하고 환영받는 느낌을 주는 데 많은 노력을 기울인다. 이들은 네트워크 내에서 발생하는 MEV와 혼잡 요금을 통해 보상을 받는다. ZK-EVM이 이더리움 프로토콜에 통합되더라도 이러한 모델은 계속 유지될 것이다.