缘由针对上面的两个问题，Geth 客户端团队的领导者 Péter Szilágyi@peter_szilagyi 都有回应。
Peter 的回应也引起了不同的反应。一位门罗社区的人表示，在 2017 年，他们也曾因为同样的顾虑而选择了静默修复 bug。当然，也有人认为，选择静默修复是对的，但至少应该通知大型基础设施的提供者，只要联系了，就能大幅减少这一漏洞所造成的破坏。 北京时间 12 日凌晨 5:34，Peter 发布了《Geth v1.9.17 客户端所造成破坏的事后报告》，定位了问题的来源：发布于 2019 年 11 月 7 日的 Geth v1.9.7 错误实现了 EIP-211；John Youngseok Yang 在 2020 年 7 月 15 日报告了该问题，于是 Geth 团队在 7 月 20 日更新的 v1.9.17 版本中修复了这个问题。该次修复使得 Geth 客户端在执行涉及相关规则的交易时能跟其他以太坊客户端（如 Besu、Nethermind）相一致，但却使 v1.9.17 版本与历史版本的 Geth 发生了不一致。 如 Peter 所述，这个过程完全不是为了引入某个以太坊社区不知道或者不同意的共识规则，仅仅是因为写了 bug 所以必须修复 bug。除非你管写了 bug 也叫 「硬分叉」，否则就没有理由管修复 bug 叫 「硬分叉」（Nikita 显然不同意这一点，他表示这里就是发生了两次，而不是一次，硬分叉）。 其次，到底怎么发布修复，实际上并不简单。以太坊的硬分叉协调也需要很长时间。如果公开一个带有严重危险性的 bug，在各节点升级的过程中难保不会有人尝试攻击。作为客户端开发者，他考虑的更多是以太坊网络的安全性，而不是某个服务的安全性。而且，他们也并不是对所有的 bug 都采取同样的静默修复措施，很多都是公开修复的。 12 日上午 7:11，Optimism 团队的 Jing is hiring for Optimism@jinglanW 出来披露了更多信息：他们在 6 个月前复制了 Geth 客户端的代码库来研究和开发 Optimistic Virtual Machine，在该过程中，他们发现了一个神秘的 bug，也修复了该 bug，但一直无法定位其来源；他们一直以为，这个 bug 可能跟团队引入的定制化改进有关，但 11 号他们开始怀疑错误就存在于旧版的 geth 客户端中，而不是因为他们引入了一些改进。于是他们看了 ethernodes.org 显示的节点分布（并发现绝大多数节点已经升级）之后，就决定在主网上测试该 bug。因此有了后面的事情。 (责任编辑：admin) |