Como a Lightning funciona

Juntando canais, invoices, rotas e pagamentos

Lightning Network

Já vimos que a Lightning usa canais de pagamento para atualizar saldos fora da blockchain. Agora vamos juntar as peças: como um QR code vira uma tentativa de pagamento, como a carteira escolhe uma rota, como intermediários encaminham sem ficar com o dinheiro e por que pagamentos às vezes falham e tentam de novo.

Conteúdo

Visão geral

Um pagamento Lightning típico envolve cinco ideias:

  1. Invoice: o recebedor cria um pedido de pagamento com valor, descrição, expiração e um hash de pagamento.
  2. Rota: a carteira do pagador procura um caminho por canais que pareçam capazes de entregar o valor.
  3. HTLC: cada salto cria um pagamento condicional, travado por hash e por tempo.
  4. Onion: cada intermediário recebe apenas a instrução do próximo salto, não a rota inteira.
  5. Preimage: o recebedor revela o segredo que prova o recebimento e liquida os HTLCs de volta pelo caminho.

Para o usuário, isso aparece como "escanear QR code e confirmar". Para a carteira, é uma sequência de validações, tentativas de rota e atualizações de estado em canais.

Rede Lightning com canais entre vários nós; um pagamento sai de você e chega ao Bob passando por um intermediário.
A rede é formada por canais. O pagamento pode passar por canais de outras pessoas.
Descrição longa do diagrama

O diagrama mostra vários nós conectados por canais. Você está de um lado, Bob está em outro, e há nós intermediários entre os dois. Uma seta destaca uma rota escolhida para o pagamento, enquanto outras conexões mostram que existem caminhos alternativos possíveis.

1. O recebedor cria uma invoice

Na Lightning, normalmente quem vai receber cria uma invoice. Ela é um pedido de pagamento, geralmente mostrado como QR code.

A invoice pode conter:

Anatomia de uma invoice Lightning: QR code, valor, descrição, payment hash, expiração e assinatura do recebedor.
A invoice diz à carteira o que pagar e como reconhecer o pagamento correto.
Descrição longa do diagrama

O diagrama mostra uma invoice Lightning representada por um QR code e por campos ao redor. Os campos destacados incluem valor, descrição, hash do pagamento, validade, assinatura e dados que ajudam a carteira a chegar ao recebedor.

O recebedor não divulga o segredo final. Ele divulga o hash desse segredo. Isso permite montar um pagamento que só será completado quando o recebedor revelar a preimage correta.

2. A carteira procura um caminho

Depois de ler a invoice, sua carteira precisa encontrar um caminho pela rede. Ela pergunta, em termos práticos: "por quais canais esse valor pode chegar ao recebedor, pagando taxas aceitáveis e respeitando os prazos?"

Para isso, ela usa informações públicas sobre canais e nós, além de dados locais:

O que a carteira considera ao escolher uma rota
Fator Por que importa
Canais conhecidos A carteira precisa saber quais nós estão conectados por canais públicos, e pode usar dicas para canais privados.
Taxas Cada intermediário pode cobrar uma taxa pequena para encaminhar.
CLTV Cada salto exige uma margem de tempo para se proteger se algo falhar.
Liquidez O canal precisa ter saldo na direção certa. Essa informação nem sempre é pública.
Histórico Carteiras aprendem com tentativas anteriores: canais que falharam podem receber pontuação pior.

Esse ponto é importante: a carteira não tem uma visão perfeita da rede. Ela sabe que um canal existe, mas muitas vezes não sabe quanta liquidez existe na direção exata do pagamento. Por isso a busca de caminho é uma tentativa informada, não uma garantia.

Se o pagamento for grande demais para uma rota, a carteira pode tentar outra rota ou, quando suportado, dividir o pagamento em partes menores.

3. O pagamento é tudo ou nada

"Se o pagamento passa por Alice, o que impede Alice de ficar com o dinheiro e não repassar para Bob?"

A resposta é o HTLC, um contrato condicional por hash e por tempo. Em linguagem simples, ele é um pagamento trancado por um cadeado:

  1. Bob escolhe um segredo e coloca o hash desse segredo na invoice.
  2. Sua carteira cria pagamentos condicionais usando esse mesmo hash em cada salto.
  3. Cada intermediário só recebe se o próximo trecho também avançar.
  4. Se Bob revelar o segredo, todos recebem na ordem correta. Se não revelar, os pagamentos expiram.
Pagamento roteado de você até Bob por Alice; cada salto tem um cadeado que só abre quando Bob revela o segredo.
O HTLC faz o pagamento ser atômico: liquida a rota ou falha.
Descrição longa do diagrama

O diagrama mostra você, Alice e Bob. Entre você e Alice há um pagamento condicional. Entre Alice e Bob há outro pagamento condicional com o mesmo hash. Bob revela o segredo para receber de Alice. Alice aprende esse segredo e usa para receber de você. Se o segredo não aparecer a tempo, os pagamentos voltam pelos caminhos de timeout.

O segredo revelado no final funciona como prova de pagamento. Quem pagou pode verificar que a preimage combina com o hash da invoice.

4. Cada hop vê só o necessário

A Lightning não manda para cada intermediário uma lista aberta com a rota inteira. O pagador monta um pacote onion: uma camada criptografada para cada salto.

Cada hop aprende apenas:

Ele não deve aprender a rota completa. Também não deve saber, só pelo pacote, se está perto do início ou do fim. Isso melhora a privacidade, mas não torna a Lightning anônima: timing, valores, peers diretos e tentativas de pagamento ainda podem vazar pistas.

5. O segredo liquida a rota

Quando o pagamento chega ao recebedor correto, ele revela a preimage. Essa revelação volta pela rota no sentido contrário:

  1. Bob revela a preimage para receber do último intermediário.
  2. Esse intermediário usa a mesma preimage para receber do anterior.
  3. O processo continua até chegar à sua carteira.
  4. Todos os HTLCs saem dos canais e os saldos finais ficam atualizados.

Do ponto de vista dos canais, o pagamento é uma sequência de estados: adicionar HTLC, confirmar estado, revelar segredo, remover HTLC e confirmar novo estado. Se todo mundo coopera, nada disso toca a blockchain.

A blockchain só entra quando um canal precisa ser aberto, fechado ou resolvido em caso de disputa, falha grave ou fechamento unilateral.

Quando falha

Falha de pagamento Lightning não significa necessariamente dinheiro perdido. Normalmente significa que a tentativa de rota não deu certo.

Motivos comuns:

Quando uma tentativa falha, a carteira pode receber uma falha criptografada, ajustar a pontuação de canais e tentar outra rota. Para o usuário, isso aparece como alguns segundos de espera ou uma mensagem de pagamento não concluído.

Falha de rota é normal em Lightning. O importante é a carteira lidar bem com retries, não apresentar cada falha intermediária como perda de fundos.

Privacidade na prática

A Lightning melhora algumas coisas em relação a pagamentos on-chain simples: cada compra não aparece publicamente na blockchain, e intermediários não recebem a rota inteira em texto aberto.

Mas privacidade não é absoluta:

Por isso a frase correta é: Lightning reduz exposição on-chain de pagamentos cotidianos, mas não transforma cada pagamento em anonimato perfeito.

Resumo

Mapa de dependências conceituais

Antes de ler esta página

Depois desta página

Referências técnicas

Esta página simplifica o fluxo. Os detalhes completos estão em:

Na próxima página, vamos sair do modelo mental e ver como começar: tipos de carteira, custódia, canais, recebimento e riscos práticos.