Traduction d’un article de Lorenzo publié le 23 juin sur voltage.cloud.
Si vous utilisez régulièrement le Lightning Network ou si vous avez lu notre article sur LNURL, vous n’ignorez pas les limitations du Lightning Network sur le plan de l’expérience utilisateur. dans le cas contraire, voici un petit récapitulatif.
La norme actuelle pour recevoir un paiement via Lightning est fixée par le BOLT 11 [1]. Chaque paiement nécessite une facture, et chaque facture, à son tour, est liée à une pré-image du paiement. Le BOLT 11 a deux limites :
– payer la même facture plus d’une fois c’est prendre le risque d’un vol des fonds,
– une facture Lightning permet uniquement de demander un paiement, pas d’envoyer des fonds.
Cela limite les utilisations de Lightning Network par rapport aux réseaux de paiement traditionnels. Si un streamer doit se mettre en pause pour générer une nouvelle facture à chaque fois que quelqu’un veut lui donner un pourboire, il n’utilisera pas le Lightning Network. Autre exemple : Lorsqu’on échange des billets de banque contre des satoshis dans un ATM Lightning, il est nécessaire de créer une facture spécifique que le guichet automatique pourra numériser. Ou pire encore, il faut taper cette facture manuellement.
Lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkjEnfin il n’est pas possible avec le BOLT 11 d’avoir une adresse de réception statique sans passer par un serveur externe (solution retenue par LNURL).
Ces exemples montrent les limitations de Lightning. Pour surpasser les autres réseaux de paiement, il faut être capable de répondre à un plus large éventail de cas d’utilisation.
La solution proposée
Le BOLT 12 est a été proposé par Rusty Russell, développeur de l’implémentation c-lightning de Blockstream, pour dépasser ces limitations. L’objectif est de permettre aux clients Lightning de générer des QR codes statiques qui peuvent être utilisés pour le paiement et également pour recevoir des fonds, comme dans l’exemple de guichet automatique ci-dessus. Comme Rusty Russel est également l’auteur de la spécification BOLT 11, personne d’autre que lui n’en connait mieux les limites.
L’idée est simple : permettre aux noeuds Lightning de créer un QR code statique contenant les informations nécessaires pour qu’un portefeuille puisse communiquer avec lui et coordonner des actions. Si vous savez comment fonctionne LNURL, cela vous est déjà familier. La différence majeure avec LNULR c’est que le BOLT 12 propose une communication et une coordination native au réseau.
Étant donné que le BOLT 12 n’a besoin d’intégrer que des informations sur un nœud Lightning, et non des informations sur le paiement, comme le BOLT 11, le QR code généré est beaucoup plus simple. Il est possible d’ajouter des données supplémentaires, telles que des chemins aveugles (blinded path), par exemple. Dissipons ici un malentendu : blinded path ne nécessite le BOLT 12, mais cette spécification le rend son utilisation beaucoup plus simple.
Pour permettre cette communication et cette coordination des nœuds Lightning, Rusty Russel propose d’utiliser des messages en oignon, un mécanisme très similaire au protocole Onion Routing qui permet d’envoyer des paiements sur le réseau, mais sans la partie paiement. Cela permettra aux offres de fonctionner nativement dans le réseau, sans avoir besoin de serveurs externes, comme c’est le cas pour LNURL. Aujourd’hui, Onion Messages est toujours en cours de développement, ce qui est l’une des raisons pour lesquelles le BOLT 12 n’est pas encore fonctionnel.
Avec le BOLT 12, l’utilisateur scannera une « offre » au lieu d’une facture. Les offres servent d’étape préliminaire au message de demande de facture. Les demandes de facture ont deux utilisations. La première est une réponse à une offre, contenant l’identifiant du propriétaire de l’offre et les détails de cette offre. Si la demande est valide, la réponse consiste à envoyer une facture en utilisant le chemin de réponse spécifié dans le message onion. L’autre cas d’utilisation consiste à publier directement une « invoice_request », à l’aide d’un QR code par exemple. Cette requête, une proposition d’envoi de fonds, contient l’identifiant du nœud qui paiera la facture.
Les offres et les demandes de facture sont encodées au format Type-Length-Value (TLV), décrit dans BOLT 1, le protocole d’encodage par défaut pour les messages sur le Lightning Network. Ce protocole facilite les mises à niveau du réseau en fournissant un moyen flexible et extensible de structurer et d’échanger des données. Il permet d’ajouter de nouvelles fonctionnalités sans perturber les implémentations existantes, en garantissant la compatibilité et en réduisant les risques et les complexités associés aux mises à niveau du réseau. Cela signifie que BOLT 12 ne nécessite pas une mise à niveau complète du réseau. C’est une fonctionnalité opt-in.
Autre caractéristique intéressante : contrairement à la preuve de paiement habituelle sur Lightning, qui ne peut que garantir que la facture a été payée, BOLT 12 permet également au payeur de prouver que c’est lui qui a effectué le paiement. De plus, si un litige doit être résolu, le payeur ne peut révéler qu’une partie de la facture pour résoudre le problème, préservant ainsi une partie de sa vie privée.
Flux de paiement
Explorons les deux flux de paiement possibles à l’aide des offres : un où un utilisateur paie un marchand et un autre où un utilisateur reçoit de l’argent d’un marchand. Pour simplifier, chaque fois que nous mentionnons « utilisateur » ou « marchand » nous nous réfèrerons à leurs nœuds Lightning respectifs. On va commencer par le premier :
L’utilisateur scanne l’offre du marchand et extrait les informations du QR code pour demander une facture via un message de demande de facture. Quand le commerçant reçoit ce message, il répond en envoyant la facture. L’utilisateur procède alors au paiement comme dans une transaction standard. À partir de là, le processus de paiement se poursuit comme d’habitude.
Voyons maintenant ce qui se passe lorsque le marchand paie l’utilisateur (par exemple dans le cas d’un ATM) :
Le marchand crée un QR code représentant une demande de facture, complété par des champs d’offre exprimant l’intention de payer. L’utilisateur scanne ce code, génère une facture basée sur l’invoice_request et la transmet au commerçant. Une fois que le commerçant reçoit la facture, il la paie et le paiement se poursuit normalement.
Conclusion
Le Lightning Network est confronté à certaines limitations de l’expérience utilisateur en raison de sa dépendance à la norme BOLT 11 pour la demande de paiement. La spécification BOLT 12, suggérée par Rusty Russell, est une solution visant à surmonter ces contraintes en permettant aux nœuds Lightning de générer des QR codes statiques pour la réception et l’envoi de paiements. En mettant en œuvre Onion Messages et en introduisant le concept d’offres, le BOLT 12 simplifie le processus de paiement tout en préservant la confidentialité et en améliorant l’expérience utilisateur. La spécification BOLT 12 est encore en développement mais a le potentiel d’étendre considérablement les cas d’utilisation du Lightning Network, lui permettant concurrencer bien davantage les réseaux de paiement traditionnels et de révolutionner le monde des transactions numériques.
[1] Les BOLT (Basis of Lightning Technology) sont les règles de fonctionnement du Lightning Network. Conçues et améliorées collégialement, ces spécifications permettent l’interopérabilité des différentes implémentations comme Eclair, LND, ou c-lightning.
