By Bitcoin Magazine - il y a 1 an - Temps de lecture : 7 minutes
Quelques façons de mettre à niveau le routage des paiements Lightning Network
Afin de devenir un protocole utilisable par le monde entier, certaines améliorations de mise à l’échelle pour Lightning doivent être envisagées.
Le Lightning Network est une solution de transaction de couche 2 bien développée et à croissance rapide sur le Bitcoin réseau. De plus en plus de services et d'échanges l'intègrent, la liquidité disponible pour acheminer les paiements augmente et de plus en plus d'applications et de moyens permettant aux utilisateurs d'interagir avec lui sont développés chaque année. Il y a également de nombreux problèmes à surmonter à long terme :
L'évolutivité limite le nombre de canaux pouvant être ouverts ou fermés en chaîne à la fois. Il y a un problème avec la taille minimale Contrat verrouillé dans le temps de hachage (HTLC) augmente à mesure que les frais en chaîne augmentent également, car le règlement doit être économique. Il existe également de nombreux problèmes de confidentialité.L'un des principaux problèmes fréquemment abordés est celui des 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 dans ces deux directions. Voici cependant le problème : le problème est en quelque sorte imaginaire. Les paiements sur Lightning utilisent des HTLC, un script dans un Bitcoin sortie qui indique qu'une personne peut réclamer la sortie et la dépenser en révélant la pré-image d'un hachage, ou qu'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'états
A 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.
Sidechains
Les sidechains peuvent implémenter toutes les règles arbitraires de leur choix. Les temps de blocage peuvent être différents, les tailles de bloc peuvent être différentes, tout peut être modifié. Le seul problème actuellement est de déplacer votre Bitcoin à une sidechain, vous devez faire confiance à une fédération qui conserve les fonds sur la chaîne principale. Vous pouvez appliquer des HTLC sur une sidechain qui utilise Bitcoinle système de script de ; 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 permet de donner de l'argent sous condition à 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 de liquidités plus efficace que la blockchain principale. Bitcoin blockchain. Vous pouvez même simplement faire quelque chose d'aussi simple que de créer un autre réseau Lightning sur une chaîne sur laquelle il est moins coûteux d'ouvrir et de fermer des canaux. L'imagination est la limite.
De toutes nouvelles constructions
Voici une idée aléatoire de ma part : plusieurs personnes peuvent s'entasser en un seul. m-de-n (c'est-à-dire 3 sur 5) adresse multisig avec quelques agents de dépôt, et faites simplement confiance aux agents de dépôt pour régler les choses correctement. Chaque personne figurant à l'adresse et les agents séquestres peuvent suivre et mettre à jour les « soldes » en fonction de l'acheminement des paiements ; enregistrer les HTLC qui sont utilisés et savoir s'ils ont été 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 de dépôt soient tout ce qu'il est nécessaire de dépenser à partir du multisig. Vous pouvez même créer une transaction de remboursement limitée dans le temps pour rembourser l'argent de chacun après une certaine période, ce qui aurait pour inconvénient que tout l'argent 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 valable.
Cela nécessiterait de faire confiance aux agents séquestres, mais l'avantage serait que toute personne de ce « groupe UTXO » pourrait transférer des fonds ou acheminer un HTLC vers tous 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 pouvez gagner de l'argent en acheminant un paiement sur le réseau pour quelqu'un, mais que vous ne disposez pas d'un 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 je dispose d'un canal Lightning conventionnel sans confiance et que je souhaite payer quelqu'un qui dispose également d'un canal Lightning conventionnel sans confiance, la manière dont ce paiement y parvient n'a aucune importance pour aucun de nous. Lorsque j'envoie de l'argent, ce paiement est mis à jour et appliqué dans mon canal Lightning avec mon homologue 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 homologue, sans confiance, comme d'habitude. Le fait que quelqu’un au milieu se fie simplement à la promesse de son pair de le payer plus tard n’a absolument aucune importance 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 désormais 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 système actuel, exigeant le partage de l'UTXO qui a financé une chaîne, est là comme une protection contre les personnes faisant de la publicité sur des 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 qu'ils n'ont jamais eus. 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.
Source primaire: Bitcoin Magazine