Кратко

  • 25 сентября IESG объявила Last Call по 17-й редакции SATP Core для возможного статуса Proposed Standard. Замечания принимаются до 9 октября; RFC ещё не утверждён.
  • В разделе 11.5 сказано, что действенность отмены зависит от стадии передачи. После отправки commit-final отмена уже не меняет результат; при сбое шлюза сообщение об остановке может вообще не дойти до второй стороны.
  • В текущей версии протокола не поддерживаются восстановление и возобновление сессии. Это не исключает внешние процедуры урегулирования, но не позволяет приписать их самому проекту стандарта.

В описании межсетевого перевода легко увидеть одну операцию там, где протокол фиксирует несколько разных состояний. Пока актив заблокирован в сети отправителя, варианты отката одни; после подготовки назначения и окончательного подтверждения — другие. Именно поэтому финальное обсуждение ядра SATP представляет отдельную новость. Более ранние Last Call по архитектуре и сценариям применения относятся к документам информационного характера. Предыдущая публикация BTW разобрала ответственность шлюзов при закрытых реестрах.

Теперь на рассмотрении последовательность сообщений, претендующая на статус Proposed Standard, и её собственная точка невозврата.

Протокол связывает два шлюза, представляющих разные сети цифровых активов. Для согласования единственного действующего состояния он использует защищённый канал и двухфазное подтверждение. Сначала шлюз отправителя блокирует актив в исходной сети и подписывает соответствующее утверждение. Получатель подготавливает актив под своим контролем и сообщает о готовности. Затем отправитель уничтожает исходное представление и направляет commit-final; получатель назначает новое представление бенефициару и присылает итоговую квитанцию. Эти этапы нельзя без потерь заменить словом «атомарно»: для эксплуатации важен каждый промежуточный факт.

Раздел 11.5 проекта проводит практическую границу. До сообщения о готовности получателя в нём описана возможность снять блокировку у отправителя либо отменить локальные изменения на принимающей стороне. Одновременно авторы предупреждают: сообщение об отмене может не попасть к партнёру, например при аварии шлюза. После того как отправитель передал commit-final, отмена, согласно тексту, уже неэффективна. Из этого не следует, что конкретная внедрённая система понесла убыток или что любая неисправность неизбежно уничтожает актив. Но наличие типа сообщения abort само по себе не обещает откат в любой момент.

Есть и другой предел, который не виден на схеме успешного обмена. Раздел 10.8 прямо исключает восстановление и возобновление сессии из нынешнего SATP, оставляя тему будущей версии либо отдельной спецификации. У операторов могут существовать журналы, договоры и ручные процедуры сверки. Их пригодность нужно оценивать отдельно: нынешний текст ядра не задаёт стандартный способ продолжить оборванный сеанс. Отправить подписанное сообщение и доказать, что другая сторона успела изменить состояние, — разные задачи.

В разделе о безопасности рассматриваются атаки на доступность, умышленная задержка или удержание сообщений в важных точках, а также возможные расходы и финансовые потери шлюзов. Это перечень рисков, а не сообщение о состоявшемся инциденте. Устав рабочей группы предполагает, что сетям, вероятно, понадобятся юридические и иные договорённости, однако их реализация лежит вне SATP. Криптографическая подпись помогает установить автора заявления; она не распределяет сама по себе последствия спорной передачи.

Срок 9 октября относится к замечаниям, а не к внедрению или принятию RFC. Обсуждение должно показать, насколько чётко проект отделяет обратимые шаги от необратимых и как участники узнают состояние при молчании партнёра. Только после этого можно честно описывать, какие гарантии даёт реализация, а какие зависят от решений вне протокола.

Источники