Na Lightning Network, normalmente o remetente constrói a rota. A partir do grafo gossip público, dos dados do destinatário e de seus próprios resultados, estima um caminho; calcula de trás para frente o valor, a taxa e o CLTV de cada salto, encapsula instruções num pacote onion e tenta outra rota após uma falha. Como o grafo não revela a divisão atual dos saldos, o routing é uma decisão probabilística com informação incompleta e mutável.
O routing começa no pagador: sua wallet ou node escolhe um caminho até o recebedor e indica o próximo channel a cada intermediário. O destinatário fornece identidade, features e talvez route hints ou blinded paths; o remetente calcula a parte pública.
O BOLT #7 propaga anúncios e channel updates direcionais com taxa base, proporcional, delta CLTV, mínimo, máximo e disponibilidade. Eles descrevem policy e topologia anunciadas, mas não provam estado online nem liquidez atual.
O gossip público não revela a divisão do balance. O router combina liquidez local conhecida, capacidade, sucessos, falhas, penalidades e scoring próprio. O caminho teoricamente mais barato pode não ser o mais provável.
Valores e expirações são montados de trás para frente. Cada hop recebe o valor seguinte mais sua fee e CLTV superior pelo seu delta; mais saltos elevam taxas agregadas e margem temporal.
O BOLT #4 usa onion routing: o pagador cria pacote Sphinx com payload cifrado por hop. O intermediário conhece vizinhos e sua instrução, não todo o caminho, extensão ou posição; análise de tráfego e conluio ainda reduzem privacidade.
Falha temporária, fee insuficiente, CLTV incorreto ou next peer desconhecido devolvem sinal limitado. A implementação pode penalizar, recalcular e tentar novamente; um resultado não descreve permanentemente o canal.
Cada hop deve aceitar o HTLC e ter liquidez útil na direção certa após reservas, pending HTLC e limites min/max. Alta capacidade total ou muitas conexões não removem um canal desequilibrado.
Com basic MPP, o pagador divide total_msat por vários caminhos liquidados como conjunto. MPP usa liquidez dispersa, mas adiciona HTLCs, tentativas e taxas e não cria capacidade.
Route hints BOLT 11 expõem saltos privados finais; BOLT 12 e route blinding fornecem uma cauda cifrada via introduction point. O pagador ainda precisa alcançar o primeiro ponto e respeitar taxas e CLTV agregados.
Registre implementação, versão, valor, limites de fee e CLTV, tentativas, paths, tempo e erro exato. Compare o mesmo par de nodes em momentos próximos: sucesso pertence a um pagamento e estado específicos. Fontes: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, HTLC, Liquidez Lightning, Payment Channel, Bitcoin, Inbound Liquidity. Também há referências a este verbete em HTLC, Liquidez Lightning, BOLT 12, Inbound Liquidity.