A Rede TOR da Lightning

Onion Routing na Lightning Network

Introdução

A Lightning Network como solução de segunda camada para transações off-chain, depende da segurança e privacidade do roteamento entre múltiplos nós.

Neste contexto, o onion routing representa um componente crítico, e sua implementação na LN é baseada em uma versão adaptada do protocolo Sphinx, projetado para mensagens anônimas com proteção criptográfica forte.

Este artigo oferece uma análise técnica do funcionamento do onion routing via Sphinx na Lightning, abordando a estrutura de pacotes, os algoritmos utilizados e os mecanismos de preservação de privacidade em uma rede não confiável.

1. Fundamentos do Onion Routing

O protocolo Sphinx, núcleo do onion routing na Lightning Network, compartilha fundamentos arquitetônicos com o onion routing da rede Tor, sobretudo na ideia de privacidade por compartimentalização. Ambos utilizam camadas criptográficas empilhadas que garantem que cada nó de roteamento conheça apenas a origem imediata e o próximo salto, nunca o trajeto completo nem o conteúdo da mensagem.

O onion routing é um método de comunicação anônima em redes descentralizadas, no qual a mensagem é cifrada em múltiplas camadas, aninhadas como uma cebola, daí o nome. Cada nó da rota remove uma única camada de criptografia, obtendo instruções apenas para o próximo hop do caminho.

No entanto, há diferenças fundamentais na otimização e propósito. Tor é projetado para transmissões contínuas e de grande volume como navegação na web, enquanto Sphinx é moldado para mensagens compactas e de baixa latência, como as necessárias para pagamentos offchain. O pacote Sphinx é de tamanho fixo, sem campos visíveis reutilizáveis ou identificadores correlacionáveis, uma evolução direta sobre o modelo Tor que evita vazamento de metadados.

Outra diferença crucial está no uso de chaves efêmeras por pacote, que tornam cada onion packet criptograficamente único. Isso impede ataques de correlação temporal mesmo quando múltiplos nós são controlados por um adversário, algo que ainda representa uma vulnerabilidade relevante em circuitos Tor tradicionais.

Formalmente, um remetente S deseja enviar uma mensagem M a um destino D, através de um caminho de nós N1,N2,…,Nn​. Para garantir o sigilo:

• O remetente cifra iterativamente a mensagem M com as chaves públicas dos nós na ordem inversa:

\(C = E_{PK_{N_1}}\left( E_{PK_{N_2}}\left( \dots E_{PK_{N_n}}(M) \dots \right) \right) \)

• Cada nó Ni​ decriptografa com sua chave privada, lê as instruções e encaminha o restante.

Esse conceito básico, embora eficaz, tem limitações práticas e de eficiência para aplicações de pagamentos. A Lightning Network resolve isso com o uso do Sphinx, um protocolo mais compacto, resistente a ataques, e ideal para circuitos multi-hop de baixa latência.

2. Protocolo Sphinx

O Sphinx foi proposto em 2009 por Danezis e Goldberg como uma melhoria sobre os esquemas de onion routing tradicionais, como o usado pelo Tor. Seu design é baseado em três objetivos:

1. Compactação: o tamanho do pacote é constante, independentemente do número de saltos.

2. Indistinguibilidade: os pacotes são indistinguíveis entre si, mesmo para nós internos.

3. Replay protection: proteção contra reutilização de pacotes.

Em suma, Sphinx pode ser visto como um "Tor para pagamentos", porém mais enxuto, com camadas criptográficas minimalistas e resistência reforçada a fingerprinting e vigilância de rede.

2.1 Estrutura do Pacote Sphinx

Na Lightning, o onion packet possui tamanho fixo de 1366 bytes e é composto por três seções principais:

1. Ephemeral Public Key (33 bytes)
   Utilizada para derivar segredos compartilhados com cada nó.

2. Routing Information (~1300 bytes)
   Camadas de instruções criptografadas para cada nó, cada uma contendo:

   • ID do canal de roteamento,

   • Valor do HTLC,

   • Delta de tempo do CLTV,

   • HMAC para autenticação.

3. MAC Final (32 bytes)
   Verificação de integridade da estrutura.

Cada nó utiliza a curva secp256k1 para derivar, via Diffie-Hellman, um segredo simétrico único para descriptografar sua camada.

\(s_i = H\left( \text{ECDH}(sk_i, PK_{\text{ephemeral}}) \right) \)

Este segredo é usado para derivar chaves simétricas para cifragem, calcular HMACs e atualizar o estado criptográfico do pacote.

2.2 Algoritmos Utilizados

A segurança do Sphinx na LN baseia-se em:

1. ECDH (Elliptic Curve Diffie-Hellman):
   Gera segredos compartilhados entre o nó e o remetente.

2. ChaCha20-Poly1305:
   Cifra autenticada de fluxo usada para criptografar as instruções.

3. HMAC-SHA256:
   Usada para verificação da integridade das mensagens encaminhadas.

Este arranjo criptográfico assegura que um nó não possa distinguir sua posição na rota. Apenas o nó pretendido possa descriptografar sua seção e pacotes forjados sejam rejeitados devido a verificação de HMAC.

3. Processo de Construção e Processamento do Onion Packet

3.1 Geração do Onion pelo Remetente

Para um caminho P={N1,N2,...,Nn}, o remetente executa:

1. Geração de uma chave efêmera k;

2. Derivação de segredos si=H(ECDH(k,PKNi);

3. Derivação de chaves simétricas ρi, μi a partir de si;

4. Criação das camadas de forwarding:

   \(\text{layer}_i = E_{\rho_i} \left( \text{channel_id}_i \,\|\, \text{amount}_i \,\|\, \text{cltv}_i \,\|\, \text{hmac}_i \right) \)

5. Encapsulamento recursivo para criar o onion packet completo.

3.2 Processamento de um Nó

Ao receber um onion packet, um nó:

1. Deriva si com sua chave privada e a chave pública efêmera;

2. Deriva ρi​ , μi​;

3. Usa ρi para descriptografar sua camada e extrair dados de forwarding;

4. Usa μi​ para verificar o HMAC;

5. Atualiza o onion para o próximo nó, embaralhando os dados restantes.

Esse processamento garante que o nó saiba apenas para onde enviar o próximo pacote e não conheça o destino final nem quantos saltos restam. Ele não pode modificar os dados sem invalidar o HMAC.

4. Propriedades de Segurança

5. Limitações

A implementação Sphinx na Lightning ainda possui alguns limites:

1. Remetente conhece o destino: o caminho completo é definido pelo originador, o que compromete parcialmente a privacidade.

2. Vulnerabilidade a ataques de correlação temporal: adversários controlando múltiplos nós podem usar o tempo de chegada para inferência parcial da topologia.

A adoção de PTLCs (Point-Time Locked Contracts) é uma alternativa para fortalecer a privacidade ao remover a exposição do preimage R durante a liquidação dos pagamentos.

6. BOLT 12 e Avanços de Privacidade com Blinded Paths

O BOLT 12 representa a próxima geração de especificações da Lightning Network, com foco explícito em privacidade, reusabilidade e descentralização de identidade.

Uma das principais inovações é o blinded path, um mecanismo pelo qual o destinatário constrói os hops finais da rota, cifra essas informações e entrega ao remetente apenas um “ponto de entrada cego”. O remetente não sabe quem é o destinatário real nem quantos saltos restam, ele apenas segue as instruções cifradas do caminho cego, mantendo a lógica de onion routing mas invertendo o controle da rota.

Essa ideia se inspira nos onion services do Tor, onde o servidor esconde sua localização e identidade real atrás de múltiplos relays. Na Lightning, isso é aplicado para ocultar identidades e topologias de pagamento, além de proteger usuários contra ataques de deanonymization e vigilância financeira.

Além disso, BOLT 12 introduz invoices dinâmicos e reutilizáveis, com suporte a mensagens assíncronas e negociação de pagamento interativa, sem dependência de um servidor web externo ou IP fixo ,um salto significativo em usabilidade e descentralização, especialmente para nós móveis ou intermitentes.

Juntos, BOLT 12 e Sphinx não apenas reforçam o modelo de segurança da Lightning Network, eles consolidam sua vocação como infraestrutura para pagamentos soberanos e privados, sem compromissos com a vigilância sistêmica.

Conclusão

A adoção do protocolo Sphinx como mecanismo de roteamento na Lightning Network representa um avanço significativo na construção de uma infraestrutura de pagamentos realmente privada e resistente a vigilância. Ao combinar criptografia assimétrica (ECDH) e simétrica (ChaCha20-Poly1305) em um modelo de encapsulamento iterativo e compacto, o Sphinx oferece garantias de confidencialidade, integridade e anonimato topológico em redes descentralizadas e não confiáveis.

Sua arquitetura, otimizada para baixa latência e eficiência criptográfica, viabiliza a operação de canais multi-hop sem que os intermediários tenham visibilidade sobre remetente, destinatário ou o conteúdo dos pagamentos. Essa abordagem posiciona a Lightning Network não apenas como uma solução técnica para escalabilidade do Bitcoin, mas como um pilar na construção de sistemas financeiros resistentes a censura e ao rastreamento sistemático.

Com a introdução de especificações como o BOLT 12 e a transição para mecanismos mais avançados como PTLCs, a Lightning consolida sua vocação como uma rede de pagamentos orientada a soberania do usuário. Essas inovações ampliam ainda mais a superfície de privacidade, blindando remetentes e receptores contra observação e correlacionamento, mesmo em cenários adversos.

Diante de um cenário global em que a rastreabilidade financeira tende a ser imposta por padrões institucionais, soluções como o Sphinx aliadas a arquitetura modular e evolutiva da Lightning, emergem como fundamentos tecnológicos essenciais para a manutenção da liberdade monetária e da autonomia individual na era digital.