摘要

  • IESG 于 9 月 25 日就 SATP Core 第 17 版启动最后征询，拟将其作为 Proposed Standard 审议；意见截止 10 月 9 日。它仍是草案，不是已获批准的 RFC。
  • 草案第 11.5 节说明，中止消息能否改变资产状态取决于发送时点；发送方发出 commit-final 后，中止不再有效。网关崩溃还可能使中止消息根本送不到对方。
  • 第 10.8 节明确说当前协议不支持会话恢复或续接；未来版本或独立规范可能再处理。这并不排除协议外的人工或合同安排，但不能把它们说成草案已有功能。

一笔转移看上去只发生一次，实际上有多个只有运营者才看得清的状态。来源网络先锁定资产，接收网络准备对应资产；只有随后的一系列确认与最终分配，才让两边完成交接。如果展示页面把全过程压成“成功／失败”两个词，最难处置的恰恰是消息停在中途时谁有权继续、谁能够撤回。9 月 25 日进入 IESG 最后征询的 SATP 核心协议第 17 版，使这个问题有了可以逐条核对的文字。

这次征询与两天前的 SATP 架构和用例文件并非同一轮批准。后两份文件以资料性 RFC 为目标，本站此前已讨论其不透明账本之间的网关保管与责任。本次核心草案拟走 Proposed Standard 路径，直接规定网关交换哪些消息、怎样锁定、准备、销毁和分配资产。新问题因此是协议本身的“不可逆边界”，而不是再讨论谁能看见另一方账本。

草案的流程图把转移分成初始化、锁定声明和最终承诺。发送网关先在来源网络锁定资产，并向接收网关发送签名声明。进入承诺阶段后，接收侧准备并铸造其控制下的资产，再发出就绪消息；发送侧随后销毁来源资产并发出 commit-final；接收侧再将目的资产分配给受益人并返回最终确认。这里不能简单地说“铸造一定发生在销毁之后”，也不能把所有承诺阶段都当作同样可撤销。不同消息对应不同的实际状态。

第 11.5 节说得比抽象的“原子转移”更具体。在接收方发出就绪消息之前，草案描述了来源侧解锁或目的侧撤回局部变更的路径。但它同时提醒，中止消息可能丢失，网关可能在收到之前崩溃。发送方发出 commit-final 后，再发出的中止不再有效。这不是某个生产事故的报道，也不是说任何故障都会让资产永久丢失；它划定了协议中止消息本身能够承诺的上限。

另外一处容易被忽略的是第 10.8 节：当前 SATP 协议并不支持恢复或续接已经中断的会话。作者把这留给未来版本或另一份规范。运营者仍可能依赖双方留存的记录、合同以及人工核对，但那些机制不属于本版核心文本，效果也不能由一张顺畅完成的流程图推定。测试时必须把“对端知道我发过什么”与“我确信对端已采取什么行动”分开。

安全章节列出拒绝服务、故意延迟或丢弃关键消息以及网关承担费用或财务损失的可能性；它没有报告已发生的具名事件。工作组章程也承认，参与网络之间可能需要法律等协议，而这些协议及其落实证明不在 SATP 范围之内。签名能帮助确认消息来自谁，却不能自动指定中断后由谁承担损失。

10 月 9 日是意见期限，不是上线或批准日期。审议者现在可以要求草案把每个可回退状态、最终承诺点和失联后的证据说清楚；准备采用的机构则应自行验证失败场景，而不只演示顺利完成的交易。所谓可信协调，首先要知道从哪一刻起“取消”已经不是安全答案。

来源