Roteamento Onion

Como cada hop aprende só o próprio próximo passo

Lightning · Técnico

No encaminhamento de HTLCs, um pagamento pode passar por varios canais antes de chegar ao destino. Sem uma camada de privacidade, cada hop poderia aprender origem, destino, tamanho da rota e talvez correlacionar tentativas. O roteamento onion, especificado na BOLT 4, reduz esse vazamento: cada hop aprende apenas de quem recebeu, para quem deve encaminhar, quanto deve encaminhar e qual CLTV usar.

A Lightning usa um esquema baseado em Sphinx. A origem calcula a rota inteira, cria um pacote de tamanho fixo e coloca uma camada criptografada para cada hop. O pacote viaja dentro do campo onion_routing_packet da mensagem update_add_htlc, descrita na BOLT 2.

Onion routing nao torna o pagamento anonimo. Ele limita o que cada hop ve. Trafego de rede, timing, valores incomuns, probing e observacao on-chain ainda podem vazar informacao.

Conteúdo

Modelo mental

Pense em uma rota simples:

Alice -> Bob -> Carol -> Dina

Alice e a origem. Dina e o destino. Bob e Carol sao hops intermediarios. Alice conhece a rota inteira porque ela fez a busca de caminho. Mas Bob nao deve saber que Dina e o destino final, e Carol nao deve saber que Alice e a origem.

O pacote onion resolve isso assim:

Pacote onion com camadas criptografadas, uma para cada hop da rota, mantendo tamanho fixo.
Cada hop remove uma camada e encaminha a cebola restante.
Descricao longa do diagrama

O diagrama mostra uma cebola com camadas externas e internas. A camada externa pertence ao primeiro hop, as camadas seguintes pertencem aos hops intermediarios, e o nucleo pertence ao destino. Setas indicam que cada hop remove apenas sua camada e repassa o restante.

Pacote onion

Na BOLT 4, o pacote onion de pagamento tem quatro partes principais:

Estrutura do onion packet
Campo Tamanho Função
version 1 byte Versao do pacote onion. Na versao 0, o valor e 0x00.
public_key 33 bytes Chave publica efemera comprimida usada pelo hop para calcular o segredo compartilhado.
hop_payloads 1300 bytes Area fixa com payloads por hop, HMACs e filler ofuscado.
hmac 32 bytes Autenticacao do pacote para o hop atual.

O campo hop_payloads tem 1300 bytes. Dentro dele aparecem payloads variaveis por hop, cada um prefixado por um tamanho em BigSize, seguido do payload, de um HMAC e de filler. Esse tamanho fixo ajuda a esconder quantos hops ainda restam.

O pacote onion nao substitui o HTLC. Ele viaja dentro do HTLC e diz aos hops como verificar e encaminhar o proximo HTLC.

Segredos e chaves derivadas

A origem cria uma chave efemera e calcula um segredo compartilhado com cada hop usando ECDH em secp256k1. Cada hop tambem consegue calcular o proprio segredo compartilhado usando sua chave privada e a chave efemera recebida. Os outros segredos continuam escondidos.

Origem combina uma chave efemera com a chave publica de cada hop para derivar segredos e chaves rho, mu, um e pad.
Cada hop tem um segredo diferente, embora a origem tenha calculado todos antes de enviar.
Descricao longa do diagrama

O diagrama mostra a chave efemera da origem sendo combinada com a chave publica de cada hop. De cada combinacao sai um segredo compartilhado. Setas a partir do segredo mostram as chaves derivadas usadas para ofuscacao, HMAC, erro e filler.

Chaves derivadas do segredo compartilhado
Chave Uso
rho Gerar o stream pseudoaleatorio usado para ofuscar o payload.
mu Gerar e verificar HMACs de integridade.
um Criptografar e descriptografar erros retornados ao pagador.
pad Gerar filler deterministico para manter o tamanho fixo.

A chave efemera tambem e cegada a cada salto. Isso significa que o proximo hop ve outra chave efemera, impedindo que hops diferentes simplesmente comparem o mesmo ponto publico para correlacionar a rota.

Payload TLV por hop

O payload moderno por hop usa o formato TLV da BOLT 1. Isso permite extensoes sem mudar a estrutura inteira do pacote.

Tipos TLV usados no hop payload da BOLT 4
Tipo Nome Hop final Hop intermediário Significado
2 amt_to_forward sim sim Valor em msat que este hop deve encaminhar ou entregar.
4 outgoing_cltv_value sim sim CLTV que o HTLC de saida deve usar.
6 short_channel_id nao sim Canal de saida para o proximo hop.
8 payment_data sim nao payment_secret e total_msat vindos da invoice BOLT 11.
10 encrypted_recipient_data blinded blinded Dados cifrados fornecidos pelo recebedor para caminhos cegados.
12 current_path_key blinded blinded Chave de caminho usada em route blinding.
16 payment_metadata sim nao Metadados da invoice, se o campo m existir.
18 total_amount_msat blinded nao Valor total em msat usado em pagamentos com caminho cegado.

Para um hop intermediario fora de caminho cegado, os campos centrais sao amt_to_forward, outgoing_cltv_value e short_channel_id. Para o destino, nao ha short_channel_id, porque nao existe proximo canal. O destino recebe payment_data com o payment_secret da invoice BOLT 11 e o total_msat.

hop intermediario:
type 2  amt_to_forward       = 101000 msat
type 4  outgoing_cltv_value  = 850144
type 6  short_channel_id     = 700000x42x0

hop final:
type 2  amt_to_forward       = 100000 msat
type 4  outgoing_cltv_value  = 850018
type 8  payment_data:
        payment_secret = 32 bytes
        total_msat     = 100000

O hop usa esses dados para conferir se o HTLC recebido bate com o que a origem prometeu no onion. Por exemplo, se o HTLC recebido nao tem valor suficiente para pagar a taxa e ainda encaminhar amt_to_forward, o hop deve falhar o pagamento.

Construção da cebola

A origem monta o pacote de dentro para fora, porque a camada externa precisa conter, cifrada, a camada interna pronta. O calculo de valor e CLTV tambem anda de tras para frente: o destino recebe o valor final; cada hop anterior precisa receber esse valor mais sua taxa, e um CLTV de entrada maior que o CLTV de saida.

rota escolhida:
Alice -> Bob -> Carol -> Dina

1. Alice pega as chaves publicas dos hops.
2. Alice cria uma chave efemera inicial.
3. Para cada hop, Alice calcula um segredo ECDH.
4. De cada segredo, Alice deriva rho, mu, um e pad.
5. Alice monta os payloads do destino para a origem:
   - Dina recebe payment_data e valor final.
   - Carol recebe amt_to_forward, outgoing_cltv_value e short_channel_id para Dina.
   - Bob recebe amt_to_forward, outgoing_cltv_value e short_channel_id para Carol.
6. Alice adiciona HMACs e filler para manter hop_payloads com 1300 bytes.
7. Alice envia update_add_htlc para Bob com onion_routing_packet.
8. Cada hop descasca uma camada e encaminha a cebola interna.

Esse processo conecta onion routing com gossip e busca de caminho. O gossip fornece short_channel_id, taxas e cltv_expiry_delta. A busca escolhe a rota. O onion transforma essa rota em instrucoes privadas por hop.

Descascando uma camada

Quando um hop recebe o HTLC, ele nao conhece a rota inteira. Ele recebe um pacote onion e processa apenas a camada destinada a ele:

ao receber um onion packet:

1. calcular shared_secret = ECDH(chave_privada_do_hop, public_key_efemera)
2. derivar rho, mu, um e pad
3. verificar HMAC do pacote atual
4. descriptografar o primeiro hop_payload
5. validar amt_to_forward e outgoing_cltv_value contra o HTLC recebido
6. se nao for o destino:
   - ler short_channel_id
   - cegar a public_key efemera para o proximo hop
   - encaminhar update_add_htlc com a cebola restante
7. se for o destino:
   - validar payment_secret
   - validar total_msat, metadata e CLTV final
   - cumprir ou falhar o HTLC
Um hop recebe onion packet e chave efemera, deriva segredo, verifica HMAC, le seu payload e encaminha a cebola restante.
O hop aprende o proximo passo, nao a rota inteira.
Descricao longa do diagrama

O diagrama mostra um hop recebendo uma cebola e uma chave efemera. O hop calcula o segredo compartilhado, verifica o HMAC, abre sua camada, le valor, CLTV e proximo canal, cega a chave efemera e encaminha uma cebola restante ao proximo hop.

Ferramenta: construtor didático de rota onion

A ferramenta abaixo calcula valor e CLTV de tras para frente e mostra o que cada hop veria em sua camada. Ela e didatica: nao implementa Sphinx real, nao cria HMACs reais e nao deve ser usada para construir pagamentos reais. Use apenas nomes e valores ficticios.

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

Erros onion

Quando algo falha, o erro precisa voltar para a origem sem revelar diagnostico aos intermediarios. O hop que detecta a falha monta uma failure message, cifra usando a chave derivada do segredo compartilhado e manda o erro de volta pelo caminho reverso. Cada hop anterior aplica sua propria camada de ofuscacao. No fim, a origem consegue descascar o erro e descobrir onde a tentativa falhou.

Isso permite retry inteligente. Se um canal falhou por liquidez insuficiente, politica desatualizada, CLTV incorreto ou canal desativado, a carteira pode penalizar aquele trecho e tentar outra rota. Essa informacao alimenta heuristicas de pathfinding, mas nao vira verdade global sobre a rede.

Erros tambem vazam informacao para a origem. Isso e necessario para retry, mas tambem permite probing: enviar tentativas para aprender sobre liquidez e topologia privada.

Route blinding

No onion routing classico, a origem conhece todos os hops, inclusive o destino. Isso protege bastante contra intermediarios, mas nao esconde o destino da origem. Route blinding, tambem especificado na BOLT 4, permite que o recebedor forneca uma parte final da rota em forma cegada.

Em alto nivel:

  1. O recebedor escolhe um ponto de entrada publico ou alcancavel.
  2. O recebedor cria uma sequencia de hops cegados ate ele.
  3. Para cada hop cegado, o recebedor fornece encrypted_recipient_data com instrucoes cifradas.
  4. O pagador monta a rota ate o ponto de entrada e inclui os dados cegados no payload.
  5. Os hops cegados encaminham usando as instrucoes cifradas, sem revelar ao pagador a identidade real do destino final.

BOLT 12 usa esse mecanismo para offers e invoices modernas. Por isso, em BOLT 12, a privacidade do recebedor melhora: o pagador nao precisa aprender necessariamente o node id publico final.

Privacidade e limites

O onion routing protege contra um hop individual curioso, mas nao contra todos os adversarios. Alguns limites reais:

Armadilhas comuns

Resumo

Mapa de dependências conceituais

Antes de ler esta pagina, ajuda conhecer:

Depois desta pagina, siga para:

Referências técnicas usadas

A seguir: como os nós anunciam canais publicos, politicas de roteamento e identidades para formar o grafo usado na busca de caminho.