イーサリアムの合併: 複数のクライアントを実行するリスクは何ですか?

Block unicorn

特邀专栏作者

2022-03-28 11:21 (UTC+8)

この記事は約7998文字で、全文を読むには約12分かかります

責任ある利害関係者は、クライアント環境を検討し、人気の低いクライアントを選択する必要があります。

AI要約

責任ある利害関係者は、クライアント環境を検討し、人気の低いクライアントを選択する必要があります。

原文の翻訳: ブロックユニコーン

フィードバックとレビューをくださった Vitalik Buterin (V God)、Hsiao-Wei Wang、Caspar Schwarz-Schilling に心より感謝いたします。

最初のレベルのタイトル

なぜ複数のクライアントが必要なのでしょうか?

なぜシングルクライアントアーキテクチャが望ましいのかについては議論があります。また、複数のクライアントを開発するとかなりのオーバーヘッドが発生するため、他のブロックチェーンネットワークがマルチクライアントオプションを真剣に追求しているところは見当たりません。

では、なぜイーサリアムはマルチクライアントを目指すのでしょうか?クライアントは非常に複雑なコードであり、バグが含まれる可能性があります。その中で最悪のものは、いわゆる「コンセンサスバグ」であり、ブロックチェーンの中核にある状態遷移のロジックにおけるエラーです。よく引用される例は、脆弱なクライアントが任意の量のイーサを印刷するトランザクションを受け入れる、いわゆる「無限通貨供給」エクスプロイトです。誰かがそのようなバグを発見したが、出口に到達する前に止められなかった場合（つまり、ミキサーや取引所を通じて資金を悪用した場合）、イーサの価値は劇的に崩壊するでしょう。

全員が同じクライアントを実行している場合、チェーン、すべてのスマートコントラクト、取引所は通常どおり機能し続けるため、停止するには人間の介入が必要です。攻撃を成功させ、攻撃者のトランザクションを単にロールバックすることは不可能なほど資金を十分に分散するには、たとえ数分でも十分な時間です。印刷された ETH の量に応じて、コミュニティは悪用前 (バグが特定され修正された後) へのチェーンのロールバックを調整する場合があります。

次に、複数のクライアントがある場合に何が起こるかを見てみましょう。考えられるシナリオは 2 つあります。

1.脆弱なクライアントが占める割合はステーキングの 50% 未満、クライアントはバグを悪用するトランザクションでブロックを生成し、ETH を出力します。このチェーンを呼び出しましょうA。

ただし、グリッチのないクライアントを実行しているほとんどのステーカーは、このブロックが無効であるため、このブロックを無視します (ステーカーにとって、ETH 操作の印刷は無効です)。彼らは建てるだろう

ただし、グリッチのないクライアントを実行しているほとんどのステーカーは、このブロックが無効であるため、このブロックを無視します (ステーカーにとって、ETH 操作の印刷は無効です)。彼らは、無効なブロックを含まない代替チェーン B を構築します。

正しいクライアントが大多数を占めているため、B チェーンにはより多くの証明が蓄積されます。したがって、問題のあるクライアントでもチェーン B に投票することになり、その結果、チェーン B が 100% の票を蓄積し、チェーン A が消滅します。チェーンは、エラーがまったく起こらなかったかのように続行されます。

2.ステークされた株式の大部分がバグのあるクライアントを使用しています、この場合はチェーンA過半数の票が累積されます。しかし、そのせいでBすべての証拠が 50% 未満であれば、違反したクライアントはスレーブチェーンを決して目にすることはありませんAチェーンに切り替えるB理由。したがって、チェーンの分割が発生します。

ケース 1 が最も理想的なケースです。なぜなら、これは孤立したブロックになる可能性が高く、ほとんどのユーザーは気付かないからです。開発者はクライアントをデバッグし、バグを修正すれば準備完了です。対照的に、ケース 2 は明らかに理想的ではありません。しかし、それでも 1 つのクライアントよりは優れています。ほとんどのクライアントはチェーンの分割を非常に迅速に検出し (複数のクライアントを実行することでこれを自動化できます)、取引所は入金をすぐに一時停止し、Defi ユーザーは分割が解決するまで待つことができます。慎重に続行してください。基本的に、これでも単一クライアントアーキテクチャと比較して、最悪の結果に対して赤色の警告灯が点滅します。

ケース 2 は、障害のあるクライアントがステークの 2/3 以上で実行されていた場合、さらに悪化します。この場合、無効なチェーンが終了します。これについては後で詳しく説明します。

最初のレベルのタイトル

クライアントの多様性を奨励する: 反関係に関する罰則

ステークが複数のクライアントに分散されている場合、最良のシナリオは、各クライアントが合計ステークの 3 分の 1 未満を所有することです。これは明らかにネットワークにとって有益です。これにより、単一クライアントでのエラーに対する回復力が高まります。しかし、なぜ利害関係者は気にするのでしょうか？ネットワークにインセンティブがなければ、少数派のクライアントに切り替えるコストが発生する可能性は低くなります。

残念ながら、バリデーターが実行されているクライアントに報酬を直接依存させることはできません。これを測定する、だまされない客観的な方法はありません。

ただし、クライアントにエラーがある場合は非表示にすることはできません。ここで反相関ペナルティが登場します。つまり、バリデーターが何か悪いことをした場合、ほぼ同時により多くのバリデーターが間違っていれば、ペナルティはより高くなるという考え方です。言い換えれば、関連する失敗に対してペナルティが課せられることになります。

ether では現在、次の 2 つの動作でハッキングされる可能性があります。

1. 同じ高さの 2 つのブロックにサインします。

2. 枝刈り可能な証明のペアを作成します (囲み投票または二重投票)。

被害に遭っても、通常は全財産を失うことはありません。この記事の執筆時点 (Altair Fork) では、デフォルトのペナルティは実際には非常に小さいです。失うのは 0.5ETH、つまりステークした Ether の 1.5% だけです (最終的には 1ETH、つまり 3% に増加します)。

ただし、落とし穴があります。バリデーターがスラッシュされた前後 4096 エポック (18 日) 以内に発生した他のすべてのスラッシュに応じて、追加のペナルティが発生します。さらにペナルティを受ける金額は、この期間中に削減された合計金額に比例します。

最初のレベルのタイトル

もう 1 つの逆相関ペナルティ: 二次非アクティビティリーク

バリデーターが失敗するもう 1 つの方法はオフラインです。これにもペナルティがありますが、仕組みは大きく異なります。これをスラッシュとは呼びません。通常は小規模です。通常の操作では、オフラインのバリデーターは、完全に検証している場合と同じペナルティを受けます。この記事の執筆時点では、年間成長率は 4.8% です。たとえばインターネットの一時的な停止により、バリデーターが数時間または数日間オフラインになっている場合は、おそらく冷や汗をかく必要はありません。
バリデーターの 1/3 以上がオフラインの場合、状況は大きく異なります。その後、ビーコンチェーンはファイナライズに失敗し、コンセンサスプロトコルの基本的な特性である生存性が脅かされます。
このような状況で回復するには、いわゆる「二次的な不活動リーク」が機能します。チェーンが不完全なままバリデーターがオフラインになり続けると、ペナルティの合計は時間の経過とともに二次関数的に増加します。最初は非常に低く、約 4.5 日後に、オフラインのバリデーターはステークの 1% を失います。ただし、約 10 日後には 5%、約 21 日後には 20% に増加しました (これは Altair の値であり、将来的には 2 倍になります)。

このメカニズムは、多数のバリデーター操作が失敗するような壊滅的なイベントが発生した場合でも、最終的にはチェーンが再び完了できるように設計されています。オフラインのバリデーターがステークをどんどん失うと、総ステークに占める彼らのシェアはどんどん小さくなり、ステークが 1/3 を下回ると、残りのオンラインバリデーターが必要な 2/3 の過半数を獲得し、ファイナライズが可能になります。チェーン。
最初のレベルのタイトル

大多数のクライアントを実行することはどのくらい悪いことですか?

何が危険なのかを理解するために、次の 3 つの失敗タイプを見てみましょう。

1. 大量のスラッシュイベント: ほとんどのクライアントバリデーターはバグのため、スラッシュ可能なプルーフに署名しました。

2. 多数のオフラインイベント: バグにより、大半のクライアントバリデーターがすべてオフラインになりました。

3. 無効なブロックイベント: 間違いにより、ほとんどのクライアント検証ツールは無効なブロックが存在することを証明しました。

最初のレベルのタイトル

シナリオ 1: 二重署名

これはおそらく、ほとんどのバリデーターオペレーターが最も恐れるシナリオです。それは、バリデータークライアントが削除可能なプルーフに署名する原因となるバグです。例としては、2 人の証明者が同じターゲットエポックに投票するが、ペイロードが異なる場合があります。これはクライアントのバグであるため、懸念されるのは 1 人のステーカーだけではなく、この特定のクライアントを実行しているすべてのステーカーです。これらの曖昧な点が発見されると、大惨事になります。関係するすべてのステーカーは、ステークした資金の 100% を失うことになります。これは、複数のクライアントを考慮しているためです。問題のクライアントがステークの 10% のみをステークしている場合、ステークの「のみ」20% が削減されます (Altair では 30%、最終的なペナルティパラメーターを設定します)。

この場合、被害は明らかに甚大ですが、その可能性は極めて低いと考えています。削除可能なプルーフの条件は単純であるため、それらを強制するためにバリデータークライアント (VC) が構築されました。バリデータクライアントは小規模で十分に精査されたソフトウェアであり、この規模の侵害が発生する可能性はほとんどありません。

最初のレベルのタイトル

シナリオ 2: 大規模なオフラインアクティビティ

このシナリオでは、ほとんどのクライアントには、トリガーされるとクライアントがクラッシュするバグがあると想定します。問題のブロックはすでにチェーンに統合されており、クライアントがそのブロックに遭遇するとオフラインになり、それ以上ネゴシエーションに参加できなくなります。ほとんどのクライアントがオフラインになっているため、非アクティブなリークが発生し始めています。

クライアントの開発者は、すべてを元に戻そうと慌てて取り組むことになるでしょう。現実的には、数時間以内、長くても数日以内に、クラッシュを取り除くバグ修正がリリースされるでしょう。

それまでの間、注文者は単に別のクライアントに切り替えることもできます。これが完了してバリデーターの 2/3 以上がオンラインになるとすぐに、二次非アクティブリークは停止します。バグのあるクライアントが修正されるまで、これが発生することは不可能ではありません。

最初のレベルのタイトル

シナリオ 3: 無効なデータブロック

このシナリオでは、ほとんどのクライアントに無効なブロックを生成するバグがあり、それを有効なものとして受け入れるという状況を考慮します。つまり、同じクライアントを使用している他のバリデーターが無効なブロックを見たときに、それが有効であるとみなして、証明されることになります。それ。
無効なブロックチェーンを含むチェーンを A と呼びます。無効なブロックが生成されると、次の 2 つのことが起こります。

1. 動作しているすべてのクライアントは無効なブロックを無視し、代わりに別のチェーン B を生成する最新の有効なヘッドに基づいて構築します。稼働しているすべてのクライアントは投票し、チェーン B に基づいて構築します。

2. 障害のあるクライアントは、チェーン A とチェーン B の両方が有効であると考えているため、現在考えている 2 つのチェーンのうち最も重い方に投票します。

次の 3 つのケースを区別する必要があります。

1. 脆弱な顧客が保有していた株式は総株式の半分未満でした。この場合、すべての正しいクライアントが投票し、B チェーン上に構築します。、最終的には最も重いチェーンになります。この時点で、障害のあるクライアントもチェーン B に切り替わります。 1 つまたは少数の孤立したブロックを除いて、悪いことは何も起こりません。これは快適な状況であり、大多数のユーザーのみが存在することが素晴らしい理由です。

2. 脆弱な顧客は株式の半分以上、3分の2未満を保有していた。この例では、2 つのチェーンが構築されています。A はバグのあるクライアントによって、B は他のすべてのクライアントによって構築されています。どちらのチェーンも3分の2の過半数を持っていないため、最終決定することはできません。これが起こると、開発者はなぜ 2 つのチェーンがあるのか理解しようと躍起になるでしょう。チェーン A に無効なブロックがあることが判明すると、バグのあるクライアントの修正に進むことができます。修正されると、チェーン A が無効であると認識されます。したがって、B チェーン上で構築が開始され、最終化が可能になります。これはユーザーにとって非常に迷惑です。どのチェーンが有効であるかについての混乱が 1 時間以内に収まることが望まれますが、チェーンが最終的に決定されるまでには数時間、あるいは 1 日かかる可能性があります。しかし、プロデューサーにとっては、問題のクライアントを運営しているプロデューサーであっても、罰則は比較的軽いままです。無効なチェーン A を構築しているときにチェーン B に参加しなかった場合、「非アクティブリーク」というペナルティが課せられます。ただし、これは 1 日未満である可能性があるため、賭け金の 1% 未満のペナルティについて話しています。

3. 当該顧客は株式の 3 分の 2 以上を保有しています。この場合、バグのあるクライアントはチェーン A を構築するだけではなく、実際にはそれを「ファイナライズ」するのに十分なステークを持っていることになります。チェーン A が完了したとみなされるのは、このクライアントだけであることに注意してください。ファイナライズの条件の 1 つは、チェーンが有効であり、正しく動作している他のすべてのクライアントではチェーン A が無効になることです。ただし、Casper FFG プロトコルの仕組みにより、バリデーターがチェーン A をファイナライズすると、そのチェーンがファイナライズされない限り、ハッキングされずに A と競合する別のチェーンに参加することはできません (詳細については、付録を参照してください)。 2)。したがって、チェーン A が最終決定されると、バグのあるクライアントを実行しているバリデーターは悲惨な状況に陥ります。チェーン A にコミットしましたが、チェーン A は無効です。 B はまだ最終決定されていないため、B に貢献することはできません。バリデーターソフトウェアのバグを修正しても役に立ちません。彼らはすでに問題のある投票用紙を送信しています。これから起こることは非常に痛ましいことです。まだ最終化されていない B チェーンは、二次的な非アクティブリークに入るでしょう。数週間にわたって、違反したバリデーターは、B が再度ファイナライズするのに十分なステークが失われるまで、ステークを漏洩します。最初は 70% の賭け金を持っていたとします。その後、79% の賭け金を失うことになります。これは、賭け金総額の 3 分の 1 未満を占めるために失う必要がある金額だからです。この時点で、チェーン B が再び確定され、すべてのステーカーがチェーン B に切り替えることができます。チェーンは再び健全になりますが、停止は数週間続き、その過程で数百万のETHが破壊されます。

最初のレベルのタイトル

リスク分析

では、これらのシナリオをどのように評価すればよいのでしょうか?典型的なリスク分析戦略は、イベントが発生する可能性 (1-非常に低い、5-非常に高い) とその影響 (1-非常に低い、5-壊滅的) を評価することです。注目すべき最も重要なリスクは、影響と可能性の積で表される、両方の指標で高いスコアを示すリスクです。

これを念頭に置くと、シナリオ 3 が最も優先度が高くなります。顧客が 3 分の 2 の超多数派にある場合、その影響は非常に壊滅的であり、これも比較的あり得るシナリオです。このような脆弱性がいかに簡単に発生するかを強調するために、このようなバグが最近 Kiln テストネットで発生しました (「Kiln テストネットブロッキング提案の失敗」を参照)。この場合、Prysm はレンガが提示された後にそのレンガに欠陥があることを検出しましたが、それを証明しませんでした。 Prysm がブロックが有効であると考えており、これがメインネットで発生した場合、シナリオ 3 のケース 3 で説明した壊滅的な状況になります。これは、Prysm が現在メインネットで 2/3 の多数派を占めているためです。したがって、現在 Prysm を実行している場合は、資金をすべて失う可能性がある非常に現実的なリスクがあるため、クライアントを切り替えることを検討する必要があります。

おそらく最も恐れられるシナリオ 1 は、比較的低い評価を受けました。その理由は、Validator クライアントソフトウェアがすべてのクライアントに適切に実装されており、スキュー可能なプルーフやブロックが生成される可能性は低いと考えられるため、このようなことが起こる可能性はかなり低いと考えているためです。

現在複数のクライアントを実行していて、切り替えることに不安がある場合、どのようなオプションがありますか?

クライアントの置き換えは大規模な作業になる可能性があり、それにはいくつかのリスクが伴います。 miter データベースが新しいセットアップに適切に移行されない場合はどうすればよいですか?ハッキングされる危険性があり、目的が完全に無効になります。

これを心配している人には別の選択肢を提案します。バリデーターのセットアップをそのままにして（キーを取り出す必要などはありません）、ビーコンノードを切り替えるだけで済みます。バリデータークライアントが期待どおりに動作している限り、再署名されることはなく、ハッキングされることはないため、これは非常に低リスクです。特に、バリデータクライアント (またはリモート署名者) インフラストラクチャの変更に費用がかかり、監査の対象となる可能性がある大規模な操作を行っている場合、これは良い選択肢となる可能性があります。セットアップが期待どおりに動作しない場合、または他のいくつかのクライアントを試してみた場合、元のクライアントに切り替えることも簡単です。

最初のレベルのタイトル

罰を受けたクライアントはどうなるでしょうか？

私が上で書いたことは、コンセンサスクライアントである Prysm、LightTower、Nimbus、Loestar、Teku に当てはまります。この記事の執筆時点では、おそらく Prysm がネットワーク上で 3 分の 2 の多数派を占めています。
これらはすべて、実行中のクライアントに同じように適用されます。 Go-Etherum はマージ後に大半の実行クライアントとなる可能性が高く、無効なブロックが生成された場合はファイナライズされ、シナリオ 3 で説明されている壊滅的な障害につながる可能性があります。
副題

付録

補遺 1: 無効なブロックはなぜスラッシュされないのですか?

シナリオ 3 では、無効なブロックを提案して投票するバリデーターにペナルティを与えるために、二次非アクティブリークに依存する必要があります。それはおかしい、なぜ彼らを罰しないのですか？この方法の方が早くて痛みも少ないように思えます。

実際、そうしない理由は 2 つあります。1 つは、現在はできないことですが、たとえできたとしても、おそらくそうしないでしょう。

1. 現在、無効なデータブロックに対してペナルティ (「スラッシュ」) を導入することはほぼ不可能です。これは、ビーコンチェーンも実行チェーンも現在「ステートレス」ではないためです。つまり、ブロックが有効かどうかを確認するには、コンテキスト (「state」) が必要です。これは、ブロックが無効であるという「簡潔な証拠」がないことを意味します。バリデーターをスラッシュするにはそのような証拠が必要です。バリデーターを「スラッシュ」するブロックには、バリデーターが法律に違反したという証拠を含める必要があります。ステートレスなコンセンサスがない場合、この問題を回避する方法はありますが、Arbitrum が現在集計に使用しているようなマルチラウンドの不正行為証明など、より複雑な構造が必要になります。

2. たとえ導入できたとしても、このタイプのスラッシュを導入したくない 2 番目の理由は、無効なブロックの生成を防ぐのが現在のスラッシュ条件よりも難しいためです。現在の条件は非常に単純なので、検証クライアントはわずか数行のコードで簡単に検証できます。だからこそ、上記のシナリオ 1 の可能性は低いと私は考えています。これまでのところ、削除可能なメッセージはオペレーターのミスによってのみ生成されており、今後もそれが続く可能性が高いと思います。無効なブロックを生成する (またはそれらを証明する) ためにスラッシュを追加すると、コイン所有者のリスクが増加します。現在では、少数派の顧客を経営する者であっても厳しい罰則にさらされる可能性がある。

副題

補遺 2: 欠陥のあるクライアントは、チェーン A を終了した後にチェーン B に切り替えることができないのはなぜですか?

このセクションは、なぜバグのあるクライアントが単に元に戻すことができず、恐ろしい非アクティブリークに悩まされなければならないのかをより詳しく理解したい人を対象としています。そのためには、Casper FFG ファイナライゼーションがどのように機能するかを確認する必要があります。

各プルーフは、ソースチェックポイントと宛先チェックポイントで構成されます。チェックポイントは、エポックの最初のブロックです。あるエポックから別のエポックへのリンクがあり、すべての投票の合計 2/3 以上が問題になっている場合 (つまり、最初のチェックポイントが「ソース」で 2 番目のチェックポイントが「ターゲット」である非常に多くの証明)、次のように呼びます。彼らは「超多数派のリンク」です。

エポックは「合理的」または「明確」であり、次のように定義されます。

1. エポック 0 が整列されます。

2. エポックが正当なエポックと超過半数の関係を持っている場合、そのエポックは正当です。

3. (1) エポック X が調整され、(2) 次のエポックも調整され、大部分のリンクのソースがエポック X である場合、エポック X は確定されます。

ルール 3 は少し簡略化されています (エポックを確定するにはさらに多くの条件がありますが、それらはこの説明では重要ではありません)。では、大幅な値下げの条件を見てみましょう。スラッシュプルーフには 2 つのルールがあります。どちらも証明 V と W のペアを比較します。

1. V と W は、同じエポック (つまり、同じ高さ) をターゲットにしている場合はハッキング可能ですが、同じチェックポイントに投票しません (二重投票)。

2. これは、(1) V のソースが W のソースよりも早く、(2) V のターゲットが W のターゲットよりも遅いことを意味します (サラウンド投票)。

最初の条件は明白です。同じ高さの 2 つの異なるチェーンに単純に投票することを防ぎます。しかし、2 番目の条件は何をするのでしょうか?

その機能は、2 つの競合するチェーンの最終処理に関与するすべてのバリデーターをスラッシュすることです (これは決して起こるべきではありません)。その理由を確認するために、シナリオ 3 をもう一度見てみましょう。最悪の場合、バグのあるクライアントの絶対多数 (ステークの 2/3 以上) が存在します。障害のあるチェーンに投票し続けると、次のように無効なブロックでエポックを終了します。

この画像の丸いボックスは、ブロックではなくエポックを表します。緑色の矢印は、すべてのバリデーターによって作成された最後の超多数リンクです。赤い矢印は、バグのあるクライアントによってのみサポートされる超多数のリンクです。動作中のクライアントは、無効なブロック (赤) を含むエポックを無視します。最初の赤い矢印は無効なエポックを位置合わせし、2 番目の矢印は無効なエポックを示します。
ここで、バグが修正され、無効なエポックを最終的に判断したバリデーターが正しいチェーン B に再参加したいと考えているとします。チェーンを終了できるようにするには、最初のステップはエポック X を調整することです。