要約

  • SATP Core 17のIETF Last Callは2026年10月9日まで。ArchitectureとUse Cases 10は10月7日までで、いずれもまだInternet-Draftである。
  • 署名と前メッセージのハッシュにより、Commit-Ready、Commit-Final、ACK-Final-Receiptの発行者と順序を検証できる。
  • burn／mintの証明方式はネットワーク固有であり、Core 17はセッション復旧を扱わない。復旧ログの共通意味論も将来課題である。

共通化されたのは会話である

SATP Coreは、異なる資産ネットワークを代表する送信側ゲートウェイと受信側ゲートウェイの間で、burn-and-mint型の移転を進める。二相コミットを用い、ACID特性を目標としている。Core 17はProposed Standardに向けたLast Call中で、ArchitectureとUse CasesはInformational文書を目指す。Last Callは審査の段階であり、完成や導入を示さない。

手順が残す共通証拠は明確だ。受信側はCommit-Readyで同等資産を生成したと主張する。送信側はCommit-Finalにburnのアサーションを載せる。最後に受信側がACK-Final-Receiptで、生成した資産を所定の受益者に割り当てたと主張する。各メッセージは署名され、直前のメッセージのハッシュを含む。

この設計により、第三者は「誰が、どのセッションで、何を、どの順番で述べたか」を検証しやすい。署名済みアサーションは責任帰属と紛争処理に有力な材料になる。一方、署名が直接証明するのは発行者とメッセージの完全性であり、記載された外部状態を独立に観測したことではない。

アサーションの中身は別の観測面を要する

Architectureは、burnとmintの機構が各資産ネットワーク固有で範囲外だと明記する。それらを暗号学的に証明する機構もネットワーク固有である。公開型台帳と許可型台帳、閉じた登録簿では、確定の意味も照会方法も異なり得る。

したがって、SATP transcriptとネットワーク状態証明は区別して保存すべきだ。前者はゲートウェイの発言を示し、後者はローカルなルールの下で状態変化を示す。受益者が実際に資産を制御できるかは、さらに別の検証になり得る。割当てのアサーションと、受益者による使用可能性は同じ事実ではない。

Coreが示す不可逆点も重要だ。送信側が元資産をburnする前なら、abortは比較的小さなコストで戻せる。Commit-Final送信後は、元資産がburnされ、先の資産がmintされ、受信側が割当てに合意済みなので、abortは有効でない。この境界を越える判断には、正しいメッセージ順だけでなく、実行主体となるネットワークの証拠が必要だ。

復旧可能性は実装の内部に残る

Architectureはイベントログとチェックポイントの保持を実装に求める。ログが利用可能で標準化されていれば予備ゲートウェイが再開できるとする一方、再開地点は実装の復旧戦略次第だという。クラッシュ管理ログの意味論と構文は将来作業である。Core 17も、現在の版はセッションの復旧・再開を支援しないと明記する。

これは個別実装が復旧できないという主張ではない。実装は状態複製、鍵管理、冪等処理、フェイルオーバー試験を独自に備えられる。ただし、別実装のチェックポイントを予備ゲートウェイが共通仕様だけで解釈する可搬性は、まだ標準化されていない。

TLS 1.3は通信路を保護し、JWTはアサーションを表現でき、Syslogは将来のログ設計の材料になる。しかし形式は観測面ではない。二つの資産ネットワークや受益者の制御を、それだけで読み取ることはできない。

Heng Luが示す「信頼と仕組み」「記録された主張と運用上の真実」を分ける視点は、SATPを過小評価せずに境界を守る。ゲートウェイを信頼する設計を採用しても、不可逆な利用判断に必要な裏付けは別途定義できる。

出典