以太坊核心开发者会议 [2022-5-13]及会议纪要

以太坊核心开发者会议是以太坊项目开发人员的的线上交流会议，通常每两周举行一次，讨论项目的最新进展，技术问题，目前是以太坊合并升级的最后测试时期，今天的会议讨论了有关大量的合并更新，以及确定了Ropsten合并（开发人员将 Merge 部署到现有的公共测试网）的时间6月8号，这是正式合并前的最关键测试之一 。

下面让我们跟随核心开发人员的推文回顾这次重要的会议吧：

迟到总比没有好，另一个@以太坊#AllCoreDevs回顾一下。今天电话会议上的大量合并更新！议程：https: //github.com/ethereum/pm/is sues/518 直播

在此之后，我们还讨论了何时应该冻结引擎 API 以及其他规范。总之，基本上现在

我们不希望对引擎 API、EL 或 CL 规范进行更实质性的更改。我们希望对它们进行一些澄清，但预计下周将削减所有这些的发布候选。

在此之后，我们介绍了对 JSON RPC 块标签的添加。简而言之，在 The Merge 中，将添加一个“finalized”标签，它允许用户获取链上最后一个最终确定的块（如果没有，则表示错误，表示尚未发生 Merge）。

Marius 已经在 Geth 中实现了它

除此之外，我们还将引入一个“安全”标签。为简单起见，现在它可能会在客户端实现中别名为“finalized”。也就是说，我们最终可以升级它以返回一个我们预计在正常网络条件下不会恢复的块，通常是 4s 旧。

在此之后，我们就在 EL 上为 Merge 设置特定 Fork ID 的利弊进行了长时间的对话。来来回回推荐直播，但我会在这里尝试和总结！

首先，在 EIP-2124 中引入的 Fork ID 是同一网络（即具有相同 *Chain* ID）上的对等方在具有不同分叉历史的情况下相互断开连接的一种方式

通过从网络的创世哈希和节点已经通过的所有分叉块创建校验和来获取分叉 ID。如果节点知道将来发生分叉，节点也会存储一个值，称为 FORK_NEXT。

这样，如果你看到一个对等点对你已经在本地传递但没有分叉的块有一个 FORK_NEXT，你可以知道将它们断开连接，因为它们是或将在另一个链上。

我们在网络升级期间总是使用它，但这个挑战是我们*不*使用块高度来触发合并，而是使用总难度值，这与此方案不兼容。

所以，我们有几个选择： 1. 重新安排 Fork ID 方案以支持难度 2. 使用我们估计发生在 TTD 之前的 FORK_NEXT 块 3. 使用我们估计发生在 TTD 之后的 FORK_NEXT 块合并，并在 TTD 后断开连接

(4) 合并的 FORK_NEXT 什么也不做

(1) 被决定反对 - 它容易出错，可能会破坏依赖于此的工具，并且仅在这次有用。

(2) 很难做到正确，因为在释放客户端和实现合并之间有一个相当短的窗口。我们可能会意外地得到（3）！即使不是这样，也很糟糕，因为我们可能会断开尚未升级但会升级的对等方。

更重要的是，矿工可能会选择不为 The Merge 升级他们的软件（他们为什么要升级？），因此它可能导致节点在合并之前与矿工断开连接......不太好。

(3) 可以工作，但是如果您尝试在合并后“尽快”计时，那么您可能会遇到与 (2) 相同的问题：您弄错了，它发生在 TTD 之前，然后您断开了矿工. 坏的！

然后，如果你把 (3) 放在很远的地方，这意味着它基本上没有用，因为在你点击 FORK_NEXT 之前，你仍然连接到坏的同伴。

我们在这方面花了很多时间，并决定专门针对 Ropsten，只做 (4) 会更简单——什么也不做。

我们将继续这样做，看看坏对等点的数量是否可控。如果它在 Ropsten 上，节点几乎没有更新的动力，它也应该在主网上，基础设施提供商、验证者和用户有强烈的动力升级他们的节点。

如果我们在 Ropsten 上发现任何问题，那么我们可以花更多时间尝试在达到 TTD（选项 3）后不久为 FORK_NEXT 估算一个好的值，并在进入主网之前在其他测试网上对其进行测试。

接下来，我们讨论了是否以及何时分叉 Ropsten！这已经争论了一段时间，所以我再次强烈建议您观看直播。

它的要点是，虽然客户端的代码可以工作，但仍然存在边缘情况和错误，因此，今天准备好的*不是*主网上会发生的事情。

那么问题来了：我们是要等待在 Ropsten 上进行部署，还是最好尽早部署，让更广泛的生态系统通过升级运行，并为跨其他测试网（最终是主网！）的发布做好准备。

对于质押者/基础设施提供商/节点运营商而言，Merge 比其他升级更复杂，因为他们需要做的不仅仅是升级一个软件：他们需要向他们的 EL 添加一个 CL，反之亦然，并确保他们的设置仍然按预期工作。

还值得注意的是，Ropsten 预计不会在合并后得到维护，并且通常非常不稳定，因此它是升级风险最低的测试网。

经过一番折腾，我们决定继续！这将是社区体验过渡的好机会，从中吸取的教训可以纳入下一次测试网合并（Goerli 和 Sepolia），这将在我们拥有“最终”客户端代码时发生。

我们预计将在大约两周内发布客户端版本，以及有关质押者、节点运营商、工具/基础设施提供商需要为升级做些什么的信息。Ropsten 预计将在 6 月 8 日左右合并！

如果您确实想在那之前做好准备，我将再次建议您尝试 Kiln：https: //blog.ethereum.org/2022/03/14/kil n-merge-testnet/ ...

已经发生在它，但一般节点架构与在 Ropsten、其他测试网和主网上的节点架构相同

关于难度炸弹的简要说明 如果在 Ropsten 分叉之后，我们还没有准备好转移到其他测试网，我们仍然可以在那时将炸弹推回主网上。Goerli/Sepolia 的质量标准将高于 Ropsten，后者再次被弃用。

精明的读者可能会注意到的一件事是，Ropsten（和 Sepolia）目前*不*有与它们相关联的信标链！我们还讨论了如何启动这些（实际上，在 Ropsten TTD 之前，我的笔记是乱序的）。

首先，我们决定将它们命名为 Ropsten 和 Sepolia 信标链，以期最终将 Prater 别名为 Goerli。Bobsten、Bepolia 和 Boerli 不幸没有成功

在启动这些信标链时，我们需要考虑一些事情：有多少验证者，谁运行它们，它们何时通过 Genesis/Altair/Bellatrix 运行。同样，直播有细微差别，但我会总结一下结果。

对于 Ropsten，我们将拥有一组由客户和测试团队控制的 100k 验证器，但也为想要运行验证器的社区成员提供一个水龙头，让他们可以选择这样做。这样，他们可以在相对稳定的 PoS 环境中运行 The Merge。

对于 Sepolia，我们将使用一个更小的验证器集，它主要由客户端/基础设施/测试团队控制，有点像今天的 Clique 网络。想法是这些可以为应用程序开发人员提供更稳定的测试环境。

而且，对于 Goerli，我们显然会维护 Prater，它拥有大量的社区参与，但也有很大一部分由客户端团队运行，以确保网络的总体稳定性。

值得注意的是，至少对于 Ropsten，我们将使用 ERC20 版本的存款合约（感谢@protolambda！）这更容易管理。它不会影响对 The Merge 或后续功能（例如提款）的​​测试。

最后，预计对于 Ropsten 和 Sepolia，我们将让信标链快速连续地通过 Genesis -> Altair -> Bellatrix。对于 Prater，需要安排单独的 Bellatrix 升级。

这就是合并！TL;DR：Ropsten 于 6 月初合并，在此之前我们推出了 2 条新的信标链。如果我们对此时的客户端代码质量和测试覆盖率感到满意，我们可能会前进到其他测试网，否则，我们仍然可以延迟炸弹

为了结束通话，我们计划讨论 3 个 EIP。第一个是来自 Geth 的 Felix：https: //eips.ethereum.org/EIPS/eip-4938这只是提出了一个新的网络协议版本，它丢弃了 GetNodeData，用作快速同步的一部分，但不再需要快速同步。

支持这个协议意味着我们可以开始为弃用以前支持它们的 eth/xx 版本奠定基础。所有客户都支持引入新版本，但大多数团队表示他们需要相当长的时间才能弃用 eth/66。

接下来，我们安排了某人谈论https://github.com/ethereum/EIPs/pull/5022 ……但是他们没有出现。令人惊讶的是，这是我第一次没有参加 ACD 通话！无论如何，EIP 提议增加从零值到非零值到 40k gas 的 SSTORE 成本。

然后，为了完成，我们有@xinbenlv在关于过期交易提案的电话会议上，EIP-5081：

普遍的反馈是，虽然 DoS 风险可能不像预期的那样令人担忧，但过去有几个即将到期的交易提案，通常它们最终不会成为我们优先级列表中的第一件事，所以不要不要被包含在分叉中。

此外，这些似乎可以通过引入 EIP-3074 来完成，甚至在今天也可以通过使用 EIP-4337 的“通过内存池进行帐户抽象”构造来完成

就是这样！设法只加班约 5 分钟结束????下一次通话定于 5 月 27 日 14:00 UTC。回头见????????

If you do want to get ready before then, I'll once more recommend trying Kiln out: https://t.co/TCHBZxcFlt

The Merge has already happened on it, but the general node architecture is the same as it will be on Ropsten, other testnets, and mainnet ????

— Tim Beiko | timbeiko.eth ???????? (@TimBeiko) May 13, 2022