Construtor de Rota Onion

Calcule payloads didáticos por hop, fees e CLTV acumulado de uma rota Lightning

Esta ferramenta mostra a parte da rota onion que é mais fácil de inspecionar sem implementar criptografia: quanto cada hop deve encaminhar, qual short_channel_id ele deve usar para o próximo canal e qual outgoing_cltv_value deve aparecer no payload daquele hop.

Ela é deliberadamente didática. Ela não cria um pacote Sphinx real, não deriva shared secrets por ECDH, não calcula HMACs, não preenche o campo fixo de 1300 bytes e não transmite um update_add_htlc. Use os dados como simulação de raciocínio, não como serialização pronta para carteira ou nó Lightning.

Conteúdo

Ferramenta

Construtor de Rota Onion

Construtor de Rota Onion

Calcule, do destino para a origem, o valor, a taxa e o CLTV de cada hop. É uma simulação didática do payload por hop, não um pacote Sphinx real.

Resultado da rota onion

Fonte primária

A estrutura do pacote onion e do payload por hop vem da BOLT 4. O cálculo de taxas e os dados anunciados por canais públicos vêm da BOLT 7. O HTLC que carrega o pacote aparece em update_add_htlc, definido na BOLT 2. O payment_hash, payment_secret, valor e min_final_cltv_expiry_delta geralmente vêm de uma invoice BOLT 11.

Modelo da ferramenta

Em uma rota simples Alice -> Bob -> Carol -> Dina, Alice monta um payload diferente para cada hop. Bob deve aprender apenas o que precisa para encaminhar para Carol; Carol deve aprender apenas o que precisa para encaminhar para Dina; Dina deve receber os campos do pagamento final.

A ferramenta modela esse pedaço:

payload de Bob:
  short_channel_id     = canal Bob -> Carol
  amt_to_forward       = quanto Bob deve enviar para Carol
  outgoing_cltv_value  = CLTV do HTLC de Bob para Carol

payload de Carol:
  short_channel_id     = canal Carol -> Dina
  amt_to_forward       = quanto Carol deve enviar para Dina
  outgoing_cltv_value  = CLTV do HTLC de Carol para Dina

payload de Dina:
  amt_to_forward       = valor recebido neste HTLC
  outgoing_cltv_value  = CLTV final esperado

O pacote onion real protege esses payloads com camadas criptográficas. O nó que processa uma camada não recebe a tabela inteira; ele recebe sua instrução local, verifica se o HTLC de entrada bate com ela e encaminha o próximo HTLC.

Campos por hop

Campos que a ferramenta representa
Campo Quem usa Função
short_channel_id Hops não finais. Identifica o canal de saída que o hop deve usar para o próximo nó. O valor vem do grafo de gossip.
amt_to_forward Todos os hops. Valor, em millisatoshis, que aquele hop deve encaminhar ou aceitar no destino final.
outgoing_cltv_value Todos os hops. Altura absoluta de CLTV esperada para o HTLC de saída daquele hop, ou para o HTLC final.
payment_data Hop final, quando exigido pela invoice. Carrega payment_secret e total_msat; importante para invoices modernas e MPP.
payment_metadata Hop final, se fornecido pelo recebedor. Metadados autenticados pelo recebedor; a ferramenta só cita, não serializa.

Cálculo de trás para frente

A origem calcula a rota de trás para frente porque cada hop cobra taxa sobre o valor que ele deve encaminhar. Se Dina deve receber 100.000 msat, Carol precisa receber esse valor mais a taxa dela; Bob precisa receber o valor que Carol espera mais a taxa de Bob.

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

valor_de_entrada_no_hop = amt_to_forward + fee
cltv_de_entrada_no_hop  = outgoing_cltv_value + cltv_expiry_delta

O mesmo raciocínio vale para CLTV. O destino final usa a altura atual mais o delta final da invoice. Cada hop anterior soma o cltv_expiry_delta anunciado no channel_update da direção usada. Isso dá tempo para o intermediário resolver o HTLC se o pagamento falhar ou precisar ir para on-chain.

Exemplo trabalhado

Com os valores padrão da ferramenta:

Resultado esperado do exemplo padrão
Hop Encaminha Taxa CLTV de saída Entrada esperada
Bob101.050 msat1.010 msat850.204102.060 msat / 850.244
Carol100.000 msat1.050 msat850.060101.050 msat / 850.204
Dina100.000 msat0 msat850.060100.000 msat / 850.060

Portanto Alice precisa oferecer a Bob um HTLC de 102.060 msat com CLTV 850.244. Bob fica com 1.010 msat se encaminhar corretamente, Carol fica com 1.050 msat e Dina recebe os 100.000 msat do pagamento.

Privacidade e offset de CLTV

Se a origem simplesmente somar os deltas mínimos, um intermediário pode tentar estimar sua posição na rota comparando o CLTV observado com políticas públicas do grafo. A BOLT 7 recomenda considerar um offset, muitas vezes chamado de shadow route extension, para tornar essa inferência menos direta.

O campo "Offset privado de CLTV" da ferramenta representa esse acréscimo didático. Ele aumenta todos os CLTVs da rota, mas não torna o pagamento anônimo. Tamanho de valor, seleção de canais, timing, falhas e liquidez ainda vazam informação para partes diferentes do caminho.

Limites reais

A ferramenta não escolhe a rota. Ela assume que a rota já foi encontrada. Busca real de caminho envolve grafo local, channel_update, canais desabilitados, htlc_minimum_msat, htlc_maximum_msat, liquidez provável, histórico de falhas, retries e, em alguns casos, MPP. Isso é explicado em Busca de Caminho.

Também não há criptografia onion real. Um pacote BOLT 4 versão 0 contém versão, chave pública efêmera, hop_payloads de 1300 bytes e HMAC. Para montar isso de verdade, a origem precisa das chaves públicas dos nós, calcular shared secrets por hop, derivar chaves como rho, mu, um e pad, aplicar filler e autenticar cada camada.

Armadilhas comuns

Mapa conceitual

Antes de usar esta ferramenta

Depois de usar esta ferramenta

Referências