Guide du débutant pour le Lightning Network de Bitcoin
Accueil
Articles
Guide du débutant pour le Lightning Network de Bitcoin

Guide du débutant pour le Lightning Network de Bitcoin

DĂ©butant
Publié le Nov 28, 2018Mis à jour le May 15, 2024
20m

Points clés à retenir

  • Les solutions de couche 2 ont Ă©tĂ© crĂ©Ă©es pour rĂ©pondre aux limites inhĂ©rentes Ă  l’évolutivitĂ© de la technologie blockchain.

  • Le rĂ©seau Lightning Network est une solution de mise Ă  l’échelle de couche 2 qui offre des transactions rapides sans avoir besoin de confirmation de bloc, ce qui permet des micropaiements efficaces.

  • Il garantit des paiements sĂ©curisĂ©s et Ă©volutifs via des adresses multisignatures et des contrats Hash Timelock.

Introduction

Les cryptomonnaies ont des propriĂ©tĂ©s assez uniques. Celles-ci ne peuvent pas facilement ĂȘtre hackĂ©es ou dĂ©sactivĂ©es 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. Étant donnĂ© que de nombreux nƓuds sont responsables du fonctionnement du rĂ©seau d’une cryptomonnaie, 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 technologie blockchain, un certain nombre de solutions d’évolutivitĂ© 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 rĂ©seau Lightning Network.

Qu’est-ce que le Lightning Network ?

Le rĂ©seau Lightning Network est un rĂ©seau fonctionnant 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 l’ont Ă©galement intĂ©grĂ©.

Vous vous demandez peut ĂȘtre ce que nous voulons dire par « fonctionnant au-dessus d’une blockchain ». Le Lightning Network est ce que l’on appelle une solution hors de la blockchain ou couche 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 blockchain principale. Pour entrer ou sortir du rĂ©seau 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 ce que l’on appelle 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 pourrait Ă©crire dans le registre « j’ai payĂ© 1 BTC Ă  Bob». Bob aurait dĂ©sormais 6 BTC. De son cĂŽtĂ©, Alice n’en aurait plus que 4. Bob peut ensuite dĂ©cider d’envoyer 2 BTC Ă  Alice, mettant de ce fait Ă  jour les soldes de la sorte : Alice possĂšde dĂ©sormais 6 BTC et Bob uniquement 4. Nos deux protagonistes peuvent continuer Ă  faire ces manipulations 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 blockchain.

FidĂšles Ă  leur nom, les transactions Lightning sont rapides comme l’éclair. Il n’y a pas besoin d’attendre la confirmation du bloc pour que les paiements 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 (abrĂ©gĂ© en « LN ») semble ĂȘtre l’approche la plus rĂ©aliste pour amĂ©liorer l’évolutivitĂ© 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 vous Ă©loignez cette expĂ©rimentation de la blockchain, vous gagnez en flexibilitĂ©. Si quelque chose se passe mal, cela n’aura aucune rĂ©percussion sur le rĂ©seau Bitcoin. Les solutions de couche 2 ne remettent pas en cause les hypothĂšses de sĂ©curitĂ© qui ont permis au protocole de fonctionner pendant plus de 15 ans.

Il n’y a pas non plus d’obligation de changer l’ancienne façon de faire les choses. Les transactions sur la blockchain continuent de fonctionner pour l’utilisateur final, mais celui-ci a dĂ©sormais la possibilitĂ© d’effectuer des transactions hors de la blockchain.

L’utilisation du rĂ©seau Lightning Network prĂ©sente plusieurs avantages. En voici quelques unes. 

L’évolutivitĂ©

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 qu’il vous faut disputer. Vous affrontez en effet les autres utilisateurs pour que vos transactions soient incluses dans les plus brefs dĂ©lais. 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. Toutefois, lorsque trop d’utilisateurs diffusent des transactions simultanĂ©ment, les frais moyens peuvent augmenter considĂ©rablement. Il y a eu plusieurs occasions oĂč ceux-ci ont dĂ©passĂ© les 10 $. Au plus haut du marchĂ© haussier de 2017, ils ont mĂȘme dĂ©passĂ© les 50 $. En avril 2021, les frais de transaction moyens ont mĂȘme dĂ©passĂ© les 60 $.

Cela peut sembler insignifiant pour des transactions de plusieurs milliers de dollars en Bitcoin, mais ce n’est pas viable pour de petits paiements. Qui veut payer 10 $ de frais pour un cafĂ© Ă  seulement 3 $ ?

Avec le rĂ©seau Lightning Network, vous devez toujours payer deux frais : un pour ouvrir le canal et un 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.

Les micropaiements

Le montant minimal 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 38 centimes. C’est un montant plutĂŽt faible, mais le Lightning Network vous permet de pousser la limite jusqu’à la plus petite unitĂ© possible (0,00000001 BTC, soit un 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 blockchain principale. Dans un canal, cependant, vous ĂȘtes libre d’envoyer une partie d’une fraction de Bitcoin gratuitement.

Les micropaiements sont adaptĂ©s Ă  de nombreux cas d’utilisation. Certains considĂšrent qu’ils pourraient remplacer les modĂšles de souscriptions, les utilisateurs payeraient des montants extrĂȘmement faible Ă  chaque utilisation d’un service Ă  la place d’un souscription mensuelle.

La 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 en son sein.

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 privĂ©es capables de signer, et celles-ci sont nĂ©cessaires pour dĂ©placer des cryptomonnaies. Retournons Ă  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 suivis comme ceci jusqu’à ce qu’ils dĂ©cident de retirer les fonds.

C’est possible, mais oĂč est l’amusement ? 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 combine 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 hachage dans la transaction envoyĂ©e au destinataire. Le destinataire 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 il peut fournir ces donnĂ©es est que l’expĂ©diteur les lui 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 dĂ©terminĂ©e.

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 tokens de Bob et trois tokens d’Alice.

Trois tokens de Bob et trois tokens d’Alice.

Rappelez-vous que la seule façon pour ces cryptomonnaies de sortir du multisig est qu’Alice et Bob signent conjointement une transaction. Si Alice souhaite envoyer les six cryptos sur une adresse externe, elle aura besoin de l’accord de Bob. Elle devra d’abord rĂ©aliser une transaction (six bitcoins Ă  cette adresse) et ajouter 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 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.

Celui 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 la 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.

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.

Nous avons deux transactions incomplĂštes, mais similaires.

Alice pourrait normalement ajouter une signature Ă  la transaction de Bob pour la rendre valide. Vous remarquerez 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 :

  1. Les deux parties peuvent le signer de maniÚre coopérative.

  2. Bob pourra ensuite les dĂ©penser lui-mĂȘme aprĂšs une certaine pĂ©riode (en raison de la condition timelock).

  3. Alice peut les dépenser si elle connaßt le secret de Bob Bs.

Pour la transaction oĂč Bob a donnĂ© Ă  Alice :

  1. Les deux parties peuvent le signer de maniÚre coopérative.

  2. Alice peut les dĂ©penser par elle-mĂȘme aprĂšs une certaine pĂ©riode de temps.

  3. Bob peut les dĂ©penser s’il connaĂźt le secret d’Alice As.

Gardez Ă  l’esprit qu’aucune des parties ne connaĂźt le secret de l’autre, la condition 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 de la pĂ©riode (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 originale. 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, celui-ci 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.

 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 blockchain. Si une partie ne rĂ©pond pas ou refuse de coopĂ©rer, l’autre peut toujours rĂ©cupĂ©rer ses fonds en attendant la fin de la pĂ©riode de verrouillage (timelock).

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 de 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 de cette idĂ©e et diffuse une ancienne transaction oĂč il paye 1 BTC Ă  Alice et 5 à 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 la pĂ©riode de verrouillage (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 rĂ©vĂ©lĂ© 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 cryptos.

Acheminement des paiements

Nous avons indiquĂ© plus tĂŽt que les canaux peuvent ĂȘtre connectĂ©s. Si cela Ă©tait impossible, le rĂ©seau 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 de cafĂ©ine lors 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.

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 petits frais (mais ce n’est pas obligatoire). Le rĂ©seau 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 blockchain de base, vos frais sont uniquement basĂ©s sur l’espace que votre transaction occupe dans un bloc, la valeur transmise n’a pas d’importance, des paiements de 1 $ ou 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 de soldes locaux et distants. Le solde local est le montant que vous pouvez « pousser » vers l’extrĂ©mitĂ© du canal. Le solde distant est le solde que votre contrepartie peut vous pousser.

Examinons 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.

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 son solde local Ă  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é. Celle-ci peut en effet 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 liquiditĂ© de Carol. En l’absence de contrepartie, Carol ne voudra peut-ĂȘtre pas affaiblir sa propre position. Pour rĂ©soudre ce problĂšme, elle pourrait simplement dire : je vais acheminer chaque 0,01 BTC Ă  un tarif de dix satoshis. De cette façon, plus Carol sacrifie son solde local dans des chemins plus « forts », plus elle est rĂ©compensĂ©e.

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 d’évolutivitĂ© de Bitcoin. Malheureusement, il possĂšde Ă©galement ses propres dĂ©fauts. 

FacilitĂ© d’utilisation

Bitcoin n’est pas le systĂšme le plus intuitif pour les dĂ©butants : les adresses et les frais sont par exemple des concepts difficiles Ă  aborder. 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 rĂ©seau 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 distant 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 des rĂ©percussions sur sa facilitĂ© d’utilisation.

Centralisation des pĂŽles

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 « pĂŽles ». 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 aurait de grandes rĂ©percussions sur 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 rĂ©seau Lightning Network

En date du mois de mars 2024, le Lightning Network semble bien se porter. Celui-ci compte en effet plus de 13 000 nƓuds actifs, plus de 52 000 canaux ouverts et plus de 4 570 BTC de capacitĂ©.

RĂ©partition mondiale des nƓuds Lightning Network. Source : explorer.acinq.co

RĂ©partition mondiale des nƓuds Lightning Network.

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.

Conclusion

Depuis son lancement sur le rĂ©seau principal en 2018, le rĂ©seau Lightning a connu une croissance significative. 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.

Pour plus d’informations

Avis de non-responsabilitĂ© et avertissement concernant les risques : ce contenu vous est prĂ©sentĂ© « tel quel » Ă  des fins d’information gĂ©nĂ©rale et pĂ©dagogiques uniquement, sans reprĂ©sentation ni garantie d’aucune sorte. Il ne doit pas ĂȘtre interprĂ©tĂ© comme un conseil financier, juridique ou venant d’un professionnel, ni comme un moyen de recommander l’achat d’un produit ou d’un service spĂ©cifique. Vous devriez vous renseigner auprĂšs des professionnels appropriĂ©s avant toute dĂ©cision. Lorsque l’article Ă  Ă©tĂ© rĂ©digĂ© par un contributeur tiers, veuillez remarquer que les opinions de l’article ne reflĂštent pas nĂ©cessairement celles de Binance Academy. Veuillez lire l’intĂ©gralitĂ© de notre avis de non-responsabilitĂ© ici pour en savoir plus. Les cours des actifs numĂ©riques peuvent ĂȘtre volatils. La valeur de votre investissement peut varier Ă  la baisse ou Ă  la hausse, et vous ne rĂ©cupĂ©rerez peut-ĂȘtre pas le montant que vous avez investi. Vous ĂȘtes seul(e) responsable de vos dĂ©cisions d’investissement et Binance Academy n’est pas responsable des pertes que vous pourriez subir. Ce contenu ne doit pas ĂȘtre interprĂ©tĂ© comme un conseil financier, juridique, ou venant d’un professionnel. Pour en savoir plus, veuillez vous reporter Ă  nos Conditions d’utilisation et Ă  l’avertissement concernant les risques.