Qu’est-ce que le réseau Lightning? On parle généralement des analogies, des métaphores ou des explications directes de l’objectif.
- «C’est le compte courant, par rapport à la chaîne comme compte d’épargne.»
- « C’est une série de tubes comme Internet, avec Bitcoin qui les traverse. »
- «C’est une couche rapide et instantanée de Bitcoin.»
Ce que c’est vraiment un réseau de canaux de paiement, où les gens verrouillent le bitcoin dans une adresse multisignature et mettent à jour l’état des distributions de solde hors chaîne. C’est ainsi que nous allons mettre à l’échelle Bitcoin – ou au moins une partie de la façon dont nous allons mettre à l’échelle Bitcoin.
Dans la courte série «explicatrice» dans ce magazine, j’explique la mécanique de comment Lightning fonctionne: comment les transactions pré-signées qui composent un canal Lightning fonctionnent, comment les paiements sont acheminés sur le réseau, les façons dont la liquidité est gérée, etc. Lisez-les, et vous devriez avoir une solide compréhension des mécanismes sous-jacents qui font fonctionner le réseau Lightning.
Le problème est, quand il s’agit de demander quoi Le réseau Lightning est que toutes ces pièces individuelles sont modulaires et remplaçables. Et si nous structurions différemment les transactions pré-signées? Ou si nous utilisons un mécanisme différent pour acheminer les paiements à travers le réseau? Qu’en est-il de repenser totalement la façon dont nous sélectionnons même les itinéraires pour les paiements en premier lieu?
Et si nous les remplacions tous au fil du temps, afin qu’aucune des pièces individuelles du protocole ou du réseau ne soit la même? Est-ce toujours le réseau Lightning? Comme le navire de Thésée, le navire est-il toujours du navire de Thésée après que chaque planche et vis ait été remplacée?
Le réseau Lightning est-il toujours le réseau Lightning si nous changeons comment toutes les pièces individuelles fonctionnent?
Conceptions de canaux
Les canaux de foudre sont des ensembles de transactions pré-signées. Le but de ces transactions est de s’engager et de donner aux utilisateurs un mécanisme à appliquer, une distribution d’équilibre d’un UTXO partagé sur lequel aucune des parties n’a de contrôle unilatéral.
Ces canaux, ou transactions, prennent actuellement la forme d’un canal Poon-Dryja. Ces transactions utilisent le mécanisme clé de révocation inventé par Tadge Dryja dans le livre blanc du réseau Lightning Original. Il s’agit d’une structure de transaction très spécifique pour un canal de paiement, mais ce n’est en aucun cas le seul.
Regardons un concept appelé «Timeout Trees» pour regarder quelque chose avec des différences minimales par rapport à la façon dont les canaux fonctionnent actuellement.
Un arbre de délai d’attente est l’une des formes les plus élémentaires possibles de canaux multipartites (un canal avec plus de deux membres). Un fournisseur de services Lightning (LSP) crée un arbre de transactions qui se ramifient à partir d’un seul UTXO sur chaîne, et se terminant le long de chaque branche avec un canal Lightning entre le LSP et certains utilisateurs. Chaque arbre a un temps d’expiration, après quoi l’UTXO sur chaîne (ou l’un des intermédiaires entre elle et les canaux de foudre) peut être dépensé unilatéralement par le LSP. L’idée est que les utilisateurs peuvent simplement échanger leurs fonds à partir de canaux de l’arbre expirant à un nouveau avant ce point, et laisser le LSP récupérer la liquidité qu’elle a verrouillée avec ses utilisateurs après l’expiration.
Ceci a été proposé en tant que cas d’utilisation pour CheckTempPeolify (CTV), un OPCode qui empêche un UTXO d’être dépensé autrement que la transaction qui correspond à un hachage prédéfini; En principe, cela pourrait être fait sans qu’il utilise des transactions pré-signées avec le compromis de l’introduction de plus de complexité de coordination et de risque d’échec à initialiser un arbre.
Les canaux de foudre fonctionneraient essentiellement de la même manière que les canaux Poon-Dryja, mais devaient également inclure toutes les transactions supplémentaires pré-signées impliquées dans le déplacement de l’arbre et soumis à l’heure d’expiration de l’arbre dans son ensemble.
Est-ce que c’est la foudre? Ou est-ce autre chose?
Qu’en est-il de la symétrie LN? Il s’agit d’une proposition utilisant CTV et ChecksigFromStack (CSFS), un OPCode qui vous permet de vérifier une signature par rapport aux données arbitraires dans une transaction pour remplacer complètement la clé de révocation et le mécanisme de révocation.
Au lieu du système de révocation, la symétrie LN crée le concept d’une transaction de signature flottante ou flottante. Le script LN-Symetry a deux façons de le dépenser, soit une branche CTV verrouillant les dépenses à la transaction représentant la distribution de solde pour cet état de canal, soit une branche CTV + CSFS qui permet à toute transaction de correspondant à un modèle CTV signé par une clé spécifique définie dans le script les dépenser. Ceci, en combinaison avec l’utilisation de différentes valeurs TimeLock, permet à toute transaction d’engagement de dépenser la sortie de toute transaction d’engagement antérieure, c’est-à-dire, à remplacer les États plus anciens par des États plus récents.
Plutôt que de pénaliser une partie qui a utilisé une ancienne transaction, la symétrie LN «corrige» l’ancienne transaction pour distribuer des soldes en fonction de l’état actuel. Est-ce toujours la foudre? Ou est-ce trop différent?
Protocoles de transfert de paiement
Les contrats de verrouillage de hachage (HTLC) sont utilisés pour acheminer les paiements sur le réseau Lightning. Chaque HTLC finalise le paiement à l’avenir avec la révélation d’un préimage à un hachage, ou lui permet d’être remboursé en arrière si cette préimage n’est pas révélée dans le temps. Il s’agit du mécanisme en appliquant en toute sécurité que chaque houblon d’un paiement avance vers le récepteur ou vers l’arrière pour l’expéditeur (s’il ne pouvait pas être terminé).
Ce n’est pas le seul moyen d’atteindre cet objectif.
Les contrats Timelock Point (PTLC) sont un autre mécanisme qui pourrait être utilisé à la place des HTLC. Les PTLC utilisent des signatures d’adaptateur par opposition aux prémages et hachages pour fournir des garanties atomiques entre tous les houblons d’un paiement. Les signatures d’adaptateur sont des signatures cryptographiques qui ont eu une valeur de données ajoutée – ou supprimée d’eux – afin de les rendre invalides. La signature ne peut désormais être rendue à nouveau valide qu’en ajoutant (ou en supprimant) la «valeur de l’adaptateur» qui a été utilisée en premier lieu.
Les paiements le long d’un itinéraire sont signés avec des signatures d’adaptateur, le destinataire du paiement publiant les informations nécessaires pour les rendre valides à nouveau. Mais ce n’est pas si différent d’un HTLC; Il utilise simplement un mécanisme différent de facilitation.
Regardons quelque chose de très différent: les paiements paquets. Il s’agit d’une ancienne proposition pour supprimer complètement les HTLC afin de transmettre les paiements. L’idée est de rompre un seul paiement en de nombreux paiements de très petite valeur, disons 100 satoshis, puis Il suffit de les transmettre aveuglément à un pair avec des instructions de routage.
Le destinataire peut dire à l’expéditeur chaque fois qu’un «paquet de paiement» arrive avec succès, et si l’on n’arrive pas, l’expéditeur sait qu’un saut le long de l’itinéraire ne transmet pas honnêtement l’argent. Ils peuvent cesser d’utiliser cette voie et en essayer un autre, ne perdant que 100 satoshis dans le processus.
Est-ce toujours la foudre, ou quelque chose de complètement différent? Les transactions de canal fonctionneraient de la même manière et le protocole de routage serait identique, mais est-ce toujours la foudre?
Protocoles de routage
Et si nous remplacons complètement le protocole de routage? Lightning utilise actuellement le protocole de potins afin de s’assurer que tous les nœuds de foudre du réseau ont une carte relativement bonne des différents canaux à travers le réseau, la quantité de bitcoin, et les frais qu’ils facturent – toutes les informations nécessaires pour chaque nœud pour sélectionner pleinement le chemin de routage pour ses paiements en soi.
Le routage des fourmis est une proposition de supprimer entièrement tout cela: acheminer les paiements sur le réseau sans aucun protocole de potins, sans aucune carte du réseau, et sans que l’expéditeur ne choisisse le chemin que leur paiement emprunte.
La conception à accomplir qui est construite autour des «sentiers phéromones» et des «graines de phéromone», des messages spéciaux qui sont diffusés sur l’ensemble du réseau afin de faciliter les paiements. Ensemble, l’expéditeur et le récepteur génèrent un grand nombre aléatoire et créent un hachage partiel de cela (la graine de phéromone). Les deux parties ont ensuite diffusé la graine de tous leurs pairs immédiats avec un comptoir qui augmente de +1 chaque fois que la graine est transmise.
Finalement, un nœud dans le réseau recevra les deux graines et sachera qu’ils sont le point de connexion pour un chemin complet entre l’expéditeur et le récepteur. À ce stade, ce nœud renverra un message de réponse dans les deux sens, et lorsque l’expéditeur et le récepteur confirment la réponse, ils peuvent coordonner le paiement.
Il sera ramené le long de l’itinéraire vers le point de connexion, et de là vers le récepteur, le tout sans personne le long du chemin, y compris l’expéditeur et le récepteur, devant construire l’itinéraire eux-mêmes ou avoir une idée de l’itinéraire complet.
Est-ce toujours le réseau Lightning? Ou est-ce trop radicalement différent?
Qu’est-ce que c’est?!
Le réseau Lightning est une série de transactions pré-signées pour appliquer une distribution de solde entre les utilisateurs, ainsi que les autres mécanismes impliqués dans la mise à jour de cette distribution et la synchronisation de ces mises à jour entre les utilisateurs de tout le réseau.
Mais cela ne décrit-il pas aussi Ark? Ou Statechains? Oui. C’est mon point.
L’idée principale de Lightning est de mettre à jour les accords sur la façon de distribuer des fonds hors de la chaîne, tout en veillant à ce que la version la plus récente de cet accord puisse être appliquée sur la tête si nécessaire, sans marge de manière pour une partie impliquée pour «tromper le système» et appliquer un accord passé plus favorable.
Il existe de nombreuses façons d’atteindre cet objectif. La façon utilisée actuellement est simplement la première manière concrète spécifiée. Il y a et peut y avoir des façons plus et différentes de faire cela. Au fil du temps, les méthodes et les outils pour atteindre cet objectif changeront.
Peut-être qu’une nouvelle façon obsolète complètement une manière plus ancienne. Peut-être qu’une nouvelle façon fonctionne mieux dans un certain scénario ou une certaine situation. Mais de nouvelles façons viendront certainement, et ça va.
Certaines choses changeront complètement, d’autres ne seront que de légères variations de ce qui a précédé, mais la foudre sera en forme au fil du temps. Il doit pour continuer à évoluer à long terme, pour résoudre ses propres problèmes, pour aider le bitcoin à fonctionner comme un argent.
La foudre évoluera.
Ne manquez pas votre chance de posséder Le problème de la foudre – Avec une interview exclusive avec le co-créateur de Lightning Tadge Dryja. Il plonge profondément dans la couche de mise à l’échelle la plus puissante de Bitcoin. Exécution limitée. Uniquement disponibles pendant les fournitures en dernier.
Cette pièce est un article présenté dans la dernière édition imprimée du magazine Bitcoin, The Lightning Issue. Nous le partageons ici pour montrer les idées explorées tout au long du numéro complet.