DeCCP: 分散型清算機関

名前の「Central（中央）」は論理上の役割を指す。債務の受入、ネッティング、保証、処理は、すべて一つの正式な清算状態を通して行う。「Decentralized（分散）」は統制の仕組みを指す。重要な変更には、独立した権限者のうち閾値以上の承認が要る。決済は一人の運営者を信じるのではなく、DeFMI に照らして検証する。これらの crate は資産を預からない。crate だけで認可を受けた清算機関になるわけでもない。

出典: deccp/README.md、defmi/DEFMI.md §4.2 · crate: deccp-core（ワークスペースの唯一のメンバー）。Aethel 向けアダプタは aethel リポジトリ側の aethel-deccp

清算の流れ

flowchart LR
    G["閾値の権限者"] --> B["ClearingBook を作成し統治する"]
    K["DeKYX
資格の証明"] --> M["清算参加者を受け入れる"]
    D1["DeFMI
資本、基金、担保のロック"] --> M
    M --> O["検証済みの債務を受け入れる"]
    Z["zkPI 検証器"] --> O
    O --> N["ネット・ポジションを計算する"]
    N --> C{"リスクと資産保存の
検査がすべて通るか？"}
    C -->|いいえ| R["状態を変えずに拒否"]
    C -->|はい| S["決済提案"]
    S --> D2["DeFMI
提案どおりに決済"]
    D2 --> E["決済受領証を記録"]
    M --> X["デフォルト宣言"]
    X --> W["損失ウォーターフォールを適用"]
    W --> D2

DeCCP が清算やデフォルト処理の最終状態へ進むのは、DeFMI の受領証がその提案またはウォーターフォールの文脈そのものに束縛されているときだけである。一部だけの受領証や、内容の食い違う受領証では何も確定しない。

受入と証拠金

参加者の受入には、閾値承認、検証済みの DeKYX の資格結果、DeFMI 上で有効な清算基金のロックが要る。DeCCP が記録するのは scope 付きの subject line（scope 内の仮名）であり、法的な名前ではない。資本、清算基金、担保のロックの識別子は一意でなければならない。一つの外部ロックで複数のリスク・ポジションを裏付けることはできない。証拠金の変更と、サイクルの進行に関わる重要な操作には閾値承認が要る。ネットのリスク借方は、すべて参加者が差し入れた証拠金の範囲に収まらなければならない。収まらなければ、そのサイクルの締めは拒否される。

三つのネッティング方式

どの資産についても、ネット・ポジションの合計はゼロでなければならない。できあがった提案には正規化したダイジェストが付く。そのため、決済の受領証を別のサイクルや別の脚の組に流用することはできない。commitment にした残高の上で各方式にかかる暗号のコストは、DeFMI のページにある。重要な結果は次のとおりである。更改（novation。債務の相手を清算機関に置き換えること）は算術的には無償で、乗算 2 回で済み、証明は要らない。そして清算済みサイクルのコストは、取引件数に比例して増えなくなる。更改そのものは取引 1 件あたり 0.53 µsである。

保証枠

金額を公開する経路では、枠の総容量、予約済み、消費済み、個別の留保（hold）を追跡する。シーケンス番号を compare-and-swap 式に検査するので、同時に来た二つの要求が同じ残り容量を使うことはない。金額を秘匿する経路では、平文の金額ではなく、保証額の commitment と DeFMI の状態ダイジェストを保存する。予約、解放、請求の各操作は、直前のシーケンス番号とダイジェストを名指しする。DeFMI アダプタは、隠した金額の関係、容量の上限、遷移証明、最終の受領証を検証する。検証が済むまで DeCCP は進まない。Aethel 側のアダプタ aethel-deccp が、Aethel の保証のライフサイクルで起きるイベントをこれらの遷移に対応付ける。この対応付けは aethel リポジトリにあり、deccp-core を取り込む向きになっている。そのため DeCCP が Aethel の crate を取り込むことはない。

デフォルト・ウォーターフォール

デフォルト事案には次を記録する。引き金になった証拠、破綻参加者が持つ使える資源、参加者全体で負担する層、CCP 自身の拠出、そしてその結果としての取り崩し。処理には、閾値承認と、そのウォーターフォールの文脈そのものに対する DeFMI の受領証が要る。決済側では、トランシェ（取り崩す順番の層）の順序を守らせるために、commitment にした積を恒等式（draw_k × remaining_{k−1} = 0）に固定する。この式は、前の層が残っているうちは次の層を取り崩せないことを表す。トランシェ 1 段あたり、証明の構築に約 11 ms、検証に 1.4 ms かかり、これはデフォルト 1 件につき一度だけである。CCP の資本は、破綻参加者の基金拠出と参加者全体の負担プールの間に置く。CPMI-IOSCO と EMIR が定める位置である。

すべての受入経路で確かめる不変条件

• 閾値承認は正規化した操作ダイジェストに束縛される
• 参加者の subject line、外部ロック、債務、保証枠、留保は、それぞれの scope 内で一意である
• 受け入れる債務は InstructionPort を通らなければならない。ゼロでないダイジェストがあるだけでは有効な zkPI ではない
• ネット・ポジションは各資産の総量を正確に保つ
• 証拠金と保証の予約は、使える容量を超えられない
• 期限切れ、解放済み、消費済みの留保は再び請求できない
• 決済とデフォルトの受領証は、その提案の文脈そのものを名指ししなければならない
• 無効な操作は、状態を部分的にも更新せずに失敗する

永続化と復旧

ClearingBook は直接デシリアライズできない。検査なしで復元すると、定足数、資格、決済の検証を飛ばしてしまうからである。復旧の方法は二つある。一つは、検証済みの操作を新しい清算簿に再生する方法。もう一つは、ClearingSnapshot の正規化ダイジェスト、権限者の集合、承認、構造上の不変条件を検証したうえで復元する方法である。restore_authenticated を使ってよいのは、ホストの記憶域がすでにそのスナップショットのバイト列そのものに commit している場合だけである。状態ルートの下に置かれたコンセンサス状態がその例である。この関数が省くのは二度目のスナップショット署名の検証だけで、構造の検証は省かない。

ポート

flowchart TB
    DK["DeKYX"] -->|検証済みの資格| EP["EligibilityPort"]
    Z["zkPI"] -->|検証済みの指図| IP["InstructionPort"]
    DF["DeFMI"] -->|ロックと受領証| DP["DeFmiPort"]
    EP --> CORE["deccp-core"]
    IP --> CORE
    DP --> CORE
    A["aethel-deccp（aethel リポジトリ）
任意の保証アダプタ"] --> CORE

deccp-core は Aethel、DeKYX、zkPI、DeFMI のどの crate にも依存しない。配置側は、クレデンシャル方式や決済ネットワークを置き換えても、DeCCP 内部の不変条件を弱めずに済む。

DeCCP がしないこと

• 提供者をまたぐクロス・マージン: ある清算提供者でのポジションを、別の提供者でのポジションと相殺しない。
• 銘柄をまたぐ更改: 債務のグラフは資産ごとに分かれている。資産の混ざった更改はネッティングせず、拒否する。
• 法的な更改: 算術として有効であることは、登録簿の規則の下で有効であることを意味しない。「CCP はもう不要」という言い方は、主張してはならないことの一覧に載っている。
• 取引の抜け落ちの検出: 清算機関はもう取引を捏造できないが、取引を一件だけ抜くことはできる。辺が一本欠けたグラフも、それだけ見れば整合している。抜くことを高くつくようにしているのがトランシェである。