V God의 새 기사: 이더리움에 ZK가 내장된 후 Layer 2는 어디로 갈까요?

Loopy Lu

读者

2023-12-14 07:07

이 기사는 약 5230자로, 전체를 읽는 데 약 8분이 소요됩니다

이더리움의 미래, 데이터 가용성, 레이어 2의 역할 변화.

AI 요약

펼치기

이더리움의 미래, 데이터 가용성, 레이어 2의 역할 변화.

제작사 - 오데일리

편집 - 루피 루

오늘 Vitalik Buterin은 Ethereum 커뮤니티에 내장된 ZK-EVM은 어떤 모습일까요?라는 제목의 기사를 게시했습니다. 》새 기사. 이 기사에서는 이더리움이 향후 네트워크 업그레이드에 자체 ZK-EVM을 내장하는 방법을 살펴봅니다.

우리 모두 알고 있듯이 이더리움의 느린 개발 상황에서 현재 거의 모든 주류 레이어 2에는 ZK-EVM이 있습니다. 이더리움 메인넷이 자체 ZK-EVM을 캡슐화하면 메인넷과 레이어 2가 역할 위치를 갖게 될까요? 갈등은 어떻습니까? ? 레이어 1과 레이어 2는 어떻게 효과적으로 분할하고 협력할 수 있나요?

이 기사에서 Vitalik Buterin은 호환성, 데이터 가용성 및 감사 가능성의 중요성을 강조하고 효율적이고 상태 저장 증명을 구현할 수 있는 가능성을 탐구합니다. 또한 이 기사에서는 효율성 향상을 위한 상태 저장 증명 구현 가능성을 살펴보고 빠른 사전 확인 및 MEV 완화 전략을 제공하는 레이어 2 프로젝트의 역할에 대해 논의합니다. 이 기사에서는 ZK-EVM을 통해 개발을 진행하면서 이더리움 네트워크의 유연성을 유지하는 균형에 대해 설명합니다.

Odaily는 원본 텍스트를 다음과 같이 편집했습니다.

Ethereum 위에 있는 Layer-2 EVM 프로토콜로서 낙관적 롤업과 ZK 롤업은 모두 EVM 검증에 의존합니다. 그러나 이를 위해서는 대규모 코드 기반을 신뢰해야 하며, 이 코드 기반에 버그가 있는 경우 이러한 가상 머신은 해킹될 위험이 있습니다. 이는 또한 ZK-EVM이 L1 EVM과 완전히 동등한 상태를 유지하기를 원하더라도 L1 EVM 변경 사항을 자체 EVM 구현에 복사하기 위한 일종의 거버넌스가 필요하다는 것을 의미합니다.

이것은 이상적인 상황이 아닙니다. 이러한 프로젝트는 이미 이더리움 프로토콜에 존재하는 기능을 자체적으로 복사하고 있기 때문에 이더리움 거버넌스는 이미 업그레이드 및 버그 수정을 담당하고 있으며 ZK-EVM은 기본적으로 레이어 1 이더리움 블록을 검증하는 작업을 수행합니다. 향후 몇 년 동안 우리는 라이트 클라이언트가 점점 더 강력해지고 곧 ZK-SNARK를 사용하여 L1 EVM 실행을 완전히 인증할 수 있을 것으로 기대합니다. 그 시점에서 이더리움 네트워크는 실제로 캡슐화된 ZK-EVM을 갖게 됩니다. 따라서 질문이 생깁니다. 이 ZK-EVM을 기본적으로 롤업에도 사용할 수 있게 만드는 것은 어떨까요?

이 기사에서는 패키지 내 ZK-EVM의 여러 버전을 설명하고 각 버전의 장단점, 설계 과제 및 특정 방향으로 진행하지 않는 이유를 분석합니다. 프로토콜 기능 구현의 이점은 생태계에서 트랜잭션을 처리하고 기본 프로토콜을 단순하게 유지하는 이점과 비교되어야 합니다.

패키지된 ZK-EVM에서 얻고자 하는 주요 기능은 무엇입니까?

기본 기능: Ethereum 블록을 확인합니다. 프로토콜 기능(opcode, 사전 컴파일 또는 기타 메커니즘인지 여부는 아직 결정되지 않음)은 최소한 사전 상태 루트, 블록 및 사후 상태 루트를 입력으로 받아들일 수 있어야 하며 사후 상태가 다음과 같은지 검증할 수 있어야 합니다. 상태 루트는 실제로 이전 상태 루트의 맨 위에 있습니다. 이 블록을 실행한 결과입니다. Ethereum의 다중 클라이언트와 호환됩니다. 이는 단일 증명 시스템을 내장하는 것을 피하고 대신 여러 클라이언트가 서로 다른 증명 시스템을 사용할 수 있도록 허용한다는 의미입니다.

이는 또한 다음과 같은 몇 가지 의미도 있습니다.

데이터 가용성 요구 사항:캡슐화된 ZK-EVM 증명을 사용하는 모든 EVM 실행의 경우, 우리는 다양한 증명 시스템을 사용하는 증명자가 실행을 재인증할 수 있고 해당 증명 시스템에 의존하는 클라이언트가 새로 생성된 증명을 확인할 수 있도록 기본 데이터를 사용할 수 있는지 확인하려고 합니다. .

증명은 EVM 및 블록 데이터 구조 외부에 있습니다.：ZK-EVM 기능은 실제로 SNARK를 EVM 내부의 입력으로 허용하지 않습니다. 왜냐하면 클라이언트마다 서로 다른 유형의 SNARK를 기대하기 때문입니다. 대신 Blob 유효성 검사와 유사할 수 있습니다. 트랜잭션에는 입증해야 하는 클레임(사전 상태, 블록 본문, 사후 상태)이 포함될 수 있으며 이러한 클레임의 콘텐츠는 opcode 또는 사전 컴파일을 통해 액세스할 수 있으며 클라이언트 합의 규칙은 데이터 가용성과 블록 내 주장의 증명을 확인하세요.

감사 가능성:실행이 입증되면 문제가 발생할 경우 사용자와 개발자 모두 검사할 수 있도록 기본 데이터를 사용할 수 있기를 원합니다. 실제로 이는 데이터 가용성 요구 사항이 중요한 이유를 하나 더 추가합니다.

업그레이드 가능성:특정 ZK-EVM 솔루션에서 버그가 발견되면 신속하게 수정할 수 있기를 원합니다. 이는 문제를 해결하는 데 하드 포크가 필요하지 않음을 의미합니다. 이는 EVM 및 블록 데이터 구조 외부의 증명이 중요한 또 다른 이유를 추가합니다.

대략적인 EVM 지원:L2의 매력 중 하나는 실행 계층에서 혁신하고 EVM을 확장하는 능력입니다. 특정 L2의 VM이 EVM과 약간만 다른 경우 L2가 EVM과 동일한 부분에 대해 기본 프로토콜 내 ZK-EVM을 사용하고 다른 부분을 처리하기 위해 자체 코드에만 의존할 수 있다면 좋을 것입니다. 이는 호출자가 비트 필드, 연산 코드 또는 주소 목록을 지정할 수 있도록 ZK-EVM 기능을 설계함으로써 달성할 수 있으며, 이는 EVM 자체가 아닌 외부에서 제공되는 테이블에 의해 처리됩니다. 가스 비용을 어느 정도 맞춤화할 수도 있습니다.

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

다중 클라이언트 아이디어는 아마도 이 목록에서 가장 논란이 많은 요구 사항일 것입니다. 한 가지 옵션은 다중 클라이언트를 포기하고 ZK-SNARK 체계에 집중하여 설계를 단순화하는 것입니다. 그러나 그 대가는 이더리움의 더 큰 철학적 변화(이것이 실제로 이더리움의 오랜 다중 클라이언트 사고 방식을 포기하는 것이기 때문입니다)와 더 큰 위험의 도입입니다. 정형검증 기술이 좋아지는 등 장기적으로는 이 길을 택하는 것이 나을 수도 있지만, 지금으로서는 너무 위험해 보입니다.

또 다른 옵션은 프로토콜 내에 알려진 고정된 증명 시스템 세트가 있는 폐쇄형 다중 클라이언트 시스템입니다. 예를 들어 PSE ZK-EVM, Polygon ZK-EVM 및 Kakarot의 세 가지 ZK-EVM을 사용하기로 결정할 수 있습니다. 블록이 유효하려면 이 세 가지 중 최소한 두 가지의 증명이 필요합니다. 이는 단일 증명 시스템보다 낫지만 사용자가 존재하는 모든 증명 시스템에 대해 유효성 검사기를 유지해야 하고 새로운 증명 시스템을 통합하기 위한 불가피한 거버넌스 프로세스가 있기 때문에 시스템 적응성이 떨어집니다.

이로 인해 나는 증거가 블록 외부에 배치되고 클라이언트가 개별적으로 확인하는 개방형 다중 클라이언트 시스템을 선호하게 됩니다. 개별 사용자는 블록을 검증하기 위해 원하는 모든 클라이언트를 사용할 것이며 해당 증명 시스템에 대한 증거를 생성하는 증명자가 하나 이상 있는 한 이를 수행할 수 있습니다. 증명 시스템은 프로토콜 거버넌스 프로세스를 설득하는 것이 아니라 사용자가 이를 실행하도록 설득함으로써 영향력을 얻게 됩니다. 그러나 앞으로 살펴보겠지만 이 접근 방식에는 더 많은 복잡성 비용이 발생합니다.

ZK-EVM 구현에서 우리가 원하는 주요 기능은 무엇입니까?

기본적인 기능적 정확성과 보안 보장 외에도 가장 중요한 속성은 속도입니다. 내장된 ZK-EVM 기능을 사용하여 비동기 프로토콜을 설계하는 것이 가능하고 각 명령문은 N 슬롯 이후의 결과만 반환하지만 몇 초 안에 증명이 생성될 수 있다는 것을 안정적으로 보장할 수 있다면 문제는 더 쉬워질 것입니다. 많으므로 각 블록에서 일어나는 일은 자급자족할 수 있습니다.

오늘날 이더리움 블록에 대한 증명을 생성하는 데는 몇 분 또는 몇 시간이 걸리지만 대규모 병렬화를 방지해야 할 이론적 이유는 없습니다. 우리는 항상 블록 실행을 개별적으로 증명하기 위해 충분한 GPU를 소집한 다음 재귀 SNARK를 사용하여 이러한 증명을 결합할 수 있습니다. . 또한 FPGA 및 ASIC을 통한 하드웨어 가속을 통해 증명 프로세스를 더욱 최적화할 수 있습니다. 그러나 실제로 이를 달성하는 것은 과소평가해서는 안 되는 엔지니어링 과제입니다.

프로토콜 내 ZK-EVM 기능은 정확히 어떤 모습인가요?

EIP-4844 Blob 트랜잭션과 유사하게 ZK-EVM 클레임을 포함하는 새로운 트랜잭션 유형을 도입했습니다.

class ZKEVMClaimTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
transaction_and_witness_blob_pointers: List[VersionedHash]
...

EIP-4844와 마찬가지로 mempool에 전달된 객체는 트랜잭션의 수정된 버전입니다.

class ZKEvmClaimNetworkTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
proof: bytes
transaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

후자는 전자로 변환될 수 있지만 그 반대는 불가능합니다. 또한 블록에 선언된 증명 목록을 포함하도록 블록 사이드카 개체(EIP-4844에 도입됨)를 확장했습니다.

실제로는 사이드카를 Blob용 사이드카와 증명용 사이드카 두 개로 분할하고 각 증명 유형에 대해 별도의 서브넷(및 Blob 추가 서브넷용 하나)을 가질 수 있습니다.

합의 계층에서 우리는 클라이언트가 블록의 각 주장에 대한 유효한 증거를 확인한 경우에만 블록을 수락한다는 유효성 검사 규칙을 추가했습니다. 증명은 ZK-SNARK 증명, 직렬화된 한 쌍의 transaction_and_witness_blobs 및 (i) 유효함과 Witness(ii) 올바른 post_state_root 출력을 사용하는 pre_state_root의 연결이어야 합니다.(Block, Witness) 잠재적으로 클라이언트는 multiple M-of-N 유형 증명입니다.

여기서 한 가지 참고할 점은 블록 실행 자체가 단순히 ZKEVMClaimTransaction 개체에 제공된 삼중항과 함께 확인해야 하는 삼중항(σpre,σpost,Proof)으로 볼 수 있다는 것입니다.

따라서 사용자의 ZK-EVM 구현은 실행 클라이언트를 대체할 수 있으며, 실행 클라이언트는 (i) 증명자 및 블록 빌더, (ii) 로컬 사용을 위해 데이터 인덱싱 및 저장에 관심이 있는 노드에서 계속 사용됩니다.

확인하고 다시 확인하세요

두 개의 Ethereum 클라이언트가 있다고 가정합니다. 하나는 PSE ZK-EVM을 사용하고 다른 하나는 Polygon ZK-EVM을 사용합니다. 이 시점에서 두 구현 모두 5초 안에 이더리움 블록 실행을 증명할 수 있는 수준으로 발전했으며 각 증명 시스템에 대해 증명을 생성하기 위해 하드웨어를 실행하는 충분한 독립 자원 봉사자가 있다고 가정합니다.

아쉽게도 독립적인 증명 시스템이 내장되어 있지 않기 때문에 프로토콜에서 인센티브를 받을 수는 없지만 RD 비용에 비해 증명자 운영 비용이 낮을 것으로 예상하므로 증명자에 대한 공통 권한을 간단히 사용할 수 있습니다. 공공재에 대한 자금을 제공합니다.

누군가가 ZKEvmClaimNetworkTransaction을 릴리스했지만 PSE ZK-EVM 증명 버전만 릴리스했다고 가정해 보겠습니다. Polygon ZK-EVM의 증명 노드는 이를 확인하고 Polygon ZK-EVM의 증명을 사용하여 객체를 계산하고 다시 게시합니다.

이는 블록을 수락하는 가장 이른 정직한 노드와 동일한 블록을 수락하는 가장 최근의 정직한 노드 사이의 전체 최대 지연을 증가시킵니다. δ: 2 δ + Tprove(Tprove 가정)<5 s ）。

그러나 좋은 소식은 단일 슬롯 최종성을 채택하면 SSF 고유의 다중 라운드 합의 대기 시간과 함께 이 추가 대기 시간을 거의 확실하게 파이프라인할 수 있다는 것입니다. 예를 들어, 4개의 서브슬롯 제안에서 헤드 투표 단계에서는 기본 블록의 유효성만 확인하면 되지만 동결 및 확인 단계에서는 존재 증명이 필요합니다.

확장: 대략적인 EVM 지원

ZK-EVM 기능의 이상적인 목표는 Near-EVM, 즉 몇 가지 추가 기능이 내장된 EVM을 지원하는 것입니다. 여기에는 새로운 사전 컴파일, 새로운 opcode 또는 EVM이나 완전히 다른 가상 머신(예: Arbitrum Stylus 등)에서 계약을 작성할 수 있는 옵션, 심지어 동기화된 교차 통신 EVM을 통한 다중 병렬도 포함될 수 있습니다.

일부 수정 사항은 간단한 방법으로 지원될 수 있습니다. 즉, ZKEVMClaimTransaction이 수정된 EVM 규칙에 대한 전체 설명을 전달할 수 있도록 하는 언어를 정의할 수 있습니다. 다음과 같이 할 수 있습니다.

맞춤형 가스 테이블(사용자가 가스 비용을 줄일 수는 없지만 늘릴 수는 있음)
특정 opcode 비활성화
블록 번호 설정(이는 하드 포크에 따라 다른 규칙을 의미함)
L1 사용 대신 L2 사용을 위해 표준화된 일련의 EVM 변경 사항 또는 기타 간단한 변경 사항을 활성화하는 플래그 설정

사용자가 보다 개방적인 방식으로 새로운 기능을 추가할 수 있도록 새로운 사전 컴파일(또는 opcode)을 도입하여 사전 컴파일된 입력/출력 레코드를 ZKEVMClaimNetworkTransaction의 blob에 추가할 수 있습니다.

class PrecompileInputOutputTranscript(Container):
used_precompile_addresses: List[Address]
inputs_commitments: List[VersionedHash]
outputs: List[Bytes]

EVM 실행은 다음과 같이 수정됩니다. 빈 입력 배열을 초기화합니다. Used_precompile_addresses의 주소가 호출될 때마다 우리는 InputsRecord(callee_address, gas, input_calldata) 객체를 입력에 추가하고 호출의 RETURNDATA를 출력[i]로 설정합니다. 마지막으로, Used_precompile_addresses가 총 len(outputs) 번 호출되었는지, 그리고 inputs_commitments가 Blob 커밋을 생성하는 입력의 SSZ 직렬화 결과와 일치하는지 확인합니다. inputs_commitments를 노출하는 목적은 외부 SNARK가 입력과 출력 간의 관계를 더 쉽게 증명할 수 있도록 하는 것입니다.

입력과 출력 간의 비대칭성에 유의하세요. 입력은 해시에 저장되고 출력은 제공되어야 하는 바이트에 저장됩니다. 입력만 보고 EVM을 이해하는 클라이언트에서 실행을 해야 하기 때문입니다. EVM 실행은 이미 입력을 생성했기 때문에 생성된 입력이 청구된 입력과 일치하는지 확인하기만 하면 되며 해시 확인만 필요합니다. 그러나 출력은 전체적으로 제공되어야 하므로 사용 가능한 데이터여야 합니다.

또 다른 유용한 기능은 모든 보낸 사람 계정에서 호출할 수 있는 특권 거래를 허용하는 것입니다. 이러한 트랜잭션은 두 개의 다른 트랜잭션 사이에서 실행되거나 사전 컴파일이 호출될 때 다른(권한이 있는) 트랜잭션의 일부로 실행될 수 있습니다. 이는 EVM이 아닌 메커니즘이 EVM으로 다시 콜백하도록 허용하는 데 사용될 수 있습니다.

이 디자인은 새롭거나 수정된 사전 컴파일 외에도 새롭거나 수정된 opcode를 지원하도록 수정될 수 있습니다. 사전 컴파일만으로도 이 디자인은 매우 강력합니다. 예를 들어:

상태에 특정 플래그가 있는 일반 계정 주소 목록을 포함하도록 Used_precompile_addresses를 설정하고 SNARK를 만들어 올바르게 빌드되었음을 증명함으로써 EVM 또는 WASM(또는 다른 방법)을 사용하여 계약을 작성할 수 있는 Arbitrum Stylus 스타일 기능을 지원할 수 있습니다. VM). 권한 있는 트랜잭션을 사용하면 WASM 계정이 EVM을 다시 호출할 수 있습니다.
여러 EVM에서 실행되는 입력/출력 레코드와 권한 있는 트랜잭션이 올바른 방식으로 일치하는지 확인하는 외부 검사를 추가하여 동기화된 채널을 통해 서로 통신하는 여러 EVM의 병렬 시스템을 증명할 수 있습니다.
유형 4 ZK-EVM은 여러 구현을 통해 작동할 수 있습니다. 하나는 Solidity 또는 다른 고급 언어를 SNARK 친화적인 VM으로 직접 변환하는 것이고, 다른 하나는 이를 EVM 코드로 컴파일하여 ZK-EVM 구현으로 빌드하는 것입니다. 두 번째(불가피하게 느린) 구현은 결함 증명자가 버그를 주장하는 트랜잭션을 보내는 경우에만 실행될 수 있으며, 두 가지 모두 트랜잭션을 다르게 처리할 수 있는 경우 포상금을 수집합니다.
모든 호출이 0을 반환하도록 하고 호출을 블록 끝에 추가된 권한 있는 트랜잭션에 매핑하여 순수 비동기 VM을 구현할 수 있습니다.

확장: 상태 저장 증명자 지원

위 설계의 한 가지 과제는 완전히 상태가 없기 때문에 데이터가 비효율적이라는 것입니다. 이상적인 데이터 압축에서 상태 저장 압축을 사용하는 ERC 20 전송은 상태 저장 압축만 사용하는 것보다 최대 3배 더 공간 효율적일 수 있습니다.

또한 상태 저장 EVM은 증인 데이터 제공을 요구하지 않습니다. 두 경우 모두 원칙은 동일합니다. 이전 EVM 실행에서 입력되거나 생성되었기 때문에 데이터가 사용 가능하다는 것을 이미 알고 있는데 데이터를 사용 가능하도록 요구하는 것은 낭비입니다.

ZK-EVM 기능을 상태 저장하려면 두 가지 옵션이 있습니다.

1) σpre는 비어 있거나, 선언된 키와 값이 있는 사용 가능한 데이터 목록이거나, 이전에 실행된 σpost여야 합니다.

2) (σpre, σpost, Proof) 삼중항에 블록 생성 영수증 R에 대한 Blob 커밋을 추가합니다. 블록, 증인, 영수증 또는 일반 EIP-4844 blob 트랜잭션을 나타내는 것을 포함하여 이전에 생성되거나 소비된 blob 커밋에는 시간 제한이 있을 수 있으며 ZKEVMClaimTransaction에서 참조되고 실행 중에 액세스될 수 있습니다(아마도 일련의 지침을 통해: 커밋 i의 바이트 N...N+k-1을 블록 + 증인 데이터의 위치 j에 삽입합니다).

옵션 1은 내장된 무상태 EVM 검증 대신 EVM 서브체인을 구축하는 것을 의미합니다. 옵션 2는 기본적으로 이전에 사용되었거나 생성된 Blob을 사전으로 사용하는 최소한의 기본 제공 상태 저장 압축 알고리즘을 만드는 것입니다. 두 방법 모두 증명 노드에 부담을 주므로 증명 노드만 더 많은 정보를 저장하면 됩니다. 두 번째 경우에는 첫 번째보다 이 부담을 시간 제한적으로 만드는 것이 더 쉽습니다.

폐쇄형 다중 증명자 및 오프체인 데이터에 대한 매개변수

M-of-N 구조에 고정된 수의 증명자가 있는 폐쇄형 다중 증명 시스템은 위의 많은 복잡성을 방지합니다. 특히, 폐쇄형 다중 인증자 시스템은 데이터가 체인에 있는지 확인하는 것에 대해 걱정할 필요가 없습니다. 또한 폐쇄형 다중 증명 시스템을 통해 ZK-EVM 증명을 오프체인에서 실행할 수 있어 EVM 플라즈마 솔루션과 호환됩니다.

그러나 폐쇄형 다중 인증자 시스템은 거버넌스 복잡성을 증가시키고 감사 가능성을 제거합니다. 이는 이러한 이점과 비교하여 평가해야 하는 높은 비용입니다.

ZK-EVM을 구축하여 프로토콜 기능으로 만든다면 Layer 2 프로젝트의 역할은 무엇인가요?

현재 레이어 2 팀 자체에서 구현하는 EVM 검증 기능은 프로토콜에 의해 처리되지만 레이어 2 프로젝트는 여전히 많은 중요한 기능을 담당합니다.

빠른 사전 확인: 단일 슬롯의 최종성으로 인해 레이어 1 슬롯이 느려질 수 있으며, 레이어 2 프로젝트는 이미 하나의 슬롯에서 훨씬 낮은 대기 시간으로 레이어 2의 자체 보안이 지원되는 사전 확인을 사용자에게 제공하고 있습니다. 이 서비스는 계속해서 레이어 2에서 완전히 관리됩니다.
MEV(채굴 추출 가능 가치) 완화 전략: 여기에는 암호화된 멤풀, 평판 기반 주문자 선택 및 레이어 1이 구현하기를 꺼리는 기타 기능이 포함될 수 있습니다.
EVM 확장: 레이어 2 프로젝트는 사용자에게 EVM에 대한 중요한 확장을 제공할 수 있습니다. 여기에는 대략적인 EVM과 Arbitrum Stylus의 WASM 지원 및 SNARK 친화적인 Cairo 언어와 같은 근본적으로 다른 접근 방식이 포함됩니다.
사용자와 개발자를 위한 편의성: 레이어 2 팀은 사용자와 프로젝트를 생태계로 끌어들이고 환영받는 느낌을 주기 위해 많은 작업을 수행하며 네트워크 내에서 MEV 및 혼잡 요금을 캡처하여 보상받습니다. 이 관계는 앞으로도 계속 존재할 것이다.