宽哥玩数码 Infura 服务崩溃及其造成的影响?,如何看待


宽哥玩数码 Infura 服务崩溃及其造成的影响?,如何看待
文章图片
免责声明:本文旨在传递更多市场信息 , 不构成任何投资建议 。 文章仅代表作者观点 , 不代表火星财经官方立场 。
小编:记得关注哦
来源:以太坊爱好者
宽哥玩数码 Infura 服务崩溃及其造成的影响?,如何看待
文章图片
事件经过
北京时间2020年11月11日下午 , 以太坊社区知名的节点服务Infura被曝出API服务出错 , 并因此导致了多个依赖于Infura来构建的服务的崩溃 , 或者前端显示不正确 。
就Infura自身而言 , 可以把它理解为一个公开的以太坊节点 , 这个节点会接收请求并返回一定的服务 , 比如帮忙转发交易、比如检查某笔交易上链了没有 , 又或者某个账户的状态如何 。 实际上 , 只要自己部署一个以太坊节点 , 就能提供跟Infura同样的服务 。 但它的特殊性在于 , Infura的大部分服务都是免费的 , 因此很多服务(包括交易所)都选择了依赖Infura来向自身播报以太坊区块链的状态 , 免去了自己部署节点的麻烦 。
也正因此 , Infura出错 , 理论上波及面会很广 , 在事件发散的过程中 , 甚至还有人扬言“以太坊会分叉(或者正在发生分叉)” 。 理由是两个不同的区块浏览器(Etherscan和Blockchair)上 , 对同一个块高显示了两个不同的区块(但是这两个区块之后的区块 , 两个浏览器的显示是一致的) 。
但很显然 , 以太坊根本没有分叉 。 从事实上来说 , 两个区块浏览器所显示的后续区块都是相同的 , 这表示出块的矿工(至少是大部分矿工)没有以两个不同的区块为父块来继续挖矿 , 也没有彼此拒绝对方的区块 。 从理论上来说 , 只有出块的节点彼此之间使用了不同的共识规则(因此会拒绝对方所出的块) , 且都占据了一定的算力 , 才有可能形成分叉 。
事实上 , 人们很快就发现了 , 这是因为Infura没有运行最新版本的Geth客户端 , 而某些特殊的交易触发了这个版本的客户端的bug , 使之宕机了 。 Blockchair也是同理 。 所以很快就有人出来呼吁大家尽快升级Geth客户端 。
至北京时间11日18时 , Blockchair团队的NikitaZhavoronkov@nikzh发表推特 , 解释事件的因果关系:
以太坊开发者某一次对代码的更改导致了当日以太坊区块链的分裂 , 分裂自区块高度11234873开始;没有更新客户端的服务商 , 包括Blockchair和Infura , 就因此受害 , 被留在了一个少数人组成的链上(该链在2小时内出了30个块)从技术上来说 , 这意味着发生了一次“未公开的硬分叉(unannouncedhardfork)”修复措施是升级geth客户端并运行debug.setHead(11234872)他还表示 , 这件事绝不该被低估 , 应该被认为是TheDAO事件之后 , 以太坊区块链上最严重的一次事故 。 确实很奇怪 , 为什么会有某个错误仅仅导致软件在某个时间以前的历史版本崩溃而现有版本不崩溃?这岂非意味着 , 不同版本的geth客户端的共识规则实际上不一样 , 也就是某时某刻发生了一次不能向后兼容的共识规则改变(“硬分叉”)?此外 , 一个Infura的崩溃就导致了大面积的服务出错 , 这是否意味着Infura已经成了一个“单点故障”来源?
缘由
针对上面的两个问题 , Geth客户端团队的领导者PéterSzilágyi@peter_szilagyi都有回应 。
从技术上来说 , 的确可以说是发生了“未公开的硬分叉” , 但这只是因为开发人员修复了一个沉睡了两年多的bug , 而因为担心公开披露这个bug会导致以太坊遭到攻击 , 所以选择了静默修复 。 人们也不该鄙视Infura没有使用最新的Geth客户端 。 从运营者的角度 , 不紧跟软件的最新版本是理性的 。 而依赖于Infura的服务 , 是自己把这个权利交出去了 , 而不是别人禁止了你运行节点 , 所以也没什么可抱怨的 。Peter的回应也引起了不同的反应 。 一位门罗社区的人表示 , 在2017年 , 他们也曾因为同样的顾虑而选择了静默修复bug 。 当然 , 也有人认为 , 选择静默修复是对的 , 但至少应该通知大型基础设施的提供者 , 只要联系了 , 就能大幅减少这一漏洞所造成的破坏 。