Arquitetura da Lightning

Como Bitcoin, canais, transporte, mensagens, roteamento e invoices se encaixam

Lightning · Técnico

A Lightning não é uma blockchain nova nem um consenso paralelo. Ela é uma rede de contratos off-chain ancorados no Bitcoin, operada por peers que trocam mensagens, assinaturas e HTLCs. A arquitetura fica mais clara quando se separa o que é garantia on-chain, o que é protocolo entre peers e o que é política local de implementação.

As fontes primárias desta página são os BOLTs principais: BOLT 1, BOLT 2, BOLT 3, BOLT 4, BOLT 5, BOLT 7, BOLT 8, BOLT 9 e BOLT 11. BOLT 12 aparece aqui como evolução, não como requisito universal.

Conteúdo

Modelo mental

A forma mais segura de entender Lightning é imaginar três planos ao mesmo tempo:

fluxo conceitual de um pagamento:

recebedor:
  cria invoice BOLT 11
  inclui payment_hash, payment_secret, valor, expiração e features

pagador:
  valida invoice
  consulta grafo BOLT 7 e políticas locais
  escolhe rota provável
  calcula fees e CLTV acumulado de trás para frente
  monta onion BOLT 4 com payload por hop

peers intermediários:
  recebem update_add_htlc
  verificam valor, CLTV, canal de saída e política local
  encaminham novo HTLC sem conhecer rota completa

recebedor:
  valida payload final e payment_secret
  revela payment_preimage

rede de canais:
  liquida o HTLC de volta até o pagador
  atualiza commitments e revoga estados antigos

Repare no ponto central: o pagamento parece instantâneo para o usuário, mas por baixo ele atravessa várias camadas. O Bitcoin fornece a saída de emergência; os canais fornecem atualização rápida de estado; o onion reduz vazamento de rota; e a busca de caminho tenta entregar algo com informação incompleta.

Pilha da Lightning: Bitcoin na base, canais, transporte criptografado, protocolo wire, roteamento e invoices no topo.
A Lightning é uma pilha: cada camada depende das garantias e limitações da camada abaixo.
Descrição longa do diagrama

O diagrama mostra Bitcoin como camada de base. Acima dele ficam canais de pagamento, que dependem da funding transaction e das commitment transactions. Depois aparecem transporte criptografado e protocolo wire, responsáveis por carregar mensagens entre peers. Em seguida vem roteamento, composto por HTLCs, onion routing, gossip e busca de caminho. No topo estão invoices e pagamentos que o usuário enxerga.

Camadas arquiteturais

Esta tabela resume onde cada parte vive, quais BOLTs entram e que tipo de falha ela tenta limitar.

Camadas da arquitetura Lightning
Camada Função Fontes Estado principal Riscos típicos
Bitcoin on-chain Ancora os fundos em UTXOs, scripts, assinaturas, taxas e confirmações. BOLT 3, BOLT 5 funding output, commitment transactions, closes fee spike, reorg, pinning, eclipse, perda de watchtower
Canal entre dois peers Mantém um contrato revogável entre duas chaves de nó. BOLT 2, BOLT 3 channel_id, balances, HTLCs, commitments estado antigo, backup errado, desconexão, limites de HTLC
Transporte e wire Cria sessão cifrada e carrega mensagens binárias tipadas. BOLT 8, BOLT 1, BOLT 9 Noise session, init, features, type/payload/TLV feature incompatível, parser frágil, metadados de conexão
Roteamento Encaminha pagamentos por canais que não pertencem ao pagador. BOLT 2, BOLT 4, BOLT 7 update_add_htlc, onion packet, channel_update, graph falha de rota, liquidez remota desconhecida, probing, jamming
Pagamento Liga invoice, payment hash, preimage, segredo do recebedor e liquidação final. BOLT 11, BOLT 4 invoice, payment_secret, payment_hash, preimage, MPP invoice expirada, metadados, fallback, privacidade do destino
Política local Escolhe canais, fees, peers, retries, backups e operação. fora do consenso dos BOLTs scores, liquidez, políticas, monitoramento heurística ruim, centralização, indisponibilidade, custo on-chain

A camada Bitcoin aparece em quase toda página técnica Lightning. Funding e fechamento são transações Bitcoin; scripts de commitment dependem de Script e witness; segurança contra estados antigos usa sequence/CSV; expiries de HTLC usam locktime/CLTV; e fechamento unilateral depende da mempool e de taxas.

Ciclo de vida

Uma implementação Lightning não executa uma única rotina chamada "pagar". Ela atravessa estados e subsistemas diferentes.

Do peer conectado ao pagamento liquidado
Etapa Mensagens ou dados O que precisa dar certo
1. Conectar Noise handshake, init Os nós autenticam a sessão, anunciam features e verificam se falam o mesmo conjunto mínimo de regras.
2. Abrir canal open_channel/accept_channel ou fluxo v2 Os peers negociam parâmetros, chaves-base, limites, funding e formato de commitment.
3. Ancorar no Bitcoin funding_created, funding_signed, channel_ready A funding transaction cria o UTXO 2-de-2; depois de confirmações, o canal fica utilizável.
4. Atualizar estado update_add_htlc, commitment_signed, revoke_and_ack Cada mudança de saldo ou HTLC só fica segura quando assinaturas e revogações cruzam corretamente.
5. Roteiar pagamento onion payload, update_fulfill_htlc, update_fail_htlc O pagador escolhe rota, monta onion, paga fees e CLTV por hop, e aprende com falhas.
6. Fechar ou resolver shutdown, closing_* ou transações on-chain O canal fecha cooperativamente, unilateralmente ou por resolução de disputa na blockchain. 
estado de um canal:

funding output on-chain
  -> commitment local
  -> commitment remoto
  -> HTLCs em voo
  -> próxima atualização proposta
  -> commitment_signed
  -> revoke_and_ack do estado antigo

regra mental:
  saldo Lightning não é um banco de dados global.
  é um conjunto de transações assináveis, mensagens pendentes,
  revogações e dados que precisam sobreviver a reconexões.

Esse estado é local. Não existe um "saldo Lightning global" consultável na rede. Cada nó conhece seus próprios canais, vê o grafo público por gossip e infere o resto por tentativa, política e histórico.

Especificação vs política local

Os BOLTs definem interoperabilidade. Eles não definem toda a experiência de carteira, todo algoritmo de pathfinding, toda estratégia de liquidez ou toda política contra abuso.

Onde termina a especificação e começa a política do nó
Área Fonte normativa Definido pelo protocolo Escolha local
Consenso Bitcoin não é BOLT Lightning validade de blocos, transações, Script, witness, UTXO, locktime, sequence e assinatura qual nó Bitcoin usar, quantos peers, política de mempool observada
Formato de mensagens BOLT 1 type de 2 bytes, payload, TLV, BigSize, regra par/ímpar e grupos de mensagens estrutura interna do parser, logs, métricas, limites defensivos adicionais
Canais BOLT 2/3/5 mensagens, chaves, scripts, commitments, HTLCs, revogação e tratamento on-chain quando abrir, com quem abrir, reservas extras, automação de fee bump e watchtower
Grafo público BOLT 7 channel_announcement, channel_update, node_announcement, SCID e validações poda, scoring, preferência por peers, cache e interpretação de falhas
Pathfinding BOLT 7 recomendações fees e CLTV são dados do grafo; não há algoritmo único obrigatório Dijkstra, Yen, randomização, shadow route, MPP, retries e penalização de canais
Invoice BOLT 11 Bech32, HRP, tagged fields, assinatura, payment_secret e feature bits UX, expiração exibida, descrição sanitizada, tentativa de fallback e limites de valor

Essa separação evita dois erros: tratar heurística de uma implementação como regra universal e, no sentido oposto, chamar de "detalhe de implementação" algo que é exigido para interoperabilidade.

Anatomia de um nó

Um nó Lightning completo costuma combinar vários módulos:

Camadas internas de um nó Lightning: Bitcoin, estado de canais, mensagens, gossip, roteamento e camada de pagamento.
Um nó Lightning junta monitoramento Bitcoin, máquina de estado de canal e rede de roteamento.
Descrição longa do diagrama

O diagrama mostra camadas internas: Bitcoin e monitoramento de cadeia na base, estado de canais e commitments acima, mensagens e transporte entre peers, gossip para formar o grafo, busca de caminho e onion routing para pagamentos, e invoices no topo. As setas indicam dependência: roteamento depende do grafo, canal depende de mensagens e chain monitor, e tudo depende da capacidade de resolver disputas no Bitcoin.

Unidades e estado

A unidade contábil da Lightning é o millisatoshi (msat), a milésima parte de um satoshi. Isso permite representar micropagamentos e fees proporcionais menores que 1 satoshi por hop. Na blockchain, porém, saídas só existem em satoshis inteiros. Por isso a BOLT 3 precisa lidar com arredondamento, dust e trimming de outputs.

Regra útil: 1 BTC = 100.000.000 sat = 100.000.000.000 msat. Em commitments on-chain, valores abaixo de 1 satoshi não viram output Bitcoin.

Conversor de Millisatoshis

Conversor de Millisatoshis

No Lightning, a unidade base é o millisatoshi (msat) — a milésima parte de um satoshi. Edite qualquer campo.

Mapa dos BOLTs

Os BOLTs são a camada de especificação que permite interoperabilidade entre LND, Core Lightning, Eclair e outras implementações. Eles não são "documentação de produto"; são contratos técnicos de mensagem, validação e comportamento mínimo.

BOLTs no mapa arquitetural
BOLT Tema Página relacionada Papel arquitetural
BOLT 1 Base protocol Protocolo Wire Define envelope de mensagem, TLV, BigSize, init, warning/error, ping/pong e regra par/ímpar.
BOLT 2 Peer protocol Operação de canais Define abertura, operação normal, HTLCs, commitment_signed, revoke_and_ack, update_fee, fechamento e retransmissão.
BOLT 3 Transações e scripts Canais de pagamento Define funding output, commitment transaction, HTLC outputs, anchors, dust, fees e derivação de chaves.
BOLT 4 Onion routing Roteamento onion Define pacote Sphinx, hop payload TLV, failure onion, MPP e route blinding.
BOLT 5 Tratamento on-chain Segurança e privacidade Recomenda como reagir a mutual close, unilateral close, revoked close e reorgs.
BOLT 7 Gossip e roteamento Gossip e busca de caminho Define anúncios de nós/canais, channel_update, consultas de gossip, SCID, fees e CLTV delta.
BOLT 8 Transporte Transporte criptografado Define Noise_XK, acts de handshake, framing cifrado, tamanho máximo e rotação de chaves.
BOLT 9 Feature bits Wire, invoices e gossip Define bits opcionais/obrigatórios em init, node/channel announcements, invoices e channel_type.
BOLT 10 DNS bootstrap Arquitetura Ajuda descoberta inicial de nós; não substitui gossip assinado nem validação on-chain.
BOLT 11 Invoices Pedidos de pagamento Define invoice Bech32, HRP, valor, timestamp, tagged fields, assinatura e payment_secret.
BOLT 12 Offers Evolução Evolução para pedidos reutilizáveis e fluxos modernos; não tratar como base universal.

O caminho de leitura desta trilha segue essa arquitetura: comece por canais de pagamento, avance para operação de canais, depois onion, gossip, busca de caminho, invoices, wire, transporte, segurança e privacidade e mensagens do protocolo.

Implicações operacionais

A arquitetura explica por que operar Lightning é diferente de manter uma carteira on-chain simples:

Armadilhas comuns

Resumo

Mapa de dependências conceituais

Antes de ler esta página

Depois desta página

Referências técnicas usadas

Com o mapa em mãos, o próximo passo é descer para a base da arquitetura: os canais de pagamento e suas transações de compromisso.