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".
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
"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:
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:
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:
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:
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".