要約

  • IESGは9月25日、SATP Core第17版をProposed Standard候補として最終意見募集に付した。締め切りは10月9日で、RFCとして承認されたわけではない。
  • 草案によれば、中断通知の効力は転送の進行段階で変わる。送信側がcommit-finalを送った後の中断は効かず、ゲートウェイ障害で通知自体が届かない場合もある。
  • 現行版はセッションの回復・再開をサポートしない。外部の取り決めまで不可能と断定する記述ではなく、プロトコルが定める範囲の限界である。

送信側はもう元の資産を消したが、受信側から最終応答が届かない。こうした瞬間を想像すると、転送手順に「中断」というメッセージがあるだけでは安心できない理由が見える。SATP Coreの最終意見募集は、二つのゲートウェイの通信をProposed Standardとして扱うべきか検討する段階に来た。先に審査入りした構成文書やユースケースはInformationalを目指す別文書であり、既報の不透明な台帳をまたぐ保管責任とは論点が違う。

中核草案は安全な通信路と二段階のコミットを使い、一つの資産を二つのネットワークで同時に有効にしないことを目指す。初期化の後、送信側は元の資産をロックして署名付きの主張を出す。受信側は対応する資産を自らの管理下に用意し、準備完了を伝える。送信側による消滅処理、commit-final、受信側による受益者への割り当て、最終確認がその後に続く。画面上では一回の「移転」でも、実際には権限と状態が幾度も変わる。

この順序を読む鍵は第11.5節にある。受信側が準備完了を出す前なら、送信側のロック解除や受信側の局所的な変更を戻す経路を草案は説明する。一方で、中断通知が相手に届かないままゲートウェイが停止する可能性も明記する。そして送信側がcommit-finalを送信した後は、中断の効力はないという。これは実際の損失が生じたという報告ではない。「中断メッセージがある」ことと「いつでも元の状態を保証できる」ことを混同しないための設計上の境界だ。

さらに第10.8節は、現行プロトコルがセッション回復と再開をサポートしていないと述べる。将来版か別仕様で扱う余地は残されている。運営者が手元の記録、契約、手作業の照合で状態を確認できる可能性はあるが、今回の中核仕様がその方法を提供しているわけではない。相手に送った事実と、相手が受け取って実行した事実の違いを埋める作業を、署名だけに託すべきではない。

草案の安全性に関する節は、妨害や重要なメッセージの意図的な遅延・破棄が計算資源や費用、場合によっては経済的損失につながると論じる。具体的な運用事故が確認されたという意味ではない。作業部会の憲章も、参加ネットワーク間に必要となり得る法的な合意などをSATPの範囲外としている。技術的なメッセージの整合性と、事故後の負担配分は分けて考える必要がある。

10月9日は意見提出期限であって、運用開始日でも規格成立日でもない。審査で問うべきは中断命令の有無より、各状態で何が戻せるか、障害後にどの証拠が残るか、再開仕様がない区間を誰の判断で処理するかだ。「原子的」という目標を、利用者がどの時点でも取り消せるという約束にすり替えてはならない。

出典