Goerli/Prater合并在即这些事项需要注意-互推传媒

原文标题：《Goerli/Prater 合并公告》

原文来源：Ethereum Foundation Blog

原文作者：Protocol Support Team

作为最后一个进行权益证明过渡的测试网，Goerli 将与 Prater 合并。Goerli/Prater 合并的网络将保留 Goerli 这个名字。

Prater 测试网为合并做准备的 Bellatrix 升级将于 epoch 112260 被激活，预计时间是 12:24PM UTC on August 4, 2022

Bellatrix 升级激活后，当 Goerli 触达总难度值 10790000 时，Goerli/Prater 合并就会发生，预计时间在 August 6-12, 2022 之间。

合并后，Goerli 的验证者集将对个人质押者运行测试网验证者保持开放。想要启动一个 Goerli/Prater 验证者的质押车可以前往 Prater Launchpad。

背景

经过几年的努力将权益证明引入以太坊，我们现在已经进入了最后的测试阶段：测试网部署！

在经历了几个开发测试网、影子分叉和被弃用的测试网之后，Sepolia 最近过渡到权益证明。现在，只剩下一个测试网了：Goerli 和与它相匹配的信标链 Prater。

合并在两个方面与以前的以太坊升级不同。首先，节点运营商需要升级他们的共识层 (CL) 和执行层 (EL) 客户端，而不是两个中的一个。然后，升级分两个阶段激活：第一个阶段是 Bellatrix 升级，在信标链上的一个公开的 epoch 高度上激活，第二个是 Paris 升级，在执行层上触达一个 Total Difficulty (总难度) 值时激活。

升级信息

时间

合并分两步走。它从共识层上的 Bellatrix 网络升级开始，由一个 epoch 高度触发。接下来是执行层从工作量证明过渡到权益证明的升级 Paris，由一个特定的 Total Difficulty 阈值触发，被称为 Terminal Total Difficulty (TTD)。

Bellatrix 升级计划在 Prater 信标链的 epoch 112260 上激活，预计在 12:24PM UTC on August 4, 2022 （2022 年 8 月 4 日 12:24PM UTC )。执行层上的部分 Paris 将在 Goerli 测试网的 Terminal Total Difficulty (TTD) 达到 10790000 时被触发，预计在 2022 年 8 月 6 - 12 日。

一旦执行层超过了 TTD，下一个区块将完全由信标链验证者产生。一旦信标链最终敲定了这个区块，我们就认为合并已经完成。假设在正常的网络条件下，这应该在 TTD 后触发了第一个区块后的 2 个 epoch，也就是大约 13 分钟后完成！

有一个新的 JSON-RPC 区块标签 finalized，它返回的时最新被最终敲定的区块，或者如果没有这样的合并后区块存在的话，就返回错误。这个标签可以被应用用来检查合并是否已经完成。同样地，智能合约可以查询 DIFFICULTY opcode (0x44)，它在合并后被改名为 PREVRANDAO，用来确定合并是否已经发生了。我们建议基础设施提供商除了监测最终敲定的状态外，也监测整个网络的稳定性。

客户端版本

以下的客户端版本支持 Goerli 和 Prater 测试网的合并。节点运行者必须运行一个执行层 (EL) 客户端和共识层 (CL) 客户端，以在合并期间和之后都在保持在网络里。

当选择运行的客户端时，验证者应该特别注意运行 EL 和 CL 上的多数客户端的风险。关于这些风险及其后果，可以看这篇解释文章。对目前 EL 和 CL 客户端分布的预估以及从一个客户端切换到另一个客户端的指南可以看这篇文章。

共识层

Lighthouse Geardude Clockberg (v2.4.0)

Lodestar v0.41.0

Prysm v2.1.4-rc.0

Nimbus v22.7.0

Teku 22.7.0

执行层

Besu 22.7.0-RC3

Erigon 2022.07.03-alpha

go-ethereum (geth) v1.10.21

Nethermind 1.13.5

升级规范

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

共识层的变更，在共识规范仓库的 bellatrix 目录

执行层的变更，在执行规范仓库的 Paris spec

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

Engine API 在 execution-apis repository 里说明了，它是用于共识层和执行层之间的通信的

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

FAQ

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

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

换句话说，如果你已经在信标链上运行了一个节点，你现在还需要运行一个执行层客户端。同样地，如果你在当前的 PoW 网络上运行着一个节点，那么你将需要运行一个共识层客户端。为了使它们能够安全地进行通信，必须向每个客户端传递一个 JWT 通证。在 Goerli/Prater 网络上运行一个节点的简要说明可以在这里找到。

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

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

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

Goerli/Prater 合并是大家在主网过渡前确保验证者得到正确配置的最后机会。我们强烈建议参与这次的合并，以避免在主网上出现任何预料以外的问题。

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

合并后，验证者需要确保他们创建和证明的区块中的交易是有效的。为了做到这一点，每一个信标节点必须与一个执行层的客户端配对。

请注意，多个验证者仍然可以与一个信标节点和执行层客户端组合配对。虽然这增加了验证者的责任，但它也使得提议区块的验证者有权获得其相关交易的优先费 (目前这笔费用由矿工获取)。

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

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

Prater Staking Launchpad 有一个合并准备检查清单，验证者可以用来确保他们已经完成了流程的每一步。EthStaker 团队还将在 7 月 29 日举办一个合并验证者准备工作坊。

3. 为什么对 Terminal Total Difficulty 的预计时间跨度这么大？

每个区块增加的难度波动使得对 TTD 的估计比区块或 epoch 高度更难，因此预期范围更广。用户应该注意，由于工作量证明哈希率的变化，主网的过渡期也会出现这种情况。

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

Goerli 测试网准备进行合并，现在是你们的最后机会，以确保你们的产品顺利通过 PoS 过渡，并在合并后的环境里按预期运行。如之前的博文所述，合并只会对以太坊上部署的合约子集产生非常微弱的影响，应该不会破坏任何合约。此外，大部分用户的应用程序接口 (API) 端点仍将保持稳定 (除非使用 eth_getWork 等工作量证明的特定方法)。

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

此外，你需要注意的是，除了 Sepolia 和 Goerli 之外的所有测试网都会在合并后关停。如果你是 Ropsten、Rinkeby 或者 Kiln 测试网的用户，你应该计划迁移到 Goerli 或者 Sepolia 测试网。更详细的信息请阅读文章《Ropsten、Rinkeby 和 Kiln 测试网弃用公告》。