予約から決済・回収まで
技術スライドの粒度で、所有権・資格・受付・部分約定・一括決済・正本照合をつなぐ。
最初に実行経路を区別する
ここではapplication note railのノート、予約指示、受付証明、約定、解除、受領権を説明します。QOMMのstanding-pool経路とOCLOBブラウザのnative account adapterは、型と状態遷移が異なります。両デモの成功だけで、このページの全関係を実証したことにはなりません。
AvalancheGoがブロックの合意を担い、Rust VMが登録された検証規則で正本を更新します。市場の意味はアプリの責務です。RPCからの読戻しは、合意証明を独立検証するライトクライアントとは異なります。
所有権と金額を、同じ秘密の入力へ結ぶ
支出は候補集合への所属と、一つの入力の所有権を位置を隠して証明します。金額も同じ秘密位置に結ぶ必要があります。独立した所有権証明と金額証明では、別の入力を選べてしまいます。nullifierで一回の消費を拘束し、出力鍵と暗号文も署名・証明対象に含めます。
Triptychの固定参照実装は証明コアです。候補の利用可否、資産タグ、出力の拘束、再利用拒否まで監査済みになるわけではありません。
C_a(v;r)=vG_a+rH,\qquad i_{\rm ownership}=i_{\rm amount}保存則にはゼロ値と範囲の関係が必要
残差を何らかの値に開けることは、残差の値がゼロである証明ではありません。保存則には値ゼロ専用の関係を使い、範囲証明で負の金額と剰余上の帳尻合わせを除きます。資産別の基点を使う場合も、意図した資産を指図に拘束します。
v_{\rm in}=v_{\rm reserve}+v_{\rm change},\quad 0\le v_{\rm reserve},v_{\rm change}<2^\ell,\quad D=\rho H実行環境・操作・更新前状態・出力を拘束する
用途別のdomain分離で、別の証明への使い回しを防ぎます。実行環境、アプリの範囲、委員会の版、操作番号、更新前状態、出力の全payloadで今回の処理を識別します。以下は説明式であり、直列化順とhash domainは実装が定義します。正本全体のrootへの拘束は、他の並行更新でも再提出を必要にし得ます。
d=H({\rm domain},{\rm version},{\rm deployment},{\rm scope},{\rm operation},R_{\rm before},{\rm payload})資格と予約指示を循環せずに結ぶ
予約指示には既存の資格証明の要約を入れます。後から生成する提示証明の要約を先に要求しません。提示側の文脈に署名済み指示と必要資格の範囲を入れます。非公開の承認サービスが実際のDeKYX提示と指示署名を検証し、承認対象へ署名します。VMの所有権・金額検証は引き続き必要です。
予約で三つの資源を一括更新する
- 入力ノートを消費し、予約とお釣りの出力を作る。
- 必要な保証枠を利用可能から予約済みへ移す。
- 予約の適用範囲、期限、委員会、更新番号を登録する。
VMは全関係が成立した候補状態だけを一括適用します。一部だけ有効でも部分的な予約は作りません。permit発行者は一貫した正本を読んでから発行します。
秘密のpermitとMPC受付用admissionを分ける
ReservationPermitは正本の予約・資産参照を所有者側に保持し、閾値暗号化できます。ReservationAdmissionはMPC受付に不要な参照を除き、金額コミットメントを再秘匿化します。許可された注文と金額の関係は証明で保持します。発行者のattestationはその発行者の証言であり、合意証明ではありません。
C^\prime=C+\delta H=vG+(r+\delta)H順序・照合・金銭関係は別の命題
OCLOBの5/7順序署名、7者malicious-Shamir MPC、決済権限の署名閾値は、それぞれ異なる目的を持ちます。市場遷移の元の証拠は委員会attestationです。数量・価格・積・残額には別の数学的な証明があります。結果のhash一致だけで照合アルゴリズムどおりの実行は証明できません。
m=qp,\qquad c^\prime=c-m\ge0,\qquad s^\prime=s-q\ge0部分約定は現在の残額を消費する
原予約と、現在の残額・更新番号・直前指図の要約を分けます。100の予約から40約定すると60・番号1になり、次の20約定はその60を消費して40・番号2に進みます。原予約100や古い番号を使う指図は現在状態に合わず拒否されます。
実際の決済は証券と資金の両側を同時更新します。この数値例は片側の説明です。
(100,0)\longrightarrow(60,1)\longrightarrow(40,2)一括決済は集合と順番も署名対象にする
各指図の署名にgroup digest、集合内の位置、件数を入れ、一部抜出し・並べ替え・別指図の混入を拒否します。現行application fill groupはpayload上限内の2〜8件を扱い、候補状態の残額を後続指図へ引き継ぎます。一件でも失敗すれば候補全体を破棄します。一つのDeFMI正本上の原子性であり、独立した複数台帳間の原子性ではありません。
g=H({\rm deployment},R_{\rm before},[{\rm op}_0,\ldots,{\rm op}_{n-1}]),\qquad {\rm signedFill}_i\supset(g,i,n)取消・期限切れ・受領権の取込みを分ける
- 取消
- 予約で指定された委員会が未消費残額の返却を承認します。
- 期限切れ
- この経路では正本ブロック時刻が予約期限を超える必要があり、期限ちょうどでは解除できません。提出者は既定の返却先を変更できません。
- 取込み
- 受領者が移し先へ署名し、確定済み受領権を支出可能ノートへ変換します。取込みを遅らせても成立済み決済の取消権にはなりません。
正本を照合してから秘密板を進める
準備済み結果を保存し、その指図を送信して、取引ID、block ID、高さ、指図hash、更新前後rootを照合します。複数約定なら全件が保存した計算と一致してから秘密板と秘密残高を進めます。timeoutで結果が不明な場合は照合対象であり、成功・失敗のどちらとも断定できません。
ブラウザのaccount adapterは5台のrootと、対象口座のcommitment・更新番号を確認してから候補状態を採用します。秘密板の再起動復旧は未実装のため、状態の再使用は拒否し、残高を黙って初期化しません。