イーサリアムマージテストネット金継ぎがバグで分割されました、理由はここにあります

イーサリアム ネットワーク上のマージ イベントは、現在採用されている Proof-of-Work モデルから Proof-of-Stake コンセンサス モデルへの移行です。 この合併は、現在のイーサリアムメインネットシステムとイーサリアム2.0と呼ばれることが多い新しいビーコンチェーンがXNUMXつのブロックチェーンに合併することを意味します。

マージをテストするために、Kintsugi テストネットが XNUMX 月にデプロイされました。 テストネットの目的は、さまざまなエッジ ケースを実行し、システムがどのように動作するかを観察することです。 Kintsugi でのテスト実行に携わった開発者の XNUMX 人は、次のとおりです。 マリウス・ファン・デル・ウィデン、Geth（Go-Ethereum）クライアントチームと協力しているEthereumコア開発者。

「テストネットは数週間完璧に動作しました。 先週、無効なブロックを送信するファザーを作成しました。 ブロックには、トランザクション、前のブロックのハッシュ、ガス制限など、多くの情報が含まれています」と、Marius van derWijden氏は言います。

一部の実装は、ブロックを実行および検証しませんでした

ファザーは、関数やその他のコードへのランダムな入力を生成し、何らかの方法でそれらを壊そうとするために開発者の間で使用される一般的なタイプのテストツールです。 それは、不正な形式の予期しない入力を生成し、システムに何が起こるかを監視することです。

van der Wijdenによって作成されたファザーは、有効なブロックを生成し、そのXNUMXつの要素を変更して無効にします。 使用する手法のXNUMXつは、要素を別の要素に変更することです。 この場合、ファザーはブロックハッシュを親ハッシュに変更しました。

「ノードは、そのような変更されたブロックを拒否する必要があります。 ただし、親ハッシュが有効なブロック自体を指しているため、一部の実装では実際にブロックを実行および検証せず、代わりにキャッシュで検索しました。 前のブロックが有効でキャッシュ内にあるため、新しいブロックも有効であると想定しました」とvan derWijden氏は説明します。

ネットワークがXNUMX回分割

その結果、ネットワークの半分であるGethクライアントがブロックを拒否し、残りの半分であるNethermind-およびBesuクライアントがそれを受け入れ、正しい状態のXNUMXつの異なるビューがあったため、チェーンが分割されました。 さらに悪いことに、上に別の問題がありました。

van der Wijdenによると、Gethチェーンノードは、Lighthouse-Geth、Prysm-Geth、Lodestar-Geth、Nimbus-Geth、およびTeku-Gethで構成されています。

「この分割はまだ調査中ですが、Tekuにもキャッシュメカニズムが失敗した可能性があります」とvan derWijden氏は言います。

この記事の執筆時点では、Kintsugi テストネットのいくつかの異なるフォークが存在し、すべてのノードが正しいフォーク上にあると考えているため、ネットワークはもうファイナライズしていません。

「ネットワークを元に戻すために何かを考えます。 Nethermindクライアントはすでに更新されており、これらのノードは現在正しいチェーン上にあります。 ノードの33％以上がTekuであるため、Tekuを修正する必要があります。そうしないと、チェーンが完成しません」とvan derWijden氏は言います。

事件はいくつかの良いものをもたらします

van der Wijdenによると、この事件はイーサリアムのマージのさらなるテストを禁止または遅らせることはなく、マージ自体を遅らせることもありません。 実際、van der Wijden氏によると、このインシデントは、ネットワークが適切に実行されているかどうかをテストするのが困難だったエッジケースをテストするのに実際に役立ちます。

「ノードにとって長期間の非ファイナライズは困難であり、ノードが現在どのように動作するかを確認することは非常に重要です。 テストネットは最終的には再び一緒になると思いますが、興味深いエッジケースをテストする機会が得られるため、手動で修正しようとは思いません。」

「マージはまだスケジュールされていないため、これによってマージが遅れることはないと思います。 しかし、それはテストがいかに重要であるかを示しています。 マージは本当に順調に進んでいると思います。 ソフトウェアを許容可能な状態にするためにさらに数週間必要であり、それからそれをテストするために数ヶ月必要です」とvan derWijden氏は言います。

これがメインネットで発生した場合はどうなりますか？

興味深い疑問は、このようなバグがメインチェーンで発生した場合はどうなるかということです。

「私たちはかなり早い段階でテストを開始したので、このようないくつかのバグが予想されました。 ただし、メインネットのこのようなバグはかなり厄介です。これは、私たちが得意とするバグを見つけて修正し、コードをリリースしてから、すべてのスタッカーにノードを更新する必要があることを知らせる必要があるためです。 最後の部分は私の意見では難しい部分です。一部のユーザーは開発をあまり厳密にフォローしていないためです」とvanderWijden氏は言います。

詳細については、興味のある読者は、Marius van derWijdenの つぶやき 事件について。