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

以太坊核心开发者会议在几个小时之前结束，会议讨论了最近Ropsten测试网完成合并，以及难度炸弹延迟的事情。

下面让我们跟随蒂姆·贝科的推文回顾整个会议要点：

首先在电话会议上，我们讨论了本周早些时候发生的 Ropsten 合并。

@dannyryan给出了更新，部分基于@parithosh_j本周早些时候的分析

合并前，一些 CL 客户在跟踪信标链的存款时遇到了问题。这是因为他们对区块时间做出了具体假设，由于其作为测试网的可变哈希率，因此在 Ropsten 混乱的区块时间下并不成立。

这些问题在达到 TTD 之前都已解决，并且存款都在合并前正常处理。

在 Ropsten 上的 Merge 之后，我们看到网络上的参与度下降了约 14%。丹尼在推特上对此发表了评论：约 14% 的验证者在过渡时出现停机 1. 9% -- nimbus-team 配置问题，通过 CLI 更改和重新部署修复 2. 1.8% -- 在 nethermind 中已知的并发错误，需要重新启动某些节点 3. 2.5- 3% -- nimbus-besu web-sockets 问题，改用 http 2/3

通过上述推文中提到的调整，参与率回升至 ~99%，这与主网相似。由于团队正在测试修复程序并在实时验证器上运行其他测试，它现在有点低。

我们也开始跑了@vdWijden的 Ropsten 上的 fuzzer，以确保我们在网络上有良好的事务负载。

我们在电话会议上更详细地探讨了客户问题。同样，强烈建议您观看直播以了解所有细微差别。

为了@nethermindeth出现并发问题的原因是，在 TTD，一些节点会从 EL p2p 网络和它们的 CL客户端接收新块。Ropsten 的情况变得更糟，因为恶劣的采矿条件导致叔块率很高。

该团队目前正在努力解决该问题

这@HyperledgerBesu<>@ethnimbus问题与 websockets、JWT 令牌的交互以及在特定端口暴露的缺少 eth_* API 端点有关。

Nimbus 团队与 Besu 共享了一个解决方法，该解决方法现在正在运行，但它需要禁用 JWT。Besu 团队目前正在努力解决该问题。

除了导致验证者参与度降低的问题外，还有一个问题是@ErigonEth正在生成其中包含 0 个交易的块。

此特定错误已修复，但“更深层次”的原因是 Erigon 不支持 PoW 挖矿。这意味着他们的块创建代码不像客户端的其他部分那样健壮，他们现在主要关注代码库的那部分。

接下来，我们讨论了一个关于 CL 在 EL 有时间创建块之前向 EL 询问块的问题。有很多关于通话中这种互动的复杂性的讨论（@ajsutton甚至出现了！）所以，再次推荐观看直播以了解详情！

简而言之，一些 CL 有时会在 EL 有时间创建区块之前向 EL 请求一个区块。根据规范，正确的行为是让客户端返回一个空块。这显然并不理想，因为 EL 通常可以很快创建_some_ 块。

因此，Geth & Nethermind 实施了一种解决方法，如果发生这种情况，他们只需“尽快”创建一个块并将其发回。这不是很好，因为它不能解决 CL 过早发送请求块的根本原因。

同样，大多数 CL 已经修复了这个问题，而其他人现在正在关注它。修复此问题后，EL 可能会恢复此功能以遵循规范。简而言之，当他们被要求获得一个区块时，他们将停止对其构造的迭代，将其密封，然后将其发回！

进一步解释：合并后，验证者控制以太坊的气体限制，就像今天的矿工一样。在生成块时，此参数被设置为 EL 的一部分。每次选择一个区块时，您可以将 gas 限制提高/降低 1/1024，或保持原样。

如果您假设质押者是生产区块的人，那么质押者会将他们想要的 gas 限制传递给他们的 EL，就是这样！在质押者可能不会自己构建区块的世界中，事情变得更加复杂！

在实践中，这可能是由于 MEV。想要从 MEV 费用中受益的验证者需要运行额外的软件来从搜索者/中继接收这些块。

因此，为了让外部区块构建者能够遵循验证者的 gas 限制偏好，让它们作为引擎 API 调用的一部分显式传递会很有用。这就是提议的更改所做的:-)

我们同意这不应该作为对当前 API 的更改，而是作为它的单独版本。还有关于是否应该将其他信息传递给构建器的问题，例如“extraData”字段。

每个人似乎都同意这很有用，但仍有一些细节需要解决，我们将在接下来的几周内继续这样做！

在此之后，我们讨论了 Sepolia Beacon Chain 的发布。随着 Ropsten 的合并，Sepolia 还需要一个 PoS 链来合并过去一周大部分配置已经完成

与 Clique 类似，在 Sepolia 上设置的验证器将获得许可。信标链将在 10 天内上线，并以人为高的 TTD 快速运行 Altair + Bellatrix。当我们准备好合并 Sepolia 时，我们将执行 TTD 覆盖，例如 Ropsten。

在此之后，我询问了各个 EL 团队在有信心推进测试网之前他们希望看到什么。再说一遍：电话里有很多分享，这些只是粗略的亮点，请观看直播！

Nethermind 先走了：对他们来说，它看到 hive/kurtosis 测试全部通过，块提案问题得到修复，并且显然他们当前的并发问题得到了完全解决。他们说他们希望至少 1/2 的测试网拥有基本上是最终版本的代码。

Erigon 回应了通过测试，说他们还有很多问题需要自己解决。除此之外，他们重申希望巩固他们的块构建代码，以及解决与在 JSON RPC 合并后返回“最新”块相关的问题。

最后一点与“最新”块是否应该仅在 CL 更新其分叉选择时更新，或者是否发送的任何被 EL 认为在规范链上的新块应该是“最新”有关。

规范使用前者，但一些 EL 实现，尤其是 Erigon，有一个数据库布局，这使得这很困难，因为它们只保留一个“当前”状态。

Besu 同意与测试相关的所有内容，重点是同步。我们在电话会议上花了一些时间讨论 EL 在没有 CL 的链头时应该做出哪些假设，以及如何与用户沟通。

Geth 同意其他团队的意见，并表示它缺少用于“安全”块的 JSON RPC 标志。

Teku、Prysm 和 Lighthouse 在电话会议上也都有代表。他们似乎都准备好转移到下一个测试网，每个测试网都有小问题，但他们认为没有任何阻碍。

最后但并非最不重要的一点是，Flashbots 也有人接听电话。有一些关于 mev-boost 的准备情况以及是否/如何成为障碍的对话。质押池似乎关注 MEV 的监控，而 FB 团队关注对单独质押者的用户教育。

关于这是否是一个障碍并没有强烈的共识，但显然工作将继续围绕 mev-boost 进行实施、测试和教育

最后，剩下的时间不多了，我们还有两个大话题：如何订购下一个测试网部署以及是否/如何延迟难度炸弹。这是通话中最混乱的部分，因为有许多相互交织的主题，所以，直播再次具有 100 倍的细微差别

首先，在测试网部署中，值得注意的是 Goerli 和 Sepolia 的不同之处。Goerli 是一个大型测试网，拥有大量活动，并且质押者可以在其中运行 The Merge（使用 Prater Beacon 链）。

OTOH，Sepolia 是一个新的测试网，几乎没有活动和许可的信标链。Goerli 将在许多方面为我们提供更多数据，而 Sepolia 将更容易过渡。

我们在电话会议上没有明确同意这一点，但是一旦我们在 Ropsten 上的问题得到解决，共识似乎已经转向在 Goerli 之前做 Sepolia，这样 Goerli 就可以与尽可能接近主网的代码合并尽可能。

Sepolia 信标链就是在这个假设下启动的。请注意，如果我们有充分的理由，我们仍然可以更改它，而两周前的计划是相反。我们没有打电话是因为我们进入了难度炸弹！

网络上可以感觉到炸弹，并且以真正的炸弹方式，它似乎比预测的要快，阻塞时间约为 14 秒，Arrow Glacier EIP（由您真正撰写）预测“到 2022 年 6 月阻塞时间延迟约 0.1 秒到 2022 年 7 月延迟约 0.5 秒。”

所以，@tkstanczak一直在倡导我们推迟炸弹的人，起草了一个 EIP 并在电话会议上提出：https: //eips.ethereum.org/EIPS/eip-5133  EIP 提议推迟炸弹〜 500,000 个区块，或 2.5 个月。

因此，这意味着到 8 月下旬，区块时间将回到今天的水平（约 14 秒，大约延迟 1 秒）。炸弹的影响每 100,000 个区块呈指数级上升，因此在此之后它会迅速上升，如前几期所见。

至少可以说，这是有争议的。再次，建议来回观看直播。给客户团队施加多少压力合适，出块时间对用户的影响，PoW 对环境的影响都出现了

简而言之，我们同意炸弹延迟。我们已经超时了，并且希望在选择确切的延迟和部署时间之前确保我们对所有数字进行了全面检查，但我们的目标是延迟约 2 个月，并且升级在 6 月下旬上线。

所有 EL 团队都一致认为，尽快这样做会让用户的事情变得更好，而短暂的延迟意味着我们将重点放在 The Merge 上。

再说一次，我们已经在这里超时了，所以我们想对数字进行异步检查，这应该在接下来的几天内发生。实际上，我们将在下周下周发布客户版本和适当的公告。

我将通过引用来结束@vdWijden热情洋溢的通话结束讲话，称炸弹延迟对客户来说是“五行改”，易于实施。他强烈认为这不会减慢团队在 The Merge 上的工作，并且@tkstanczak之前也有同样的说法。

就是这样！我们不得不放弃议程上的所有其他内容来度过难关。希望我们可以在 UTC 时间 6 月 24 日 14:00 的下一次电话会议上联系到他们。回头见！

参考：https://twitter.com/TimBeiko/status/1535337288036540416