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

以太坊核心开发者会议是以太坊项目开发人员的的线上交流会议，通常每两周举行一次，讨论项目的最新进展，技术问题，由于近期发生了7个区块重组， Ropsten TTD 在测试网的信标链上线之前被击中等问题，今天的会议涵盖了RopstenTTD、信标链、Ropsten、难度炸弹等。

下面让我们跟随蒂姆·贝科的推文回顾这次会议：

首先在电话会议上，我们讨论了 Ropsten 发生的事情。我做了一个回顾，昨天我也在这里以书面形式分享过：https://notes.ethereum.org/@timbeiko/ropsten-ttd-override

TL;DR 的问题是 Ropsten TTD 在测试网的信标链上线之前被击中，并且激活合并功能的 CL 分支 Bellatrix 已经上线。

避免这种情况的最安全方法是简单地将 TTD 设置为非常高的值，然后在 Bellatrix 上线后将其降低。

对于 PoW 测试网，这似乎是确保哈希率峰值不会影响推出的唯一方法。

对于主网，考虑到大量的哈希率，我们_可以_更有信心地在 Bellatrix 上线之前设置一个 TTD，并高度保证它之前不会被击中。

也就是说，在电话会议上，我们同意主网的推出流程与测试网不同：用户和基础设施提供商将使用测试网作为配置事物的一种方式，我们不想告诉他们为主网做一些不同的事情。

然后我们讨论了这是否会导致 The Merge 的延迟，并得出结论认为不会。对于主网，我们可以在准备设置 TTD 前几周让 Bellatrix 激活。

Bellatrix 上线的要求是来自 CL 客户端的 The Merge 代码应该是最终的（至少对于共识更改）。这是我们在最后一个测试网版本中所期望的，所以我们可以让这些版本还包括用于主网的 Bellatrix。

我们还需要 EL 客户端在那时为主网做好准备，同样，我们希望最后一次测试网部署。

总而言之，要让 Merge 发生，我们需要： 1. 信标链上线 2. BC 激活 Bellatrix 升级，这意味着它开始在 PoW 链上监听 TTD 3. 在 PoW 链上命中 TTD

我们最初的计划是发布一个包含 Bellatrix 激活时期和 TTD 的版本，但现在将发布两个版本：一个包含 Bellatrix，另一个设置正确的 TTD。

特别是对于 Ropsten，这种方法失败了，因为链的难度非常低，每天只需几百美元，有人可以在一夜之间将其提高 10 倍。

对于主网（以及任何其他有价值的 PoW 网络），我们假设 51% 的哈希率不会串通，因此它在短时间内不可能接近这么多。

也就是说，在 mainenet 上，我们可能面临相反的问题：我们设置了一个 TTD，哈希率下降，我们需要设置一个较低的 TTD，因为它需要太长时间才能命中。

这正是我们现在将在测试网上默认做的事情，因此社区将尽早并经常“练习这些肌肉”:-)

特别是对于 Ropsten，我们现在人为设置了 100000000000000000000000 的高 TTD，这是当前以太坊主网总难度的两倍

客户团队现在正在发布具有此值的版本，预计下周初会发布公告。

如果您已经使用旧的 Ropsten TTD (43531756765713534) 将节点更新为版本，则需要再次更新，或手动覆盖 TTD

Ropsten 升级的时间表是：

1. 周五至周一：客户端发布

2. 周一：信标链创世

3. 周一至周二：博客公告

4. 6 月 2 日：Bellatrix 升级

5. 6 月 3 日：TTD 选择

6. 六月 ~ 8：TTD 命中 Ropsten PoW 链

对于其他网络，（5）和（6）之间的延迟会更大。我们在电话会议上来回讨论这个问题，但考虑到 Ropsten 计划弃用，决定为这个更快地移动一点是可以的。

所有这些都导致了一些问题。首先是 Potuz 的一篇关于 JWT 代币状态的文章。快速背景知识：EL 和 CL 通过一个新的 API，即引擎 API 进行通信，该 API 需要使用 JWT 机密进行安全身份验证。

所有 EL 团队都已实现此功能，其中大多数将其作为默认设置，其他人计划很快默认使用它。这是下一个测试网的硬性要求。

下一个问题是我们是否应该现在启动 Sepolia 信标链，以避免在那里遇到类似的情况。普遍的共识是我们应该尽快通过 Altair 运行它，但在安排 Bellatrix 之前等待它，以确保我们镜像主网部署。

我们已经开始看到区块时间变慢了（我上次检查时，本周平均约为 13.7 秒）。@tkstanczak然后解释说他认为我们应该考虑延迟。他昨天也在推特上分享了他的理由：

有一些客户团队对此表示支持，一般来说，虽然合并_几乎_完成，但我们还没有完成，炸弹确实增加了压力。

也就是说，有些人对进展速度比其他人更乐观，并不是每个人都认为我们应该推迟炸弹。

人们也不同意什么是“不可接受的”块时间，有些人认为我们已经快到了，而另一些人认为如果这意味着我们只专注于合并，那么 20 秒以上的块就可以了。

另一个潜在的问题是，如果块变慢，然后提高气体限制以弥补损失的吞吐量，我们可能会看到合并发生在比我们目前在主网上获得的更大的块上。

提出的一个想法是将炸弹延迟与信标链上的 Bellatrix 硬分叉的客户端版本结合起来。那时，我们还需要 EL 版本，所以你也可以让它们分叉，然后推回炸弹。

实际上，这至少会在 1 个月后发生，所以在此之前我们仍会看到区块时间在攀升，但这会让协调 PoV 变得更容易。

就延迟本身而言，每个人似乎都同意 2-4 个月是合理的。做的比这少是没有用的，没有人觉得我们需要更多。该范围的较短端似乎也有轻微的偏好。

再次，直播有更多细微的讨论，这只是亮点????我们没有对这次电话会议做出决定，但下一步将是有人以 EIP 的形式提出具体的提案。我怀疑我们也会在下一次电话会议中讨论这个问题。

到下一个 ACD，我们还将在 Ropsten 发生分叉，这将为我们提供有关事情进展情况的另一个数据点！

这就是所有与合并/炸弹相关的事情！我们已经加班了，但我们确实有另外两个关于 EIP 的更新。

第一的，@asn_d6更新了 EIP-4844，又名 protodanksharding。简而言之，EIP 的一个问题是验证内存池中 blob 的有效性可能会打开一个 DoS 向量，就像所有好的 EIP 一样！

也就是说，使用一些加密/数学魔法，@asn_d6@adietrichs和@dankrad有一个提案可以大大减少验证时间来解决这些问题https://github.com/ethereum/EIPs/pull/5088 验证时间从 40ms *per blob* 减少到任意数字的 ~3.5ms ！

最后，我们让 PeterCClu 来提供有关 EIP-2537 的更新，它引入了 BLS 预编译，并且自柏林分叉以来一直“搁置”。

Peter 解释说，其中几个库已经进行了广泛的模糊测试，客户端实现基本完成。@vdWijden还一直在研究各种库之间的 fuzzing。

我们没有讨论是否可以将其纳入上海，因为我们之前同意暂停此类讨论，直到我们基本完成 The Merge 工作并且可以更全面地看待各种提案。

今天就是这样！请注意，我们将在下周四召开 CL 电话会议，下周五将召开 Merge 社区电话会议 ( https://github.com/ethereum/pm/is sues/532 ) 以及从今天起两周后的 AllCoreDevs，即 6 月 10 日14:00世界标准时间

Another merge-heavy @ethereum #allcoredevs today ???? TTD, beacon chains, Ropsten, difficulty bomb, we covered it all!

Agenda: https://t.co/ei00nskBFg
Stream: https://t.co/Ydq0lfrQIL

Recap below ⤵️ https://t.co/yeGVLIuhX4

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