提案：延迟stateRoot引用以提高吞吐量并降低延迟

作者：Charlie Noyes, Max Resnick

介绍

目前，每个区块头都包含一个 stateRoot，它代表执行该区块内所有交易后的状态。这种设计要求区块构建者和中间人（如 MEV-Boost 中继）计算 stateRoot，这在计算上是密集的，并且在区块生产期间增加了显著的延迟。

本提案建议修改以太坊区块结构，以便区块 n 中的 stateRoot 引用区块开始时的状态（即，在执行区块 n - 1 中的交易之后，而不是区块结束时的状态）。

通过将 stateRoot 引用延迟一个区块，我们的目标是从链顶区块验证的关键路径中移除 stateRoot 计算，从而减少 L1 延迟并释放容量以增加 L1 吞吐量。

技术规范（高层）

在验证区块 n 时，节点会确保 stateRoot 与执行区块 n-1 后的状态相匹配（即，区块 n 的 pre-state root）。

需要明确的是，执行顺序没有任何改变。区块 n 中的交易仍然应用于区块 n-1 产生的状态。

动机

stateRoot 的计算和验证在区块生产的关键路径上是不必要的工作。构建者必须首先计算 stateRoot 才能在 MEV boost 上提议一个区块，并且验证委员会必须计算 stateRoot 才能与提议的 stateRoot 进行比较，才能验证一个区块。stateRoot 计算本身约占所有参与共识的参与者在链顶工作所花费时间的 一半。 此外，stateRoot 计算所带来的任何延迟影响都会在关键路径上支付两次：一次是在区块构建阶段，另一次是在验证期间。

• 当区块构建者向中继提交区块时，他们需要提供计算出的 stateRoot。通过调查四个最大的构建者中的三个，每个构建者平均只花费 40%-50% 的时间实际构建每个区块，其余时间用于 stateRoot 计算。
• 当 MEV-Boost 中继从构建者那里收到区块时，他们应该验证其正确性。在 Flashbots 的中继中，大约一半的 ~100ms (p90) 验证时间也花在了 stateRoot 计算上。
• 当验证者收到一个新区块，或者当非 MEV-Boost 验证者（“家庭构建者”）生产一个区块时，他们也需要重新验证其执行及其 stateRoot。商品硬件 Reth 节点在实时同步期间大约 70% 的时间花在 stateRoot 上（其余时间用于执行）。

\ RETH benchmarks2130×1118 161 KB

RETH 大约 70% 的区块处理时间花在 stateRoot 计算上。

这些参与者——构建者、中继和验证者——对延迟高度敏感。他们在 slot 边界附近受到严格的时间约束（特别是随着时间博弈的日益普及）。

在链顶引入的 stateRoot 验证延迟是不必要的，移除它可以让我们改善区块生产流程的健康状况和网络稳定性。

延迟 stateRoot 的好处

• 更高的 L1 吞吐量，因为目前用于验证 stateRoot 的时间可以重新分配给执行。stateRoot 验证将与下一个插槽并行进行流水线处理（即在节点当前空闲的时间内）。在激活吞吐量增加之前，带宽要求增加和状态增长也需要是可以接受的。
• 通过流水线处理 stateRoot 节省的时间也可以分配来缩短 slot 时间——改善 L1 以太坊 UX，并可能导致去中心化交易所用户的点差更小。
• 构建者和中继避免了不必要的延迟障碍。两者都是对延迟高度敏感的行为者。我们希望最大限度地降低成为中继或验证者的复杂性。从区块验证的关键路径中移除 stateRoot 延迟意味着他们将不再需要担心优化它，从而提高区块生产流程的健康状况和效率。

潜在的缺点和担忧

受影响的应用程序

1. 轻客户端和 SPV 客户端

• 影响：这些客户端依赖于最新的 stateRoot 来验证交易和账户余额，而无需下载整个区块链。一个区块的延迟会在访问最新的状态信息时引入延迟。跨链通信协议（如利用轻客户端的桥）也会遇到这种延迟。
  • 考虑因素：我们认为轻客户端延迟一个区块没有明显的问题。

2. 无状态客户端协议

• 影响：无状态客户端依赖于最新的 stateRoot 来验证交易见证。一个区块的延迟可能会影响即时交易验证。
  • 考虑因素：如果这些客户端可以容忍一个区块的延迟，那么影响可能是最小的。这与无状态路线图中正在进行的讨论相一致。

基本原理

为什么选择这种方法？

• 效率：从关键路径中移除 stateRoot 计算可以显著减少区块验证时间。
• 简单性：就协议修改而言，这种改变是直接的，只影响 stateRoot 引用的位置。这与现有的区块生产流程（即原生构建和 MEV-Boost）向后兼容。其他包括执行流水线处理的提案，如 ePBS，在范围和复杂性上要广泛得多。延迟 stateRoot 是我们可以做出的一种更简单的改变，它可以立即带来好处，而且风险很小。
• 最小的干扰：虽然某些应用程序可能会受到影响，但我们认为大多数（全部？）都可以容忍一个区块的延迟，而不会出现重大问题。我们应该收集应用程序开发人员的反馈来验证这一点。

向后兼容性和过渡

• 硬分叉要求：此更改不向后兼容，需要网络硬分叉。
• 应用适配：受影响的应用程序（轻客户端、Layer2解决方案、无状态客户端）可能需要调整其协议或实现。

征求反馈

我们邀请社区就本提案提供反馈，特别是：

• 可行性：是否存在可能阻碍此变更实施的技术挑战？
• 好处：通过流水线处理 stateRoot 计算并将时间重新分配给执行，我们能够榨取多少吞吐量？
• 受影响的应用程序：我们没有明显看到任何会受到影响的广泛使用的应用程序类别。我们希望任何其应用程序依赖于同区块 stateRoot 的开发人员告知我们。

后续步骤

我们计划将此提案正式化为 EIP，以便可能包含在 Pectra B 中。

致谢

感谢 Dan Robinson、Frankie、Robert Miller 和 Roman Krasiuk 对本提案的反馈和意见。

• Native rollups—superpowers from L1 execution

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