原生 Rollup——来自 L1 执行的超能力 - Layer 2

总结: 这篇文章提出了一个EVM等效rollup摆脱安全委员会和其他攻击途径的方案，从而完全解锁以太坊L1的安全性。

感谢: 这篇文章的完成要感谢更广泛的以太坊研发社区。关键的贡献源于2017年，多年来取得了显著的增量设计突破。最近的zkVM工程突破促使人们对设计空间进行了彻底的探索。这篇文章只是尽力将一个伟大想法的连贯设计拼凑在一起，而这个想法的时机可能终于成熟了。

摘要: 我们提出了一个优雅而强大的EXECUTE预编译，将原生的L1 EVM执行引擎暴露给应用层。原生执行rollup，简称“原生rollup”，是一种使用EXECUTE来验证用户交易批次的EVM状态转换的rollup。可以将原生rollup视为“可编程的执行分片”，它们将预编译包装在派生函数中，以处理额外的EVM系统逻辑，例如排序、桥接、强制包含和治理。

由于EXECUTE预编译由验证者直接执行，因此它具有(zk)EL客户端多样性，并提供了EVM等效性，这种等效性在设计上没有错误，并且通过L1硬分叉与EVM升级向前兼容。对于希望完全继承以太坊安全性的EVM等效rollup来说，像EXECUTE预编译这样的EVM内省形式是必要的。我们将完全继承以太坊安全性的rollup称为“无需信任的rollup”。

EXECUTE预编译通过消除复杂的基础设施需求（例如欺诈证明游戏、SNARK电路、安全委员会）来实现EVM仿真和维护，从而显著简化了EVM等效rollup的开发。有了EXECUTE，只需几行Solidity代码和一个简单的派生函数即可部署最小的原生rollup和Based Rollup，从而无需特殊处理排序、强制包含或治理。

最重要的是，原生rollup可以享受实时结算，而无需担心实时证明，从而大大简化了同步可组合性。

这篇文章分为两部分，首先描述了提议的预编译，最后讨论了原生rollup。

第 1 部分 - EXECUTE 预编译

构造

EXECUTE预编译接受输入pre_state_root、post_state_root、trace和gas_used。当且仅当满足以下条件时，它才返回true：

• trace是格式良好的执行 轨迹（例如，L2事务列表和相应的状态访问证明）
• 从pre_state_root开始的trace的无状态执行在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 gasEXECUTE_GAS_COST，加上gas_used * gas_price，其中gas_price（以ETH/gas计价）由EIP-1559风格的机制设置。即使预编译返回false，也需要预先支付全额费用。

该trace必须指向calldata、blobs、状态或内存中可用的以太坊数据。

通过重新执行进行强制执行

如果EXECUTE_CUMULATIVE_GAS_LIMIT足够小，验证者可以简单地重新执行trace以确保EXECUTE调用的正确性。基于重新执行的预编译的初始部署可以作为垫脚石，类似于使用blobs的天真重新下载的proto-danksharding到完整的danksharding。请注意，天真的重新执行不会给验证者带来状态增长或带宽开销，并且任何执行开销都可以在CPU内核上并行化。

验证者必须持有trace的显式副本以进行重新执行，从而防止使用指向通过DAS采样的（未下载的）blob数据的指针。请注意，乐观原生rollup仍然可以将rollup数据发布在blob中，仅在欺诈证明游戏回退到calldata。另请注意，乐观原生rollup可以具有远远超过EXECUTE_CUMULATIVE_GAS_LIMIT的gas限制，因为EXECUTE预编译只需要在小的EVM段上调用一次即可解决欺诈证明挑战。

作为历史记录，Vitalik 在 2017 年提出了一个类似的名为 EXECTX 的“EVM 里面的 EVM”预编译。

通过SNARK强制执行

为了解锁大的EXECUTE_CUMULATIVE_GAS_LIMIT，很自然地让验证者选择性地验证SNARK证明。从现在开始，我们假设单Slot延迟执行，其中无效区块（或无效交易）被视为空操作。（有关延迟执行的更多信息，请参阅此ethresearch帖子，此EIP和Francesco的此设计。）单Slot延迟执行产生几秒钟的时间——整整一个Slot——用于证明。它们还避免了激励由MEV驱动的证明竞赛，这会引入中心化向量。

请注意，即使当EXECUTE由SNARK强制执行时，共识中也没有明确规定任何明确的证明系统或电路。（请注意，EXECUTE预编译不接受任何明确的证明作为输入。）相反，每个staking运营者都可以自由选择自己喜欢的zkEL验证器客户端，类似于今天主观选择EL客户端的方式。此设计决策的优势在下一节“链下证明”中进行了解释。

从现在开始，我们假设执行提议者在具有交替执行和共识Slot的证明者-提议者分离（APS）的上下文中是复杂的。为了激励理性的执行提议者及时（在一个Slot内）生成证明，我们强制证明者仅证明执行区块n+1，如果区块n的证明可用。（我们建议在p2p层将区块n+1与区块n的EXECUTE证明捆绑在一起。）跳过证明的执行提议者可能会错过他们的Slot，导致错过费用和MEV。我们进一步对错过的执行Slot处以固定罚款，将其设置得足够高（例如1 ETH）以始终超过证明的成本。

请注意，在APS的上下文中，共识区块的生成不会因错过的执行Slot而受阻。但是，及时生成证明对于轻客户端轻松读取链顶部的状态而无需无状态重新执行是相关的。为了确保即使在下一个执行提议者错过其Slot的特殊情况下，也能及时为轻客户端生成证明，我们依赖于利他少数证明者的假设。单个利他证明者足以在一个Slot内生成证明。为了避免不必要的冗余证明，大多数利他证明者可以等待待命，并且仅在1个Slot内没有证明到达时才启动，从而充当最多2个Slot延迟的故障安全。

请注意，需要将EXECUTE_CUMULATIVE_GAS_LIMIT设置得足够低，以使利他少数证明者的假设是可信的（以及使执行提议不会不切实际地复杂）。保守的策略可能是设置EXECUTE_CUMULATIVE_GAS_LIMIT，以便笔记本电脑可以访问单Slot证明，例如高端MacBook Pro。一种更务实和积极的政策可能是以小型GPU集群为目标，并且可能最终以SNARK ASIC证明器为目标，一旦这些证明器足够商品化。

链下证明

重申一下，我们建议zkEL EXECUTE证明不上链，而是在链下共享。不规定证明是一个由 Vitalik 首次提出的绝妙想法，它具有以下几个优点：

• 多样性：验证者可以自由地从他们信任的开发团队中选择证明验证器（包括证明系统和电路），类似于验证者选择他们信任的EL客户端的方式。这通过多样性提供了鲁棒性。zkEL验证器客户端（以及作为某些客户端基础的zkVM）是复杂的密码软件。任何一个客户端中的错误都不应破坏以太坊。
• 中立性：拥有一个zkEL验证器客户端市场允许共识层不选择技术赢家。例如，zkVM市场竞争非常激烈，选择像Risc0、Succinct或许多其他供应商这样的获胜供应商可能不会被认为是中立的。
• 简单性：共识层无需规定特定的SNARK验证器，从而大大简化了共识层的规范。规定状态访问证明的格式就足够了，而不是特定的证明验证器实现细节。
• 灵活性：如果发现错误或优化，受影响的验证者可以更新他们的客户端，而无需进行硬分叉。

拥有链下证明确实引入了一些可管理的问题：

• 证明者负载和p2p碎片化：因为没有单个规范证明，所以需要生成多个证明（每个zkEL客户端至少一个）。每个zkEL客户端自定义（例如，将一个RISC-V zkVM交换为另一个）都需要不同的证明。同样，每次zkEL版本升级都需要不同的证明。这将导致证明负载增加。如果每种证明类型都有单独的gossip通道，它还会使 p2p 网络碎片化。
• 少数zkEL：很难激励少数zkEL的证明生成。理性的执行提议者可能只会生成足够的证明，以便达到绝大多数证明者并且不会错过他们的Slot。为了解决这个问题，可以社会鼓励staking运营商并行运行多个zkEL客户端，类似于今天的Vouch运营商。运行一个 k-of-n 设置的额外好处是提高安全性，特别是对冲健全性错误，这些错误允许攻击者为任意EXECUTE调用制作证明（对于传统的EL客户端来说，这种情况并不常见）。

链下证明还为实时结算的L2引入了低效率：

• 没有alt DA：因为EXECUTE的trace输入需要提供给L1验证者，所以实时结算的L2（即立即更新其规范状态根的L2）必须消耗L1 DA，即成为rollup。请注意，通过欺诈证明游戏延迟结算的乐观L2没有此限制，即可以作为validium。
• 状态访问开销：因为trace必须是无状态可执行的，所以它必须包含读取或写入的状态 MPT叶子节点，相对于典型的L2区块引入了小的DA开销。请注意，乐观L2没有此限制，因为状态 MPT叶子节点 仅在欺诈证明挑战中需要，并且挑战者可以重新计算 MPT叶子节点。
• 没有状态差异：因为给定trace，证明应该是无需许可的，所以rollup状态差异是不可能的。但是，如果相应的专用证明在共识中规定，则可以压缩无状态访问证明或EVM交易签名。

RISC-V 原生执行

鉴于今天事实上的趋同于RISC-V zkVM，可能有一个机会将RISC-V状态转换原生暴露给EVM（类似于Arbitrum Stylus上下文中的WASM），并保持SNARK友好。

第 2 部分 - 原生 Rollup

命名

我们首先讨论原生rollup的命名，以解决几个混乱来源：

• 备用名称：原生rollup以前被称为已确定的rollup，例如参见这个帖子和这个帖子。（术语“规范rollup”也曾被Polynya简要使用。）后来放弃了“已确定”一词，转而支持“原生”一词，以表明现有的EVM等效rollup可以选择升级为原生rollup。 “原生”这个名称是Dan Robinson和一位希望保持匿名的Lido贡献者于2022年11月独立提出的。
• Based Rollup：Based Rollup和原生rollup是正交概念：“基于”与L1排序相关，而“原生”与L1执行相关。同时基于且原生的rollup被异想天开地称为“超健全rollup”。
• 执行分片：执行分片（即L1 EVM链的确定的副本）是一个与原生rollup相关的不同但相关的概念，比原生rollup早几年。（执行分片以前是以太坊2.0路线图的“第2阶段”。）与原生rollup不同，执行分片是不可编程的，即没有自定义治理、自定义排序、自定义gas代币等选项。执行分片通常也以固定的数量实例化（例如64或1,024个分片）。不幸的是，Martin Köppelmann在他2024年关于执行分片的Devcon演讲中使用了术语“原生L2”。

好处

原生rollup有几个好处，我们将在下面详细介绍：

• 简单性：原生rollup VM的大部分复杂性都可以通过预编译来封装。今天的EVM等效乐观和zk-rollup为其欺诈证明游戏或SNARK验证器编写了数千行代码，这些代码可能会减少到单行代码。原生rollup也不需要辅助基础设施，例如证明网络、瞭望塔和安全委员会。

• 安全性：构建一个没有错误的EVM欺诈证明游戏或SNARK验证器是一项非常困难的工程任务，可能需要深入的形式验证。每个乐观和zk EVM rollup今天在其EVM状态转换函数中都很可能存在关键漏洞。为了防御漏洞，中心化排序通常被用作拐杖来限制对抗性制作的区块的产生。原生执行预编译允许安全部署无需许可的排序。完全继承L1安全性的无需信任的rollup还会完全继承L1资产的可替代性。

• EVM等效：今天，rollup与L1 EVM规则保持同步的唯一方法是拥有治理（通常是安全委员会和/或治理代币）来镜像L1 EVM升级。（EVM更新仍然大约每年通过硬分叉定期发生。）治理不仅是一个攻击媒介，而且严格来说是脱离L1 EVM，并阻止任何rollup实现真正的长期EVM等效。另一方面，原生rollup可以与L1同步升级，无需治理。

• SNARK gas成本：在链上验证SNARK非常昂贵。因此，许多zk-rollup不频繁地结算以最大程度地降低成本。由于SNARK不在链上验证，因此EXECUTE预编译可以用作降低验证成本的一种方式。如果在区块中的多个调用中使用SNARK递归批量处理EXECUTE证明，则可以将EXECUTE_GAS_COST设置得相对较低。

• 同步可组合性：今天与L1的同步可组合性需要相同Slot实时证明。对于zk rollup来说，实现超低延迟证明，例如100毫秒的数量级，是一项特别具有挑战性的工程任务。借助单Slot延迟状态根，原生执行预编译的基础证明延迟可以放宽到整整一个Slot。

• 用于3SF的原生Rollup

• EXECUTE预编译的费用结构

• Prover Killers Killer: 你构建它，你证明它

• 已确定的原生L2和无状态区块构建

• 原文链接： ethresear.ch/t/native-ro...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～