Summary

  • IESGは9月23日、SATPの相互運用アーキテクチャとユースケースの二つの草案について、情報提供用RFCに向けた最終意見募集を始めた。締め切りは10月7日で、採択済みのRFCではない。
  • 送信元ネットワークが非公開なら、受信側ゲートウェイは台帳を直接読めず、送信側が署名した資産ロックの宣言に頼る。草案は事前の同意、運用者の確認と移転中の責任を前提にする。
  • 署名を連ねた記録は紛争の検証材料になるが、隠れた台帳の正しさや法的な権利移転を、それだけで確定させるものではない。

二つの台帳の間に資産を置くとき、受信側が本当に見ているのは何か。SATPの設計では、送信側が元の資産を動かせない状態にし、その事実を署名付きで相手のゲートウェイへ通知する。相手が閉じたネットワークの内部状態を閲覧できない以上、通知は不可欠だ。一方、署名の検証と台帳の事実確認は別の作業である。

草案は各ネットワークの内部構造を外から隠せる設計を採る。交換前に資産、送信者、受益者、双方の同意が確認され、ゲートウェイの所有者も特定されていることを想定する。所有者は署名するメッセージに責任を負い、移転の間はゲートウェイが資産を一時的に支配する、とも記す。いずれも文書上の運用条件であり、現実の事業者が満たしたという調査結果ではない。

ロックの宣言を受けた後、二つのゲートウェイはコミット手順を進め、送信元の資産を消滅させ、受信先で同等の資産を生成する。段階ごとの署名とメッセージの連結は、後日の紛争で権限のある第三者が経過を確かめる手掛かりとなる。しかし送信元の局所データが誤っていれば、改ざんされていない履歴も誤りをそのまま運ぶ。

今回の手続き上の出来事は限定して読む必要がある。IESGが9月23日に意見を求めたのは、アーキテクチャ第10版とユースケース第10版であり、いずれも情報提供用の文書を目指す。10月7日が回答期限だ。別に存在するコア・プロトコル草案は提案標準を目指しているが、この二文書の募集をもって標準化が完了したわけではない。金融や流通の例は想定用途で、導入事例ではない。

SATP作業部会の憲章は、参加ネットワークに法的またはその他の事前合意が必要になるだろうと述べ、その枠組みと履行の証明をプロトコルの対象外とする。Lu Hengが区別する証拠と権威もここで効く。記録を裁定の材料にすることと、記録そのものに権利を裁定させることは違う。

Sources