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

周五的14:00 UTC，以太坊核心开发者会议如期召开，会议讨论了最近合并测试网遇到的一些问题，以及难度炸弹是否需要延迟的问题，最后会议决定目前不急于对难度炸弹做延迟，因为还有足够的时间周期做出调整，在此之前社区工作重点：

1. 再拥有两个主网影子分叉。

2. 让客户支持并通过 hive 测试套件。

3. 修复过去影子叉的突出错误。

具体的会议细节内容让我们参考会议协调负责人蒂姆·贝科 的推文：

我们在这里没有做出一致的决定，而是决定让各个团队按照他们认为最好的方式处理这个问题。除此之外，我们将确保继续准确沟通节点运营商、质押者和基础设施提供商应如何为 The Merge 配置其节点。

除此之外，Geth 团队还开始研究新的调试 API，以帮助对影子分叉期间出现的问题进行分类。他们鼓励其他客户团队也支持他们，使跨客户诊断更容易。

然后，我们讨论了如何实现影子分叉的自动化。我们一直在与@KurtosisTech用于合并测试并将团队推向极限

我们同意，在这个项目和他们的其他项目之间，在合并网络中创建分区和其他中断，让他们在后者上工作更有意义。

简而言之，在阿姆斯特丹的一些 f2f 讨论之后，我们同意保留 Engine API 规范，并添加额外的测试用例以确保在各种边缘情况下的正确行为。

在此结束后，Mikhail 还强调了另一个规范边缘案例，如果根据 Engine API 的第一个合并后块是无效的，则不清楚 CL 客户端应该做什么。

简而言之，其他区块的行为是然后回溯历史以在该分叉中找到最新的有效区块。但是，CL 没有将预合并块作为其块树的一部分。有几个选项可以解决这个问题，Mikhail 在问题中详细说明了这一点。

没有人有时间对其进行适当的审查（它是在 9 小时前创建的！），但没有任何选择会带来灾难性的感觉。我们将在接下来的一两周内花时间研究这个问题。

接下来，我们讨论了关于如何在合并后标记新的 JSON RPC 参数的另一个突出问题：

关于是否以及如何使用安全/不安全/最新的电话有一些来回，但我不希望我们在这个话题上花费太多时间，所以邀请人们在接下来的几周内异步讨论它。直播各有优缺点????

也就是说，重要的是我们尽快同意*某事*，因为在我们转向分叉公共测试网之前，我们希望在客户端之间标准化这种行为。所以，虽然我对结果没有强烈的看法，但我强烈希望得到*一个*结果????

在这之后，@lightclients有一些与 mev-boost 相关的设计问题，这是 Flashbots 与以太坊客户沟通的合并后产品。

在 MEV 提升中，区块构建者将整个区块（而不是交易包）发送给验证者。作为块的一部分设置的参数之一是它的气体限制，矿工/验证者可以从前一个块的限制提高/降低它。

所以核心问题是你是否希望验证者/区块提议者对区块构建者施加特定的气体限制，或者允许构建者设置他们自己的限制。经过一番反复，我们同意验证者/提议者应该设置它，而不是构建者。

换句话说，现在在 mev-boost 中会有一个额外的约束，区块构建者需要构建一个有效的区块*并尊重验证者选择的气体限制*。

接下来，我们讨论了 The Merge 之后测试网的未来。会上对此进行了一些讨论@EthMagicians上周聚会，总结在这里：

有一件事变得很清楚，社区讨厌弃用测试网的想法！如此之多，以至于一些组织已经加紧提供在合并后维护它们。

因此，从客户端开发 PoV 开始，我们将继续拥有 Goerli & Sepolia（很快@_anishagnihotri的水龙头！）作为长期维护的测试网，并通过合并运行 Ropsten 以弃用它。这将提供足够的测试数据。

也就是说，如果一个组织想要维护 Rinkeby/Ropsten，我们会努力让它发挥作用。我已经在与一些人讨论这将如何工作，期待更多关于此的更新。

然后，我转到了电话中棘手的部分：询问客户团队他们对我们何时应该开始考虑分叉测试网的想法

不同的人提出了不同的标准，这里是： 1. 我们希望看到成功的主网影子分叉顺利进行。一般的感觉是，我们的最后一个是_就在我们希望看到的条形下方，如果我们可以更平滑一点，再增加 1-2 个就足够了。

2. 我们希望看到所有客户端通过绝大多数 Hive + 其他测试套件。我们在这方面取得了不错的进展，但并非所有客户团队都有足够的带宽来添加支持 + 审查所有故障。

值得注意的是，由于测试设置错误，可能会发生一些故障，但我们希望确定这一点！

3. 更多的模糊测试和边缘案例测试。理想情况下，我们希望对每个客户端对进行模糊测试以发现问题，并测试诸如在合并期间不同步的情况@peter_szilagyi早早长大。

最后，我们讨论了所有这些如何与难度炸弹相匹配

@tjayrush应邀提出他对炸弹的预测：

他争辩说，当炸弹开始出现时，它会迅速出现，因此我们要准备好做出反应。

我的立场是，理想情况下，我们应该尽可能地等待，然后再做出关于炸弹的决定，因为*如果*有一条通往合并的路径可以避免炸弹延迟，我们应该尝试这样做不添加炸弹的另一个分叉造成的延迟。

有一些担忧来自@nethermindeth这将很难预测，因为哈希率可能会下降，并且当炸弹爆炸时，最终用户的体验会很糟糕。此外，移动炸弹相当容易，因为我们之前已经做过多次。

@MicahZoltu还建议，如果我们对炸弹感到如此紧张，我们也可以简单地将其移除，以便我们有空间尽可能专注于交付合并，而不必担心日期。

整个客户团队都支持这个想法。也就是说，@dannyryan还指出，拥有炸弹确实可以作为防止欺诈 PoW 分叉在 The Merge 出现的机制。

简而言之，如果 PoW 分叉需要推回炸弹，这表明从事它的团队至少拥有_一些_技术知识，并且他们可以说服用户下载他们的软件，而不是停留在默认链上。

炸弹的影响每 2 周就会增加一次，这意味着我们可以在每次通话中查看其进度并评估正确的下一步是什么。在块时间比现在长 > 1 秒之前，可能还有大约 2 个周期。

那时我们已经结束了电话会议，所以我们同意在两周内重新评估，在此之前专注于：1. 再拥有两个主网影子分叉

2. 让客户支持并通过 hive 测试套件

3. 修复过去影子叉的突出错误

就是这样！下一个 ACD 设置为 5 月 13 日 14:00 UTC - 到时见

We were at the end of the call by then, so we agreed to re-assess in two weeks, and until then focus on:
1. Having two more mainnet shadow forks ????
2. Getting clients supporting and passing hive test suites ✅
3. Fixing the outstanding bugs from past shadow forks ????

— Tim Beiko | timbeiko.eth ???????? (@TimBeiko) April 29, 2022