Busca de Caminho
Escolher uma rota — e entregar o pagamento
-
Eric de Castro - Atualizado em
⚡ Lightning · Técnico
Com o grafo de canais em mãos, falta o último passo: escolher uma rota da origem até o destino e entregar o pagamento. Diferente da internet (onde cada roteador decide o próximo salto), na Lightning é a origem que calcula a rota inteira — é o source-based routing, e é o que permite o roteamento onion.
O ponto cego: você não conhece os saldos
Aqui está o que torna a busca de caminho difícil. Pelo gossip, você sabe que um canal existe, sua capacidade e a política (taxa, cltv). Mas você não sabe como o saldo está dividido entre os dois lados — e é justamente isso que determina se o canal consegue encaminhar o seu valor naquela direção.
Resultado: a busca de caminho é probabilística. Você escolhe um caminho promissor, tenta, e se falhar (por exemplo, saldo insuficiente em algum salto), o erro onion te diz onde falhou — e você tenta outra rota.
A função de custo
Entre os caminhos possíveis, qual é o "melhor"? A carteira atribui um custo a cada aresta e procura o de menor custo (tipicamente com um algoritmo tipo Dijkstra, rodado de trás para frente, do destino para a origem — porque taxas e cltv se acumulam nesse sentido). O custo combina:
- Taxa — base + proporcional (ppm) que cada salto cobra.
- Tempo de bloqueio — um
cltv_expiry_deltamaior prende seu dinheiro por mais tempo se algo der errado; isso tem um custo. - Confiabilidade — canais que já falharam antes recebem uma "penalidade" para serem evitados nas próximas tentativas.
Compare rotas candidatas pela taxa total e pelo CLTV total:
Comparador de Rotas
Entrega: tentar, errar, tentar de novo
Entregar um pagamento costuma ser um ciclo:
- escolhe a rota de menor custo ainda não descartada;
- monta a cebola e envia o HTLC;
- se chegou, ótimo — o segredo volta e liquida tudo;
- se falhou, lê o erro onion, aprende com ele (qual canal estava sem saldo) e tenta a próxima rota.
As implementações guardam o que aprenderam sobre a rede nessas tentativas (no LND isso se chama mission control) para que as próximas escolhas sejam mais certeiras.
Pagamentos em partes (MPP)
E se nenhum caminho único tiver saldo suficiente para o valor todo? Aí entram os pagamentos multipartes (MPP, Multi-Part Payments): a origem divide o valor em pedaços e envia cada um por uma rota diferente. Todos os pedaços carregam o mesmo payment_hash, e um payment_secret os amarra. O destinatário só resgata quando a soma dos pedaços recebidos bate com o valor total — então continua sendo tudo ou nada.
E os clientes leves?
Manter o grafo inteiro e calcular rotas dá trabalho — pesado demais para uma carteira de celular. O trampoline routing resolve isso deixando o cliente leve escolher só alguns nós "trampolim" e delegar a eles o cálculo do caminho detalhado, sem abrir mão do roteamento onion.
Já entendemos como o pagamento acha o caminho. A seguir, voltamos ao ponto de partida de tudo: a invoice (BOLT 11) — o pedido de pagamento que a origem lê para saber quanto, para quem e com qual payment_hash.