비탈릭: ZK-EVM이 이더리움 L1에 캡슐화되면 어떻게 되나요?

원문 게시처: https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
번역자: Dengchain Community^{[1 )} 번역팀

옵티미스틱 롤업과 ZK 롤업을 포함하여 이더리움 위에 구축된 레이어2 EVM 프로토콜은 EVM 검증에 의존합니다. 그러나 이를 위해서는 대규모 코드베이스를 신뢰해야 하며, 코드베이스에 취약점이 있는 경우 이러한 가상 머신은 해킹의 위험에 노출됩니다. 또한, L1 EVM과 완전히 동등하도록 설계된 ZK-EVM조차도 L1 EVM의 변경 사항을 자체 EVM 구현에 복제하기 위해 어떤 형태의 거버넌스 메커니즘이 필요합니다.

이러한 프로젝트는 이더넷 프로토콜에 이미 존재하는 기능을 복제하는 것이고, 이더넷 거버넌스는 이미 업그레이드와 버그 수정을 담당하고 있기 때문에 이러한 상황은 이상적이지 않습니다: ZK-EVM은 기본적으로 L1 이더넷 블록을 검증하는 작업을 수행하고 있습니다! 또한, 향후 몇 년 동안 라이트 클라이언트 ^[2]가 점점 더 강력해질 것으로 예상되며, 곧 ZK-SNARK를 사용하여 L1 EVM 실행을 완전하게 검증할 수 있을 것으로 기대합니다. 그 시점이 되면 이더넷 네트워크는 사실상 ZK-EVM이 내장된 네트워크가 될 것입니다. 따라서 롤업에 ZK-EVM을 기본적으로 사용할 수 없는 이유는 무엇일까요?

이 글에서는 구현할 수 있는 캡슐화된 ZK-EVM의 몇 가지 변형을 설명하고, 장단점 및 설계 과제와 특정 방향을 택하지 않는 이유에 대해 자세히 설명할 것입니다. 프로토콜 기능을 구현할 때의 장점과 에코시스템을 떠나 기본 프로토콜을 단순하게 유지할 때의 이점을 비교 검토해야 합니다.

ZK-EVM 패키징을 통해 얻고자 하는 주요 기능은 무엇인가요?

기본 기능: 이더넷 블록 확인. 프로토콜 기능(연산자인지, 사전 컴파일인지, 아니면 다른 메커니즘인지는 결정되지 않음)은 (최소한) 사전 상태 루트, 블록, 사후 상태 루트를 입력으로 받아들이고 사후 상태 루트가 실제로 사전 상태 루트에서 블록을 실행한 결과인지 확인해야 합니다.

이더넷의 다중 클라이언트 철학과의 호환성은 단일 증명 시스템을 사용하는 것을 피하고 대신 클라이언트마다 다른 증명 시스템을 사용할 수 있도록 허용한다는 것을 의미합니다. 이는 몇 가지를 의미합니다.

• 데이터 가용성 요건: 캡슐화된 ZK-EVM을 통해 수행되는 모든 EVM 실행의 경우. 모든 EVM 실행에 대해, 다른 증명 시스템을 사용하는 증명자가 실행을 재증명하고 해당 증명 시스템에 의존하는 클라이언트가 새로 생성된 증명을 검증할 수 있도록 기본 데이터 가용성^[4]을 보장하고자 합니다.

• 증명이 EVM과 블록 데이터 구조 외부에 저장됨: ZK-EVM 기능은 클라이언트마다 다른 유형의 SNARK를 기대하기 때문에 SNARK를 EVM에 직접 입력으로 받지 않고 대신 다른 유형의 SNARK를 가져올 수 있습니다. 대신 블롭 검증과 유사하게 트랜잭션에 증명이 필요한 문(사전 상태, 블록 본문, 사후 상태)이 포함될 수 있고, 연산자나 사전 컴파일이 이러한 문 내용에 접근할 수 있으며, 클라이언트 합의 규칙이 이러한 각 문에 대해 데이터 가용성과 블록 내 증명의 존재 여부를 각각 확인할 수 있습니다.

감사 가능성: 실행이 증명된 경우, 사용자와 개발자가 확인할 수 있도록 기초 데이터를 사용할 수 있어야 합니다. 사실상 데이터 가용성 요건이 중요한 또 하나의 이유가 추가된 셈입니다.

확장성: 특정 ZK-EVM 시나리오에서 취약점이 발견되면 하드 포크 없이도 빠르게 수정할 수 있기를 원합니다. 이는 결국 EVM 및 블록 데이터 구조 외부에 저장되는 증명의 중요성을 증가시킵니다.

거의 모든 EVM에 대한 지원: L2의 매력 중 하나는 실행 수준에서 혁신하고 EVM을 확장할 수 있다는 점입니다. 특정 L2의 VM이 EVM과 약간만 다른 경우, L2에서 EVM과 동일한 부분은 여전히 네이티브 프로토콜 내 ZK-EVM을 사용하고 EVM과 다른 부분에 대해서만 자체 코드에 의존할 수 있으면 좋습니다. 이는 호출자가 비트필드, 연산자 코드 또는 주소 목록을 EVM 자체가 아닌 외부에서 제공된 테이블에서 처리하도록 지정할 수 있는 방식으로 ZK-EVM 기능을 설계함으로써 가능합니다. 또한 가스 비용을 제한적으로 사용자 정의할 수 있습니다.

개방형과 폐쇄형 멀티 클라이언트 시스템

멀티 클라이언트 아이디어는 아마도 위 목록에서 가장 확실한 요구 사항일 것입니다. >. 이를 포기하고 ZK-SNARK 체계에 집중하는 옵션이 있는데, 이는 설계를 단순화할 수 있지만 이더리움에 대한 더 큰 아이디어 전환이 될 수 있고(사실상 이더리움의 오랜 멀티 클라이언트 철학을 포기하는 것이기 때문에) 더 큰 위험을 초래할 수 있습니다. 공식적인 검증 기술이 더 정교해지는 등 장기적인 미래에는 이 길을 택하는 것이 더 나을 수도 있지만, 현재로서는 리스크가 너무 커 보입니다.

또 다른 옵션은 프로토콜에 고정된 증명 시스템 세트가 알려진 폐쇄형 멀티클라이언트 시스템입니다. 예를 들어, PSE ZK-EVM^[5], Polygon ZK-EVM^[6], Kakarot^[7]의 세 가지 ZK-EVM을 사용하기로 결정할 수 있습니다. 블록이 유효한 것으로 간주되려면 이 세 가지 중 두 가지의 증명이 필요합니다. 이는 단일 증명 시스템보다는 낫지만, 사용자가 각 증명 시스템에 대한 검증자를 유지해야 하기 때문에 시스템의 적응성이 떨어지며, 새로운 증명 시스템을 통합하는 정치적 거버넌스 프로세스에 영향을 미칠 수밖에 없습니다.

이 때문에 저는 블록 외부에 증명을 배치하고 클라이언트가 개별적으로 검증하는 개방형 멀티클라이언트 시스템을 선호합니다. 개별 사용자는 해당 증명 시스템에 대한 증명을 생성하는 증명자가 있는 한, 블록을 검증하기 위해 원하는 만큼의 클라이언트를 사용할 수 있습니다. 증명 시스템은 프로토콜 거버넌스 프로세스를 설득하는 것이 아니라 사용자를 설득하여 실행하도록 함으로써 영향력을 얻습니다. 그러나 이러한 접근 방식은 복잡성 비용이 훨씬 더 높습니다.

ZK-EVM 구현에서 원하는 핵심 기능은 무엇인가요?

올바른 기능과 보안을 기본적으로 보장하는 것 외에도 가장 중요한 기능은 속도입니다. 각 문장에 대한 답을 N개의 슬롯이 지나야 반환하는 비동기식 프로토콜 내 ZK-EVM 함수를 설계할 수도 있지만, 각 블록 클럭에서 발생하는 모든 일이 독립적으로 이루어지도록 몇 초 안에 증명을 생성할 수 있다는 것을 안정적으로 보장할 수 있다면 문제는 훨씬 쉬워집니다.

현재 이더리움 블록에 대한 증명을 생성하는 데 몇 분 또는 몇 시간이 걸리지만, 이론적으로 대규모 병렬화를 막아야 할 이유는 없습니다. 블록 실행의 여러 부분을 개별적으로 증명할 수 있는 충분한 GPU를 조립한 다음 재귀적 SNARK를 사용하여 증명을 병합할 수 있습니다. 또한 FPGA와 ASIC을 통한 하드웨어 가속화는 증명을 최적화하는 데 도움이 될 수 있습니다. 그러나 이를 달성하는 것은 과소평가해서는 안 되는 중요한 엔지니어링 과제입니다.

프로토콜 내 ZK-EVM 기능은 정확히 어떻게 작동하나요?

EIP-4844 블롭 트랜잭션^[8]과 유사하게, ZK-EVM 선언을 포함하는 새로운 트랜잭션 유형을 소개합니다:

EIP-4844와 유사하게 메모리 풀에서 전파되는 객체는 트랜잭션의 수정된 버전이 됩니다.

후자는 전자로 변환할 수 있지만 그 반대의 경우는 불가능합니다. 또한 블록에서 이루어진 선언의 증명 목록을 포함하도록 블록 사이드 카 객체(EIP-4844^[9]에 도입됨)를 확장했습니다.

실제에서는 아마도 사이드카를 블롭용과 증명용 두 개의 사이드카로 나누고, 각 증명 유형에 대해 별도의 서브넷(블롭용 서브넷과 다른 서브넷)을 사용하고자 할 것입니다.

합의 레이어에는 검증 규칙을 추가합니다. 클라이언트가 블록의 각 문장에 대해 유효한 증명을 확인한 경우에만 블록을 수락할 수 있습니다. 이 증명은 <코드>transaction_and_witness_blobs의 연결이 (블록, 위트니스) 쌍의 직렬화이며, <코드>pre_state_root에서 위트니스(i)의 사용이 실행이 유효하고, (ii) 올바른 post_state_root가 출력되는지 확인합니다. 잠재적으로 클라이언트는 M-of-N의 여러 유형의 증명을 기다리도록 선택할 수 있습니다.

여기서 언급할 철학적 포인트는 블록 실행 자체가 단순히 <코드>와 동일한 유형의 증명을 필요로 하는 것으로 볼 수 있다는 것입니다. (σ_pre,σ_post,Proof) 트리플 중 하나로, ZKEVMClaimTransaction 객체에서 제공되는 트리플과 함께 확인해야 합니다. 따라서 사용자의 ZK-EVM 구현은 실행 클라이언트를 대체할 수 있으며, 실행 클라이언트는 여전히 (i) 증명자와 블록 빌더, (ii) 로컬에서 인덱스를 사용하고 데이터를 저장하는 데 관심이 있는 노드에서 사용됩니다.

검증 및 재증명

두 개의 이더리움 클라이언트가 있고, 그 중 하나는 PSE ZK-EVM을 사용하고 다른 하나는 Polygon ZK. -EVM을 사용하고 있다고 가정합니다. 두 구현 모두 이더리움 블록 실행을 5초 이내에 증명할 수 있을 정도로 발전했고, 각 증명 시스템에 대해 하드웨어를 실행하여 증명을 생성하는 독립적인 자원자가 충분하다고 가정해 보겠습니다.

아쉽게도 개별 증명 시스템은 프로토콜에 포함되지 않아 인센티브를 받지 못하지만, 연구 개발에 비해 증명 시스템을 운영하는 데 드는 비용이 낮을 것으로 예상되며, 공공재원 조달에 사용되는 것과 동일한 범용 기관을 통해 간단히 증명자에게 자금을 지원할 수 있을 것으로 기대합니다 . provers.

누군가가 ZKEvmClaimNetworkTransaction을 발행하지만, PSE ZK-EVM의 증명 버전만 발행한다고 가정해 보겠습니다. 폴리곤 ZK-EVM의 증명 노드는 이를 보고, 계산하여 폴리곤 ZK-EVM 증명으로 다시 릴리스합니다.

이렇게 하면 블록을 수락하는 가장 빠른 정직한 노드인 노드 수와 가장 늦은 정직한 노드인 노드 수가 증가합니다. 동일한 블록을 마지막으로 수락하는 가장 늦게 정직한 노드 사이의 총 최대 지연 시간을 δ에서 2δ+T_prove로 증가시킵니다(여기서는 T_prove < 5초로 가정).

그러나 좋은 소식은 단일 슬롯 최종 결정론을 사용할 경우, SSF에 내재된 여러 라운드의 합의 지연 시간과 함께 이 추가 지연 시간을 거의 확실하게 '파이프라인화'할 수 있다는 것입니다. 예를 들어, 이 4슬롯 제안 ^[10]에서 "헤더 투표" 단계에서는 기초 블록의 유효성만 확인하면 되지만 "동결 및 확인" 단계에서는 증명의 존재가 필요합니다.

확장: 거의 EVM에 대한 지원

ZK-EVM 기능의 바람직한 목표 중 하나는 몇 가지 추가 기능이 있는 EVM인 거의 EVM을 지원하는 것입니다. EVM. 여기에는 새로운 프리컴파일러, 새로운 옵코드, EVM 또는 완전히 다른 VM에서 컨트랙트를 작성하는 옵션(Arbitrum Stylus^[11]에서처럼), 심지어 동기식 교차 통신이 가능한 여러 병렬 EVM이 포함될 수 있습니다.

일부 수정은 간단한 방식으로 지원될 수 있습니다. 일부 수정은 간단한 방법으로 지원될 수 있습니다. ZKEVMClaimTransaction이 수정된 EVM 규칙에 대한 전체 설명을 전달할 수 있는 언어를 정의할 수 있습니다. 이는 다음과 같은 경우에 적용될 수 있습니다.

가스 비용 테이블 사용자 지정(사용자는 가스 요금을 낮출 수는 없지만 높일 수는 있음)

특정 옵코드 비활성화

블록 번호 설정(하드포크에 따라 다른 규칙을 의미함)

L1이 아닌 L2 전용의 전체 EVM 변경 또는 기타 간단한 변경을 활성화하는 플래그 설정

사용자가 새로운 사전 컴파일러(또는 옵코드)를 도입하여 새로운 기능을 보다 개방적으로 도입할 수 있도록 하기 위해, ZKEVMClaimNetworkTransaction에 블롭의 일부로 포함된 사전 컴파일된 입력/출력 스크립트를 다음과 같이 추가할 수 있습니다.

EVM 실행이 수정됩니다. <코드>입력 배열이 비어 있는 상태로 초기화됩니다. used_precompile_addresses에 있는 주소에 대한 첫 번째 호출에서 inputs에 InputsRecord(callee_address, gas, input_calldata)를 추가하고 호출을 inputsRecord(callee_address, gas, input_calldata)로 설정합니다. 코드>로 변경하고 호출의 <코드>RETURNDATA를 <코드>outputs[i]로 설정합니다. 마지막으로, 사용된_프리컴파일_주소가 총 len(출력) 횟수만큼 호출되었는지, 그리고 inputs_commitments가 input의 SSZ 직렬화와 동일한지 확인합니다. 코드>의 SSZ 직렬화는 결과와 일치하는 블롭 커밋을 생성합니다. inputs_commitments를 노출하는 목적은 외부 SNARK가 입력과 출력 간의 관계를 쉽게 증명할 수 있도록 하기 위해서입니다.

입력(해시로 저장)과 출력(바이트로 저장) 사이의 비대칭성에 주목하세요. 이는 입력만 보고 EVM을 이해하는 클라이언트가 실행할 수 있어야 하기 때문입니다. 클라이언트는 EVM 실행이 이미 입력을 생성했기 때문에 생성된 입력이 청구된 입력과 일치하는지 확인하기만 하면 되고, 해시 확인만 하면 됩니다. 그러나 출력은 전체가 제공되어야 하므로 데이터를 사용할 수 있어야 합니다.

또 다른 유용한 기능은 모든 발신자 계정에서 호출할 수 있는 "권한 있는 트랜잭션"을 허용하는 것일 수 있습니다. 이러한 트랜잭션은 두 개의 다른 트랜잭션 사이에서 실행되거나 다른 (권한이 있는) 트랜잭션에서 사전 컴파일러가 호출될 때 실행될 수 있습니다. 이는 비 EVM 메커니즘이 EVM으로 다시 호출하는 데 사용할 수 있습니다.

이 디자인은 새롭거나 수정된 프리컴파일러 외에도 새롭거나 수정된 옵코드를 지원하도록 수정할 수 있습니다. 이 디자인은 프리컴파일러만 사용해도 매우 강력합니다. 예를 들어, used_precompile_addresses에 특정 플래그가 있는 일반 계정 주소 목록을 포함하도록 설정하고 올바르게 구성되었다는 SNARK 증명을 생성하면 다음과 같은 것을 지원할 수 있습니다. 아비트럼 스타일러스^[12] 스타일 기능으로 컨트랙트가 EVM이나 WASM(또는 다른 가상머신)에서 코드를 작성할 수 있습니다. 권한 있는 트랜잭션을 사용하여 WASM 계정이 EVM으로 다시 호출할 수 있습니다.

여러 EVM에서 실행한 입출력 기록과 권한 있는 트랜잭션이 올바른 방식으로 일치하는지 확인하는 외부 검사를 추가하면 동기 채널을 통해 통신하는 여러 EVM의 병렬 시스템을 시연할 수 있습니다.

유형 4의 ZK-EVM^[13]은 솔리디티 또는 기타 상위 레벨 언어를 SNARK 친화적인 VM 구현으로 직접 변환하는 구현과 이를 EVM 코드로 컴파일하여 빌트인된 ZK-EVM. 두 번째(필연적으로 느릴 수밖에 없는) 구현은 결함이 있는 증명자가 취약점을 주장하는 트랜잭션을 전송하는 경우에만 실행할 수 있으며, 두 곳에서 다르게 처리되는 트랜잭션을 제공하는 경우 포상금을 받습니다.

모든 호출을 0으로 반환하고 블록 끝에 추가된 권한 있는 트랜잭션에 호출을 매핑하여 순수 비동기식 가상 머신을 구현할 수 있습니다.

확장: 스테이트풀 증명자에 대한 지원