Canais de Pagamento (a fundo)
Financiamento, transação de compromisso, revogação e fechamento
-
Eric de Castro - Atualizado em
⚡ Lightning · Técnico
Na versão para iniciantes falamos do canal como uma "comanda". Aqui vamos ver o que acontece no nível das transações Bitcoin: como o canal é ancorado on-chain, como o saldo é representado e atualizado, e por que a trapaça não compensa.
A transação de financiamento (funding)
Abrir um canal é criar uma saída multisig 2-de-2 na blockchain — normalmente uma P2WSH cujo script é:
OP_2 <pubkey_alice> <pubkey_bob> OP_2 OP_CHECKMULTISIGEssa saída é a transação de financiamento. O valor depositado nela é a capacidade do canal, e ninguém consegue mexer nesse dinheiro sem a assinatura dos dois. O par txid:índice_da_saída dessa saída identifica o canal para sempre — é o channel point.
Tradicionalmente só um lado financia o canal (single-funded), mas há também o financiamento por ambos (dual funding). De qualquer forma, é uma única transação on-chain que dá origem ao canal.
A transação de compromisso (commitment)
O saldo atual do canal é representado por uma transação de compromisso: uma transação que gasta a saída de financiamento e divide o dinheiro entre os dois. Ela não é publicada enquanto o canal está aberto — é a carta na manga de cada lado para fechar o canal a qualquer momento no estado atual.
O detalhe crucial: cada lado guarda a sua própria versão, e elas são assimétricas. A versão da Alice tem estas saídas:
to_remote→ paga o Bob imediatamente (o saldo dele).to_local→ paga a Alice, mas com um atraso (to_self_delay, um timelock relativo via OP_CHECKSEQUENCEVERIFY) e de um jeito que pode ser revogado.- uma saída para cada HTLC pendente (veremos os HTLCs na próxima página).
Na versão do Bob é o espelho: o to_local dele é que fica atrasado e revogável. Em outras palavras: quem publica a transação de compromisso é quem espera — o seu próprio dinheiro fica preso pelo to_self_delay, enquanto o do outro lado sai na hora.
Brinque com um estado de canal e veja as saídas que cada lado enxerga:
Transação de Compromisso
Revogação e penalidade
Toda vez que o saldo muda, os dois criam uma nova transação de compromisso e invalidam a antiga. Mas como "invalidar" uma transação que já está assinada e seria válida na blockchain?
A resposta é a revogação. A saída to_local não pode ser gasta só pelo dono — ela tem dois caminhos:
- pelo dono, mas só depois do
to_self_delay; ou - por quem tiver a chave de revogação daquele estado, imediatamente.
A cada atualização, cada lado entrega ao outro o segredo de revogação do estado anterior. Com esse segredo, a chave de revogação do estado antigo passa a ser derivável pela contraparte. Resultado: se a Alice tentar publicar um estado antigo (revogado) — por exemplo, um em que ela tinha mais saldo — o Bob tem a janela do to_self_delay para usar a chave de revogação e varrer todo o to_local dela. Somando ao to_remote que já é dele, o Bob fica com o canal inteiro.
Por isso trapacear é irracional: a punição é perder tudo. Esse mecanismo é o que permite que dois desconhecidos mantenham um canal sem confiar um no outro.
Fechando o canal
Há três jeitos de um canal terminar:
- Fechamento cooperativo (mutual close). Os dois concordam e assinam juntos uma transação de fechamento simples, que paga cada um na hora — sem timelock e com taxa baixa. É o caminho feliz.
- Fechamento forçado (force close). Se o outro lado sumiu ou não coopera, você publica a sua transação de compromisso mais recente. Funciona, mas o seu dinheiro fica preso pelo
to_self_delay(e a taxa é maior). - Quebra de contrato (breach). Publicar um estado revogado aciona a penalidade descrita acima — você perde tudo.
Detalhes que evoluíram
O desenho acima é o "clássico". Vale saber que o protocolo avançou:
- Anchor outputs. Saídas extras pequenas na transação de compromisso que permitem aumentar a taxa depois (CPFP), importante quando as taxas on-chain disparam num fechamento forçado.
- Canais Taproot (simple taproot channels). Uma evolução mais recente que usa Taproot e assinaturas MuSig2 para deixar os canais mais privados e baratos on-chain (o multisig 2-de-2 vira uma chave só, indistinguível de um gasto comum).
A seguir: como o dinheiro realmente se move por um canal e através de vários — os HTLCs e o encaminhamento de pagamentos.