12 日上午 7:11，Optimism 团队的 Jing is hiring for Optimism@jinglanW 出来披露了更多信息：他们在 6 个月前复制了 Geth 客户端的代码库来研究和开拓 Optimistic Virtual Machine，在该进程中，他们发明白一个神秘的 bug，也修复了该 bug，但一直无法定位其来历；他们一直觉得，这个 bug 大概跟团队引入的定制化改造有关，但 11 号他们开始猜疑错误就存在于旧版的 geth 客户端中，而不是因为他们引入了一些改造。于是他们看了 ethernodes.org 显示的节点漫衍（并发明绝大大都节点已经进级）之后，就抉择在主网上测试该 bug。因此有了后头的工作。
所以，确实产生了一件事，也确实袒暴露了一些问题、指出了我们进修和进步的偏向。但办理这些问题，离不开我们对社区中差异集体的领略和尊重。远离阴谋论，远离恶意和自作智慧的冷笑，弄清楚问题的来源，思考其实质和改造方案。我们做的工作，才抉择了我们是谁。
我认可我在这里不太合理，但更合理的话，也有许多人已经说过了。我在此只想表达我对 geth 客户端团队的敬意。我愿意把印象分给他们，因为他们在已往提供了许很多多的事情量证明。他们值得各人的尊敬。
ERC 20
该如何领略和对待这件工作呢？就工作的本因来看，这是因为客户端团队选择了静默修复一个甜睡了许久的 bug。固然许多人认为 geth 团队可以通过接洽基本设施提供者来低落粉碎，但我在这里照旧认为，我们应该给客户端开拓人员更多的信任和尊重。我相信 Geth 客户端团队这么做是有来由的，他们知道绝大部门节点都在利用本身的软件，也思量了 bug 的甜睡时间，因此选择了静默修复。从过后诸葛亮的角度，虽然提前通知了大的基本设施提供者会更好，粉碎会更少。可是，这样吹毛求疵公道吗？为什么依赖于 Infura 的处事不假设 Infura 大概瓦解？
ERC-721
以太坊开拓者某一次对代码的变动导致了当日以太坊区块链的破裂，破裂自区块高度 11234873 开始；
从技能上来说，简直可以说是产生了 「未果真的硬分叉」，但这只是因为开拓人员修复了一个甜睡了两年多的 bug，而因为担忧果真披露这个 bug 会导致以太坊遭到进攻，所以选择了静默修复。
撰文：阿剑关于 「Infura 是否成为了
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
