イーサリアムのクライアントの多様性を理解することがなぜそれほど重要なのでしょうか?
著者: ジョセフ・クック
オリジナル編集: Nanfeng、Unitimes
イーサリアムには複数の相互運用可能なクライアントがあり、独立したチームによってさまざまな言語で開発および保守されています。これは、影響を受けるクライアントを実行しているネットワーク部分への侵害または攻撃の影響を制限することで、ネットワークに回復力を提供する重要な成果です。ただし、この利点は、すべてのユーザーが使用可能なクライアント全体にほぼ均等に分散されている場合にのみ実現できます。現在、イーサリアム ノードの大部分は単一のクライアントを実行しており、ネットワークに不必要なリスクをもたらしています。
ビーコンチェーン
ビーコンチェーン
ビーコン チェーンは PoS ブロックチェーンです。現在、イーサリアムメインネットと並行して実行されていますが、2つは間もなく一緒に「マージ」される予定です。合併後、既存のイーサリアムメインネットクライアント（「実行クライアント」）は引き続きイーサリアム仮想マシン（EVM）をホストし、トランザクションを検証およびブロードキャストしますが、プルーフオブワーク（PoW）マイニングへの参加を停止し、コンセンサスに対する責任を放棄します。ブロックチェーンのヘッド (トップブロック) にあります。
代わりに、このコンセンサスは、コンセンサスに必要な情報とともに「実行クライアント」からのトランザクションを「ビーコン ブロック」にパッケージ化する責任を負う「コンセンサス クライアント」の責任となります。ブロックはビーコン チェーンを形成します。 「マイナー」は、ETHをイーサリアムスマートコントラクトに入金する必要がある「バリデーター」に置き換えられます（「ステーキング」と呼ばれるプロセス）。バリデーターによって賭けられた ETH は、検証作業を正しく完了するよう促すための担保として使用されます。バリデーターが検証作業を実行しなかったり (オフラインであるなどの理由で)、悪意のある行為を行ったりすると、誓約した ETH の一部が破棄されます。一方で、バリデーターが良い行動をとれば、報酬としてETHが与えられます。
1. バリデーターの責任
バリデーターにとって、良い行動とは、他のバリデーターから受け取ったビーコンブロックの検証に参加し、ブロックチェーンヘッドに投票することを意味します。バリデーターが受け取ったブロックが有効な場合、バリデーターはブロックを「証明」し、ブロックチェーンに追加するブロックに事実上投票します。時々、ノードは新しいブロックを提案するように求められ、他のバリデーターがそれを「証明」します。ブロックチェーンに複数のフォークがある場合、その歴史の中で最も多くの「証明書」を蓄積したものだけが正しいものになります。
検証者は、時々、同期委員会にも参加します。同期委員会は、ランダムに選択された 512 人の検証者のグループです。これらのランダムに選択された検証者は、ブロック ヘッダーをチェックします。ライト クライアントが、全体にアクセスせずにこれらの検証済みブロックを取得できるように署名します。履歴チェーンまたはバリデーターのセット全体。
2. 合理化および最終化
ビーコン チェーンはネットワークのペースを設定します。このリズムは、スロットとエポックという 2 つの時間単位で構成されます。スロットはビーコン チェーンにブロックを追加する機会であり、12 秒ごとに発生します。スロットにブロックがない場合もありますが、システムが最適に動作している場合は、使用可能なすべてのスロットにブロックが追加されます。エポックの単位は 32 スロット (約 6.4 分) です。スロットとエポックは、イーサリアム ブロックチェーンのリズムを設定します。
各エポックの間、最初のスロットのブロックはチェックポイントです。チェックポイントは、ブロックチェーン台帳上の記録を永続的かつ不可逆的なものにするために使用されるため、重要です。これは 2 段階のプロセスです: まず、すべてのアクティブなバリデーターが ETH をステークしているかどうか 残高の少なくとも 2/3 (つまり、「超過半数」) が証明しているかどうか最後の 2 つのチェックポイント (現在のチェックポイントは「ターゲット チェックポイント」と呼ばれ、前のチェックポイントは「ソース チェックポイント」と呼ばれます) まで、その後 2 つのチェックポイント間のブロックは「正当化」されます。
「合理化」は、イーサリアムの権威チェーン上で永久的な記録となるための第一歩です。 「合理化された」チェックポイントの後に別の「合理化された」チェックポイントが出現すると、前のチェックポイントは「確定」され、永続的かつ不可逆的になります（つまり、このチェックポイントより前のすべてのレコードはブロックチェーン上で永続的かつ不変のレコードになります）。
この「合理化」および「終了」プロセスでは、検証者は実際には上記で説明したものよりも複雑な「証明」を実行する必要があります。証明には 2 種類あります: 1 つはブロックチェーンのチェーンヘッドを証明するために使用される LMD GHOST 投票 (LMD GHOST はフォーク選択アルゴリズムです); 2 つ目は 2 つのチェックポイントを証明するために使用される FFG 投票です (FFG はブロックチェーンを合理化して最終化する「ファイナリティ ガジェット」)。すべてのバリデーターは各チェックポイントに対して FFG に投票しますが、ランダムに選択されたバリデーターのサブセットのみがスロットごとに LMD GHOST に投票します。
賞
賞
前述したように、バリデーターによって担保された ETH は、バリデーターの誠実な行動を奨励するための「担保」として使用されます。このステーキングされた ETH は、ネットワークのセキュリティ保護に参加したバリデーターに報酬が与えられるため、時間の経過とともに増加します。バリデーターによって行われた LMD-GHOST 投票と FFG 投票が他のバリデーターの大部分と一致する場合、バリデーターは証明報酬を受け取ります。バリデーターが「ブロック提案者」として選択された場合、提案したブロックが「確定」した場合、バリデーターにも報酬が与えられます。ブロックの提案者は、提案したブロックに他のバリデーターによる不正行為の証拠を含めることで、自身の報酬を増やすこともできます。これらの報酬は、バリデーターが誠実に行動するよう促す「報酬」です。
罰する
検証者が受ける可能性のある「罰」は、さまざまなメカニズムの形で検証者が約束したETHの一部を破棄することです。検証ペナルティは、バリデーターが FFG 投票を提出しなかった場合、提出が遅れた場合、または間違った FFG 投票を提出した場合に課せられます。ただし、検証者が LMD-GHOST の投票を逃した場合、罰せられることはありませんが、チェーン ヘッドに投票することで得られるはずの報酬を逃すことになります。バリデーターの残高は、正しい証明を提出した場合に受け取れるはずだった報酬と同じ金額だけ削減されます。
これは、誠実だが「怠惰」な検証者が証明を怠った場合の最大のペナルティは、証明を完璧に行った場合に受け取れるはずの報酬額の 3/4 を失うことを意味します。さらに、バリデーターが「同期委員会」に割り当てられている場合、バリデーターがブロックに署名できなかった場合、ブロックに署名できた場合に受け取れるはずの ETH の価値に等しいペナルティが課せられます。
全体として、これらのペナルティは軽く、バリデーターが非アクティブな状態を続けても、ステーキングされた ETH はかなりゆっくりと削減されるだけです。
没収された
より深刻なアクションはスラッシュであり、バリデーターがネットワークから強制的に削除され、それに関連して ETH デポジットが失われます。バリデーターをスラッシュする方法は 3 つあります。いずれも、バリデーターが不正なブロック提案またはブロック証明を行うのと同じです。
- 同じスロットで 2 つの異なるブロックを提案し、署名します。
- ブロックを「囲む」別のブロックへの認証 (実際にブロックチェーン履歴を変更する)。
- 同じブロックの 2 つの候補ブロックに対する「二重投票」による。
これらのアクションが検出された場合、バリデーターはスラッシュされます。これは、ステークされた ETH の 1/64 (最大 0.5 ETH) が直ちに破棄され、その後 36 日間のエグジット期間が開始されることを意味します: この期間中、バリデーターのステークは徐々に減らされ、この期間の中間点で（18 日目）、バリデーターは、スラッシュ イベントの 36 日前にすべてのスラッシュされたバリデーターによって誓約された ETH の合計額に比例した追加のペナルティも受け取ります。
これは、より多くのバリデーターがスラッシュされるにつれて、スラッシュの大きさが増加することを意味します。最大スラッシュは、スラッシュされたすべてのバリデーターの有効残高全体です (つまり、多数のバリデーターがスラッシュされた場合、ステーク全体を失う可能性があります)。一方、単一の独立したスラッシュ イベントでは、バリデーターのステークのごく一部が破壊されるだけです。この中間ペナルティは、スラッシュされたバリデータの数に応じて変化し、「相関ペナルティ」と呼ばれます。
不活動リークのメカニズム
ビーコン チェーンが 4 エポックを超えて確定されていない場合、「非アクティブ リーク」と呼ばれる経済メカニズムがアクティブになります。非アクティブ リークの最終的な目的は、ブロックチェーンがファイナライズを再開するための条件を作成することです。上で説明したように、「ファイナリティ」では、「ソース チェックポイント」と「宛先チェックポイント」で合意に達するために、ETH 入金総額の 2/3 が必要です。バリデーターの 1/3 以上がオフラインであるか、証拠の提出に失敗した場合、バリデーターの 2/3 を超える過半数がチェックポイントを完了することは不可能です。
この時点で、非アクティブ リーク メカニズムは、これらの非アクティブなバリデーターによって管理されるデポジットがネットワーク内の総デポジットの 1/3 未満になるまで、これらの非アクティブなバリデーターに属する ETH デポジットを徐々に減らし、残りのアクティブなバリデーターがブロックチェーンをファイナライズできるようにします。これらの非アクティブなバリデーターの数に関係なく、残りのバリデーターが最終的に総賭け金の 2/3 以上を制御することになります。このステーキングの削減は、非アクティブなバリデーターをできるだけ早く再アクティブ化するための強力なインセンティブとなります。
ビーコン チェーンの設計における報酬、ペナルティ、およびスラッシュは、個々のバリデーターが正しいことを行うことを奨励します。ただし、これらの設計の選択から、複数のクライアント間でバリデータを均等に分配することを強く奨励し、単一のクライアントによるこの支配を強力に阻害するシステムが生まれます。これは、ビーコン チェーンにとって「絶対多数決システム」が非常に重要であるためで、悪意のあるバリデータが 1 つ存在する場合はネットワークにまったく無害ですが、悪意のあるバリデータが多数存在すると重大な損害を引き起こす可能性があります。考えられるシナリオをいくつか見てみましょう...
リスクシナリオ
この資産インセンティブのコンセンサスによる顧客の多様性には危険が伴います。バリデータを複数のクライアントに均等に分散することで、クライアント固有の攻撃や脆弱性の影響を大幅に軽減できますが、単一クライアントの優位性によりリスクが増大します。このリスク乗数効果は、単一の支配的なクライアントが占めるネットワークのシェアによって異なります。
いくつかの仮説的な (しかしおそらく実際の) シナリオを経験することで、より多くの直観を得ることができます。コンセンサス クライアントにバグが誤って導入され、クライアントが不正な認証を行うことを直接引き起こすか、悪意のある攻撃者がクライアントに不正な認証を強制できる脆弱性が暴露されると仮定します。それでは、クライアントの多様性はこのバグの結果にどのような影響を与えるのでしょうか?
シナリオ 1: 影響を受ける顧客が管理している ETH 預金は全体の 1/3 未満
この状況は、ステークされた ETH の 2/3 がまだ正しく証明されており、ビーコン チェーンが正常にファイナライズできるため、ビーコン チェーンに最大の回復力を提供します。したがって、ネットワークの観点からは、このシナリオの影響は無視できます。影響を受けるバリデーターは、間違った証明を提出したために怠惰であるとしてペナルティを受けます。これらの損失は比較的小さいため、影響を受けるバリデーターはクライアントが修正されるまで待つか、別のクライアントに切り替えることができます。いずれの場合でも、バリデーターは、経済的影響を最小限に抑え、ビーコン チェーンを切断することなく、正しさの証明を続行できます。
シナリオ 2: 影響を受ける顧客はすべての ETH 預金の 1/3 以上を管理している
このケースは、ETH ステークの 2/3 未満しか正しく証明できないため、より問題が大きくなります。つまり、正確にコンセンサスに達するための超過半数のバリデーターが存在しないからです。これは、ビーコン チェーンを終了できず、非アクティビティ リーク メカニズムがアクティブになることを意味します。この時点で、バグはネットワーク全体に影響を及ぼしました。イーサリアム上に構築された取引所や Dapps (分散型アプリケーション) では、ブロックチェーンのファイナリティが非常に重要であり、ブロックチェーンがファイナライズできない場合、トランザクションが永久的なセクシュアリティと不変であるという保証はありません。
この影響を受けるクライアントを使用する個々のバリデーターの場合、関連するペナルティはさらに厳しくなります。非アクティビティ リーク メカニズムの有効化は、個々のバリデーターによって誓約された ETH が、バグ コントロールの影響を受けるクライアントが 1/3 未満になるまで徐々に破棄されることを意味するためです。 ETH ステークの合計を取得し、それから初めてビーコン チェーンはファイナライズを再開します。この ETH の書き込みは、実際にはビーコン チェーンが復元された後もしばらく継続する可能性があり、バリデーターの数の小さな変更に対するバッファーを提供します。ビーコンチェーンの最終化が危険にさらされるのは、影響を受ける単一のクライアントがステーキングされた合計 ETH の 1/3 以上を制御している場合のみです。
このシナリオでは、非アクティビティ リーク メカニズムがアクティブである間、他の代替クライアントを実行しているバリデーターは報酬を受け取りません。これは、攻撃者が意図的に非アクティビティ リーク メカニズムを起動して、その攻撃者が制御する他の正しく動作するバリデータに対する合計報酬を増やすことを防ぐための安全メカニズムです。これらは小さなペナルティですが、重要なのは、クライアントがステーク総額の 1/3 以上を管理しているコンセンサスバグの悪影響から誰も逃れることはできないということです。
シナリオ 3: 影響を受けるクライアントが ETH デポジットの 2 分の 1 を管理している
この状況により、ビーコン チェーンで回復不能なフォークが発生する可能性があります。コンセンサスバグのあるクライアントが独自のチェーンにフォークした場合、元のチェーンもフォークされた新しいチェーンもファイナライズを達成できません。これは、古いチェーンと新しいチェーンの両方でバリデーターの約半分が欠落しており、両方とも非アクティビティリークメカニズムがアクティブ化されるためです。現時点では、2 つのチェーン上で行方不明の検証者の ETH デポジットは、それらが管理するデポジットがネットワーク全体の ETH デポジットの 1/3 未満になるまで徐々に破棄され、ファイナライゼーションが再び開始される可能性があります。ファイナライゼーションを復元するには同量の ETH を書き込む必要があるため、このプロセスには両方のチェーンで同じ時間がかかります。
2 つのチェーンは異なるチェックポイントを使用して、独立してファイナライズを完了します。これら 2 つのチェーンが単一の「権威チェーン」に統合されることはありません。解決策には、イーサリアムコミュニティがどのチェーンが「権威チェーン」であるかについて合意に達する必要があるが、このプロセスは政治的に困難で意見の相違を引き起こすのは確実で、その結果、ブロックチェーンの切り替えによりコミュニティの半分が経済的損失を被ることになる（これは現在も継続中である）。 ETHの減価償却の可能性は除く）。おそらくさらに悪いことに、コミュニティは分裂し続けるかもしれません（イーサリアムクラシックにつながったDAO事件と同様）。
ビーコン チェーンの永続的な分割を回避するために、影響を受けるクライアントを使用しているバリデーターは、ブロックチェーンのファイナライズが開始される前に、非アクティビティ リークと競合してクライアントを切り替えるか、クライアントを修正する必要があります。開発者がイーサリアムを救うために奔走する期間は 3 ～ 4 週間になる可能性があります。このシナリオでは、多数のバリデーターにとって、重大な経済的損失は避けられません。
シナリオ 4: 影響を受けるクライアントがすべての ETH 預金の 2/3 以上を管理
影響を受けるクライアントは大多数のバリデーターを制御し、独自のチェーンを完成させることができるため、これはビーコン チェーンにとって悪夢のような状況です。このように、誤った情報がイーサリアムの歴史に永久に固定される可能性が高くなります。ブロックチェーンが不正なブロックの最終処理を開始する前に、クライアント チームはコンセンサス バグを特定して修正し、影響を受けるバリデータにクライアントの更新をブロードキャストするのに約 13 分かかります。
この状況の場合、唯一の実行可能な緩和策は、影響を受けるバリデーターがステーキングしたETHを引き出し、ブロックチェーンから撤退することです。バグが修正された後、影響を受けるバリデーターが正しいブロックチェーンに再参加しようとした場合、以前に証明したものと同じチェックポイントであることが証明されるため、「共謀ペナルティ」により削除されます。 。多数のバリデーターが離脱することにより、非アクティビティリークメカニズムがアクティブ化されます。これは、影響を受けるこれらのバリデーターが出金 (出口) を待っている間、ETH 預金を失い続けることを意味します。多数のバリデーターが退場すると、待機列は長くなり、時間がかかり、費用も高くなります。
他の唯一の選択肢は、影響を受けていない残りのクライアントがバグを受け入れ、新しいチェーンに参加し、そのバグが今後のイーサリアムコンセンサス層の意図された動作であることに同意することです。これはステーキングコミュニティの中核となる理念に反し、非常に分裂を招くことになります。こうした少数派のクライアントは、たとえ適切に行動していたとしても、新しいチェーンで怠けているとペナルティを受けることになります。
その他のリスク
その他のリスク
逆ファイナリティ
単一のクライアントがステーキングされた ETH の合計の 2/3 以上を制御している場合、そのクライアントの開発者は、ブロックチェーン履歴のどのバージョンが正しいかを選択することができます。たとえば、このクライアントの開発者が悪意を持った場合、一部の ETH を使用する可能性があり (取引所を介して現金化したり、別のブロックチェーン ネットワークにブリッジしたりするなど)、その後、これらの開発者は集合的に、これを含まない別の ETH を使用するよう投票します。支出トランザクションのチェーン バージョンは、現在完了したチェーンを置き換えます。
クライアントはバリデータの大部分を制御しており、ファイナリティを逆転させて履歴を書き換えることができるため、これは「二重支出」です。同時に、少数の正直なバリデーターは、矛盾した証明のために罰せられます。 ETH 預金総額の大部分を制御する悪意のある攻撃者が、そうすることを脅してネットワークを制御し、身代金を要求する可能性もあります。 ETH 入金総額の 1/3 を管理する悪意のある当事者であっても、チェーンのファイナライゼーションを停止し、非アクティビティ リーク メカニズムをアクティブにする恐れがあります。
責任の共有
集中化された
集中化された
たとえクライアント開発チームが純粋に善意の開発者で構成されていたとしても、彼らがETHステークの大部分を制御している場合、依然としてイーサリアムの仕組みに対して過剰な権限を保持しています。分散化はイーサリアムの中核的な理念であり、これには開発者、ユーザー、カストディアンの分散化が含まれなければなりません。 ETH デポジットを均等に分散することにより、複数のクライアントにわたる開発チームを分散化します。これにより、個々のクライアント チームがいつ何をフォークするかなどの重要な決定を行うことが制限され、イーサリアムの哲学的方向性に対する影響力が制限されます。クライアントの多様性により、開発者レベルでの分散型意思決定が保証されます。
政治
正直な連鎖の社会的回復は政治的に難しい問題です。イーサリアムのコンセンサスメカニズムは、クライアントにエンコードされたルールに基づいて決定される必要があります。これがイーサリアムの主な目標です。このプロセスを妨害すると、イーサリアム コミュニティの分裂につながる可能性があり、主要クライアントに対するコンセンサス バグ/攻撃の軽減に関して、さまざまなユーザーがさまざまな哲学的、倫理的、技術的見解を持つことになります。ガバナンスの決定は扱いにくく、破壊的なものとなり、最大の効果を得るには遅すぎる可能性があります。
実際の例
上記のシナリオが発生する確率は比較的低いです。開発者はソフトウェアのすべてのアップデートを細心の注意を払って調査し、テストしているため、クライアント チームのプロフェッショナルとしての誠実さを疑う理由はありません。ただし、これらのシナリオも単なる仮説ではありません。クライアントの多様性によってイーサリアムのメインネットが永久的な損傷から救われた実例があり、また一部のコンセンサスバグによってイーサリアムのテストネットが破壊されたこともあります。これらの例のいくつかを以下に説明します。
上海攻撃
2016 年 9 月、上海で開催された DevCon カンファレンス中に、ハッカーがイーサリアムを攻撃し、クライアント ソフトウェアのいくつかの脆弱性を悪用し、ネットワークの速度を大幅に低下させました。攻撃者は粘り強く、新たな同様の攻撃を迅速に展開しますが、クライアント開発者はこれらの攻撃をリバース エンジニアリングしてパッチを当てようと競い合います。最終的に、攻撃者は Geth クライアントにパッチ不可能な脆弱性を発見し、ハード フォークが避けられなくなりました。ハード フォークのアップグレード後も、攻撃者は前回の攻撃によって引き起こされた肥大化した状態を悪用するサービス拒否の脆弱性を発見し、クライアントはブロックごとに数万回もの低速なディスク I/O 操作を実行する必要がありました。開発者が Geth の脆弱性の修正に取り組んでいる間に、イーサリアムは同じ脆弱性の影響を受けない代替パリティ クライアントに移行することができたため、クライアントの多様性が実現しました。
上海攻撃は複数のクライアントが存在するため回復可能ですが、同様のバグが大多数のコンセンサスクライアントに影響を与えた場合、状況は大きく異なる可能性があります。 「コンセンサスクライアント」がゲスが攻撃されたときと同じ支配的な地位を持っていた場合、現時点ではバリデーターの大多数がブロックを証明できないため、イーサリアムの金額は最終決定されません。 ETH ステークの 1/3 未満しか認証に利用できないため、非アクティビティ リークが有効になります。
安全でないチェーン
最近、「リモート攻撃」の実現可能性がピルモントのテストネットで実証されました。そのアイデアは、代替ブロックチェーンの歴史を証明するバリデーターのセットを構築することです。これらのバリデーターは、新しいバリデーターを騙してこの不正な「Insecura」チェーンに参加させるために使用され、影響を受けるバリデーターの数が徐々に増加し、最終的にはブロックチェーンのファイナライゼーションを中断し、非アクティブ リークをアクティブにして誠実さを枯渇させる点に達します。バリデーターの大多数。最終的には、影響を受けるクライアントが独自のバージョンのブロックチェーンを完成させる可能性があります。時間と資金の投資が必要なため、この動作は攻撃ベクトルとしては考えられませんが、同様の動きにより、支配的なコンセンサス クライアントのバグがネットワークの大部分に感染する可能性があります。
メダラテストネット
以前は、Prysm クライアントのクロックの問題により、Medalla テストネット上のアクティブなバリデーターの数が突然減少しました。非常に多くのバリデーターがネットワークから脱落し、ステーキングされた ETH の大部分の 2/3 が認証に利用できなくなったため、チェーンを完成させることができません。バリデーターがクライアントを Prysm から他の少数のクライアントに切り替えることに依存しているため、その回復は段階的です。すると、リアルタイムが Prysm クライアントの誤ったクロック時間に追いつき、それまで無効だった証明が突然有効になってしまいます。
これにより、Prysm クライアントが停止し、Teku クライアントと Lighthouse クライアントも、突然大量のプルーフを処理したため、状態が大幅に肥大化しました。もし Prysm が Medalla テストネット上の唯一のクライアントであれば、ネットワーク全体が停止していただろう; Prysm クライアントが管理している ETH 預金総額の 1/3 未満であれば、多くの混乱は避けられただろう。
Prysmデポジットのルートバグ
2021 年の初めに、Prysm クライアントで Eth1 デポジットのルート検証に関連するバグが発生しました。当時、Prysm クライアントは無効なデポジット ルートを生成し、それを他の Prysm ノードに渡すことができました。 Prysm はバリデータのシェアが非常に大きいため、そのような無効なスタブはネットワーク全体に急速に広がります。また、Prysm はブロックごとにスタブを明示的に検証するのではなく多数決メカニズムに従っているため、拡散が加速されます。
このバグの影響は最小限でしたが、ビーコン チェーンの最終処理が中断されることはなく、バリデーターに重大な金銭的罰金をもたらすこともありませんでした。このインシデントは、クライアントの多様性の重要性を 2 つの点で証明しました。1 つ目は、Prysm クライアントの場合です。バリデーターのシェアが小さいため、ネットワーク全体へのバグの拡散が制限され、その影響が軽減されます。2 番目に、ポストイベント分析の記事では、担当者がバグを迅速に特定して修正する際に代替クライアント実装を使用する方法について説明しています。明らかに、これはアクティブに保守されている複数のクライアントがなければ不可能です。
画像の説明
上の図は、イーサリアム クライアントの現在の多様性を示しています。左側は実行クライアントの割合、右側はコンセンサス クライアントの割合です。
上の 2 つの円グラフは、イーサリアムの実行層とコンセンサス層の現在のクライアントの多様性のスナップショットを示しています (この記事を書いている 2022 年 1 月の時点): 実行層は Geth クライアントが大半を占めており、OpenEthereum クライアントははるか遠くの 2 番目に来ています。クライアントは 3 位、Nethermind は 4 位で、その他のクライアントがネットワークに占める割合は 1% 未満です。コンセンサス層で最も使用されているクライアントである Prysm は、実行層では Geth クライアントほど支配的ではありませんが、依然としてネットワークの 60% 以上を所有しており、Lighthouse と Teku がそれぞれ 20% と 14% であり、他にはほとんど使用していません。
2022 年 1 月 23 日の Ethernodes Web サイト (ethernodes.org/) からの実行層データ、Michael Sproul (github.com/sigp/blockprint) からのコンセンサス クライアント データ。ビーコン チェーン クライアントは、クライアントを識別するために使用できる明確な証跡を常に持っているとは限らないため、コンセンサス クライアント データを取得するのはさらに困難です。データは、少数のクライアントに誤解を与える可能性がある分類アルゴリズムを使用して生成されます。ただし、コンセンサス層のネットワーク ノードの大部分が Prysm を実行していることは明らかです。 Prysm の優位性は場合によってはさらに高く、68% を超えました。単なるスナップショットではありますが、グラフ内のパーセンテージは、クライアントの多様性の現状を全体的によく示しています。
実行層のクライアントの多様性が上の図に含まれています。これは、実行クライアントに影響を与えるバグがコンセンサス層にも伝播する可能性があるためです。これは、合併後、コンセンサス層と実行層が結合され、実行が生成されるためです。実行クライアント 実行ペイロードは、ビーコン ブロックのコア コンポーネントになります。
個人ステーカーとステーキングプール
不均衡な顧客割り当てに対処するには、主要な取引所とステーキングプールからの行動が必要になります。ただし、個々のステーカーは、非 Geth/Prysm クライアントの組み合わせを実行することを選択することで役割を果たすこともできます。少数のクライアントを構築する手順については、こちらを参照してください。clientdiversity.orgページが見つかりました。
保有額が 32 ETH 未満のステーカー、またはバリデーターの実行の責任を負いたくないステーカーの場合は、利用できるステーキング サービス プロバイダーがいくつかあります。一部の主要な集中型取引所は ETH ステーキング サービスを提供していますが、ステーキング プール内のクライアントの分布は通常隠蔽されており、これらの取引所が提供する ETH ステーキング トークンの取引可能性は制限されています。上記およびその他の理由により、これらの集中プロバイダーの使用はお勧めできません。
要約する
要約する
元のリンク
