首页 手机兼职平台区块链正文

反思 The DAO 后以太坊最严重事故:Infura 是「单点故障」 来历吗?

admin 区块链 2020-11-24 10:31:07 9610 0

|Infura

20201111InfuraAPIInfura

就 Infura 本身而言,能够把它了解为一个揭露的以太坊节点,这个节点会接纳恳求并回来必定的服务,比方帮助转发买卖、比方查看某笔买卖上链了没有,又或许某个账户的状况怎样。实际上,只需自己布置一个以太坊节点,就能供给跟 Infura 相同的服务。但它的特别性在于,Infura 的大部分服务都是免费的,因而许多服务(包括买卖所)都挑选了依靠 Infura 来向本身播报以太坊区块链的状况,免去了自己布置节点的费事。

也正因而,Infura 犯错,理论上触及面会很广,在工作发散的进程中,甚至还有人扬言 「以太坊会分叉(或许正在产生分叉)」。理由是两个不同的区块浏览器(Etherscan 和 Blockchair)上,对同一个块高显现了两个不同的区块(可是这两个区块之后的区块,两个浏览器的显现是共同的)。

但很明显,以太坊底子没有分叉。从事实上来说,两个区块浏览器所显现的后续区块都是相同的,这表明出块的矿工(至少是大部分矿工)没有以两个不同的区块为父块来持续挖矿,也没有互相回绝对方的区块。从理论上来说,只需出块的节点互相之间运用了不同的一致规矩(因而会回绝对方所出的块),且都占有了必定的算力,才有或许构成分叉。

事实上,人们很快就发现了,这是由于 Infura 没有运转最新版别的 Geth 客户端,而某些特别的买卖触发了这个版别的客户端的 bug,使之宕机了。Blockchair 也是同理。所以很快就有人出来呼吁咱们赶快晋级 Geth 客户端。

至北京时刻 11 日 18 时,Blockchair 团队的 Nikita Zhavoronkov@nikzh 宣布推特,解说工作的因果关系:

  1. 以太坊开发者某一次对代码的更改导致了当日以太坊区块链的割裂,割裂自区块高度 11234873 开端;
  2. 没有更新客户端的服务商,包括 Blockchair 和 Infura,就因而受害,被留在了一个少数人组成的链上(该链在 2 小时内出了 30 个块)
  3. 从技术上来说,这意味着产生了一次 「未揭露的硬分叉(unannounced hard fork)」
  4. 修正办法是晋级 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。

但这个问题的处理,相同依靠于以太坊客户端开发者和研讨人员的才智。无状况性,能够说是处理状况胀大问题的终极计划。而在终极计划变得可行之前,咱们依然需求客户端开发者,为咱们奉献更高功率的客户端。

mp.weixin.qq.com

版权声明

本文仅代表作者观点,不代表网赚之家本站立场。
本文系作者授权发表,未经许可,不得转载。

评论