全文精译版：以太坊主网合并公告

原用标题（译后）：以太坊主网合并公告

以太坊正在转向权益证明机制！这场称为“合并(TheMerge)”的共识机制过渡必须首先在信标链上激活Bellatrix升级。升级后，工作量证明机制的以太坊链将在触达特定的总难度值后过渡至权益证明机制。

Bellatrix升级计划在信标链的epoch144896——北京时间2022年9月6日19：34：47左右进行。

触发合并的TerminalTotalDifficulty值（终结总难度）58750000000000000000000，预计在2022年9月10至20日。

请注意：正如之前所宣布的(中文版《Ropsten、Rinkeby和Kiln测试网弃用公告》)，Klin测试网被弃用了，运行者将会在2022年9月6日将它关停。

背景

经过多年的努力，我们终于迎来了以太坊权益证明机制升级！所有公共测试网现已成功完成升级，以太坊主网合并的安排也已确定。

合并与之前的网络升级在两个方面有所不同。首先，节点运行者需要同步升级他们的共识层（CL）和执行层（EL）客户端，而不是仅升级其中一个；其次，升级活动有两个阶段：第一个阶段，称为Bellatrix升级，会在信标链的一个epoch高度被触发，而第二个阶段，称为Paris升级，在执行层触达TotalDifficulty值之后触发。

升级信息

时间

合并通过两步完成，第一步是Bellatrix网络升级，会在共识层的某个epoch高度被触发。随后是执行层从工作量证明机制向权益证明机制的过渡，即第二步Paris升级，由称作TerminalTotalDifficulty（终结总难度，TTD）的特定的总难度门槛触发。

Bellatrix升级预计在信标链的epoch144896，即UTC时间2022年9月6日11:34:47am。

Paris升级是执行层过渡的部分，将在TerminalTotalDifficulty(TTD)为58750000000000000000000时触发，预计在9月10-20日之间。准备触达的日期取决于工作量证明的算力。对于过渡的预测可以在bordel.wtf和797.io/themerge找到。

一旦执行层触达或者超过TTD，随后的区块将会由信标链的验证者生成。一旦信标链敲定这个区块，则视为完成合并。在正常的网络情况下，合并将会在TTD后生成的第一个区块的2个epoch（或者13分钟左右）后发生！

一个新的JSON-RPC区块标签finalized，会返回最新的敲定区块，或者如果不存在合并后的区块则会返回错误。这个标签可以被应用程序用来检查合并是否完成。同样地，智能合约可以请求DIFFICULTY操作码(0x44)（在合并后重命名为PREVRANDAO）来确定合并是否发生。我们建议基础设施提供商监控整个网络的稳定性还有最终确定状态。

客户端版本发布

以下客户端版本支持以太坊主网的合并。节点运行者必须在合并期间和合并后都运行执行层和共识层的客户端以保持在线。

在选择运行哪个客户端时，验证者必须尤其小心运行EL和CL上节点占比较大的客户端的风险。有关这些风险及其后果的解释文章可查看(https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html)。对于目前EL和CL客户端分布的预估以及从一个客户端转至另一个的指南则可以查看(https://clientdiversity.org/)。

共识层

执行层

警告：geth的v.1.10.22包含着一个重大的数据库问题，不要使用这个版本，如果你已经升级至该版本，请尽快升级至v.1.10.23。

升级规范

合并的共识关键变更在两个地方得到详细说明：

共识层变更，在共识规范仓库的bellatrix目录。
执行层变更，在执行规范仓库的Paris规范。

此外，另外两个规范涵盖了共识层和执行层客户端是如何交互的：

引擎API在execution-apisrepository里说明了，它用于共识层和执行层之间的通信

OptimisticSync在共识规范仓库的sync文件夹里说明了，它被共识层用于在执行层客户端同步时导入区块，并给执行层提供共识层链头的部分视域。

合并漏洞赏金奖励

从现在到9月8日，所有与合并相关的漏洞赏金都增长了4倍。关键性的漏洞的赏金高达100万美元。

更多具体信息请查看漏洞赏金计划。

常见问题解答

作为节点运行者，我应该做什么？

合并后，一个以太坊全节点将结合一个共识层客户端(运行PoS信标链)和一个执行层客户端(管理用户状态和运行与交易相关的计算)。它们通过一个已认证的端口进行通信(使用一套新的JSONRPC方法，称为引擎API)。执行层客户端和共识层客户端使用一个加密JWT来验证对方。节点运行者需要对照他们的客户端文档的指示，了解如何生成和配置这些信息。

换句话说，如果你已经在信标链上运行了一个节点，那么你现在还需运行一个执行层客户端。同样地，如果你在当前的PoW网络上运行着一个节点，那么你将需要运行一个共识层客户端。为了使它们能够安全地进行通信，必须向每个客户端传递一个JWT通证。ethereum.org网站的“运行一个节点”部分的升级更加详细地解释了这些。

值得强调的是，虽然信标链节点和验证者客户端都是共识层客户端的一部分，但是运行一个信标链节点和运行一个验证者客户端是不一样的。验证者必须运行两者，而节点运行者只需运行信标链节点。(https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-client-architecture/)更详细地解释了这两个组件之间的区别。

另外，请注意，共识层和执行层都会维护一个独立的对等点集，并公开它自己的API。Beacon和JSONRPC的API都将按预期继续工作。

作为质押者，我需要做什么？

如上所述，合并之后，信标链上的验证者除了运行他们的共识层客户端之外，还需要运行一个执行层客户端。我们强烈建议大家在合并前就这样做，但是验证者可以将这些功能外包给第三方提供商。这是有可能的，因为执行层需要的唯一数据就是对存款合约的更新。

合并后，验证者需要确保他们创建和证明的用户交易和状态转换区块是有效的。为了做到这一点，每一个信标节点必须与一个执行层的客户端配对。请注意，多个验证者仍然可以与一个信标节点和执行层客户端组合配对。虽然这增加了验证者的责任，但它也使得提议区块的验证者有权获得其相关交易的优先费(目前这笔费用由矿工获取)。

虽然验证者的奖励在信标链上累积，并且要在随后的网络升级才能提出来，但交易费将会继续在执行层支付、销毁以及分配。验证者可以指定任何以太坊地址作为交易费的接收者。

在更新你的共识层客户端之后，请确保在设置验证者客户端时设置了feerecipient(费用接收方)，以确保交易费用能够发送到你所控制的地址中。如果选择了第三方提供商来质押，由你选择的提供商来指定这些费用的分配方式。

StakingLaunchpad有一个合并准备检查清单，验证者可以用来确保他们已经完成了流程的每一步。EthStaker团队还举办了一次合并验证者准备工作坊，还有更多的计划。

希望在测试网上运行验证者节点，为主网PoS过渡做准备的质押者也可以在Goerli（现已与Prater合并）上这么做，Goerli也有一个StakingLaunchpad实例。

为什么对TerminalTotalDifficulty的预计时间跨度这么大？

每个区块增加的难度取决于波动的网络算力。如果网络中加入了更多的算力，TTD则会早点触达。同理，如果算力从网络中离开，TTD则将晚点触达。在算力水平大跌的事件中，可以协调TTDOverride(TTD覆盖)，就像Ropsten事件中所做的。

作为应用或工具开发商，我应该做什么？

合并只会对以太坊上部署的合约子集产生非常微弱的影响，应该不会破坏任何合约。此外，大部分用户的应用程序接口(API)端点仍将保持稳定（除非使用eth_getWork等工作量证明的特定方法）。

尽管如此，以太坊上的大多数应用程序涉及的远不止链上合约。现在您要确保前端代码、工具、部署管道和其他链下组件能够按预期运行。我们强烈建议开发者在Sepolia（或Goerli）上执行一个完整的测试和部署周期，并向这些项目的维护者报告任何工具或依赖项存在的问题。如果不确定在哪里提出问题，请使用此资源库。

此外，你需要注意的是，除了Sepolia和Goerli之外的所有测试网都会在合并后关停。如果你是Ropsten、Rinkeby或者Kiln测试网的用户，你应该计划迁移到Goerli或者Sepolia测试网。

作为以太坊用户或ETH持有者，我需要做什么？

不管你是使用链上以太坊应用，还是在交易所或自托管钱包中持有ETH，都不需要做任何事情。如果你使用的应用、交易所或者钱包提供了指示或是建议，那么你就需要验证这些指示和建议真的来自他们。小心骗局！

作为矿工，我需要做什么？

不需要。如果在以太坊主网上挖矿，你应该了解在合并后，每个网络将完全基于PoS权益证明机制运行。届时，以太坊网络上将没有可能再进行挖矿。

如果我是一名矿工或节点运行者，而我没有参与升级会怎么样？

如果你使用一个没有升级到最新版本（上面所列的）的以太坊客户端，你的客户端将会在主网升级发生后，同步到分叉前的区块链。

你会困在一条不兼容的链，遵循着旧的规范，也将无法发送ETH或在合并后的以太坊主网上运行。

作为验证者，我可以提出我的质押资产吗？

不能。合并是迄今为止以太坊最复杂的升级。为了最大限度减少网络中断的风险，我们采取了最小可行的方法，将所有与过渡无关的变更先放一边。

从信标链上提款的功能可能会在合并后的第一次升级中引入。共识层和执行层的规范在推动中。

我有更多问题，可以去哪里问？