Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
BOLT 12 est une proposition de Rusty Russel de Blockstream pour optimiser la façon dont les paiements sont effectués sur Lightning et devenir finalement le successeur de BOLT 11. Même s’il existe de nombreuses fonctionnalités différentes regroupées afin de composer le BOLT, cet article va principalement se concentrer sur les compromis et les enjeux concernant l’un d’entre eux. Tout d’abord, je vais résumer rapidement certaines des principales caractéristiques de la proposition BOLT :
BOLT : (base de la technologie Lightning ; l’équivalent Lightning de la proposition d’amélioration Bitcoin [BIP] Caractéristiques)
* Chemins aveugles : Ceci est utilisé à la fois pour les factures de paiement et les messages d’oignon. Il prédéfinit et crypte les derniers sauts dans un circuit de paiement ou de message d’oignon afin que l’expéditeur ne sache pas où il envoie quelque chose, tout en lui permettant d’arriver au destinataire prévu.
* Signatures Schnorr : cela permet à tous les différents endroits où les signatures sont utilisées dans la coordination d’un paiement Lightning ou dans la communication avec les nœuds de tirer parti de Schnorr multisig à l’avenir.
* Payer Proofs : les nœuds créent désormais une clé spéciale lorsqu’ils demandent des factures, leur permettant de prouver, par une signature, qu’ils ont effectué un paiement. Cela garantit également en cas de remboursement que seul le véritable payeur pourra y prétendre.
* Arbres Merkle des factures : les factures sont désormais encodées sous forme d’arbres Merkle dédiés à chaque champ individuel. De cette façon, si jamais vous avez besoin de prouver que vous avez effectué un paiement ou reçu une facture, vous pouvez choisir de manière sélective les pièces à révéler au lieu d’avoir à montrer à quelqu’un la totalité de la facture.
Toutes ces choses réunies forment une « offre Lightning ». Cela vous permet de publier un seul code QR statique avec des informations pour envoyer un ping à un nœud sur les messages onion et recevoir une facture Lightning pour un paiement spécifique sur le Lightning Network lui-même. Actuellement, les factures BOLT 11 ne sont valables que pour le paiement unique pour lequel elles sont générées, et bien que les paiements Keysend permettent d’effectuer des paiements sans la facture, ils ne vous permettent pas de recevoir les détails du paiement dans une facture signée par le nœud de réception et conservez-les pour de futurs enregistrements. BOLT 12 permet tous les avantages des deux : permettre à une seule donnée statique de faciliter les paiements à un nœud de réception tout en recevant des factures avec les détails de chaque paiement individuel effectué. En passant, cela permet également une coordination rapide et facile des paiements en continu, des paiements d’abonnement, etc. qui ne permettent pas au destinataire de facturer de l’argent si l’expéditeur n’approuve pas la transaction, tout en maintenant une expérience utilisateur simplifiée.
Grâce à l’utilisation de chemins aveugles, il améliore également considérablement l’une des plus grandes lacunes en matière de confidentialité du Lightning Network : les récepteurs de paiements doxxant de nombreuses informations privées à l’expéditeur lors du processus de réception d’un paiement, tels que les UTXO en chaîne associés à leur canal ainsi que leur place dans le graphique Lightning Network (c’est-à-dire à quel nœud ils sont connectés et reçoivent le paiement via). Les chemins en aveugle sont utilisés à la fois pour la réception des paiements et pour la réception du ping du message onion pour renvoyer une facture à l’expéditeur.
BOLT 12 regroupe de nombreuses pièces mobiles pour faciliter cette nouvelle façon de coordonner les paiements sur le Lightning Network. L’une des plus grandes critiques formulées à l’encontre de la proposition a été l’inclusion de messages d’oignon à usage général et la crainte qu’elle n’ouvre de nouveaux vecteurs d’attaque par déni de service (DoS). Je pense que la logique ici est complètement incorrecte, et je vais expliquer pourquoi.
L’un des plus gros problèmes de DoS (et de confidentialité) avec le protocole Lightning est le sondage. Chaque canal peut avoir à tout moment 483 HTLC (contrats de verrouillage temporel de hachage) ouverts, représentant des paiements en attente, en raison des limites de taille d’une transaction dans le protocole Bitcoin. Cela permet de s’assurer qu’une transaction de fermeture de canal peut réellement s’installer sur la chaîne et ne pas être rejetée par le mempool parce qu’elle est trop volumineuse. Le sondage est l’acte de spammer des paiements via des canaux, des canaux qui sont intentionnellement conçus pour échouer afin de recueillir des informations sur la façon dont les fonds sont équilibrés dans un canal Lightning. Cela consomme de la bande passante, de l’espace qui pourrait être utilisé pour traiter de véritables paiements, et tout autour gaspille des ressources sur le réseau ainsi que des fuites d’informations qui pourraient être utilisées pour anonymiser les paiements.
Le problème avec les transactions de sondage est qu’elles peuvent être utilisées pour transmettre des messages arbitraires sans payer un seul sat pour eux. Vous pouvez acheminer un paiement via le réseau qui a été conçu pour ne jamais réussir et inclure des données arbitraires pour le destinataire, puis simplement laisser le paiement échouer. Cela abuse du protocole de paiement du Lightning Network pour transporter gratuitement des informations arbitraires, et il n’y a aucun moyen d’empêcher les gens de le faire pour le moment. Vous n’auriez aucun moyen de savoir si un paiement que vous acheminez est authentique ou si vous abusez simplement de votre nœud pour transmettre des données ; lorsqu’un paiement échoue, vous ne pouvez pas savoir s’il a simplement échoué de manière organique ou s’il a été conçu pour échouer dès le départ. C’est en fait ainsi que fonctionne Sphinxchat, à l’exception que, évidemment, ils envoient des paiements et n’abusent pas du réseau gratuitement.
En fin de compte, cette utilisation du protocole Lightning sature le débit rare sous la forme de créneaux HTLC qui pourraient être utilisés pour des paiements économiques « réels » (réels entre guillemets car évidemment, qui doit juger de ce qu’est une activité économique « réelle ») pour transmettre des données arbitraires , et peuvent actuellement être abusés d’une manière où personne n’est réellement payé pour le faire. Il s’agit d’un risque DoS très réel et déjà présent qui existe sur le Lightning Network.
Il existe quelques solutions proposées au problème de sondage et au problème de DoS qu’il crée, dont le principal est l’idée de payer des frais pour un paiement avant qu’il ne réussisse réellement à passer. Il s’agit d’une proposition assez controversée, car cela signifierait qu’un expéditeur finira par payer des frais pour un paiement, qu’il soit ou non effectué avec succès. La nature de toutes les solutions proposées pour cela sort du cadre de cet article, mais le fait est qu’il existe des solutions proposées, et aucune d’entre elles n’est actuellement mise en œuvre. Point clé : elles ne sont pas mises en œuvre.
Donc, pour moi, l’argument selon lequel les messages d’oignon généraux « ouvrent un nouveau vecteur d’attaque DoS » pour Lightning est complètement fallacieux et un faux argument. Ce vecteur d’attaque existe déjà en ce moment. En fait, c’est encore pire que les messages oignon généraux, car cela gaspille une ressource rare nécessaire au routage des paiements – les créneaux horaires HTLC. Les messages généraux sur les oignons ne le font pas.
Les messages Onion sont une fonctionnalité qui peut être désactivée, de sorte que votre nœud peut complètement refuser de les relayer, et aussi quelque chose qui peut être limité en débit. Ce que je veux dire par là, c’est que votre nœud pourrait facilement avoir un paramètre où il ne transmet que « x » messages par seconde, ou « y » quantité de données par seconde, ou toute autre chronologie arbitraire, et refuser de relayer tout ce qui dépasse ces limites. De cette façon, votre nœud peut facilement gérer la quantité de ressources qu’il autorise à consommer en passant des messages généraux.
En d’autres termes, BOLT 12 n’ouvre aucun nouveau vecteur d’attaque DoS ; il en prend simplement un existant qui affecte la capacité du réseau à traiter les paiements et le déplace quelque part qui n’affecte pas le relais des paiements ou ne consomme aucun créneau HTLC. Il a également un moyen d’atténuer la consommation de ressources sans restreindre davantage le flux de paiement. La pire chose qui puisse arriver est un événement de spam massif sur le réseau – saturant la capacité des messages en oignon qui dégraderait la possibilité d’utiliser les offres BOLT 12 ou d’obtenir une facture sur le réseau.
Cela n’affecterait pas le relais des paiements ; cela n’empêcherait pas la capacité de recevoir et de payer les factures de BOLT 11 ; cela signifierait simplement que les tentatives de récupération de factures à l’aide de BOLT 12 échoueraient tant que le réseau serait spammé avec des messages d’oignon. Rappelez-vous également que les nœuds individuels qui ne voulaient pas faire face à la légère augmentation de l’utilisation de la bande passante pouvaient se retirer et ne pas relayer les messages d’oignon. Tout, tel qu’il fonctionne actuellement, continuerait de fonctionner, et un vecteur d’attaque DoS existant aurait une sorte de soupape de décharge où les personnes qui voulaient transmettre des messages arbitraires pourraient le faire d’une manière qui ne gaspille pas les créneaux HTLC ou n’entrave pas le traitement des paiements. , et toute personne souhaitant désactiver la nouvelle fonctionnalité pouvait le faire.
En bref, je pense que l’argument du « vecteur DoS » contre BOLT 12 est un non-sens. Si les gens veulent proposer des arguments sur la complexité de toutes les pièces de travail, le temps de développement nécessaire pour la mettre en œuvre ou d’autres aspects de la proposition, je pense que ce sont tous des arguments valables à faire valoir. Cependant, l’argument contre les messages oignon et les nouveaux vecteurs DoS ne tient pas la route.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Bitcoin Magazine.
