合并后的客户端架构。NFT 艺术家：Danny Ryan

　　上图展示了合并后一个完整的以太坊客户端的样子。让我们以此为起点，深入到每个组件。

　　信标节点？

　　现在，信标节点是对空区块 (从终端用户角度来看) 达成共识的。这些区块包括与共识相关的信息，称为操作 (Operations)，比如证明 (attestations)、存款合约根和验证者的罚没/退出，但不包括 Eth1 意义上的交易信息 (例如，发送 ETH 或与智能合约交互)。合并将改变这个情况。

　　在合并发生时，信标节点将监测当前的 PoW 链，并等待它触达预设定的 total difficulty (总难度) 阈值，被称为 TERMINAL_TOTAL_DIFFICULTY (终结总难度)。一旦出了一个区块的 total difficulty >= TERMINAL_TOTAL_DIFFICULTY，该区块将会被视为最后的 PoW 区块。随后的区块都开始由信标链上的验证者构建和证明。

　　要做到以上内容，信标节点将需要与它们的执行引擎 (以前的 Eth1 客户端) 通信，并请求它生成或验证 ExecutionPayloads (执行数据)。这些数据是 Eth1 区块合并后的等同物。它们包含这些信息：父块的哈希值 (parent's hash)、状态根 (state root)、基本费用 ( base fee)、需要执行交易列表。一旦这些信息都被生成或验证了，信标节点将在 p2p 网络与其他节点分享。

　　合并后的区块：共识层 (即信标节点) 验证所有现在属于信标链区块的栏位。当它在网络上收到 ExecutionPayloads 时，它会将其传送到执行层进行验证。

　　为了在共识层和执行层建立通信，会引入一组新的 JSON RPC 端点：Engine API (引擎应用程序接口)。

　　Engine API ⚙️

　　Engine API 是共识层和执行层间的通信接口。它不在执行层的公共 JSON RPC API，而在一个独立的端口。为了简单，对 API 的调用总是由共识层发起，而 API 只引入三个方法：engine_executePayload、 engine_forkchoiceUpdated 和 engine_getPayload。让我们逐个看看它们是做什么的：

　　engine_executePayload (引擎执行数据) 要求执行层验证 ExecutionPayload 是否符合所有协议规则。

　　在通过这个调用接收到数据后，执行层将返回 VALID/INVALID (有效/无效) 或，如果它还没同步完链头，则返回 SYNCING (同步中)。因为一个区块的有效性是取决于它的父块有效性的，如果执行层缺乏历史数据来评估数据的有效性，它将从网络上获取这些数据。

　　engine_forkchoiceUpdated (引擎分叉选择更新) 是共识层在网络上告知执行层新的链头和最终敲定的区块的方式。如果共识层需要执行层在最新的链头区块上生成一个新的 ExecutionPayload，它会和这个调用一起传送一个 payloadAttributes 栏位。

　　payloadAttributes 栏位包含与执行引擎生成一个 ExecutionPayload 的相关信息，特别是 timestamp (时间戳), random (乱数) 和 feeRecipient (相当于以前的 coinbase) 的值。在接收到这个调用时，执行层将更新它的链头，根据需要进行同步，以及，如果有需要的话，开始用 payloadAttributes 的数值构建一个 ExecutionPayload。 (责任编辑：admin)