要約

  • Commit-Finalより前なら、送信元のロック解除や宛先側の暫定mintの取り消しが可能だが、元資産をburnした後のabortは無効だと第17版は明記する。
  • 現行Coreはセッション回復と再開をサポートしない。Architectureはログとチェックポイントを要求する一方、共通形式と再開位置を将来作業と実装判断に残す。
  • 運用には、停止の意思、送信、相手の受信、ゲートウェイの主張、二つの不透明なネットワークで観測した状態を分ける「後戻り不能点の台帳」が必要になる。

障害対応画面にabort成功と表示されても、資産が戻ったとは限らない。

送信側ゲートウェイがCommit-Finalを送り、元ネットワークで資産を消却したと主張する。その直後に接続が切れ、宛先から最終確認が届かない。ここでabortを送っても、SATP Core第17版の第11.5節では既に実効性がない。宛先は同等資産をmintし、受益者へ割り当てる約束をしているからだ。

この文書は2026年9月25日にIESG Last Callへ入り、期限は10月9日である。Datatracker履歴が示すのはProposed Standard候補のInternet-Draftであり、RFC、導入実績、実際の移転結果ではない。

SATPは、内部を相互に読み書きできない二つの資産ネットワークをゲートウェイで結ぶ。SAT Architectureは原子性、一貫性、分離性、永続性を望ましい性質として掲げるが、メッセージ互換性だけでは不十分だとも述べる。下位システムが協調して状態を変えなければならない。

Stage 1のproposal、receipt、commence、ACKは合意したパラメーターを署名とハッシュでつなぐ。これは合意したバイト列の証拠であり、資産移動の証拠ではない。Stage 2では送信元がロックまたはエスクローを主張する。主張形式は各ネットワークに依存し、Coreの範囲外だ。受信側のreceiptは主張を受け入れた証拠であって、送信元台帳を直接観測した証拠ではない。

Stage 3はlockAssertionExpirationまでに終える必要がある。Commit-Readyは、宛先が等価資産をmintし、一時的に自分へ割り当て、次へ進めると表明する。その前なら元資産のロック解除や暫定mintの取り消しが可能だ。次のCommit-Finalはburnの主張、ACK-Finalは受益者への割り当ての主張、Transfer-Completeはセッション終了を意味する。

この差を一つの「commit済み」に畳むと、切断位置が分からなくなる。Commit-Readyは受益者の支配ではなく、Commit-Finalは宛先確認ではなく、ACK-Finalは送信側の閉鎖通知ではない。

abortにも段階がある。ローカルで決めた、送信した、相手が受信した、ネットワーク状態が復元した、は別の出来事だ。草案はabortが失われ得ること、受信前にゲートウェイが停止し得ることを認めている。送信ログだけで「ロールバック済み」と表示してはならない。

Core第10.8節は現行版に回復・再開機能がないと明記する。一方Architectureは、クラッシュ回復用イベントログとチェックポイントを実装に要求し、代替ゲートウェイによる継続を想定する。しかし共通の意味と形式は将来作業で、どこから再開するかは実装戦略次第だ。RFC 5424はログの土台になっても、burnの再実行可否を定めない。

RFC 8446のTLS 1.3は通信路を守り、RFC 7515のJWSは主張を鍵に結び、RFC 9457はエラーを構造化する。いずれも二つのブラックボックス内部のlock、burn、mint、assignmentを自動的に観測するものではない。

SAT Use Casesは船荷証券や信用状などを例示するが、採用証拠ではない。権利を表す可能性があるからこそ、プロトコル受領、ネットワークfinality、法的権限を一つに混ぜてはならない。

必要な台帳は、sessionIdとtransferContextIdを全署名メッセージ、直前ハッシュ、元側のlockとburn、宛先側のmintとassignment、ロック期限、送受信時刻、ゲートウェイID、各ネットワークの確定性、再起動世代、abortの送受信、双方が最後に確認した段階へ結び付ける。

Lu HengのRunning-Code Primacyは、実行中の状態をメッセージ名より先に置く。Minimum Initial Specificationは共通線上仕様を狭く保ち、Reality Layersは署名された記号を、それが指す現実そのものへ昇格させない。

情報源