イーサリアム 2.0 メインネットの事故レビュー

出典 | Prysmatic Labs

副題

https://beaconcha.in/epoch/32302

事故の概要

エポック 32302 以降、ビーコン チェーンは多数のブロック提案を失いました。 Prysm は最もよく使用されている Eth2 クライアントであるため、問題は Prysm にある可能性が最も高くなります。しばらくしてから、ローカルでエラーが再現されました。これは実際には、eth1 データ投票とバリデーター デポジットに関する既知の問題です。この問題は以前にも報告されていますが、このバグを再現できず、単独のインシデントであると考えられています。そして、この問題がテストネットやメインネットで広く伝播したことはありません。この問題によりブロック提案が失敗する結果となったのはこれが初めてです。

これら 18 エポックの間、ほぼすべての Prysm ビーコン ノードは新しいブロックを生成できませんでした。エポック 32320 は、事件が終わったと広く信じられていた時点で、再び正常に機能し始めました。しかし、約24時間後、同様の影響を伴う事故が再び発生した。

影響

このレビューでは、インシデントのタイムラインが詳しく説明されており、根本原因が分析され、Eth2 ステーカーと参加者が認識する必要がある問題が明らかにされています。

影響

一部の予備データは、影響を受けた各バリデーターが最初のインシデントで平均 122,950 グウェイ (執筆時点で 0.3 ドル) を失ったことを示唆しています。そのインシデントから 24 時間以内に 2 番目の同一のインシデントが発生し、影響を受けた各バリデーターに約 0.22 ドルの費用がかかりました。

いくつかの重要な事実:

➤ バリデータはスラッシュされません

➤ ビーコンチェーンのファイナライズには影響しません

➤ 参加率は依然として非常に高い（最低点で 84.8%）（編集者注、このデータは Ben Edgington が執筆した最新号と一致しています）Eth2 進捗状況の更新矛盾があります。 ）

➤ クライアントのタイプに関係なく、ほとんどのバリデーターは 2 ～ 3 個の証明を失います

➤ 今回は悪意のあるまたは意図的な攻撃ではないようです

副題

よくある質問

バリデーターになるための近道

この事故は Eth2 に対するみんなの信頼を弱めるでしょうか?

しません。このインシデントはコンセンサス違反を引き起こさず、インシデントの規模は Eth2 メインネットの規模に比べて非常に小さかったです (最初のインシデントでは、影響を受けた各バリデーターの損失は平均 ~0.3 ドルでした)。創世記以来、Eth2 は非常に強力であり、エポックごとに非常に多くのバリデーターの参加とファイナライズが行われてきました。私たちの観点からすると、障害が解決された後にネットワークが完全に機能する状態に戻る能力は、イーサリアムの回復力に対するコミュニティの信頼をさらに強化しました。

この事件は Prysmatic Labs チームに対する全員の信頼を損なうでしょうか?

このインシデントに対する私たちの対応と解決策は、Eth2 テストネットの障害に対処するためのこれまでの取り組みとはまったく異なりました。インシデントの直後、私たちのチームは誤った情報を排除し、影響を定量化し、解決を待つ間バリデーター向けに明確な手順を提示しました。さらに、解決策が完全に決定した後、クライアントのバージョンアップを皆様にお願いする予定です。 Prysm クライアントはイーサリアム 2.0 ネットワークで最も多くのユーザーを抱えるソフトウェアであるため、バグが発生するとさらに深刻な問題を引き起こす可能性があることに注意してください。

副題

事件の根本原因の概要

Eth2 チェーンと Eth1 チェーンは緩やかに接続されており、Eth2 はバリデータによるデポジットの検証に Eth1 のみを必要とします。つまり、バリデーターがガベージ データに投票した場合でも、Eth2 PoS チェーンは動作し続けることができます。唯一重要なことは、PoS チェーンが正しい Eth1 データに再度投票するまで、新しいバリデーター デポジットを追加できないことです。この「投票」は「投票期間」中に行われます。投票期間は現在、メインネット上で 64 エポック (約 6.8 時間) に設定されています。

投票方法は単純な「超過半数」の原則であり、これは Eth2 バリデーター仕様で説明されています。残念ながら、Prysm はこの原則 (超過半数による投票) を強制する際に一部の検証を失います。このインシデントでは、Prysm のバグにより、ブロック提案者が完全に無効な Eth1 デポジット ツリー ルートを作成し、他の Prysm ノードが最初にブロック提案を発見しました。 Prysm クライアントは明示的な検証を行わずに単純な「超多数決」に従うため、彼らはこれに有効な投票を行いました。

その後、すべての Prysm ノードが無効な情報に「雪だるま式」に投票し、その結果、ブロック提案者はデポジットのあるブロックをチェーンに含めることができなくなります。これは、これらのデポジットがノードの Eth1 デポジット ツリー ルートに対して検証されないため、ブロック提案は失敗するためです。投票期間が経過すると、問題は自動的に解決されますが、バグが修正されない場合、問題が再発します。

副題

イベントのタイムライン

以下の技術的な詳細に注意してください。次のセクションに進んで、解決策とインシデントから学んだ教訓について読んでください。

提案をブロックできませんでした

エポック 32302 では、ブロック提案の喪失に関する問題が発生し始めました。

ニシャント氏はチームに通知し、全員会議を招集した。その後、ローカルのメインネット ビーコン ノードを介してインシデントを再現し、調査を開始しました。

Prysm が奇妙で間違った eth1 デポジット ツリーのルートに投票、調査で判明

文章

除外

当初の疑惑は、Prysm がバリデータ提案コード パス内の eth1 データ投票をどのように処理するかに関するものでした。特に、次のようないくつかの問題を排除するよう努めます。

1. デポジットをブロックに詰めることに問題はありますか?

2. 取得された入金ログ情報は eth1 情報と混在していませんか?

3. 私たちのデポジットマークルツリーに問題はありますか?

それから 16 時間ほど、私たちは根本的な問題を診断するために協力して多くの時間を費やしました。私たちはコード行を徹底的に調べ、単体テストを通じて障害プロセスを再現し、さまざまな方法を試しました。潜在的な解決策はすでにありましたが、自信がなかったため、修正をリリースすることに不安を感じていました。

考えられる根本原因

私たちは、Eth2 テストネットのバグに対処したこれまでの経験から、根本原因を確信するだけでは十分ではないという教訓をいくつか学びました。一か八かの状況では、ソリューションをユーザーにリリースする前に、そのソリューションに 100% の自信を持つ必要があります。事故から 28 時間後、私たちは腰を据えて自問しました。「他に何がわからないでしょうか? 故障の根本原因に近づくために、どのような質問をすればよいでしょうか?」そして、次のことを学びました。

1. 私たちのスパースマークルツリーの実装は、メインネットとプラーターテストネットのデポジットを使用しており、Lighthouse と Protolambda の Eth2 zrnt 実装と一致しているため、深刻なバグはありません。

2. Eth1 ノードから Eth1 データを取得するために使用するコード パスにはバグがなく、間違ったデータも返されません。

私たちが知らないことは次のとおりです。

1. 無効なデポジットツリーのルートがどのように作成されるか

2. この問題は一部のノードでは再現できるが、他のノードでは再現できない理由

3. ブロック内のデポジット額を決定するときに、Prysm ノードが「off-by-one」エラーを起こしたのはなぜですか

問題を解決します

これらの質問に答えるために、デポジット ツリーを初期化するコード パスを調べました。ステーカーがノードを起動するたびにすべてのバリデーターデポジットレコードをダウンロードする必要を避けるために、キャッシングレイヤーが早い段階で追加されたことが判明しました。さらに、新しい機能、つまりクライアント内に埋め込まれたジェネシス状態から Prysm を起動する機能を追加しました。デポジット ツリーのデフォルトが間違っていたため、キャッシュにデータを追加するときに情報が破損しました。

問題の根本

デポジット ツリーが空の場合、関数 len(items) は常に 1 を返すことがわかります。これは、実際には lastReceivedMerkleIndex の値を -1 に設定する必要があるのに、0 に設定したことを意味します。上記のコードにより、コード パス内の一部の Prysm ノードがツリーへのデポジット 0 の埋め込みをスキップします。私たちのコードベースの残りの部分はすべて、このコードパスではなく、デポジットツリー実装のこの奇妙な部分を問題として指摘していました。

副題

問題が解決しました

根本原因の概要

➤ Prysm は eth1 データをディスク上に保持し，プロセスが再起動されるたびにユーザーがバリデータ・デポジット・コントラクト・ログにリクエストを行う必要がないようにします。

➤ ノードが再起動してディスク上に eth1 データを保持する場合、このデータからデポジット・キャッシュを初期化しますが、スパース・マークル・ツリー (SMT) ヘルパーの方法により、このキャッシュを初期化するためのコード・パスは上記のデータとは異なります。 0 番目のデポジットをデポジット ツリーに埋め込むことをスキップすると、無効なデポジット ツリー ルートが生成されます。このコード パスは、生成以来まだデータベースを持たなかったノードにのみ影響し、後に修正されました。

➤ 公式仕様では、Prysm ノードは「絶対多数」の原則に従って eth1 データ投票アルゴリズムを実装していますが、Prysm はアルゴリズムの一部の有効な条件を完全には実装していません。 Prysm ノードは、既存のブロック ルートを参照する圧倒的多数の eth1 データ投票で投票します。これにより、問題のあるデポジット ツリーによって生成されたデポジット ツリー ハッシュに Prysm ノードが投票する可能性があります。これは、これらのデポジットが検証されていないためです。

➤ ネットワーク内のノードの大部分が Prysm ノードであるため、超多数決ルールで欠陥のあるデポジット スタブに投票することによる雪だるま式効果が深刻な問題に発展しました。これは、Prysm ノードがその後一定期間メインネット上でブロックを生成できなかったためです。

解決

解決

4 月 25 日日曜日の北京時間 13:00 に、何時間も不確実性があった後、私たちはこの問題の修正をリリースしました。私たちはこの解決策に絶対の自信を持っており、ノードのアップグレード後に Eth2 でこの問題が再発することはないと確信しています。

教訓を学ぶ

➤ 当社のソリューションに対する自信と、外部との慎重なコミュニケーションがこのイベントにおいて重要です

Eth2 Medalla テストネットの事故があったとき、私たちは良好なコミュニケーションの価値について重要な教訓を学びました。パブリックコメントや言葉の正確な表現はすべて、出来事の結果に重大な影響を与える可能性があります。テストネットの場合、当面の解決策はパブリック チャネルを通じて全員に「ノードを再起動する」ように指示することだと考えました。この性急な決定により、ネットワーク上のほとんどのノードがオフラインになり、ブロックチェーンと同期するために、多数の悪いピアの中から良いピアを見つけるために奔走しました。さらに、問題を解決できるかどうか 100% 確信があったわけではありませんが、ソフトウェア アップグレードのホットパッチをすぐにリリースしました。これにより、システムにさらなる混乱が生じ、ノードオペレーターの間で解決策についての疑念が生じます。

対照的に、メインネットの新たな事故の全過程を通じて、私たちは常に注意深く正確なコミュニケーションに注意を払ってきました。また、問題の原因と解決策について 100% 確信が持てるまで、ホットフィックスはリリースされません。

➤ 忍耐と冷静さが問題解決に役立つ

私たちのチームは過去数年間 Eth2 の構築に費やし、逆境に直面しても冷静さを保つ方法を学びました。私たちは、問題解決のプロセスでは、冷静さを保ち、頻繁に状況報告を伝え、チームがサポートされていると感じられるようにすることが重要であり、肯定的なフィードバックが重要であると考えています。私たちは時間をかけてできる限り多くの証拠を収集し、ユーザーと細心の注意を払って協力し、この問題を無事に解決することができました。さらに重要なことは、ステーカーや情報不足に対する不安を軽減するために、最初に時間をかけてイベントの影響を定量化したことです。このレッスンは、高いストレスや睡眠不足の状況で働く場合に非常に重要です。速度を落とし、適切な手段で問題を解決し、問題の悪化を何としても避けてください。

➤ Eth2 テスト ネットワークはメイン ネットワークと同等ではありません

Prysm クライアントについては、パブリック Eth2 テストネット上で Prysm の試作リリース候補を広範囲にテストし、試聴してきました。 Prater テストネットと Pyrmont テストネットはどちらも、ユーザーが Eth2 メインネットに参加する前にセットアップをテストするための優れたツールです。ただし、これらのテストネットは、4 つの実稼働グレードの Eth2 クライアントの割合が平均スコアに近い、つまりバリデーター間で明らかな過半数のシェアを持つクライアントがないことを前提としています。残念ながら、これはおそらく、特定のクライアントがほとんどの人によって使用される場合にのみ発生する脆弱性を考慮していません。将来的には、Prysmatic Labs は、メインネット環境に近い環境、または Prysm ネットワーク ノードの 50% を含む環境の内部テストネットでテストを行う予定です。

副題

利害関係者が考慮すべきこと

ステーキングに Prysm クライアントを使用する理由

https://launchpad.ethereum.org

人々が Prysm の実行を選択するのは、私たちのチームが当初からイーサリアムのステーキング体験をより簡単にすることに重点を置いていたからです。私はユーザーと何度も話をしましたが、多くの人が 1 つのクライアントを選択するのは、微細な最適化や他のクライアントと比較した歩留まりの差が比較的小さいためではなく、ユーザーのエクスペリエンスを簡素化するため、つまり優れたドキュメント情報が重要な支援を提供しているためです。コミュニティメンバー全員。初心者にとって、Eth2 は怖いものであり、ステーキングは不確実性とリスクに満ちています。私たちのチームの使命は、問題がどんなに小さなものであっても、私たちがサポートしていることをユーザーに知らせることです。特に、コマンド ラインや UNIX オペレーティング システムに精通していない可能性のある平均的なステーカーに注目してきました。

将来的には、私たちのチームには次のことが期待できます。

➤ コードを記述する前に事前に設定された有効な条件が完全にレビューされ、検証されるようにすることで、仕様条件の実装の精度を向上させます。

➤ 私たちはこのエクスペリエンスを改善するためにさらに努力し、Prysm を今日よりも何倍も改善し、Web インターフェイスの改善を含め、クライアントを使用するステーカーがネットワークに参加しやすくします。

➤ Prysm は研究開発を倍増します。<>eth2 の事前マージにより、主要な機能と改善が提供されます。

➤ すべてのクライアントチームがソフトウェアを継続的に改善するにつれて、健全な競争がETHのプルーフ・オブ・ステークをより関与させ、より安全なものにする強力なインセンティブを生み出すと私たちは信じています。

➤ 私たちのチームは、ステーカーが遭遇する可能性のある問題を最高の専門基準で解決することに尽力しています。私たちは、直面するあらゆる問題に対処する準備ができていると信じており、ステーカーエクスペリエンスを最優先にすることをコミュニティに保証します。

➤ 最後に、私たちは Prysm を Eth2 に参加するためのより魅力的なソフトウェアにすることができる多くの重要な機能があると信じており、この目標に向かって引き続き反復していきます

副題

クライアントの多様性に関する会話を振り返る

Eth2 の誕生以来、私たちが聞いてきた共通のテーマは、クライアントの多様性です。 Eth2 は、世界中の人々がバリデータとして参加する分散システムです。ブロックチェーンのコンセンサスには、人によってソフトウェアが異なりますが、特定のソフトウェアに重大な問題が発生した場合でも、ネットワークを運用するクライアントがバランスよく分散していれば影響は小さくなります。

Leonardo Bautista-Gomez 氏は 1 月にデータ分析を発表し、その結果、Prysm ノードがネットワークの 65% を占めていたことがわかりましたが、このインシデントは、現在では Prysm バリデーターが多数を占めていることも示しています。

https://github.com/leobago/BSC-ETH2/tree/master/armiarma

各クライアント、つまりソフトウェア、コミュニティ、回復力を客観的に見て、どのソフトウェアとその背後にいるチームがお客様のニーズに最も適しているかを判断することをお勧めします。 Eth2 クライアントに重要な点が欠けている場合、またはクライアントを選択しない理由がある場合は、機能リクエストを提出することを強くお勧めします。 Prysmatic Labs は、イーサリアム ネットワークへの参加を支援し、ブロックチェーン ソフトウェアの限界を押し上げることに引き続き注力していきます。

参照する

参照する

• インシデントに関するコミュニケーション https://www.reddit.com/r/ethstaker/comments/mxpz57/regarding_the_recent_beacon_chain_incident/

• 事後レポート https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit?usp=sharing

• Medalla テストネット インシデント https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a

https://medium.com/prysmatic-labs/tagged/blockchain)

元のリンク: https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c