Berlin hard fork bug由于“0x10”地址的气体消耗差异

雍和比特币 OpenEthereum 在区块 #12244294 处产生 Bug 的本源：OpenEthereum包括了EVM已完成的预编译列表! 以太坊区块中的单一客户；上的过错导致以太坊其时网络中止，生成问题块后无法与网络坚持同步。事端的原因是什么？运用；Tokenview 以太坊浏览器，用于检查触发事端的业务：https://eth.tokenview.com/cn/tx/0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247这是一种合约呼叫买卖，将eth从kucoin买卖所分配到其他地址。让咱们仔细分析一下合同调用进程1在浏览器的“数据输入”列中，将显现合同调用的参数。榜首行表明地址列表从“40”（十六进制）字节开端，即64字节，图中第四行表明传输量列表从“1a0”（十六进制）字节开端，即416字节，数据输入列从第15行开端。2依照地址列表的次序进行传输，传输到每个地址的量与传输数据列表一一对应。3现在咱们开端遍历地址列表并检查第三行中的“10”（十六进制），这意味着咱们将把接下来的16个地址搬运到eth。依据数字的次序，当数字到达10时，值变为“10”。该值实际上是表明传输量的列表的长度。可是，依据第三行中的阐明，它应该搬运到16个地址，因而预定将持续履行以“0x10”为地址的搬运操作，并将0 eth搬运到地址“0x10”。实际上，“0x10”是EVM的“特别地址”之一，它彻底在EVM的预编译合同列表中。它是由eip-2537断语的预编译契约，是为BLS配对加密程序设计的，可是该eip没有布置到主网。那么，假如0eth被发送到柏林硬分叉的“0x10”，将会产生什么呢？这将导致天然气消费的分解。“0x10”地址的耗气量误差Berlin硬分叉改变了EVM中气体耗费的测量方法。在eip-2929完成之后，假如在一个业务中屡次在同一个存储槽上履行状况存储操作，则榜首次履即将耗费更多的气体，而随后的履即将耗费更少的气体。这是；openeithem在block#12244294的bug的根本原因：openeithem包括EVM完成的预编译列表。因而，openem将对拜访“0x10”的业务给予gas扣头。但是，网络中的大多数活动客户机并没有以这种方法完成eip-2929。它们只对有权拜访激活的预编译合同的业务供给gas扣头。因而，openem客户端对业务耗费的气体量的核算与网络中其他客户端的不同。这种由用气量不合引起的单客户端中止不足以形成显着的链分叉，但也提示咱们选用多客户端完成来前进阻力。不可否认，区块链技能仍处于不断测验和前进的进程中。2021年defi和NFT的迸发也以史无前例的速度向更多观众传达。Tokenview期望与更多的开发者携手共创一个更好的区块链国际。