以太坊向 PoS 的过渡——合并——即将到来：devnets (开发网络) 正在被建立起来，规范正在被敲定，向社区拓展也已经正式开始。合并被设计为对以太坊终端用户、智能合约和 dapps 的影响最小化。尽管如此，还是有一些细微的变化值得强调。在我们深入研究这些变化之前，这里有一些链接提供关于整体合并架构的概述：
以太坊路线图的演变：
https://tim.mirror.xyz/CHQtTJb1NDxCK41JpULL-zAJe7YOtw-m4UDw6KDju6c
合并之后的客户端架构：
https://tim.mirror.xyz/CHQtTJb1NDxCK41JpULL-zAJe7YOtw-m4UDw6KDju6c
本文的其余部分将假设读者熟悉上述内容。如果你想要更深入地了解合并的完整规范，可参阅：
执行层：
https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/merge.md
共识层：
https://github.com/ethereum/consensus-specs/tree/dev/specs/merge
引擎 API：
https://github.com/ethereum/execution-apis/tree/main/src/engine
区块结构
在合并之后，PoW 区块将不再存在于以太坊网络上。相反，此前的 PoW 内容将成为信标链上创建的区块的一部分。届时你可以将信标链视为以太坊新的 PoS 共识层，取代之前的 PoW 共识层。信标链区块将包含ExecutionPayloads, 这是当前 PoW 链的区块在合并之后的等价物。下图展示了这种关系：
对于终端用户和应用开发者而言，这些ExecutionPayloads是与以太坊发生交互的地方。在这一层上面的交易将依旧被执行层客户端 (Besu、Erigon、Geth、Nethermind 等) 处理。幸运的是，由于执行层的稳定性，合并只会引入最小的破坏性更改。
挖矿 & Ommer 区块字段
合并后，之前包含在 PoW 区块头中的几个字段将不再使用，因为它们与 PoS 无关。为了尽量减少对工具和基础设施的破坏，这些字段被设置为 0，或者它们的数据结构的等效值，而不是从数据结构中完全删除。区块字段的全部变化可以在 EIP-3675 中找到：
https://eips.ethereum.org/EIPS/eip-3675#block-structure
由于 PoS 不像 PoW 那样自然产生 ommers (又称叔块)，因此每个区块中的这些列表 (ommers) 将是空的，而该列表的哈希 (ommerHash) 将成为一个空列表的 RLP 编码哈希。类似地，由于difficulty 和nonce是 PoW 具有的特征，它们将被设置为 0，同时赋予它们字节大小值。
另一个与挖矿相关的字段mixHash将不会被设置为 0，而是将包含信标链的 RANDAO 值。下文将更加详细地对此进行阐述。
BLOCKHASH & DIFFICULTY 操作码变更
合并之后，BLOCKHASH 操作码将仍然可以使用，但鉴于它将不再通过 PoW 哈希过程缔造，因此此操作码提供的伪随机性将会弱得多。
与此相关，DIFFICULTY操作码(0x44) 将被更新并重命名为 RANDOM。合并后，此操作码将返回信标链提供的随机信标的输出 (output)。因此，与 BLOCKHASH 相比，这个操作码将成为应用程序开发者们使用的一个更强大的 (尽管仍然存在偏差的) 随机性来源。
RANDOM公开的值将存储在 ExecutionPayload 中，其中存储了与 PoW 计算相关的 mixHash 值值。该 payload 的mixHash 字段也将被重命名为random。
下方是 DIFFICULTY & RANDOM 操作码在合并前和合并后如何运作的图解：
在合并之前，我们看到 0x44 操作码会返回区块头的 difficulty 字段。合并之后，此操作码重命名为 RANDOM，并指向先前包含 mixHash 的区块头字段，现在存储来自信标链状态的 random 值。
此变更在 EIP-4399中正式提出，也为链上应用提供了一个评估合并是否发生的方式。EIP-4399:
https://eips.ethereum.org/EIPS/eip-4399
下方摘取自 EIP-4399：
此外，此 EIP 提议的更改将允许智能合约确定是否已经升级到 PoS。这可以通过分析DIFFICULTY 操作码的返回值来确定。如果该返回值大于
2**64，则表示交易正在 PoS 区块中被执行。
出块时间
合并将影响以太坊上的平均出块时间。目前，在 PoW 机制中，出块时间平均每~13秒，实际出块时间可能有相当大的变化。在 PoS 机制中，出块时间被精确到 12 秒，除非由于某个验证者离线或者因为没有及时提交区块而导致某个 slot 没有出块。但在实践中，这种情况只发生在不到 1% 的 slots 中。
这意味着 PoS 网络上的平均出块时间减少了约 1 秒。对于在计算中假定了某个特定的出块时间的智能合约，将需要考虑到这一点。
安全头部区块 & 被敲定区块
在 PoW 机制中，总是存在区块重组的可能性。应用程序通常会等待在新的头部区块 (head block) 之上挖出几个区块之后，才会将该这个区块视为不太可能从权威链中被移除，也即视该区块“被确认”(confirmed)。而在合并之后，我们有了“被敲定”(finalized) 和“安全的头部区块”(safe head block) 的概念。与 PoW 机制中“被确认”的区块相比，PoS 中的这些区块要更加可靠，但需要理解上的转变才能正确地使用。
“被敲定”的区块是指该区块被超过 2/3 的 PoS 验证者接受为规范 (权威) 的区块。如果攻击者想要创建一个与之相冲突的区块，那么攻击者将必须销毁 ETH 总质押量的 1/3。截至撰文时，这意味着超过价值 100 亿美元 (或超过 250 万枚) 的ETH。
安全头部区块 (safe head block) 是指在正常的网络条件下，我们期望被纳入权威链中的区块。假设网络延迟小于 4 秒，且大多数验证者都是诚实的，同时没有对分叉选择规则的攻击，那么安全头部区块就永远不会成为孤块。下方链接是一个详细介绍在各种情况下如何计算安全头部区块，此外我们将在之后发表的文章中对安全头部区块的假设和保证进行正式定义和分析：
https://docs.google.com/presentation/d/1MUVaFyd9ce3hPQ5L-UhqVSfxf1ajMYFbkActkp5xNKI/edit#slide=id.gf1d0105ca5_0_147
合并之后，执行层 API (例如 JSON RPC) 将在被要求提供 latest(最新) 区块时默认返回安全头部区块。在正常的网络条件下，安全头部区块和区块链的顶端将是等同的 (安全头部区块会落后几秒钟)。与当前 PoW 的 latest (最新) 区块相比， PoS 中的安全头部区块将更不可能被重组。为了显露出 PoS 链的实际顶端，将向 JSON RPC 添加一个 unsafe 标志。
被敲定的区块也将通过 JASON RPC 的一个全新的 finalized(被敲定) 标志来显露出来。这些可以作为 PoW 确认的一个强大的替代方式。下表对此进行了总结：
后续行动
我们希望这篇文章能帮助应用程序开发者为期待已久的 PoS 过渡做好准备。在接下来的几周内，一个长期存在的合并测试网将被更广泛的社区用于测试。还有一场即将到来的有关合并的社区电话会议，让基础设施、工具和应用程序的开发者们抛出问题，并听取关于合并的最新技术更新。我们不见不散??：
感谢 Mikhail Kalinin 提供了本文“安全头部区块”部分的核心内容，感谢 Danny Ryan 和 Matt Garnett 审阅了本文的草稿。
撰文：Tim Beiko
编辑：南风
