Les ordinateurs d'un réseau communiquent entre eux selon des protocoles. Ici, "protocole" fait référence à un système de règles spécifiant comment les messages doivent être transmis et interprétés. La partie transmission des messages de paiement du protocole Lightning Network est décrite par le BOLT#4, également connu sous le nom de "Onion Routing Protocol (Onion Routing Protocol)".
Onion Routing est une technologie qui a précédé le Lightning Network de 25 ans. Il est également utilisé dans Tor, d'où vient le nom "Tor" ("The Onion Router"). Le Lightning Network utilise une version légèrement modifiée appelée "routage d'oignon basé sur l'origine", abrégé "SPHINX". Dans cet article, nous allons parler du fonctionnement du routage en oignon.
## Pourquoi utiliser le routage en oignon ?
De nombreux protocoles de communication différents existent dans le monde, mais comme le Lightning Network est un réseau de paiement, il est logique de choisir un protocole qui révèle le moins d'informations possible sur le paiement transmis.
Si le Lightning Network utilisait le même protocole qu'Internet, chaque intermédiaire saurait qui est l'expéditeur du paiement, qui est le destinataire et qui sont les autres intermédiaires le long du chemin. Le routage oignon est un bon choix car ses caractéristiques garantissent des nœuds intermédiaires :
Ne connaissez que votre nœud précédent (qui vous a envoyé un message) et le nœud suivant (où vous souhaitez transférer le message).
ne connaît pas la longueur du chemin complet ;
Ne pas savoir où vous en êtes sur le chemin.
## Aperçu du routage des oignons
Utilisons un colis comme analogie pour expliquer le fonctionnement du routage en oignon.
Supposons qu'Alice veuille payer Dina. Tout d'abord, Alice doit trouver un chemin réalisable pour son paiement :
Alice→Bob→Chan→Dina
Ensuite, elle construit un "oignon". Elle commence par Dina (du bout du chemin). Elle met un message secret (contenu du paiement) dans un colis envoyé à Dina, et le verrouille avec une clé connue seulement d'elle et de Dina. Maintenant, elle met ce paquet dans un autre paquet à envoyer à Chan, et verrouille le paquet à Chan avec une clé connue seulement d'elle et de Chan. Exact et ainsi de suite.
Alice envoie le dernier oignon (paquet) au premier intermédiaire sur le chemin, Bob. Bob déverrouille son colis avec sa propre clé et voit que le prochain colis est pour Chan. Il a donc transmis le colis à Chan. Il en va de même pour Chan.Après avoir déballé le colis, il a transmis le colis à Dina. Enfin, Dina a ouvert son propre colis et a trouvé le message de paiement à l'intérieur.
Dans le routage en oignon, les intermédiaires comme Bob et Chan ne connaissent pas le contenu du message envoyé à Dina, ni la longueur du chemin de paiement complet. La seule chose qu'ils savent, c'est qui leur a transmis le colis et qui le recevra ensuite. Cela garantit la confidentialité du message et la confidentialité du chemin. Chaque intermédiaire ne peut toucher que la couche de messages spécialement conçus pour TA.
Dans le routage en oignon basé sur la source du Lightning Network, l'expéditeur choisit le chemin de paiement et construit un oignon complet pour ce chemin, qui peut être considéré comme un trou de confidentialité (Note du traducteur : l'emplacement réseau du destinataire doit être exposé à l'expéditeur). D'autres schémas de routage, tels que le "routage aveugle" (traduction en chinois), résolvent ce problème en masquant une partie du chemin de paiement vers l'expéditeur. Cependant, dans cet article, nous nous concentrons exclusivement sur SPHINX.
Assembler l'oignon
Examinons maintenant la spécification du routage en oignon. Au début, nous devons définir ces choses:
L'expéditeur est le « nœud initial » (Alice) ;
Le récepteur est le « nœud final » (Dina) ;
Chaque nœud intermédiaire sur le chemin de paiement est un « saut » (Bob et Chan) ;
Les informations de communication entre chaque saut sont appelées "chargement de saut".
Construire une charge de saut
Une fois qu'Alice a choisi un chemin de paiement, elle obtient les informations pour chaque canal de paiement à partir du protocole de potins pour créer la charge utile pour chaque saut, indiquant essentiellement à chaque saut comment créer le HTLC pour le paiement transmis (contrat de verrouillage de temps de hachage).
Afin d'établir un HTLC approprié, chaque saut doit :
Le montant qui doit être transféré ;
valeur secrète payée;
L'ID du canal de paiement qui continue d'envoyer des oignons ;
La durée du verrouillage horaire.
La plupart de ces données proviennent de messages de "mise à jour de canal", qui contiennent des informations sur les frais de routage, les demandes d'événement et les ID de canal de paiement. Le montant total qui doit être transmis est la somme du montant du paiement plus les frais de traitement facturés pour chaque saut ultérieur ; tandis que la valeur secrète du paiement est calculée par Dina et intégrée dans la facture de paiement (informée par le message d'oignon à chacun houblon).
Alice commence par le nœud final Dina. Elle inclut le montant du transfert, la valeur de la durée du verrouillage horaire, la valeur secrète du paiement et le montant du paiement dans le package. Notez qu'elle n'a pas besoin d'ajouter l'ID de canal, car Dina est le nœud final et n'a pas besoin de transférer le paiement aux autres.
À première vue, il semble redondant de fournir le montant du transfert, car ce montant est le même que le montant du paiement.Cependant, le paiement multivoie enverra le montant du paiement via plusieurs chemins, puis les deux valeurs ne correspondront pas.
Dans la charge utile de Chan, Alice ajoute les ID de canal de Chan et de Dina. Elle a également ajouté des montants de transfert et des valeurs de timelock. Enfin, Alice crée une charge utile pour Bob. Chan facture 100 Satoshi pour le paiement via le canal entre elle et Dina, donc Alice doit dire à Bob que le montant transféré est le paiement plus les frais de traitement. Selon le message de mise à jour du canal de Chan, la valeur du timelock a également été augmentée de 20 (en blocs). Enfin, Alice prend également en compte les frais de gestion et les exigences de verrouillage temporel de Bob, et lui donne un HTLC avec une longueur de verrouillage temporel de 700040 et une valeur de 100200 Satoshi.
Valeur secrète partagée et génération de clé
Ensuite, Alice prépare l'oignon en générant un secret partagé pour chaque saut (y compris le nœud final). Cette valeur secrète partagée peut être générée respectivement par Alice et le saut cible en multipliant sa propre clé privée avec la clé publique de l'autre partie.
Une valeur secrète partagée est nécessaire pour le routage en oignon, permettant à Alice et à chaque saut de dériver la même clé. Alice utilise ensuite ces clés pour obscurcir chaque couche de l'oignon, et ce saut utilise les clés pour éclaircir.
Pour protéger la vie privée d'Alice, elle crée une clé de session unique pour un oignon, plutôt que d'utiliser sa propre clé publique de nœud, pour dériver la valeur secrète partagée. Elle utilise cette clé de session pour le premier saut, puis, pour chaque saut suivant, Alice randomise la clé de manière déterministe en multipliant la dernière clé par un facteur aveuglant. Celles-ci sont utilisées pour créer une clé de valeur secrète partagée, que nous appelons "clés éphémères".
Bob, Chan et Dina doivent tous obtenir la même valeur secrète qu'Alice, ils doivent donc connaître la clé éphémère à utiliser dans leur session. Alice ne met que la première clé dans l'oignon pour économiser la taille du message. Chaque saut calcule la clé éphémère suivante et l'intègre dans l'oignon pour le nœud suivant. Chaque saut peut utiliser sa propre clé publique et sa propre valeur secrète partagée pour calculer le facteur d'aveuglement utilisé par Alice pour déterminer la prochaine clé éphémère.
Comme mentionné précédemment, la valeur secrète partagée sera utilisée pour générer certaines clés, et Alice et le saut correspondant peuvent utiliser ces clés pour effectuer certaines opérations sur l'oignon. Voyons ce que fait chaque touche.
Touche Rho
La clé Rho est utilisée par Alice pour chiffrer une couche d'oignon ; cela obscurcira le contenu de la charge utile afin qu'elle ne puisse pas être déchiffrée par des étrangers. Seul le propriétaire de la clé rho peut déchiffrer la charge utile. C'est ce que le nœud qui reçoit l'oignon doit faire : utiliser la valeur secrète partagée avec Alice pour dériver la clé rho, puis déchiffrer l'oignon et lire le contenu.
Mukey
Alice utilise la clé mu pour créer une somme de contrôle pour chaque charge utile. Elle passe également la somme de contrôle au houblon qui reçoit l'oignon. Ce saut, à son tour, utilise la clé mu pour générer une somme de contrôle de la charge utile reçue, en vérifiant qu'elle correspond à celle donnée par Alice. Il s'agit de vérifier l'intégrité de la charge utile, en vérifiant qu'elle n'a pas été altérée.
Touche clavier
Cette clé n'est utilisée que par Alice pour générer des données "garbage" aléatoires. Ces données font également partie de l'oignon, et cela n'a rien à voir avec la longueur du chemin de paiement, le nombre de sauts que l'oignon a passés, et cela garde l'oignon toujours de la même taille, même si certains de ses contenus ne sont pas pertinents. C'est ainsi que le routage en oignon masque la longueur du chemin, protégeant ainsi la confidentialité de l'expéditeur et du destinataire.
Une clé
Cette clé est également utilisée pour vérifier l'intégrité des données contenues dans l'oignon, mais uniquement si une erreur est renvoyée. Oui, ça s'appelle "um" parce que c'est "mu" écrit à l'envers. Dans le cas d'une erreur de paiement, le saut qui trouve l'erreur utilisera la clé um pour créer une somme de contrôle, et lorsque le nœud précédent recevra le rapport d'erreur, il utilisera également la clé um pour vérifier l'intégrité du message.
Encapsulage de la couche d'oignon
Le wrap final à l'oignon ressemble à ceci :
Alice a maintenant la charge utile pour chaque saut et la valeur secrète partagée pour chaque saut. Voyons comment Alice transforme cette information en oignon final. Elle commence par le nœud final et remonte pas à pas.
Elle crée d'abord un champ vide d'une longueur de 1300 octets, qui correspond à la longueur totale de toutes les charges utiles en oignon. Elle utilise ensuite la clé pad pour créer une chaîne aléatoire de 1300 octets de long, ce qui est inutile pour n'importe quel saut. Cette étape est effectuée pour s'assurer que chaque couche de l'oignon a la même apparence, de sorte que vous ne pouvez ni voir la longueur totale du chemin (combien de sauts), ni qui est l'expéditeur et qui est le destinataire.
Elle crée ensuite une somme de contrôle de la charge utile qui doit être utilisée et la place à la fin de la charge utile. Dans le message au nœud final, la somme de contrôle est tout à 0 pour informer Dina qu'elle est la destinataire finale de cet oignon. Après avoir ajouté la somme de contrôle à la fin de la charge utile, Alice place la charge utile (et la somme de contrôle) au début de la poubelle et supprime la partie du message entier qui dépasse 1300 octets, de sorte que le message entier fait 1300 octets de long.
Ensuite, Alice utilise la clé rho pour créer une chaîne d'octets aléatoires et utilise une opération ou exclusif (XOR) sur la charge utile en oignon obtenue à l'étape précédente pour obtenir la charge utile obscurcie. Le texte original de la charge utile peut être obtenu en utilisant l'opération XOR de cette chaîne d'octets aléatoires sur le texte obscurci (Note du traducteur : En d'autres termes, XOR est ici l'algorithme de chiffrement symétrique, et la chaîne d'octets aléatoire est la clé). L'opération XOR compare la charge utile de l'oignon à la chaîne d'octets aléatoires (générée par la clé rho) bit par bit, ne produisant un 1 que si l'un des bits de données est un 1 ; cela se traduit par une charge utile obscurcie. La chose intelligente à propos de l'opération XOR est que tant que vous obtenez la chaîne d'octets aléatoires correcte et la charge utile obscurcie, il vous suffit d'exécuter à nouveau l'opération XOR avec les deux pour obtenir la charge utile obscurcie.
Étant donné que les nœuds recevant l'oignon peuvent dériver la même clé rho, ils peuvent générer la même chaîne d'octets aléatoires qu'Alice. C'est ainsi que chaque nœud en cours de route peut démêler la confusion et lire le contenu.
Après avoir préparé l'oignon de confusion pour un saut, Alice répète les mêmes étapes pour le nœud suivant. La principale différence est qu'une fois que les oignons de Dina sont cuits, elle n'a plus besoin de générer des déchets. Elle ajoute simplement l'oignon masqué de l'étape précédente après la charge utile et la somme de contrôle utiles, et supprime tout ce qui dépasse 1300 octets.
Enfin, Alice prend l'oignon obscurci final et ajoute une somme de contrôle afin que Bob puisse vérifier l'intégrité de l'oignon. Alice ajoute ensuite la clé publique de session afin que Bob puisse utiliser cette clé publique pour calculer la valeur secrète partagée. Enfin, elle ajoute également un octet représentant la version, indiquant aux autres nœuds comment interpréter les données qu'il contient. Pour la version décrite par le BOULON #4, l'octet de version doit être 0.
oignon vers l'avant
Pour envoyer ce package onion, l'expéditeur crée un message update_add_htlc avec les champs suivants :
Channel ID : Le canal spécifique auquel ce message se rapporte.
ID : L'identifiant de ce HTLC.
Montant : La valeur de ce HTLC.
Hachage de paiement : créé par le destinataire du paiement.
Délai d'expiration : ce HTLC expirera après un certain blocage.
Colis d'oignon : L'oignon créé pour ce paiement, qui est ce qui a été mentionné ci-dessus.
Données supplémentaires : utilisé pour spécifier des données supplémentaires.
Après avoir préparé le message, Alice envoie le message à Bob. Après avoir reçu le message, Bob peut commencer à décoder son propre oignon. Il obtient d'abord la clé de session du wrapper onion et l'utilise pour dériver la valeur du secret partagé avec Alice.
Armé de la valeur secrète partagée, Bob génère la clé mu pour vérifier la somme de contrôle de la charge utile intégrée dans le package onion. Si la charge utile n'a pas été falsifiée, les sommes de contrôle doivent correspondre.
Pour empêcher les autres nœuds du chemin de connaître la longueur du chemin, Bob ajoute un champ de 1300 octets rempli de zéros au paquet oignon. Bob génère ensuite une chaîne d'octets aléatoires longue de 2600 octets à partir de la clé rho. Bob utilise cette chaîne d'octets aléatoires pour XOR la charge utile d'oignon remplie de zéros.
Rappelez-vous comment je vous ai parlé des charges d'oignons confuses ? Utilisez la charge utile de l'oignon obscurci comme entrée et exécutez l'opération "XOR" avec la même chaîne d'octets pour obtenir la charge utile de l'oignon avant l'obscurcissement. Étant donné qu'Alice et Bob utilisent la même valeur secrète partagée, générant la même clé rho, Bob peut désobscurcir. Cela a l'avantage supplémentaire de transformer les caractères de remplissage longs de 1300 octets en octets aléatoires.
La charge utile non masquée de Bob comprend les données de charge utile pour son saut ainsi qu'une empreinte digitale. Bob enregistre cette empreinte digitale afin qu'il puisse l'ajouter au paquet d'oignons qu'il envoie à Chan. Après que Bob ait séparé sa propre charge utile du message onion, il reconvertit le paquet onion à sa taille d'origine de 1300 octets et randomise sa clé de session comme l'a fait Alice. Enfin, Bob ajoute l'octet de version, la clé de session et l'empreinte digitale qu'il a l'intention de mettre dans la charge utile onion, et transmet le paquet onion à Chan via un message update_add_htlc.
Ce processus se poursuivra jusqu'à ce que le message soit envoyé au nœud final, Dina. Lorsque Dina reçoit le message update_add_htlc, elle peut entrer la valeur de hachage de la valeur secrète générée par elle-même, ce qui signifie que ce HTLC lui est destiné. Donc, Dina a juste besoin de vérifier les empreintes digitales, de démêler les messages d'oignon et de révéler sa propre charge utile.
Dépannage
Nous parlons d'une réussite, un cas où tout s'est déroulé comme prévu, mais si quelque chose ne va pas en cours de route, vous devez renvoyer un message tout au long du chemin pour informer tous les nœuds que quelque chose s'est mal passé. Ce processus est similaire au routage régulier des oignons. Repérer un nœud défectueux nécessite de dériver la clé um de la valeur secrète partagée, de l'utiliser pour générer une chaîne d'octets aléatoire et d'utiliser une opération XOR pour obscurcir le colis d'oignon renvoyé.
Un nœud qui trouve une erreur renverra un message au nœud précédent dans le chemin de paiement. Chaque saut utilise la clé um et la clé ammag pour effectuer la même opération jusqu'à ce que l'expéditeur reçoive le colis. Enfin, l'expéditeur utilise la clé ammag et la clé um pour démasquer et vérifier le colis.
Les erreurs peuvent être causées par des paquets d'oignons, des nœuds ou des canaux. Si vous utilisez beaucoup le Lightning Network, vous avez peut-être rencontré des erreurs telles que "canal indisponible" ou "pas assez de frais".
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
"Onion Routing" dans le Lightning Network et son fonctionnement
Auteur : LORENZO
Les ordinateurs d'un réseau communiquent entre eux selon des protocoles. Ici, "protocole" fait référence à un système de règles spécifiant comment les messages doivent être transmis et interprétés. La partie transmission des messages de paiement du protocole Lightning Network est décrite par le BOLT#4, également connu sous le nom de "Onion Routing Protocol (Onion Routing Protocol)".
Onion Routing est une technologie qui a précédé le Lightning Network de 25 ans. Il est également utilisé dans Tor, d'où vient le nom "Tor" ("The Onion Router"). Le Lightning Network utilise une version légèrement modifiée appelée "routage d'oignon basé sur l'origine", abrégé "SPHINX". Dans cet article, nous allons parler du fonctionnement du routage en oignon.
## Pourquoi utiliser le routage en oignon ?
De nombreux protocoles de communication différents existent dans le monde, mais comme le Lightning Network est un réseau de paiement, il est logique de choisir un protocole qui révèle le moins d'informations possible sur le paiement transmis.
Si le Lightning Network utilisait le même protocole qu'Internet, chaque intermédiaire saurait qui est l'expéditeur du paiement, qui est le destinataire et qui sont les autres intermédiaires le long du chemin. Le routage oignon est un bon choix car ses caractéristiques garantissent des nœuds intermédiaires :
## Aperçu du routage des oignons
Utilisons un colis comme analogie pour expliquer le fonctionnement du routage en oignon.
Supposons qu'Alice veuille payer Dina. Tout d'abord, Alice doit trouver un chemin réalisable pour son paiement :
Alice→Bob→Chan→Dina
Ensuite, elle construit un "oignon". Elle commence par Dina (du bout du chemin). Elle met un message secret (contenu du paiement) dans un colis envoyé à Dina, et le verrouille avec une clé connue seulement d'elle et de Dina. Maintenant, elle met ce paquet dans un autre paquet à envoyer à Chan, et verrouille le paquet à Chan avec une clé connue seulement d'elle et de Chan. Exact et ainsi de suite.
Alice envoie le dernier oignon (paquet) au premier intermédiaire sur le chemin, Bob. Bob déverrouille son colis avec sa propre clé et voit que le prochain colis est pour Chan. Il a donc transmis le colis à Chan. Il en va de même pour Chan.Après avoir déballé le colis, il a transmis le colis à Dina. Enfin, Dina a ouvert son propre colis et a trouvé le message de paiement à l'intérieur.
Dans le routage en oignon, les intermédiaires comme Bob et Chan ne connaissent pas le contenu du message envoyé à Dina, ni la longueur du chemin de paiement complet. La seule chose qu'ils savent, c'est qui leur a transmis le colis et qui le recevra ensuite. Cela garantit la confidentialité du message et la confidentialité du chemin. Chaque intermédiaire ne peut toucher que la couche de messages spécialement conçus pour TA.
Dans le routage en oignon basé sur la source du Lightning Network, l'expéditeur choisit le chemin de paiement et construit un oignon complet pour ce chemin, qui peut être considéré comme un trou de confidentialité (Note du traducteur : l'emplacement réseau du destinataire doit être exposé à l'expéditeur). D'autres schémas de routage, tels que le "routage aveugle" (traduction en chinois), résolvent ce problème en masquant une partie du chemin de paiement vers l'expéditeur. Cependant, dans cet article, nous nous concentrons exclusivement sur SPHINX.
Assembler l'oignon
Examinons maintenant la spécification du routage en oignon. Au début, nous devons définir ces choses:
Construire une charge de saut
Une fois qu'Alice a choisi un chemin de paiement, elle obtient les informations pour chaque canal de paiement à partir du protocole de potins pour créer la charge utile pour chaque saut, indiquant essentiellement à chaque saut comment créer le HTLC pour le paiement transmis (contrat de verrouillage de temps de hachage).
Afin d'établir un HTLC approprié, chaque saut doit :
La plupart de ces données proviennent de messages de "mise à jour de canal", qui contiennent des informations sur les frais de routage, les demandes d'événement et les ID de canal de paiement. Le montant total qui doit être transmis est la somme du montant du paiement plus les frais de traitement facturés pour chaque saut ultérieur ; tandis que la valeur secrète du paiement est calculée par Dina et intégrée dans la facture de paiement (informée par le message d'oignon à chacun houblon).
Alice commence par le nœud final Dina. Elle inclut le montant du transfert, la valeur de la durée du verrouillage horaire, la valeur secrète du paiement et le montant du paiement dans le package. Notez qu'elle n'a pas besoin d'ajouter l'ID de canal, car Dina est le nœud final et n'a pas besoin de transférer le paiement aux autres.
À première vue, il semble redondant de fournir le montant du transfert, car ce montant est le même que le montant du paiement.Cependant, le paiement multivoie enverra le montant du paiement via plusieurs chemins, puis les deux valeurs ne correspondront pas.
Dans la charge utile de Chan, Alice ajoute les ID de canal de Chan et de Dina. Elle a également ajouté des montants de transfert et des valeurs de timelock. Enfin, Alice crée une charge utile pour Bob. Chan facture 100 Satoshi pour le paiement via le canal entre elle et Dina, donc Alice doit dire à Bob que le montant transféré est le paiement plus les frais de traitement. Selon le message de mise à jour du canal de Chan, la valeur du timelock a également été augmentée de 20 (en blocs). Enfin, Alice prend également en compte les frais de gestion et les exigences de verrouillage temporel de Bob, et lui donne un HTLC avec une longueur de verrouillage temporel de 700040 et une valeur de 100200 Satoshi.
Valeur secrète partagée et génération de clé
Ensuite, Alice prépare l'oignon en générant un secret partagé pour chaque saut (y compris le nœud final). Cette valeur secrète partagée peut être générée respectivement par Alice et le saut cible en multipliant sa propre clé privée avec la clé publique de l'autre partie.
Une valeur secrète partagée est nécessaire pour le routage en oignon, permettant à Alice et à chaque saut de dériver la même clé. Alice utilise ensuite ces clés pour obscurcir chaque couche de l'oignon, et ce saut utilise les clés pour éclaircir.
Pour protéger la vie privée d'Alice, elle crée une clé de session unique pour un oignon, plutôt que d'utiliser sa propre clé publique de nœud, pour dériver la valeur secrète partagée. Elle utilise cette clé de session pour le premier saut, puis, pour chaque saut suivant, Alice randomise la clé de manière déterministe en multipliant la dernière clé par un facteur aveuglant. Celles-ci sont utilisées pour créer une clé de valeur secrète partagée, que nous appelons "clés éphémères".
Bob, Chan et Dina doivent tous obtenir la même valeur secrète qu'Alice, ils doivent donc connaître la clé éphémère à utiliser dans leur session. Alice ne met que la première clé dans l'oignon pour économiser la taille du message. Chaque saut calcule la clé éphémère suivante et l'intègre dans l'oignon pour le nœud suivant. Chaque saut peut utiliser sa propre clé publique et sa propre valeur secrète partagée pour calculer le facteur d'aveuglement utilisé par Alice pour déterminer la prochaine clé éphémère.
Comme mentionné précédemment, la valeur secrète partagée sera utilisée pour générer certaines clés, et Alice et le saut correspondant peuvent utiliser ces clés pour effectuer certaines opérations sur l'oignon. Voyons ce que fait chaque touche.
Touche Rho
La clé Rho est utilisée par Alice pour chiffrer une couche d'oignon ; cela obscurcira le contenu de la charge utile afin qu'elle ne puisse pas être déchiffrée par des étrangers. Seul le propriétaire de la clé rho peut déchiffrer la charge utile. C'est ce que le nœud qui reçoit l'oignon doit faire : utiliser la valeur secrète partagée avec Alice pour dériver la clé rho, puis déchiffrer l'oignon et lire le contenu.
Mukey
Alice utilise la clé mu pour créer une somme de contrôle pour chaque charge utile. Elle passe également la somme de contrôle au houblon qui reçoit l'oignon. Ce saut, à son tour, utilise la clé mu pour générer une somme de contrôle de la charge utile reçue, en vérifiant qu'elle correspond à celle donnée par Alice. Il s'agit de vérifier l'intégrité de la charge utile, en vérifiant qu'elle n'a pas été altérée.
Touche clavier
Cette clé n'est utilisée que par Alice pour générer des données "garbage" aléatoires. Ces données font également partie de l'oignon, et cela n'a rien à voir avec la longueur du chemin de paiement, le nombre de sauts que l'oignon a passés, et cela garde l'oignon toujours de la même taille, même si certains de ses contenus ne sont pas pertinents. C'est ainsi que le routage en oignon masque la longueur du chemin, protégeant ainsi la confidentialité de l'expéditeur et du destinataire.
Une clé
Cette clé est également utilisée pour vérifier l'intégrité des données contenues dans l'oignon, mais uniquement si une erreur est renvoyée. Oui, ça s'appelle "um" parce que c'est "mu" écrit à l'envers. Dans le cas d'une erreur de paiement, le saut qui trouve l'erreur utilisera la clé um pour créer une somme de contrôle, et lorsque le nœud précédent recevra le rapport d'erreur, il utilisera également la clé um pour vérifier l'intégrité du message.
Encapsulage de la couche d'oignon
Le wrap final à l'oignon ressemble à ceci :
Alice a maintenant la charge utile pour chaque saut et la valeur secrète partagée pour chaque saut. Voyons comment Alice transforme cette information en oignon final. Elle commence par le nœud final et remonte pas à pas.
Elle crée d'abord un champ vide d'une longueur de 1300 octets, qui correspond à la longueur totale de toutes les charges utiles en oignon. Elle utilise ensuite la clé pad pour créer une chaîne aléatoire de 1300 octets de long, ce qui est inutile pour n'importe quel saut. Cette étape est effectuée pour s'assurer que chaque couche de l'oignon a la même apparence, de sorte que vous ne pouvez ni voir la longueur totale du chemin (combien de sauts), ni qui est l'expéditeur et qui est le destinataire.
Elle crée ensuite une somme de contrôle de la charge utile qui doit être utilisée et la place à la fin de la charge utile. Dans le message au nœud final, la somme de contrôle est tout à 0 pour informer Dina qu'elle est la destinataire finale de cet oignon. Après avoir ajouté la somme de contrôle à la fin de la charge utile, Alice place la charge utile (et la somme de contrôle) au début de la poubelle et supprime la partie du message entier qui dépasse 1300 octets, de sorte que le message entier fait 1300 octets de long.
Ensuite, Alice utilise la clé rho pour créer une chaîne d'octets aléatoires et utilise une opération ou exclusif (XOR) sur la charge utile en oignon obtenue à l'étape précédente pour obtenir la charge utile obscurcie. Le texte original de la charge utile peut être obtenu en utilisant l'opération XOR de cette chaîne d'octets aléatoires sur le texte obscurci (Note du traducteur : En d'autres termes, XOR est ici l'algorithme de chiffrement symétrique, et la chaîne d'octets aléatoire est la clé). L'opération XOR compare la charge utile de l'oignon à la chaîne d'octets aléatoires (générée par la clé rho) bit par bit, ne produisant un 1 que si l'un des bits de données est un 1 ; cela se traduit par une charge utile obscurcie. La chose intelligente à propos de l'opération XOR est que tant que vous obtenez la chaîne d'octets aléatoires correcte et la charge utile obscurcie, il vous suffit d'exécuter à nouveau l'opération XOR avec les deux pour obtenir la charge utile obscurcie.
Étant donné que les nœuds recevant l'oignon peuvent dériver la même clé rho, ils peuvent générer la même chaîne d'octets aléatoires qu'Alice. C'est ainsi que chaque nœud en cours de route peut démêler la confusion et lire le contenu.
Après avoir préparé l'oignon de confusion pour un saut, Alice répète les mêmes étapes pour le nœud suivant. La principale différence est qu'une fois que les oignons de Dina sont cuits, elle n'a plus besoin de générer des déchets. Elle ajoute simplement l'oignon masqué de l'étape précédente après la charge utile et la somme de contrôle utiles, et supprime tout ce qui dépasse 1300 octets.
Enfin, Alice prend l'oignon obscurci final et ajoute une somme de contrôle afin que Bob puisse vérifier l'intégrité de l'oignon. Alice ajoute ensuite la clé publique de session afin que Bob puisse utiliser cette clé publique pour calculer la valeur secrète partagée. Enfin, elle ajoute également un octet représentant la version, indiquant aux autres nœuds comment interpréter les données qu'il contient. Pour la version décrite par le BOULON #4, l'octet de version doit être 0.
oignon vers l'avant
Pour envoyer ce package onion, l'expéditeur crée un message update_add_htlc avec les champs suivants :
Après avoir préparé le message, Alice envoie le message à Bob. Après avoir reçu le message, Bob peut commencer à décoder son propre oignon. Il obtient d'abord la clé de session du wrapper onion et l'utilise pour dériver la valeur du secret partagé avec Alice.
Armé de la valeur secrète partagée, Bob génère la clé mu pour vérifier la somme de contrôle de la charge utile intégrée dans le package onion. Si la charge utile n'a pas été falsifiée, les sommes de contrôle doivent correspondre.
Pour empêcher les autres nœuds du chemin de connaître la longueur du chemin, Bob ajoute un champ de 1300 octets rempli de zéros au paquet oignon. Bob génère ensuite une chaîne d'octets aléatoires longue de 2600 octets à partir de la clé rho. Bob utilise cette chaîne d'octets aléatoires pour XOR la charge utile d'oignon remplie de zéros.
Rappelez-vous comment je vous ai parlé des charges d'oignons confuses ? Utilisez la charge utile de l'oignon obscurci comme entrée et exécutez l'opération "XOR" avec la même chaîne d'octets pour obtenir la charge utile de l'oignon avant l'obscurcissement. Étant donné qu'Alice et Bob utilisent la même valeur secrète partagée, générant la même clé rho, Bob peut désobscurcir. Cela a l'avantage supplémentaire de transformer les caractères de remplissage longs de 1300 octets en octets aléatoires.
La charge utile non masquée de Bob comprend les données de charge utile pour son saut ainsi qu'une empreinte digitale. Bob enregistre cette empreinte digitale afin qu'il puisse l'ajouter au paquet d'oignons qu'il envoie à Chan. Après que Bob ait séparé sa propre charge utile du message onion, il reconvertit le paquet onion à sa taille d'origine de 1300 octets et randomise sa clé de session comme l'a fait Alice. Enfin, Bob ajoute l'octet de version, la clé de session et l'empreinte digitale qu'il a l'intention de mettre dans la charge utile onion, et transmet le paquet onion à Chan via un message update_add_htlc.
Ce processus se poursuivra jusqu'à ce que le message soit envoyé au nœud final, Dina. Lorsque Dina reçoit le message update_add_htlc, elle peut entrer la valeur de hachage de la valeur secrète générée par elle-même, ce qui signifie que ce HTLC lui est destiné. Donc, Dina a juste besoin de vérifier les empreintes digitales, de démêler les messages d'oignon et de révéler sa propre charge utile.
Dépannage
Nous parlons d'une réussite, un cas où tout s'est déroulé comme prévu, mais si quelque chose ne va pas en cours de route, vous devez renvoyer un message tout au long du chemin pour informer tous les nœuds que quelque chose s'est mal passé. Ce processus est similaire au routage régulier des oignons. Repérer un nœud défectueux nécessite de dériver la clé um de la valeur secrète partagée, de l'utiliser pour générer une chaîne d'octets aléatoire et d'utiliser une opération XOR pour obscurcir le colis d'oignon renvoyé.
Un nœud qui trouve une erreur renverra un message au nœud précédent dans le chemin de paiement. Chaque saut utilise la clé um et la clé ammag pour effectuer la même opération jusqu'à ce que l'expéditeur reçoive le colis. Enfin, l'expéditeur utilise la clé ammag et la clé um pour démasquer et vérifier le colis.
Les erreurs peuvent être causées par des paquets d'oignons, des nœuds ou des canaux. Si vous utilisez beaucoup le Lightning Network, vous avez peut-être rencontré des erreurs telles que "canal indisponible" ou "pas assez de frais".