Uma negociação, muitas pernas, zero lacunas: como a atomicidade multi-perna realmente funciona

Ontem eu escrevi que ferrovias não são liquidação: um pagamento é uma perna - o agente paga um vendedor, um ativo, uma direção - e as ferrovias de pagamento do agente se tornaram muito boas nisso muito rapidamente. Este post é a outra metade desse argumento. Porque no momento em que seu agente para de pagar e começa a negociar, uma perna não é mais suficiente, e a diferença não é cosmética. É onde o dinheiro desaparece.

Isso é sobre um primitivo ao qual continuamos voltando: atomicidade de negociação multi-perna. Não é glamouroso e é o ponto principal.

Um pagamento tem uma perna. Uma negociação tem pelo menos duas.

Imagine a negociação real mais simples que seu agente pode fazer às 3 da manhã com uma contraparte que ele nunca conheceu: meu USDC pelo seu wETH. Isso não é uma transferência. São duas:

1. Perna A: meu USDC se move para você.
2. Perna B: seu wETH se move para mim.

Ambas devem acontecer, ou nenhuma deve. Não há um mundo aceitável onde a perna A é concluída e a perna B não - isso é apenas eu enviando dinheiro para você e esperando.

Agora torne isso realista. As negociações interessantes do agente não são de duas pernas. Elas são:

• Cross-asset, cross-chain: meu USDC em uma cadeia pelo seu ativo em outra. Agora você tem duas transferências em dois livros contábeis que não compartilham um relógio.
• Múltiplas partes: A quer o que B tem, B quer o que C tem, C quer o que A tem. Um ciclo de três vias que só faz sentido se todas as três pernas dispararem juntas.
• Empacotadas: "troque, depois poste os rendimentos como colateral, depois abra a posição" - uma sequência onde um preenchimento parcial deixa o agente em uma situação pior do que não negociar nada.

Cada uma dessas tem a mesma forma: N pernas que só estão corretas como um conjunto. O número de pernas aumenta; o requisito não muda. Todas elas liquidadas, ou todas elas reembolsadas.

A lacuna é o bug

A implementação ingênua é uma sequência. Eu envio, eu espero, você envia. Entre esses dois passos há uma janela onde uma parte atuou e a outra não. Essa janela é todo o problema. É onde:

• a contraparte simplesmente sai após receber a perna A;
• uma reorganização ou paralisação de cadeia e as pernas se desincronizam;
• um agente falha no meio da sequência e deixa uma negociação inacabada que ninguém possui.

A "solução" padrão que você vê sendo implementada nas pilhas de agentes é inserir um escrow: uma terceira parte mantém ambos os lados até que tudo esteja pronto, então libera. Leia isso com atenção. Isso não remove a lacuna. Ele reloca a lacuna para um custodiante. Agora a suposição de confiança é "este intermediário liberará corretamente e ainda está solvente e não está comprometido." Você transformou um problema de risco de contraparte em um problema de risco de custódia e chamou isso de liquidação. É orquestração vestindo as roupas da liquidação.

Atomicidade significa que não há lacuna para relocar. Não uma lacuna menor. Nenhuma lacuna.

Como a atomicidade multi-perna une as pernas

O mecanismo é um contrato de bloqueio de tempo hash (HTLC), estendido para que toda perna da negociação dependa do mesmo segredo.

Aqui está a ideia central em uma respiração: escolha um segredo aleatório s, calcule seu hash h = SHA256(s), e bloqueie cada perna da negociação sob a condição "reivindicável ao revelar a pré-imagem de h, reembolsável após o tempo limite T.

segredo s ; h = SHA256(s)

perna A:  bloquear(montante_A -> contraparte, desbloquear_se = pré-imagem(h), reembolsar_após = T_A)
perna B:  bloquear(montante_B -> eu,           desbloquear_se = pré-imagem(h), reembolsar_após = T_B)
...
perna N:  bloquear(montante_N -> ...,          desbloquear_se = pré-imagem(h), reembolsar_após = T_N)

Agora a negociação tem exatamente dois estados finais possíveis:

• O segredo é revelado. Revelar s para reivindicar qualquer uma das pernas publica s na cadeia. Uma vez que s é público, toda outra perna se torna reivindicável por todos que deviam uma. Uma revelação cascata em liquidação total. Toda a negociação é concluída.
• O segredo nunca é revelado. O tempo limite de cada perna passa e cada montante bloqueado é reembolsado ao seu proprietário original. Toda a negociação se desfaz. Ninguém fica meio liquidado.

Não há um terceiro estado. É isso que "atômico" deve significar: não "rápido," não "em um bloco," mas nenhum resultado parcial é alcançável. As pernas não são coordenadas por um árbitro; elas estão ligadas pelo fato de que todas dependem da mesma peça de informação se tornar pública.

A única parte que requer cuidado real é a ordenação do tempo limite. As janelas de reembolso devem ser escalonadas para que a parte que revela o segredo nunca possa ser a que fica exposta - a perna que você deve reivindicar por último deve ter a maior margem de segurança. Se você errar a ordenação, reintroduz uma lacuna pela porta dos fundos. Esta é a parte do design que vale a pena verificar formalmente, e é exatamente onde nossos caminhos de tempo limite/reembolso recebem mais atenção (Slither + Halmos + Echidna + Stryker + um monitor de invariantes em tempo de execução).

Por que uma ferrovia unidirecional estruturalmente não pode fazer isso

Este é o cerne da questão, e é uma declaração de arquitetura, não uma de marketing. Uma ferrovia de pagamento move valor em uma direção: do pagador para o recebedor. Seu modelo de dados é uma transferência. Para expressar uma negociação de dois lados em uma ferrovia unidirecional, você tem que adicionar uma segunda transferência e então coordenar as duas - e o único lugar para colocar essa coordenação é uma parte confiável que observa ambas e decide quando liberar.

O modelo de dados do HTLC é um bloqueio condicional, não uma transferência. A condicionalidade é nativa. Adicionar uma perna não adiciona um coordenador; adiciona outro bloqueio sob o mesmo hash. É por isso que a atomicidade multi-perna é algo que os primitivos de liquidação podem expressar e as ferrovias de pagamento só podem aproximar reintroduzindo confiança.

Ferrovias e liquidação são complementares - seu agente pode usar uma ferrovia de pagamento para pagar por uma chamada de API e uma camada de liquidação para trocar o ativo que ganhou. Mas elas são camadas diferentes, e apenas uma delas pode fazer N pernas serem liquidadas como um conjunto.

Onde isso é real hoje

Ser preciso sobre o status, porque precisão é a marca:

• Ethereum mainnet: ao vivo de ponta a ponta. Os contratos HTLC V1 estão implantados e imutáveis.
• Sui: contratos estão implantados e testados em CLI; a fiação do gateway está em andamento. Não ao vivo - eu não chamarei assim.
• Bitcoin: validado por signet, com mainnet pendente.

O servidor MCP expõe o primitivo para agentes como ferramentas (create_htlc, get_htlc, withdraw_htlc, refund_htlc, swap_quote, swap_execute), para que um agente componha uma negociação multi-perna da mesma forma que chama qualquer outra ferramenta - via hashlock-tech/mcp (escopo no npm). A mecânica mais profunda e a metodologia de volume vivem em hashlock.markets/methodology. A redação formal do modelo de liquidação está em SSRN.

A conclusão

Um pagamento é uma perna, e as ferrovias possuem essa perna. Uma negociação é várias pernas, e uma negociação só está correta quando cada perna é liquidada ou cada perna é reembolsada - sem estado alcançável entre e sem custódia segurando a bolsa no meio. A atomicidade multi-perna é o primitivo que torna isso verdadeiro, e é a propriedade que um agente autônomo precisa antes de você deixá-lo