以太坊过渡至权益证明 (PoS，proof of stake) 将至 – The Merge(合并)：目前 Devnet (开发者社群)已建立、规格也确立了，正迫不急待地与社群分享。The Merge(合并) ，是以对终端用户、智能合约与 dapp(去中心化应用) 最小化影响为设计。也就是说，只有些许次要的改变值得受到关注。

区块结构

在合并后，工作证明的区块将不再存在于网络上。取而代之的是，过往工作证明的内容，将成为 Beacon Chain 上创建区块的元件。你可以将 Beacon Chain 想成新的以太坊权益证明共识层，而它取代了先前的工作证明共识层。Beacon Chain 区块将包含 ExecutionPayloads，它等同于合并后在现在工作证明链上的区块。如下图表示：

对终端用户与应用开发者来说，这些 ExecutionPayloads 指的是与以太坊发生互动的地方。此层的交易仍会由执行层的客户端处理 (Besu, Erigon, Geth, Nethermind 等)。好处是，因为执行层的稳定，合并只会有极小的突破性改变。

挖矿与 Ommer 区块字段

合并后，许多字段包含工作证明的区块头 (block header)，将因为与权益证明无关而被弃用。为了减少工具与基础建设的伤害，这些字段将被设为 0，或是其资料架构的同质物，而不会接将其从资料架构完全移除。

因为权益证明不会像工作证明一样自然产生 Ommers (也就是「叔块」uncle block)，每个区块中的这些列表 (ommers) 会是空值 (empty)，而这个列表的 hash (ommers hash) 将会变成一组空值列表的 RLP (Recursive Length Prefix) 编码 hash。相同地，因为难度 (difficulty) 与 nonce 是工作证明的主要特点，这些也会被设为 0，以位元组的值显示。

mixHash，是另一个与挖矿有关的字段，但不会被设为 0，而是含有 beacon chain 的 RANDAO 值。更多内容如下。

BLOCKHASH 与 DIFFICULTY 操作码改变

合并后，BLOCKHASH 的操作码还是可以使用，但因为不再有工作证明的杂凑过程，这个操作码所提供的伪随机性将会大幅削弱。

还有，DIFFICULTY 操作码 (0x44) 将会更新，并重命名为 RANDOM。合并后，它将传回由 beacon chain 所提供的随机 beacon 输出值。比起 BLOCKHASH，这个操作码对于应用开发者来说，会是更强大 (尽管这是主观意见) 的随机来源。

由 RANDOM 产出的值会被处存在 ExecutionPayloadwhere，也就是之前 mixHash (与工作证明计算有关的值) 的储存位置。payload 的 mixHash 字段也会被重新命名为 random。

下图是 DIFFICULTY 跟 RANDOM 两操作码在合并前与合并后的运作方式：

合并前，我们看到 0x44 操作码传回区块头中的 difficulty 的字段。合并后，原先指向先前包含 mixHash 头字段的操作码，会重新命名为 RANDOM，负责储存来自 beacon chain 状态的 random 值。

这项改变，是在EIP-4399中拟定，它提供链上应用去评定合并是否已经发生。根据该 EIP：

而且，由这项改进建议所提出的改变，可以让智能合约判别 PoS 升级是否已经发生。这是透过分析 DIFFICULTY 操作码传回的值所做到的。当值大于 2**64，就代表交易已经在 PoS 区块中执行了。

区块时间

合并将影响以太坊平均区块时间。目前在工作证明之下，平均出块时间大概是 13 秒，实际每次时间仍有差异。在权益证明下，出块会变成确切的每 12 秒一次，除非验证者离线获释他们没有及时提交区块，才会错过一个时段 (slot)。实际上，这样的情况在所有时段中是小于 1% 的。

这表示，整体网络平均出块时间减少了约一秒。因此有设置特定平均区块时间的智能合约会需要考虑到这件事。

安全头块与最终块

在工作证明之下，都会有重组 (reorg) 可能。应用程式通常会等待新头块后的数个区块后，才会确认它不会从主链 (canonical chain) 上被移除，或是「区块确认」。在合并之后，我们不会有这些「最终化」(finalized) 与安全头块的概念。比起工作证明的「区块确认」这些区块可以更可靠地被使用，但也需要理解和适应，正确地被使用。

最终块 (finalized block) 是指被主链上大于三分之二的验证者接受。要创建与之冲突的区块，攻击者需要销毁至少三分之一的质押总数 (total stake)。截稿时，这相当于以太坊上超过 100 亿美元价值 (或大于 250 万个 ETH)。

安全头块 (safe head block) 是指，在正常网络状况下，我们预期它会被纳入主链。假设网络延迟少于四秒，有诚实多数的验证者，也没有人选择用分叉规则来攻击，安全头块将永远不会成为孤块 (orphaned)。可以在这边看到安全头块在多种情境下是如何被计算的。而且，这些安全头块假设与保证已在即将出炉的报告中正式的被定义与解析。

合并后，执行层的 API (像是 JSON RPC) 会在要求最新区块时，预设将安全头块传回。在正常的网络状态下，安全头块与实际的最新链会是相同的 (基于安全头块只需几秒就跟上)。比起现在的工作证明最新区块，安全头块将不太可能被区块重组。为了显示权益证明链上的实际最新状态，JSON RPC 会增添 unsafe 标示。

下一步

我们希望这篇文章能够帮助应用开发者做好准备，迎接众所期待的权益证明过渡。未来几周，存在已久的测试网将会给更广大的社群测试。也会有支持合并的社群，透过电话会议向基础设施、工具与应用开发者提问，了解最新合并的最新技术更新。期待与你相见。