Кратко

  • Last Call по SATP Core 17 идёт до 9 октября 2026 года; Architecture и Use Cases 10 рассматриваются до 7 октября и пока остаются черновиками.
  • Подписи и хэши предыдущих сообщений позволяют проверить последовательность утверждений вплоть до ACK-Final-Receipt.
  • Доказательства burn и mint зависят от конкретных сетей, а Core 17 не поддерживает восстановление сессии; общая семантика журналов отложена.

Необратимость начинается не с квитанции

SATP связывает отправляющий и принимающий шлюзы двух сетей активов. Core 17 описывает burn-and-mint и двухфазную фиксацию с целью ACID. Документ проходит Last Call как кандидат в Proposed Standard; два сопроводительных черновика нацелены на Informational. Это стадия проверки, а не подтверждение внедрения.

В Commit-Ready принимающий шлюз утверждает, что создал эквивалентный актив. В Commit-Final отправляющий шлюз подписывает утверждение об уничтожении исходного. В ACK-Final-Receipt принимающая сторона заявляет о назначении нового актива предполагаемому получателю. Все сообщения подписаны и связаны хэшем предыдущего сообщения.

Такой transcript показывает автора, порядок и контекст утверждений. Но подпись удостоверяет источник сообщения, а не независимо измеряет внешнее состояние. Architecture прямо оставляет механизмы и криптографические доказательства burn/mint каждой сети. Общий протокол разговора не становится универсальным доказательством состояния.

Разница особенно важна после Commit-Final. До уничтожения исходного актива abort можно обратить со сравнительно небольшими затратами. После сообщения он неэффективен: исходный актив уничтожен, целевой создан, а принимающий шлюз согласился выполнить назначение. Решение пересечь эту границу должно опираться и на протокольный transcript, и на записи систем, где произошли необратимые изменения.

Квитанция, состояние и контроль

Полный досье может состоять из трёх разных доказательств. SATP фиксирует утверждения шлюзов. Каждая сеть подтверждает своё состояние по собственным правилам финальности. Получатель отдельно демонстрирует возможность контролировать или использовать назначенный актив. ACK-Final-Receipt важен, но не подменяет последние две проверки.

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

Общего контракта восстановления пока нет

Architecture требует журналы событий и checkpoints. Резервный шлюз мог бы продолжить перенос, если журнал доступен и стандартизован, однако точка рестарта зависит от стратегии реализации. Семантика и синтаксис crash-management log названы будущей работой. Core 17 прямо исключает восстановление и возобновление сессии из текущей версии.

Конкретная реализация всё равно может надёжно восстанавливаться: реплицировать состояние, сохранять ключи и тестировать failover. Но один продукт пока не может только по общему протоколу прочитать checkpoint другого. TLS 1.3 защищает канал, JWT кодирует утверждение, Syslog может стать основой журнала; ни один из них сам не наблюдает обе сети и не выбирает безопасную точку рестарта.

Подход Heng Lu требует не смешивать доверие с механизмом, а записанное утверждение — с операционной истиной. Такая граница не ослабляет SATP: она позволяет использовать его квитанцию с точным смыслом.

Источники