Canais de Pagamento
A peça fundamental da Lightning
-
Eric de Castro - Atualizado em
Lightning Network
Um canal de pagamento é um acordo entre duas partes para atualizar saldos de bitcoin fora da blockchain, sem confiar uma na outra e sem publicar uma transação para cada pagamento.
Na página anterior, usamos a analogia da comanda. Agora vamos abrir essa ideia com mais cuidado: a comanda só funciona porque existe bitcoin preso em uma transação real, existem estados assinados que podem fechar o canal, e existe punição para quem tentar usar um estado antigo.
Conteúdo
O que é um canal
Um canal Lightning tem duas partes:
- Uma âncora on-chain: uma transação Bitcoin prende a capacidade do canal em uma saída controlada pelos dois participantes.
- Um estado off-chain: os participantes trocam assinaturas para atualizar quem tem direito a quanto desse valor.
Isso é diferente de uma conta em servidor. Não existe um banco de dados global da Lightning dizendo "Alice tem X e Bob tem Y". O que existe são transações Bitcoin possíveis, assinaturas e dados locais que cada participante precisa guardar corretamente.
Enquanto os dois cooperam, o canal parece simples: saldos mudam rápido. Se algo dá errado, a blockchain serve como tribunal final.
Descrição longa do diagrama
O diagrama mostra você e o Bar do Bob criando uma transação de financiamento. Essa transação leva bitcoin para uma saída que exige participação dos dois lados. A imagem representa essa saída como um cofre compartilhado. A partir desse cofre, os saldos do canal podem ser atualizados fora da blockchain.
Abrindo o canal
Para abrir um canal, uma carteira ou nó cria uma transação de financiamento, também chamada de funding transaction. Essa transação tem entradas, saídas, taxa e confirmação como qualquer outra transação Bitcoin.
A diferença é a saída especial que financia o canal. Em termos simples, ela funciona como um cofre compartilhado: nenhum lado deve conseguir gastar sozinho direto dali sem seguir as regras do canal.
Exemplo fictício:
| Item | Valor |
|---|---|
| Capacidade do canal | 100.000 sats |
| Saldo inicial seu | 100.000 sats |
| Saldo inicial do Bob | 0 sats |
| Transações on-chain até aqui | Uma: a funding transaction. |
Depois que a funding transaction confirma o suficiente, o canal fica pronto. A partir daí, vocês podem atualizar saldos sem criar uma transação on-chain para cada pagamento.
Abrir canal custa uma taxa on-chain e prende capital. Por isso Lightning é boa para muitos pagamentos pequenos ao longo do tempo, não para abrir e fechar canal a cada compra.
Capacidade, saldo e liquidez
Três palavras aparecem muito em Lightning:
| Conceito | Significado |
|---|---|
| Capacidade | Valor total preso no canal. Se o canal tem 100.000 sats, a soma dos saldos dos dois lados não passa disso. |
| Liquidez de saída | Quanto você consegue enviar naquele canal, antes de considerar reservas e limites. |
| Liquidez de entrada | Quanto você consegue receber por aquele canal. Para receber, o outro lado precisa ter saldo que possa mover para você. |
No exemplo inicial, você tem quase toda a liquidez de saída: pode pagar Bob. Mas você quase não tem liquidez de entrada nesse canal, porque Bob ainda não tem saldo do lado dele para mandar de volta.
Depois de você pagar 30.000 sats para Bob, o canal fica assim:
- Você: 70.000 sats.
- Bob: 30.000 sats.
- Capacidade total: continua 100.000 sats.
Agora você consegue enviar menos por esse canal, mas consegue receber até parte do saldo que foi para Bob. É por isso que "ter bitcoin na Lightning" não é só ter valor total: a direção da liquidez importa.
Pagando dentro do canal
Cada pagamento dentro do canal cria um novo estado. Esse estado diz como o dinheiro do canal seria dividido se ele fosse fechado naquele momento.
Descrição longa do diagrama
O diagrama mostra três versões de saldo em uma comanda. Primeiro todo o saldo está do seu lado. Depois de pagamentos, parte do saldo passa para Bob. Cada versão substitui a anterior como estado atual do canal. A blockchain não recebe uma transação para cada mudança; ela só será usada se o canal fechar ou precisar resolver uma disputa.
Em linguagem simples, o processo é:
- Os dois lados têm uma versão assinada que fecha o canal no estado atual.
- Um pagamento muda os saldos.
- Os dois trocam assinaturas para o novo estado.
- O estado antigo é revogado.
O ponto importante é a ordem: o canal só é seguro se os dois lados sabem qual estado é o mais novo e têm como punir uma tentativa de publicar estado antigo.
Na parte técnica, essas versões são chamadas de commitment transactions. Elas são transações Bitcoin que ainda não foram publicadas, mas que podem ser publicadas se o canal precisar fechar unilateralmente.
Estados antigos e punição
O risco óbvio é alguém tentar fechar o canal com uma versão antiga, mais favorável para si.
No exemplo:
- Estado antigo: você tinha 100.000 sats e Bob tinha 0.
- Estado atual: você tem 70.000 sats e Bob tem 30.000 sats.
- Se você publica o estado antigo, está tentando apagar o pagamento feito a Bob.
A Lightning desencoraja isso com revogação. Quando um estado novo substitui o anterior, o estado antigo vira perigoso para quem tentar usá-lo. Se você publicar uma versão revogada, Bob pode usar dados de revogação para reivindicar os fundos daquele estado antigo.
Descrição longa do diagrama
O diagrama mostra uma parte publicando uma commitment transaction antiga. A contraparte identifica que aquele estado foi revogado e usa uma chave de revogação para gastar a saída antes que o trapaceiro consiga usar o próprio saldo. A imagem destaca a janela de tempo disponível para reação.
Isso explica uma responsabilidade importante: em canais não-custodiais, alguém precisa observar a blockchain. Se sua carteira ou nó ficar offline por muito tempo e a contraparte publicar um estado antigo, você precisa detectar a tentativa dentro da janela de reação. Algumas carteiras simplificam isso, e nós próprios podem usar watchtowers, mas o problema existe.
Fechando o canal
Um canal pode terminar de formas diferentes:
| Fechamento | O que significa |
|---|---|
| Cooperativo | Os dois lados concordam em fechar e publicam uma transação de fechamento mais simples. Normalmente é o caminho mais limpo. |
| Unilateral | Um lado publica sua commitment transaction porque o outro sumiu, travou, discordou ou não cooperou. Pode envolver espera e taxas maiores. |
| Estado revogado | Um lado tenta fechar com estado antigo. A contraparte precisa reagir e usar a revogação. |
Quando o canal fecha, o resultado volta para a blockchain. A partir daí, o dinheiro deixa de estar em canal e volta a ser UTXO on-chain comum, sujeito a confirmações, taxas e regras normais do Bitcoin.
Se havia pagamentos em voo, o fechamento pode ser mais complexo, porque HTLCs precisam ser resolvidos por preimage ou timeout. Isso é assunto da próxima página, onde pagamentos roteados entram em cena.
Limites práticos
Canais de pagamento são a base da Lightning, mas trazem limites que a carteira tenta esconder:
- Capital fica preso. A capacidade do canal fica comprometida enquanto ele está aberto.
- Direção importa. Ter capacidade total não significa conseguir enviar ou receber qualquer valor.
- Taxas on-chain ainda existem. Abrir e fechar canal usa blockchain, então mempool e feerate continuam relevantes.
- Estado precisa ser preservado. Backup antigo de canal pode ser perigoso. A seed sozinha nem sempre recupera todo o estado Lightning.
- Fechamento unilateral pode demorar. O lado que publica sua própria commitment pode ter que esperar um atraso relativo antes de gastar certas saídas.
- Carteiras custodiais mudam o modelo. Se uma empresa controla os canais por você, você não está lidando diretamente com esses estados, mas também não controla plenamente os fundos.
Esses limites não tornam a Lightning ruim. Eles explicam por que ela é uma ferramenta específica: excelente para pagamentos rápidos e pequenos, menos adequada para guardar todo o patrimônio por longo prazo.
Resumo
- Um canal prende bitcoin em uma funding transaction on-chain.
- Pagamentos dentro do canal atualizam saldos fora da blockchain.
- Cada estado pode ser fechado por uma commitment transaction.
- Estados antigos são revogados para punir tentativa de trapaça.
- Fechamento cooperativo costuma ser mais simples; fechamento unilateral exige mais cuidado.
- Liquidez, direção do saldo, taxas on-chain e backups são parte real do uso da Lightning.
Mapa de dependências conceituais
Antes de ler esta página
Depois desta página
- Como a Lightning funciona
- Primeiros Passos
- Canais de Pagamento a fundo
- Operação de Canais e Encaminhamento
Referências técnicas
Esta página simplifica o protocolo. Para os detalhes normativos, veja:
- BOLT 2 — Peer Protocol for Channel Management
- BOLT 3 — Bitcoin Transaction and Script Formats
- BOLT 5 — Recommendations for On-chain Transaction Handling
- Canais de Pagamento a fundo
Até aqui falamos de um canal entre duas partes. O que transforma isso em uma rede é conseguir pagar alguém com quem você não tem canal direto, saltando por canais de outras pessoas. É o assunto da próxima página.