Pourquoi le réseau Bitcoin Lightning ne fonctionne pas

Je suppose donc que je devrais commencer par un avertissement  : j’aime vraiment le Lightning Network. C’est l’une de mes parties préférées de la pile de protocoles Bitcoin et je l’ai suivie d’assez près pendant des années. Si Lightning n’existait pas, je posséderais toujours Bitcoin, mais je serais beaucoup moins optimiste quant à son avenir potentiel. Je ne vois pas beaucoup d’alternatives réelles à la mise à l’échelle qui n’impliquent pas les dépositaires, la confiance et l’érosion des propriétés de l’autosouveraineté pour la plupart des personnes les plus pauvres du spectre de la richesse.

À un niveau élevé, un canal Lightning est aussi simple que cela  :

• Deux personnes bloquent de l’argent dans une adresse multisig 2 sur 2.
• Les deux parties organisent une transaction pré-signée qui leur rendrait leur argent avant le financement.
• Pour mettre à jour le solde, les deux parties signent une nouvelle transaction avec le solde mis à jour et échangent des « clés de pénalité » pour permettre à l’autre partie de prendre tout l’argent de l’adresse multisig si quelqu’un essaie d’utiliser une ancienne transaction pré-signée

Mais le Lightning Network est bien plus que quelques connexions directes entre deux parties. Ces canaux uniques peuvent être enchaînés avec d’autres canaux uniques pour former un vaste réseau de paiement interconnecté. C’est un système très flexible qui permet des paiements entre des parties autrement non connectées. Cela étant dit, je vois de nombreux inconvénients et limitations qui ne sont pas vraiment reconnus ou évoqués en dehors des groupes de développeurs et des utilisateurs plus techniques.

Problèmes de gestion de l’État

Un canal Lightning n’est en réalité qu’un ensemble de transactions pré-signées – ce que je n’ai pas abordé, c’est le modèle d’incitation qui permet à cela de fonctionner. Une fois qu’une transaction est signée, vous ne pouvez plus la reprendre. Il existe et sera toujours une transaction Bitcoin valide à moins que vous ne dépensiez ce bitcoin avec une transaction différente (vous ne pouvez pas dépenser du bitcoin deux fois ; une fois qu’une transaction dépense du bitcoin, toute autre transaction qui essaie d’agir sur ces pièces sera invalide). Maintenant, étant donné qu’un canal Lightning est un multisig 2 sur 2, aucune des parties ne peut signer une nouvelle transaction sans la coopération de l’autre. Cela signifie que vous ne pouvez pas invalider toutes les autres transactions pré-signées que vous avez effectuées sur la chaîne sans la coopération de l’autre partie. Vous avez ouvert cette chaîne ensemble, vous devez donc la mettre à jour ensemble. Si l’une ou l’autre des parties pouvait agir unilatéralement, l’un d’entre vous pourrait simplement voler tous les fonds.

Chaque fois que les parties échangent des fonds dans leur canal Lightning – Bob envoie 1000 sats à Alice -, elles génèrent une nouvelle transaction pré-signée qui reflète leurs soldes mis à jour. Si chaque partie joue bien, elle ne conservera que la dernière transaction pré-signée, car les précédentes ne refléteront plus les soldes corrects. Et si les deux parties souhaitent encaisser, elles peuvent utiliser la transaction pré-signée la plus récente pour payer à chaque partie son solde actuel sous forme de bitcoin en chaîne.

Mais que se passe-t-il si l’autre partie ne joue pas bien ? Que se passe-t-il si Bob a dépensé sa part des fonds en les envoyant à Alice mais souhaite maintenant encaisser en utilisant une transaction pré-signée antérieure qui montrait toujours tous les fonds de son côté de leur canal ? Nous contournons cela avec des touches de pénalité. Ceux-ci vous permettent d’invalider efficacement toutes les transactions pré-signées antérieures sans avoir à les invalider réellement en chaîne à chaque fois.

L’idée est qu’une fois que les deux parties ont remplacé l’ancienne transaction pré-signée par une nouvelle qui met à jour les soldes, elles échangent également des clés de pénalité. Le système est conçu pour que si l’un d’eux essaie d’exécuter une ancienne transaction, la clé de pénalité de l’autre partie est activée et peut être utilisée pour réclamer 100% des fonds dans le canal. Surtout, les transactions pré-signées ont un timelock intégré, donc il y a toujours une fenêtre d’opportunité pour l’autre partie d’utiliser la clé de pénalité avant que la transaction puisse être confirmée dans un bloc Bitcoin. Vous n’invalidez pas réellement les transactions pré-signées existantes, vous incitez simplement l’autre partie à ne pas les utiliser. S’ils l’essayent et que vous les attrapez, vous gardez tout leur argent.

Cela introduit une dynamique de mise à l’échelle qui, je pense, n’est pas bien comprise par les utilisateurs moins techniques. Chaque fois que l’un de vous dépense un seul satoshi, vous remplacez une transaction pré-signée par une nouvelle. Mais vous devez toujours conserver des informations sur chaque ancienne transaction – ainsi que la clé de pénalité associée à cette transaction spécifique – au cas où vous deviez l’utiliser pour punir une contrepartie de canal malhonnête. Il n’y a aucun moyen d’échapper à cela, car si une contrepartie de canal essaie de fermer le canal avec une ancienne transaction, vous avez besoin de la clé de pénalité de cette transaction exacte afin de les arrêter et de les punir. Cela signifie que vous devez conserver toutes les données pertinentes pour chaque transaction que vous avez effectuée avec eux.

les disques durs sont bon marché ». Examinons toutes les différentes manières dont cette dynamique peut causer des problèmes. Avant cela, je tiens à rappeler à tout le monde une hypothèse de base de Lightning  : l’idée d’ouvrir un canal est de le garder ouvert aussi longtemps que possible pour maximiser la valeur qu’il en retire avant d’encourir des frais sur la chaîne. Donc, idéalement, vous voulez ouvrir un canal et le garder ouvert très longtemps.

téléchargent de la musique, des vidéos, des applications et des jeux, etc. Je suis sûr que la plupart d’entre vous sont habitués à devoir effacer un tas de choses du stockage parce que vous manquez d’espace. Les données que votre portefeuille Lightning doit stocker continueront de croître pour toujours (jusqu’à ce que vous fermiez vos canaux) tant que vous effectuez des transactions. Finalement, cela entrera en conflit avec d’autres choses que vous souhaitez stocker sur votre téléphone et, après cela, commencera éventuellement à dépasser les limites de stockage supérieures de votre téléphone. Et rappelez-vous, vous devez absolument conserver 100% de ces données ou votre canal Lightning pourrait ne pas être ouvert en toute sécurité.

Considérons maintenant les nœuds de routage. Tout est dans le nom; ce sont des nœuds qui sont configurés pour être les autoroutes du réseau Lightning, acheminant activement des tonnes de paiements sur leurs canaux soigneusement gérés. Même logique de base, bien que dans ce cas, il soit beaucoup plus probable que quelqu’un ait acquis un appareil juste pour exécuter son nœud Lightning. Mais bien sûr, un nœud de routage mettra à jour les soldes de canaux beaucoup plus fréquemment, de sorte que le taux de croissance dépassera de loin celui d’un portefeuille mobile s’il s’agit d’un nœud de routage réussi. Notez également que plus vous devez stocker de données critiques, plus il est coûteux de les stocker de manière redondante afin que la panne de l’appareil ne conduise pas à une perte d’argent.

Enfin, la zone où je pense que cette dynamique pose vraiment problème : les tours de guet. La plupart des gens ne pourront pas être en ligne 24h/24 et 7j/7 pour s’assurer que leur contrepartie n’essaie pas de les tromper. C’est ici qu’intervient une tour de guet ; ils regardent les choses pour vous. Mais pour ce faire, ils doivent stocker toutes les mêmes données que vous pour pouvoir pénaliser votre contrepartie s’ils trichent. Les tours de guet sont encore à peine développées ou déployées, mais à long terme, elles constituent une infrastructure absolument essentielle pour que les gens puissent utiliser le réseau Lightning en toute sécurité.

Les tours de guet peuvent fonctionner de trois manières. Tout d’abord, une tour de guet altruiste qui n’obtient rien en échange de la surveillance de la chaîne pour vous. Deuxièmement, une tour de guet qui n’est payée que si votre contrepartie triche et qu’elle doit la pénaliser. Enfin, une tour de guet qui est payée juste pour stocker des données et surveiller la chaîne. Étant donné que les données par utilisateur continueront de croître indéfiniment jusqu’à la fermeture d’un canal, voyez-vous le problème ? Dans les deuxième et troisième modèles, les frais pour un utilisateur commenceront à s’ajouter pour couvrir les coûts de stockage des données de la tour de guet plus un canal est ouvert longtemps. Ce serait une sorte de frais cachés que les utilisateurs devraient payer et qui pourraient atteindre des niveaux absurdes.

je ne suis pas d’accord.

Heureusement, ce problème serait résolu avec une proposition de mise à niveau du protocole Bitcoin appelée ANYPREVOUT et des canaux Lightning basés sur eltoo, ce qui permettrait à une seule donnée de taille constante d’accomplir le même mécanisme de dissuasion que les clés de pénalité font actuellement. Mais jusqu’à ce que cette fonctionnalité soit intégrée à Bitcoin, les canaux Lightning actuels ont ce problème de mise à l’échelle.

Problèmes HTLC

Les deux problèmes majeurs suivants tournent autour des HTLC (Hashed Timelock Contracts). Ce sont de nouvelles sorties ajoutées aux transactions pré-signées qui disent « si vous connaissez un secret, vous pouvez réclamer l’argent, sinon l’expéditeur peut le récupérer après une période d’attente ». Ils utilisent des hashlocks et des timelocks. C’est ainsi que les paiements sont transférés en toute confiance sur plusieurs sauts via le réseau Lightning ; soit le destinataire final libère le secret et tous ceux qui ont aidé à transférer le paiement via leurs canaux peuvent réclamer ce qui leur est dû, soit le destinataire ne divulgue pas le secret et après une période d’attente, tout le monde est remboursé.

Cette structure a des implications pour la mise à l’échelle de deux manières, 1) le nombre de HTLC qu’un canal peut transmettre à tout moment, et 2) la valeur minimale pour un HTLC car ils doivent finalement être économiques à régler en chaîne en cas de perturbation.

vous ne pouvez transférer que des paiements qui sont finalement soutenus par des sorties spécifiques en chaîne sur lesquelles votre chaîne a des réclamations prouvables. Et parce que les transactions Bitcoin elles-mêmes ont des limites de taille maximales, il en va de même pour le nombre de HTLC qu’une transaction peut avoir (483). Si une transaction avait plus de HTLC que cela, ce ne serait pas une transaction Bitcoin valide et laisserait donc le canal dans un état étrange où chaque transaction pré-signée qui était valide (celles construites avant que la limite de 483 n’ait été atteinte) permettrait le une autre personne pour voler votre argent et aucune des transactions pré-signées actuelles (celles construites après la limite de 483) ne pourrait être utilisée pour fermer le canal honnêtement. À moins qu’une solution à ce problème ne soit trouvée, il présente un plafond supérieur du nombre de HTLC pouvant passer par un nœud Lightning à la fois, ce qui finira par créer un plafond supérieur inégal sur le nombre de HTLC que l’ensemble du réseau Lightning peut transmettre à tout moment. moment.

La dynamique en chaîne est également prise en compte dans la valeur d’un HTLC. Si un HTLC ne transfère que 10 satoshis, mais que l’ajout de la sortie HTLC coûterait 100 satoshis en frais en chaîne, pouvez-vous vraiment appliquer cela en chaîne si vous devez le faire ? Non. Parce que l’appliquer sur la chaîne vous ferait perdre de l’argent, il n’y a aucune incitation économique à l’appliquer, et il n’y a vraiment pas de raison rationnelle pour faire le HTLC en premier lieu dans cet environnement à frais élevés. Les frais sont susceptibles de continuer à augmenter à long terme, ce qui affectera la valeur qui peut être rationnellement acheminée sur le réseau Lightning avec les HTLC.

Il existe une solution à ce problème, mais elle comporte ses propres compromis et inconvénients  : les paiements par paquets. L’idée est qu’au lieu d’acheminer un paiement avec une chaîne de HTLC en une seule fois, vous le divisez en plusieurs paiements individuels qui n’utilisent pas de HTLC. Cela vous permet de transmettre encore et encore une infime fraction du paiement au destinataire prévu jusqu’à ce qu’il soit terminé. Mais comme il n’y a pas de HTLC, n’importe lequel de vos petits paquets de paiement peut être complètement arraché. Si une partie du paiement échoue, vous pouvez arrêter d’utiliser l’itinéraire actuel et en trouver un autre à essayer. Le problème est que si une partie du paiement échoue, vous ne savez pas qui blâmer le long de la chaîne de routage. Vous devez donc reconstruire un nouvel itinéraire à partir de zéro, en ne faisant confiance à personne dans l’itinéraire précédent. Cela ne fonctionne pas bien dans un environnement conflictuel.

Latence de paiement

Une fois lorsque le paiement est configuré à l’aide des HTLC et une fois de plus lorsque le HTLC est compensé et réglé. Cela introduit une sorte de dynamique de « maillon le plus faible » en termes de rapidité avec laquelle un paiement peut réellement être réglé. Vous pouvez le remarquer si vous êtes un utilisateur fréquent de Lightning ; Parfois, les portefeuilles prennent quelques secondes (ou dans les mauvais cas, plusieurs secondes) avant qu’un paiement ne soit effectué et met à jour le solde. Le seul portefeuille léger que je connaisse est Breez, qui peut prendre de 5 à 20 secondes d’après mon expérience pour passer après avoir cliqué sur envoyer.

Actuellement, cela ne représente rien de plus qu’une légère friction UX, semblable à celle de devoir se tenir maladroitement devant une caisse enregistreuse en attendant qu’un achat par carte de crédit soit autorisé. Mais rappelons la proposition de paiements par paquets évoquée plus haut pour traiter la question des montants trop faibles pour utiliser les HTLC. En tant que très petit réseau en pleine croissance poussant des montants sans micropaiement avec les HTLC, cette latence présente un problème notable. Imaginez maintenant si au lieu de deux rondes de signature pour un seul HTLC, vous aviez des centaines de rondes de signature pour pousser le même paiement divisé en montants individuels de la taille d’un micropaiement.

Cela devient un problème beaucoup plus important en termes d’expérience utilisateur à ce stade, mais également un goulot d’étranglement de mise à l’échelle pour les nœuds de routage. Les opérations de signature cryptographique sont très rapides et bon marché dans le sens absolu, mais dans un monde où Lightning est simultanément conçu pour faciliter toutes sortes de cas d’utilisation de micropaiement et de paiement en continu et les paiements plus conventionnels plus importants doivent également être divisés en flux de la taille d’un micropaiement. de sats, cela devient également un gros goulot d’étranglement pour les nœuds de routage. Cette dynamique à long terme pourrait très bien tuer l’idée d’exécuter un nœud de routage rentable (ou même suffisamment fiable pour être largement utilisé) sur du matériel bon marché tel qu’un Raspberry Pi ou d’autres ordinateurs monocarte.

Viabilité du nombre de canaux

Les HTLC ne sont pas la seule chose sur le Lightning Network qui est fortement affectée par la fluctuation ou l’augmentation constante des frais en chaîne. Les canaux de foudre eux-mêmes sont également victimes de cette dynamique. Supposons que vous souhaitiez ouvrir un canal Lightning d’une capacité de 10 $ de BTC, mais les frais en chaîne pour cette transaction coûteront 1 $. Cette chaîne a des frais de 10% pour l’établir en premier lieu. Cependant, si vous financez une chaîne avec 100 $, votre taux de frais effectif n’est que de 1%. Cela crée un marché très réel pour les personnes essayant d’interagir directement avec le Lightning Network. Si le taux de frais effectif pour l’ouverture d’un canal est trop élevé, ils n’ouvriront pas ce canal.

Le seul véritable compromis ou solution à cette dynamique est le temps. Si vous n’avez que 10 $ au lieu de 100 $ et que vous ne voulez pas payer de frais de 10 %, vous soumettez votre transaction d’ouverture de canal avec des frais inférieurs. Et tu attends. La durée de cette attente dépendra du marché des frais Bitcoin en temps réel et de l’arriéré du mempool (les mineurs de Bitcoin sélectionnent les transactions les plus payantes du mempool jusqu’à ce que leur bloc candidat soit plein). Dans une bonne situation, l’attente pourrait se résumer à quelques heures supplémentaires. Dans une mauvaise situation, vous pourriez avoir à attendre des jours ou des semaines. En période de demande de transaction extrême, le mempool peut même purger les transactions les moins chères, garantissant que votre canal ouvert ne se produit jamais. Avec le fonctionnement actuel des canaux Lightning, ce jeu d’attente est vraiment la seule solution à ce problème.

Des taux de frais effectifs élevés ont une autre implication  : les délais utilisés pour garantir que quelqu’un peut pénaliser une ancienne transaction pré-signée devraient être beaucoup plus longs pour les canaux de faible valeur qui ne veulent pas payer un taux de frais effectif élevé. L’intérêt du timelock est que vous pouvez efficacement sauter la file d’attente et battre votre partenaire de distribution pour réclamer les fonds. Mais si vous n’êtes pas disposé ou en mesure de payer les frais potentiellement élevés pour que votre demande s’exécute rapidement, vous devez coder le temps d’attente supplémentaire pour votre transaction lente et peu coûteuse dans vos transactions pré-signées. Au fil du temps, cela entraînera probablement des attentes beaucoup plus longues pour l’ouverture et la fermeture des canaux de faible valeur en chaîne et nécessitera des périodes de verrouillage beaucoup plus longues pour garantir que ces propriétaires de canaux de faible valeur ne perdent pas d’argent à cause du vol en cas d’attaque malveillante. contrepartie du canal.

Selon Tor

L’un des principaux inconvénients de Lightning devrait être connu même des utilisateurs les moins techniques : vous devez être en ligne pour l’utiliser car l’envoi et la réception sont un processus interactif. Cela signifie que les pairs ont besoin d’adresses IP pour pouvoir se parler. Devoir exposer votre adresse IP à vos pairs de canal est un gros problème de confidentialité et aussi potentiellement un problème de censure si les FAI veulent fouiner pour savoir quelles adresses IP se parlent.

Tor est à peu près la solution incontournable pour traiter ce problème actuellement. Le problème avec ça, c’est que Tor a ses propres problèmes. Il s’appuie sur une autorité de réputation entièrement basée sur la confiance et gérée par des bénévoles. Ces « serveurs d’annuaire » sont gérés par les membres du projet et sont l’endroit où votre nœud Tor trouve tous les autres pairs sur le réseau avec lesquels construire des circuits Tor. La fiabilité de ces entités est la base qui vous permet de passer par des nœuds Tor qui n’ont pas connaissance de tout le chemin parcouru par vos informations à travers le réseau.

Il existe également de nombreuses vulnérabilités d’attaque auxquelles Tor est soumis. Les attaques par déni de service distribué (DDoS) sont beaucoup plus difficiles à gérer dans Tor que sur Internet au sens large. Il existe des services professionnels qui gèrent les pics de trafic massifs sur Internet ordinaire. Le trafic peut également être refusé à partir de points de terminaison malveillants sur Internet non protégé. Mais dans le réseau Tor, de par sa conception, vous ne savez pas d’où vient le trafic, les attaques DDoS sont donc beaucoup plus difficiles à gérer. Il s’agit en fait d’un problème tellement systémique que les développeurs de Tor envisagent actuellement l’intégration de jetons anonymisés ou de preuves de travail comme le hashcash afin de faire face à ces vecteurs d’attaque. Le réseau étant si vulnérable à ces types d’attaques remet en question la fiabilité des nœuds Lightning fonctionnant sur Tor.

La faiblesse la plus fondamentale de l’interaction de Tor avec Lightning est encore plus importante que le risque de perturbations du réseau ou de devoir faire confiance aux autorités de l’annuaire Tor. Les connexions Tor sont triviales à identifier, donc votre FAI ou votre gouvernement pourrait simplement bloquer entièrement la possibilité de se connecter à Tor. Évidemment, dans la plupart des pays du monde, cela n’arrive pas, mais cela pourrait facilement. Et le plus triste à ce sujet, c’est que les endroits où cela aurait le plus de chances de se produire sont les pays autoritaires où il serait le plus nécessaire de protéger votre vie privée. La Chine bloque Tor et l’Iran a fait des tentatives qui ont été rejetées avec succès par les développeurs de Tor. La Russie et la France au cours de la dernière décennie ont toutes deux abordé le sujet du blocage de Tor pour différentes raisons : la pédopornographie dans le cas de la Russie et de la France en réponse à des attentats terroristes.

Ce sont en quelque sorte des nœuds Tor spéciaux qui ne s’annoncent pas aussi publiquement que des nœuds normaux pour permettre aux utilisateurs qui ne peuvent pas accéder directement à Tor de se connecter via ces nœuds de pont. Mais les nœuds de pont ne sont pas non plus à l’abri d’être attaqués, identifiés et bloqués. En fin de compte, si les États-nations ou les FAI veulent faire pression sur le réseau Tor, ils le peuvent, et cela devient un jeu du chat et de la souris qui dégrade encore plus la fiabilité de Tor comme moyen d’effectuer des paiements Bitcoin rapides et transparents en privé.

Conclusion

Le Lightning Network est un bond en avant vraiment incroyable pour la pile de protocoles Bitcoin. Il s’agit d’une extension d’évolutivité du mécanisme de règlement de la blockchain qui crée des gains de débit exponentiels au lieu de se fier uniquement à la blockchain elle-même pour traiter les transactions. Mais tout comme la blockchain elle-même, elle a ses limites. Ce n’est pas une solution miracle, ce n’est pas une solution à tous les problèmes, ce n’est pas sans ses propres défauts. Et c’est bien.

Cela signifie que les Bitcoiners reconnaissent les lacunes réalistes des choses et recherchent des solutions. Ce n’est pas du FUD, ou une attaque, c’est une bonne chose. C’est ainsi que quelque chose devient plus fort et évolue, en reconnaissant ses limites actuelles et en cherchant des moyens de les dépasser.

Ceci est un article invité par Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC, Inc. ou Bitcoin Magazine.