原作者: パリソシュ

元のソース:notes.ethereum.org

まとめ

まとめ

要約する

要約する

統合されたテストネット Kintsugi は、運用開始から最初の数週間で一連の問題に遭遇し、複数のクライアントにわたっていくつかの脆弱性が明らかになりました。この問題は主に、開発者 Marius によって開発されたファザーによって引き起こされます。このファザーは、興味深いブロックを作成し、ネットワーク内でそのブロックをブロードキャストすることを目的としています。

このようなブロックblockHash(ブロック ハッシュ) はそのブロック ハッシュに置き換えられます。parentHash(親ブロックのハッシュ)。engine_executePayloadすべてのビルディングブロックとビルディングブロックがありますblockHashすべてのパラメータが必要です。 EL (実行層) クライアントは、これらのパラメータに基づいてブロックを構築する必要があります。blockHash認証中。この特定のブロックは Geth のチェックには正しく失敗しましたが、Nethermind と Besu のチェックには合格しました。 Nethermind ではキャッシュの問題によりブロックが誤って検証されましたが、Besu にはそのようなチェックがまったくありません。その結果、ブロックは Lighthouse-Besu ノードによって提案され、ブロックチェーンが 2 つに分岐し、一方のフォークでは実行レベルで検証データが Nethermind または Besu に接続され、一方のフォークでは検証データが Geth に接続されました。 。

現在のブロックを確認することに注意してください。blockHashはマージの新しい要件であるため、一部のクライアントでは検証が欠落しているか、不正確になります。

Geth の問題は、間違ったペイロードを実行すると、代わりに JSON-RPC エラーが返されることです。INVALID(機能しません)、そして Teku の問題 (修正されていますが、現時点では展開されていません) は、それらのバグが楽観的同期モードでは許容できることです。したがって、Teku-Geth ノードは無効な負荷が発生した場合でもオプティミスティック同期モードになります。ブロック自体は有効であるため、接続された Geth ノードは、engineAPI ではなくネットワークからデータをフェッチするため、Teku-Geth ノードは無効なフォーク上にあります。 Teku ノードはまだ多くのバグを含む古いバージョンを使用しているため、Teku-Geth ノードはオプティミスティック同期モードのままで、ブロックチェーンのファイナライズが停止している期間はブロックの提案を拒否します。現在、コンセンサス層クライアント (lighthouse、prysm、nimbus、lodestar) - Geth (約 46%) とコンセンサス層クライアント - Nethermind/Besu (約 19%) が異なるフォーク上にあり、残りのバリデーターが実行されている状況です。 Teku-Geth (約 35%) は楽観的同期モードです。

Nethermind ノードと Besu ノードの修正を見つけてデプロイした後、それらを正しいチェーンに戻すことができました。 Teku-Geth ノードの更新により、ブロック順序の検証に関連する Geth の問題が原因で、無効なメモリ アクセスに関連する別の問題が発生しました。この特定の脆弱性は、Marius のファザーによっても引き起こされました。parentRoot有効であり、block_number=1ブロック。 Geth はブロックを実行する前に、その親ブロックを調べて、同期する必要があるかどうかを確認する必要があります。これを行う 1 つの方法は、キャッシュをチェックインすることですparentHashそしてparentHashそしてblockNumber。 Teku はすべてのフォークですべてのロードを同時に実行するため、キャッシュにはparentHash。したがって、Geth はparentHash を渡そうとします。blockNumberその親ブロックを見つけます。ただし、データベースにはこの blockNumber のハッシュがありません (このブロックはファザーによって構築されます)。 Geth は、親ブロックがないため、同期をオンにする必要があると推測します。ただし、この方法でトリガーされた同期は、権限のあるチェーンよりも短いチェーンを同期しようとするため、Geth の特定の条件に違反し、Geth プロセス エラーが発生し、ノードがシャットダウンされ、Teku-Geth ノードは常に異常な状態になります。

上記の問題のデバッグ中に、Geth チームはマージされたコード ベース内でエラーを引き起こす競合状態も発見しました。さらに、他の問題もありました。Nimbus にはエグゼクティブ層の再接続に関連するバグがあり、Lodestar はブロックの生成を拒否したピアのスコアを下げていました。

最初のレベルのタイトル

FAQ

Q: このテストネットは廃止されましたか?

A:いいえ。修正をデプロイし、いくつかの停滞ノードを再同期した後、最終的にチェーンが再びファイナライズを開始しました。チェーンの回復が完了すると、通常どおり動作することができます。現在、Kintsugi の参加率は約 99% であり、すべてのクライアントにパッチが適用され、ネットワークが正常に機能していることを示しています。トランザクションとスマート コントラクトの相互作用は通常どおり機能し続けます。

Q: このチェーンが長い間完成していないのはなぜですか?

A:私たちは根本原因を早期に発見しましたが、チェーンを未完成のままにして、クライアント チームがコードをデバッグできるようにしたいと考えていました。さらに、ファイナライズ前の期間中にクライアントのパフォーマンス データを収集したいと考えていました。

Q: フォークされたチェーン上のバリデーターはスラッシュされますか?

A:しません。各ベリファイアにはスラッシュ保護データベースが含まれており、これにより、ベリファイアがスラッシュの可能性があるメッセージに署名しないことが保証されます。 「間違った」フォーク上のバリデータは、「正しい」フォーク上でのみ非アクティブとみなされます。 「正しい」フォークに再グループ化すると、スラッシュ データベースによってスラッシュ可能なメッセージに署名できなくなります。

Q: これはメインネットの立ち上げにどのような影響を与えますか?新たな遅延は発生するのでしょうか？

A:この問題がメインネットの立ち上げ計画に影響を与えるとは考えていません。仕様自体には重大な問題は見つかりませんでした。テストネットの目的はバグを見つけることであり、Kintsugi はクライアント実装のエッジケースを見つけるのに優れた仕事をしていると考えています。このイベントは、複数のクライアントの組み合わせに対する優れたストレス テストです。メインネットにマージする準備ができたときにガイドとなる公開チェックリストがあります。

Q: これはテスト計画にどのような影響を与えますか?

A:強制的に未ファイナライズ状態になるいくつかのテストネットの作成を検討します。これらの未完成のテストネットで継続的にテストを行うことで、より多くのエッジケースをトリガーし、ツールを改善することができます。このインシデントで見つかった脆弱性は、回帰テストに合格することを確認するために静的テスト ケースとして追加されます。

バリデーター、インフラストラクチャープロバイダー、ツール開発者にとって重要な影響:

テストネットの未完了期間は、最悪の場合のハードウェア要件に関するいくつかの仮定を強化します。未完了期間中、バリデーターは次のことを期待する必要があります。

• 複数のフォーク選択ルールを評価する必要があるため、CPU 負荷が増加します (場合によっては最大 100%)。

• 非ファイナライズ期間中はプルーニングがないため、HDD の使用量が増加します。

• RAM 使用量がわずかに増加します

これは、同じマシン上で追加のツールや監視を実行すると、リソースの競合が発生することを意味します。 Kintsugi テストネットのツール (ブロック エクスプローラー、フォーセット、RPC) は、3 つのノードを持つ Kubernetes クラスター上で実行されます。このクラスターは、いくつかのツールで使用されるビーコン ノードも実行します。ビーコン ノードはプロビジョニングされたリソースよりもはるかに多くのリソースを使用するため、リソース不足によりツールが低下した状態で実行されることがよくあります。インフラストラクチャ プロバイダーは、コンセンサス層と実行層を別のマシンで実行するか、リソース使用量を厳密に定義することが賢明です。

マージとは、各コンセンサス層クライアントが独自の実行層クライアントを実行する必要があることを意味します。実行層クライアント (メインネット上) は、大量のディスク容量を必要とするようになりました。 CL のディスク使用量は、非ファイナライズ期間中に急増する可能性があり、ディスク容量不足によるクラッシュにつながる可能性があります。すべてのバリデーターは、この種の問題に対処するのに十分な大きさのバッファー ディスク領域があることを確認する必要があります。

ファイナリティに依存するツール開発者は、非ファイナライゼーション期間について特別な考慮を払う必要があります。考えられる 1 つの方法は、次のように示すことですoptimistic情報は、その情報をユーザーインターフェースで伝えながら変化していきます。