Ethereum-Optimism项目中的ExecutionPayloadEnvelope.RequestsHash实现分析

背景介绍

在Ethereum-Optimism项目中，ExecutionPayloadEnvelope结构体用于表示执行负载的封装，其中包含一个名为RequestsHash的字段。这个字段最初是为了支持网络升级而引入的，但经过技术分析发现其实际实现与预期存在差异。

技术细节分析

RequestsHash字段的现状

在当前的实现中，RequestsHash字段被包含在ExecutionPayloadEnvelope结构体中，主要用于以下场景：

1. 排序器(sequencer)签名验证
2. 引擎API交互
3. 区块哈希重构

然而，经过深入分析发现，尽管该字段存在于结构体定义中，但在实际的区块链主网实现中，特别是在网络升级后的版本中，并没有直接编码RequestsHash字段。相反，主网实现采用的是请求列表(Requests List)的方式，而非其哈希值。

实现差异带来的问题

这种实现差异可能导致以下潜在问题：

1. 签名兼容性问题：虽然当前实现中RequestsHash未被编码，因此不影响签名过程，但字段的存在可能导致未来兼容性问题。

2. 区块重构逻辑不一致：在区块重构过程中，主网实现是从请求列表重新计算哈希值，而Optimism实现中直接使用了RequestsHash字段。

3. 引擎API交互差异：当从引擎API获取负载时，返回的是请求列表而非其哈希值，这可能导致数据表示不一致。

解决方案建议

基于上述分析，建议采取以下优化措施：

1. 移除RequestsHash字段：与处理withdrawalsRoot的方式类似，由于RequestsHash本质上是常量值，没有必要将其包含在负载中。

2. 返回空请求列表：在负载封装中返回非nil的空请求列表即可满足需求，这与主网实现保持一致。

3. 保持签名兼容性：确保修改不会影响现有的签名验证机制。

技术实现考量

在实施上述修改时，需要考虑以下技术细节：

1. 向后兼容性：确保修改不会破坏现有客户端的行为。

2. 性能影响：评估从请求列表重新计算哈希值对性能的影响。

3. 测试覆盖：增加测试用例验证修改后的行为与主网实现的一致性。

总结

通过对Ethereum-Optimism项目中RequestsHash实现的分析，我们发现当前实现与主网存在不一致之处。这种不一致虽然目前没有造成直接影响，但从长期维护和兼容性角度考虑，建议采用与主网一致的实现方式，即移除RequestsHash字段并改为处理请求列表。这种修改将使代码更加简洁，同时减少未来潜在的兼容性问题。