Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
Le protocole Lightning fonctionne en mettant à jour de manière atomique les paiements sur plusieurs canaux de paiement de telle sorte que tout se confirme ou échoue tous ensemble, c’est-à-dire qu’il achemine les paiements sur plusieurs sauts. Une partie intégrante de tout système basé sur le routage est une table de routage, une collection de toutes les informations nécessaires pour réellement construire un chemin d’un point A à un point B. Sans ces informations, vous ne pouvez pas vraiment router quoi que ce soit n’importe où parce que vous ne savoir comment obtenir l’information d’où elle se trouve à l’endroit où vous voulez qu’elle aille. Lightning nécessite évidemment une table de routage, ce que le protocole de potins spécifié dans BOLT 7 accomplit ; la propagation et la maintenance de l’enregistrement des canaux disponibles sur le réseau pour acheminer les paiements.
Ce protocole de potins est l’une des préoccupations de mise à l’échelle de l’ensemble de la pile de protocoles Lightning. Actuellement, il est très basique et fonctionne d’une manière assez similaire à la propagation des transactions sur le réseau Bitcoin proprement dit ; Les nœuds du réseau reçoivent un message de potins, ils vérifient ensuite le message selon les règles de validité et le transmettent à tous leurs pairs pour se propager davantage à travers le réseau. Il s’agit d’un protocole de remplissage naïf qui suppose que des messages valides finiront par se propager sur l’ensemble du réseau.
Pour cette raison, il existe un risque d’attaques par déni de service (spam) qui finiront par consommer une grande quantité de ressources de traitement et de bande passante à traiter. Dans le cas du réseau Bitcoin principal, les nœuds ne relayeront pas les transactions invalides, donc pour diffuser quelque chose qui consomme de la bande passante et des ressources de calcul des nœuds, vous devez disposer de bitcoin pour créer une transaction avec. Dans le cas du protocole Lightning Gossip, vous devez prouver que vous contrôlez un UTXO valide finançant une chaîne afin de relayer un message de ragots sur la chaîne. Cela exécute la même fonction de protection anti-spam que sur le réseau Bitcoin principal ; vous ne pouvez pas spammer des messages sur le réseau sans contrôler réellement le bitcoin.
Cela m’amène à la structure réelle du protocole de potins. Il ne s’agira en aucun cas d’une ventilation complète du protocole, mais d’un examen suffisamment approfondi pour examiner un changement proposé et évaluer les compromis entre la proposition et le protocole actuel. Il y a trois messages principaux actuellement dans le protocole de potins. Le message channel_announcement, le message node_announcement et le message channel_update. Il existe également un message d’annonce_signatures, mais celui-ci n’est utilisé qu’avec des homologues de canal directs pour signer des messages annonçant des canaux, et il n’est pas largement diffusé sur l’ensemble du réseau. Je ne vais pas couvrir les messages de demande de données, car ils ne sont pas vraiment pertinents pour le propos de cet article.
Le message channel_announcement est la première chose nécessaire pour annoncer un canal au réseau, puis pour annoncer également votre nœud au public. Il est construit en collaboration et nécessite que les deux partenaires de la chaîne le réalisent et le diffusent. Ce message inclut la preuve que la transaction de financement vers un canal paie l’adresse multisig du canal, puis il inclut les signatures de la clé d’identité du nœud Lightning des deux participants sur le message. Il déclare quelle clé multisig appartient à quel nœud et inclut les signatures de chaque clé multisig de l’UTXO en chaîne finançant le canal. Cela prouve que les deux nœuds impliqués dans un canal contrôlent le multisig en chaîne, puis cela prouve que leur clé d’identité de nœud Lightning y est associée.
Vient ensuite le message node_announcement. Si un nœud tente de relayer ce message sans avoir préalablement envoyé un message channel_announcement pour un canal valide, il est ignoré et non relayé. Les nœuds relaient eux-mêmes ce message après avoir ouvert leur premier canal public pour permettre à d’autres nœuds de s’y connecter. Ce message contient une signature de la clé d’identité du nœud sur le message ; quelques éléments de fonctionnalité pour les futures mises à jour de version, l’adresse réseau à laquelle le nœud peut être atteint pour ouvrir des canaux avec, un alias (surnom) et quelques autres informations.
Enfin, le message channel_update. Ce message est également réalisé et diffusé unilatéralement par un nœud unique. Il contient les contrats de verrouillage de temps hachés de valeur minimale et maximale (HTLC) qu’un canal acheminera ; les frais que l’opérateur facturera pour l’acheminement via ce canal (frais de base et taux de frais en pourcentage) ; et la longueur de la différence de verrouillage de temps dont il a besoin entre lui-même et le saut précédent, de sorte qu’il ait le temps de trouver une transaction se réglant sur la chaîne et d’appliquer le résultat approprié pour lui-même si nécessaire. Il est également signé comme tous les autres messages.
Ainsi, le protocole tel qu’il est maintenant fournit toutes les informations nécessaires pour trouver les canaux par lesquels vous pouvez acheminer les paiements, annoncer les informations nécessaires pour savoir quels frais chaque canal facturera et fournit un mécanisme de protection contre le déni de service pour empêcher le Lightning Network de être spammé toute la journée avec des publicités absurdes de chaînes qui n’existent pas en exigeant les signatures des clés détenant le financement UTXO sur la chaîne.
Mais il a un problème majeur : un manque total d’intimité. Afin de faire la publicité de votre chaîne sur le réseau pour que les personnes puissent acheminer les paiements, vous devez doxer l’UTXO exact utilisé pour financer cette chaîne et l’associer à la clé d’identité de votre nœud Lightning. Alors, que pouvons-nous faire pour résoudre ce problème ?
Rusty Russell de Blockstream a proposé une version mise à jour du protocole de potins en février 2022. Cela réduirait le protocole de base de trois messages à deux et améliorerait considérablement les propriétés de confidentialité en conséquence.
En fait, ce qui se passerait serait de supprimer complètement le message channel_announcement et de laisser le protocole avec node_announcement_v2 et un message channel_update_v2. Au lieu de doxxer chaque UTXO individuel associé à un canal et d’exiger d’abord un channel_announcement, le node_announcement_v2 pourrait être fait initialement et prouver le contrôle sur un UTXO qui n’est pas réellement utilisé pour financer un canal. L’opérateur de nœud serait alors autorisé à annoncer des canaux reflétant un multiple de ce montant (donc, disons que vous avez 1 BTC sur lequel vous avez prouvé le contrôle, vous pouvez maintenant annoncer 10 BTC de capacité de routage), sans avoir à doxer les UTXO de canal réels.
Ce serait une amélioration massive de la confidentialité pour le réseau en n’obligeant pas chaque canal à se lier à un UTXO spécifique sur la chaîne ; les entreprises d’analyse de la chaîne ne seraient plus en mesure de suivre facilement les fonds de chaque opérateur de nœud public sur la chaîne entre les canaux. Le message channel_update_v2 prendrait alors la place de channel_announcement et channel_update, remplissant le même objectif général dans le protocole.
À long terme, l’idée d’un protocole de commérage basé sur la propagation des inondations n’est probablement pas évolutive. Le remplissage d’inondation est l’une des conceptions de réseau les plus inefficaces pour propager des informations, et c’est un problème qui, à long terme, devra être optimisé et déplacé dans une autre direction pour être vraiment évolutif pour un réseau de paiement qui, espérons-le, sera de taille mondiale. Il n’y a pas vraiment de moyen de contourner cela. Mais l’une des plus grandes lacunes du protocole de potins actuel est l’éviscération de la vie privée des opérateurs de nœuds de routage. Vous ne pouvez pas être un nœud de routage sans entacher publiquement les UTXO de votre canal comme étant liés à vous et faciliter leur surveillance en chaîne.
Étant donné que l’un des plus grands utilitaires potentiels que le Lightning Network pourrait ajouter en plus de l’évolutivité des paiements est la confidentialité des paiements, ne devrions-nous pas nous attaquer aux énormes façons dont la pile de protocoles ne parvient pas à tenir ces promesses de confidentialité ? Je pense que nous devrions, et une grande façon de commencer est d’améliorer la confidentialité des opérateurs de nœuds qui jouent en fait le rôle de faciliter les paiements sur le réseau en premier lieu.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne
reflètent nécessairement ceux de BTC Inc ou Bitcoin Magazine.
