Guide du débutant pour le Lightning Network de Bitcoin

Introduction

Les cryptomonnaies ont des propriétés assez uniques. Celles-ci ne peuvent pas facilement être hackées ou clôturées facilement, et quiconque peut les utiliser pour transmettre de la valeur dans le monde entier sans l'intervention d'un tiers.

Pour assurer le maintien de ces caractéristiques, des compromis importants doivent être faits. De nombreux nœuds étant chargés d'exécuter un réseau de cryptomonnaies, le débit est limité. Ainsi, le nombre de transactions par seconde (TPS) qu'un réseau blockchain peut traiter est relativement faible pour une technologie destinée à être adoptée par le grand public.

Pour surmonter les limites inhérentes à la blockchain, un certain nombre de solutions de scalabilité ont été proposées afin d'augmenter le nombre de transactions que le réseau peut traiter. Dans cet article, nous aborderons l'une des extensions du protocole Bitcoin, le Lightning Network.

Qu'est-ce que le Lightning Network ?

Le Lightning Network est un réseau se trouvant au-dessus d'une blockchain permettant de mettre en place des transactions pair à pair rapides. Celui-ci n'est pas exclusif à Bitcoin : d'autres cryptomonnaies tels que le Litecoin l'ont également intégré.

Vous vous demandez peut être ce que nous voulons dire par « se trouvant au-dessus d'une blockchain ». Le Lightning Network est ce que l'on appelle une solution off-chain ou layer-2. Il permet aux utilisateurs d'effectuer des transactions sans avoir à enregistrer chaque transaction dans la blockchain.

Le Lightning Network est distinct du réseau Bitcoin – et possède ses propres nœuds et son logiciel, mais communique tout de même avec la chaîne principale. Pour entrer ou sortir du Lightning Network, vous devez créer des transactions spéciales sur la blockchain.

Ce que vous faites en réalité avec votre première transaction est la création d'une sorte de smart contract avec un autre utilisateur. Avant que nous n'entrions dans les détails – imaginez que le smart contract possède le registre privé avec l'autre utilisateur. Vous pouvez inscrire de nombreuses transactions sur ce registre. Celles-ci ne sont visibles que par vous et votre contrepartie, mais aucun d'entre vous ne peut tricher en raisons de certains fonctionnalités spécifiques.

Ce mini-registre est un canal. Disons que Alice et Bob mettent chacun 5 BTC dans le smart contract. Dans leur canal, ils disposent maintenant d'un solde de 5 BTC chacun. Alice peut maintenant écrire dans le registre qu'elle paye 1 BTC à Bob. Bob possède désormais 6 BTC et Alice en possède 4. Bob peut ensuite décider de renvoyer 2 BTC à Alice, en mettant à jour les soldes à 6 BTC du côté d'Alice et 4 BTC du côté de Bob. Ils peuvent continuer à le faire pendant un certain temps.

À tout moment, l'un d'entre eux peut publier l'état actuel du canal sur la blockchain. À ce stade, les soldes de chaque côté du canal sont attribués à leurs parties respectives sur la chaîne.

Fidèle à leur nom, les transactions Lightning sont rapides. Il n'y a pas de confirmation de bloc à attendre pour que les paiement soient effectués aussi rapidement que ce que votre connexion Internet le permet.

Pourquoi le Lightning Network est-il nécessaire ?

Jusqu'à présent, le Lightning Network (ou LN) semble être l'approche la plus réaliste pour améliorer la scalabilité de la blockchain Bitcoin. La coordination des changements dans un écosystème aussi vaste est très délicate en raison des risques de hard fork et de bugs potentiellement catastrophiques. Avec autant de valeur en jeu, l'expérimentation est incroyablement dangereuse.

Lorsque cette expérimentation a lieu loin de la blockchain, la flexibilité augmente. Si quelque chose se passe mal, cela n'aura aucun impact sur le réseau Bitcoin. Les solutions de layer 2 ne remettent pas en cause les hypothèses de sécurité qui ont permis au protocole de fonctionner pendant plus de 10 ans.

Il n'y a pas non plus d'obligation de changer l'ancienne façon de faire les choses. Les transactions on-chain continuent de fonctionner pour l'utilisateur final, mais celui-ci a désormais la possibilité d'effectuer des transactions off-chain.

L'utilisation du réseau Lightning présente plusieurs avantages. En voici quelques unes.

Scalabilité

Les blocs Bitcoin sont généralement créés toutes les dix minutes et ne peuvent pas stocker de nombreuses transactions. L'espace dans les blocs est une ressource rare mise aux enchères. Vous affrontez en effet les autres utilisateurs pour que vos transactions soient incluses. Les mineurs se souciant avant tout d'êtres payés, ils incluront en priorité les transactions dont les frais sont les plus élevés.

Lorsque peu d'utilisateurs essaient d'envoyer des fonds en même temps, ce n'est pas vraiment un problème. Vous pouvez fixer des frais peu élevés et vous avez toutes les chances de voir la transaction incluse dans le bloc suivant. Mais lorsque tout le monde diffuse des transactions en même temps, les frais moyens peuvent augmenter considérablement. À certaines occasions, ceux-ci ont dépassé 5 $. Au plus haut du marché acheteur de 2017, ils ont même dépassé 50 $.

Moyenne des frais de transaction Bitcoin (en USD)

Cela peut sembler insignifiant pour des transactions de plusieurs milliers de dollars en Bitcoin, mais ce n'est n'est pas viable pour des petits paiements. Qui veut payer 5 $ de frais pour un café à 3 $ ?

Avec le Lightning Network, vous devrez payer deux frais : un pour ouvrir le canal et l'autre pour le fermer. Mais vous et votre contrepartie pouvez effectuer des milliers de transactions gratuitement une fois le canal ouvert. Une fois que vous avez terminé, il vous suffit de publier l'état final sur la blockchain.

Dans l'ensemble, si davantage d'utilisateurs ont recours à des solutions off-chain telles que le Lightning Network, l'espace des blocs sera utilisé plus efficacement. Les transferts de faible valeur et à haute fréquence pourraient être effectués dans les canaux de paiement, tandis que l'espace des blocs est utilisé pour les transactions plus importantes et l'ouverture/la fermeture des canaux. Cela rendrait le système accessible à une base d'utilisateurs beaucoup plus large, ce qui lui permettrait d'évoluer à long terme.

Micropaiements

Le montant minimum de Bitcoin que vous pouvez envoyer dans une transaction est d'environ 0,00000546 BTC. Au moment où nous rédigeons ces lignes, cela correspond à environ quatre centimes. C'est un faible montant, mais le Lightning Network vous permet de repousser les limites jusqu'à la plus petite unité possible (0,00000001 BTC : le satoshi).

Le réseau Lightning est beaucoup plus intéressant pour les micropaiements. Les frais sur les transactions normales rendent peu pratique l'envoi de petits montants sur la chaîne principale. Dans un canal, cependant, vous êtes libre d'envoyer une fraction de fraction de Bitcoin gratuitement.

Les micropaiements sont adaptés à de nombreux cas d'utilisation. Certains considèrent qu'ils pourraient être un remplaçant au modèle des abonnements, les utilisateurs payeraient des montants très très faible à chaque utilisation d'un service à la place d'un abonnement mensuel.

Confidentialité

Un autre avantage du Lightning Network est qu'il peut offrir à ses utilisateurs un haut degré de confidentialité. Les parties n'ont pas besoin de faire connaître leurs canaux au réseau plus large. Si vous pouvez regarder la blockchain et dire cette transaction a ouvert un canal, vous ne pourrez pas forcément dire ce qu'il se passe dans le canal. Si les participants décident de rendre leur canal privé, ils seront en effet les seuls à savoir les transactions ayant eu lieu.

Si Alice a un canal avec Bob et que Bob a un canal avec Carol, Alice et Carol peuvent s'envoyer des paiements l'une à l'autre via Bob. Si Dan est relié à Carol, Alice peut lui envoyer des paiements. On peut voir le Lightning Network comme un réseau tentaculaire de canaux de paiement interconnectés. Dans une telle configuration, vous ne pourriez pas être sûr de savoir à qui Alice a envoyé des fonds une fois que le canal est fermé.

Comment fonctionne le Lightning Network ?

Nous avons expliqué comment le réseau Lightning repose sur les canaux entre les nœuds à un niveau élevé. Jetons maintenant un coup d'œil sous le capot.

Adresses multisignatures

Une adresse multisignature (ou multisig) est une adresse à partir de laquelle plusieurs clés privées peuvent dépenser. En créant une multisig, vous devez indiquer combien de clés privés peuvent dépenser les fonds et combien sont requises pour signer une transaction. Par exemple, un schéma 1-5 signifie que cinq clés peuvent produire une signature valide et qu'une seule est nécessaire. Un schéma 2-3 indique que sur les trois clés, deux sont requises pour dépenser les fonds.

Pour initialiser un canal Lightning, les participants bloquent les fonds dans un schéma 2-2. Il n'y a que deux clés capables de signer, et celles-ci sont nécessaires pour déplacer leurs fonds. Faisons revenir nos amis Alice et Bob. Étant amenés à se faire de nombreux paiements dans les prochains mois, ils décident d'ouvrir un canal Lightning Network.

Pour commencer, ils déposent chacun 3 BTC sur l'adresse multisig détenue conjointement. Il est important de réitérer que Bob ne peut pas retirer les fonds de l'adresse sans l'aval d'Alice, et inversement.

Maintenant, ils pourraient juste garder une feuille de papier qui permettrait d'ajuster les soldes de chacun. Leur solde de départ respectif est de 3 BTC. Si Alice souhaite effectuer un paiement de 1 BTC à Bob, pourquoi ne pas faire une note indiquant qu'Alice possède maintenant 2 BTC et Bob 4 ? Les soldes peuvent être suvis comme ceci jusqu'à ce qu'ils décident de retirer les fonds.

C'est possible, mais où est le fun ? Plus important encore, cela ne permet-il pas à l'une des parties de facilement refuser la coopération ? Si Alice se retrouve au final avec 6 BTC et Bob 0, rien n'empêche Bob de refuser de débloquer les fonds (sauf peut-être son amitié avec Alice).

Contrats Hash Timelock (HTLC)

Le système ci-dessus est ennuyeux et n'offre pas grand-chose de plus que les configurations fiables d'aujourd'hui. La situation devient beaucoup plus intéressante lorsque nous introduisons un mécanisme qui fait respecter le « contrat » entre Alice et Bob. Si l'une des parties décide de ne pas jouer selon les règles, l'autre a encore un recours pour retirer ses fonds du canal.

Ce mécanisme est le Contrat Hash Timelock (ou HTLC). Si le terme peut faire peur, il s'agit d'un concept relativement simple à comprendre. Celui-ci utilise deux technologies (hashlock et timelock) pour remédier à tout comportement non coopératif dans le canal.

Un hashlock est une condition placée sur une transaction qui fait que vous ne pouvez dépenser des fonds qu'en prouvant que vous connaissez un secret. L'expéditeur hache un ensemble de données et inclut le hash dans la transaction du destinataire. Le récepteur ne peut le dépenser que s'il fournit les données originales (le secret) qui correspondent au hachage. Et la seule façon dont ils peuvent fournir ces données est que l'expéditeur les leur donne.

Une condition timelock empêche de dépenser les fonds avant une certaine date. Celle-ci est définit comme une heure réelle ou comme une hauteur de bloc.

Les HTLC représentent la combinaison des hashlocks et des timelocks. En pratique, les HTLC peuvent être utilisées pour créer des paiements conditionnels : le destinataire doit fournir un secret avant une certaine date, le cas échéant l'expéditeur pourra récupérer les fonds. Nous pourrons probablement mieux expliquer la section suivante avec un exemple, alors revenons à Alice et Bob.

Ouvrir et fermer des canaux

Nous avons donné l'exemple d'Alice et de Bob qui viennent de créer des transactions finançant l'adresse multisignature qu'ils vont partager. Mais ces transactions ne sont pas encore publiées sur la blockchain ! Il reste en effet une chose à faire avant.

Trois coins de Bob et 3 coins d'Alice.

Rappelez-vous que la seule façon pour ces coins de sortir du multisig est que Alice et Bob signent conjointement une transaction. Si Alice souhaite envoyer les six coins sur une adresse externe, elle aura besoin de l'accord de Bob. Elle a d'abord conclu une transaction (six bitcoins à cette adresse) et ajouté sa propre signature.

Elle pourrait essayer de diffuser immédiatement la transaction, mais celle-ci ne sera pas valide, Bob ne l'ayant pas signé. Alice doit d'abord lui donner la transaction incomplète. Une fois que Bob aura ajouté sa signature, la transaction devient valide.

Nous n'avons toujours pas mis en place un mécanisme permettant à chacun de collaborer honnêtement. Comme dit plus haut, si votre contrepartie refuse de coopérer, vos fonds seront effectivement piégés. Voyons ensemble le mécanisme qui empêche cela. Il y a plusieurs parties à étudier, alors veuillez bien suivre.

Chaque partie doit se présenter avec un secret – appelons-les simplement As et Bs. Ce serait de piètres secrets si Alice et Bob les révélaient, c'est pourquoi ils les maintiennent cachés pour l'instant. La paire générera le hachage des secrets respectifs : h(As) et h(Bs). À la place de partager leur secret, ceux-ci se partagent leur hachage.

Alice et Bob se partagent le hachage de leur secret.

Alice et Bob doivent également créer un ensemble de transactions d'engagement avant de publier leur première transaction à l'adresse de multisignature. Cela leur permettra de faire un recours au cas où l'autre déciderait de garder les fonds en otage.

Si vous considérez un canal comme le mini-registre dont nous avons parlé précédemment, les transactions d'engagement sont les mises à jour que vous effectuez sur le registre. Chaque fois que vous créez une nouvelle paire de transactions d'engagement, vous rééquilibrez les fonds entre les deux participants.

Celle d'Alice aura deux sorties : une qui paye une adresse qu'elle possède, et une autre qui est verrouillée dans une nouvelle adresse multisig. Elle signe et le donne à Bob.

La transaction d'Alice avec deux sorties : une vers sa propre adresse et une autre vers un nouveau multisig. Alice a encore besoin de la signature de Bob pour la rendre valide.

Bob fait de même : une sortie se paie, l'autre paie une autre adresse multisig. Il le signe et le donne à Alice.

Nous avons deux transactions incomplètes, mais similaires.

Alice pourrait normalement ajouter une signature à la transaction de Bob pour la rendre valide. Vous noterez cependant que ces fonds sont dépensés à partir du multisig 2 sur 2, que nous n'avons pas encore financé. C'est un peu comme si vous tentiez de dépenser un chèque depuis un compte n'ayant pas le solde nécessaire. Par conséquent, ces transactions partiellement signées ne sont utilisables qu'une fois le multisig opérationnel.

Les nouvelles adresses multisignatures (où sont destinées les 3 BTC) ont certaines propriétés spécifiques. Jetons un oeil à la transaction incomplète qu'Alice a signée et remise à Bob. La sortie multisig peut être dépensée dans les conditions suivantes :

Les deux parties peuvent le signer de manière coopérative.
Bob pourra ensuite les dépenser lui-même après une certaine période (en raison du timelock).
Alice peut les dépenser si elle connaît le secret de Bob Bs.

Pour la transaction où Bob a donné à Alice :

Les deux parties peuvent le signer de manière coopérative.
Alice peut les dépenser par elle-même après une certaine période de temps.
Bob peut les dépenser si il connaît le secret d'Alice As.

Gardez à l'esprit qu'aucune des parties ne connaît le secret de l'autre, le 3) n'est donc pas encore possible. Une autre chose à noter est que, si vous signez une transaction, votre contrepartie peut dépenser les fonds immédiatement, car il n'y a pas de conditions spéciales sur leur sortie. Vous pouvez soit attendre l'expiration du timelock pour dépenser les fonds par vous-même, soit coopérer avec l'autre partie pour pouvoir les dépenser directement.

Bien ! Vous pouvez maintenant publier les transactions dans l'adresse multisignature 2-2. Il est enfin possible de le faire en toute sécurité, car vous pouvez récupérer vos fonds si votre contrepartie abandonne le canal.

Une fois les transactions confirmées, le canal est opérationnel. Cette première paire de transactions nous montre l'état actuel du mini-registre. Actuellement, il paiera 3 BTC à Bob et 3 BTC à Alice.

Lorsque Alice veut effectuer un nouveau paiement à Bob, la paire crée deux nouvelles transactions pour remplacer la première série. Le principe est le même : elles ne sont qu'à moitié signées. Cependant, Alice et Bob doivent d'abord abandonner leur ancien secret et échanger de nouveaux hachages pour le prochain cycle de transactions.

Si Alice veut payer 1 BTC à Bob, les deux nouvelles transactions créditeront 2 BTC à Alice et 4 BTC à Bob. Le solde est ainsi à jour.

Chaque partie peut signer et diffuser à tout même l'une des transactions récentes pour la « régler » sur la blockchain. Cependant, quelle que soit la partie qui le fait, il lui faudra attendre l'expiration du timelock, tandis que l'autre pourra dépenser les fonds immédiatement. Rappelez-vous que si Bob signe et diffuse la transaction d'Alice, elle a maintenant une sortie sans condition.

Les deux parties peuvent décider de fermer le canal ensemble (une fermeture coopérative). Il s'agit probablement du moyen le plus simple et le plus rapide pour rapatrier les fonds sur la chaîne. Si une partie ne répond pas ou refuse de coopérer, l'autre peut toujours récupérer ses fonds en attendant le timelock.

Vous souhaitez vous lancer dans les cryptomonnaies ? Achetez du Bitcoin sur Binance !

Comment le Lightning Network empêche-t-il la triche ?

Vous avez peut être déjà identifié un vecteur d'attaque ici. Si Bob dispose d'un solde 1 BTC, qu'est-ce qui l'empêche de diffuser une transaction plus ancienne montrant qu'il possède plus de 1 BTC ? Il a déjà reçu la transaction semi-signée d'Alice, ne lui suffit-il pas d'ajouter sa signature avant de diffuser la transaction ?

Rien ne l'empêche de le faire, sauf peut être le fait qu'il pourrait perdre l'intégralité de son solde. Admettons qu'il aille jusqu'au bout et diffuse une ancienne transaction où il paye un BTC à Alice et cinq à l'adresse multisig que nous avons mentionnée précédemment.

Alice reçoit son BTC immédiatement. Bob, d'un autre côté, doit attendre que le timelock expire pour dépenser à partir de l'adresse multisig. Vous souvenez-vous de l'autre condition que nous avions mentionnée qui permet à Alice de dépenser ces fonds immédiatement ? Elle a besoin d'un secret qu'elle ne possède pas encore. Elle le fait maintenant : dès que la deuxième série de transactions a été créée, Bob lui a donné ce secret.

Alors que Bob attend, incapable de faire quoi que ce soit en attendant l'expiration du timelock, Alice peut déplacer ces fonds. Ce mécanisme basé sur la punition empêche les participants de tricher sous peine de perdre l'accès à leurs coins.

Acheminement des paiements

Nous avons indiqué plus tôt que les canaux peuvent être connectés. Si cela était impossible, le Lightning Network ne serait pas utile pour les paiements. Allez-vous vraiment verrouiller 500 $ sur un canal avec un magasin de café, juste pour obtenir votre dose quotidienne des prochains mois ?

Personne ne fait ça. Si Alice ouvre un canal avec Bob et que Bob a un Canal avec Carol, Bob peut acheminer les paiements entre les deux. Cela peut fonctionner sur plusieurs « sauts », ainsi Alice peut payer toute personne faisant partie de cette route.

Dans ce scénario, Alice peut emprunter plusieurs connexions pour se rendre jusqu'à chez Frank. En pratique, elle prendra toujours la plus facile.

Pour leur rôle dans l'acheminement, les intermédiaires peuvent exiger des faibles frais (mais ce n'est pas obligatoire). Le Lightning Network étant relativement nouveau, le marché des frais n'a pas encore été matérialisé. Ce que beaucoup attendent, ce sont des frais basés sur les liquidités fournies.

Sur la chaîne de base, vos frais sont uniquement basés sur l'espace que votre transaction occupe dans un block – la valeur transmise n'a pas d'importance – les paiements de 1 $ ou encore de 10 000 000 $ coûtent la même chose. En revanche, il n'y a pas d'espace de bloc dans le Lightning Network.

Au lieu de cela, il y a un concept d'équilibres locaux et distants. L'équilibre local est le montant que vous pouvez « pousser » vers l'extrémité du canal. L'équilibre distant est le solde que votre contrepartie peut vous pousser.

Voyons un autre exemple. Examinons de plus près la route ci-dessus : Alice <> Carol <> Frank.

Solde des utilisateurs avant et après un transfert de 0,3 BTC d'Alice à Frank.

Les transactions Alice <> Carol et Carol <> Frank ont chacune une capacité totale de 1 BTC. Le solde local d'Alice est de 0,7 BTC. Si les transactions étaient réglées maintenant sur la blockchain, Alice aurait 0,7 BTC et Carol recevrait le solde distant (0,3 BTC).

Si Alice veut envoyer 0,3 BTC à Frank, il lui suffit de transmettre 0,3 BTC à Carol grâce au canal. Carol transmet ensuite 0,3 BTC de sa balance locale à Frank grâce au canal. Ainsi, le solde de Carol reste le même : les +0,3 BTC d'Alice et les -0,3 BTC pour Frank s'annulant.

Carol ne perd pas de valeur en agissant à titre de connexion entre Frank et Alice, mais perd néanmoins en flexibilité. Vous voyez, elle peut maintenant dépenser 0,6 BTC dans son canal avec Alice, mais seulement 0,1 BTC dans le canal avec Frank.

On peut aussi imaginer une situation où Alice n'est connectée qu'à Carol, alors que Frank est connecté à un réseau beaucoup plus large. Carol, qui pouvait auparavant envoyer un total de 0,4 BTC à d'autres personnes par l'intermédiaire de Frank, ne peut désormais envoyer que 0,1 BTC, car c'est tout ce dont elle dispose sur son extrémité du canal.

Dans ce scénario, Alice ponctionne effectivement la dans liquidité de Carol. Sans aucune récompense, Carol ne voudra peut-être pas affaiblir sa propre position. Ainsi, au lieu de cela, elle pourrait simplement dire : je vais acheminer chaque 0,01 BTC à un tarif de dix satoshisDe cette façon, plus Carol sacrifie son solde local dans des chemins plus « forts », elle en profite.

Comme dit précédemment, il n'y a pas d'obligation de facto de facturer des frais. Certains peuvent ne pas être préoccupés par la réduction de la liquidité. D'autres peuvent simplement ouvrir des canaux directement vers le récepteur.

Limites du Lightning Network

Cela serait tout simplement fantastique si le Lightning Network s'avérait être la solution à tous les problèmes de scalabilité de Bitcoin. Malheureusement, il possède également ses propres défauts.

Utilisabilité

Bitcoin n'est pas le système le plus intuitif pour les débutants : les adresses et les frais sont des concepts difficiles à aborder. Mais les portefeuilles peuvent faire abstraction des aspects compliqués pour offrir aux utilisateurs quelque chose qui ressemble vaguement aux systèmes de paiement existants. Vous pouvez néanmoins faire en sorte que quelqu'un télécharge un portefeuille pour smartphone, envoie des fonds et se tienne prêt pour la suite.

Cela est actuellement impossible pour le Lightning Network. Les options sont encore très limitées en ce qui concernant les applications smartphone : en général, les nœuds Lightning exigent l'accès à un nœud Bitcoin pour pouvoir être utilisés.

Une fois qu'un client a fait sa configuration, les utilisateurs doivent commencer à ouvrir des canaux avant de pouvoir faire des paiements. En plus de prendre du temps, cela est rapidement pénible pour un débutant de devoir comprendre des concepts tels que la capacité entrante/sortante.

Cela dit, des améliorations sont constamment apportées afin de réduire les obstacles à l'entrée pour offrir aux utilisateurs une expérience plus simple.

Liquidité

L'une des principales critiques à l'égard du Lightning Network est que votre capacité à effectuer des transactions est limitée. Vous ne pouvez pas dépenser plus que ce que vous avez verrouillé dans un canal. Si vous dépensez tous vos fonds afin que le solde à distance dispose de tous les fonds du canal, vous devrez le fermer. Vous pouvez aussi attendre que quelqu'un vous paie pour le faire, mais ce n'est pas l'idéal.

Vos connexions sont également limitées par la capacité totale du canal. Reprenons notre exemple de la connexion Alice <> Carol <> Frank. Si Alice et Carol ont une capacité de 5 BTC sur leur canal, mais que Carol et Frank n'ont qu'une capacité de 1 BTC, Alice ne pourra jamais envoyer plus de 1 BTC. Même dans ce cas, il faudrait que la totalité du solde soit du côté de Carol (sur le canal Carol <> Frank) pour que cela fonctionne. Cela peut limiter considérablement le montant des fonds qui peuvent être transmis par les canaux LN et a donc un impact sur sa praticité.

Centralisation des hubs

En raison du problème mentionné dans la section précédente, il existe également une crainte que le réseau ne facilite la création de gros « hubs ». C'est-à-dire des entités importantes, fortement connectées et disposant de beaucoup de liquidités. Tous les paiements importants devront être acheminés via certaines de ces entités.

Ce n'est évidemment pas quelque chose de positif. En effet, cela affaiblirait le système, car une simple mise hors ligne de ces entités impacterait grandement l'ensemble des relations entre pairs. Le risque de censure est également accru, les transactions ne circulant plus qu'à travers quelques entités.

État actuel du Lightning Network

Depuis avril 2020, le Lightning Network semble bien se porter. Celui-ci compte en effet plus de 12 000 nœuds actifs, plus de 30 000 canaux ouverts et plus de 920 BTC de capacité.

Répartition mondiale des nœuds Lightning Network. Source : explorer.acinq.co

Il existe plusieurs implémentations de nœuds : c-lightning de Blockstream, Lightning Network Daemon de Lightning Labs et Eclair d'ACINQ font partie des plus populaires. De nombreuses entreprises proposent des nœuds prêts à l'emploi aux utilisateurs moins expérimentés. La seule chose que vous devez faire avec ces appareils est de les mettre sous tension et vous voilà prêt à utiliser le Lightning Network.

Pour conclure

Depuis le lancement de son réseau principal en 2018, le Lightning Network a connu une croissance impressionnante. Néanmoins de nombreuses personnes le considère comme étant encore en phase bêta.

Il reste encore quelques obstacles à surmonter sur le plan de utilitaire, l'utilisation d'un nœud Lightning demandant actuellement un certain degré de compétences techniques. Mais compte tenu de l'ampleur du développement en cours, nous pourrions bien voir les barrières à l'entrée se réduire dans les prochaines années.

Si ces problèmes peuvent être résolus, le Lightning Network pourrait devenir une partie intégrante de l'écosystème Bitcoin et améliorer considérablement sa scalabilité et la vitesse de ses transactions.