ETH:科普 | OpenEthereum客户端 “柏林” 升级后出错始末

AlexStokes@ralexstokes:

你可能已经听说了,@OpenEthereum客户端的一个错误导致了一些支撑以太坊网络的重要服务宕机。

我们来琢磨一下那笔造成事故的交易。

首先,我想感谢所有快速反应到事故并解决了问题的工程师:https://twitter.com/OpenEthereumOrg/status/1382719444833726470?s=20…

另外,我没有自己跟踪所有的细节,下文中的重要事实都由用户eb在EthR&Ddiscord服务器里提出。

先从那笔触发了错误的交易开始:https://etherscan.io/tx/0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247

欧易OKEx将于3月18日推出DeFi系列科普视频:据欧易OKEx官方消息显示,欧易OKEx将正式推出DeFi系列科普视频《欧易DeFi20讲》,本系列节目由欧易OKEx亚太区CEO马克金主讲。该视频首期将于3月18日11:00(HKT)推出,用户可以在欧易OKEx官方学院、金色财经观看。

《欧易DeFi20讲》主要包含DeFi入门指南、全景解读DeFi生态及如何参与DeFi三个篇章,可以轻松使用户了解DeFi原理,洞察DeFi价值,掌握DeFi热点,更多详情请关注欧易OKEx官方学院。[2021/3/18 18:55:59]

这是一笔合约调用交易,从KuCoin交易所发出,向许多地址分发ETH。该笔交易的calldata的ABI编码错误,最终导致了链分裂。你可以在Etherscan上看看这笔交易的“InputData”。

火币推出《一分钟读懂DeFi》系列科普视频:据官方消息,8月24日,火币推出《一分钟读懂DeFi》系列科普视频,并与微博财经合作冠名播出,布道DeFi认知,助力行业发展《一分钟读懂DeFi》是由火币成长学院打造的业内首个系统全面讲解DeFi的系列科普动画,继推出《区块链100问》后的再续佳作。《一分钟读懂DeFi》系列动画对DeFi的发展进行系统梳理,适合想要由浅入深、全面系统了解区块链DeFi的人们轻松了解DeFi。目前视频已由火币网官方微博发布。[2020/8/24]

1/在合约中调用sendEths时,需要提供两个参数:一个是关于目标地址的不定长数组;一个是关于转账数额的不定长数组;两者相搭配才知道要转移多少钱给哪个地址。

2/我们可以解析calldata来看看到底哪里出了错:第一行表示地址列表从字节64开始。第二行表示转移数额的列表从字节416开始。

声音 | 上海股交所总经理:区块链想要大规模发展要做好社会科普工作:金色财经报道,上海股交所总经理张云峰表示,区块链当前还处于一个“概念”的阶段,距离成熟应用,影响到百姓的日常生活还有很长的路要走。对于“区块链”和其会带来的社会和经济效果,沈阳应当持审慎的态度。区块链想要大规模发展,一方面要做好这项复杂技术的社会科普工作,加快社会大众对区块链的了解。另一方面,要充分发挥市场的作用,让企业用实实在在的技术创新,赋能实体经济的发展。[2019/11/17]

3/因此,大体上,我们是希望成对成对地、从上往下、向某个地址发送一定数量的ETH——看起来很直接嘛。

4/然而,当我们开始遍历这个列表,我们先跳转到calldata的正确字节,而SolidityABI声明了数据的第一个字是整个不定长数组的长度。

声音 | ETC Labs主管:科普教育是未来几年公链面临的巨大挑战:ETCLabs主管Darin Kotalik认为,科普教育是未来几年公链面临的巨大挑战,人们必须要对区块链有基本的认识,分清楚公链和私链的区别。[2019/8/25]

5/这就是最终bug的根源:因为calldada中的值是“0x10”,但是calldata只给出了10个地址-数值对。对这个calldata的正确ABI编码应该是“0xA”——不是“0x10”!

6/你可能已经猜到了那时候会发生什么事,我们可以通过执行情况跟踪器来看看:https://etherscan.io/vmtrace?txhash=0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247&type=parity

动态 | 美国演说家Anthony Robbins开始科普什么是比特币:美国演说家安东尼·罗宾(Anthony Robbins)在自己的网站上发布了一篇比特币的科普文章,并在推特上向自己的粉丝介绍什么是比特币,目前他的推特账户共有粉丝304万人。[2019/1/1]

7/合约成功地遍历了前10个地址。本来合约应该在此时停止执行,但根据calldata的声明,还有很多个地址!那就继续执行吧。

但是,根据calldata的结构,“第11个地址”是用于编码列表长度的0x10,所以合约就尝试发送0ETH到地址0x10。

8/此外,似乎,当合约尝试读取并不存在的calldata时,会返回0ETH——你可以想象成合约在这里跑出了一个错误,但它却继续发送0ETH到它从calldata中读取的另外6个“地址”。

此时,你可能会注意到,0x10有可能是我们所谓的“特殊地址”之一,它完全在EVM预编译合约的范围内。

而我们也并不期望预编译合约0x10能够返回ETH。如此,它就成了一个ETH黑洞。但是,这也并不必然造成任何问题。到底是什么导致了整个客户端崩溃?

原因在于,0x10实际上是一个由EIP-2537断言的预编译合约,是为BLS配对密码学程序而设的,但这个EIP还未部署到主网上。所以虽然你能够跟这个地址互动,但主网上的这个地址里没有任何合约,不会有任何进一步的动作。

此外,我们还需要一个事实来解释这次分裂,你可能也猜到了,就是“柏林”硬分叉:它改变了EVM中Gas消耗量的计量方法。

在EIP-2929实施后,如果你在一笔交易中对同一个存储槽多次执行状态存储操作,第一次执行会消耗更多Gas,后续执行的消耗会更少。这种重定价理论上能更准确地反映当前的客户端访问存储项的成本……

而且,要知道,在所有客户端的执行中,这些数据通常都换存在更便宜的硬件层中。

现在我们终于找到了OpenEthereum在区块#12244294处发生的Bug:该客户端包含了所有已实现的预编译,作为EIP-2929访问清单的一部分。

因为EIP-2537在大部分客户端中都已经实现就绪了,OpenEthereum对所有访问了0x10的交易都给了gas折扣。

但网络的绝大部分活跃客户端都不是这样实现EIP-2929的,它们只会给访问了已激活预编译合约的交易提供gas折扣——而EIP-2537属于还未激活的预编译合约!所以,OpenEthereum客户端对该交易消耗了多少Gas的计算与网络中其他客户端发生了分歧。

所幸,@mhswende很快找出了该bug,而@sorpaas出力修复了该bug:https://github.com/openethereum/openethereum/pull/364

还有很多东西可说,我也预期会有比我更能观察到全貌人来撰写更好的时候报告。

我能说的只是,这个bug彰显了硬分叉的内在风险,以及持续致力于建设更有弹性的基础设施的重要性。

依赖于OpenEthereum客户端的单客户端系统在今天停机了一段时间,因为客户端无法在问题区块出现后与网络保持同步。Etherscan自身也因此停机。

庆幸的是,这个bug没有严重到导致重大的链分叉,但这样的可能性并不是不存在。我们可以利用多客户端实现来提升抗性——多客户端本身就是我们以太坊生态的一大长处——并推动您的基础设施提供商也这样做。

我们已经看到,2021年的普及速度已经前所未有地快,而且前景非常光明。我们要从这个事故中吸取教训,一起打造更好的以太坊。

原文链接:https://twitter.com/ralexstokes/status/1382750001026146304作者:AlexStokes翻译:阿剑

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

地球链

[0:15ms0-1:145ms