Operação de Canais e Encaminhamento
HTLCs: como o dinheiro se move por um canal — e por vários
-
Eric de Castro - Atualizado em
⚡ Lightning · Técnico
Na página de canais a fundo, os HTLCs apareceram como "saídas extras" na transação de compromisso. Agora vamos abrir essa caixa: o que é um HTLC, como ele torna um pagamento atômico e como vários HTLCs encadeados movem dinheiro através de uma rede de desconhecidos.
O que é um HTLC
HTLC é Hash Time-Locked Contract — um contrato com cadeado de hash e prazo. Na prática, é uma saída que pode ser gasta de dois jeitos:
- Caminho do hash (resgate). Quem revelar o segredo (o preimage) que corresponde a um payment_hash pega o dinheiro.
- Caminho do tempo (reembolso). Se o segredo não aparecer até um prazo (um OP_CHECKLOCKTIMEVERIFY, em altura de bloco), o pagador pode pegar o dinheiro de volta.
É exatamente o "cadeado com segredo" da explicação para iniciantes — só que agora com nome e forma. O recebedor sorteia um segredo aleatório r, calcula payment_hash = SHA256(r) e coloca o hash na invoice. O pagamento se completa quando r é revelado.
Experimente o cadeado de hash: sorteie um segredo, veja o cadeado (hash) que vai na invoice, e tente "resgatar":
Cadeado do HTLC
HTLC oferecido vs. recebido
Quando um HTLC está "em voo", ele vira uma saída na transação de compromisso dos dois lados — mas com papéis trocados:
- HTLC oferecido (na visão de quem envia): "pago a quem mostrar o segredo; senão, recupero após o timeout".
- HTLC recebido (na visão de quem recebe): "recebo se mostrar o segredo a tempo; senão, o valor volta para o outro lado".
Cada uma dessas saídas tem suas próprias transações de resgate (HTLC-success, com o preimage) e de expiração (HTLC-timeout), e elas também respeitam o to_self_delay e a revogação do canal — afinal, um HTLC também faz parte de um estado que pode ser revogado.
Encaminhando por vários canais
Aqui está o pulo do gato da rede. Digamos que a Alice quer pagar a Carol, mas só tem canal com o Bob, e o Bob tem canal com a Carol. A Carol gera uma invoice com um payment_hash. Então:
- A Alice cria um HTLC para o Bob com aquele
payment_hash. - O Bob cria um HTLC para a Carol com o mesmo
payment_hash. - A Carol revela o segredo para resgatar o HTLC do Bob. Agora o Bob conhece o segredo.
- O Bob usa o segredo para resgatar o HTLC da Alice.
O segredo propaga de volta, da ponta para a origem, liquidando cada HTLC no caminho. Como é o mesmo hash em todos os saltos, ou o pagamento chega ao fim e todos liquidam, ou ninguém liquida — é a tal atomicidade. E o Bob, por repassar, fica com uma taxa (a diferença entre o que entrou e o que saiu do HTLC dele).
Os prazos diminuem em direção ao destino
Tem um detalhe de segurança importante: os timeouts dos HTLCs não são iguais. O HTLC mais perto da origem precisa expirar depois do que está mais perto do destino. Assim, se o HTLC da ponta (Bob→Carol) expira, o Bob ainda tem uma folga para reagir no HTLC de entrada (Alice→Bob) antes que ele expire também.
Essa folga que cada nó exige é o cltv_expiry_delta. Por isso, ao montar a rota, o prazo (em altura de bloco) decresce a cada salto da origem até o destino. (Vamos calcular isso na página de busca de caminho.)
A "dança" do compromisso
Adicionar (ou remover) um HTLC não é instantâneo: os dois lados precisam concordar com o novo estado e revogar o anterior. Pela BOLT 2, a troca de mensagens é mais ou menos esta:
update_add_htlc— "quero adicionar este HTLC".commitment_signed— "aqui está a minha assinatura para a nova transação de compromisso".revoke_and_ack— "ok, e aqui está o segredo que revoga o meu estado anterior".
Isso acontece nos dois sentidos até os dois lados estarem comprometidos com o mesmo estado novo. Para liquidar um HTLC, há o update_fulfill_htlc (com o preimage) ou o update_fail_htlc (se algo deu errado).
Repare que até aqui o Bob sabe que está repassando da Alice para a Carol. Quem esconde o caminho completo (para o Bob não saber que a Alice é a origem nem que a Carol é o destino) é o roteamento onion — a próxima página.