- Ropsten 将是第一个执行合并的老牌测试网
- 新的 Ropsten 信标链已在 2022 年 5 月 30 日启动,为网络提供共识
- Ropsten 信标链预计将在 2022 年 6 月 2 日升级到兼容合并的协议规则 (Bellatrix)(位于时隙 24000)
- 此后,Terminal Total Difficulty (TTD) 将被选中,以触发工作量证明链上的合并。 节点运营商将需要在其客户端上手动设置该值。
- 本博客将在 2022 年 6 月 3 日发布另一项公告,并提供用于 Ropsten 合并的具体 Terminal Total Difficulty。 在被选中几天后将达到该 TTD 值,而用户应准备好在短时间内对其客户端进行相应配置。
背景
为了在以太坊中引进权益证明,我们经过多年努力,现在终于进入到最后的测试阶段:测试网部署!
在 Kintsugi 🍵、Kiln 🔥🧱 及多个影子分叉上对客户端实现进行测试后,客户端团队已经准备好让 Ropsten 这个最老牌的工作量证明测试网执行合并。 在准备期间,我们已启动 Ropsten 信标链,为网络提供共识。
在完成 Ropsten 过渡以后,另外两个测试网(Goerli 和 Sepolia)也将过渡到权益证明,然后把重点转移到主网上。 社区可能会单独维护并升级其他测试网,如 Rinkeby 和 Kovan 等,它们不再受客户端开发者的监控。
合并与以往以太坊升级的区别体现在两个方面。 首先,节点运营商需要协同更新他们的共识层和执行层客户端,而不仅限于其中一个。 其次,升级将分两个阶段触发:首先要在信标链的时隙高度,然后要达到执行层的 Total Difficulty 值。
鉴于这些情况,在开发流程当中,Ropsten 网络(合并后弃用)将比以往的网络升级更早地执行升级。 社区将因此获得更多时间,以熟悉该升级流程。
注意:下面列出的客户端版本将不适用于以太坊主网过渡到权益证明。
升级信息
时间安排
合并分两个步骤进行。 刚开始时,它将由一个时隙高度触发,在共识层进行网络升级。 随后是执行层从工作量证明过渡到权益证明,由特定的 Total Difficulty(即 Terminal Total Difficulty (TTD))阈值触发。
2022 年 6 月 2 日,在时隙 24000,Bellatrix 升级将使 Ropsten 信标链做好合并的准备。 届时,共识层客户端将开始侦听在工作量证明链上是否达到 TTD 值。
由于工作量证明测试网的哈希率具有很大波动性,TTD 值在刚开始时被设置得非常高,具体为 100000000000000000000000。 按 Ropsten 的当前哈希率,要达到该值将需要大约 250 年时间。
如果在信标链上进行 Bellatrix 升级,将选中并公布新的 TTD 值,而且预计将在几天后达到该值。 然后,用户将需要使用这个新值配置他们的节点。 如需查看有关对每个客户端执行此项操作的说明,请见此处。
当在 Ropsten 上达到或超过这个新的 TTD 时,过渡的执行层部分(代号为 Paris)将会开始。 同样,请注意 Ropsten 上的哈希率极为易变,因此达到 Terminal Total Difficulty 的实际时间可能发生波动。
如果执行层超过 TTD,下一个区块将完全由信标链验证者生成。 在信标链最终确定该区块后,我们将视合并已完成。 假设网络状况正常,此过程应在达到第一个 TTD 后区块之后的 2 个时段或大约 13 分钟左右发生!
新的 JSON-RPC 区块标签 finalized 将返回最近确定的区块,或者如果不存在此类合并后区块,则会返回错误。 此标签可被用于应用,以检查合并是否已完成。 类似地,智能合约可能会查询 DIFFICULTY 操作码 (0x44) 以确定是否发生合并,该操作码将在合并后被重命名为 PREVRANDAO。 除检查最终确定状态以外,我们还建议基础设施提供商监控整体网络稳定性。
客户端版本
以下客户端版本支持 Ropsten 测试网上的合并。 节点运营商必须同时运行执行层和共识层客户端,以确保在合并期间及合并后留在网络当中。
如上文所述,以下版本的 Terminal Total Difficulty 值将被硬编码为 100000000000000000000000。在信标链上触发 Bellatrix 升级以后,这个值将需要被手动更新。
在选择要运行哪个客户端时,验证者应尤其注意同时在执行层和共识层上运行大多数客户端将会引发的风险。 您可以点击此处以了解关于这些风险及其影响的详细说明。 有关当前执行层和共识层客户端分发的估计情形和在客户端间切换的指南,请见此处。
注意:如果之前下载过 Ropsten TTD 为 43531756765713534 的客户端版本,您必须更新您的版本或手动将 TTD 覆盖为 100000000000000000000000,具体请见此处。
共识层
名称 | 版本 | 链接 |
---|---|---|
Lighthouse | Baby Wizard (2.3.0) | 下载 |
Lodestar | 参见下方的“Lodestar 说明” | 参见下方的“Lodestar 说明” |
Prysm | v2.1.3-rc.2 | 下载 |
Nimbus | ||
Teku | v22.5.2 | 下载 |
**Lodestar 说明:**最新的 Lodestar 版本 v0.37.0 使用过时的 Ropsten TTD 值,43531756765713534。 要与现在使用 100000000000000000000000 作为 TTD 的 Ropsten 合并兼容,Lodestar 用户将需要手动覆盖该值。 有关此项操作的具体说明,请见团队的发布公告博文。
执行层
名称 | 版本 | 链接 |
---|---|---|
Besu | v22.4.2 | 下载 |
Erigon | v2022.05.08 | 下载 |
go-ethereum (geth) | 参见下方的“Geth 说明” | 参见下方的“Geth 说明” |
Nethermind | v1.13.1 | 下载 |
**Geth 说明:**最新的 go-ethereum (geth) 版本 Sharblu (v1.10.18) 使用过时的 Ropsten TTD 值,43531756765713534。 要与现在使用 100000000000000000000000 作为 TTD 的 Ropsten 合并兼容,geth 用户必须:
- 使用最新 master 分支上的源进行构建
- 使用最新的 Docker 镜像
- 在启动客户端时运行以下命令,以手动覆盖 TTD:--override.terminaltotaldifficulty 100000000000000000000000。
升级规范
指定在两个地方执行合并的共识关键型更改:
- 共识层更改,位于共识规范存储库的 bellatrix 目录下
- 执行层更改,位于执行规范存储库的 Paris 规范下
除了这些以外,还有其他两项规范涉及到共识层和执行层客户端的交互方式:
- 在 execution-apis 存储库中指定的引擎应用程序接口可用来实现共识层与执行层间的通信。
- 在执行层客户端进行同步时,共识层使用在共识规范存储库的 sync 文件夹中指定的乐观同步来导入区块,并按前后顺序提供区块链头部的部分视图
常见问题
作为节点运营商,我应该做什么?
合并后,以太坊完整节点将整合共识层客户端(运行权益证明信标链)和执行层客户端(管理用户状态并运行交易相关的计算)。 它们使用一组新的 JSON RPC 方法(称为引擎应用程序接口)通过已验证端口进行通信。 执行层和共识层客户端会使用 JWT 密钥相互验证。 节点运营商应参考其客户端的相关文档,以了解有关如何生成并设置这些客户端的说明。
换言之,如果您已经在信标链上运行节点,现在还需要运行执行层客户端。 同样,如果您正在当前工作量证明网络上运行节点,则还需要运行共识层客户端。 为使其能够安全通信,必须向每个客户端传送 JWT 代币。
值得强调的是,如果它们两个都是共识层客户端版本的一部分,则运行信标节点不同于运行验证者客户端。 质押人必须运行两者,但节点运营商只需要运行前者。 本博客更详细地解释了这两个组件之间的差异。
另外还要注意,每一层都将维护一组独立的对等点并公开自己的应用程序接口。 信标应用程序接口和 JSON RPC 应用程序接口都将继续按预期运行。
最后,别忘了在 6 月 6-7 日再次查看本博客上的公告,了解最终的 Ropsten TTD 值。
作为质押人,我需要做些什么?
前文解释过,**合并后信标链上的验证者除了运行其共识层客户端外,还需要运行执行层客户端。**合并前,强烈建议验证者运行两种客户端,但验证者可以将这些职能外包给第三方提供商。 这是因为执行层所需的唯一数据就是对存款合约的更新。
合并后,验证者需要确保他们创建并证明的区块中的交易有效。 为此,每个信标节点必须与一个执行层客户端配对。 请注意,多个验证者也可与单个信标节点及执行层客户端组合配对。 虽然这会加大验证者的责任,但同时也让提出区块的验证者有权获取相关交易优先费(目前该权利为矿工所有)。
尽管验证者获得的奖励会在信标链上累积,需要后续网络升级才能提取,但手续费的支付、销毁和分配将继续在执行层上进行。 验证者可以指定任何以太坊地址作为手续费的接收地址。
在更新您的共识客户端后,务必将 fee recipient 设置为您的验证者客户端配置的一部分,以确保交易费发送到由您控制的地址。
如果您是通过第三方提供商质押,则由您选择的提供商指定这些费用的分配方式。
测试网升级是验证者确保其设置正确无误并解决存在的问题的最后机会。 有关在 Ropsten 信标链上运行验证者以便为合并做好准备的更多信息,请见 Ropsten 质押启动板。
在以太坊主网过渡到权益证明前,我们强烈建议主网验证者在 Ropsten 和其他测试网上执行合并。
作为应用或工具开发者,我应该做什么?
随着合并在 Ropsten 上线,现在是时候确保您的产品能在向权益证明过渡期间和合并后的环境中如预期运行。 如之前的博文所述,合并只会对以太坊上部署的合约子集产生非常微弱的影响,应该不会破坏任何合约。 此外,大部分用户的应用程序接口端点仍将保持稳定(除非使用 eth_getWork 等工作量证明的特定方法)。
尽管如此,以太坊上的大多数应用程序涉及的远不止链上合约。 现在您要确保前端代码、工具、部署管道和其他链下组件能够按预期运行。 我们强烈建议开发者在 Ropsten(或 Kiln)上执行一个完整的测试和部署周期,并向这些项目的维护者报告任何工具或依赖项存在的问题。 如果不确定在哪里提出问题,请使用此存储库。
作为以太坊用户或以太币持有者,我需要做什么?
不需要。 以太坊主网不受此测试网的影响。 在主网过渡之前,我们将在此博客中发布后续公告。
作为矿工,我需要做什么?
不需要。 如果在以太坊主网或 Ropsten 上挖矿,您应该了解在合并后,每个网络将完全采用权益证明机制运营。 届时,以太坊网络上将无法再挖矿。
针对 Ropsten 和以太坊主网,此项安排分别将于 2022 年 6 月 8 日和今年稍晚时候生效。
作为验证者,我能否取回质押物?
不需要。 合并是迄今为止最复杂的以太坊升级。 为了尽量降低网络中断的风险,我们采取了最精简的方法,在本次升级中不会包含任何非过渡更改。
合并后的首次升级可能会推出从信标链中取回质押物的功能。 共识层和执行层的规范都在制定中。
我还有其他问题,我可以在哪里提问?
我们计划在 6 月 3 日 14:00(协调世界时)举行有关合并的社区电话会议。 客户端开发者和研究人员将在会上回答由节点运营商、质押人、基础设施和工具提供商,以及社区成员提出的问题。
何时合并?
截止到本博客发布时,以太坊主网的权益证明过渡日期还未确定。 任何来源发布其他相关言论都可能不实。 相关信息更新将通过本博客发布。 请注意网络信息安全!
如果 Ropsten 不存在任何问题,在完成客户端测试后,以太坊的其他测试网也将执行合并。 当 Goerli 和 Sepolia 成功完成过渡并稳定运行后,将为信标链上的 Bellatrix 升级选择一个时隙高度,并且为主网过渡设置一个难度值。 然后,客户端将发布在主网上支持合并的版本。 我们将在此博客以及其他社区出版物上宣布相关消息。
以上均以未发现问题作为前提。 如果在此过程的任何时间点发现问题,或测试范围被判定不够全面,我们将解决这些问题,然后再继续推进部署进程。
只有到这时,才可能估计合并的确切日期。
也就是说,我们会快马加鞭 🔜。