Le Lightning Network ne peut pas exactement bifurquer comme Bitcoin lui-même, mais il commence à se diversifier. Le protocole minimum viable a été initialement spécifié dans les documents BOLT très tôt avant que quoi que ce soit ne soit réellement mis en ligne sur le réseau Bitcoin principal, mais ce n’était que le point de départ. Il reste encore de nombreuses extensions à développer dans le protocole et les zones présentant des problèmes de mise à l’échelle non résolus. En général, le protocole Lightning lui-même a encore un long chemin à parcourir pour résoudre les problèmes existants et devenir suffisamment robuste et évolutif pour servir de réseau transactionnel mondial au-dessus de Bitcoin.
Une partie de la justification des systèmes de deuxième couche en tant que solution de mise à l’échelle de Bitcoin, mis à part la réalité évidente que les blockchains ne s’adaptent pas, est de faire de la place pour une expérimentation plus facile. En ce qui concerne les deuxièmes couches comme Lightning, il n’est pas nécessaire que tout le monde accepte un changement pour essayer quelque chose de nouveau. Tant que ce que vous faites fonctionne avec la fonctionnalité de couche de base prise en charge par Bitcoin, seulement deux personnes peuvent se détacher et jouer avec de nouvelles fonctionnalités sans avoir à se soucier de tous les autres qui la prennent en charge. Différentes implémentations commencent à profiter de cette plus grande liberté que la couche de base de Bitcoin, et certains membres des équipes Core Lightning (CLN), Lightning Network Daemon (LND) et Lightning Dev Kit (LDK) ont participé à un panel très intéressant à Bitcoin 2022 pour discuter de certaines des différentes priorités que chaque équipe prend en termes d’expansion de l’ensemble de fonctionnalités de leurs clients Lightning.
LND
LND, géré par Lightning Labs, est l’implémentation Lightning la plus largement adoptée sur le réseau. Il alimente également de grandes entreprises comme Bitrefill et Hodl Hodl. L’une des plus grandes lacunes de LND a été le taux de croissance massif de sa base de données d’état de canal (qui est optimisée dans sa prochaine version), mais il reste le leader actuel du pack sur le réseau.
L’équipe Lightning Labs s’est généralement concentrée sur la fourniture de ses propres services monétisés pour aider à combler les lacunes inhérentes au protocole Lightning en tant que cœur de son modèle commercial. En ce qui concerne la feuille de route actuelle à court terme, le LND a donné la priorité à deux choses différentes comme priorité principale de ses efforts de développement.
La première est la mise en œuvre de Taproot pour activer une nouvelle structure de transaction pour les canaux (rappelez-vous, tout ce qu’est un canal est un ensemble de transactions pré-signées) pour jeter les bases des futures améliorations de la confidentialité. L’un d’entre eux est le passage des contrats de verrouillage de temps de hachage (HTLC) aux contrats de verrouillage de temps de point (PTLC). Actuellement, les HTLC garantissent qu’un paiement réussit ou échoue à chaque saut le long d’un itinéraire de paiement ; la préimage du hashlock est libérée et garantit que le paiement est effectué pour tout le monde ou non et est remboursé pour tout le monde. Les PTLC accomplissent la même chose en utilisant des signatures d’adaptateur au lieu de hachages, ce qui signifie que chaque saut le long du chemin n’a pas le même hachage qui pourrait identifier un seul paiement sur plusieurs sauts si une personne exécute plusieurs nœuds le long du chemin de paiement. Bien qu’il ne s’agisse en aucun cas d’une solution de confidentialité magique pour le réseau, il s’agit d’un élément de base vers une confidentialité complète une fois que d’autres solutions sont mises en œuvre.
La prochaine étape après la mise en œuvre des canaux Taproot pour Lightning consiste à mettre à jour les canaux en direct sur le réseau pour les utiliser. Il existe 82 697 chaînes Lightning publiques à ce jour. Avec une utilisation presque la plus efficace de l’espace de bloc contenant environ 3 300 transactions, il faudrait 25 blocs de fermetures de canaux pour les fermer tous, et 25 autres pour les rouvrir en tant que canaux Taproot.
Supposons qu’il y ait deux fois plus de chaînes privées que de chaînes publiques. Cela porterait le total à environ 150 blocs pour fermer et rouvrir tous les canaux Lightning existants en tant que canaux Taproot, en supposant que les blocs ne sont remplis d’aucune autre transaction. En réalité, cependant, ces blocs ne seront pas remplis uniquement de transactions Lightning, ce processus pourrait donc prendre une semaine ou plus pour que l’ensemble du réseau parcoure et se mette à niveau. LND prévoit d’implémenter une fonctionnalité appelée « mises à jour des canaux à la volée », où au lieu de fermer les canaux existants et d’en ouvrir de nouveaux, vous passez simplement l’état du canal existant (transaction pré-signée) dans un nouveau plutôt que dans des sorties qui fermer le canal sur la chaîne. Cela se fait au prix d’une transaction supplémentaire pour les fermetures non coopératives, mais permettrait aux opérateurs de nœuds de profiter des nouvelles fonctionnalités basées sur Taproot sans avoir à fermer les canaux existants.
De toute évidence, la mise en œuvre de Taro prendra probablement une place de choix à un moment donné après ces développements, mais la mise en œuvre d’un tout nouveau protocole de jeton de couche supérieure prendra probablement beaucoup de temps. Compte tenu d’autres fonctionnalités qui pourraient être une bonne idée à implémenter, ainsi que du travail quotidien d’optimisation des fonctionnalités existantes du nœud, je ne pense pas qu’il soit possible de dire combien de temps avant que cela ne voie le jour. =
NCL
CLN (anciennement c-lightning), était, malgré de nombreuses informations contraires à l’époque, la première implémentation de Lightning à être mise en ligne sur le réseau principal en 2018. Toute l’architecture de CLN a été construite autour de l’idée de modularité, de sorte que différents éléments de le nœud (tel que les clés de gestion des pièces et la signature) pourrait être facilement échangé et personnalisé. Il existe même un système de plug-in conçu pour que les utilisateurs puissent écrire leur propre comportement personnalisé pour s’interfacer avec CLN et modifier le fonctionnement du nœud dans certaines situations ou en réponse à des événements spécifiques.
Un excellent exemple de cela est la fonctionnalité de paiement, qui est même implémentée en tant que plug-in pour le comportement de paiement par défaut fourni avec CLN. C’est la partie du nœud qui gère la détermination des itinéraires de paiement et leur envoi. Il existe un large catalogue de plugins disponibles, de la gestion automatisée des nœuds avec CLBOSS, des plugins de tour de guet et de la logique de sondage automatisée, à l’élagage dynamique de Bitcoin Core pour garantir que CLN dispose toujours des blocs dont il a besoin pour rester synchronisé. Une grande liste de plugins peut être trouvée ici.
L’objectif principal de CLN a toujours été la modularité et la flexibilité, et l’équipe prévoit de passer au niveau supérieur avec sa pile logicielle Greenlight. Greenlight séparera davantage les fonctionnalités des différentes parties du nœud au point que les utilisateurs pourront stocker et gérer leurs clés et leurs opérations de signature sur différents (et même plusieurs) appareils à partir desquels les canaux de gestion du backend du nœud réel et d’autres données peuvent s’exécuter. ailleurs, soit dans le cloud, soit même sur un appareil hébergé chez vous. Breez Wallet prévoit même de passer à l’utilisation de CLN/Greenlight et de diviser les différentes fonctions de son portefeuille en applications distinctes pour profiter de la liberté permise par cette architecture. Applications distinctes pour la diffusion de podcasts, l’utilisation générale du portefeuille, les systèmes PoS, toutes connectées au même nœud. Cela ouvre même la porte à la réception de paiements lorsque votre portefeuille mobile est hors ligne, un problème majeur dans de nombreux cas d’utilisation avec Lightning. Un dispositif de signature distinct pourrait être laissé à la maison en ligne tout le temps et programmé pour ne signer que les mises à jour de chaîne lorsqu’elles augmentent le solde de votre chaîne. Problème résolu, vous n’avez plus à vous soucier d’avoir votre téléphone ouvert en permanence pour recevoir des fonds.
La prochaine priorité de CLN sera de s’appuyer sur le travail de Niftynei sur les chaînes à double financement. Actuellement, lors de l’ouverture d’un canal Lightning, un seul côté du canal fournit un UTXO de financement, laissant toute la liquidité du canal du côté de cette partie. CLN prend actuellement en charge le double financement où les deux côtés du canal peuvent contribuer des UTXO dans la transaction de financement, permettant au canal de démarrer dans un état équilibré où les deux côtés disposent de fonds. S’appuyant sur cette fonctionnalité, il travaille actuellement à la mise en œuvre de l’épissage, une fonctionnalité longuement discutée pour le protocole.
L’épissage vous permettrait d’ouvrir et de fermer un canal en une seule transaction pour ajouter plus de fonds ou supprimer certains mais pas tous les fonds du canal. Ce serait une énorme victoire pour la liquidité du canal. Imaginez ouvrir un canal avec quelqu’un pour qu’il puisse recevoir des fonds et réaliser que vous lui avez alloué dix fois le montant dont il avait besoin. L’épissage vous permettrait de supprimer l’excédent sans perturber la capacité de votre pair à recevoir des fonds et à allouer votre bitcoin à un endroit plus productif. Il s’agit d’une énorme victoire pour les utilisateurs moyens, les fournisseurs de services Lightning (LSP) et les nœuds de routage. Cela leur permettrait à tous d’utiliser leurs liquidités plus efficacement sans fermer le canal pour l’autre partie.
LDK
Lightning Dev Kit n’est pas tant une implémentation de nœud Lightning qu’une bibliothèque pouvant être utilisée pour construire un nœud Lightning. Il fournit du code pour chaque élément isolé d’un nœud Lightning, la logique de routage, la gestion des canaux, la logique de surveillance de l’état de la blockchain pour vérifier si les canaux sont ouverts, le tout.
Blue Wallet travaille sur une implémentation basée sur LDK, et une toute nouvelle implémentation Lightning Sensei est également en cours de développement autour de LDK. Cash App a même construit un nœud entièrement à partir de zéro. Lorsqu’elle a commencé à envisager l’intégration de Lightning, elle souhaitait intégrer profondément le comportement de ses nœuds Lightning avec le backend gérant les soldes des utilisateurs de Cash App. Aucune implémentation existante ne permettrait une intégration facile à ce degré, ils ont donc personnalisé la leur en utilisant LDK.
L’équipe LDK entreprend une entreprise très différente de celle des autres implémentations Lightning. Comme indiqué précédemment, il ne s’agit pas vraiment d’une implémentation, mais plutôt d’un kit d’outils qui peut être utilisé pour en créer un vous-même avec le comportement personnalisé que vous souhaitez. En tant que tel, il ne donne pas vraiment la priorité à des ensembles de fonctionnalités spécifiques par rapport aux autres. L’objectif de LDK est de prendre en charge largement toutes les fonctionnalités standard du protocole Lightning et de permettre aux constructeurs d’utiliser toutes les fonctionnalités standardisées de la manière qu’ils choisissent dans leurs propres applications, ou non.
La route à suivre
Une grande partie du discours de Lightning consistait à faciliter les paiements natifs sur Internet pour les services numériques, mais l’expérience utilisateur de cet objectif ne s’est pas vraiment concrétisée de manière simple et fluide.
Des travaux ont été menés par LND, CLN et LDK pour résoudre ce problème. Web Assembly (WASM) est un nouveau langage et format binaire pour faciliter l’exécution de programmes plus efficaces et légers dans le navigateur Web. LND et LDK ont tous deux des binaires WASM pour leurs nœuds, et CLN prévoit de mettre en œuvre des outils de gestion de clés à exécuter dans WASM qui peuvent se connecter à distance à un nœud Lightning, en s’appuyant sur son travail Greenlight. Bien qu’il y ait des problèmes de sécurité à prendre en compte lors de la gestion des clés dans un navigateur Web, les jours de l’intégration transparente de Lightning sur le Web approchent.
Lightning en tant que protocole et réseau a encore un long chemin à parcourir pour résoudre les problèmes ouverts et trouver comment créer des applications simples et intuitives pour les utilisateurs finaux, mais le travail avance. Cela deviendra sans aucun doute plus compliqué à mesure que différentes équipes divergent et se concentrent sur la résolution de différents problèmes et l’extension des fonctionnalités dans différentes directions, mais des progrès sont sans aucun doute en cours. Nous ne pouvons qu’espérer que les choses ne divergeront pas au point de fragmenter le réseau et la compatibilité logicielle. Le chemin à parcourir sera en effet très intéressant.
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.