Cofres de colateral BTC: como um agente posta Bitcoin nativo sem custódia

A maioria das histórias sobre "Bitcoin em DeFi" passa silenciosamente por um custodiante ou uma representação embrulhada. Você envia BTC para algum lugar, alguém (ou algum multisig de ponte) o mantém, e você recebe um IOU em outra cadeia. Isso funciona até que a coisa que está segurando seu BTC seja a coisa que falha. Para um agente autônomo que precisa postar colateral contra uma obrigação que não pode supervisionar, "confie no custodiante" é exatamente a suposição que estamos tentando eliminar.

Este post é sobre a alternativa: um cofre de colateral BTC onde o Bitcoin nativo garante uma obrigação em outra cadeia, a liberação é controlada por um hashlock, e o pior cenário é um reembolso — não uma perda. É um dos primitivos por trás da camada de liquidação do Hashlock. Vou explicar a ordenação de timelock que a torna segura, o script do Bitcoin que a impõe e os modos de falha que você deve projetar ao redor. Status honesto desde o início: isso é validado por signet, não pela mainnet BTC.

O problema em uma frase

Um agente quer comprometer BTC como colateral apoiando uma ação na Ethereum — liquidando um forward, ancorando um lado de uma negociação de múltiplos lados, garantindo um pagamento — de tal forma que o BTC seja liberado para a contraparte apenas se a obrigação correspondente na Ethereum for cumprida, e retorna ao seu proprietário se não for. Nenhuma terceira parte deve ser capaz de segurar, congelar ou se apropriar do BTC no meio do caminho.

Isso é uma condição condicional entre cadeias. O Bitcoin não pode ler o estado da Ethereum, e a Ethereum não pode ler o do Bitcoin. A única coisa que ambas as cadeias podem verificar independentemente é uma pré-imagem de hash. Portanto, toda a construção depende de um segredo compartilhado.

O segredo compartilhado, e por que a ordem do timelock é todo o jogo

Ambos os lados bloqueiam para o mesmo hash H = SHA256(s). Quem souber a pré-imagem s pode reivindicar. No instante em que s é revelado em uma cadeia para reivindicar uma moeda, é público, e a outra parte o copia para reivindicar a outra moeda. Essa é a parte atômica: uma pré-imagem desbloqueia ambos os lados ou nenhum.

O perigo não é o hash. É tempo. Se ambos os lados tivessem a mesma expiração, a parte que conhece o segredo poderia esperar até o último bloco, reivindicar o ativo da contraparte e deixar a contraparte sem tempo para reivindicar de volta. A solução é timelocks assimétricos, e acertar a direção é a decisão mais importante em todo o design.

Regra: a parte que conhece o segredo assume o timelock mais longo.

Vamos analisar com Alice postando colateral BTC e Bob bloqueando ETH:

1. Alice escolhe o segredo s, calcula H. Ela financia a saída do cofre BTC, que pode ser gasto por Bob se ele apresentar s, reembolsável para Alice após T_A = 48h.
2. Bob, vendo o cofre BTC na cadeia bloqueado para H, financia o HTLC do lado ETH, que pode ser reivindicado por Alice se ela apresentar s, reembolsável para Bob após T_B = 24h. Note que T_B < T_A.
3. Alice reivindica o ETH revelando s na Ethereum — ela deve fazer isso antes do limite de 24h.
4. No momento em que a reivindicação de Alice é registrada, s está em uma transação pública da Ethereum. Bob lê e usa para reivindicar o BTC, com a janela total de até 48h para que sua transação seja minerada.

Se Alice nunca revelar, ambos os lados reembolsam: Bob após 24h, Alice após 48h. Ninguém fica preso. A lacuna de 24h existe precisamente para que Bob sempre tenha margem para reagir após Alice forçar a revelação. Inverter os timelocks e você dá ao detentor do segredo uma opção gratuita — eles reivindicam seu ativo e deixam o seu expirar. Este é o clássico argumento de segurança do swap atômico, e um cofre de colateral é o mesmo argumento com o lado BTC mantido aberto por mais tempo como margem postada em vez de trocado instantaneamente.

Como é realmente o lado do Bitcoin

O Bitcoin não tem uma VM de contrato inteligente, mas não precisa de uma aqui. Um HTLC é expressável diretamente em Script. A condição de resgate é um simples if/else: gastar revelando a pré-imagem e uma assinatura do reclamante, ou gastar após um tempo de bloqueio absoluto com uma assinatura do reembolsador.

OP_IF
    OP_SHA256 <H> OP_EQUALVERIFY
    <Bob_pubkey> OP_CHECKSIG
OP_ELSE
    <T_A> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <Alice_pubkey> OP_CHECKSIG
OP_ENDIF

A ramificação de reembolso usa OP_CHECKLOCKTIMEVERIFY (CLTV, BIP-65) para um bloqueio absoluto de altura de bloco/tempo; você pode usar OP_CHECKSEQUENCEVERIFY (CSV, BIP-112) em vez disso se quiser que o timelock conte a partir do momento em que o cofre foi financiado em vez de a partir de um ponto fixo no relógio. A ramificação de reivindicação requer s tal que SHA256(s) == H, além da assinatura de Bob para que um observador que apenas vê s não possa redirecionar os fundos para si mesmo.

Duass notas de implementação que importam na prática:

• Envolva em P2WSH, ou melhor, uma saída Taproot (P2TR). Com Taproot, você coloca o caminho de reembolso em uma tapleaf e o caminho cooperativo como a chave de gasto, então um cofre que fecha felizmente parece um gasto de assinatura única comum na cadeia — menor, mais barato e mais privado. O script HTLC só aparece se você optar pelo caminho do script.
• A transação de reembolso deve permanecer minerável. Você pré-assina o reembolso com uma taxa que ainda é credível na expiração, ou mantém saídas CPFP/âncora disponíveis, porque um reembolso que você não consegue colocar em um bloco não é um reembolso. No Bitcoin, você não pode assumir que simplesmente "aumentará depois" dentro de uma janela de timelock apertada.

Por que "cofre", não "swap"

Um swap atômico simples revela o segredo quase imediatamente — ambos os lados querem fechar rapidamente. Um cofre de colateral deliberadamente mantém o lado BTC aberto como apoio para uma obrigação de vida mais longa: um forward que liquida na próxima semana, uma posição de múltiplos lados onde o lado BTC deve ser liquidado em sincronia com outros dois, uma garantia de pagamento que um agente posta antes de realizar o trabalho. O hashlock ainda é a condição de liberação; o timelock agora é dimensionado para a duração da obrigação, não para algumas confirmações.

A propriedade que um agente realmente se importa: a cada instante, o BTC está exatamente em um dos três estados — bloqueado (apoiando uma obrigação ativa), liberado (a obrigação foi cumprida, pré-imagem revelada) ou reembolsado (expirou, BTC de volta para casa). Não há um quarto estado onde alguém está "segurando para você." Essa é a diferença entre isso e um cofre custodiado, e é toda a proposta.

Modos de falha que você deve projetar

Isso é infraestrutura, então a parte interessante é o que dá errado:

• Corrida de revelação e espera. Alice revela na Ethereum no limite de 23h59m esperando que a reivindicação de BTC de Bob não confirme antes que sua taxa esteja muito antiga. A lacuna de 24h/48h é o orçamento para isso; deve ser dimensionada contra condições realistas do mempool do Bitcoin, não otimistas.
• Granularidade do tempo de bloco. Os blocos de ~10 minutos do Bitcoin significam que um timelock de "24h" é realmente "≈144 blocos ± variação." Suas margens de segurança devem absorver essa variação, especialmente perto das fronteiras de época de dificuldade.
• Picos de taxa. Uma transação de reembolso ou reivindicação precificada no momento do financiamento pode se tornar não minerável em um pico de congestionamento. Reembolsos pré-assinados com saídas âncora (CPFP) são a mitigação padrão.
• Reorganizações de cadeia no lado curto. Você espera por confirmações suficientes na revelação antes de tratar o segredo como final; uma reorganização rasa que desminera a revelação não deve deixar o lado longo preso.

Nenhum desses problemas é exótico — são os perigos bem conhecidos dos HTLCs entre cadeias. O objetivo de construir uma vez, corretamente, por trás de uma ferramenta MCP: um a