作者: 以太坊研究员 Justin Drake, ethresearch; 编译: 陶朱, 진써차이징(Jinse)
这篇文章的功劳要归功于更广泛的以太坊研发社区。关键贡献源自 2017 年, 多年来设计有了重大的增量解锁。最近的 zkVM 工程突破引发了彻底的设计空间探索。本文只是尽最大努力尝试为一个可能终于到来的大创意拼凑出一个连贯的设计。
摘要
我们提出了一种优雅而强大的 EXECUTE 预编译, 将原生 L1 EVM 执行引擎暴露给应用层。原生执行汇总(简称"原生汇总")是一种使用 EXECUTE 来验证批量用户交易的 EVM 状态转换的汇总。可以将原生汇总视为"可编程执行分片", 将预编译包装在派生函数中以处理 EVM 外的系统逻辑, 例如排序、桥接、强制包含、治理。
由于 EXECUTE 预编译由验证器直接执行, 因此它享有 (zk)EL 客户端多样性并提供 EVM 等效性, 该等效性在构造上无错误, 并且与通过 L1 硬分叉进行的 EVM 升级向前兼容。对于希望完全继承以太坊安全性的 EVM 等效汇总, 像 EXECUTE 预编译这样的 EVM 自省形式是必要的。我们将完全继承以太坊安全性的汇总称为"无需信任的汇总"。
EXECUTE 预编译大大简化了 EVM 等效汇总的开发, 因为无需复杂的基础设施(例如防欺诈游戏、SNARK 电路、安全委员会)即可进行 EVM 模拟和维护。使用 EXECUTE, 只需几行 Solidity 代码, 使用简单的派生函数即可部署最小的原生汇总和基于汇总, 从而无需对排序、强制包含或治理进行特殊处理。
最重要的是, 原生汇总可以享受实时结算, 而无需担心实时证明, 从而大大简化了同步可组合性。
本文分为两部分, 首先介绍拟议的预编译, 最后讨论原生汇总。
第 1 部分 — EXECUTE 预编译
结构
EXECUTE 预编译接受输入 pre_state_root、post_state_root、trace 和 gas_used。当且仅当满足以下条件时, 它才返回 true:
trace 是格式良好的执行跟踪(例如 L2 交易列表和相应的状态访问证明)
trace 的无状态执行从 pre_state_root 开始, 在 post_state_root 结束
trace 的无状态执行恰好消耗 gas_used gas
有一种 EIP-1559 式机制, 用于计量和定价 L1 区块中所有 EXECUTE 调用所消耗的累计 gas。具体来说, 有一个累计 gas 限制 EXECUTE_CUMULATIVE_GAS_LIMIT, 以及一个累计 gas 目标 EXECUTE_CUMULATIVE_GAS_TARGET。(当 L1 EVM 可由验证者无状态执行时, 累计限制和目标可以与 L1 EIP-1559 机制合并。)
调用预编译需要花费固定数量的 L1 gas、EXECUTE_GAS_COST, 加上 gas_used * gas_price, 其中 gas_price(以 ETH/gas 计价)由 EIP-1559 式机制设置。即使预编译返回 false, 也会提取全额预付款。
跟踪必须指向来自调用数据、blob、状态或内存的可用以太坊数据。
重新执行
如果 EXECUTE_CUMULATIVE_GAS_LIMIT 足够小, 验证器可以简单地重新执行跟踪以强制执行 EXECUTE 调用的正确性。基于重新执行的预编译的初始部署可以作为垫脚石, 类似于原始 danksharding 的简单重新下载 blob 到完整 danksharding。请注意, 简单的重新执行不会给验证器带来状态增长或带宽开销, 并且任何执行开销都可以在 CPU 核心之间并行化。
验证器必须持有跟踪的明确副本以进行重新执行, 从而防止使用通过 DAS 采样(而不是下载)的 blob 数据的指针。请注意, 乐观的本机汇总可能仍会以 blob 的形式发布汇总数据, 仅在欺诈证明游戏中回退到调用数据。还要注意的是, 乐观的原生汇总可以具有远远超过 EXECUTE_CUMULATIVE_GAS_LIMIT 的 gas 限制, 因为 EXECUTE 预编译只需要在小型 EVM 段上调用一次即可解决欺诈证明挑战。
作为历史记录, 2017 年 Vitalik 提出了类似的"EVM inside EVM"预编译 16, 称为 EXECTX。
通过 SNARK 执行
要解锁较大的 EXECUTE_CUMULATIVE_GAS_LIMIT, 自然会让验证者选择性地验证 SNARK 证明。从现在开始, 我们假设一个时隙延迟执行, 其中无效块(或无效交易)被视为无操作。(有关延迟执行的更多信息, 请参阅此 ethresearch 帖子 15、此 EIP 18 和 Francesco 的此设计 19。)一个时隙延迟执行会产生几秒钟(整个时隙)用于证明。它们还避免激励 MEV 驱动的证明竞赛, 这将引入集中化向量。
请注意, 即使 EXECUTE 由 SNARK 强制执行, 也没有明确的证明系统或电路被纳入共识。(请注意, EXECUTE 预编译不会将任何明确的证明作为输入。)相反, 每个质押操作员都可以自由选择他们最喜欢的 zkEL 验证器客户端, 类似于今天主观选择 EL 客户端的方式。下一节"链下证明"将解释此设计决策的好处。
从现在开始, 我们假设执行提议者在具有交替执行和共识时隙的证明者-提议者分离 (APS) 的背景下是成熟的。为了激励理性的执行提议者及时生成证明(在 1 个时隙内), 我们要求证明者仅在执行块 n 的证明可用时才证明执行块 n+1。(我们建议在 p2p 层将块 n+1 与块 n 的 EXECUTE 证明捆绑在一起。)跳过证明的执行提议者可能会错过他们的时隙, 导致错过费用和 MEV。我们进一步对错过的执行时隙施加固定惩罚, 将其设置得足够高(例如 1 ETH)以始终超过证明的成本。
请注意, 在 APS 的背景下, 共识块的生成不会因错过的执行时隙而受阻。然而, 及时生成证明对于轻客户端来说很重要, 这样他们就可以在链端轻松读取状态, 而无需无状态重新执行。为了确保及时为轻客户端生成证明, 即使在下一个执行提议者错过其时隙的特殊情况下, 我们也依赖于利他少数证明者假设。单个利他证明者足以在 1 个时隙内生成证明。为了避免不必要的冗余证明, 大多数利他证明者可以等待待命, 并且仅在 1 个时隙内没有证明到达时才启动, 从而充当最多 2 个时隙延迟的故障安全措施。
请注意, EXECUTE_CUMULATIVE_GAS_LIMIT 需要设置得足够低, 以使利他少数证明者假设可信(以及使执行提议不会不切实际地复杂化)。保守的策略可以是设置 EXECUTE_CUMULATIVE_GAS_LIMIT, 以便笔记本电脑(例如高端 MacBook Pro)可以访问单时隙证明。更务实和积极的政策可能是瞄准一小部分 GPU, 并且一旦它们充分商品化, 最终可能会瞄准 SNARK ASIC 证明器。
链下证明
重申一下, 我们建议不要将 zkEL EXECUTE 证明放在链上, 而是在链下共享。不保存证明是一个好主意, 由 Vitalik 22 首次提出, 它有几个优点:
多样性: 验证者可以自由地从他们信任的开发团队中选择证明验证器(包括证明系统和电路), 类似于验证者选择他们信任的 EL 客户端的方式。这通过多样性提供了稳健性。zkEL 验证器客户端(以及一些客户端的基础 zkVM)是复杂的加密软件。任何一个客户端中的错误都不应该导致以太坊崩溃。
中立性: 拥有 zkEL 验证器客户端市场允许共识层不选择技术赢家。例如, zkVM 市场竞争激烈, 选择获胜供应商(如 Risc0、Succinct 或许多其他供应商 31)可能不会被视为中立。
简单性: 共识层不需要包含特定的 SNARK 验证器, 从而大大简化了共识层的规范。只需包含状态访问证明的格式, 而不是特定的证明验证器实现细节。
灵活性: 如果发现错误或优化, 受影响的验证者可以更新他们的客户端, 而无需硬分叉。
拥有链下证明确实会带来一些可控的复杂情况:
증명 부하 및 p2p 파편화: 단일 표준 증명이 없기 때문에 여러 증명을 생성해야 합니다(각 zkEL 클라이언트마다 최소 하나씩). 각 zkEL 클라이언트의 사용자 정의(예: RISC-V zkVM을 다른 것으로 교체)에는 다른 증명이 필요합니다. 마찬가지로 각 zkEL 버전 업그레이드에도 다른 증명이 필요합니다. 이로 인해 증명 부하가 증가할 것입니다. 각 증명 유형에 별도의 gossiping 채널이 있는 경우 p2p 네트워크가 더 파편화될 것입니다.
소수의 zkEL: 소수의 zkEL이 증명을 생성하도록 동기부여하기 어렵습니다. 합리적인 제안자는 자신의 슬롯을 놓치지 않기 위해 대부분의 증명자를 충족하는 정도의 증명만 생성할 것입니다. 이 문제를 해결하기 위해 오늘날의 Vouch 4 운영자와 유사하게 사회적으로 스테이킹 운영자가 병렬로 여러 zkEL 클라이언트를 실행하도록 장려할 수 있습니다. k-of-n 설정을 실행하면 안전성도 높아지는데, 특히 임의의 EXECUTE 호출에 대한 증명을 만들 수 있는 무결성 취약점을 방지할 수 있습니다(이는 전통적인 EL 클라이언트에서는 일반적이지 않습니다).
오프체인 증명은 또한 실시간 L2 정산의 효율성을 저하시킵니다:
대체 불가능한 DA: EXECUTE의 추적 입력을 L1 검증자에게 제공해야 하므로, 실시간 정산 L2(즉시 자신의 정규 상태 루트를 업데이트하는 L2)는 L1 DA, 즉 집계를 소비해야 합니다. 주목할 점은 사기 증명 게임을 통해 정산을 지연시키는 낙관적 L2에는 이러한 제한이 없다는 것입니다.
상태 액세스 오버헤드: 추적이 무상태 실행이어야 하므로 읽거나 쓴 상태 트라이 리프를 포함해야 하며, 이는 일반적인 L2 블록보다 약간의 DA 오버헤드를 초래합니다. 주목할 점은 낙관적 L2에는 이러한 제한이 없다는 것입니다. 왜냐하면 상태 트라이 리프는 사기 증명 도전에서만 필요하고 도전자가 다시 계산할 수 있기 때문입니다.
무상태 차이: 주어진 추적에 대해 증명은 허가 없이 이루어져야 하므로 상태 차이를 집계할 수 없습니다. 그러나 해당 전용 증명이 합의에 포함되면 무상태 액세스 증명 또는 EVM 트랜잭션 서명을 압축할 수 있습니다.
RISC-V 네이티브 실행
오늘날 사실상 RISC-V zkVM으로 수렴하고 있기 때문에, RISC-V 상태 전환을 EVM(Arbitrum Stylus 5 환경의 WASM과 유사)에 직접 노출하고 SNARK 친화성을 유지할 기회가 있을 수 있습니다.
Part 2 - 네이티브 롤업
명명
먼저 네이티브 롤업의 명명에 대해 논의하여 몇 가지 혼란을 해결하겠습니다:
대체 명칭: 네이티브 롤업은 이전에 enshrined 롤업이라고 불렸습니다. 예를 들어 문헌 13과 문헌 7을 참조하십시오. ("규범 롤업"이라는 용어도 Polynya 12에서 잠시 사용되었습니다.) "enshrined" 용어는 나중에 "네이티브"로 대체되었는데, 이는 기존의 EVM 등가 롤업이 네이티브로 업그레이드될 수 있음을 나타냅니다. "네이티브"라는 이름은 Dan Robinson와 익명을 요청한 Lido 기여자가 2022년 11월에 독립적으로 제안했습니다.
기반 롤업: 기반 롤업과 네이티브 롤업은 직교 개념입니다. "기반"은 L1 정렬과 관련되고 "네이티브"는 L1 실행과 관련됩니다. 기반 및 네이티브 롤업을 "초음속 롤업"이라고 부르는 것은 과도한 상상력입니다.
실행 샤딩: 실행 샤딩(즉, L1 EVM 체인의 enshrined 복사본)은 네이티브 롤업과 관련된 다른 개념이지만 몇 년 전에 나왔습니다. (실행 샤딩은 이더리움 2.0 로드맵의 "2단계"였습니다.) 네이티브 롤업과 달리 실행 샤딩은 프로그래밍할 수 없으며 사용자 정의 거버넌스, 사용자 정의 정렬, 사용자 정의 가스 토큰 등의 옵션이 없습니다. 실행 샤딩은 일반적으로 고정 수의 인스턴스(예: 64개 또는 1,024개 샤드)로 구현됩니다. 불행히도 Martin Köppelmann은 2024년 Devcon에서 실행 샤딩에 대한 강연에서 "네이티브 L2"라는 용어를 사용했습니다.
이점
네이티브 롤업에는 다음과 같은 여러 가지 이점이 있습니다:
단순성: 네이티브 롤업 VM의 대부분의 복잡성은 사전 컴파일을 통해 캡슐화할 수 있습니다. 오늘날 Optimism과 zk-롤업은 EVM에 상응하는 수천 줄의 코드를 사용하여 사기 증명 게임 또는 SNARK 검증기를 구현하지만, 이를 단일 코드 줄로 압축할 수 있습니다. 네이티브 롤업에는 증명 네트워크, 감시탑, 보안 위원회와 같은 보조 인프라도 필요하지 않습니다.
보안성: 오류 없는 EVM 사기 증명 게임 또는 SNARK 검증기를 구축하는 것은 매우 어려운 엔지니어링 과제이며 심층 형식 검증이 필요할 수 있습니다. 오늘날 각 Optimism 및 zk EVM 롤업에는 EVM 상태 전환 기능에 심각한 취약점이 있을 가능성이 높습니다. 이러한 취약점을 방지하기 위해 일반적으로 중앙 집중식 정렬이 적대적 블록 생산에 대한 지팡이로 사용됩니다. 네이티브 실행 사전 컴파일을 통해 신뢰할 필요 없는 정렬을 안전하게 배포할 수 있습니다. 완전히 L1 보안을 상속하는 무신뢰 롤업은 L1 자산 호환성도 완전히 상속합니다.
EVM 등가성: 오늘날 롤업이 L1 EVM 규칙과 동기화되는 유일한 방법은 거버넌스(일반적으로 보안 위원회 및/또는 거버넌스 토큰)가 L1 EVM 업그레이드를 미러링하는 것입니다. (EVM 업데이트는 여전히 약 1년에 한 번씩 하드 포크를 통해 정기적으로 수행됩니다.) 거버넌스는 공격 벡터일 뿐만 아니라 엄격히 말하면 L1 EVM에서 벗어나 어떤 롤업도 진정한 장기 EVM 등가성을 달성하지 못하게 합니다. 반면에 네이티브 롤업은 거버넌스 없이 L1과 동기화된 업그레이드를 수행할 수 있습니다.
SNARK 가스 비용: 체인 상의 SNARK 검증 비용이 매우 높습니다. 따라서 많은 zk-롤업은 비용을 최소화하기 위해 자주 정산하지 않습니다. SNARK가 체인 상에서 검증되지 않기 때문에 EXECUTE 사전 컴파일을 사용하여 검증 비용을 낮출 수 있습니다. 단일 블록의 여러 EXECUTE 호출에 대한 SNARK 재귀 증명을 배치 처리하면 EXECUTE_GAS_COST를 상대적으로 낮게 설정할 수 있습니다.
동기 조합성: 오늘날 L1과의 동기 조합성을 달성하려면 동일한 슬롯에서 실시간 증명이 필요합니다. zk 롤업의 경우 초저지연 증명(예: 약 100ms)을 구현하는 것은 특히 어려운 엔지니어링 과제입니다. 단일 슬롯 지연 상태 루트를 사용하면 네이티브 실행 사전 컴파일의 증명 지연을 완전한 슬롯으로 완화할 수 있습니다.
