所以，实际上，是 Optimism 团队发现了一个 bug，草率地决定在主网上测试该 bug 还存不存在，再加上 Geth 团队此前选择了静默修复该 bug，才使得某些没有及时升级的节点出错了。

该如何理解和看待这件事情呢？

就事情的本因来看，这是因为客户端团队选择了静默修复一个沉睡了许久的 bug。虽然很多人认为 geth 团队可以通过联系基础设施提供者来降低破坏，但我在这里还是认为，我们应该给客户端开发人员更多的信任和尊重。我相信 Geth 客户端团队这么做是有理由的，他们知道绝大部分节点都在使用自己的软件，也考虑了 bug 的沉睡时间，因此选择了静默修复。从事后诸葛亮的角度，当然提前通知了大的基础设施提供者会更好，破坏会更少。但是，这样吹毛求疵合理吗？为什么依赖于 Infura 的服务不假设 Infura 可能崩溃？

我承认我在这里不太公正，但更公正的话，也有很多人已经说过了。我在此只想表达我对 geth 客户端团队的敬意。我愿意把印象分给他们，因为他们在过去提供了许许多多的工作量证明。他们值得大家的尊敬。

在静默修复措施的执行上，当然存在提高的空间，也应该跟包括门罗和比特币社区学习经验。但如果只想着谴责 geth 团队，乃至以阴谋论来揣度他们，那才是更大的不公正。

关于 「Infura 是否成为了单点故障的来源」，也分简单的回答和复杂的回答。简单的回答是，不是，因为就像 Peter 所说，从来没有人禁止你部署节点，只是很多提供商自己选择了外包。Infura 不是设计层面上必须经过的一个单点。只是因为各种各样的原因，它成了可能是最大的节点服务提供商。

但复杂的回答是，以太坊节点的资源消耗比较大，确实是一个被低估的问题。以太坊协议的运行需要各节点完全执行区块中包含的交易，而执行交易必须从状态数据中取出数据、并且完成后也要将结果写入，这个过程会涉及大量的硬盘随机读写。而且，随着状态数据体量的扩大，读写的效率要求也会提高。前些年热议的 「状态膨胀」 问题，在当前的以太坊上还没有解决。运行节点的门槛高，节点的数量自然就少。从善意的角度看，如果以太坊节点的运行门槛降低，我相信会有更多人自建节点（毕竟更安全），而不是选择依赖于 Infura。

但这个问题的解决，同样依赖于以太坊客户端开发者和研究人员的智慧。无状态性，可以说是解决状态膨胀问题的终极方案。而在终极方案变得可行之前，我们仍然需要客户端开发者，为我们贡献更高效率的客户端。

所以，确实发生了一件事，也确实暴露出了一些问题、指出了我们学习和进步的方向。但解决这些问题，离不开我们对社区中不同团体的理解和尊重。远离阴谋论，远离恶意和自作聪明的嘲讽，弄清楚问题的根源，思考其实质和改进方案。我们做的事情，才决定了我们是谁。 (责任编辑：admin)