以太坊?OpenEthereum?单客户端在区块?#12244294?处发生的 Bug 导致当时的以太坊网络停机,并在问题区块产生后无法与网络保持同步。那么造成这个事故的原因究竟是什么呢?
先看触发了这个事故的交易:
https://eth.tokenview.com/cn/tx/0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247
这是一笔合约调用交易,是从 KuCoin 交易所向其他地址分发ETH。
今日恐慌与贪婪指数为45 恐慌程度略有加剧:据Alternative.me数据显示,今日恐慌与贪婪指数为45(昨日为46),恐慌程度略有加剧,等级仍为恐慌。恐慌指数由0至100,其中0表示“极度恐惧”,而100表示“极度贪婪”。[2020/9/26]
我们仔细分析一下合约调用过程:
在浏览器的“数据输入”栏展示的是合约调用的参数,第一行表示地址列表从“40”(16进制)字节,也就是 64 字节开始,图中第4行,第二行表示转移数额的列表从“1a0”(16进制)字节,也就是 416 字节开始,数据输入栏第15行。
调查:少数用户在DeFi耕作领域获利且面临极大风险:9月22日消息,加密数据网站CoinGecko发布一份调查发现,DeFi领域加密耕作盈利趋势仅限于少数用户,而这些用户所承担的风险可能比他们意识的要大。调查称,40%参与加密耕作的用户并不能自行阅读和评估智能合约代码风险。(Decrypt)[2020/9/22]
转账是按照地址列表的顺序进行的,往每个地址转入的数额和转移数据的列表一一对应的。
现在我们开始遍历地址列表,看第三行的“10” (16进制),表示的是即将为接下来的 16 个地址转入 ETH。
按照图上顺序,当数到第11个地址的时候,发现值是“10”。这个值会被认为是地址列表中的第11个地址,然而事实上是表示转移数额的列表长度。那么按照第三行的指示,应该向 16 个地址转入,合约会把“0x10”当成地址继续执行转账操作,向地址“0x10”转入 0 个 ETH。
注意,“0x10”是EVM “特殊地址” 之一,它完全处在 EVM 的预编译合约列表内。它是一个由 EIP-2537 断言的预编译合约,是为 BLS 配对密码学程序而设的,但这个 EIP 还未部署到主网上。
那么在柏林硬分叉中给“0x10”发送 0 ETH 会造成什么呢?会造成 Gas 消耗产生分歧。
柏林硬分叉改变了 EVM 中 Gas 消耗量的计量方法。在 EIP-2929 实施后,如果在一笔交易中对同一个存储槽多次执行状态存储操作,第一次执行会消耗更多 Gas,后续执行的消耗会更少。
这就是OpenEthereum 在区块 #12244294 处发生 Bug 的根源:OpenEthereum包含了EVM已实现的预编译列表。所以OpenEthereum 会对该笔交易中访问了“0x10”的交易给gas 折扣。但网络的绝大部分活跃客户端都不是这样实现 EIP-2929 的,它们只会给访问了已激活预编译合约的交易提供 gas 折扣。
由此,OpenEthereum 客户端对该交易消耗了多少 Gas 的计算与网络中其他客户端发生了分歧。
这场由Gas消耗分歧引起的 OpenEthereum 单客户端停机,虽没有严重到导致重大的链分叉,但也提醒我们利用多客户端实现来提升节点稳定性。
不可否认,区块链技术仍然处于不断尝试不断前进的过程中,2021 年爆发的Defi和NFT也以前所未有的速度普及给更多的受众,Tokenview希望携手更多的开发者打造更好的区块链世界。
郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。