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

以太坊区块中的单一客户；上的错误导致以太坊当时网络中断，生成问题块后无法与网络保持同步。事故的原因是什么？

使用；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希望与更多的开发者携手共创一个更好的区块链世界。