EIP-7862: 延迟执行层状态根

将 ExecutionPayload 的状态根引用延迟一个区块。

摘要

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

动机

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

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

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

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

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

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

规范

执行层变更

1. ExecutionPayload 状态根字段

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

     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. 主动计算后状态根：

   • 为了充分发挥延迟优势，客户端应在时隙 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. 减少顶端的延迟

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

2. 提高吞吐量

   • 当前用于同一时隙 state_root 计算的时间可以重新利用。
   • 现在可以将此时间重新分配给增加的 L1 区块容量（更高的 gas 目标）或更快的时隙时间，并降低重组的风险。

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

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

4. 加速实时 ZK 证明

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

向后兼容性

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

安全考虑

1. 轻客户端

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

2. 依赖合约

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

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

Charlie Noyes <charlie@paradigm.xyz>, Dan Robinson <dan@paradigm.xyz>, Justin Drake <justin@ethereum.org>, Toni Wahrstätter (@nerolation), "EIP-7862: 延迟执行层状态根 [DRAFT]," Ethereum Improvement Proposals, no. 7862, December 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7862.