Façons de mettre à niveau le routage des paiements Lightning
Le Lightning Network est une solution de transaction de couche 2 bien développée et à croissance rapide sur le réseau Bitcoin. De plus en plus de services et d’échanges l’intègrent, la liquidité disponible pour l’acheminement des paiements augmente, et de plus en plus d’applications et de moyens pour les utilisateurs d’interagir avec elle sont développés chaque année. Il a également de nombreux problèmes à surmonter à long terme :
- L’évolutivité limite le nombre de canaux pouvant être ouverts ou fermés sur la chaîne à la fois.
- Il y a un problème avec la taille minimale Contrat verrouillé dans le temps de hachage (HTLC) augmentant à mesure que les frais en chaîne augmentent également, car il doit être économique de régler.
- Il y a aussi une multitude de problèmes de confidentialité.
L’un des principaux problèmes fréquemment évoqués concerne les besoins en liquidités pour l’acheminement des paiements. Afin d’acheminer avec succès un paiement, il doit y avoir un lien de canaux, de l’expéditeur au destinataire, qui dispose de suffisamment de liquidités du côté droit du canal pour pouvoir transmettre le paiement. Cela rend la décision de savoir où déployer vos pièces sur le réseau très importante. Cela signifie également que le montant global de liquidités que les gens sont prêts à déployer est une sorte de limite supérieure de la valeur que le réseau peut traiter.
En fin de compte, cela revient à dire que lorsque vous ouvrez un canal, vous décidez de verrouiller cet argent afin qu’il ne puisse être utilisé que pour acheminer les paiements vers ce partenaire de canal, et à qui ils sont connectés sur le graphique. Oui, en fin de compte, l’idée du Lightning Network est qu’en faisant suffisamment de sauts, vous pouvez trouver une connexion à presque n’importe où. Cependant, la réalité est que si quelqu’un d’autre peut accomplir l’acheminement d’un paiement vers une destination en utilisant moins de sauts que vous, c’est le chemin qui sera très probablement sélectionné pour acheminer le paiement. Lightning nécessite déjà un surdimensionnement dans une large mesure, c’est-à-dire que pour acheminer un paiement de 1 BTC sur 10 sauts, il faut que 10 BTC de garantie soient verrouillés dans les canaux de paiement le long de cette route. La concurrence pour avoir de bonnes connexions pour générer des revenus de routage exacerbe cela en incitant à une garantie encore plus redondante.
Il s’agit d’un problème résultant du fait que les canaux Lightning sont des « tubes » à deux parties qui peuvent simplement pousser la valeur d’avant en arrière dans ces deux directions. Voici la chose cependant : Le problème est un peu imaginaire. Les paiements sur Lightning utilisent des HTLC, un script dans une sortie Bitcoin qui indique qu’une personne peut réclamer la sortie et la dépenser en révélant la préimage à un hachage, ou une autre personne peut réclamer la sortie et la dépenser après avoir attendu l’expiration d’un délai. Il s’agit d’un script général qui peut être appliqué en chaîne, dans les canaux Lightning, au-dessus des chaînes d’état, sur les chaînes latérales, etc. Tant que vous pouvez utiliser un HTLC, en théorie, tout peut participer à l’acheminement d’un paiement Lightning.
Chaînes d’état
Une chaîne d’état est en fait quelque chose comme un canal Lightning, sauf que vous pouvez transférer la propriété de l’ensemble du canal entièrement hors chaîne. Leur modèle de confiance dépend du fait que l’opérateur (qui peut être une fédération) de la chaîne d’état refuse de s’entendre avec les anciens propriétaires et de voler la chaîne d’état au propriétaire actuel. Il n’est pas aussi fiable qu’un canal Lightning, mais il est beaucoup plus flexible car la propriété peut être transmise sans avoir à effectuer une transaction en chaîne. Étant donné que les chaînes d’état sont basées sur des transactions pré-signées hors chaîne, vous pouvez leur ajouter des HTLC.
Cela leur permet d’être utilisés pour optimiser l’efficacité du routage des paiements sur Lightning en permettant aux opérateurs de nœuds de réaffecter la liquidité à la volée hors chaîne. Au lieu d’avoir à ouvrir des canaux et à y couler des liquidités pour être bien connectés à l’avance, leurs fonds peuvent être dynamiquement réaffectés à la volée hors chaîne en réponse au déplacement de la demande vers des endroits auxquels ils ne sont pas connectés (ou pas assez bien connectés pour ). La seule exigence est que l’autre partie veuille transférer des liquidités vers la confiance de l’opérateur de la chaîne d’État.
Chaînes latérales
Les chaînes latérales peuvent implémenter toutes les règles arbitraires qu’elles souhaitent. Les temps de bloc peuvent être différents, les tailles de bloc peuvent être différentes, tout peut être modifié. Le seul hic actuellement est que pour déplacer votre Bitcoin vers une sidechain, vous devez faire confiance à une fédération qui garde les fonds sur la chaîne principale. Vous pouvez appliquer des HTLC sur une sidechain qui utilise le système de script de Bitcoin ; vous pouvez avoir un système de script plus proche d’Ethereum qui permet à des dizaines de personnes de partager un compte qui divise les soldes et les met à jour en fonction de la réussite ou de l’échec d’un HTLC ; Tu peux faire n’importe quoi. Tant que la blockchain prend en charge le versement conditionnel d’argent à une partie si elle produit un hachage, et à l’autre partie après l’expiration d’un délai, elle peut aider à acheminer les paiements Lightning. D’autres blockchains peuvent expérimenter des moyens de rendre l’allocation des liquidités plus efficace que la blockchain principale de Bitcoin. Vous pouvez même faire quelque chose d’aussi simple que de créer un autre réseau Lightning sur une chaîne moins chère à ouvrir et à fermer. L’imagination est la limite.
De toutes nouvelles constructions
Voici une idée que j’ai moi-même prise au hasard : de nombreuses personnes peuvent toutes s’empiler en une seule m-de-n (c’est-à-dire, 3 sur 5) adresse multisig avec quelques agents fiduciaires, et faites simplement confiance aux agents fiduciaires pour régler les choses correctement. Chaque personne à l’adresse et les agents fiduciaires peuvent suivre et mettre à jour les « soldes » en fonction du routage des paiements ; enregistrer les HTLC qui sont utilisés et s’ils sont réglés ou remboursés avec succès ; et régler périodiquement les soldes en chaîne. Vous construisez simplement le multisig de sorte qu’un seul participant « de routage » et tous les agents d’entiercement soient tout ce qu’il faut dépenser du multisig. Vous pouvez même créer une transaction de remboursement verrouillée dans le temps pour rembourser l’argent de tout le monde après une certaine période, dont l’inconvénient serait que tout l’argent que quelqu’un aurait gagné pendant la durée de vie de la construction serait perdu s’il était utilisé. Cela nécessiterait un règlement en chaîne avant que la transaction de remboursement ne devienne valide pour être dépensée.
Cela nécessiterait de faire confiance aux agents d’entiercement, mais l’avantage serait que toute personne de ce « groupe UTXO » pourrait transférer des fonds ou acheminer un HTLC vers quelconque autre personne du groupe UTXO. Cela représenterait un gain d’efficacité massif dans l’allocation des liquidités.
Relations de crédit
Le moyen le plus simple de gagner en efficacité serait de simplement faire confiance aux gens. Si vous pouviez gagner de l’argent en acheminant un paiement sur le réseau pour quelqu’un, mais que vous n’avez pas de canal ouvert vers le nœud nécessaire pour acheminer ce paiement, alors vous pouvez simplement promettre de les payer plus tard s’ils vous font confiance. Si vous étiez une personne ou une entité particulièrement digne de confiance et que de nombreuses personnes sur le réseau étaient disposées à vous faire confiance de cette manière, vous pourriez alors acheminer les paiements avec un degré de flexibilité énorme et ne pas avoir à investir de capitaux dans les canaux de paiement sur tout le réseau. Réglez-vous simplement honnêtement à la fin de la journée, et les gens continueront de vous faire confiance pour effectuer des paiements pour vous sur la base d’un système d’honneur.
Le seul problème et les avantages
Le principal avantage de toutes ces possibilités est que, bien qu’elles présentent toutes d’énormes différences en termes de modèle de confiance (la plupart d’entre elles vous obligeant explicitement à faire confiance aux personnes avec lesquelles vous interagissez si vous choisissez de les utiliser), cela n’a aucune importance pour l’expéditeur et le destinataire. Si j’ai un canal Lightning conventionnel sans confiance et que je veux payer quelqu’un qui a également un canal Lightning conventionnel sans confiance, la façon dont ce paiement y parvient n’a aucune importance pour nous deux. Lorsque j’envoie de l’argent, ce paiement est mis à jour et appliqué dans mon canal Lightning avec mon pair sans confiance, comme d’habitude. Lorsque le destinataire reçoit réellement l’argent, ce paiement est mis à jour et appliqué dans son canal Lightning avec son pair, sans confiance, comme d’habitude. Le fait que quelqu’un au milieu fasse simplement confiance à une promesse de son pair de le payer plus tard est totalement hors de propos pour nous deux. J’ai envoyé mon argent et je n’en ai plus le contrôle, et le destinataire a effectivement reçu son argent et en a maintenant le contrôle, sans confiance.
Le problème est de savoir comment puis-je, en tant qu’expéditeur, connaître ces relations ? Sur Lightning, l’expéditeur est celui qui choisit l’itinéraire d’un paiement, après avoir consulté la table de routage des canaux publics du réseau disposés à transférer les paiements. Pour annoncer la possibilité d’acheminer un paiement, il faut montrer la chaîne UTXO qui a financé votre canal Lightning et prouver qu’il s’agit d’un canal réel. Quel est le problème ici, aucune des idées ci-dessus ne serait en mesure de fournir cela, de sorte que l’expéditeur d’un paiement pourrait être au courant de ces autres options pour acheminer un paiement. Si le protocole de potins et la structure de la table de routage étaient mis à jour pour autoriser ces autres choses, ils pourraient être mis au courant d’autres options.
La seule véritable exigence est de s’assurer que la publicité d’autres moyens « hors canal » d’acheminer les paiements n’ouvre pas de vecteurs de déni de service. Le schéma actuel, nécessitant le partage de l’UTXO qui a financé une chaîne, est là pour se protéger contre les personnes faisant la publicité de chaînes qui n’existent pas, ce qui pourrait surcharger les nœuds avec des données de potins inutiles et conduire les utilisateurs à essayer constamment d’effectuer des paiements qui n’ont jamais eu lieu. une chance de réussir en premier lieu.
En fin de compte, il y a des problèmes à résoudre pour augmenter la flexibilité de l’acheminement des paiements sur le réseau, mais ce sont des problèmes résolubles. Penser que Lightning doit continuer à fonctionner comme il le fait actuellement pour fonctionner comme un réseau de paiement est une réflexion très étroite, et pour le dire crûment, inventer des problèmes qui sont pour la plupart imaginaires.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Bitcoin Magazine.