- 以太坊正在过渡到权益证明！ 这种过渡称为“合并”，必须首先在信标链上通过 Bellatrix 升级启动。 然后，工作量证明链将会在达到特定的 Total Difficulty 值时迁移到权益证明。
- Bellatrix 在信标链上的升级安排在时段 144896 进行 -- 2022 年 9 月 6 日上午 11:34:47（协调世界时）。
- 触发合并的 Terminal Total Difficulty 值为 58750000000000000000000，预计在 2022 年 9 月 10-20 日之间达到。
- 注意：正如早些时候宣布的那样，Kiln 测试网即将废止。 运营商将于 2022 年 9 月 6 日关闭。
背景
经过多年的努力，以太坊权益证明升级最终启动了！ 所有公共测试网现已全部成功升级，以太坊主网合并已在计划中。
合并与以往网络升级的区别体现在两个方面。 首先，节点运营商需要依次升级他们的共识层 (CL) 和执行层 (EL) 客户端，而非仅升级两者之一。 其次，升级分两个阶段启动：第一个阶段名为 Bellatrix，在信标链上达到某个时段高度时开始；第二个阶段名为 Paris，在执行层达到某个 Total Difficulty 值时开始。
升级信息
时间安排
合并分两个步骤进行。 首先是共识层网络升级 Bellatrix，由时段高度触发。 然后是执行层从工作量证明过渡到权益证明的 Paris 升级，由特定的 Total Difficulty 阈值触发，即 Terminal Total Difficulty (TTD)。
Bellatrix 在信标链上的升级安排在时段 144896 进行 -- 2022 年 9 月 6 日上午 11:34:47（协调世界时）。
Paris 为执行层部分的过渡，将在 Terminal Total Difficulty (TTD) 达到 58750000000000000000000 时触发，预计时间为 Sept 10-20, 2022 之间。 达到 TTD 的确切日期取决于工作量证明哈希率。 有关过渡的预估，请参阅 bordel.wtf 和 797.io/themerge。
在执行层达到或超过 TTD 后，后面的区块将由信标链验证者生成。 一旦信标链最终确定此区块，合并过渡即视为已完成。 在正常网络状况下，此过程应在生成第一个 TTD 后区块之后 2 个时段或（大约 13 分钟）发生！
新 JSON-RPC 区块标签 finalized 将返回最新确定的区块，如果不存在此类合并后区块，则会返回错误。 此标签可由应用程序使用，以检查合并是否已完成。 同样，智能合约可以查询 DIFFICULTY 操作码 (0x44) 以确定合并是否发生，该操作码合并后重命名为 PREVRANDAO。 除了监控最终确定状态以外，我们还建议基础设施提供商监控整体网络稳定性。
客户端版本
以下客户端版本支持以太坊主网上的合并。 节点运营商必须同时运行执行层和共识层客户端，确保在合并期间及合并后一直在线。
在选择要运行哪种客户端时，验证者应尤其注意在执行层和共识层上运行主流客户端引发的风险。 可以点击此处以了解关于这些风险及其影响的详细说明。 有关对于执行层和共识层客户端分布现状的估计以及客户端切换指南，请查看此处。
共识层
执行层
警告：geth v1.10.22 版本存在重大数据库问题，不要使用该版本。如果你已经升级，请尽快升级到 v1.10.23 版本。
升级规范
针对合并的共识关键变更在下面两个位置详细说明：
- 共识层变更，位于共识规范存储库的 Bellatrix 目录下
- 执行层变更，位于执行规范存储库的 Paris 规范下
除此之外，还有两套规范涉及到共识层和执行层客户端的交互方式：
- 引擎应用程序接口，在执行应用程序接口存储库中详细说明，用于实现共识层和执行层之间的通信
- 乐观同步，在共识规范存储库的 sync 文件夹下详细说明，由共识层用于在执行层客户端同步时导入区块，并按前后顺序提供区块链头部的部分视图
合并相关漏洞奖励
从现在起到 9 月 8 日，所有与合并有关的漏洞奖励都可以扩大 4 倍。 重大漏洞的奖励现在高达 100 万美元。
更多详情请参阅漏洞奖励计划。
常见问题
作为节点运营商，我应该做什么？
合并后，以太坊全节点将共识层 (CL) 客户端与执行层 (EL) 客户端合二为一。前者运行权益证明信标链，后者管理用户状态并运行与交易相关的计算。 执行层客户端和共识层客户端使用一套新的 JSON RPC 方法，即引擎应用程序接口，通过经过身份验证的端口进行通信。 此外，执行层和共识层客户端使用 JSON Web 令牌 (JWT) 密钥相互进行身份验证。 因此，节点运营商应参考客户端文档，了解如何生成和配置该值。
换句话说，如果你已经在信标链上运行了一个节点，现在还需要运行执行层客户端。 同样，如果你在当前的工作量证明网络上运行一个节点，还需要运行共识层客户端。 为使两个客户端之间安全通信，必须将 JSON Web 令牌 (JWT) 密钥传送至每个客户端。 ethereum.org 网站的“运行节点”部分的更新更加详细地讨论了这些步骤。
值得强调的是，虽然信标节点和验证者客户端都是共识层客户端版本的一部分，但它们的运行却存在差异。 质押人必须运行两者，但节点运营商仅需运行信标节点。 本文更加深入地解释了两者之间的差异。
另请注意，每一层都会维护一组独立的对等节点，并公开自己的应用程序接口。 信标 API 和 JSON RPC API 都将继续按预期运行。
作为质押人，我需要做什么？
如前所述，在合并后，**除了共识层客户端以外，信标链上的验证者还需要运行执行层客户端。**虽然强烈建议在合并前也这么做，但一些验证者将这些功能外包给第三方提供商执行。 由于执行层所需的唯一数据是对存款合约的更新，因此可以实现外包。
在合并后，验证者必须确保他们创建并证明的用户交易及状态过渡区块有效。 为此，每个信标节点必须与一个执行层客户端配对。 请注意，多个验证者仍可与一个信标节点和执行层客户端组合配对。 这增加了验证者的责任，但也使提出区块的验证者有权获得相关交易优先费（该费用目前由矿工获得）。
虽然验证者奖励仍会在信标链上累积，且需要后续网络升级才能提取，但交易费的支付、销毁和分发将在执行层执行。 验证者可将任何以太坊地址指定为交易费的接收者。
**更新完共识层客户端之后，务必将 fee recipient 设为验证者客户端配置的一部分，以确保交易费发送至由你控制的地址。**如果你通过第三方提供商进行质押，则由你选定的提供商指定如何分配这些费用。
质押启动板有一张合并准备情况检查清单，质押人可用它确保完成了合并的每个步骤。 EthStaker 还主持了验证者准备工作研讨会，并在这期间计划了更多事宜。
对于想要在测试网上运行验证者以便为主网权益证明过渡做好准备的质押人，也可以在 Goerli（现已与 Prater 合并）上这样操作，后者还有质押启动板实例。
为什么 Terminal Total Difficulty 的预估日期如此宽泛？
每个区块增加的难度增量取决于网络哈希率，该值不稳定。 如果更高的哈希率加入网络，则将更快地达到 TTD。 同样，如果哈希率离开网络，则达到 TTD 的时间更晚。 当哈希率水平显著下降时，可以协调 TTD Override，就像在 Ropsten 上所做的那样。
作为应用程序或工具开发者，我应该做什么？
如前一篇文章所述，合并仅会对以太坊上部署的一小部分合约产生极小的影响。这些合约均不会遭到中断。 此外，大部分用户的应用程序接口端点保持稳定（除非使用特定的工作量证明方法，如 eth_getWork）。
尽管如此，以太坊上的大多数应用程序涉及的远不止链上合约。 就是现在，需要确保你的前端代码、工具、部署管道和其他链下组件能够按预期工作。 我们强烈建议开发者在 Sepolia 或 Goerli 上运行完整的测试和部署过程，并向项目维护者报告任何与工具或依赖项相关的问题。 如果你不确定在哪里提出问题，请使用此存储库。
还请注意，除 Sepolia 和 Goerli 以外，所有测试网都将在合并后弃用。 因此，如果你是 Ropsten、Rinkeby 或 Kiln 的用户，应该计划迁移至 Goerli 或 Sepolia。 如需深入了解相关信息，请点击此处。
作为以太坊用户或以太币持有者，我是否需要做点什么？
无论你是在链上使用以太坊应用程序还是在交易所或自已保管的钱包中持有以太币，都没有任何需要去做的事。 如果你使用的应用程序、交易所或钱包提供了附加说明或建议，则应验证这些建议确实来自它们。 当心诈骗！
作为矿工，我是否需要做点什么？
不需要。 如果你在以太坊主网上挖矿，就应该了解在合并后，网络将完全采用权益证明运营。 届时，网络上将不再支持挖矿。
如果我是矿工或节点运营商，并且我不参与升级，会发生什么情况？
如果你使用的以太坊客户端未更新到最新版本（上文已列出），则在升级发生时你的客户端将同步到分叉前区块链。
你将被卡住在遵循旧规则的不兼容链中，并且无法发送以太币或在合并后的以太坊网络上运行。
作为验证者，我能否撤销质押？
不能。 合并是以太坊迄今为止最为复杂的升级。 为将网络中断的风险降至最低，我们采取了最精简的方法，即在本次升级中摒弃了一切与过渡无关的变更。
从信标链撤销质押这一功能很可能会在合并后的第一次升级中实现。 共识层和执行层的相关规范均在制定中。
我还有其他问题，可以在哪里提问？
和客户端团队开发者、ETHStaker 成员、研究人员等一起参加下一次合并社区会议，时间 9 月 9 日星期五 14:00（协调世界时）！
非常感谢
以太坊向权益证明的过渡姗姗来迟。 感谢为研究、具体化、开发、分析、测试、中断、修复或解释做出贡献的每一个人，是他们促使我们实施合并。
多年以来涌现出的贡献者太多，无法在此一一列举，但大家都心知肚明。 没有大家的襄助，我们就无法建成这座圣殿。
何时合并？ 非常 🔜。
感谢 Joseph Schweitzer 和 Tomo Saito 为此帖子提供封面图片！