来源 | AllCoreDev Updates

• 伦敦升级即将在区块 12 965 000 启动，社区组织了几场观看派对 📺
• 在 Ropsten 测试网发现 (并修复了) 一个漏洞，以太坊基金会正在招一名新的测试工程师。在此处申请🛠
• 合并 (The Merge) 现在有一份 EIP：EIP-3675📝
• 我们正在考虑一些不一样的路线图，但所有这些情况都包含搭起合并测试网并尽快把它们运行起来💪🏻

伦敦升级🇬🇧

如你所愿，下周伦敦升级将在以太坊主网上启动！分叉区块是 12,965,000，目前 Etherscan 和 Ethernodes 预计会在北京时间 8 月 5 日 18:00。

如果你运行以太坊节点，是时候更新了！你可以在此处找到与伦敦升级兼容的版本。

Ropsten 测试网漏洞🐛

在上面的链接里，你可能会注意到一件事，那就是提到 Ropsten 网络上出现的共识问题。这个问题的详情在这篇事后总结里说明了，但这里有一个概要：

• 在五月，我们给 1559 的规范增加了一些新的检查，以防止某些类型的垃圾邮件攻击；

• 其中一个检查断言是交易发送账户上的 ETH 量至少有交易的gasLimit乘以其maxFeePerGas (每单位 gas 的费用上限)

  • 这确保了发送出去的交易总能有足够的 ETH 在”最坏情况下“ (即当 baseFeePerGas 等于 maxFeePerGas时) 完成执行。

• 为了使这个检查有效，它需要从余额中扣除在交易发送的任何金额后在账户余额上起作用。

• 规范中的检查顺序是正确的，但从什么账户中扣除这个事实是不清晰的，因此有些客户端是在初始账户余额里进行检查的。

• 在 Ropsten 测试网上，有一笔交易在转账前而不是之后有足够的 ETH 支付 maxFeePerGas ，因此导致有些客户端错误地接受了该交易，而其他拒绝了它 [0]。

在之后的几个小时内，这个问题被发现了，并在客户端上进行了修复。受影响的团队在第二天就发布了更新版本。

在这次事件后，有人提出我们是否应该进一步推迟伦敦升级的时间。尽管没有客户端团队在发布更新版本软件前要求这样做，且在随后的核心开发者会议上也没有提到想要这样做，这个问题是在其他论坛里提到或许应该推迟。

我在核心开发者的 discord 上重开了这个问题的讨论。只有一个客户端团队认为我们因为此事推迟。尽管推迟似乎是”理应的”选择，但有人提出反对推迟的几个理由：

• 难度炸弹：在区块 13,100,000 后，难度炸弹的影响将开始变得更加明显，而且不确定延迟这么短的时间会否产生重大影响；
• 修复的性质：对该漏洞的修复在技术上是一个软分叉 (即收紧协议规则)。这意味着，只要大多数的矿工都升级了，他们将不会产出一个还未升级的、与伦敦升级兼容而节点拒绝的区块。
• 有两个伦敦分叉区块的风险：与上述情况相反，如果我们真的修改伦敦升级的分叉区块且有些节点没有升级，那么那些节点会比“新的”伦敦升级更早进行分叉。

当然，只有时间能证明这是否是正确的决定，以及可能一个更极端的延迟 (例如，“取消伦敦升级、延迟难度炸弹，从头开始重新评估”) 会更好。全体客户端团队的大致共识是，这个漏洞不值得采取如此激烈的措施，对升级进行更多的测试和检测应该足够了。

作为提醒，如果你认为你发现伦敦升级有问题，在分叉前，在 bounty.ethereum.org 提交会有双倍的奖励 💰

最后，如果你想在未来协助防止此类漏洞，以太坊基金会正在招募一名新的测试工程师。这个职位是完全远程的，工作时间灵活，并会与以太坊基金会的测试团队和多个客户端团队里的核心开发者一起工作！你可以在此处申请。

观看派对 📺

如果你想关注伦敦升级的最新情况，下周会有多个不同的观看派对：

• 北京时间 8 月 3 日 00:00：Ethereum Cat Herder 组织的社区会议 😸

  • 在这个会议里，多名核心开发者以及 EIP 的倡导者会给大家重温此次升级会带来的多项变更；

• 8 月 3 日：Bankless 的 EIP-1559 座谈会之夜🏦

  • 由 Bankless 主持，他们会与参与 EIP-1559 的一些研究员和实现者一起深入讨论 1559；

• 8 月 4 /5 日：Ethstaker 伦敦升级上线派对🎉

  • 如果你想与其他社区成员一起观看伦敦升级上线，这就是你要选的派对了！

EIP-3675 📝

合并现在有一份 EIP了！EIP-3675 说明的是执行层 (eth1) 所需的修改，以便为合并做好准备。它与在共识层 (eth2) 规范里的 merge 文件夹是成对的。

EIP-3675 最值得注意的地方大概是它的简洁性。从设计上看，执行层因应合并所需做出的修改量是非常少的。这意味着，它对现有应用的影响是很少的。换句话说，智能合约应该只需保持原样运行，而背后的共识算法将会从工作量证明变为权益证明。

也就是说，仍会有一些变更。以下是总览：

• 多个字段会被设为“0”，或它们的等效编码，它们是：

  • ommersHash 和 ommers (PoS 系统里没有 ommer 区块);
  • extraData (在信标链里已经有 graffiti ，它就变成是多余的);
  • difficulty + mixHash + nonce (在 PoW 系统里使用的).

• DIFFICULTY: 考虑上述的变更，合并后操作码 DIFFICULTY 将总返回 0 ；

• BLOCKHASH：由这个操作码提供的伪随机性在合并后会因权益证明的特性变得 (甚至) 更不安全了

这份 EIP 目前还是草稿，还未合并，但如果你是在以太坊上做构建工作的，它仍然值得你去了解。我们在这个过程中仍处于早期阶段，如果理由充分，要做出重大变更还是可以考虑的。

路线图🗺

在最新的一次核心开发者会议上，EIP-3675 的作者Mikhail Kalinin 向客户端团队介绍了这份 EIP。在一轮技术讨论后，会议对从此时的进度到合并的路线图进行了更高层次的讨论。

想了解背景的话，值得看看这次会议视频或阅读会议记录 ，但简言之，我们对以下几点达成共识：

1. 进行伦敦升级

2. 专注于合并 (The Merge)，上线测试网

3. 基于在测试网上的非共识工作的数量 (例如，JSON RPC APIs、基础设施支持等)，有以下三个可能性：

   • 尽快合并 (不会轻易改变，除非有安全方面的原因，)；
   • 会有一次只推迟难度炸弹的网络升级，随后很快进行合并；
   • 进行网络升级，引入新的 EIP，并给社区一段较长的时间与测试网交互。

尽管我们当然注意到希望尽快合并的愿望，但在准备伦敦升级的工作过程中，有几个项目提到，他们希望在共识修改和上线主网之间有更长的时间。这样，在变更在主网部署以及最初的客户端行为确定下来之前，无论如何，像 API 这样的东西可以进行更多的迭代。

与此相关的一点是，这引发了一次关于我们应该如何命名所有这些升级的对话。如果你想参与，我已经在 Ethereum Magicians 论坛上开帖了🧙🏻‍♂️。

---

就这些内容了！预计在夏末会有下一次更新，一旦伦敦升级完成了，我们就会开始实现合并了☀️

---

发布于 2021 年 7 月 29 日

---

[0] 注：以当下的 baseFeePerGas，此笔交易的账户里仍有足够的 ETH 支付执行。 maxFeePerGas 被设得很高，因此如果 baseFeePerGas 已经被设的更高，账户可能就没有足够的 ETH 被执行了。如果是这样的情况，交易无法通过另一个有效性检查。

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[email protected]进行授权。