看法 | 怎样对待 Infura 效劳崩溃及其形成的影响？_数字货币

[2021-02-02 15:51:16] 来源：编辑：wangjia 点击量：

评论 点击收藏

导读： 比特币向左，以太坊向右，POW和POS你站哪一边？捧高PoS，压低PoW，V神是为了给以太坊2.0造势？事宜经由北京时候 2020 年 11 月 11 日下昼，以太坊社区着名的节点效劳 Infu

比特币向左，以太坊向右，POW和POS你站哪一边？

捧高PoS，压低PoW，V神是为了给以太坊2.0造势？

事宜经由

北京时候 2020 年 11 月 11 日下昼，以太坊社区着名的节点效劳 Infura 被曝出 API 效劳失足，并因而致使了多个依靠于 Infura 来构建的效劳的崩溃，或许前端显现不正确。

就 Infura 本身而言，能够把它明白为一个公然的以太坊节点，这个节点会吸收请求并返回肯定的效劳，比方帮助转发作意业务、比方搜检某笔生意业务上链了没有，又或许某个账户的状况怎样。实际上，只需本身布置一个以太坊节点，就可以供应跟 Infura 一样的效劳。但它的特别性在于，Infura 的大部分效劳都是免费的，因而许多效劳（包括生意业务所）都挑选了依靠 Infura 来向本身播报以太坊区块链的状况，免去了本身布置节点的贫苦。

也正因而，Infura 失足，理论上触及面会很广，在事宜发散的历程当中，以至还有人扬言 “以太坊会分叉（或许正在发作分叉）”。来由是两个差别的区块浏览器（Etherscan 和 Blockchair）上，对同一个块高显现了两个差别的区块（然则这两个区块以后的区块，两个浏览器的显现是一致的）。

但很明显，以太坊基础没有分叉。从事实上来讲，两个区块浏览器所显现的后续区块都是雷同的，这示意出块的矿工（至少是大部分矿工）没有以两个差别的区块为父块来继承挖矿，也没有相互谢绝对方的区块。从理论上来讲，只要出块的节点相互之间运用了差别的共鸣划定规矩（因而会谢绝对方所出的块），且都占有了肯定的算力，才有大概构成分叉。

事实上，人们很快就发明了，这是由于 Infura 没有运转最新版本的 Geth 客户端，而某些特别的生意业务触发了这个版本的客户端的 bug，使之宕机了。Blockchair 也是同理。所以很快就有人出来号令人人尽快升级 Geth 客户端。

至北京时候 11 日 18 时，Blockchair 团队的 Nikita Zhavoronkov@nikzh 宣布推特，诠释事宜的因果关系：

以太坊开发者某一次对代码的变动致使了当日以太坊区块链的破裂，破裂自区块高度 11234873 入手下手；没有更新客户端的效劳商，包括 Blockchair 和 Infura，就因而受益，被留在了一个少数人构成的链上（该链在 2 小时内出了 30 个块）从技术上来讲，这意味着发作了一次 “未公然的硬分叉（unannounced hard fork）” 修复步伐是升级 geth 客户端并运转 debug.setHead(11234872)

他还示意，这件事毫不应被低估，应当被认为是 The DAO 事宜以后，以太坊区块链上最严峻的一次变乱。

确切很新鲜，为何会有某个毛病仅仅致使软件在某个时候之前的汗青版本崩溃而现有版本不崩溃？这难道意味着，差别版本的 geth 客户端的共鸣划定规矩实际上不一样，也就是某时某刻发作了一次不能向后兼容的共鸣划定规矩转变（“硬分叉”）？另外，一个 Infura 的崩溃就致使了大面积的效劳失足，这是不是意味着 Infura 已成了一个 “单点故障” 泉源？

针对上面的两个问题，Geth 客户端团队的领导者 Péter Szilágyi@peter_szilagyi 都有回应。

从技术上来讲，确实能够说是发作了 “未公然的硬分叉”，但这只是由于开发人员修复了一个甜睡了两年多的 bug，而由于忧郁公然表露这个 bug 会致使以太坊遭到进击，所以挑选了寂静修复。人们也不应蔑视 Infura 没有运用最新的 Geth 客户端。从运营者的角度，不紧跟软件的最新版本是理性的。而依靠于 Infura 的效劳，是本身把这个权益交出去了，而不是他人制止了你运转节点，所以也没什么可埋怨的。

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。因而有了背面的事变。

所以，实际上，是 Optimism 团队发明了一个 bug，草率地决议在主网上测试该 bug 还存不存在，再加上 Geth 团队此前挑选了寂静修复该 bug，才使得某些没有实时升级的节点失足了。

该怎样明白和对待这件事变呢？

就事变的本因来看，这是由于客户端团队挑选了寂静修复一个甜睡了好久的 bug。虽然许多人认为 geth 团队能够经由过程联络基础设施供应者来下降损坏，但我在这里照样认为，我们应当给客户端开发人员更多的信托和尊重。我置信 Geth 客户端团队这么做是有来由的，他们晓得绝大部分节点都在运用本身的软件，也斟酌了 bug 的甜睡时候，因而挑选了寂静修复。从预先诸葛亮的角度，固然提早关照了大的基础设施供应者会更好，损坏会更少。然则，如许隐恶扬善合理吗？为何依靠于 Infura 的效劳不假定 Infura 大概崩溃？

我认可我在这里不太公平，但更公平的话，也有许多人已说过了。我在此只想表达我对 geth 客户端团队的敬意。我情愿把印象分给他们，由于他们在过去供应了许许多多的工作量证实。他们值得人人的尊重。

在寂静修复步伐的实行上，固然存在提高的空间，也应当跟包括门罗和比特币社区进修履历。但假如只想着责难 geth 团队，以致以阴谋论来推断他们，那才是更大的不公平。

关于 “Infura 是不是成为了单点故障的泉源”，也分简朴的回覆和庞杂的回覆。简朴的回覆是，不是，由于就像 Peter 所说，历来没有人制止你布置节点，只是许多供应商本身挑选了外包。Infura 不是设想层面上必需经由的一个单点。只是由于林林总总的缘由，它成了多是最大的节点效劳供应商。

但庞杂的回覆是，以太坊节点的资本斲丧比较大，确切是一个被低估的问题。以太坊协定的运转须要各节点完整实行区块中包括的生意业务，而实行生意业务必需从状况数据中掏出数据、而且完成后也要将效果写入，这个历程会触及大批的硬盘随机读写。而且，跟着状况数据体量的扩展，读写的效力请求也会提高。前些年热议的 “状况膨胀” 问题，在当前的以太坊上还没有处理。运转节点的门坎高，节点的数目天然就少。从好心的角度看，假如以太坊节点的运转门坎下降，我置信会有更多人自建节点（毕竟更平安），而不是挑选依靠于 Infura。

但这个问题的处理，一样依靠于以太坊客户端开发者和研讨人员的伶俐。无状况性，能够说是处理状况膨胀问题的最终计划。而在最终计划变得可行之前，我们依然须要客户端开发者，为我们孝敬更高效力的客户端。

所以，确切发作了一件事，也确切暴露出了一些问题、指出了我们进修和提高的方向。但处理这些问题，离不开我们对社区中差别整体的明白和尊重。阔别阴谋论，阔别歹意和自作聪明的讽刺，弄清楚问题的泉源，思索其实质和革新计划。我们做的事变，才决议了我们是谁。