以太坊PoW和PoS合并The Merge在即 应用层会受到哪些影响？

以太坊网络向权益证明的过渡（The Merge）即将到来：目前开发网络正在建立，规范也进入最终确定，社区外展准备工作已经认真开始。The Merge旨在过渡过程中对最终用户、智能合约和 dapps 的运作方式产生最小的影响。也就是说，在这个过程中，有一些小的变化值得强调。在我们深入研究这些变化之前，下面有一些链接可以提供有关The Merge 整体架构的一些了解：

路线图演变‌

合并后客户端架构‌

本文的其余部分将假设读者熟悉上述内容。对于那些想要更深入挖掘的人，下面可获得 The Merge 的完整规范：

执行层‌

共识层‌

引擎API‌

区块结构

以太坊合并之后，网络上将不再存在工作量证明（PoW）。相反，以前的PoW部分将成为信标链（Beacon Chain）上创建的区块的组成部分。然后，您可以将信标链视为以太坊新的PoS共识层，取代之前的PoW共识层。信标链区块将包含 ExecutionPayloads，这是当前PoW链上区块的合并后等价物。下图显示了这种关系：

对于最终用户和应用开发人员来说，这些 ExecutionPayloads 是与以太坊进行交互的地方。该层上的交易仍将由执行层客户端（Besu、Erigon、Geth、Nethermind 等）处理。幸运的是，由于执行层的稳定性，The Merge 只引入了最少的破坏性更改。

挖矿和Ommer区块字段

合并后，之前包含在PoW区块头中的几个字段不再使用，因为它们与PoS无关。为了最大限度地减少对工具和基础设施的破坏，这些字段被设置为 0，或者它们的数据结构的等效项，而不是从数据结构中完全删除。你可以在 EIP-3675 中找到对区块字段的完整更改内容。

因为PoS不会像PoW那样自然产生 ommers（又名叔块），所以每个叔块（ommers）中的这些列表将为空，这个列表的哈希（ommersHash）将成为 RLP 编码哈希的一个空列表。同样，因为PoW还包含了难度和随机数，所以此后它们将被设置为 0，同时赋予它们字节大小值。

另一个与挖矿相关的字段 mixHash 不会设置为 0，而是包含信标链的 RANDAO 值。下文将会对此进行更多介绍。

BLOCKHASH & DIFFICULTY 操作码更改

合并后，BLOCKHASH 操作码仍可使用，但考虑到它不再通过PoW哈希程序伪造，此操作码提供的伪随机性将弱得多。

相关地，DIFFICULTY 操作码 (0x44) 将被更新并重命名为 RANDOM。合并后，它将返回信标链提供的随机信标的输出。因此，与 BLOCKHASH 相比，尽管仍然存在偏差，此操作码将成为应用程序开发人员使用的更强大的随机源。

RANDOM 公开的值将存储在 ExecutionPayload 中，其中存储了与PoW计算相关的值 mixHash。Payload 的 mixHash 字段也将被重命名为 random。

这是 DIFFICULTY & RANDOM 操作码在合并前和合并后如何工作的说明：

合并前，我们看到 0x44 操作码返回区块头中的难度字段。合并后，重命名为 RANDOM 的操作码指向先前包含 mixHash 的区块头字段，现在存储来自信标链状态的随机值。

这一变化在 EIP-4399 中得到正式化，也为链上应用程序提供了一种评估合并是否发生的方法。根据这个EIP的介绍：

此外，此 EIP 提出的更改允许智能合约确定是否已升级到 PoS。这可以通过分析 DIFFICULTY 操作码的返回值来完成。如果值大于 2**64 ，则表示交易正在 PoS 区块中执行。

出块时间

合并将影响以太坊的平均区块时间。目前在PoW下，平均每约 13 秒产出一个区块，实际区块间隔时间有相当大的差异。在权益证下，区块间隔将恰好为12 秒，除非由于验证者离线或因为他们没有及时提交区块而错过了某个时隙。在实践中，发生这种情况的插槽<1%。

这意味着网络上的平均出块时间减少了约 1 秒。在计算中假设特定平均区块时间的智能合约需要考虑到这一点。

安全头区块（safe head）和最终区块

在PoW下，区块重组在一直都可能出现。应用通常会等待在新头区块（safe head）上挖出几个区块，然后再将其视为该区块已不太可能从规范链中被删除，或已经得到“确认”。在合并之后，我们有了最终和安全的头部区块的概念。这些区块可以比“已确认”的PoW区块更可靠地使用，但需要改变理解才能正确使用。

最终确定的区块是指被超过 2/3 的验证者接受为规范的区块。要创建一个冲突区块，攻击者必须至少销毁ETH总质押数量的 1/3，在撰写本文时，这意味着超过 100 亿美元（或 >250 万枚）的ETH。

安全头区块（safe head）是指在正常网络条件下，我们希望包含在规范链中的区块。假设网络延迟小于 4 秒，大多数验证者都是诚实的，并且没有对分叉选择规则的攻击，那么safe head将永远不会成为孤儿块。此处提供了详细介绍如何在各种情况下计算safe head的演示文稿。此外，safe head的假设和保证将在即将发表的论文中得到正式定义和分析。

合并后，执行层 API（例如 JSON RPC）在要求提供最新区块时将默认返回安全头（safe head）。在正常的网络条件下，safe head和链的实际顶端将是等效的（安全头尾仅几秒钟）。与当前的PoW最新区块相比，safe head不太可能被重组。为了公开PoW链的实际提示，将向 JSON RPC 添加一个unsafe标志。

最终区块也将通过 JSON RPC 公开，通过一个新的finalized标志。然后，这些可以作为PoW证明的更强大的替代品。下表总结了这一点：

区块类型共识机制JSON RPC发生重组的条件headPoWlatest可以预料到，必须小心使用headPoSunsafe可以预料到，必须小心使用safe headPoSlatest可能发生，但需要大的网络延迟或对网络的攻击才能实现。confirmedPoWN/A不太可能发生，因为需要大部分算力来挖一个深度 > # 确认的竞争链。finalizedPoSfinalized极不可能发生，因为需要超过 2/3 的验证者来完成一个竞争链，需要至少 1/3 被削减。

下一步

我们希望这篇文章可以帮助应用程序开发人员为备受期待的PoS过渡做好准备。在接下来的几周内，有一个测试网将可供更广泛的社区进行测试。还有一个即将到来的 The Merge 社区呼吁基础设施、工具和应用程序开发人员提出问题并听取有关 The Merge 的最新技术更新。

-------------------------------------------------- ------------------------------

感谢 Mikhail Kalinin 提供“Safe Head”部分的核心内容，感谢 Danny Ryan 和 Matt Garnett 审阅这篇文章的草稿。

来源：以太坊官方博客

(https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/)

作者：以太坊开发者、以太坊基金会社区经理Tim Beiko