"Onion Routing" na Lightning Network e como funciona

Autor: LORENZO

Os computadores em uma rede se comunicam uns com os outros de acordo com protocolos. Aqui, "protocolo" refere-se a um sistema de regras que especifica como as mensagens devem ser transmitidas e interpretadas. A parte de transmissão da mensagem de pagamento do protocolo Lightning Network é descrita pelo BOLT#4, também conhecido como "Onion Routing Protocol (Onion Routing Protocol)".

Onion Routing é uma tecnologia que antecedeu a Lightning Network em 25 anos. Também é usado no Tor, de onde vem o nome "Tor" ("The Onion Router"). A Lightning Network usa uma versão ligeiramente modificada chamada "roteamento de cebola baseado em origem", abreviado como "SPHINX". Neste artigo, falaremos sobre como funciona o roteamento de cebola.

###Por que usar roteamento de cebola?

Existem muitos protocolos de comunicação diferentes no mundo, mas como a Lightning Network é uma rede de pagamento, faz sentido escolher um protocolo que revele o mínimo possível de informações sobre o pagamento que está sendo encaminhado.

Se a Lightning Network usasse o mesmo protocolo da Internet, todos os intermediários saberiam quem era o remetente do pagamento, quem era o destinatário e quem eram os outros intermediários ao longo do caminho. O roteamento Onion é uma boa escolha porque suas características garantem nós intermediários:

• Conheça apenas o seu nó anterior (quem lhe enviou uma mensagem) e o próximo nó (para onde pretende reencaminhar a mensagem).
• não conhece o comprimento de todo o caminho;
• Não saber onde você está no caminho.

###Visão geral do roteamento de cebola

Vamos usar um pacote como analogia para explicar como funciona o roteamento de cebola.

Suponha que Alice queira pagar Dina. Primeiro, Alice precisa encontrar um caminho viável para seu pagamento:

Alice→Bob→Chan→Dina

Então, ela constrói uma "cebola". Ela começa com Dina (do final do caminho). Ela coloca uma mensagem secreta (conteúdo de pagamento) em um pacote enviado a Dina e o tranca com uma chave conhecida apenas por ela e Dina. Agora, ela coloca este pacote em outro pacote para ser enviado a Chan e tranca o pacote para Chan com uma chave conhecida apenas por ela e Chan. Certo e assim por diante.

Alice envia a cebola final (pacote) para o primeiro intermediário no caminho, Bob. Bob destranca seu pacote com sua própria chave e vê que o próximo pacote é para Chan. Então ele encaminhou o pacote para Chan. O mesmo vale para Chan. Depois de desempacotar o pacote, ele encaminhou o pacote para Dina. Finalmente, Dina abriu seu próprio pacote e encontrou a mensagem de pagamento dentro.

No roteamento cebola, intermediários como Bob e Chan não conhecem o conteúdo da mensagem para Dina, nem a duração de todo o caminho de pagamento. A única coisa que eles sabem é quem encaminhou o pacote para eles e quem o receberá em seguida. Isso garante a privacidade da mensagem e a confidencialidade do caminho. Cada intermediário só pode tocar na camada de mensagens feitas especialmente para o TA.

No roteamento de cebola baseado na fonte da Lightning Network, o remetente escolhe o caminho de pagamento e constrói uma cebola completa para esse caminho, que pode ser visto como uma falha de privacidade (Nota do tradutor: o local de rede do destinatário deve ser exposto ao remetente). Outros esquemas de roteamento, como "roteamento cego" (tradução chinesa), resolvem esse problema ofuscando parte do caminho de pagamento para o remetente. No entanto, neste artigo, nos concentramos exclusivamente no SPHINX.

###Monte a cebola

Agora, vamos dar uma olhada na especificação do roteamento cebola. No começo, precisamos definir estas coisas:

• O remetente é o "nó inicial" (Alice);
• O receptor é o "nó final" (Dina);
• Cada nó intermediário no caminho de pagamento é um "salto" (Bob e Chan);
• As informações de comunicação entre cada salto são chamadas de "carga de salto".

####Construir carga de salto

Uma vez que Alice tenha escolhido um caminho de pagamento, ela obtém as informações para cada canal de pagamento do protocolo gossip para criar a carga útil para cada salto, essencialmente informando a cada salto como criar o HTLC para o pagamento que está sendo encaminhado (contrato de hash timelock).

Para estabelecer um HTLC adequado, cada salto precisa:

• O valor que precisa ser encaminhado;
• valor secreto pago;
• O ID do canal de pagamento que continua enviando cebolas;
• A duração do bloqueio de tempo.

A maioria desses dados vem de mensagens de "atualização de canal", que contêm informações sobre taxas de roteamento, solicitações de eventos e IDs de canais de pagamento. O valor total que precisa ser encaminhado é a soma do valor pago mais a taxa cobrada a cada salto subseqüente; enquanto o valor secreto do pagamento é calculado pela Dina e embutido na fatura de pagamento (informada pela mensagem onion a cada um saltar).

Alice começa com o nó final Dina. Ela inclui valor de encaminhamento, valor de tempo de bloqueio, valor de segredo de pagamento e valor de pagamento no pacote. Observe que ela não precisa adicionar o ID do canal, pois Dina é o nó final e não precisa encaminhar o pagamento para outros.

À primeira vista, parece redundante fornecer o valor do encaminhamento, porque esse valor é o mesmo que o valor do pagamento. No entanto, o pagamento multipath enviará o valor do pagamento por vários caminhos e, em seguida, os dois valores não serão correspondentes.

Na carga útil de Chan, Alice adiciona os IDs de canal de Chan e Dina. Ela também adicionou valores de encaminhamento e valores de timelock. Por fim, Alice cria uma carga útil para Bob. Chan cobra 100 Satoshi pelo pagamento através do canal entre ela e Dina, então Alice precisa dizer a Bob que o valor encaminhado é o pagamento mais a taxa de manuseio. De acordo com a mensagem de atualização do canal de Chan, o valor do timelock também foi aumentado em 20 (em blocos). Por fim, Alice também considera a taxa de manuseio de Bob e os requisitos de bloqueio de tempo e fornece a ele um HTLC com um comprimento de bloqueio de tempo de 700040 e um valor de 100200 Satoshi.

####Valor secreto compartilhado e geração de chave

Em seguida, Alice prepara a cebola gerando um segredo compartilhado para cada salto (incluindo o nó final). Esse valor secreto compartilhado pode ser gerado por Alice e pelo salto de destino, respectivamente, multiplicando sua própria chave privada pela chave pública da outra parte.

Um valor secreto compartilhado é necessário para roteamento de cebola, permitindo que Alice e cada salto obtenham a mesma chave. Alice então usa essas chaves para ofuscar cada camada da cebola, e esse salto usa as chaves para desofuscar.

Para proteger a privacidade de Alice, ela cria uma chave de sessão única para uma cebola, em vez de usar sua própria chave pública de nó, para derivar o valor do segredo compartilhado. Ela usa essa chave de sessão para o primeiro salto e, em seguida, para cada salto subsequente, Alice torna a chave aleatória de forma determinística multiplicando a chave mais recente por um fator de cegueira. Elas são usadas para criar uma chave de valor secreta compartilhada, que chamamos de "chaves efêmeras".

Bob, Chan e Dina precisam obter o mesmo valor secreto que Alice, então eles precisam saber a chave efêmera para usar em sua sessão. Alice apenas coloca a primeira chave na cebola para economizar o tamanho da mensagem. Cada salto calcula a próxima chave efêmera e a incorpora na cebola para o próximo nó. Cada salto pode usar sua própria chave pública e valor secreto compartilhado para calcular o fator de cegueira usado por Alice para determinar a próxima chave efêmera.

Conforme mencionado anteriormente, o valor do segredo compartilhado será usado para gerar algumas chaves, e Alice e o salto correspondente podem usar essas chaves para realizar algumas operações na cebola. Vamos dar uma olhada no que cada tecla faz.

Chave Rho

A chave Rho é usada por Alice para criptografar uma camada de cebola; isso ofuscará o conteúdo da carga útil para que não possa ser decifrado por estranhos. Somente o proprietário da chave rho pode descriptografar a carga útil. É isso que o nó que recebe a cebola deve fazer: usar o valor do segredo compartilhado com Alice para derivar a chave rho, então descriptografar a cebola e ler o conteúdo.

Mukey

Alice usa a tecla mu para criar uma soma de verificação para cada carga útil. Ela também passa a soma de verificação para o salto que recebe a cebola. Este salto, por sua vez, usa a tecla mu para gerar um checksum do payload recebido, verificando se ele corresponde ao dado por Alice. Isso é para verificar a integridade da carga útil, verificando se ela não foi adulterada.

Tecla do teclado

Essa chave é usada apenas por Alice para gerar dados "lixo" aleatórios. Esses dados também fazem parte da cebola, e não tem nada a ver com o comprimento do caminho de pagamento, quantos saltos a cebola passou e mantém a cebola sempre do mesmo tamanho, mesmo que alguns de seus conteúdos sejam irrelevantes. É assim que o roteamento de cebola oculta o comprimento do caminho, protegendo de fato a privacidade do remetente e do destinatário.

Um key

Essa chave também é usada para verificar a integridade dos dados contidos na cebola, mas somente se um erro for retornado. Sim, é chamado de "um" porque é "mu" escrito ao contrário. No caso de um erro de pagamento, o salto que encontrar o erro usará a chave um para criar um checksum, e quando o nó anterior receber o relatório de erro, ele também usará a chave um para verificar a integridade da mensagem.

####Encapsulando a camada de cebola

O wrap final de cebola fica assim:

Alice agora tem a carga para cada salto e o valor secreto compartilhado para cada salto. Vamos ver como Alice transforma essa informação na cebola final. Ela começa com o nó final e volta passo a passo.

Ela primeiro cria um campo vazio com um comprimento de 1300 bytes, que é o comprimento total de todas as cargas de cebola. Ela então usa a tecla do teclado para criar uma string aleatória de 1300 bytes de comprimento, que é um lixo inútil para qualquer salto. Esta etapa é feita para garantir que cada camada da cebola tenha a mesma aparência, para que você não possa ver o comprimento total do caminho (quantos saltos), nem quem é o remetente e quem é o destinatário.

Ela então cria uma soma de verificação da carga útil que precisa ser usada e a coloca no final da carga útil. Na mensagem para o nó final, a soma de verificação é 0 para informar a Dina que ela é a destinatária final desta cebola. Depois de adicionar o checksum ao final do payload, Alice coloca o payload (e o checksum) no início do lixo e exclui a parte de toda a mensagem que excede 1300 bytes, de modo que toda a mensagem tenha 1300 bytes de comprimento.

Em seguida, Alice usa a chave rho para criar uma cadeia de bytes aleatórios e usa uma operação de ou exclusivo (XOR) na carga de cebola obtida na etapa anterior para obter a carga ofuscada. O texto original da carga útil pode ser obtido usando a operação XOR dessa sequência de bytes aleatórios no texto ofuscado (Nota do tradutor: em outras palavras, XOR aqui é o algoritmo de criptografia simétrica e a sequência de bytes aleatórios é a chave). A operação XOR compara a carga útil da cebola com a string de bytes aleatórios (gerada pela tecla rho) bit a bit, gerando 1 somente se um dos bits de dados for 1; isso resulta em uma carga ofuscada. O mais inteligente sobre a operação XOR é que, desde que você obtenha a string de bytes aleatórios correta e a carga ofuscada, você só precisa executar a operação XOR com os dois novamente para obter a carga ofuscada.

Como os nós que recebem a cebola podem derivar a mesma chave rho, eles podem gerar a mesma sequência de bytes aleatórios que Alice. É assim que cada nó ao longo do caminho pode desvendar a confusão e ler o conteúdo.

Depois de preparar a cebola confusa para um salto, Alice repete os mesmos passos para o próximo nó. A principal diferença é que uma vez que as cebolas de Dina estão prontas, ela não precisa mais gerar lixo. Ela apenas acrescenta a cebola ofuscada da etapa anterior após a carga útil e a soma de verificação e corta qualquer coisa acima de 1300 bytes.

Por fim, Alice pega a cebola ofuscada final e adiciona uma soma de verificação para que Bob possa verificar a integridade dessa cebola. Alice então adiciona a chave pública da sessão para que Bob possa usar essa chave pública para calcular o valor do segredo compartilhado. Por fim, ela também adiciona um byte representando a versão, informando aos outros nós como interpretar os dados nele contidos. Para a versão descrita pelo PARAFUSO #4, o byte da versão deve ser 0.

cebola para a frente

Para enviar este pacote onion, o remetente cria uma mensagem update_add_htlc com os seguintes campos:

• ID do canal: O canal específico ao qual esta mensagem se refere.
• ID: O identificador deste HTLC.
• Valor: O valor deste HTLC.
• Hash de Pagamento: Criado pelo destinatário do pagamento.
• Tempo de expiração: Este HTLC irá expirar após um determinado bloqueio.
• Onion Parcel: A cebola criada para este pagamento, que é o que foi mencionado acima.
• Dados adicionais: usados para especificar dados adicionais.

Depois de preparar a mensagem, Alice envia a mensagem para Bob. Depois de receber a mensagem, Bob pode começar a decodificar sua própria cebola. Ele primeiro obtém a chave de sessão do wrapper de cebola e a usa para derivar o valor do segredo compartilhado com Alice.

Armado com o valor do segredo compartilhado, Bob gera a chave mu para verificar a soma de verificação da carga incorporada no pacote onion. Se a carga útil não foi adulterada, as somas de verificação devem corresponder.

Para evitar que outros nós no caminho saibam quanto é o caminho, Bob adiciona um campo de 1300 bytes preenchido com zeros ao pacote de cebola. Bob então gera uma string de bytes aleatórios de 2600 bytes a partir da chave rho. Bob usa essa sequência de bytes aleatórios para XOR da carga de cebola preenchida com zero.

Lembra como eu falei sobre confundir cargas de cebola? Use a carga de cebola ofuscada como entrada e execute a operação "XOR" com a mesma string de bytes para obter a carga de cebola antes da ofuscação. Como Alice e Bob usam o mesmo valor secreto compartilhado, gerando a mesma chave rho, Bob pode desofuscar. Isso tem o bônus adicional de transformar os caracteres de preenchimento de 1300 bytes em bytes aleatórios.

A carga útil não ofuscada de Bob inclui os dados da carga útil de seu salto junto com uma impressão digital. Bob salva essa impressão digital para poder adicioná-la ao pacote de cebola que envia a Chan. Depois que Bob separa sua própria carga útil da mensagem onion, ele converte o pacote onion de volta ao seu tamanho original de 1300 bytes e randomiza sua chave de sessão como Alice fez. Por fim, Bob adiciona os bytes de versão, a chave de sessão e a impressão digital que ele pretende colocar na carga cebola e encaminha o pacote cebola para Chan por meio de uma mensagem update_add_htlc.

Este processo continuará até que a mensagem seja enviada para o nó final, Dina. Quando Dina recebe a mensagem update_add_htlc, ela pode inserir o valor hash do valor secreto gerado por ela, o que significa que este HTLC é destinado a ela. Então Dina só precisa verificar as impressões digitais, desvendar as mensagens de cebola e revelar sua própria carga.

###Solução de problemas

Estamos falando de uma história de sucesso, um caso em que tudo correu conforme o planejado, mas se algo der errado no meio do caminho, você deve enviar uma mensagem de volta para avisar todos os nós de que algo deu errado. Esse processo é semelhante ao roteamento de cebola regular. Detectar um nó defeituoso requer derivar a chave um do valor do segredo compartilhado, usá-la para gerar uma cadeia de bytes aleatórios e usar uma operação XOR para ofuscar o pacote de cebola retornado.

Um nó que encontra um erro enviará uma mensagem de volta ao nó anterior no caminho de pagamento. Cada salto usa a tecla um e a tecla ammag para fazer a mesma operação até que o remetente receba o pacote. Por fim, o remetente usa a chave ammag e a chave um para não ofuscar e verificar o pacote.

Os erros podem ser causados por pacotes de cebola, nós ou canais. Se você usa muito a Lightning Network, pode ter encontrado erros como "canal indisponível" ou "taxas insuficientes".