EIP-7898: 将执行负载与信标块分离
将执行负载与信标块分离，以便独立传输它们
| Authors | Gajinder Singh (@g11tech) |
|---|---|
| Created | 2025-03-01 |
| Discussion Link | https://ethereum-magicians.org/t/uncouple-execution-payload-from-beacon-block/23029 |
摘要
目前，以太坊共识中的信标块将交易嵌入到 BeaconBlockBody 的 ExecutionPayload 字段中。本 EIP 提议用 BeaconBlockBody 中的 ExecutionPayloadHeader 替换 ExecutionPayload，并独立传输 ExecutionPayloadWithInclusionProof。
然而，除了区块可用性现在包括等待 ExecutionPayloadWithInclusionProof 的可用性之外，此 EIP 不会对区块导入机制进行任何更改，这使得它与 ePBS/APS 等提案不同且更简单。
但实际上，这种可用性要求可以限制在 gossip 导入，同时允许执行层 (EL) 在检查点/范围同步上进行乐观同步，因为 EL 可以像现在一样从其对等方拉取完整区块以进行乐观同步。
动机
以太坊协议有一个雄心勃勃的目标，即增加执行负载的 gasLimit（可能增加 10 倍）。这会导致更大的消息，对共识层 (CL) 客户端的网络和区块处理管道产生负面影响，从而导致以下问题：
- 信标块到达的延迟增加，需要提供更大的带宽资源供信标节点使用。
- 更多的交易数量和更大的交易规模直接增加了 merkelization 的计算时间，从而增加了区块的导入时间。
我们从时间游戏中了解到，区块导入延迟极大地影响了客户端做出正确头部证明的性能。 通过此 EIP，区块传输和区块导入过程将得到缓解，从而可以更灵活地接收更大的 ExecutionPayloadWithInclusionProof，同时信标块可以同时进行处理。
此外，EL 客户端还可以独立参与转发和接收更大的执行区块。 然而，该机制可以独立开发，不属于本 EIP 的范围。
从此 EIP 获得的额外好处：
- 共识客户端无需存储和提供包含交易的区块，从而为运行信标节点提供更高的效率并减少资源需求。
- 通过提议者将签名区块直接传输到 p2p 网络，同时提交给构建者/中继以独立显示
ExecutionPayloadWithInclusionProof，提议者-构建者分离 (PBS) 管道变得更加高效。 - 未来，通过对 EL 区块执行进行零知识 (ZK) 证明，节点可以像处理 blobs 一样处理交易，利用数据可用性采样 (DAS) 机制来获取可用数据，而无需重新执行交易来建立有效性。 因此，L1 执行本身可以通过减轻节点导入所有交易数据的需求而成为 rollup。
此外，由于将盲版本和完整版本（如 BlindedBeaconBlock、BlindedBeaconBlockBody）合并到同一类型中，CL 客户端的 API 和代码路径将变得更简洁且更易于维护。
规范
BeaconBlockBody中的ExecutionPayload被ExecutionPayloadHeader替换ExecutionPayloadWithInclusionProof由区块提议者/构建者计算，并在单独的新主题上独立 gossip。 此外，构建器的submitBlindedBlockAPI 被修改为返回ExecutionPayloadWithInclusionProof。- 现在，将区块导入到 forkchoice 中的数据可用性检查必须等待相应的
ExecutionPayloadWithInclusionProof的可用性，但仅适用于 gossiped 区块 - 引入了
newPayloadHeader引擎 API，以增强之前在区块处理中使用newPayload的方式，例如，在处理范围同步区块时，当ExecutionPayload不可用时，指示 EL 客户端从 EL p2p 网络乐观地同步这些负载。
EL 可以选择引入 getExecutionPayload 方法（类似于 getBlobs），以帮助从 EL 的 p2p 网络对等方更快地恢复执行负载，这些对等方可以在看到新的 VALID 负载时宣布新的负载哈希。 然而，如上所述，该机制可以独立指定，不属于本 EIP 的范围。
<– TODO: 添加规范细节 –>
理由
我们还可以选择使用 SignedExecutionPayload 而不是 ExecutionPayloadWithInclusionProof，并使用 SignedExecutionPayloadHeader，让构建者签署这些消息（在本地区块构建中，验证者是构建者）。 但是，如果没有构建者强化，对 SignedExecutionPayload 进行严格的 gossip 验证将成为一个问题，并且可能成为 DOS 向量。
SignedExecutionPayload 设计的好处是，它可以先于甚至 SignedExecutionPayloadHeader 包含在信标块中进行传输，并且在 PBS 管道中特别有用，因为它可以显着减少提议者到构建者/中继的延迟。
向后兼容性
此更改不向后兼容，需要新的硬分叉来激活此 EIP。
测试用例
<– TODO –>
参考实现
<– TODO –>
安全考虑
<– TODO –>
需要讨论。
版权
版权及相关权利通过 CC0 放弃。
Citation
Please cite this document as:
Gajinder Singh (@g11tech), "EIP-7898: 将执行负载与信标块分离 [DRAFT]," Ethereum Improvement Proposals, no. 7898, March 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7898.