Routage en oignon

Chaque paiement Lightning voyage dans un paquet de 1 366 octets de taille fixe dont les couches sont retirées une par une, si bien qu'un nœud de transfert ne connaît que son prédécesseur et son successeur, rien de plus. Le paquet garde la même taille à chaque saut, ce qui dissimule la longueur de la route et votre position dans celle-ci. Votre confidentialité face aux inconnus situés au milieu est forte ; face au portefeuille ou à la plateforme d'échange à chaque extrémité, elle ne l'est pas.

Comment cela fonctionne

Le routage en oignon chiffre la route par couches, une par saut, enveloppées dans l'ordre inverse, de sorte que retirer la couche la plus externe est la seule opération que puisse effectuer un nœud.

Le BOLT 4 appelle cette construction Sphinx, étendue par une charge utile par saut. Avant que le paiement ne parte, votre portefeuille connaît la clé publique de chaque nœud de la route et utilise ECDH contre chacune pour dériver un secret partagé. Quatre clés sortent de chaque secret partagé : rho génère le flux d'octets qui obscurcit le paquet, mu calcule le HMAC d'intégrité, um authentifie les erreurs sur le chemin de retour, et pad amorce le remplissage. Ce flux est ChaCha20 appliqué à des zéros avec un nonce nul de 96 bits, sûr ici uniquement parce qu'aucune clé n'est jamais réutilisée.

Le paquet a quatre champs et une taille fixe : un octet de version, actuellement 0x00, un point secp256k1 compressé de 33 octets faisant office de clé éphémère, 1 300 octets de charges utiles de saut, et un HMAC de 32 octets. Cela fait 1 366 octets sur le fil, sans besoin de préfixe de longueur.

L'assemblage se fait à rebours. La région de 1 300 octets commence par des octets aléatoires issus d'un flux ChaCha20, et pour chaque saut, du dernier au premier, elle est décalée vers la droite pour faire de la place, poussant l'extrémité lointaine hors du bord et la jetant. Pour une charge utile inférieure à 253 octets, le décalage vaut la longueur de cette charge utile plus 33 : un octet de longueur et 32 octets de HMAC. Chaque décalage est suivi d'un XOR contre le flux rho du saut, ce qui brouille à nouveau les couches précédentes.

Ce qu'un saut lit est une courte liste de champs typés : le type 2 est amt_to_forward en millisatoshis, le type 4 est outgoing_cltv_value, le verrou temporel qu'il doit appliquer au HTLC qu'il propose ensuite, et le type 6 est short_channel_id, qui nomme le canal à utiliser, bien qu'un nœud puisse substituer un autre canal vers le même pair. À la place de ce court identifiant de canal, le nœud final reçoit le type 8, qui porte un secret de paiement de 32 octets et le montant total.

Une étape supplémentaire rend des paquets consécutifs non corrélables. Chaque saut modifie la clé éphémère par un facteur d'aveuglement avant de la transmettre, de sorte que le même oignon ressemble à des octets sans rapport sur chaque lien qu'il traverse. Le BOLT 4 est honnête sur la limite : l'obscurcissement « does not preclude the possibility of packet association by an attacker via traffic analysis. »

Pourquoi cela compte quand vous achetez du bitcoin

Le routage en oignon vous protège des inconnus au milieu d'une route et de personne à ses deux extrémités, ce qui est l'aspect le plus mal compris de la confidentialité de Lightning.

Le premier saut est généralement un service avec lequel vous avez déjà une relation, et il voit bien plus qu'un nœud de transfert quelconque. Notre avis sur Phoenix cite la propre FAQ d'ACINQ sans l'adoucir : « The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments. » Phoenix obtient 4,0 ici et est réellement en auto-conservation, un vrai nœud sur le téléphone derrière une phrase de récupération de 12 mots. La conservation et la confidentialité sont des questions distinctes, et il n'en résout bien qu'une.

L'extrémité réceptrice n'est pas mieux lotie. Strike conserve vos fonds tant que ceux-ci restent dans l'application et exige une vérification d'identité, de sorte qu'un retrait Lightning vers votre propre portefeuille indique à Strike le montant, le moment et la facture payée, quel que soit le nombre de sauts franchis par l'oignon. Wallet of Satoshi porte un statut de mise en garde et une note de 2,7 ici en partie parce que l'entreprise détient les clés, et elle a déjà retiré son service Lightning dépositaire de l'Union européenne.

Ne lisez donc pas le routage en oignon comme un contournement des obligations de conformité. Il ne change pas la section de légalité d'un guide pays qui s'applique à vous, il ne dissimule pas un achat à la plateforme d'échange qui l'a vendu, et il ne vous apporte rien quand l'opérateur de votre portefeuille est l'une des extrémités. Ce qu'il apporte vaut néanmoins la peine : un nœud de routage dont vous n'avez jamais entendu parler ne peut pas construire un graphe de qui paie qui, ne peut pas dire si vous êtes l'expéditeur ou un autre saut, et ne peut pas distinguer une route courte d'une route longue.

Payer une facture Strike via deux nœuds dont vous n'avez jamais entendu parler

Payer une facture Strike sur Lightning montre ce que chaque nœud d'une route apprend et n'apprend pas.

Supposez que votre portefeuille choisisse un chemin de quatre nœuds : votre propre pair, deux nœuds de routage publics, puis Strike. Le paquet est construit à partir de Strike en remontant. La charge utile de Strike reçoit le montant final et le secret de paiement. Chaque charge utile intermédiaire reçoit un amt_to_forward qui contient encore les frais de tous les nœuds en aval, un outgoing_cltv_value diminué du delta annoncé par ce nœud, et le short_channel_id du lien à utiliser.

Le deuxième nœud de routage ne lit qu'une seule charge utile. Il apprend que le nœud précédent lui a remis un HTLC et qu'il doit en proposer un légèrement plus petit ensuite. Il n'apprend pas que Strike est à l'arrivée, n'apprend pas que vous êtes au départ, et ne peut pas dire si le chemin fait quatre sauts ou huit, car la région qu'il transmet correspond aux mêmes 1 300 octets qu'il a reçus.

Si ce nœud n'a pas de liquidité pour le transfert, il construit un paquet de retour : un HMAC sous sa clé um, un code d'échec, un remplissage choisi pour que le message d'échec plus le remplissage atteigne au moins 256 octets, et le résultat passé au XOR avec un flux issu d'une clé ammag. Chaque saut sur le chemin de retour l'obscurcit à nouveau. Votre portefeuille déroule les couches puis continue de déchiffrer jusqu'à ce que la boucle ait tourné 27 fois, la route la plus longue que permet le format de charge utile TLV, afin que le nœud en échec ne puisse pas déterminer sa position en chronométrant une tentative répétée. Les nœuds plus récents joignent aussi des données d'attribution : des HMAC tronqués à 4 octets, au nombre de 210 pour une route dimensionnée au maximum de 20 sauts, et des temps de retenue en unités de 100 millisecondes.

Routage en oignon vs chemin aveuglé

Le routage en oignon dissimule la route aux nœuds qui transportent un paiement, tandis qu'un chemin aveuglé dissimule la fin de la route à la personne qui paie.

Le routage en oignon simple exige que l'expéditeur connaisse la clé publique réelle de chaque nœud, car les secrets partagés proviennent d'ECDH contre ces clés. L'aveuglement de route inverse cela pour le dernier segment : le destinataire construit une chaîne d'identifiants de nœuds modifiés, transformant Bob en Bob prime et Carol en Carol prime dans l'exemple même du BOLT 4, puis remet à l'expéditeur un point d'introduction plus un bloc chiffré par saut. L'expéditeur enveloppe un oignon autour de blocs qu'il ne peut pas lire. Les deux se composent plutôt qu'ils ne rivalisent : le BOLT 4 impose à chaque message oignon d'utiliser l'aveuglement de route, et un message oignon utilise la même forme de paquet qu'un oignon de paiement.

Routage en oignon vs HTLC

Le routage en oignon transporte les instructions et le HTLC transporte l'argent, et un paiement Lightning a besoin des deux car chacun vérifie l'autre.

L'oignon indique à un saut où transférer et combien. Le HTLC est le paiement conditionnel réellement proposé sur le canal. Comme la région de charge utile est couverte par un HMAC à l'échelle du paquet que seuls l'expéditeur et ce saut peuvent produire, un nœud compare le HTLC qui lui a été proposé avec l'amt_to_forward et l'outgoing_cltv_value écrits pour lui et échoue lorsqu'ils divergent, ce qui permet de repérer un nœud en amont qui rogne discrètement le montant. Ils se séparent aussi : un message oignon, de type 513, est la même construction sans transport d'argent, et aucune erreur ne revient jamais d'un saut intermédiaire pour un tel message.