本文へ移動
Financial Context Wiki

コンセンサスメカニズム：妥当性、フォーク選択、ファイナリティ

コンセンサスメカニズムは、明示した障害・ネットワーク仮定の下で、レプリカを両立する履歴へ収束させます。決定課題、参加者と重み、妥当性規則、提案経路、フォーク選択、ファイナリティ、安全性、ライブネス、実運用を分けて分析します。

更新日

プロトコル分析の教育目的に限ります。コンセンサスという名称だけでは、実運用ネットワークの安全性、ライブネス、正しい実装、分散性、ファイナリティ、公正な順序付け、資産の安全は証明されません。

端的な答え

コンセンサスメカニズムとは、遅延、並行処理、モデルが対象とする障害があっても、非故障レプリカが順序付きログや状態について両立する決定へ収束するためのプロトコルです。ブロックチェーンの完全な仕組みには、提案者選択、ブロックと状態遷移の検証、投票または証明、フォーク選択、コミットまたはファイナリティ、復旧、メンバーシップ規則が含まれ得ます。「多数のコンピューターが同じファイルを保存すること」や、投票閾値、マイニング、ステーキング、報酬設計のどれか一つではありません。

三つの性質を別々に示す必要があります。safety（安全性）は非故障参加者による両立しない決定を防ぎ、liveness（ライブネス）は指定条件下で有効な処理が最終的に進むことを示し、validity（妥当性）は何を決定できるかを制約します。プロトコルは安全性を維持したまま停止することも、後の再編を許す仮定の下で進み続けることもあります。「コンセンサス」という語だけでは、どの保証がいつ成立し、クライアントがどの証拠を信頼すべきかは分かりません。

トランザクションの妥当性と正規履歴の選択は別です。フルノードは現行規則に反する状態遷移を独立に拒否します。同じ入力を使う二つのトランザクションが個別には妥当でも、順序付けまたはフォーク選択がどちらを正規履歴へ入れられるか決めます。多数の資源が両方を同時に妥当にするわけではありません。同様に、バイト列への合意は、オラクルの事実、ブリッジの主張、アプリ計算、法律上の主張の真実性を証明しません。

Proof of Work と Proof of Stake は通常、シビル耐性、提案への影響力、または説明責任のある投票重みを与えますが、その名称だけで完全なコンセンサスプロトコルは定まりません。Bitcoin は Proof of Work と検証、累積作業量によるチェーン選択を組み合わせます。Ethereum の Gasper は、ステーク加重アテステーション、LMD-GHOST フォーク選択、Casper FFG のチェックポイント・ファイナリティを組み合わせます。CometBFT のようなラウンド型 BFT は、異なるメッセージ、閾値、時間仮定、ファイナリティを使います。これらの比率は置き換えられません。

分析手順

  1. 決定対象と範囲を定める。 レプリカが一つの値、順序付きトランザクションログ、各高さのブロック、チェックポイント、アプリ状態のどれを決めるのかを示し、チェーン、ネットワーク、レイヤー、プロトコル版、信頼する開始点を特定します。
  2. 参加者と影響力を定義する。 提案者、投票者、フル検証ノード、ライトクライアント、観測者を分けます。アイデンティティの参加・退出、ハッシュパワー、ステーク、等重みメンバーシップなど影響力の源泉、安価な複製アイデンティティを防ぐ方法を記録します。
  3. プロトコル段階を分ける。 トランザクションと状態の妥当性、提案構築、伝播、投票または証明、フォーク選択、コミット、ファイナリティ、復旧を記述します。妥当なブロックもフォーク選択で敗れ得て、正規ヘッドもまだファイナライズ済みとは限りません。
  4. システムモデルを示す。 認証チャネル、同期性または部分同期性、遅延とタイムアウト、クラッシュとビザンチン障害、二重投票、欠落、適応的侵害、鍵漏えい、分断、最大障害数または重み f を定義します。
  5. 一つの決定を追跡する。 提案から決定まで、メッセージドメイン、高さ、ラウンド、親、ロック、証明書、ローカル状態を追います。遅延メッセージ、提案者の矛盾提案、ラウンドのタイムアウト、二つの妥当な分岐に対する処理を示します。
  6. 安全性とライブネスを別々に検証する。 正確な参加者集合と重みスナップショットからクォーラム交差、チェーン成長などの条件を導きます。次に、進行に十分な誠実な接続と参加が残るかを試し、安全性閾値からライブネスを推測しません。
  7. 証明を実運用へ対応させる。 クライアント版、パラメーター変更、メンバーとステークの集中、鍵保管、ピア多様性、ビルダーやシーケンサーの役割、チェックポイント、弱い主観性規則、再編処理、アプリ独自の確認方針を確認します。

FLP は実運用のコンセンサスが不可能だとは述べていません。完全非同期のメッセージ通信モデルでは、クラッシュ障害が一つだけでも、決定的コンセンサスプロトコルが終了しない許容実行が存在すると述べています。実際のプロトコルは、同期・部分同期仮定、ランダム選択、障害検知器、経済仮定、または弱い終了保証を加えて有用な保証を得ます。追加条件は名称の背後に隠さず明記する必要があります。

計算例

1. 妥当性は正規順序ではない

未使用出力 U は 1 BTC です。トランザクション T_B はそれを Bob に、T_C は同じ出力を Carol に支払います。同じ親状態に対して、各トランザクションは正しい署名と形式を持ち得ますが、妥当な履歴は U を二度消費できません。

競合する妥当なブロックがそれぞれ一方のトランザクションを含む場合、検証は両候補分岐をローカルに保持し、フォーク選択が正規分岐を選びます。T_B が選択履歴に入れば、T_C はその結果状態と競合します。コンセンサスが選んだのは順序であり、不正な署名を正しくしたり、どちらの受取人に道徳的権利があるか決めたりしたのではありません。

2. ノード数ではなく累積作業量

二つの妥当な Bitcoin 型分岐の累積作業量が、同じ任意単位で W_A=240 と W_B=235 だとします。検証ノードは、B をより多くのピアから先に受信していても、累積作業量規則で A を選びます。ピア数はコンセンサス重みではありません。

その後 B が 10 作業単位を増やし A が増えなければ、W_B=245 対 W_A=240 となり、ノードは分岐を検証して B へ再編し得ます。この単純化した計算は、Proof of Work の確認が確率的である理由を示します。深い履歴ほど置換費用が高まるのであって、固定ブロック数で論理的に不可逆になるのではありません。

3. 加重 BFT クォーラムとライブネス停止

検証者総重みを 100 とし、CometBFT 型コミットには、同じ高さ・ラウンドの同じブロックへの >2/3 のプリコミットが必要だとします。整数重み 67 は条件を満たします。67 重みの二つのクォーラムは 67 + 67 - 100 = 34 により、少なくとも 34 重みで交差します。ビザンチン重みが 3 分の 1 未満なら、交差にはプロトコル上競合コミットへ署名しない誠実な重みが含まれます。

同じ閾値はライブネス境界も示します。34 重みがオフラインなら残りは 66 で、オンライン検証者が全員誠実でもコミットを形成できません。プロトコルは停止しながら安全性を保てます。ガバナンス投票や運営者数は欠けたコンセンサス重みの代用になりません。

4. フォーク選択とチェックポイント・ファイナリティは別

単純化した Ethereum Gasper の軌跡で、チェックポイントを C_0、C_1、その直接の子 C_2 とします。アクティブ有効残高の 67/100 を表す投票により C_0 から C_1 へのスーパーマジョリティリンクができ、C_1 が正当化されます。その後、C_1 から C_2 への適格リンクにより、該当する FFG 規則の下で以前のチェックポイントをファイナライズできます。

チェックポイント間では、LMD-GHOST が検証者の最新アテステーションを使い、正当化チェックポイントの実行可能な子孫からヘッドを選び、ファイナライズ済みチェックポイントの制約が競合分岐を除外します。したがって、ヘッド選択、正当化、ファイナライズは関連しつつ異なる状態遷移であり、「67% がこのブロックへ投票した」だけではどれも完全に説明できません。

リスクとレビュー上の失敗

モデルと保証

  • 決定、安全性、ライブネス、妥当性、終了条件を定義せず「ネットワークが合意した」と述べる。
  • Proof of Work、Proof of Stake、マイニング、ステーキング、投票比率の一つを完全なプロトコル仕様とみなす。
  • 51%、2/3、n=3f+1 を異なる障害、時間、重み、ファイナリティモデルへ一律適用する。
  • クラッシュ、ビザンチン動作、鍵窃取、故障チャネル、相関ソフトウェア、ガバナンス掌握を混同する。
  • FLP を、決定的・完全非同期・終了保証という範囲の結果ではなく実用コンセンサスの禁止とみなす。
  • 独立運営者、投票重み、クライアント、クラウド、保管を測らず、ノードや検証鍵だけ数える。
  • 正規、safe、正当化、コミット、ファイナライズ済みを交換可能な状態とみなす。
  • レプリカ合意から外部事実の正しさ、公正な順序、プライバシー、分散性、資産価値を推論する。

プロトコルと実装

  • チェーン、プロトコル版、高さ、ラウンド、親、ペイロード、送信者、メンバーシップ期に束縛されないブロックや投票を受け入れる。
  • 状態遷移、直列化、署名ドメイン、フォーク選択、同点規則、丸めを実装間で食い違わせる。
  • 適格重みスナップショットと重複署名者処理を再構成せずクォーラム証明書を検証する。
  • フォーク、ネットワーク、ラウンド、アップグレード、検証者集合変更をまたいで投票、作業量、証明書を再利用する。
  • タイムアウト、ビュー変更、復旧時にロック、正当化チェックポイント、最高証明書を誤更新する。
  • ローカル観測ヘッドや一つの RPC 提供者のラベルを、独立したネットワーク・ファイナリティ証拠とみなす。
  • 正常経路だけを試し、遅延、分断、二重投票、無効提案、再編、復旧を試さない。

実運用とアプリケーション

  • ハッシュパワー、ステーク、クライアント、リレー、ビルダー、シーケンサー、クラウド、署名基盤を名目上別のアイデンティティの背後へ集中させる。
  • タイムアウトやブロック間隔を現実の伝播・検証時間より短くし、ライブネスを損ないフォークを増やす。
  • 必要な送信元チェーンとアプリのファイナリティ前に入金計上、ブリッジ資産発行、不可逆処理を行う。
  • スラッシング、報酬、トークン価格が常に十分で換金可能なセキュリティ予算を作ると仮定する。
  • 誰が調整し、クライアントがどのチェーンを導入し、以前のどの保証が変わったか認めず、社会的復旧やガバナンス介入を使う。

よくある誤解

  • コンセンサスと検証は同じである。 検証は規則違反データを拒否し、コンセンサスはそれぞれ局所的には妥当かもしれない候補から両立する決定を選びます。
  • ノードが多いほど自動的に安全になる。 生のプロセス数より、影響力、独立性、トポロジー、ソフトウェア多様性、障害モデルが重要です。
  • 51% 攻撃者は誰の署名でも偽造できる。 特定プロトコルで多数資源が検閲や再編を可能にしても、それ自体は秘密鍵を暴露せず、無効な支出を承認しません。
  • 3 分の 2 は常にファイナリティを意味する。 厳密な不等式、メッセージ、ラウンド、重みスナップショット、ロック規則、ファイナリティ条件はプロトコル固有です。
  • 高速ブロックは強いコンセンサスの証拠である。 短い間隔は伝播競争と資源圧力を増やし得ます。遅延は安全性、ライブネス、ファイナリティ仮定と一緒に評価します。

関連トピック

出典

ナビゲーション

Wiki を検索...