Goerli/Prater合并公告|以太坊基金会博客

对于最后的测试网络证明过渡，Goerli将与Prater合并。合并后的Goerli/Prater网络将保留Goerli姓氏后合并。
贝拉特里克斯（Bellatrix 112260，期望在 12:24 PM UTC于2022年8月4日。
激活Bellatrix后，Goerli/Prater合并将在Goerli击中完全困难时发生 10790000，期望之间 8月6日至12日，2022年。
合并后，Goerli的验证器集将保持打开状态，以供各个Stakers运行TestNets验证器。希望启动Goerli/Preter验证者的Stakers可以在 Prater Launchpad。

背景

经过多年的工作将验证证明带入以太坊，我们现在已经进入了最终测试阶段：TestNet部署！

经过几个DEVNET，Shadow Forks并在不弃用的测试网上合并，塞波利亚最近被过渡到股份证明。现在，只剩下一个测试网：Goerli及其相关的信标链Prater。

合并与以前的以太坊升级不同。首先，节点运算符需要同时更新其共识层（CL）和执行层（EL）客户端，而不仅仅是两者之一。其次，升级分为两个阶段：第一个名为贝拉特里克斯（Bellatrix 完全困难在执行层上值。

升级信息

定时

合并是一个两步的过程。它从共识层上的网络升级Bellatrix开始，由时期高度触发。接下来是执行层从工作证明到列车证明的过渡，巴黎，由特定的触发完全困难阈值，称为终端完全难度（（TTD）。

这贝拉特里克斯升级计划用于时期 112260 在PRATER BEACON连锁店中，预计 12:24 PM UTC于2022年8月4日。巴黎，执行层的过渡部分，将通过到达终端总难度（TTD）的 10790000 在Goerli上，期望 8月6日至12日，2022年。

一旦执行层超出了 TTD，下一个块将仅由信标链验证器生产。我们认为，一旦Beacon链完成了此块，我们认为合并已完成。假设正常的网络条件，这应该发生2个时期，即在第一个TTD块被击中之后大约13分钟！

一个新的JSON-RPC块标签，最终确定，如果不存在此类合并块，则返回最新的最终块或错误。该标签可用于应用程序检查合并是否已完成。同样，智能合约可以查询困难 opcode（0x44），更名为 Prevrandao 合并后，确定合并是否发生了。我们建议除最终状态外，基础架构提供商还监视整体网络稳定性。

客户发布

以下客户释放支持在Goerli＆Prater Testnets上合并。节点操作员必须运行 两个都 在合并期间和之后，执行和共识层客户端保留在网络上。

在选择要运行哪个客户的客户时，验证者应特别注意在EL和CL上运行多数客户的风险。可以找到这些风险及其后果的解释这里。可以找到当前EL和CL客户端分布以及从一个客户切换到另一个客户的指南的估计值这里。

共识层

执行层

升级规格

合并的关键共识变化在两个地方指定：

共识层在下面发生了变化贝拉特里克斯目录共识规格存储库
执行层在下面发生了变化巴黎规格在执行规格存储库中

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

引擎API，在执行 – 本次存储库，用于共识和执行层之间的通信
乐观的同步，在同步共识规格存储库的文件夹被共识层使用，以导入块，因为执行层客户端正在同步并提供从前者到后者的链的部分视图

常问问题

作为节点操作员，我该怎么办？

以太坊完整节点后合并将结合一个共有的层（CL）客户端，该客户端（CL）运行吧验证型信标链和执行层（EL）客户端，该客户端（EL）客户端管理用户态并运行与之关联的计算交易。这些使用一组新的JSON RPC方法通过一个名为发动机API。 EL和CL客户端使用JWT Secret互相验证。 节点操作员应参考其客户文档，以获取有关如何生成和配置这些文档的说明。

换句话说，如果您已经在信标链上运行了一个节点，则现在还需要运行执行层客户端。同样，如果您在当前的工作证明网络上运行节点，则需要运行共识层客户端。要使他们安全地交流，必须将JWT令牌传递给每个客户。 可以找到有关在Goerli/Prater网络上运行节点的摘要说明这里。

值得强调的是，尽管它们都是共识层客户端版本的一部分，但运行信标节点与运行验证器客户端不同。 Stakers必须同时运行两者，但是节点操作员只需要前者。这篇文章说明两个组件之间的区别更详细。

另外，请注意，每一层都会保持一组独立的同行并公开自己的API。这信标和 JSON RPC API都将继续按预期工作。

作为斯塔克，我需要做什么？

Goerli/Prater合并是您的最后机会，以确保在主网过渡之前正确配置验证器。现在强烈建议通过过渡进行过渡，以避免Mainnet上的任何意外问题。

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

合并后，验证者需要确保其创建和证明的块中的交易是有效的。为此，每个信标节点必须与执行层客户端配对。请注意，多个验证器仍然可以与单个信标节点和执行层客户端组合配对。尽管这扩展了验证者的职责，但它还为验证者提供了一个验证者，该验证者提出了一个障碍其相关交易优先费用的权利（目前授予矿工）。

验证者奖励在信标链上积累，并需要撤回后续网络升级，但交易费将继续在执行层上支付，燃烧和分配。验证者可以将任何以太坊地址指定为交易费用的接收者。

更新您的共识客户端后，请确保设置费用收件人作为验证器客户端配置的一部分，以确保将交易费用发送到您控制的地址。 如果您使用第三方提供商置于固定状态，则取决于您所选的提供商，以指定如何分配这些费用。

PRATER Stataking Launchpad有一个合并准备清单 Stakers可以用来确保他们经历了过程的每个步骤。 Ethstaker团队还主持合并验证者准备工作室 7月29日。

为什么对终端完全难度约会如此广泛？

每个块增量难度的波动率使得估算一个窗口 TTD 比块或时期高度更难，因此预期范围更大。用户应注意，由于工作证明哈希率的变化，Mainnet的过渡也是如此。

作为应用程序或工具开发人员，我该怎么办？

随着合并在Goerli上进行的合并，现在是您的最后机会，确保您的产品通过商品证明过渡和合并后的情况下的预期工作。正如在上一篇文章，合并只会对以太坊部署的合同的一部分产生最小的影响，而这些合同不应破裂。此外，大狮的用户API端点的份额保持稳定（除非您使用工作证明的特定方法，例如 eth_getwork）。

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

此外，您应该注意，除了Sepolia和Goerli之外，所有测试网络都将被弃用后。如果您是Ropsten，Rinkeby或Kiln的用户，则应计划迁移到Goerli或Sepolia。可以找到有关此的更多信息这里。