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

以太坊核心开发者会议是以太坊项目开发人员的的线上交流会议，通常每两周举行一次，讨论项目的最新进展，技术问题，目前是以太坊合并升级的关键时期，所以以太坊的核心开发者会议也受到了比以往更多时候的关注。

会议纪要整理来自蒂姆·贝科推特：

简而言之，如果攻击者可以强制客户端重新组织到他们已经丢弃父状态的块，就会出现问题，因为他们最初认为它不是规范链的一部分并丢弃它。

客户端通常只保留最近的状态差异（64-128 块），因此这种导致他们重新组织到以前认为的非规范链的攻击可能会导致他们最终无法重新组织到有效链。

电话会议上对此有几个问题，但出现的一件事是攻击者需要控制很大一部分股份才能发动这次攻击。

人们仍然需要消化这一点，但在接下来的两周内，我们将看看在客户端之间实施缓解措施有多么容易，以及导致这种情况需要多少权益，以及在该权益数量上是否会出现更严重的攻击已经可以了。

如果在那个 % 的股份上已经有可能发生更糟糕的事情，并且客户实施修复程序并非易事，那么修补它可能不值得。也就是说，如果其中一件事情不是真的，我们将要确保我们对这些场景是安全的并对其进行测试。

在接下来的电话会议中，我们讨论了如何为 The Merge 部署测试网。我们在过去的电话会议中曾简要谈到过它，但由于时间紧迫，从未深入讨论过。

我们在电话中来回交流了很多，我说了很多，所以没有很好的笔记，但这是我对我们最终结果的总结 - 直播有所有来回让我们到达那里????

首先，鉴于我们在测试过程中添加了影子分叉，而我们在之前的以太坊升级中没有这样做，我们可以假设一旦我们转向测试网，大多数/所有问题都将得到解决。

同样，影子分叉基本上是_实际发生_的测试网/主网分叉，但仅在极少数节点上，由客户端 + 测试团队控制。我们希望保持影子分叉，直到事情非常稳定。

此时，我们要确保的主要内容是节点运营商能够正确配置其节点以进行升级。Nethermind 发现这次升级对于节点运营商来说比以前的升级更加复杂。

理想情况下，每个人都已经在 Kiln 上完成了这项工作，因为我们几个月来一直在敦促人们这样做（所有信息都在这里：https: //blog.ethereum.org/2022/03/14/kil n-merge- testnet / ，仍然是时候这样做了！！），但我们知道在实践中情况并非如此????

因此，考虑到这一点，在我们分叉第一个测试网之前给人们更多的提示是合理的，并期望事情可能不会非常顺利，因为会有很多首次组合的 EL 和 CL 节点运营商。

因为我们希望以尽可能多的现有用户为目标，并且存在更大的错误配置风险，所以我们宁愿在合并后一段时间内关闭的网络上运行此过程：Ropsten

一旦 Ropsten 稳定下来，我们将继续分叉 Goerli，然后是 Sepolia，紧随其后。这样，当所有三个测试网都被分叉时，Ropsten 将在合并后运行相当长的时间。

这意味着我们可以在合并后的上下文中在 Ropsten 上测试节点稳定性、同步新节点等内容，并确保一切按预期工作。这是一个很好的网络，因为它确实有很大的状态和历史。

这里隐含的一件事是，Rinkeby *不会*通过 The Merge 进行转换。

因此，如果您正在使用该网络，我们建议您迁移到 Sepolia 或 Goerli，这两者都有望在合并后得到维护。Rinkeby 和 Ropsten 都不会在一夜之间关闭，但它们将被弃用????

不同之处在于，Ropsten _will_ 在合并过程中运行，并且在关闭之前仍然作为测试网工作，而在合并后，Rinkeby 实际上不会成为主网的良好暂存环境，因为它将落后于升级。

最后，我们讨论了在迁移到公共测试网之前需要完成的另外两件事： 1. 确保所有客户端仅通过经过身份验证的 JSON RPC 端口提供引擎 API。我们希望强制用户必须在 Ropsten 分叉之前进行配置。

2. 运行影子分叉，其中更多的验证者由客户团队控制。到目前为止，虽然客户端团队确实在 Shadow Forks 中运行验证器，但 EF devops 团队（嗨@parithosh_j！）已经控制到足以确保网络上的最终确定性。

一旦事情变得更加顺利，更广泛地分发验证器以拥有更多反映公共网络的测试条件是有意义的。

因此，总结一下：从这里到合并的路径????

1. 更多影子分叉，不会导致客户端问题，以及客户端团队控制大部分验证者的地方????

2. 分叉 Ropsten：让人们有足够的头脑进行配置他们的节点正确，希望他们做对了????????

3. Fork Goerli & Sepolia：确保一切顺利，Ropsten 已经稳定，新节点可以加入等。????

4. 稍等，确保所有测试网看起来都很好✨

5. 然后，在主网上运行该过程????！同样，Rinkeby *不会*经历这个过渡????

我们讨论的第一件事是我们是否可以使用 EOF 作为开始删除 SELFDESTRUCT 的一种方式。

这是我们一直想做的事情，现在有一个合理的建议（https://eips.ethereum.org/EIPS/eip-4758），但不清楚我们是否想在上海增加更多的 EIP（更多稍后再说！）

鉴于 EOF 已经为其合约指定了新的执行规则，很容易从一开始就简单地从中删除 SELFDESTRUCT。

通话中有一些来回，对于下一步没有明确的结论，但一个想法是，也许我们不能在 EOF 的第一个版本中简单地启用该操作码，然后如果我们认为需要，然后决定激活它它。

这不是一个明确的肯定，因为如果我们将 SELFDESTRUCT 替换为 SENDALL（在合约中发送 ETH 而不删除代码），可能有一些正当的理由想要在 EOF 中使用 SENDALL。

然后，关于 EOF 如何与 Verkle Tries 交互存在一些问题，这是无状态以太坊的要求，尤其是在代码分块方面。

解开所有这些：无状态以太坊允许我们通过只要求大多数节点存储状态的子集而不是整个状态来扩展我们在执行层的吞吐量。

为了向网络上可能没有所有状态的另一个节点证明交易是有效的，因此我们需要开始在网络周围发送状态的小部分，称为见证人。

ELI5 版本：今天，所有节点存储每个人的余额和所有智能合约代码。在无状态中，也许您的节点只存储您的余额以及您关心的智能合约（例如您拥有的 NFT）。

因此，如果您想向某人发送 1 个 ETH，则另一个节点需要证明您实际上拥有 1 个 ETH，因此您只是交易状态的一部分，以及交易本身。

挑战在于，使用我们目前在以太坊上的存储结构 Merkle Patricia Tries，这些证人/证明/迷你状态可能非常大。把它想象成一棵大圣诞树，你需要发送的证明从它的顶端一直到底部。

相反，Verkle 尝试更“平坦”。把它想象成灌木丛（但非常宽且呈三角形......请耐心等待????）

因此，在这种情况下，证明要小得多，因为从树的顶部/头部到要证明的基础/根/数据的距离更短。这意味着这些证明更容易在网络上发送！

接下来，我们有一个快速公告：在之前的 ACD 上，有几个 EIP 要求在上海考虑。也就是说，我们已经有了一个不错的列表（参见：https: //github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md ... 并且还没有开始实施/测试其中任何一个，因为我们仍在合并中。

围绕区块提议者 DoS 攻击和降低链吞吐量有一些安全考虑，但对于这些是我们希望通过此 EIP 解决的问题并没有达成一致意见。

最后，@greg_colvin还有一些关于 EOF 的问题，但我们很难在电话会议上找到问题的核心。关于研发不和谐的对话仍在继续，下周可能会在阿姆斯特丹继续

就是这样！Next AllCoreDevs 计划于 4 月 29 日 14:00 UTC 举行。在那之前，@EFDevconnect ????！

And that was it! Next AllCoreDevs is scheduled for April 29th, 14:00 UTC. Before then, see you at @EFDevconnect ????!

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