engine_getPayload (引擎获取数据）请求执行层返回它的最佳 ExecutionPayload，它的构建过程已在之前对 engine_forkChoiceUpdated 的相关调用时启动了。

　　这就是当验证者必须出块时，它从它的执行引擎获取一个有效区块的方式。其他节点在从 p2p 层接收到该区块后将调用 engine_executePayload 来评估其有效性。

　　......就是这样！有了这三个新的端点，共识层和执行层可以就链的状态和交易数据进行通信。现在，让我们深入了解执行引擎的工作原理。

　　执行引擎？

　　如上文所述，执行引擎就是合并后的 Eth1 客户端。在这点上，任何与共识相关的内容都从它们的权限中移除了。它们的主要重点变成状态管理、区块构建和验证，这些都稍有修改。大部分的修改都写在了 EIP-3675。

　　第一，合并将需要对区块格式进行一些修改。有些仅与 PoW 而非 PoS 相关的栏位会被设为 0 (或它们的数据结构的等同物)。这些栏位不是与挖矿 (difficulty, mixHash, nonce) 就是与 ommers (ommers, ommersHash) 有关，它们在 PoS 上都是不存在的。主网上 extraData 的长度也将被限制在 32 个字节上。

　　第二，由于合并后代币增发仅会在信标链上发生，执行层将不再处理区块和叔块奖励。也就是说。执行引擎将仍然负责处理交易费。事实上，当它创建 ExecutionPayload 时，执行引擎会确保所有交易发送者至少可以支付当前的 baseFeePerGas (每单位gas 的基本费用)，且任何额外费用都会被发送到 feeReceipient (费用接收者)。请注意，feeReceipient 指的是“传统”的以太坊地址，而不是信标链验证者。

　　第三，当 PoS 取代了 PoW，执行引擎将不再广播区块。这意味着将弃用在 p2p 网络上的 NewBlockHashes (0x01) 和 NewBlock (0x07) 的处理程序。同样，执行层将仍然负责同步网络状态，广播交易和维持它的交易池。

　　下图同样由 Danny Ryan 制作，它展示了当合并发生时执行层弃用 PoW 转而依赖信标链的过程。

　　PoW 区块不再生成，而信标链区块在合并后开始包含 ExecutionPayloads。

　　PoW 区块不再生成，而信标链区块在合并后开始包含 ExecutionPayloads。

　　我们现在已经介绍了客户端如何处理区块以及合并后进行内部通信的核心组件了。现在，让我们简单谈谈系统的的各种相对“边缘”的组件。

　　P2P 网络、用户 API 和 同步？

　　如本文第一张图表所示，合并后，执行和信标链层都在 p2p 网络里。除了执行层上区块广播被弃用外，p2p 网络上的所有东西保持不变：在它们各自独立的 p2p 网络上，信标节点将广播证明、罚没等，而执行层将分享交易、同步状态等。 (责任编辑：admin)