ファイナリティは、待つのではなくクォーラムで決まる。

ステーク、権限、検証済みワークという三つの力が、バリデーターの輪の中へ流れ込みます。バリデーターは、一つの提案された状態遷移に対して署名付きの票を投じます。票が設定されたビザンチン・クォーラムに達すると、それらはクォーラム証明書へと結合し、証明された状態はファイナルと記されます。

1. 01

   選出

   ステークが、そのエポックのセキュリティセットを構成するバリデーターを決定します。各バリデーターの検証済みワークの実績に基づく権限スケジュールが、提案者と委員会の職務を割り当てます。

2. 02

   提案

   予定された提案者が、VectorLanesによって実行された状態遷移の順序付けされたバッチをまとめ、その結果生じる状態コミットメントとともに提案します。

3. 03

   検証

   バリデーターはそのバッチを決定論的に再実行し、同じ状態ルートに到達することを確認します。再現できない提案には、票が投じられません。

4. 04

   投票

   各バリデーターは、自らが検証した状態遷移に署名します。票は提案者に集まり、すべてのピアにブロードキャストされるのではなく、一つの簡潔な証明書に集約されます。

5. 05

   証明

   署名が設定されたビザンチン・クォーラムに達すると、それらはファイナリティ証明書を形成します。積み上げるべき確率的な確認の段階はなく、その状態遷移はファイナルです。

6. 06

   記録

   可用性、検証、サービスは計測され、検証済みワークとして記録されます。矛盾する二つの状態遷移に署名するといった証明可能な不正行為は、スラッシングの証拠になります。

• クォーラムの交差明示された障害モデルのもとでは、いかなる二つのクォーラムも、少なくとも一人の正直なバリデーターにおいて重なり合い、正直なバリデーターが矛盾する二つの状態遷移に署名することは決してありません。したがって、矛盾する二つの状態が両方とも証明されることはあり得ません。
• ファイナリティ後の再編成なし証明された状態遷移は、明示された障害モデルのもとでは置き換えられません。アプリケーションは、ファイナライズされた状態のためのロールバックロジックを必要としません。
• ビューチェンジによるリブネスクラッシュした、遅い、または悪意のある提案者は、一つのビューを遅らせることはできますが、ネットワークを停止させることはできません。ペースメーカーが指揮権を巡回させ、次の提案者のもとでコンセンサスが再開します。
• 証明可能な不正行為へのスラッシング矛盾する二つの状態遷移に署名することは、それ自体で完結した証拠——両方が正直であることはあり得ない、二つの有効な署名——を生み出します。責任のあるステークはスラッシングされます。
• プロトコルの健全性維持形式仕様、クライアントの多様性、バージョン管理された署名スイートが、一つの実装上の不具合や一つの暗号技術上の弱点が、ネットワーク全体の障害になってしまう可能性を減らします。

トレーダーと利用者

取引や決済は、ファイナルであるか、まだファイナルでないかのいずれかです。待つべき曖昧な中間状態は存在しません。

機関

決済のファイナリティは、内部の決済ポリシーと担保ポリシーに直接対応し、すべての証明書は、突合と監督上のレビューのために検証可能な証拠となります。

開発者

一つのファイナリティの信号の上に構築できます。ライトクライアントはノードを信頼するのではなく証明書を検証し、ファイナライズされた状態は再編成への対応を必要としません。

• VectorLanes並列実行レーンから、一つの確定状態へ。
• ApexMatch決定論的なネイティブマッチングエンジン。
• Q-Switch量子時代への移行に備える暗号方式の柔軟性。
• GateMesh管理されたクロスチェーン相互運用。