Lightning Network

Lightning Network

Le Lightning Network est un canal de paiement off-chain verrouillé dans le temps. Cela signifie que les utilisateurs peuvent fixer des BTC off-chain, c’est-à-dire en dehors de la blockchain Bitcoin, et les envoyer à d’autres utilisateurs. L’envoi de valeurs se fait de manière quasi instantanée et ne nécessite, comme pour les transactions on-chain, aucune instance tierce digne de confiance. Le Lightning Network est considéré comme une solution d’échelle prometteuse pour Bitcoin.

L’affaire de l’échelle

Le bitcoin est censé être un système de monnaie électronique dans lequel les participants peuvent s’envoyer directement de l’argent. Un système monétaire qui n’est pas contrôlé par un centre, mais qui repose sur un protocole informatique. En théorie, ce système monétaire devrait être accessible à tous les habitants de la planète. Cela permettrait d’avoir un standard monétaire universel ; une « langue » commune à toute l’humanité.

Mais la théorie n’est pas si facile à transposer dans la réalité. Même si le bitcoin est déjà un système de monnaie électronique sans intermédiaires de contrôle, il ne peut pas être utilisé par tout le monde. La raison en est l’échelle requise.

Le problème devient évident si l’on imagine le nombre de transactions qui ont lieu chaque jour dans l’économie mondiale. Alors que la technologie Bitcoin peut facilement transférer des sommes gigantesques, elle atteint ses limites lorsqu’il s’agit d’une fréquence élevée de transactions. La raison est d’ordre technique : la blockchain, sur laquelle sont enregistrées toutes les transactions, n’offre qu’un espace limité pour les transactions.

On peut se représenter cela un peu comme un bus. Ce bus a un nombre limité de sièges. Si tous les sièges sont pleins, il n’y a pas d’autres personnes qui peuvent monter. Il en va de même pour les blocs de la chaîne de blocs Bitcoin. Eux aussi n’ont qu’un nombre limité de « sièges » pour les transactions. Lorsque tous les sièges sont occupés, plus aucune transaction ne peut « monter » (c’est-à-dire être confirmée).

L’un des mécanismes de Bitcoin est que les transactions peuvent s’assurer une place dans le bus grâce à leurs frais de transaction. Cela signifie que si Alice veut envoyer une transaction super importante à Bob, qui doit en tout cas trouver une place dans le prochain bus, elle peut payer une taxe plus élevée que la moyenne. Le « chauffeur du bus » (le mineur) n’est pas obligé de laisser la transaction monter, mais il peut gagner un joli penny en plus s’il le fait. Il a donc une incitation économique à laisser de la place à la transaction dans son bus.

Tout va bien, n’est-ce pas ? Pas encore, car que se passe-t-il si tout le monde le fait ? La place sur la blockchain, la place dans le prochain bloc, dans le prochain bus, est fermement limitée. Si de plus en plus de personnes veulent utiliser le système monétaire Bitcoin, si de plus en plus de transactions veulent se bousculer dans le bus, alors les frais de transaction augmentent. En effet, les transactions sont en concurrence les unes avec les autres pour une place sur la blockchain en raison de leurs frais. En décembre 2017, on a pu voir un exemple de cette montée en flèche des frais de transaction.

Combien de transactions le bitcoin peut-il traiter par seconde ?

Une métrique souvent citée lorsqu’il s’agit de la fonctionnalité de Bitcoin est le nombre de transactions par seconde. La taille maximale d’un bloc de Bitcoin est de 1 mégaoctet. Une transaction moyenne a une taille de 400 octets. Cela signifie qu’en moyenne, 2 500 transactions tiennent dans un bloc. Un nouveau bloc est trouvé toutes les 10 minutes environ. Par conséquent, le système Bitcoin peut traiter environ 4 transactions par seconde.

Combien de transactions par seconde la concurrence du bitcoin peut-elle effectuer ?

Pour avoir un peu de perspective sur la capacité de Bitcoin, nous comparons les transactions par seconde avec deux alternatives attrayantes ; Visa et Paypal. Alors que la chaîne de blocs Bitcoin atteint sa limite à plus de quatre transactions par seconde, PayPal peut traiter jusqu’à 115 transactions par seconde. Le leader du marché, Visa, effectue même sans problème 2.000 transactions par seconde, voire 4.000 en période de pointe. Mais selon ses propres dires, Visa peut faire bien plus : jusqu’à 56.000 transactions par seconde seraient possibles. Comment le bitcoin peut-il rivaliser avec cela et devenir un système de paiement mondial ?

Deux nuances doivent toutefois être mentionnées dans cette discussion : La taille des transactions et la finalité d’une transaction.

En Bitcoin, peu importe pour les frais et le réseau qu’un montant de 0,001 BTC ou de 10.000 BTC soit envoyé. Ce qui compte, c’est le nombre d’entrées et de sorties de la transaction. Avec les systèmes de paiement alternatifs comme Visa et PayPal, on paie généralement un pourcentage du montant de la transaction. L’envoi de gros montants est donc coûteux.

La finalité de la transaction décrit la possibilité d’annuler la transaction. Avec Bitcoin, cela est très difficile : une fois qu’une transaction a été envoyée et écrite dans un bloc, il est quasiment impossible de l’annuler. C’est un avantage, car les vendeurs peuvent ainsi être sûrs que le client prétendument amical ne les trompe pas par la suite. Il en va autrement avec PayPal et Visa : il existe ici une période (généralement de 30 à 120 jours) pendant laquelle le paiement peut être annulé. C’est possible parce que PayPal ou Visa sont l’autorité centrale du système monétaire. Ils déterminent l’historique des transactions et peuvent également les modifier ultérieurement.

Ainsi, alors que le bitcoin est à la traîne en termes de fréquence des transactions, cette technologie peut déjà marquer des points massivement en termes de taille des transactions et de finalité financière.

Solutions pour la mise à l’échelle : on-chain vs. off-chain

La question de la capacité de transaction est souvent appelée la question de l’échelle. Au fond, elle a pris entre-temps le même caractère que la question de Gretchen dans le Faust de Goethe :

« Alors, dis-moi, qu’est-ce que tu fais de l’échelle ?

En principe, les réponses peuvent être divisées en deux camps : Échelle on-chain et échelle off-chain.

L’approche des représentants On-Chain, pour reprendre l’exemple du bus, est d’augmenter la taille du bus. C’est-à-dire de limiter les blocs à 1 mégaoctet, une nouvelle limite supérieure est fixée pour le bloc. Ainsi, davantage de transactions tiennent dans le bus, qui continue à partir toutes les 10 minutes. En supposant que la taille du bloc passe à 10 mégaoctets, le nombre de transactions par seconde est multiplié par 10. Cela signifie qu’il serait alors possible de traiter environ 40 transactions par seconde. La manière d’améliorer la capacité de la chaîne de blocs en augmentant la taille des blocs se traduit par le Bitcoin Hard Fork Bitcoin Cash (BCH).

L’alternative est le « Off Chain Scaling ». Dans ce cas, on ne souhaite pas améliorer la capacité de transaction de la chaîne de blocs elle-même, mais créer un deuxième niveau pour les transactions, qui se rattache au premier niveau, à la chaîne de blocs. Ce deuxième niveau (en anglais : Second Layer) hériterait des aspects de sécurité du bitcoin et permettrait en outre une magnitude de transactions supplémentaires. Ainsi, au lieu d’évoluer de manière linéaire comme dans l’approche « on-chain », le deuxième niveau permettrait de traiter des millions de transactions. Et ce, immédiatement, pour des montants très faibles et avec une sécurité similaire à celle du système Bitcoin lui-même. Cette méthode de mise à l’échelle du bitcoin en dehors de la chaîne de blocs répond également au nom de Lightning Network.

Le Lightning Network

Pour de nombreux représentants de Bitcoin, le Lightning Network (en abrégé : LN) est la prochaine évolution logique du système de paiement Bitcoin. On peut se représenter l’architecture comme un gâteau avec plusieurs couches. La blockchain Bitcoin est la base, ou ce que l’on appelle la couche de base. Le Lightning Network s’appuierait sur cette couche. Certaines caractéristiques de la couche de base pourraient être héritées, comme par exemple la sécurité, tandis que d’autres limites ne s’appliqueraient plus, notamment le nombre limité de transactions.

Le lien entre la couche de base et le Lightning Network est réalisé par une série de mécanismes cryptographiques.

Canaux de paiement – la base du Lightning Network

Les canaux de paiement (Payment Channels) sont au cœur du Lightning Network. Un canal de paiement peut être considéré comme un tunnel entre deux parties, Alice et Bob. Il relie donc directement Alice et Bob. La différence entre un canal de paiement et une transaction sur la blockchain est que les paiements à l’intérieur du tunnel ne sont pas enregistrés sur la blockchain. Au lieu de cela, Alice et Bob peuvent continuer à mettre à jour l’état du canal de paiement et n’écrire le dernier état sur la blockchain que lorsqu’ils ont « terminé ». La mise à jour du canal de paiement se fait en dehors de la blockchain et n’est pas liée à ses limites. Alice et Bob pourraient renouveler l’état de leur canal plusieurs fois par seconde. En d’autres termes, les microtransactions deviennent non seulement possibles, mais aussi plausibles.

Celui qui veut comprendre le Lightning Network devrait donc, dans un premier temps, comprendre les canaux de paiement.

Canaux de paiement unidirectionnels

Le canal classique ou canal de paiement existe entre deux participants (pairs), Alice et Bob. Pour ce canal, on utilise la technologie multisignature Bitcoins et ce que l’on appelle un locktime. Les transactions multisignatures permettent de générer des transactions qui nécessitent plus d’une clé privée pour signer une transaction. Dans le cas des canaux de paiement, on génère des transactions multisignature 2-2. Cela signifie que les bitcoins associés à cette transaction nécessitent l’accord des deux parties pour être envoyés. Le locktime veille à ce que, pendant une durée déterminée, les coins ne soient pas transférables au sein du multisig.

Un canal de paiement unidirectionnel n’envoie de l’argent que dans un sens. Donc de A vers B, pas dans l’autre sens.

Imaginons un exemple tiré du monde réel : Bob tient un magasin de café où Alice achète un café chaque matin. Pour qu’Alice ne doive pas écrire à chaque fois une transaction dans la blockchain, ce qui prend relativement longtemps et coûte cher. Elle ouvre donc un canal de paiement avec Bob. Pour cela, elle envoie un certain montant, dans notre exemple 10.000 satoshi, à une adresse 2-2 multi-sig. Alice contrôle une clé privée et Bob l’autre. Pour qu’une transaction valide puisse être inscrite dans la blockchain, Alice et Bob doivent tous deux signer la transaction.

La transaction qui ouvre le canal de paiement est aussi appelée transaction de financement. Elle est inscrite dans la blockchain et reliée. La transaction de financement indique le montant maximal pouvant être dépensé.

De plus, Alice apporte une deuxième transaction qui, après un mois, renvoie automatiquement les 10.000 satoshi à son adresse. C’est sa garantie. Ainsi, en cas de problème avec Bob, Alice reçoit son argent en retour au bout d’un mois. Bob pourrait donc « garder en otage » les 10.000 satoshi pendant un mois maximum – pas pour toujours.

D’une part, Alice a maintenant ouvert un canal de paiement avec Bob, d’autre part, elle a la garantie de récupérer son argent au plus tard dans un mois. Comment fonctionne maintenant ce canal de paiement ?

Lorsqu’Alice se rend le matin chez Bob au café, elle a 10.000 satoshi dans le canal de paiement et Bob a zéro satoshi. Alice paie son café en mettant à jour le niveau du canal. Pour cela, elle crée une transaction dans le portefeuille multi-sig qui ne lui enverrait plus que 9.000 satoshi et Bob 1.000 satoshi. Elle signe cette transaction et l’envoie à Bob. Bob a maintenant une transaction signée d’Alice pour le multi-portefeuille 2-2 sig. Cela signifie qu’il pourrait décider d’ajouter également sa signature et d’écrire cette transaction (9.000 satoshi à Alice, 1.000 à Bob) dans la blockchain. Mais il ne le fait pas, car il sait qu’Alice reviendra demain. La certitude d’avoir déjà un chèque signé d’Alice lui suffit. Il peut le signer lui-même à tout moment avant la fin du locktime et l’écrire ensuite dans la blockchain Bitcoin comme une transaction normale.

Le lendemain matin, Alice se rend à nouveau au magasin pour acheter du café. Elle paie à nouveau via le canal de paiement. Elle crée donc une nouvelle transaction dans le portefeuille multi-sig qui ne lui envoie plus que 8.000 satoshi et en échange 2.000 satoshi à Bob. Elle signe cette transaction et remet le chèque métaphorique à Bob. Cette mise à jour incrémentielle peut se poursuivre jusqu’à ce que le lock time soit écoulé. Ou jusqu’à ce qu’Alice n’ait plus d’argent à dépenser dans le canal.

C’est dans ce contexte que s’explique le terme « off chain ». Alice paie Bob avec des bitcoins, mais ces paiements ne touchent pas directement la blockchain. Ils ont lieu en dehors de la blockchain (off chain).

L’avantage est donc qu’Alice peut acheter son café chaque matin. Elle ne le fait pas avec une transaction sur la blockchain, mais avec un chèque pour Bob, que ce dernier peut encaisser à tout moment. Auparavant, Alice doit charger une sorte de compte prépayé, duquel elle peut ensuite déduire les différentes transactions. Lorsque Bob encaisse le chèque ou lorsque le lock time expire, le canal de paiement est fermé. Une transaction est inscrite dans la blockchain et distribue l’argent restant en conséquence à Alice et Bob.

Seules deux transactions sont inscrites dans la blockchain. Une transaction qui a financé le multi-sig wallet et une transaction qui ferme le canal de paiement. Mais entre ces 2 transactions sur la blockchain, un million ou plus de petites transactions auraient pu avoir lieu entre Alice et Bob.

Lorsqu’un canal de paiement est fermé, on parle de transaction de règlement. La transaction de règlement est inscrite dans la blockchain et reliée.

Jusqu’à présent, nous n’avons toutefois considéré qu’un canal de paiement unidirectionnel. C’est-à-dire lorsqu’Alice envoie uniquement de l’argent à Bob (comme elle vient d’acheter un café). Mais si le tout doit également fonctionner dans l’autre sens, les choses se compliquent un peu.

Commitments – Quand les canaux doivent aller dans les deux sens

Pour que les bases du Lightning Network soient posées, il faut des canaux de paiement bidirectionnels.

Un canal de paiement bidirectionnel est un canal où l’argent peut circuler dans les deux sens.

Seulement, ces canaux de paiement doivent également être établis « sans confiance ». Cela signifie que les deux parties ne peuvent rien gagner par la fraude et qu’il n’y a pas besoin d’une tierce partie qui arbitre.

Un scénario serait par exemple que Bob écrive sur la blockchain un ancien état du canal de paiement. Si Alice avait déjà accepté le paiement dans le canal de paiement et que Bob avait remis une marchandise ou fourni un service, elle aurait ainsi été escroquée de son argent. Cela ne doit évidemment pas se produire. C’est pourquoi les canaux de paiement bidirectionnels nécessitent une étape supplémentaire. Une protection cryptographique doit être mise en place pour les deux parties afin que les participants ne puissent pas revenir impunément sur les anciens états des canaux de paiement.

[RecapInformation complémentaire] Pourquoi ce scénario ne pose-t-il pas de problème pour les canaux de paiement unidirectionnels ? Dans le cas du canal de paiement unidirectionnel, seule Alice verse de l’argent à Bob. Pour cela, elle remet toujours à Bob un chèque signé par elle et indiquant l’état actualisé du canal. A aucun moment Alice ne reçoit un chèque signé de Bob. Cela signifie qu’elle ne peut pas effectuer de transaction à partir du portefeuille multi-sig, car elle a besoin de deux signatures pour cela. Bob, quant à lui, ne fait que gagner plus d’argent avec de nouvelles transactions. Dans son propre intérêt économique, il n’écrirait pas d’ancien état dans la blockchain, car cela signifierait qu’il recevrait moins de bitcoins que ce qu’Alice lui a en fait transféré. Dans les canaux de paiement unidirectionnels, il est donc toujours préférable pour Bob de publier l’état le plus récent.

Les canaux de paiement bidirectionnels sont structurés et sécurisés de la manière suivante :

Alice et Bob veulent établir un canal de paiement bidirectionnel. Pour cela, les deux parties doivent d’abord se mettre d’accord sur une transaction d’ouverture (transaction de financement) avec les montants respectifs. Autrement dit, combien chacun verse dans le canal. Dans notre exemple, Alice verse un satoshi de 10.000 et Bob ne verse rien. Alice envoie les 10.000 satoshi à un porte-monnaie 2-2 multi-sig. Pour ce portefeuille, Alice a une clé et Bob a l’autre. Pour qu’une transaction soit valable sur la blockchain, les deux doivent donc la signer. Si Bob disparaît, Alice peut récupérer l’argent après un certain temps.

Maintenant, Alice veut utiliser le canal de paiement et envoyer 1.000 satoshi à Bob. Pour cela, un deuxième multi-sig wallet entre en jeu. Une fois que la transaction de financement a eu lieu, Alice crée une nouvelle transaction dans laquelle elle envoie 9.000 satoshi à une adresse qu’elle contrôle et 1.000 satoshi au nouveau multi-sig wallet. Pour ce nouveau multi-sig wallet, deux signatures sont à nouveau nécessaires. L’une appartient à Alice, l’autre est une nouvelle adresse temporaire de Bob. De plus, cette transaction a un verrou temporel, c’est-à-dire qu’elle ne peut être émise qu’après une période de temps écoulée. Jusqu’ici tout va bien. Bob pourrait maintenant décider de signer avec sa signature temporaire et de fermer ainsi le canal de paiement. Ou il peut attendre la prochaine mise à jour du canal de paiement.

Bob souhaite maintenant envoyer 500 satoshi à Alice via le même canal. Pour cela, il doit révéler sa signature précédente en partageant la clé privée correspondante avec Alice. Il crée ensuite une nouvelle transaction dans laquelle Alice reçoit 500 Satoshi et 500 Satoshi sont toujours envoyés à Bob. Pour cette transaction, une nouvelle signature temporaire d’Alice et une signature de Bob sont nécessaires. Cette transaction est à nouveau verrouillée dans le temps, de sorte que Bob reçoit la totalité de ses 1000 satoshi si Alice ne réagit pas.

Mais, comme il s’agit d’un canal de paiement bidirectionnel, une étape doit être franchie avant la transaction d’engagement. Il faut imaginer et échanger le secret, la pré-image.

Dans la pratique, c’est le portefeuille qui s’en charge et l’utilisateur ne remarque pas grand-chose du processus. En général, on peut toutefois se représenter les choses ainsi. L’application Wallet génère un grand nombre aléatoire. C’est la pré-image. Ensuite, l’application de portefeuille hache la pré-image. C’est le hash. Avant que le canal de paiement ne puisse vraiment démarrer, les deux participants créent donc une telle pré-image et le hash correspondant. Ils échangent ce hash entre eux. Tout est maintenant prêt pour le canal de paiement bidirectionnel.

Alice envoie maintenant 10.000 satoshi à Bob en signant à nouveau un chèque pour le portefeuille multi-sig. Ce chèque lui verse 49 990 000 satoshi et Bob 50 010 000 satoshi. Il s’agit donc d’une transaction d’engagement. Mais cette transaction est particulière, car elle est assortie d’un Hashed Timelock Contract. Cela signifie qu’Alice utilise d’une part le hash que Bob lui a donné et dit « celui qui peut prouver qu’il connaît la pré-image correspondant à ce hash peut résoudre le HTLC ». L’autre façon d’effectuer une transaction est de laisser passer un certain temps. Dans le cas d’un HTLC, ce temps est exprimé en nombre de blocs (un bloc dure environ 10 minutes).

Bob peut ainsi obtenir son argent à tout moment. Pour cela, il résout le canal de paiement dans une transaction de règlement en présentant sa pré-image dans la transaction. Alice ne peut pas le faire, car elle ne connaît pas la pré-image. Si Bob ne coopère pas avec Alice et essaie de « garder l’argent en otage », il ne peut le faire que jusqu’à l’expiration du verrou temporel. S’il n’a pas fermé le canal et revendiqué son argent d’ici là, Alice pourra à nouveau récupérer tout son argent.

Lorsque la balance est modifiée dans un canal de paiement, c’est-à-dire qu’une partie abandonne plus de bitcoin, on parle également de transaction d’engagement. Les transactions d’engagement ne sont pas écrites dans la blockchain.

Lightning Network – Les canaux deviennent un réseau

Nous avons maintenant compris les bases techniques du Lightning Network. Mais comment passe-t-on d’un canal de paiement bidirectionnel entre Alice et Bob à un réseau entre tous les participants ?

Un Hashed Timelock Contract (HTLC) est une classe de transaction qui doit remplir une certaine condition pour être valable. Plus précisément, l’émetteur doit soit fournir une preuve cryptographique, soit attendre une certaine date.

Le HTLC se compose de deux éléments : d’une part, le secret et, d’autre part, un verrou temporel. Le secret est un nombre aléatoire qui est haché à l’aide d’une fonction de hachage. Le nombre original utilisé pour générer le hachage est également appelé Pre Image.

La Pre Image est un nombre aléatoire qui sert de secret pour un HTLC. Celui qui connaît la Pre Image pour un HTLC possède la preuve cryptographique pour effectuer une transcription.

Jusqu’à présent, les participants devaient créer un nouveau canal pour chaque nouvelle activité de paiement. Ainsi, si Alice voulait faire des affaires avec Carol, les deux partenaires commerciaux devaient établir un canal de paiement. Le Lightning Network intervient ici – les paiements pourraient être acheminés via les différents participants. Au lieu qu’Alice établisse un nouveau canal avec Carol, elle utilise plutôt les canaux existants entre elle et Bob, et entre Bob et Carol. Bob agit dans ce cas comme une étape intermédiaire, un hop, entre Alice et Carol.

Lightning Network

Le Lightning Network est un réseau routé de canaux de paiement bidirectionnels de bout en bout. Cela signifie que les participants peuvent s’envoyer des paiements de canal à canal sans devoir passer par un intermédiaire.

Le lecteur critique se pose ici des questions : « Attention, l’argent passe d’Alice à Carol via Bob – n’est-ce pas exactement le modèle fiduciaire que Bitcoin veut remplacer » ?

Le Lightning Network n’est pas un modèle fiduciaire basé sur la confiance. En effet, même si le paiement fait son chemin jusqu’à Carol via Bob, ce dernier n’a à aucun moment le contrôle de l’argent d’Alice. Cela est rendu possible par une cryptographie avancée. C’est précisément le mécanisme des canaux de paiement bidirectionnels sans confiance, les Hashed Timelock Contracts (HTLC).

Ce processus garantit que personne ne peut tricher dans la chaîne des canaux de paiement, ou que la fraude n’en vaut pas la peine. Voici comment cela fonctionne : Carole invente un secret, à nouveau un nombre aléatoire. Carol en transmet le hash à Alice. Ce hash devient alors un gage : Bob reçoit un paiement s’il connaît le secret. Alice peut le vérifier à l’aide du hash. Bob transmet le hash – à nouveau avec la promesse de payer si le destinataire découvre le secret. En principe, le chemin entre Alice et Carol peut comporter d’autres participants qui utilisent tous le hash comme gage, mais dans l’illustration, on a simplement formé un réseau simple de trois parties.

Les HTLC permettent de relier entre eux des canaux de paiement entre différentes parties. On peut le voir : Les participants au réseau qui, en tant que nœuds, forment un pont entre Alice et Carol, sont l’épine dorsale du Lightning Network. Leur importance peut être comparée à celle des mineurs sur la blockchain régulière.

Hop

La blockchain continue de jouer un rôle central pour le règlement final des paiements et donc pour le consensus global. Il est secondaire qu’il s’agisse effectivement de la blockchain Bitcoin : le Lightning Network peut également interagir avec d’autres crypto-monnaies comme par exemple le Litecoin. C’est ainsi que l’on peut enfin réaliser des Atomic Swaps. Ici, on ouvre un canal dont on stocke le règlement final sur différentes blockchains.

  • indépendamment du fait que Carol et Bob aient déjà échangé des bitcoins entre eux ou non. Le peer-to-peer serait déformé à l’extrême et donc absolument inefficace. Une approche consisterait à ce que les participants à différents canaux de paiement se transmettent des transactions. Alice pourrait envoyer de l’argent à Carol par l’intermédiaire de Bob. La question est de savoir si l’on peut faire confiance à Bob. D’une part, il pourrait s’approprier l’argent et tout simplement ne pas le transmettre, d’autre part, le Lightning Node de Bob pourrait tomber en panne.

Défis avec le Lightning Network

L’implémentation pratique du Lightning Network est encore loin d’être prête pour que cette technologie puisse être utilisée par un grand nombre de personnes. Actuellement, le réseau se trouve dans une phase expérimentale. Pour l’utiliser, il est essentiel d’avoir une bonne compréhension de la technique. Mais même dans ce cas, il est possible de perdre son propre bitcoin. En bref, même si l’approche et l’idée sont déjà claires, il reste encore de nombreux chantiers.

L’un des plus grands chantiers – et l’une des critiques les plus souvent formulées contre le Lightning Network – est sans doute le routage. Si un réseau est constitué de canaux de paiement, le paiement doit trouver son chemin à travers le réseau. Cependant, la méthode de routage n’est pas spécifiée dans le livre blanc du Lightning Network. Les critiques du Lightning Network estiment qu’il s’agit là d’un problème insoluble. En effet, de nouveaux nœuds seraient constamment mis en ligne et d’autres seraient mis hors ligne. La seule condition d’être en ligne pour recevoir une transaction en décourage plus d’un d’utiliser le Lightning Network. Ainsi, il s’agirait d’un pas en arrière plutôt qu’en avant, car avec le bitcoin, le destinataire n’a pas besoin d’être en ligne pour recevoir des paiements.

Le statut technologique du Lightning Network est donc encore immature. Pour une large adaptation, la technologie doit être simple et sûre à utiliser. Dans le meilleur des cas, l’utilisateur ne remarque même pas qu’il interagit avec le Lightning Network et les canaux de paiement. Toutefois, il faudra probablement attendre encore quelques années avant d’en arriver là. Enfin, l’expérience pourrait aussi échouer.

Lightning Network expérimenté dans son propre portefeuille

Le Lightning Network n’est pas encore terminé. Il existe certes plus de 2.000 Lightning Nodes. Néanmoins, il n’est pas garanti que deux utilisateurs puissent effectivement établir un canal de paiement. Il reste donc encore beaucoup à faire. Fidèle à la devise « Be your own bank », chacun peut y contribuer : Les plus ambitieux peuvent mettre en place leur propre Lightning Node (https://github.com/Stadicus/guides/tree/master/raspibolt).

Mais il est également possible de profiter du Lightning Network sans télécharger l’ensemble de la blockchain. Ceux qui veulent expérimenter rapidement peuvent utiliser HTLC.me comme portefeuille web. Avec Zap et la Lightning App, il existe deux portefeuilles de bureau. Enfin, avec Eclair, il existe même déjà un portefeuille mobile pour les utilisateurs d’Android. Comme décrit ailleurs, il existe avec Coingate un service qui permet d’autoriser rapidement des transactions via le Lightning Network dans son propre webstore.

On voit que les choses bougent.

Termes associés

  • SegWit (Segregated Witness).
Token Boost

Commencez à trader dès maintenant

Investissez dans les cryptos et trader vos devises numériques sur les différentes plateformes.

Laisser un commentaire

Crypto logo

Token Boost, votre e-magazine français 100% crypto & DeFi.

Contact

54, impasse Toussaint, Lorainville