以太坊向 POS（权益证明）的过渡——合并——已近在眼前：开发网正在建立，规范正在敲定，社区宣传也已紧锣密鼓展开。合并的目的是最小化对以太坊的终端用户、智能合约和 DApp 的运作方式产生影响，也就是说，有一些小变化值得强调。在我们深入了解它们之前，这里有几个链接，以提供关于整个合并架构的背景。
路线图的演变
合并后的客户架构
这篇文章的其余部分将假设读者对上述内容很熟悉。对于那些想更深入了解的人来说，可在此查阅 The Merge 的全部规格。
执行层
共识层
API 引擎
合并后，POW（工作证明）区块将不再存在于网络中，以前 POW 链的内容会成为信标链（Beacon Chain）上创建的区块的一部分。那么你可以认为 Beacon 链成为了以太坊 POS 链的（权益证明）共识层，取代了之前的工作证明共识层。信标链区块将包含 ExecutionPayloads，它是合并后当前工作证明链上的区块等价物。
下面的图片显示了这种关系。
对于终端用户和程序开发人员来说，这些 ExecutionPayloads 是与以太坊交互的地方。这一层的交易仍将由执行层客户端（Besu, Erigon, Geth, Nethermind 等）处理。幸运的是，由于执行层的稳定性，合并只带来了最小的破坏性。
合并后，以前包含在工作证明区块头中的几个字段变得不能使用，因为它们与 POS（权益证明）无关。为了尽量减少对工具和基础设施的干扰，这些字段被设置为 0，或其数据结构的等价物，而不是完全从数据结构中删除。关于区块字段的修改详细内容可以参考 EIP-3675。
由于 POS（权益证明）并不像 POW（工作证明）那样自然产生 omers（又称叔叔区块），每个区块中的这些列表（omers）将是空的，这个列表的哈希值（omersHash）将成为一个空列表的 RLP 编码哈希值。同样地，由于难度和 nonce 是 POW（工作证明）的特征，考虑到它们的字节大小值，它们都将被设置为 0。
mixHash，另一个与采矿有关的字段，不会被设置为 0，而是包含信标链的 RANDAO 值。
关于这方面的更多详细内容请看下面章节内容。
合并后，BLOCKHASH 操作码仍可使用，但鉴于它不再能被通过工作证明哈希计算过程来锻造，该操作码提供的伪随机性将大大减弱。
与此相关，DIFFICULTY 操作码（0x44）将被升级并更名为 RANDOM。合并后，它将返回由信标链提供的随机性信标的输出。因此，这个操作码将成为比 BLOCKHASH 更强大的（尽管仍有偏见）供应给程序开发人员使用的随机性来源。
RANDOM 暴露的值将被存储在 ExecutionPayload 中，其中 mixHash 是一个与工作证明计算相关的值。payload 的 mixHash 字段也将被重新命名为 random。
下面是一个关于 DIFFICULTY 和 RANDOM 操作码在合并前和合并后如何工作的说明。
合并前，我们看到 0x44 操作码返回块头中的 difficulty 字段。合并后，该操作码更名为 RANDOM，指向之前包含 mixHash 的块头字段，现在存储来自信标链状态的 random 值。
在 EIP-4399 中正式确定的这一变化，也为链上应用提供了一种评估合并是否已经发生的方法。
来自 EIP：
此外，本 EIP 提出的变化允许智能合约确定是否已经升级到 PoS。这可以通过分析 DIFFICULTY 操作码的返回值来完成，大于 2**64 的值表明交易正在 PoS 块中执行。
合并将影响以太坊的平均区块时间。目前在 POW（工作证明）下，平均每 13 秒就有一个区块进入（实际区块时间有一些差异），在 POS（权益证明）下，每 12 秒就有一个区块进入，除非是由于验证者离线或没有及时提交区块而错过了一个时间段。在实践中，这种情况只在<1% 的时段发生过。
这意味着网络上的平均区块时间将减少 1 秒，那些有计算一个特定的平均区块时间需求的智能合约将需要考虑这一点。
在 POW（工作证明）下，总是有可能出现重排的情况，应用程序通常会等待几个区块在一个新的头块（head）上被开采出来，然后再将其视为不太可能从公认链中删除，或 "确认"。在合并之后，我们反而有了 finalized（最终确定）的和 safe head（安全头块）的概念。这些区块甚至可以比 "确认 "的 POW（工作证明）区块更可靠地使用，但需要转变观念以正确使用。
一个最终确定的区块是被大于 2/3 的验证者接受为公认的区块，要创建一个冲突的区块，攻击者必须烧掉至少 1/3 的总权益（stake）。在写这篇文章的时候，这代表了以太坊上超过 100 亿美元（或大于 250 万 ETH）。
安全头块是指在正常的网络条件下，我们期望被包含在公认链中的块。假设网络延迟小于 4 秒，大多数验证者是诚实的，并且没有对分叉选择规则的攻击，安全头将永远不会成为孤儿。
这里有一份详细介绍在各种情况下如何计算安全头的报告。此外，在即将发表的论文中安全头块的假设和保证正在被正式定义和分析。
合并后，执行层 API（如 JSON RPC）在询问最新（latest）区块时，将默认返回安全头。在正常的网络条件下，安全头和链的实际顶端将是相等的（安全头块只落后几秒钟）。安全头将比当前 POW(工作证明) 的最新（latest）区块更不可能被重新挂起。为了暴露 POS（权益证明）链的实际顶端，一个不安全（unsafe）的标志将被添加到 JSON RPC 中。
最终确定区块 (finalized) 也将通过 JSON RPC，通过一个新的最终确定的标志被公开。然后，这些可以作为工作证明确认的一个更有力的替代品。
下表对此进行了总结。
我们希望这篇文章能帮助程序开发者为备受期待的向 POS（权益证明）阶段的过渡做好准备。
在接下来的几周里，一个长期存在的测试网将被提供给更广泛的社区进行测试，还有一个即将举行的关于基础设施、工具和应用程序开发人员提问的合并社区电话会议，并听取关于合并的最新技术更新。
原文标题：《 How The Merge Impacts Ethereum’s Application Layer 》
原文作者：以太坊开发者、以太坊基金会社区经理 Tim Beiko
原文编译：RexHuang7
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。