延迟执行层状态根

摘要

本 EIP 提议，对于每个区块 n，区块 n 的 ExecutionPayload 中的 state_root 引用区块 n-1 的后状态。因此，区块 n 不再需要计算和包含或验证区块 n 的后状态根。这消除了区块传播关键路径上昂贵的 state root 计算，从而减少了区块生产的端到端延迟，并可能提高吞吐量。

动机

目前，每个以太坊区块都包含两个 state_root。

共识层 (CL) state_root 包含在 BeaconBlock 中，用于跟踪 CL 状态（例如，验证者进入和退出）。

执行层 (EL) state_root 包含在 ExecutionPayload 中，用于跟踪交易执行的影响（例如，账户余额、代码等）。

EL state_root 必须由区块构建者计算（并由中继者、验证者和轻客户端验证），并且几乎是实时的。这种计算占用了区块生产和验证时间的很大一部分，尤其是在 MEV-Boost 环境中。这种开销对于实现链的实时 ZK 证明的努力也是一个挑战。

通过将 EL state_root 引用延迟一个区块，我们可以从区块生产的关键路径中消除 EL state_root 计算开销。相反，客户端可以在区块 n 之前的空闲Slot时间内流水线化计算区块 n-1 的 EL state_root。

此更改将降低尖端延迟，使我们能够提高吞吐量并简化区块生产流水线。它还可以显着加速以太坊实时 ZK 证明的时间表。

规范

执行层变更

1. ExecutionPayload State Root 字段

   • 之前（在当前的合并后设计中）：

     struct ExecutionPayload {
     uint256 blockNumber;
     uint256 timestamp;
     bytes32 parentHash;
     address feeRecipient;
     bytes32 stateRoot;  // 引用*此*区块的交易的后状态根
     }

   • 之后（概念性的）：

     struct ExecutionPayload {
     uint256 blockNumber;
     uint256 timestamp;
     bytes32 parentHash;
     address feeRecipient;
     bytes32 stateRoot;  // 现在引用*此*区块的预状态，即 区块 (n-1) 的后状态根
     }

   • 换句话说，区块 n 的 ExecutionPayload.stateRoot 现在必须指向区块 n-1 的执行层后状态，而不是引用区块 n 自身交易后的新状态。

2. 区块头验证

   • 删除要求每个区块的 stateRoot 与同一区块中交易产生的后状态匹配的规则：

   • 相反，要求 payload_n.stateRoot == post_state(n-1)：

     def validate_execution_payload(payload_n, post_state_of_block_n_minus_1):
      # 之前：
      #   assert compute_state_root(transactions_of_block_n) == payload_n.stateRoot
      #
      # 现在：
      assert payload_n.stateRoot == post_state_of_block_n_minus_1

   • 区块 n 产生的实际新状态根只会出现在区块 n+1 中。

3. 主动计算后状态根：

   • 为了充分实现延迟优势，客户端应在Slot n 的空闲时间内计算区块 n-1 的后状态根。
     • 具体来说，一旦收到并处理了区块 n-1，客户端就可以在等待区块 n 到达的“间隙”中生成（或最终确定）其 EL 后状态根。
     • 这样，当区块 n 到达时，节点可以快速验证 payload_n.stateRoot 是否与已知的 post_state(n-1) 匹配。
   • 或者，客户端可以懒惰地等到区块 n 到达后再计算 n-1 的后状态根，但这会消除大部分延迟优势。客户端将不得不再次暂停以计算先前的根，然后才能最终确定当前区块的验证。

共识层

CL 验证过程或区块结构不需要进行任何更改：

• 信标区块继续像往常一样包装每个 ExecutionPayload。
• 该提案仅更改 EL stateRoot 字段的填充和验证方式。

转换 / 分叉激活

在激活此提案的硬分叉时（称此激活区块为 F）：

• 区块 F 将重复与前一个区块 F-1 相同的 EL state_root。也就是说：

  ExecutionPayload(F).stateRoot = post_state(F-1)

• 区块 F+1 将引用区块 F 的后状态，并从那时起继续新的延迟根方案。

理由

1. 减少尖端延迟

   • 提议者和构建者不再需要在同一个Slot内计算和最终确定新的状态根。
   • 这加快了区块验证速度，因为验证者可以在检查区块的执行情况以及其预状态根与他们预先计算的预期值匹配后进行签名（即，无需等待计算新的状态根）。

2. 提高吞吐量

   • 当前花费在同槽 state_root 计算上的时间可以重新利用。
   • 现在可以将这些时间重新分配给增加的 L1 区块容量（更高的 gas 目标）或更快的Slot时间，从而降低重组的风险。

3. 简化 MEV-Boost 和构建者的时序

   • 在提议者-构建者分离 (PBS) 模型中，区块构建速度是构建者和中继者的一个重要的竞争维度。
   • 延迟 state root 也有助于区块生产流水线中的参与者。构建者可以将时间重新分配给构建更有效的区块，中继者不必担心 state root 延迟成为时序差异或竞争的来源。

4. 加速实时 ZK 证明

   • Merkle 根对于 ZK 证明系统来说尤其具有挑战性，因为 Keccak 不是 ZK 友好的哈希函数。
   • 如果没有延迟的 state root，实时 SNARK 证明将与现有的实时 state root 共享所有延迟问题（但会更糟，因为它们需要更长的时间来计算）。
     • 区块提议者和构建者需要在决定构建区块后 <1 秒内能够证明 state root。这在现实中是不可能的。
     • 延迟将以与当前 state root 计算延迟相同的方式与 MEV 流水线交互。
   • 通过延迟的 state root，伴随的 ZK 证明的计算也可以延迟（流水线化）。网络将有大约 6 秒的时间来生成证明，这要可行得多。
   • State root 延迟可能是实时 ZK 证明的必要更改。

向后兼容性

此 EIP 是一项共识破坏性更改，需要在主网或采用它的任何网络上进行协调的硬分叉。激活后，期望区块包含其自己的（执行层）后状态根的旧客户端将不兼容且无法同步。

安全考虑事项

1. 轻客户端

   • 必须接受区块的最终状态根直到后续区块才发布，从而增加了一个Slot的延迟（例如 12 秒）。
   • 在实践中，许多轻客户端协议已经容忍证明可用性方面的一些延迟。
   • 值得注意的是，许多其他区块链网络已经以延迟的 state root 运行，并且运行良好。其中一个网络 Cosmos 是一个完全基于具有延迟 state root 的轻客户端互操作性的多链架构。

2. 依赖合约

   • 我们不知道有任何常见的合约类型假设同一区块 state root 的可用性。

版权

版权和相关权利通过 CC0 放弃。

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