以太坊基金会：以太坊主网合并公告

Unitimes view 59837 2022-8-25 15:22

以太坊正在转向权益证明 (PoS)！这次过渡被称为合并 (The Merge)，必须首先在信标链上通过 Bellatrix 升级来激活。之后，以太坊工作量证明 (PoW) 链将在达到特定的总难度值时迁移到权益证明 (PoS)。

根据计划，Bellatrix 升级将于 2022 年 9 月 6 日 UTC 时间 11:34:47 在信标链第 144896 个 epoch 时进行。

触发合并的终端总难度值为 58750000000000000000000，预计在 2022 年 9 月 10 日至 20 日之间。

注意：正如此前宣布的，Kiln 测试网即将弃用，运营商将在 2022 年 9 月 6 日关闭。

背景

经过多年的努力，以太坊的 PoS 升级终于要来了！所有公共测试网现已成功完成升级，而以太坊主网的合并升级也已经被安排完毕。

合并在两个方面不同于以往的网络升级。首先，节点运营商需要同时更新其共识层 (CL) 客户端和执行层 (EL) 客户端，而不仅仅是其中之一。第二，此次升级分两个阶段激活：第一阶段称为 Bellatrix，将在信标链上的某个 epoch 高度完成；第二阶段称为 Paris，将在执行层达到预定的总难度值时完成。

升级信息

以太坊基金会：以太坊主网合并公告

时间

合并分为两个步骤，第一步是在某个 epoch 高度时，在共识层触发的 Bellatrix 网络升级。随后，执行层从工作量证明 (PoW) 过渡到权益证明 (PoS)，这个步骤被称为 Paris，由一个称为终端总难度 (TTD) 的特定总难度值触发。

Bellatrix 升级计划于 2022 年 9 月 6 日 UTC 时间上午 11:34:47 在信标链高度达到 144896 时进行。

而执行层升级 Paris，将在 TTD 总难度值达到 58750000000000000000000 时触发，预计将在 2022 年 9 月 10 日 - 9 月 20 日之间。达到 TTD 的确切日期取决于工作量证明的算力情况，关于过渡时间的预计，你可以在 bordel.wtf[1]以及 797.io/themerge [2]找到。

一旦执行层达到或超过预定 TTD 值，信标链验证器将负责生成后续的区块。一旦信标链敲定了该区块，那么此次合并升级就被视为完成。在正常网络条件下，TDD 难度值达到之后生成的第一个区块，会在 2 个 epoch (约 13 分钟) 被敲定。

一个新的 JSON-RPC 区块标签 finalized，会返回最新的最终区块，或者如果不存在此类合并后区块，则会返回错误。应用程序可以使用此标签来检查合并是否已完成。同样，智能合约可以查询 DIFFICULTY 操作码‌ (0x44) [3] (在合并后重命名为 PREVRANDAO) 以确定合并是否发生。我们建议基础设施提供商除了监控最终状态外，还要监控整体网络的稳定性。

客户端版本

以下客户端版本支持以太坊主网的合并升级，注意，节点运营商必须同时运行执行层和共识层客户端，才能在合并期间和之后保持在网络上。

在选择运行哪个客户端时，验证者应该特别注意在 EL 和 CL 上运行多数客户端的风险。你可以在此处‌ [4] 找到这些风险及其后果的解释。你还可以在此处‌ [5] 找到执行层和共识层客户端分布的估计，以及从一个客户端切换到另一个客户端的指南。

1) 共识层客户端

客户端：Lighthouse

版本：v3.0.0

下载链接：

https://github.com/sigp/lighthouse/releases/tag/v3.0.0

客户端：Lodestar

版本：v1.0.0

下载链接：

https://github.com/ChainSafe/lodestar/releases/tag/v1.0.0

客户端：Nimbus

版本：v22.8.0

下载链接：

https://github.com/status-im/nimbus-eth2/releases/tag/v22.8.0

客户端：Prysm

版本：v3.0.0

下载链接：

https://github.com/prysmaticlabs/prysm/releases/tag/v3.0.0

客户端：Teku

版本：22.8.1

下载链接：

https://github.com/ConsenSys/teku/releases/tag/22.8.1

2) 执行层客户端

客户端：Besu

版本：22.7.1

下载链接：

https://github.com/hyperledger/besu/releases/tag/22.7.1

客户端：Erigon

版本：v2022.08.02-alpha

下载链接：

https://github.com/ledgerwatch/erigon/releases/tag/v2022.08.02

客户端：go-ethereum (geth)

版本：v1.10.23

下载链接：

https://github.com/ethereum/go-ethereum/releases/tag/v1.10.23

客户端：Nethermind

版本：v1.14.0

下载链接：

https://github.com/NethermindEth/nethermind/releases/tag/1.14.0

警告：geth v1.10.22 版本客户端包含严重的数据库问题，请勿使用此版本，如果你使用的是该版本的客户端，请尽快升级到 v1.10.23。

升级规范

合并的共识关键变更在两处指定：

共识层根据共识规范存储库的 Bellatrix 目录‌ [6] 发生变化。

执行层根据执行规范存储库中的 Paris 规范‌ [7] 发生变化。

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

在 execution-apis‌ [8] 存储库中指定的 Engine API 用于共识层和执行层之间的通信。

在共识规范存储库的 sync‌ [9]文件夹中指定的 Optimistic Sync，由共识层在执行层客户端同步时用于导入区块，并提供从前者到后者的链头部的部分视图。

合并漏洞赏金计划

从现在到 9 月 8 日的这段时间，所有与合并相关的漏洞奖励都会有 4 倍的乘数。严重的漏洞赏金最高可达 100 万美元。

有关更多详细信息，请参阅漏洞赏金计划‌:

https://bounty.ethereum.org/

FAQ

1. 作为节点运营商，我该怎么做？

合并后，以太坊全节点是共识层（CL）客户端和执行层（EL）客户端的组合，前者运行权益证明信标链，后者管理用户状态并运行与交易相关的计算。执行层（EL）和共识层（CL）客户端使用一组称为 Engine API‌ [10] 的新 JSON RPC 方法，通过经身份验证的端口进行通信。执行层（EL）和共识层（CL）客户端使用 JWT 密钥相互认证。有关如何生成和配置此值的说明，节点运营商应参考其客户端的文档。

换句话说，如果你已经在信标链上运行了一个节点，那么你现在还需要运行一个执行层客户端。同样，如果你在当前的工作量证明（PoW）网络上运行一个节点，那你还需要运行一个共识层客户端。为了让它们安全通信，必须将一个 JWT token 传递给每个客户端。ethereum.org 网站的“Run a Node”部分[11] 更新更详细地介绍了这些步骤。

值得强调的是，虽然它们都是共识层客户端版本的一部分，但运行信标链节点与运行验证器客户端是不同的。质押者必须同时运行两者，而节点运营商只需要运行前者。这篇文章 [12] 更详细地解释了这两个组件之间的区别。

此外，请注意，每一层都将维护一组独立的对等节点并公开其自己的 API。Beacon‌ API [13] 和 JSON RPC API [14] 都将继续按预期工作。

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

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

合并后，验证者必须确保他们创建和证明的用户交易和状态转换区块是有效的。为此，每个信标链节点必须与执行层客户端配对。请注意，多个验证器仍然可以与单个信标链节点和执行层客户端组合配对。这扩大了验证者的责任，但也赋予了提出区块的验证者相关交易优先权费用的权利 (目前属于矿工)。

虽然验证者奖励仍然在信标链上产生，并且需要随后的网络升级才能提取，但交易费用将在执行层上支付、销毁和分配。验证者可以指定任何以太坊地址作为交易费用的接收方。

更新共识客户端后，请务必将 fee recipient 设置为验证者客户端配置的一部分，以确保将交易费用发送到你控制的地址。如果你使用第三方提供商进行质押，则由你选择的提供商指定如何分配这些费用。

Staking Launchpad 有一个合并准备检查清单‌ [15]，质押者可以使用它来确保他们完成了流程的每个步骤。EthStaker 还举办了验证者准备研讨会，并计划举办更多的研讨会。

希望在测试网上运行验证器以准备主网 PoS 转换的质押者，可以在 Goerli 测试网 (现已完成合并) 上操作，它也有一个 Staking Launchpad 实例。

3. 为什么终端总难度 (TTD) 的预计日期范围如此宽泛？

每个区块增加的难度取决于不稳定的网络算力，如果更多的算力加入网络，则 TTD 将更快达到。同样，如果算力撤离网络，TTD 的到达时间将会延后。在算力水平显著下降的情况下，可以像在 Ropsten 测试网上所做的那样协调一个 TTD 覆盖值。

4. 作为应用程序或工具开发者，我应该怎么做？

如前一篇文章所述，合并对部署在以太坊上的合约子集的影响很小，所有合约都不应被破坏。此外，大部分用户 API 端点会保持稳定（除非你使用工作量证明特定的方法，例如 eth_getWork）。

也就是说，以太坊上的大多数应用所涉及的远不止链上合约。现在是确保前端代码、工具、部署管道和其他链外组件按预期工作的时候了。我们强烈建议开发人员在 Sepolia 或 Goerli 上运行一个完整的测试和部署周期，并向这些项目的维护人员报告任何工具或依赖性问题。如果你不确定在哪里打开问题，请使用此存储库。

此外，请注意，除了 Sepolia 和 Goerli 之外的所有测试网，都将在合并后被弃用。如果你是 Ropsten、Rinkeby 或 Kiln 的用户，你应该计划迁移到 Goerli 或 Sepolia。有关这方面的更多信息，请参见此链接[16]‌。