zkEVM证明下的验证者架构变革

摘要

本文档概述了在客户端中支持 zkEVM 证明所需的高级变更。

问题

需要解决多个问题，我们简要提及它们。

状态

共识层（CL）的区块验证过程需要一个执行层（EL）节点。这是因为信标区块中包含执行负载。这意味着作为证明者（attester）验证区块时，也必须运行一个 EL。

目抢跑 EL 意味着需要拥有 EL 的完整状态，这可能非常庞大。

处理时间

随着区块 Gas 限额的增加，验证执行负载所需的平均和最坏情况时间也会增加。

带宽

随着区块 Gas 限额的增加，区块大小也会增加，因为区块中会包含更多交易。

EL 客户端多样性

由于当抢跑 EL 需要大量资源，大多数实体只会运行一个客户端。

提议的 zkEVM 解决方案

状态

zkEVM 证明可以被视为一种无状态验证方式，因此验证区块将不再需要状态。

处理时间

无论区块大小如何，验证区块所需的时间将是恒定的。

带宽

zkEVM 证明同时也是执行证明，因此不再需要交易本身。但我们仍需通过 DA 证明其可用性。

EL 客户端多样性

“添加”额外的 EL 的成本将等同于订阅额外子网的成本。

证明者架构

依赖项

zkVM 证明的主要依赖是需要某种形式的流水线（pipelining），例如 ePBS 中的流水线。

这是必要的，因为生成证明的时间大约为 6-8 秒。如果没有 ePBS 或延迟执行，我们将需要在证明截止时间之前（1-2 秒内）生成证明。

在尚未拥有 ePBS 的情况下，目前有两种缓解措施：

• 允许在测试网上延迟证明
• 指定信标节点始终处于乐观同步模式

引擎 API

需要注意三种引擎 API 方法：

• engine_getPayload：当 CL 希望 EL 生成新的执行负载时调用。
• engine_newPayload：当 CL 希望 EL 验证新的执行负载时调用。
• engine_forkchoiceUpdate：当 CL 希望更新 EL 当前的规范终结点和安全头（以及负载准备）时调用。

getPayload

作为无状态证明者，你将无法调用 engine_getPayload。这是因为你没有用于创建执行负载的 EL 状态。

forkchoiceUpdate

无状态证明者不再需要调用此方法，因为它们未连接到需要更新的 EL。

newPayload

证明者将不再调用 EL，而是监听其订阅子网上的证明。如果收到的证明验证为真，则足以使信标节点确信执行负载是有效的。

接收证明

证明将通过子网接收。

不失一般性，每个子网将包含特定 EL 的证明。我们建议订阅多个子网以实现客户端和证明的多样性。

N 将在未来确定。现在假设我们使用数字 8。这涵盖了已知客户端：Reth、Nimbus-eth、Besu、Geth、Erigon、Nethermind、Eth-rex

节点可以设置一个参数，决定在将块的执行负载视为有效之前需要多少个证明。

生成与广播证明

无状态证明者不生成证明，但它们会重新广播在其分叉中收到的有效证明区块。

构建者或有状态提议者（用于本地区块构建）将生成区块，然后为该区块生成 N 个证明，因为无状态证明者只有在收到该区块的 K 个（来自 N 个）证明后才会认为区块有效。

MevBoost

初始实现不需要更改。

同步

EL 的同步组件现在简化为下载每个区块所需的证明。

从技术上讲，我们只需要最新区块的证明

区别在于这发生在 CL 上而非 EL 上。所需证明的数量等于自终结点检查点以来的区块数量。

与 PeerDAS 的协同作用

我们注意到，许多客户端可能由于实现了 PeerDAS 而已经拥有相似的代码路径。观察以下图示：

高级概览

┌─────────────┐    ┌─────────────────-┐     ┌──────────────┐
│   网络      │───▶│  依赖检查器     │-───▶│ 区块导入     │
│  (Gossip)   │    │  (收集与验证)    │     │   流水线     │
│             │    │                  │     │              │
└─────────────┘    └─────────────────-┘     └──────────────┘
       │                     │                     │
   组件到达           检查完成               导入区块
                     依赖项                 到分叉选择

使用 peerDAS 时，区块的列（columns）被收集并验证，只有这样才能确定区块的有效性。如果列缺失，则区块被视为无效。

可以将 peerDAS 视为引入了“区块依赖”的概念——这是区块为了被视为有效而依赖的组件。

我们希望将这个概念扩展到执行证明。列和执行证明之间的主要区别在于证明是由区块构建者创建的。

组件依赖可视化

┌───────────────────────────────────────────────────────────────────────────────┐
│                        区块导入依赖项                                          │
├─────────────────┬─────────────────┬─────────────────┬─────────────────────────┤
│   Pre-Deneb     │     Deneb       │     Fusaka      │   zkVM 分叉              │
├─────────────────┼─────────────────┼─────────────────┼─────────────────────────┤
│ • 仅区块        │ • 区块          │ • 区块          │ • 区块                  │
│                 │ • Blob 侧车     │ • 数据列        │ • 数据列                │
│                 │                 │   (PeerDAS)     │ • 执行证明              │
└─────────────────┴─────────────────┴─────────────────┴─────────────────────────┘

上面的图示展示了“区块依赖项”的演进过程。我们提到这一点是为了在概念上说明：如果存在一个组件来协调区块相对于列/blob 的有效性，那么该组件也可以泛化到包含证明。

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