Comparador de Rotas

Compare rotas Lightning por taxa, CLTV e uma heurística local explícita

Eric de Castro
Atualizado em 26/06/2026

Uma carteira Lightning raramente tem uma única rota possível. Ela pode encontrar vários caminhos entre a origem e o destino, cada um com taxas, deltas de CLTV, número de hops e riscos diferentes. Este comparador mostra a conta que uma carteira precisa fazer antes da tentativa: calcular o custo de cada rota e escolher uma candidata.

A ferramenta é didática. Ela não consulta gossip real, não mede liquidez remota, não faz probing, não monta onion, não envia HTLC e não prevê sucesso. Ela só explicita uma heurística local: score = taxa + custo_CLTV + penalidade + penalidade_por_probabilidade.

Conteúdo

Ferramenta

Comparador de Rotas

Compare rotas candidatas por taxa, CLTV e uma penalidade local fictícia. É uma heurística didática, não prova liquidez real.

Valor a entregar (msat)

CLTV final mínimo

Custo por bloco CLTV (msat)

Rotas candidatas

Uma por linha. Formato: Nome | base/ppm/cltv > base/ppm/cltv | penalidade_msat | probabilidade_0a100.

Resultado do comparador de rotas

Fonte primária

A fórmula de taxa por hop vem da seção de HTLC fees da BOLT 7: taxa base mais taxa proporcional em partes por milhão. O payload por hop e as falhas que voltam para a origem vêm da BOLT 4. O HTLC que carrega a tentativa é update_add_htlc, definido na BOLT 2. Dados como valor, destino, payment_secret e min_final_cltv_expiry_delta normalmente vêm da invoice BOLT 11.

O que está sendo comparado

O comparador assume que uma etapa anterior já encontrou rotas candidatas. Cada linha descreve uma rota como uma sequência de hops, e cada hop tem:

Campos usados por hop
Campo	Exemplo	Significado
base	1000	Taxa fixa em millisatoshis que o hop cobra para encaminhar.
ppm	500	Taxa proporcional em millionths, aplicada ao valor encaminhado.
cltv	144	Folga de blocos que aquele hop exige entre HTLC de entrada e saída.
penalidade	1500	Custo local fictício para representar falhas recentes, canal antigo, preferência de privacidade ou política da carteira.
probabilidade	45	Probabilidade didática de sucesso, entre 1 e 100. Não vem da especificação.

Na prática, base, ppm e cltv vêm de channel_update para a direção exata usada. Já penalidade e probabilidade são heurísticas locais de implementação.

Score local

Ordenar só por taxa total é simples, mas incompleto. Uma rota barata pode ter CLTV alto demais, canal com falha recente ou baixa chance estimada de ter liquidez suficiente. Por isso carteiras reais mantêm algum tipo de memória local. A ferramenta usa uma fórmula transparente:

fee_hop = fee_base_msat + floor(amt_to_forward * fee_proportional_millionths / 1.000.000)

taxa_total = soma das fees calculadas de trás para frente
CLTV_total = min_final_cltv_expiry_delta + soma dos cltv_expiry_delta
custo_CLTV = CLTV_total * custo_por_bloco
penalidade_por_probabilidade = floor((100 - probabilidade) * valor_final / 1000)

score = taxa_total + custo_CLTV + penalidade + penalidade_por_probabilidade

Essa fórmula não é normativa. Ela existe para o leitor ver que a escolha de rota é uma função de custo local, não uma regra universal dos BOLTs.

Exemplo trabalhado

Considere uma invoice de 100.000 msat, CLTV final mínimo de 18 e custo de 2 msat por bloco de CLTV. A rota A tem dois hops:

Rota A | 1000/100/40 > 1000/500/144 | 0 | 70

O cálculo volta do destino para a origem:

Cálculo reverso da Rota A
Hop	Encaminha	Fee	Entrada exigida
Hop 2	100.000 msat	1.050 msat	101.050 msat
Hop 1	101.050 msat	1.010 msat	102.060 msat

A taxa total é 2.060 msat. O CLTV total é 18 + 40 + 144 = 202 blocos. Com custo de 2 msat por bloco, o custo CLTV é 404 msat. Com probabilidade didática de 70%, a penalidade por probabilidade é 3.000 msat. O score fica 5.464.

Por que isso não prova liquidez

O grafo público não revela saldos por direção. Um canal pode ter capacidade grande e mesmo assim não ter liquidez na direção que você precisa. Também pode ter channel_update recente, taxa baixa e CLTV razoável, mas estar congestionado por HTLCs pendentes ou por política local do nó.

O pagador conhece melhor apenas seus próprios canais: saldo local, limites, HTLCs pendentes e peer conectado. Para canais remotos, ele trabalha com sinais indiretos: capacidade, idade do update, falhas recentes, sucessos recentes, probing, valores testados e reputação local.

Falhas e retries

Quando uma tentativa falha, a origem recebe uma falha onion e tenta aprender algo sem enxergar saldos privados. Alguns exemplos importantes:

temporary_channel_failure: pode indicar falta de liquidez, canal temporariamente indisponível ou outro problema local.
fee_insufficient: a taxa calculada não bate com a política atual do hop.
incorrect_cltv_expiry: o CLTV oferecido não respeita o delta esperado.
channel_disabled: a direção foi marcada como desabilitada.
incorrect_or_unknown_payment_details: o destino rejeitou dados finais do pagamento.

Depois disso, a carteira pode penalizar um canal, recalcular rotas, tentar valor menor, dividir em MPP ou aguardar. Esses comportamentos são implementação, não formato obrigatório do protocolo.

Privacidade

Escolher sempre a rota mais barata pode criar padrão. Intermediários observam o valor que recebem, o CLTV de entrada e saída, o peer anterior e o próximo peer. Eles não veem a rota inteira, mas podem fazer inferências com base no grafo público e em padrões de tentativa.

Uma carteira pode randomizar entre rotas suficientemente boas, evitar hubs óbvios, limitar retries, usar MPP ou aplicar penalidades de privacidade. Essas decisões trocam custo, confiabilidade e vazamento de metadados.

Limites da ferramenta

A ferramenta não substitui um algoritmo real de pathfinding. Ela não interpreta channel_flags, htlc_minimum_msat, htlc_maximum_msat, features, routing hints, blinded paths, MPP, canais privados, liquidez local real, falhas onion reais nem estado de mempool/on-chain. Ela também não calcula o pacote onion; para isso use a página Construtor de Rota Onion como modelo didático separado.

Armadilhas comuns

Confundir menor taxa com maior probabilidade de sucesso.
Usar política de canal no sentido errado. channel_update é direcional.
Ignorar CLTV acumulado e o tempo que fundos podem ficar presos em uma falha.
Assumir que capacidade pública é liquidez disponível.
Tratar probabilidade local como dado de protocolo. Ela é inferência da carteira.
Fazer retries agressivos e aumentar vazamento por probing acidental.

Mapa conceitual

Antes de usar esta ferramenta

Busca de Caminho, para entender a separação entre BOLT e heurística.
Gossip e o Grafo de Canais, para revisar channel_update e políticas direcionais.
Construtor de Rota Onion, para ver como a rota escolhida vira payload por hop.

Depois de usar esta ferramenta

Roteamento Onion, para entender como falhas voltam sem revelar a rota inteira.
Cadeado do HTLC, para conectar rota escolhida, preimage e timeout.
Taxas de transação e mempool, para comparar custo Lightning com risco on-chain em fechamentos.