摘要

  • SATP Core 第 17 版规定：在 Commit-Final 之前，源端仍可解锁资产，目的端也可撤销临时铸造；源资产销毁之后，abort 已不再有效。
  • 当前 Core 不支持会话恢复或续传。配套架构要求事件日志和检查点，却把共同语义及重启位置留给未来工作和本地实现。
  • 运营控制必须建立“不可逆时点账本”，把本地意图、消息发送、对端接收、网关声明和两个不透明网络中的实测状态分别留证。

最危险的不是一条错误消息，而是一条正确但已经太迟的消息。

发送方网关发出 Commit-Final，声明源网络中的资产已经销毁。连接随后中断，最终确认没有回来。值班人员点击终止。签名、会话号和收件地址都可以正确，但原来的资产已经没有可供“回滚”的状态。

SATP Core 第 17 版第 11.5 节直接写明：Commit-Final 之后发送的 abort 无效。原因是 G1 已在 NW1 销毁资产，G2 已在 NW2 铸造资产，并承诺把它分配给受益人。指令的名字没有改变它抵达时的现实。

这是一项正在审议的新闻，而不是既成标准。IESG 于 2026 年 9 月 25 日启动 IETF Last Call，意见截止 10 月 9 日。Datatracker 历史显示它仍是拟进入 Proposed Standard 的 Internet-Draft，不是 RFC，也不能证明任何机构已部署。

SATP 的两端各自代表一个资产网络，网络内部对另一端保持不透明。SAT 互操作架构希望转移满足原子性、一致性、隔离性与持久性，同时提醒：通信互操作只能传递意图和状态声明，不能单独保证底层系统真的协同改写了状态。

第一阶段先确定提案、回执、开始指令和开始确认。签名与前序哈希能证明哪一个网关认可了哪一串字节，却不能证明资产已经移动。第二阶段由源端发送锁定声明，称资产已被锁住或托管，以避免重复处置。声明格式依赖具体网络，不在 Core 范围内；目的端的接收回执确认的是这份声明，并没有因此获得观察源账本的能力。

第三阶段接近不可逆边界，而且必须在 lockAssertionExpiration 之前完成。Commit-Ready 表示目的端已铸造等价资产、先分配给自身并准备继续。在这之前，源端还能解锁，目的端还能撤销自己的临时状态。随后，Commit-Final 携带源端签署的销毁声明；ACK-Final 声明目的端已把新资产分配给受益人；最后 Transfer-Complete 才关闭会话。

这四步不能压缩成一个“已提交”状态。Commit-Ready 不是受益人已经取得控制，Commit-Final 不是目的端确认，ACK-Final 也不是发送方已经完成收尾。连接恰好在其中两步之间断开时，被删掉的差异就是调查最需要的证据。

abort 本身也有四个事实层：本地决定终止、消息已经发出、对端确实收到、资产状态已经恢复。草案明确提醒 abort 可能丢失，对端也可能在接收前崩溃。因此“已发送 abort”只是一张控制面回执，不是回滚证明。

当前版本的恢复缺口让这一点更加关键。Core 第 10.8 节明确不支持会话恢复与续传。架构则要求实现为崩溃恢复保存事件日志和检查点，并设想备用网关继续未完成的转移；但它又把日志格式、共同语义和重新开始的位置留给未来及各实现。RFC 5424能提供日志基础，却没有定义重复一次 SATP burn 是否安全。

RFC 8446规定的 TLS 1.3 保护通道，RFC 7515的 JWS 绑定消息与密钥，RFC 9457规范错误对象。它们都很重要，但都不会自动观察两个黑箱网络内的锁定、销毁、铸造与分配。签名证明网关说过什么，不等于声明已在底层实现。

SAT 用例提到提单、信用证等可在贸易与金融网络之间移动的数字资产。这些是设计背景，不是采用证据。恰恰因为对象可能代表权利，协议回执、网络终局性和法律权限更不能被混成一个成功标记。

一份可用的不可逆时点账本，应把 sessionId、transferContextId、每条签名消息及其前序哈希，与源端锁定和销毁证据、目的端铸造和分配证据、锁定到期时间、收发时间、网关身份、各网络终局性、崩溃代次、abort 收发情况及双方最后共同确认的阶段绑定起来。

Lu Heng 的运行代码优先提供了判断顺序：运行系统决定状态是否变化，协调消息不能借用它没有观察到的权威。最小初始规范支持狭窄的共同协议，把网络内部执行留在本地；现实层级则阻止一个签名符号冒充它所命名的现实。

来源