原生 Rollups：以太坊 L2 架构的未来

本系列之前的文章：

Gelato 的 Avalanche L1 和原生互操作性指南

L1 区块链堆栈：Avalanche vs Cosmos

Rollup L1：ABC Stack 的 Celestia Sovereign Rollup L1 与 Avalanche 和 Cosmos L1 区块链的比较

OP Stack vs. Arbitrum Orbit：最佳 L2 Rollup 比较

超越 Optimistic Rollups：ZK Rollups 和 zkVMs

概括

● 什么是 Native Rollups？ Native Rollups 是 Justin Drake 提出的一个新的以太坊扩容模型。它们通过 EXECUTE 预编译使用以太坊内置的执行引擎，消除了当前 rollups 依赖的复杂的自定义验证系统。

● 什么是 EXECUTE 预编译？为什么它很重要？ 这一核心创新使得 rollups 能够自动继承未来的 EVM 升级，并确保 L1 和 L2 执行之间的一致性。它将复杂的 rollup 逻辑压缩成一个单独的调用，验证者可以使用 zk-proofs 重新执行或验证。

● 它们与 Optimistic 和 ZK Rollups 有何不同？ 与当前需要数千行自定义代码和中心化回退机制的 rollups 不同，Native Rollups 直接使用以太坊的核心引擎。它们通过重新执行（简单但计算密集型）或 SNARKs（高效但复杂）来验证状态转换，从重新执行开始，直到 zk 技术成熟。

● Attester-Proposer Separation（APS）扮演什么角色？ APS 将信标提议者（共识）与执行提议者（区块执行）分开，从而使执行提议者有完整的 12 秒来生成 SNARK 证明。在需要时，备份的“利他证明者”会填补空白，以确保活跃性。但需要注意的是，最新的 Same-Slot Proof 设计通过自证明区块和 no-op 执行回退消除了对利他证明者的依赖。

● 无状态验证如何减少验证者的开销？ 验证者依赖于交易中包含的状态证明，而不是存储完整的区块链状态。这会将验证从一个存储密集型过程转变为一个以计算为中心的过程，同时保持无需信任性。

● 为什么 Native Rollups 是以太坊的最终扩容方案？ 它们模糊了 L1 和 L2 之间的界限，从而实现无缝的跨 rollup 交互并将以太坊的安全保证扩展到 L2。虽然由于 gas 限制和数据开销，部署可能不会在 2026 年之前发生，但它们代表了以太坊的长期统一扩容愿景。

介绍

如今的 EVM 等效 rollup 本质上是不安全和复杂的。它们需要数千行自定义代码用于欺诈证明游戏或 SNARK 验证器，这些代码很可能包含漏洞，尤其是在证明电路中，不正确的 opcode 实现可能导致无效的状态转换以加密方式被接受为正确。为了弥补这一点，大多数 rollup 依赖于中心化的排序器和安全委员会作为保障。而且，它们也无法保持真正的 EVM 等效性，因为它们需要治理来手动实施以太坊升级，并且昂贵的链上 SNARK 验证导致结算不频繁。

什么是 Native Rollups 以及它们如何成为解决方案

Native Rollups 代表了一种改变游戏规则的以太坊扩容方法，它建立在以太坊研发社区自 2017 年以来不断发展的想法之上。它使用一个提议的 EXECUTE 预编译，将以太坊的原生 EVM 执行引擎直接暴露给 rollups。Rollups 无需构建自定义验证系统，只需使用其交易轨迹调用此预编译，以太坊验证者可以使用不同的 zkEL 客户端离线重新执行或验证证明。

正如 Justin Drake 所说：“可以将 Native Rollups 视为‘可编程的执行分片’，它们将预编译包装在一个派生函数中，以处理额外的 EVM 系统逻辑，例如排序、桥接、强制包含、治理。”

EXECUTE 从根本上来说是通过 L1 安全继承来实现无需信任的 rollups 并消除复杂的自定义验证系统，而不是使每次执行的计算成本更低。成本优势是次要的，来自批量处理效率和潜在的补贴，而不是来自预编译在计算任务上本质上更有效。

要理解 Native Rollups 如何实现这种戏剧性的简化，我们需要检查使其成为可能的技术基础：EXECUTE 预编译。

Optimistic Native Rollups vs ZK Native Rollups

乐观 Native Rollups 可以使用像 Celestia 这样的廉价数据可用性来进行正常操作，只需要在欺诈纠纷期间使用昂贵的以太坊 DA。它们可以处理任意大的批次，因为 EXECUTE 预编译仅在挑战期间验证小的有争议的片段，而不是整个批次。用户必须等待挑战期才能 finality。

另一方面，ZK Native Rollups 必须将所有交易数据存储在以太坊 DA 上，因为验证者需要立即访问执行轨迹。它们的批次大小受到 EXECUTE_CUMULATIVE_GAS_LIMIT 的限制，但可以实现实时结算（单Slot延迟执行），而无需当前 ZK rollups 所需的超快证明。

ZK Native Rollups 的速度优势可以大大节省成本并解锁新的功能。快速 finality 使得 Across 等资本效率高的桥接协议成为可能，做市商可以在无需延长资金锁定的情况下提供即时流动性，从而大大降低了桥接费用，而这些费用通常会抵消 ZK rollup 的溢价。实时证明还可以实现无缝的跨 rollup 可组合性和完全无需信任的桥接，用户可以直接通过 ZK 互操作性进行桥接，而无需依赖于具有信任假设和延迟的第三方证明桥。

虽然乐观 native rollups 具有较低的运营成本，但它们的慢速 finality 会带来隐藏的成本，例如挑战期间的资本锁定、由于结算延迟而增加的桥接费用，以及整个应用程序中资本效率的降低。在计算这些间接成本时，ZK native rollups 通常被证明更经济，尽管它们具有较高的前期运营费用。

但是，这假设 EXECUTE 的主要价值是执行效率。如果真正的成本节省来自使用 SNARK 递归批量处理 EXECUTE 调用，那么乐观 native rollups 可能会放弃复杂的欺诈证明而选择简单的重新执行，从而变得更具竞争力。在不知道批量处理与当前 rollup 验证相比可以降低多少成本的情况下，很难确定哪种 native rollup 方法在长期来看实际上更经济。

技术架构

EXECUTE 预编译函数旨在将以太坊 L1 执行引擎暴露给应用程序。

它有四个输入：pre_state_root（起始状态）、post_state_root（结果状态）、trace（执行细节）和 gas_used（消耗的计算资源）。

当调用时，预编译从起始状态开始处理提供的 trace，并确认其产生完全声明的结束状态，同时精确消耗指定的 gas 量。

EIP-1559 风格的机制计量并定价在 L1 区块中所有 EXECUTE 调用中消耗的累积 gas，参数包括累积 gas 限制和目标，以管理资源使用。

状态转换和无状态验证

状态转换是通过执行交易从一个区块链状态移动到另一个区块链状态的过程。每个交易都会改变区块链的状态，例如更新帐户余额、修改合约存储或创建新帐户。

无状态验证 是一种方法，验证者可以在无需维护区块链状态的完整副本的情况下确认这些状态转换的正确性。验证者无需在本地存储所有帐户余额和合约数据，而是会收到状态访问证明（加密证明），这些证明会显示交易之前和之后的相关状态值。

为什么无状态验证对于 Native Rollups 很重要？

无状态验证可以有效验证 Native Rollups 的状态转换。验证者无需存储完整的区块链状态来验证转换，而是可以使用提供的证明来重建验证所需的特定状态数据。这会将状态转换验证从存储密集型过程转变为以计算为中心的过程。

这一点至关重要，因为状态存储是以太坊验证者最昂贵的资源。借助 ZK 证明，Native Rollup 的计算变得非常廉价，因为验证者只需验证简洁的加密证明，而不是逐步重新执行整个状态转换，从而大大提高了 rollup 验证的效率。

在 Native Rollups 中的实现

Native Rollups 将采用分阶段验证方法启动，该方法会随着 ZK 技术的成熟而发展：

1. 简单重新执行（启动策略）：验证者直接重新运行 rollup 的交易来检查正确性。这种方法简单明了，但受到验证者计算资源的限制。

2. SNARK 验证（长期愿景）：验证者无需重新执行所有内容，而是检查简洁的数学证明。这可以大大提高吞吐量，同时减少计算开销。随着 ZK 证明变得更快、更便宜，SNARK 验证可能会完全取代重新执行，成为主要的验证方法。

一种中间方法可以使用乐观假设，并使用 ZK 故障证明来解决争议，类似于当前的乐观 rollup，但使用加密证明而不是欺诈证明游戏。但是，随着 ZK 证明成本的降低和证明速度的提高，这变得不太有吸引力，因为乐观方法的主要好处是避免了证明生成开销，但代价是在系统中引入了大量缓慢（挑战期），这可能会带来自身的成本，例如桥接资产进出 rollup 的资本效率低下。

目前尚不清楚 Native Rollup 桥将如何处理状态转换。当前的 L2 发布链上证明以进行智能合约验证，但是由于 Native Rollup 证明是由验证者离线验证的，因此用于桥接互操作性的其他链上验证仍然是一个悬而未决的设计问题。

通过无状态验证，虽然验证者不会长期存储 rollup 状态，但他们仍然必须临时持有 trace 的显式副本，因为 blob 数据仅通过 DAS 进行采样，而不是完全下载，但是验证者需要完整的 trace 访问权限才能验证 EXECUTE 调用。对于重新执行强制执行，他们使用此 trace 自己重新执行计算。与传统的乐观 rollup 相比，这会产生额外的 DA 开销，后者仅在欺诈证明挑战期间才需要状态访问证明，而不是针对每次状态转换验证。对于 SNARK 强制执行，他们使用 trace 来验证其格式是否正确，同时依靠加密证明来确保正确性。

对于 SNARK 强制执行，执行提议者通过点对点网络离线生成和共享证明，验证者仅在存在先前区块的有效证明时才证明新的执行区块。Native rollups 使用 EXECUTE 预编译通过使用执行轨迹调用它来验证其状态转换，并且如果轨迹正确地将预状态转换为后状态，则预编译将返回 true。

验证者实际上如何验证这些证明？

没有通用的 ZK 证明格式。ZK 证明完全保持离线且非标准化，每个验证者都可以使用他们信任的团队的任何 ZK 证明系统和格式。以太坊的共识层标准化的只是状态访问证明的格式（显示读取/写入哪个状态的 Merkle 证明），而不是 ZK 证明验证的实现细节。

关键是不同的验证者可以做出不同的选择。有些人可能使用 Succinct，另一些人使用 Risc0，另一些人使用完全不同的证明系统，并且他们都将参与同一个网络。只要他们都可以验证 EXECUTE 调用是否正确地从预状态转换为后状态，系统就可以正常工作。

因为证明没有标准化或写入共识，所以可能需要为同一执行轨迹生成多种证明格式，每种格式对应于验证者使用的每个 zkEL 客户端。验证者不会验证彼此的证明，而是使用他们选择的客户端独立验证轨迹。

这种设计确实会产生潜在的少数 zkEL 问题，即一些使用不太流行的证明系统的验证者可能依赖于利他证明者来生成兼容的证明，尽管该提案表明这是可以管理的。这种复杂性和牺牲简单性真的有必要避免技术锁定吗？或者，我们是否会看到统一的 ZK 证明规范的开发，该规范可以允许不同的证明系统实现与当今以太坊执行客户端类似的证明格式？

当今以太坊共识如何运作

在深入研究 Attester-Proposer Separation (APS) 之前，重要的是要了解以太坊当前的共识机制如何与提议者和证明者一起运作。

当前以太坊共识角色

在以太坊中，验证者轮流成为“提议者”（他们选择区块并获得奖励），而其他验证者的委员会则充当“证明者”（他们对区块有效性进行投票以完成链）。今天，当一个验证者被选为提议者时，他们既获得少量的共识奖励，又可能获得大量的执行奖励（来自 MEV 和费用）。

即使现在大多数提议者都通过 MEV-Boost 使用 PBS（Proposer-Builder Separation）来外包区块构建，他们仍然会获得所有执行奖励。虽然 PBS 的设计是通过消除对复杂区块构建基础设施的需求来保持提议者的去中心化，但在实践中，一些参与者正在运行垂直整合的构建者-提议者操作，这些操作可以胜过仅从外部构建者那里进行选择的纯提议者。这会给验证者带来成为复杂的构建者-提议者本身的压力，以保持竞争力，从而破坏 PBS 的去中心化目标。

了解 Attester-Proposer Separation

使用 APS，当轮到信标提议者时，信标提议者不会获得执行奖励，而是将信标提议者分开，以便信标提议者仍然提议信标区块并且仅获得信标奖励，而一个单独的“执行提议者”角色获得执行奖励。 因此，虽然信标提议者始终是由协议选择的验证者，但执行提议者是由市场确定的参与者，他们可能是任何愿意为执行权付费的人。

来源：Barnabé 在 CCE 上的 幻灯片

当前在 PBS 下，我们有信标提议者（他们处理共识但也处理执行提议）和构建者（他们构建区块）。APS 进一步拆分了信标提议者角色，从而创建了：信标提议者（纯粹的共识/证明）、执行提议者（时间和区块发布决策）和构建者（区块构建）。重要的是要注意，APS 和 PBS 并非互斥。

APS 对 Native Rollups 有何关键作用

APS 实现了单Slot延迟执行，这是一种最初为解决以太坊的执行瓶颈而提出的计时结构，它允许验证者在完全执行交易之前证明区块。

使用 APS，由于信标提议者和执行提议者是具有不同工作的不同实体，因此协议可以为他们提供不同的计时（有关 APS 的实现，请参见下图）：

• Slot N：信标提议者完成其共识工作
• Slot N+1：执行提议者完成其Slot N 的执行工作

来源：更多关于提议者和构建者的图片

这个额外的时间Slot使 Native Rollups 变得实用，因为执行提议者有完整的 12 秒来生成 Native Rollups 所需的复杂 SNARK 证明，而不必将所有内容都赶到一个Slot中。

如果没有 APS，则一个人（信标提议者）必须在同一Slot中完成两项工作，这没有为繁重的计算留下足够的时间。

什么是延迟执行

延迟执行是 Ethereum 的一项提议的增强，它将块验证与交易执行分开，以解决当前系统中的一个主要瓶颈。目前，验证者必须先执行一个块中的每个交易，然后才能验证和批准该交易，这会减慢整个网络的速度，因为交易执行的计算量可能很大且耗时。

来源：https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677

通过延迟执行，验证者可以快速验证块的结构并批准将其包含在区块链中，而无需先运行交易。此更改可以使 Ethereum 处理块的速度提高 5 到 8 倍，因为验证者不再需要等待复杂的交易执行才能继续前进，同时仍通过经济激励来维护安全性，其中块提议者为包含交易支付前期成本。

来源：https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677

什么是单Slot延迟证明生成

现在我们了解了延迟执行和 APS 如何提供计时结构，让我们来看看 Native Rollups 如何将其用于证明生成。

Native Rollups 可以使用两种不同的强制执行机制，具体取决于吞吐量需求。对于较小的 gas 限制，验证者可以简单地直接重新执行轨迹，而无需复杂的证明。但是，对于具有较大 gas 限制的 SNARK 强制执行的 EXECUTE 调用，Native Rollups 使用单Slot延迟证明系统进行实际验证。 如下图所示，在一个块在Slot n 中执行后，其加密证明将在下一个Slot (n + 1) 中生成。这为验证者提供了足够的时间来创建复杂的 zk 证明。证明者仅在执行块 n 的证明可用时才证明执行块 n + 1，从而确保安全性。

如果证明被延迟，则备份“利他证明者”会介入以保持系统平稳运行。

当验证者被选为执行提议者时，他们负责生成前一个块的证明。他们有强大的经济动机这样做，因为未能提供证明意味着错过他们的Slot并损失费用和 MEV。

但是，关于备份机制仍然存在一个悬而未决的问题：如果执行提议者未能在一个Slot内交付证明，是否希望利他证明者生成丢失的证明以保持轻客户端可访问性？如果没有这些证明，轻客户端将需要自己重新执行 EXECUTE 调用，而不是简单地验证加密证明。当激励方选择不这样做时，是否会有足够多的利他证明者愿意免费生成昂贵的证明？

Same-Slot 证明解决方案

Native Rollup 架构的最新进展通过“Same-Slot 证明”设计解决了这些问题，该设计完全消除了对利他证明者的需求。通过将证明责任分配给Slot n 的构建者（而不是Slot n + 1），构建者必须证明自己的块才能获得执行奖励，从而创造直接的经济激励。

当缺少证明时，系统会自动将块执行视为“no-op”，其中预状态保持不变。这可确保连续的网络运行，而无需任何人免费生成昂贵的证明。链只需跳过有问题的块的执行，同时保持活跃性和轻客户端可访问性。

时序挑战

当前的 zk rollup 面临着极大的压力，需要在极短的时间内（通常在数百毫秒内）生成 SNARK 证明。这给围绕专用证明基础设施带来了重大的技术壁垒和中心化压力。

Native Rollups 通过单Slot延迟执行和 Attester-Proposer Separation (APS) 解决了这个问题：执行提议者获得一个完整的Slot（几秒钟）来生成块 n 的证明，而证明者仅在块 n 的证明准备就绪后才验证块 n +1。

这种架构通过将少量单Slot延迟换取更易于管理的证明需求，从而实现了“实时结算，而无需担心实时证明”，从而使 rollup 操作可以在无需超快专用基础设施的情况下进行访问，同时保持快速最终性。

Native Rollups 的优势和实施路径

Native Rollups 是以太坊 L2 扩容路线图的最终目标，因为它们从根本上模糊了 L1 和 L2 之间的界限。 通过 EXECUTE 预编译直接利用以太坊的原生执行引擎，这些 L2 成为以太坊本身的扩展，而不是具有自身信任假设的单独系统。 对于在整个生态系统中运营的用户和协议而言，这创造了一个更加统一、安全的环境，并将系统性风险降至最低。

通过直接与以太坊的执行引擎集成，Native Rollups 使不同的 rollups 更容易安全地交互和共享信息。 一个 rollup 可以在没有其他信任假设的情况下验证另一个 rollup 的状态。 这意味着应用程序和用户可以在多个 rollups 中移动资产或调用智能合约。

新的解决方案，例如共享/基于排序器和共享结算层，正在开发中，以帮助 rollups 实时“对话”。 虽然 Native Rollups 简化了此问题的技术方面，但完全自动和即时的跨 rollup 交易对于整个生态系统来说仍然是一项正在进行的工作。

该实施路线图涉及 EXECUTE 预编译和单Slot延迟执行的 EIP，以允许有足够的时间生成证明。 部署可能不会在 2026 年之前进行，从严格 gas 限制下的重新执行方法开始，这将大大限制吞吐量，同时零知识解决方案会逐渐成熟。 技术挑战是巨大的：见证数据会产生 5-10 倍的 DA 开销，存款/取款接口需要标准化，并且只有严格的 EVM 等效 rollups 才能过渡到此模型。 现有的 rollups 将需要大量的代码重构，这使得采用成为一项复杂的技术工作，而不是简单的升级。

值得注意的是，Native Rollup 的愿景已获得领先 ZK 团队的强烈支持。 Succinct 首席执行官 Uma Roy 特别直言不讳，分享了关于 Native Rollups 如何简化 ZK 集成并与以 rollup 为中心的路线图保持一致的热情。 在此 Bankless 播客剧集中，Uma 解释说，Succinct 的 zkVM 基础设施可以帮助为 Native Rollups 的证明层提供支持，从而实现具有以太坊级别安全性的可扩展实时执行。 支持这一愿景的关键公共基础设施是 ethproofs.org，该网站跟踪和比较 zkVM 性能，特别是证明成本和延迟，以帮助推动以太坊 rollup 基础设施实现实时证明的进展。

未来的生态系统：以太坊作为安全出口商

对于关键的金融应用程序和高价值资产，以太坊的结算层继续提供无与伦比的安全保证，并且 native rollups 最终会将这种安全性扩展到兼容的 L2。

对于以太坊扩容的未来，Native rollups 代表着一个激动人心的愿景， rollups 真正成为以太坊本身的扩展，而不是具有自身信任假设的独立系统。

对于希望将其应用程序与 Gelato Web3 Services 集成的开发人员，请查看 Web3 Functions、Relay 和 VRF！ 请访问我们的 Discord 服务器 以获取开发人员支持和参与，并通过关注我们的 X 了解最新进展。

定义

• 什么是利他证明者？：证明生成过程中的备份角色，当主要证明者延迟或失败时，他们会介入以生成和提交证明。 他们的角色对于活跃性至关重要，但会引发有关激励机制调整的问题。

• 什么是基于排序器？：基于排序器是一种 rollup 交易排序系统，它直接从以太坊 Layer 1 区块提议者处获得其排序权。 排序器不是独立运行，而是集成到以太坊的提议者-构建者分离 (PBS) 流程中，使 rollup 上的交易排序与 L1 区块生成保持一致。 这可以实现抗审查性、MEV 最小化和紧密的 L1 最终性对齐，但取决于以太坊提议者的合作和约定的排序基础设施。

• 什么是 Native Rollup？：Native Rollup 是一种以太坊 Layer 2，它通过 EXECUTE 预编译利用以太坊的内置执行引擎，从而实现与以太坊的紧密集成，并消除了对自定义 EVM 验证或欺诈证明的需求。

• 什么是重新执行？：一种状态验证方法，验证者通过重放 rollup 的交易跟踪来确认结果状态是否与声明的后状态匹配。 它很简单，但计算量很大。

• 什么是共享排序器？：共享排序器是一个去中心化网络，它可以同时为多个 rollups 订购交易，从而实现跨 rollup 协调并降低中心化风险。

• 什么是共享结算层？：共享结算层是一个区块链，它充当多个 rollups 的最终真实来源，为所有结算的交易提供高级别的安全性和不可逆的最终性。

• 什么是 SNARK 验证？：一种用于证明计算正确性的加密方法。 在 rollups 中，SNARK 允许验证者使用简洁、可验证的数学证明来确认状态转换，而无需重新执行交易。

• 什么是无状态验证？：一种验证方法，验证者不存储完整的区块链状态。 相反，每个交易批次都包含所有必要的状态数据（例如 Merkle 证明），从而可以在没有本地状态访问的情况下验证正确性。

• 什么是证明者？：证明者是 Ethereum 权益证明系统中的验证者，他们对链的头部进行投票，并通过提交证明来为区块的最终性做出贡献。

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