Resumo

  • Antes de Commit-Final, a origem pode liberar o bloqueio e o destino pode desfazer sua cunhagem provisória; depois que o emissor queima o ativo, a revisão 17 considera o aborto ineficaz.
  • O Core atual não oferece recuperação nem retomada de sessão. A arquitetura exige logs e checkpoints, mas deixa sem padrão comum a semântica e o ponto de reinício.
  • A operação precisa de um livro do ponto sem retorno que separe intenção local, envio, recebimento, alegação do gateway e estado observado em cada rede opaca.

Imagine a desconexão no pior intervalo. O gateway remetente envia Commit-Final, afirmando que extinguiu o ativo na rede de origem. A confirmação final do destino não chega. O operador dispara abort. O comando pode estar assinado e vinculado à sessão correta; ainda assim, não ressuscita o estado anterior.

A seção 11.5 do SATP Core revisão 17 define esse limite. Até Commit-Final, o bloqueio de origem pode ser liberado ou a cunhagem que o destino atribuiu a si mesmo pode ser revertida. Depois, o ativo original já foi queimado e o destino já se comprometeu a entregar o equivalente ao beneficiário.

O documento entrou em Last Call da IETF em 25 de setembro de 2026, com prazo em 9 de outubro. O histórico no Datatracker registra um Internet-Draft candidato a Proposed Standard, não um RFC, uma implantação ou uma transferência observada.

SATP conecta dois gateways diante de redes que permanecem caixas-pretas uma para a outra. A arquitetura SAT deseja atomicidade, consistência, isolamento e durabilidade, mas reconhece que interoperabilidade de mensagens não basta. Os sistemas subjacentes precisam executar as mudanças em conjunto.

O estágio 1 registra proposta, recibo, início e confirmação. Assinaturas e hashes demonstram a sequência aceita, não movimentação do ativo. No estágio 2, a origem afirma que bloqueou ou colocou o ativo em custódia. O formato dessa alegação depende da rede e está fora do Core. O recibo do destino aceita a alegação; não observa diretamente o livro de origem.

O estágio 3 termina antes de lockAssertionExpiration. Commit-Ready afirma que o destino cunhou um equivalente, atribuiu-o provisoriamente a si e está pronto. Commit-Final afirma a queima na origem. ACK-Final afirma a atribuição ao beneficiário. Transfer-Complete fecha a sessão. Um painel que resume tudo como “confirmado” perde a posição exata da falha.

Abort também é uma sequência: decisão, envio, recepção e restauração comprovada. O texto avisa que a mensagem pode se perder e que o par pode cair antes de recebê-la. Registrar apenas o envio é registrar intenção, não rollback.

A seção 10.8 diz que a versão atual não suporta recuperação ou retomada. A arquitetura exige eventos e checkpoints e imagina um gateway substituto continuando a sessão, porém deixa formato, semântica e ponto de reinício para trabalho futuro e estratégia local. RFC 5424 ajuda a transportar logs; não torna uma queima repetida idempotente.

TLS 1.3, JWS e Problem Details protegem canal, autoria e erro. Não verificam sozinhos bloqueio, queima, cunhagem e atribuição nos dois sistemas. Os casos de uso SAT citam conhecimentos de embarque e cartas de crédito como contexto, sem provar adoção.

O livro operacional deve unir sessionId, transferContextId, assinaturas e hashes anteriores às provas locais de lock e burn, às provas de mint e assignment, ao vencimento, aos horários, às identidades dos gateways, à finalidade de cada rede, à geração de reinício e ao último estágio corroborado por ambos.

A primazia do código em execução de Heng Lu coloca o estado real acima do rótulo da mensagem. A especificação inicial mínima preserva um contrato comum estreito; as camadas de realidade impedem que o símbolo assinado seja confundido com o efeito material.

Fontes