BOLT12, LNURL et Bitcoin Lightning

3 juin 2023 La redaction 66 Views

Qu’est-ce que le BOLT 12 ? Eh bien, il s’agit de nombreuses fonctionnalités différentes et de pièces mobiles assemblées pour accomplir plusieurs choses différentes – codes QR statiques, factures modulaires, confidentialité pour la personne qui reçoit le paiement.

Mais qu’est-ce que le package complet? C’est un moyen d’avoir un seul code QR, une « offre », vous permettant de récupérer les factures d’un nœud de manière à préserver la confidentialité, tout en permettant des choses comme demander qu’un nœud distant paie votre facture.

Maintenant, toute personne connaissant LNURL devrait déjà penser, « Cela ressemble beaucoup à LNURL. » Mais pour ceux d’entre vous qui ne savent pas ce qu’est LNURL ou comment cela fonctionne, voici une ventilation rapide.

Qu’est-ce que LNURL ?

LNURL est une pile de protocoles simples permettant de coordonner les informations nécessaires pour effectuer des paiements sur le Lightning Network à l’aide de HTTP. La liste complète des pièces du protocole LNURL peut être trouvée icimais je vais juste aborder quelques utilisations principales qui se chevauchent avec BOLT 12.

Trois éléments principaux du protocole LNURL sont un schéma d’authentification, où une clé publique peut être utilisée pour se connecter à un service, un schéma de demande de facture où un portefeuille peut envoyer un ping à un serveur via un code QR statique et récupérer une facture, et un retrait schéma de demande où un portefeuille peut envoyer un ping à un serveur et demander que le serveur paie une facture fournie par le portefeuille. Les factures Lightning sont beaucoup plus longues que les adresses Bitcoin en chaîne, le paiement lui-même est déjà un processus interactif nécessitant que les deux parties soient en ligne, il est donc logique de coordonner les détails de paiement de manière interactive via une connexion réseau.

Le protocole d’authentification n’est en fait que le serveur fournissant un numéro généré de manière aléatoire que le portefeuille de l’utilisateur signe avec une clé nouvellement générée. Une fois que la valeur aléatoire signée est reçue par le serveur, il enregistre la clé associée à utiliser lors de futures connexions.

La fonctionnalité de demande de facture est un moyen de fournir des informations à un utilisateur sur un paiement qu’il souhaite effectuer dans un format qui n’est pas une facture. Cela fournit une description du paiement, le montant minimum et maximum que le service s’attend à payer, et une URL pour le portefeuille à partir duquel demander une facture réelle. À partir de là, le portefeuille affiche ces informations à l’utilisateur, lui permettant de définir un montant final et de demander une facture. Après avoir envoyé la demande de facture et en avoir reçu une du serveur, le portefeuille vérifie que les montants correspondent à ce que l’utilisateur a défini et paie la facture.

La demande de retrait fonctionne en envoyant un ping au service et en recevant en réponse une description, une URL à laquelle envoyer une facture, une chaîne aléatoire (ou déterministe à lier à un compte ou à un utilisateur), et un montant minimum et un montant maximum pouvant être retiré . Après avoir renseigné la valeur appropriée, le portefeuille renvoie une facture au serveur, et si elle est valide et dans les paramètres de montant, le service paie la facture. Le protocole d’authentification LNURL peut être utilisé en plus de cela pour garantir que seul l’utilisateur prévu peut se retirer avec succès en utilisant le lien LNURL.

LNURL a lissé et amélioré une grande partie de l’expérience UX autour de l’utilisation du Lightning Network, mais il nécessite l’utilisation d’un serveur Web pour être utilisé. Toutes les demandes et réponses sont traitées via HTTP, et une infrastructure supplémentaire au-delà du nœud Lightning lui-même est nécessaire pour gérer ces moyens rationalisés de coordination et d’exécution des paiements. Il s’agit d’une exigence parfaitement raisonnable pour tout fournisseur de services en ligne ou commerçant, qui aura de toute façon réaliste besoin d’un serveur Web pour fournir son service ou ses produits en ligne. Cependant, pour un utilisateur final non technique à la maison qui souhaite simplement une telle expérience simplifiée, un vendeur de rue, un magasin physique ou d’autres utilisateurs qui n’ont pas déjà besoin de l’utilisation d’un serveur Web, cela peut être une exigence lourde et potentiellement risquée. .

Qu’est-ce que le BOLT 12 ?

BOLT 12 offre une tentative d’atteindre certaines des fonctionnalités de base fournies par LNURL sans nécessiter l’utilisation d’un serveur Web. Une offre encode les données nécessaires pour atteindre un nœud afin de demander une facture pour effectuer un paiement, soit un node_id, soit un chemin aveugle (les derniers sauts d’une route en oignon, pré-calculés et cryptés) vers ce nœud à l’aide de messages en oignon. Il peut également coder un montant minimum pour un paiement, la devise payée, un délai d’expiration et des numéros de quantité minimum/maximum (pour l’achat de plusieurs articles).

Il s’agit de toutes les informations nécessaires pour extraire une facture réelle du nœud qui a émis l’offre. Quelqu’un qui veut payer une facture le fait via des messages onion, l’une des principales fonctionnalités de BOLT 12. Il permet aux nœuds d’établir une connexion directe chiffrée de bout en bout entre eux qui n’implique pas de canal Lightning. Tout comme les paiements Lightning, ceux-ci peuvent être utilisés pour acheminer les messages en oignon. Après avoir obtenu une offre, un payeur utilisera les informations qui y sont encodées pour envoyer un message de demande de facture. Le créateur de l’offre répondra ensuite avec une facture réelle.

Il existe également un support pour générer des offres uniques par utilisateur qui permettent au destinataire de demander un paiement au créateur de l’offre, similaire à la fonction de demande de retrait de LNURL. Les factures BOLT 12 s’engagent sur une clé de payeur unique — celle-ci peut être utilisée dans le cas d’émission de remboursements pour prouver que vous êtes la personne qui a effectivement payé la facture. Cela peut également être utilisé en combinaison avec l’offre de retrait pour garantir que seule la bonne personne peut réussir à obtenir une facture payée par le créateur, par opposition à celui qui est en mesure d’obtenir une copie de l’offre.

Ces deux utilisations des offres remplissent effectivement les mêmes fonctionnalités que les demandes de facturation et de retrait de LNURL, sans qu’il soit nécessaire d’exécuter un serveur Web.

LNURL ou BOULON 12 ? Tout est question de compromis

LNURL et BOLT 12 accomplissent tous deux la même fonctionnalité générale, alors quelle est vraiment la différence entre eux ? Quel est le besoin de BOLT 12 si LNURL existe déjà ? La principale distinction est le serveur Web. Un serveur Web nécessite l’exécution de plus d’infrastructure, un nom de domaine, un certificat TLS et l’expertise pour gérer ces éléments.

Bien que ce ne soit pas un problème qui mérite d’être mentionné pour la plupart des entreprises et des services, car ces choses sont nécessaires pour exploiter toute entreprise en ligne en premier lieu, c’est un gros problème pour votre utilisateur final non technique typique. Il n’est pas raisonnable de s’attendre à ce qu’un utilisateur maintienne une infrastructure supplémentaire boulonnée au-dessus de son nœud Lightning afin d’avoir accès à une expérience utilisateur rationalisée et simple. Se pose également la question de la centralisation du DNS ; un domaine n’est pas quelque chose qui peut jamais être vraiment contrôlé par le propriétaire.

Ces problèmes mis à part, les deux peuvent coexister. LNURL fonctionne très bien et est déjà très largement adopté dans l’écosystème Lightning, ce n’est tout simplement pas une solution réaliste pour les utilisateurs autres que les entreprises ou les services. BOLT 12, tel qu’il est adopté, peut combler cette lacune et offrir la même expérience utilisateur simplifiée aux utilisateurs finaux à domicile qui ne sont pas des entreprises.