本文へ移動
Financial Context Wiki

弱い主観性：信頼済みチェックポイントと安全な PoS 同期

弱い主観性により、プルーフ・オブ・ステークノードは、十分に新しい信頼されたチェックポイントを取得した後に、前方を客観的に検証することができます。古い署名がどのように長期の履歴をサポートできるか、チェックポイントの新しさとソースの独立性がどのように検証されるか、そしてチェックポイントの同期が何を証明しないかを学びましょう。

更新日

教育目的のみ；投資の助言ではありません。投資は損失を招く可能性があります。

直接の答え

弱い主観性は、ノードが信頼されたまたは社会的に裏付けられたチャネルを通じて取得した十分に最近のチェックポイントから開始した後、プロトコル規則に従ってブロック、状態遷移、投票、およびフォーク選択を検証できるプルーフ・オブ・ステークのセキュリティモデルです。「弱い」主観的入力が出発点です。それは任意の後続ブロックを選択する許可ではありません。一度固定されると、ノードはチェックポイントを含まない履歴を拒否し、通常通りに検証を進めなければなりません。

問題は歴史的曖昧さにあります。経済的に罰せられなくなった退出済みのバリデーターから鍵を入手した攻撃者は、有効に見える署名を伴う長い代替履歴を構築することができます。そのバリデーターがスラッシュ可能であった間に正規チェーンを観測していたノードは、有用な記憶を保持しています。全く新しいノード、データベースが削除されたノード、またはプロトコルの安全な最近性ウィンドウを超えてオフラインだったノードは、ジェネシスデータとピアメッセージだけでは社会的に正規な履歴を識別できない可能性があります。

Ethereumでは、ウィークサブジェクティビティチェックポイントは、クライアントが絶対的な基準として扱うepochおよびblock_rootです。同期に成功するためには、カノニカルパスがそのエポックでそのルートを含んでいることを証明する必要があります。ミスマッチは重大な失敗であり、フォーク選択の投票ではありません。ウィークサブジェクティビティチェックポイントは、通常の最終化チェックポイントとも異なります。ノードが事前の記憶なしに、まず二つの矛盾する最終化された履歴に遭遇した場合、最終化ルールだけではどのソーシャル履歴がカノニカルであるかは特定できません。

Ethereumのメカニズムを一般化しないでください。CometBFTライトクライアントは、設定されたtrusting_period内の信頼できるヘッダーから開始し、バリデータセットの重複、署名、時間制限、および証人を用いて信頼を移転します。Ouroboros Genesisの研究は、それに代わり、定められたセキュリティモデルの下で信頼できるジェネシスブロックからブートストラップすることを目的としたチェーン選択ルールを定義します。したがって「プルーフ・オブ・ステーク」は、単一のチェックポイント形式、単一の期間の公式、または単一のブートストラップ手順を意味するものではありません。

また、弱い主観性を同期ショートカットから分離します。チェックポイント同期は起動時間や履歴状態処理を短縮できますが、速度はセキュリティの定義ではありません。信頼されたルートは、それを提供したウェブサイトを認証したり、クライアントの明示された仮定外で実行ペイロードを検証したり、削除された履歴を復元したり、データの可用性を証明したり、隔離されたピアセットを正直にすることはありません。

弱い主観性のブートストラップを検証する方法

1. 正確なプロトコルとセキュリティモデルを特定してください

network、chain ID、ジェネシスルートまたはハッシュ、アクティブフォークまたはランタイム、クライアントバージョン、チェックポイントタイプ、およびコンセンサス仕様を記録してください。プロトコルが最近のソーシャルチェックポイント、信頼されたヘッダーとバリデータセット、ファイナリティプルーフチェーン、または異なるモデルの下でのジェネシスのみを要求するかどうかを確認してください。Ethereumのcompute_weak_subjectivity_periodやCometBFTのtrusting_periodを、そのルールなしに別のチェーンに移植してはいけません。

2. 既存の信頼がまだ有効かどうかを判断する

ノードの最後にローカルで検証された確定チェックポイント、そのエポックまたは高さと時間、現在の時間ソース、およびデータベースの復元状況をインベントリとして記録します。年齢の計算は、覚えているカレンダーの推定値ではなく、プロトコルのライブルールと状態を使用して行います。Ethereumについては、Phase 0 ガイドが current_epoch <= ws_state_epoch + ws_period をテストします。Electra は期間計算を総アクティブ残高および残高変動に基づくように変更します。信頼が期限切れの場合、信頼されていないピアに対して無理に試みるのではなく、帯域外で新しいアンカーを取得してください。

3. チェックポイントを取得して確認する

独立して運用および独立して供給されるチャネルから同じチェックポイントを取得してください。例えば、あなたが運用するノード、別のオペレーター、複数のクライアントチーム、そして異なるインフラストラクチャを持つエクスプローラーなどです。各ソース、取得時間、ネットワーク、epoch、および完全なルートを記録してください。上流を1つコピーする5つのURLは1つの障害ドメインです。単純な応答の過半数は、ソースの独立性、認証済みトランスポート、または社会的インシデントレビューの代わりにはなりません。

4. すべてのチェックポイントフィールドをバインドする

チェックポイント値の前にネットワークとジェネシスの識別を確認してください。完全なルートを切り捨てずに保持し、必要に応じて正確なエポックまたは高さ、ステート、フォークバージョン、取得時間と組み合わせてください。Ethereumのガイドはblock_root:epoch_numberを使用しています；CometBFTの初期化は、信頼できるヘッダーとバリデーターセット、および信頼パラメータも結びつけます。正しいルートが間違ったチェーンや高さに添付されている場合、それは有効なアンカーではありません。

5. フェイルクローズ同期パスを強制する

クライアントの文書化されたインターフェースを通してチェックポイントを構成し、起動ログを保持してください。同期中は、チェックポイント時点での標準パスが提供されたblock_rootと等しいことを要求してください。Ethereumガイドでは、アサーションが失敗した場合に説明的な重大エラーとプロセスの終了を要求しています。チェックポイントを黙って破棄したり、ピアの多数派にフォールバックしたり、新しいピアの応答で上書きしたり、コンセンサスビューが不確かな間にバリデーターの署名を保持したりしないでください。

6. 検証済みのレイヤーと未検証のレイヤーを分ける

コンセンサスのチェックポイント信頼、ビーコンまたはコンセンサスブロックの検証、実行ペイロードの状態、実行状態の同期、履歴のバックフィル、およびアプリケーションの証明を別々に追跡します。Ethereumの楽観的同期では、チェックポイントアンカーのExecutionPayloadを実行エンジンに渡すことなくVALIDと見なすことが許可されますが、楽観的ノードはバリデータの職務を行ってはいけません。Lighthouseのチェックポイントバックフィルは、履歴のハッシュチェーンの整合性と提案者の署名を確認しますが、デフォルトではすべての履歴状態を再構築することはありません。

7. 復旧を更新、監視、リハーサルする

適用期間内で快適にマージンを設定し、アラートを設定して更新してください。最終化、クロックの状態、クライアントの異議、execution_optimisticの状態、ピアの多様性、チェックポイントの経過時間、バックフィルのギャップを監視してください。削除されたデータベース、期限切れのチェックポイント、矛盾するソース、利用できないプロバイダーからの回復をリハーサルしてください。アンカーや決定の署名済み記録を保持してください。ただし、アーカイブされたチェックポイントを恒久的に信頼される古いチェックポイントにしてはいけません。

例題

残りの余裕があるEthereumチェックポイント

適用可能なElectra参照計算がws_period = 3,532 epochsを与える例示的な状態を使用します。current_epoch = 420,000および独立して裏付けられたチェックポイントがcheckpoint_epoch = 418,200であると仮定します：

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

ガイドの最新性テストは420,000 <= 418,200 + 3,532であるため、チェックポイントは期間内にあります。32 slots * 12 seconds = 6.4 minutes per epochでは、その年齢は1,800 * 6.4 / 1,440 = 8 daysです。残りの余裕は3,532 - 1,800 = 1,732 epochs、または1,732 * 6.4 / 1,440 = 7.6978 daysです。これはライブネットワークの約束ではなく、参照テーブルの期間を使用しています。クライアントは実際のフォークと状態から計算する必要があります。

期限切れのチェックポイントは、より多くのピアによって修復されません

current_epoch = 500,000、checkpoint_epoch = 496,000、および該当するws_period = 3,532 epochsを仮定します:

checkpoint_age = 500,000 - 496,000 = 4,000 epochs.

500,000 > 496,000 + 3,532のため、チェックポイントは4,000 - 3,532 = 468 epochsによって古くなっています。1エポックあたり6.4分として、これは境界を468 * 6.4 / 60 = 49.92 hours分超えています。100のピアから同じ期限切れのルートをダウンロードしても前提は復元されません。オペレーターは、信頼できる、裏付けのあるチャネルから十分に新しいチェックポイントを入手する必要があります。

ソース数対ソース独立性

あるオペレーターは5つの応答を受け取ります。4つはepoch = 600,000とラベルされた応答と、root_Aとラベルされた同一の完全ルートを報告し、1つはroot_Bとラベルされた異なる完全ルートを報告します。調査の結果、意見が一致している3つのウェブサイトはすべて同じホストノードをプロキシしており、4つ目はオペレーター自身のノードです。見かけ上の合意は4 / 5 = 80%ですが、これは実際には独立した系統2つ分しか表していません。3つの独立した管理およびデータ経路を要求するポリシーの下では、このチェックポイントはまだ承認されていません。3つ目の独立したオペレーターがroot_Aを確認し、異議を唱えるサービスは分離され、出所記録が決定の理由を説明します。

CometBFTスタイルの信頼期間予算

unbonding_period = 21 daysで構成されたチェーンと、オペレーターが選択したtrusting_period = 14 daysがあり、信頼期間がアンボンディング期間より短いという要件に一致しています。11 daysで経過した信頼されたヘッダーには14 - 11 = 3 daysの余裕があります。毎日の更新目標は運用マージンを残します。クライアントが16 days後に戻る場合、ヘッダーは信頼期間を2日超過しており、新しい信頼済み初期化を通じて置き換える必要があります；Ethereumのエポック式ではこのCometBFTのケースは決定されません。

リスクとレビューの失敗

  • ネットワークの取り違え: テストネット、フォーク、複製チェーン、別のジェネシスの有効なルートは、誤った履歴を固定する可能性があります。
  • 古いチェックポイント: 適用期間外のルートは、必要な最近のバリデーター集合という仮定を満たしません。
  • 期間式の取り違え: フォーク更新、バリデーター残高、チャーン規則、アンボンディング、安全パラメータで期限は変わり得ます。
  • 情報源の単一障害点: 複数のエンドポイントが同じノード、クラウドアカウント、データベース、DNS事業者、運営者を共有する場合があります。
  • 配布経路の侵害: 悪意あるリリース、ウェブサイト、パッケージ、DNS応答、サポートメッセージがチェックポイントを差し替える可能性があります。
  • 省略表記での比較: 接頭辞、スクリーンショット、整形済み識別子だけの一致は、完全なルートの相違を隠します。
  • フィールドの不一致: 正しいルートでも、エポック、高さ、状態、フォーク、チェーンが違えば同じチェックポイントではありません。
  • ピア多数へのフォールバック: エクリプス攻撃を受けたノードには多数の敵対ピアが見えます。ピア数は信頼済みアンカーに優先しません。
  • サイレントフォールバック: 拒否されたチェックポイントをクライアントやラッパーが無視すると、フェイルクローズ制御が無効になります。
  • 競合する確定済み履歴: 新しいノードは、両方の分岐に「確定済み」と表示されているだけではコンセンサス障害を解決できません。
  • 時計の誤差: 不正確なローカル時刻は、スロット、エポック、経過時間、信頼期間、将来ヘッダーの検査を誤らせます。
  • 楽観状態の混同: 取り込んだコンセンサスブロックにも、完全には検証されていない実行ペイロードが含まれる場合があります。
  • 早すぎるバリデーター業務: 楽観状態、未同期、または不確かなアンカーで署名すると、誤投票やスラッシングを招く可能性があります。
  • 履歴完全性の混同: ライブヘッドが有効でも、チェックポイント同期とバックフィルには履歴状態が含まれないことがあります。
  • 無効なバックフィル署名: ハッシュで連結された履歴ブロックにも、プロトコル所定の提案者署名検査が必要です。
  • 実行・アプリケーション証明の不足: コンセンサスの固定だけでは、任意の RPC 値、コントラクト上の主張、オフチェーン索引は証明されません。
  • データ可用性の欠落: 状態ルートを知っていても、すべてのボディ、Blob、証人、履歴記録を取得できるとは限りません。
  • 期限切れの復旧計画: 障害時に初めて期限切れに気づくと、独立したチェックポイント情報源が利用できない場合があります。
  • 社会的調整の集中: ガバナンス、クライアントチーム、エクスプローラー、取引所、運営者が利害や依存先を共有する場合があります。
  • 誤った一般化: 別の PoS 設計は、異なる仮定、証明チェーン、信頼期間、ジェネシス起点の保証を採用している可能性があります。

一般的な誤解

弱い主観性は、起動後にプロトコルのルールが主観的であることを意味しますか？

いいえ。そのノードは、特定の最近のアンカーをソーシャルまたは信頼できるチャンネルを通じて受け入れ、その後、決定論的な検証とフォーク選択ルールを適用します。アンカーと競合するブロックは拒否されます。

最終化されたチェックポイントは、自動的に安全なブートストラップチェックポイントですか？

いいえ。それは意図されたネットワークおよび正典的な社会的歴史に属し、適用される規則の下で十分に最近であり、必要なフィールドを含み、信頼できる裏付けのある経路を通っている必要があります。攻撃者が提供した歴史で初めて観察された最終性は、出所を確立するものではありません。

ジェネシスからの同期は、長期攻撃の問題を解消しますか？

最近の弱主観性チェックポイントを必要とするプロトコルには適していません。ジェネシスから内部的に有効な署名を再生しても、新しいノードにコミュニティが実際にどちらの古い確定履歴をたどったかを教えることはできません。他のプロトコルでは、異なる前提の下で異なるジェネシスブートストラップ保証を提供する場合があります。

チェックポイント同期はすべての過去の実行と状態を検証しますか？

いいえ。クライアントの動作は層状であり、実装に依存します。ノードはアンカーを信頼するか楽観的にインポートすることもあり、現在の実行状態を別途同期し、すべての過去の状態を再構築することなく、ブロックリンクと提案者の署名のみをバックフィルすることもあります。

ハードコーディングされたチェックポイントを永遠に信頼できますか？

いいえ。チェックポイントはネットワークに紐づいており、それだけです。それは監査記録や過去の制約として有用であり続けることができますが、最近の信頼仮定が期限切れになったノードは、適切に最近のアンカーか、そのプロトコルで指定された回復プロセスが必要です。

関連するトピック

情報源

ナビゲーション

Wiki を検索...