Кратко

  • До Commit-Final источник может снять блокировку, а получатель — отменить предварительный выпуск; после burn исходного актива версия 17 называет abort неэффективным.
  • Текущий Core не поддерживает восстановление и продолжение сессии. Архитектура требует журналы и контрольные точки, но оставляет их общую семантику и точку перезапуска будущей работе.
  • Нужен журнал точки невозврата, который различает локальное решение, отправку, приём, заявление шлюза и наблюдаемое состояние в каждой закрытой сети.

Сбой происходит в самом неприятном промежутке. Шлюз-отправитель передал Commit-Final, заявив об уничтожении актива. Соединение исчезло до финального подтверждения назначения. Оператор посылает abort. Сообщение может быть безупречным, но состояние, которое оно должно вернуть, уже уничтожено.

Раздел 11.5 SATP Core версии 17 прямо говорит: abort после Commit-Final неэффективен. Раньше источник способен снять lock, а получатель — обратить временный mint. Позже актив в NW1 уже сожжён, а в NW2 создан эквивалент и принято обязательство назначить его бенефициару.

25 сентября 2026 года документ вышел на IETF Last Call до 9 октября. История Datatracker подтверждает Internet-Draft, рассматриваемый как будущий Proposed Standard, а не RFC, внедрение или состоявшийся перевод.

SATP связывает два шлюза перед сетями, внутреннее состояние которых скрыто друг от друга. Архитектура SAT требует атомарности, согласованности, изоляции и долговечности, но подчёркивает: совместимость сообщений сама по себе их не обеспечивает. Системы должны действительно согласованно изменить состояние.

На стадии 1 proposal, receipt, commence и ACK закрепляют параметры. Подписи и хэши доказывают согласованную последовательность байтов, но не перемещение актива. На стадии 2 источник заявляет о блокировке или эскроу. Формат зависит от сети и находится вне Core; квитанция получателя принимает заявление, не превращая его в наблюдателя исходного реестра.

Стадия 3 должна завершиться до lockAssertionExpiration. Commit-Ready утверждает, что получатель выпустил эквивалент, временно назначил его себе и готов продолжать. Commit-Final утверждает burn в источнике. ACK-Final утверждает назначение бенефициару. Transfer-Complete закрывает сессию. Это разные доказательства, а не одно состояние «commit».

У abort тоже несколько фактов: локальное решение, передача, получение другой стороной и подтверждённое восстановление. Проект предупреждает, что сообщение может потеряться, а шлюз — упасть до приёма. Запись «отправлено» доказывает намерение, но не откат.

Раздел 10.8 не поддерживает recovery или resumption в текущей версии. Архитектура обязывает хранить события и checkpoints и допускает продолжение резервным шлюзом, но откладывает общий формат и смысл, а точку рестарта оставляет реализации. RFC 5424 задаёт Syslog, но не делает повторный burn безопасным.

TLS 1.3, JWS и Problem Details защищают канал, авторство и форму ошибки. Они не наблюдают автоматически lock, burn, mint и assignment в двух чёрных ящиках. Сценарии SAT упоминают коносаменты и аккредитивы как контекст, но не доказывают внедрение.

Рабочий журнал связывает sessionId, transferContextId, подписи и предыдущие хэши с доказательствами lock и burn, mint и assignment, сроком блокировки, временами передачи и приёма, идентичностями шлюзов, финальностью сетей, поколением перезапуска и последней стадией, подтверждённой обеими сторонами.

Приоритет работающего кода Lu Heng ставит исполняемое состояние выше ярлыка сообщения. Минимальная начальная спецификация сохраняет узкий общий контракт, а слои реальности не позволяют подписанному символу присвоить эффект, которого он не наблюдал.

Источники