Medallaテストネットの「クラッシュ」イベントの全容が分かる記事

ソース |What’s New in Eth2

著者 | ベン・エジントン

ソース |著者 | ベン・エジントン

翻訳者注: Prysm クライアントを実行しているユーザーは、次のようにアップグレードする必要があります。

この問題は wnie2 計画外のアップデートであり、週末に Eth2 Medalla テスト ネットワークで発生したエピソードをレビューおよび分析します。前期。

私たちは、ほぼ 2 週間前の 8 月 4 日に、Eth2 メインネット仕様を実行する大規模なパブリック マルチクライアント テストネットとして Medalla を立ち上げました。 Medalla テストネットの概要については、以下を参照してください。

前期

しかし、金曜日の夜、私はバリデーターの参加率がダッシュボードの崖から落ちていくのを目にしました。数分以内に、アクティブなバリデーターは 22,000 から約 5,000 に減少し、ネットワーク内のバリデーターの約 80% が消滅しました。

したがって、この記事では、その後の影響と次のステップを含めて、この事件について概観します。

最初のレベルのタイトル

どうしたの？私たちは、ネットワーク内で Prysm クライアントを実行しているすべてのバリデーターが突然消失したことを発見しました。 Prysm は最もよく使用されているクライアントであるため、その結果は想像できます。Prysmatic チームは、

文書レポートRoughtime、インシデントの詳細とチームの対応が継続的に更新されます。私のメモとともにいくつかのハイライトを紹介します。

このイベントの原因は、クロック同期の問題です。 Prysm クライアントは Cloudflare の

時間を数えるために。この理由は (私の意見では) あまり明確ではありませんが、ラフタイムが時間を 4 時間未来にシフトし、それが 1 時間以上続いたことは明らかです。 Prysm クライアントのバリデーターは、突然時間が 4 時間短縮されたことに気づき、まだ存在しないブロックチェーンのブロックと証明を生成し続けました。

それだけでは壊滅的な影響を与えるほどではありません。多くのブロックが失われ、将来的に大量の証明に直面しても、残りのクライアントは依然として元のチェーン上に構築することができます。徐々に、Prysm ノードのクロックが調整されるにつれて、ネットワークに戻り始め、バリデーターの参加も増え始めました。ネットワークは正常に戻りつつあるようです。

しかし数時間後、状況は急変した。

最初の時間から 4 時間後、さらに 2 つのことが起こりました。まず、将来的にすべての Prysm クライアントによって生成されるプルーフが有効になり始めます。第二に、ネットワークに再参加する Prysm ノードは、矛盾する証明を生成するのを防ぐためにスラッシュ保護メカニズムがトリガーされたため、再び消滅し始めました。

これら 2 つのことが同時に発生し、ネットワークは混乱に陥りました。残りのクライアントは受信した情報を処理するのに依然として苦労しており、ビーコン チェーンは枝分かれしたジャングルと化しました。 (Prysmatic チームの Raul は、Prysm の最初の修正のバグが事態を悪化させたと私に言いました)

一定期間、ネットワーク内の情報は依然として管理されています。しかし、その後 24 時間ほどで、ますます複雑になり混沌とした分岐点をナビゲートするために必要なメモリと CPU が膨大になってきました。 Lighthouse クライアントが 30 GB のメモリ (通常の約 100 倍) を使用しているのを見ましたが、Teku クライアントの場合、12 GB の Java メモリ ヒープを使用してプロセッサを最大にしても、問題が発生しました。 Eth2Statsこれはすべて週末に行われることに注意してください。最前線で戦っているすべての顧客チームに感謝します ノードが混沌としたネットワークに対処するには、メモリと効率を常に最適化する必要があります。

現在のところ、ネットワークは徐々に復旧しています。ユーザーからの報告はまちまちですが、Prysm と Lighthouse の新しいバージョンでは、たまたま正しいチェーン ヘッダーを見つけて、ビーコン チェーンの構築を続行できただけです。

現在、一部のノードにはチェーン ヘッドまたは近くの Lighthouse、Prysm、Teku ノードが表示されています。 Teku の最適化を継続して、同期に必要なリソースを削減していきます。

コンセンサス違反は発生しませんでした

1 つ明確にしておきたいのは、クライアント間でコンセンサス障害が発生しないということです。つまり、ネットワークが復元されると、すべてのクライアントがチェーン ヘッドの状態についてコンセンサスに達することができます。これは、ビーコン チェーンが基本的に失敗しないことを意味します。ハード フォークが必要です。

レッスン体験

このエピソードを十分に考察し、要約するためにさらに時間をかけていきます。以下は私の個人的な意見の一部です。時刻同期の重要性。

サードパーティのタイム サービスへの依存度が高いことは、ネットワークにとって致命的な点です。偶然にも、ConsenSys TX/RX 研究チームの Alex Vlasov 氏は、イーサリアム 2.0 ネットワークにおける時刻同期とその重要性について説明する詳細な記事を以前に執筆しています。彼の仕事は急速に進んでおり、おそらくこれは誰もがこの側面に注目する機会でもあります。ここが彼のです

関連記事と ethresear.ch の投稿

クライアントの多様性の重要性

理想的には、4 つ以上の独立したクライアントがあり、各クライアント ノードがネットワークの 30% を超えないようにします。そうすれば、たとえ 1 人のクライアントに問題があったとしても、注意を引くほどの影響はありません。

たとえこの理想を達成できなかったとしても、個々のクライアントによる極端な使用量を減らすことでネットワークはより堅牢になります。今回はバリデーターの 80% ではなく 50% のみがオフラインになったと仮定すると、ネットワークはより簡単に回復します。これは、クライアントに問題があると、ネットワークのブロック生成、プルーフ パッケージング、ブロードキャスト効率、ポイントツーポイント通信、同期に影響を及ぼし、これらの要因が残りの部分にも波及効果を及ぼすためです。バリデーター。

バックアップ計画の有効性一部のステーカーは、署名キーを他のクライアントのホット バックアップ ノードに切り替えることができます。これは確かに優れたセキュリティ ネットワークになりますが、スラッシュを避けるように注意する必要があります。新しいバリデーターは既存のバリデーターの投票履歴について何も知らない可能性があるため、反対票を投じる可能性があります。将来的には、それが完了したら、

新しいAPI

、キーだけでなく、異なるビーコン ノード間でバリデータ クライアントを切り替える機能を有効にする必要があります。たとえば、Prysm バリデーターは、Prysm ビーコン ノードから簡単に接続を解除し、Teku ビーコン ノードに再接続できます。これにより、前述のスラッシュの問題を解決できます。

ステークホルダーの責任感

現時点では、Eth2 への参加は「一度行ったら終わり」というものではありません。ステーカーは一定の注意を維持し、フォーラム間を歩き回り、開発者にフィードバックを提供し、短時間でクライアントを更新できる必要があります。私は個人バリデーターを実行する人々を非常に支持しますが、それは彼らが自分たちの責任を認識している場合に限ります。

急ぎは無駄を生む金曜の夜はいつも物事がうまくいかないのはなぜですか?現時点でも、Prysmatic チームからの反応は驚くべきものでした。詳しくはチームのお知らせをご覧ください

事故報告書

。私が以下で言うことは、本当に良い仕事をした Prysmatic チームに否定的な光を当てることを意図したものではなく、Teku チームが同様の状況に直面したときに経験を提供することを目的としています。

非常に多くのユーザーが（たとえそれがテストコインであっても）資産を失い、ネットワークが高いプレッシャーにさらされている場合、迅速に対応したいと思うのは自然なことですが、性急な行動は時には逆効果になる可能性があります。

この事件では 2 つのことが避けられました。まず、初期修正リリース Alpha.21 にはバグがあり、ユーザーは 17 時間後にロールバックする必要がありました。

Prysmatic チームの Raul 氏によると、この欠陥がその後のネットワーク混乱の原因でした。第二に、チームは状況に対処する際に 1,024 人のバリデーターのスラッシュプルーフ記録のデータベースを誤って削除し、その結果バリデーターの大部分がスラッシュされることになりました。

同様の状況はどのクライアントでも発生する可能性があります。したがって、たとえ高いプレッシャーの下であっても、開発者でもユーザーでも、私たち全員が冷静に対処し、盲目的にスピードを追求する必要はありません。そのため、ネットワークを復元しようとしたときは、ゆっくりと慎重なアプローチを採用しました。

問題を明らかにして将来のトラブルを回避する

結局のところ、このエピソードは実際には必要でした。何もテストされない場合、テストネットの意味は何でしょうか?常にスムーズに実行することは明らかに非現実的です。今回もすごい試練ですね！これはおそらくネットワークが受ける可能性のある最悪の種類のショックであり、私たちが自分で設計したとしても、おそらくそのようなテストを設計することはできないでしょう。テストネットをこのレベルの影響にさらすことは、まさにクライアントを強化するために必要なことです。先週

記事内のブロック

私の声明を引用すると、

PegaSys エンジニアの Ben Edgington 氏は電子メールの中で、Medalla が「メインネットの規模と構成を備えた最初のテストネットである」と書いています。実を言うと、。

次は何ですか？

あなたは何を楽しみにしていますか？

次は何ですか？

ウェブサイト: ethereum.cn

イーサリアムの詳細については、次の点に注意してください。

パブリックアカウント: ETH中国語ウェブサイト

ウェブサイト: ethereum.cn

免責事項: ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に属します。転載する場合は、原文と ethereum.cn の出典を示す必要があります。再版の場合はご連絡くださいethereumcn@gmail.com承認します。