Summary

  • IESG于9月23日对SATP架构草案和用例草案发起最后征询，拟将两份文件作为资料性RFC审议，意见截止10月7日；这不是通过或实施通知。
  • 架构允许网络内部状态对外不透明。来源网关签署“资产已锁定”的声明，接收网关据此推进交接，却无法直接读取封闭的来源账本。
  • 草案把当事人同意、网关所有者身份、签名责任和转移期间的资产控制视为前提；签名记录有助于争议复核，但不能自行证明隐藏状态或法律所有权。

先有锁定，后有交接。SATP架构草案中，来源网关将资产在原网络中暂时固定，再向另一端发送签名声明。倘若原网络是私有系统，接收网关看不到内部账本，只能根据这份声明继续协商。密码学能够保存声明出自何人、是否被改动，却不能替接收方亲眼核对账本。

这不是草案遗漏的技术细节，而是其设计取舍。文件允许两个网络各自保留内部结构；为了跨网转移，网关须在两套系统之间建立可核验的消息链。草案又明确假设，启动协议以前，资产、发起人、受益人及同意均已得到确认；网关所有者身份已经核实。运营者被假定要为签署的消息以及资产处于网关控制期间承担相关责任。文章所说的责任是草案前提，不等于已有某项法律裁定。

协议过程也并非“一枚代币飞过桥”。发送端声明锁定，接收端回执，随后双方协调原资产的消灭和目标网络中等价资产的生成。连续签名的消息可供有权限的第三方在争议时检查。若原账本数据本来就不可靠，完整的消息链仍可能忠实保存一个错误陈述。这是证据真实性与基础事实真实性之间的差别。

9月23日，互联网工程指导委员会把架构第10版及用例第10版送入最后征询，均拟为资料性RFC；10月7日是提交实质意见的期限。核心协议另有草案，目标是拟议标准，不能把两份资料性文件的征询当作整个SATP已经获批。用例文档描绘贸易、金融和供应链等场景，也不是运营部署清单。

SATP工作组章程划出更关键的一条线：采用协议的网络可能需要先达成法律或其他协议，而协议框架及其落实证明不属SATP范围。借用卢恒对“证据”和“权威”的区分，网关记录可以送交裁决，却不会自己创造裁决权或资产权属。此次征询值得追问的，正是消息之外由谁承接这些责任。

Sources