ベルリンアップグレード後の OpenEthereum クライアントエラーの技術的分析

元のタイトル: 「Popular Science | OpenEthereum クライアント「Berlin」のアップグレード後に発生したエラーの全容」
アレックス・ストークス
翻訳：アジアン

ご存知かもしれませんが、@OpenEthereum クライアントのバグにより、Ethereum ネットワークをサポートするいくつかの重要なサービスがダウンしました。

事故の原因となった取引について考えてみましょう。

まず、このインシデントに迅速に対応し、問題を解決してくれたすべてのエンジニアに感謝したいと思います。

また、私はすべての詳細を自分で追跡したわけではありませんが、以下の重要な事実は Eth R&D のユーザー eb によって提起されました。不和のサーバー。

エラーを引き起こしたトランザクションから始めましょう。

これは、KuCoin 取引所から送信され、ETH を多くのアドレスに配布する契約呼び出しトランザクションです。このトランザクションの呼び出しデータの ABI エンコーディングが正しくなかったため、最終的にチェーン分割が発生しました。このトランザクションの「入力データ」は Etherscan で確認できます。

1/ コントラクトで sendEths を呼び出すときは、2 つのパラメータを指定する必要があります。1 つはターゲット アドレスの動的にサイズが調整される配列です。もう 1 つは、転送量 (wei 単位) の動的サイズ配列です。これら 2 つを組み合わせることで、どのアドレスにいくら送金すればよいかがわかります。

2/ 通話データを解析して何が問題だったのかを確認できます。最初の行 (Etherscan では「[0]」としてマークされています) は、アドレス リストがバイト 64 (行「[2]」) から始まることを示しています。 2行目は、バイト416（行「[13]」）から始まる転送量のリストを示しています。

3/ つまり、一般的には、特定の量の ETH を上から下へペアで特定のアドレスに送信したいのですが、これは簡単なようです。

4/ ただし、このリストを調べ始めると、まず呼び出しデータの正しいバイトにジャンプし、Solidity ABI では、データの最初のワードが不定長配列全体の長さであると規定されています。

5/ これが最終的なバグの原因です。call data の値は「0x10」(16 進数であることに注意してください) ですが、call data は 10 個のアドレスと値のペアしか提供しないためです。この呼び出しデータの正しい ABI エンコーディング (行 [2] と [13] に入力) は、「0x10」ではなく「0xA」である必要があります。

6/ その時に何が起こるかはご想像のとおりですが、実行トレースで確認できます。

7/ 契約は最初の 10 個のアドレスを正常に通過します。この時点でコントラクトの実行は停止しているはずですが、呼び出しデータ ステートメントによると、まだ多くのアドレスが残っています。その後、実行を続行します。

ただし、呼び出しデータの構造によると、「11 番目のアドレス」は 0x10 であり、これはリストの長さをエンコードするために使用されるため、コントラクトは 0 ETH をアドレス 0x10 に送信しようとします。

8/ さらに、コントラクトが存在しない呼び出しデータを読み取ろうとすると、0 ETH が返されるようです。ここでコントラクトがエラーに遭遇したと考えられますが、呼び出しデータから読み取った他の 6 つの「アドレス」には 0 ETH が送信され続けました。

この時点で、0x10 は、EVM プリコンパイル済みコントラクトの範囲内にある、いわゆる「特別なアドレス」の 1 つである可能性が高いことに気付くかもしれません (いわゆる「プリコンパイル済みコントラクト」は、EVM 外部で最適な実装を持つ特殊なタイプのコントラクトですが、ほとんどのコントラクトと同様にコンパイルされます)。

また、プリコンパイルされたコントラクト 0x10 が ETH を返すことは想定されていません。このようにして、ETH ブラックホールになります。ただし、必ずしも問題が発生するわけではありません。クライアント全体がクラッシュした原因は何でしょうか?

その理由は、0x10 は実際には BLS ペアリング暗号化プログラム用に設計された EIP-2537 によってアサートされたコンパイル済みコントラクトですが、この EIP はまだメインネットに展開されていないためです。したがって、このアドレスとやり取りすることはできますが、メインネット上のこのアドレスには契約はなく、それ以上のアクションは実行されません。

さらに、この分裂を説明するために別の事実が必要です。それは、おそらく「ベルリン」ハードフォーク（この問題を表面化したハードフォークでもある）です。つまり、EVM でガス消費量を測定する方法が変更されたのです。

EIP-2929 が実装された後、トランザクション内で同じストレージ スロットに対して状態ストレージ操作を複数回実行すると、最初の実行ではより多くの Gas が消費され、後続の実行ではより少ない Gas が消費されます。この価格変更により、理論的には、クライアントがストレージ アイテムにアクセスするための現在のコストがより正確に反映されるはずです...

また、すべてのクライアント側実行では、このデータは多くの場合、より安価なハードウェア層に保存されることに注意してください。

現在、OpenEthereum のブロック #12244294 で発生したバグがようやく見つかりました。クライアントには、実装されたすべてのプリコンパイルが EIP-2929 アクセス リストの一部として含まれていました。 （翻訳者注：これは「EIP-2930」のはずです）

EIP-2537 はすでにほとんどのクライアントに実装されているため (ベルリン アップグレードに組み込むことが提案されていました)、OpenEthereum は 0x10 にアクセスするすべてのトランザクションにガス割引を提供します。

ただし、ネットワーク上のアクティブなクライアントのほとんどは、この方法で EIP-2929 を実装していません。アクティブ化されたプリコンパイル済みコントラクトにアクセスするトランザクションに対してのみガス割引を提供します。EIP-2537 は、まだアクティブ化されていないプリコンパイル済みコントラクトに属します。そのため、OpenEthereum クライアントによるトランザクションで消費された Gas 量の計算は、ネットワーク内の他のクライアントの計算とは異なっていました。

幸いなことに、@mhswende がすぐにバグを見つけ、@sorpaas が修正に取り組みました。

言うべきことはまだまだたくさんありますが、私よりも全体像をよく理解している人が、より良いレポートを書いてくれることを期待しています。

私が言えるのは、このバグはハードフォークの固有のリスクと、より回復力のあるインフラストラクチャの構築に継続的に取り組むことの重要性を浮き彫りにしているということです。

OpenEthereum クライアントに依存する単一クライアント システムは、問題のあるブロックの後にクライアントがネットワークに追いつけなかったため、本日ダウンタイムが発生しました。その結果、Etherscan 自体もダウンしました。

幸いなことに、このバグは大きなチェーンフォークを引き起こすほど深刻ではありませんが、可能性はまだ残っています。マルチクライアント実装を活用することで耐性を向上させることができます。これは、当社の Ethereum エコシステムの大きな強みであり、インフラストラクチャ プロバイダーにも同様の取り組みを促すことができます。

2021 年には前例のない導入が見られ、見通しは非常に明るいです。私たちはこの事件から教訓を学び、より良いイーサリアムを共に構築しなければなりません。