「0x10」アドレスのガス消費量の違いによるベルリンのハードフォークバグ

イーサリアム OpenEthereum ブロック内の単一クライアント #12244294このバグにより、イーサリアム ネットワークはその時点でシャットダウンし、問題のあるブロックが生成された後はネットワークに追いつくことができなくなりました。では、この事故の原因は何だったのでしょうか？

Tokenview Ethereum ブラウザを使用して、事故を引き起こしたトランザクションを表示します。https://eth.tokenview.com/cn/tx/0x7006f38fa2e6654fae1a781aefc5885fe0cb8f778b1add10636eaf7e34279247

これはKuCoin取引所から他のアドレスにETHを分配するコントラクトコールトランザクションです。

コントラクト呼び出しプロセスを注意深く分析してみましょう。

1. ブラウザの「データ入力」欄にコントラクトコールのパラメータが表示されます。1行目はアドレスリストが「40」(16進数)バイト、つまり64バイトから始まることを示しています。図の2行目は、データ入力欄の15行目の「1a0」（16進数）バイト、つまり416バイトから転送量のリストが始まることを示しています。

2. 転送はアドレスリストの順に行われ、各アドレスへの転送量は転送データのリストに 1 つずつ対応します。

3. 次に、アドレスリストのトラバースを開始します。3 行目の「10」（16 進数）に注目してください。これは、ETH を次の 16 アドレスに転送することを意味します。

図の順序に従い、10番目まで数えると、求められた値は「10」になります。この値は、実際には転送量を表すリストの長さです。しかし、3行目の指示によれば、16個のアドレスに転送する必要があり、その後、コントラクトはアドレスとして「0x10」を使用して転送操作を継続し、0 ETHをアドレス「0x10」に転送します。

実際、「0x10」は EVM の「特別なアドレス」の 1 つであり、完全に EVM のプリコンパイル済みコントラクトのリスト内にあります。これは、BLS ペアリング暗号化プログラム用に EIP-2537 によってアサートされたプリコンパイルされたコントラクトですが、この EIP はまだメインネットにデプロイされていません。

副題

「0x10」アドレスのガス消費量が発散

ベルリンのハードフォークにより、EVM におけるガス消費量の測定方法が変更されました。 EIP-2929 の実装後、トランザクション内の同じストレージ スロットで状態ストレージ操作が複数回実行されると、最初の実行ではより多くの Gas が消費され、その後の実行ではより少ない Gas が消費されます。

これは、ブロック #12244294 の OpenEthereum バグの原因です。OpenEthereum には、EVM 実装のプリコンパイルされたリストが含まれています。したがって、OpenEthereum は、このトランザクションで「0x10」にアクセスするトランザクションに対してガス割引を適用します。ただし、ネットワークのアクティブなクライアントのほとんどは、この方法では EIP-2929 を実装しておらず、アクティブ化されたプリコンパイル済みコントラクトにアクセスするトランザクションに対してのみガス割引を提供します。

その結果、トランザクションによって消費されたガスの量に関する OpenEthereum クライアントの計算は、ネットワーク内の他のクライアントとは異なりました。

ガス消費量の相違によって引き起こされるこの OpenEthereum シングルクライアントのダウンタイムは、大きなチェーンフォークを引き起こすほど深刻ではありませんが、耐性を向上させるためにマルチクライアント実装を使用する必要があることも思い出させます。

ブロックチェーン技術がまだ絶え間ない試みと進歩の過程にあることは否定できません.2021年に勃発したDefiとNFTも前例のないスピードでより多くの視聴者に普及するでしょう.Tokenviewはより多くの開発者と協力してより良いブロックを作成したいと考えています.チェーンワールド。