By Bitcoin Magazine - il y a 6 mois - Temps de lecture : 6 minutes
Arbres de délai d'attente : une solution pour faire évoluer les LSP du réseau Lightning
L'une des plus grandes limitations inhérentes au Lightning Network est le nombre limité de canaux pouvant être ouverts ou fermés par bloc, compte tenu de la taille limite des blocs. Quel que soit le nombre de transactions hors chaîne pouvant être effectuées à moindre coût, il s'agit d'un goulot d'étranglement fondamental limitant le nombre de personnes qui pourraient réellement utiliser le réseau Lightning. Même le livre blanc de Lightning Network concluait que dans un scénario où la population mondiale de 7 milliards d'habitants utilisait Lightning, avec seulement deux transactions en chaîne par an et par personne, Bitcoin il faudrait des blocs de 133 Mo pour que Lightning fonctionne. Il ne s’agit pas d’un problème sortant du champ de gauche ou d’un problème imprévisible, il s’agissait d’une limitation de la conception du protocole parfaitement comprise dès le premier jour.
Une partie du plan visant à résoudre ce problème a toujours été l'idée d'usines de canaux, c'est-à-dire un type de canal auquel plus de deux utilisateurs participaient. C'était toujours la direction que les choses devaient prendre pour faire évoluer Lightning et Bitcoin sans augmentation de la taille des blocs, mais le problème est que la résolution du problème des empreintes en chaîne introduit toute une série d'autres problèmes. Tout d’abord, rien ne change fondamentalement à l’obligation d’imposer des états intermédiaires si une contrepartie ne répond plus. Cela a des implications sur la valeur ajoutée. L’intérêt d’une usine de canaux est que, par exemple, vingt personnes peuvent partager un UTXO et réorganiser la liquidité à l’intérieur avec les vingt autres personnes comme elles le souhaitent. Une fois que quelqu'un ferme la chaîne de manière non coopérative, cela commence à interférer avec cet objectif.
Si je ferme ma chaîne dans une usine de chaînes, j'entraîne un groupe de personnes avec moi hors de l'usine. Pensez à une usine comme un arbre Merkle, il y a un UTXO au sommet, et qui se divise en deux hors chaîne, et ceux-ci sont divisés en deux, etc. jusqu'à ce que nous arrivions aux canaux individuels de chacun. Une fois que j'ai retiré ma chaîne de l'usine, tout le monde de mon côté de chaque division qui passe en chaîne est désormais coupé de tous les autres dans l'usine. Ils ne peuvent plus réorganiser leurs liquidités dans cette partie du groupe si tout le monde coopère.
Un autre gros problème est que même pour en démarrer une, vous devez avoir tout le monde en ligne au début pour pré-signer toutes les transactions. Si vous voulez vingt personnes dans une usine, tout le monde doit être en ligne pour la démarrer. Si vous voulez mille personnes, mille personnes doivent être en ligne, etc.
Cela fait des usines de distribution un vaste espace de conception rempli de nombreux problèmes à résoudre. Nous résolvons donc un problème existant pour Lightning, mais en créons un certain nombre de nouveaux. Cela me semble être de l'ingénierie.
Arbres de délai d'attente
La récente proposition de John Law, Arbres de délai d'attente, tente d’offrir une solution au problème central des usines de canaux. Je n’appellerais pas vraiment un arbre de temporisation une usine de canaux, plutôt une « proto-usine », mais il offre une solution potentielle au problème de l’ouverture et de la fermeture d’un nombre massif de canaux sans introduire le problème des fermetures non coopératives qui ruinent le système. utilisation de l'usine pour d'autres utilisateurs. Il nécessite CHECKTEMPLATEVERIFY (CTV) et un fournisseur de services d'éclairage (LSP) pour fonctionner fonctionnellement.
Un Timeout Tree est essentiellement une fabrique de canaux garantie par des clauses restrictives, sans possibilité de modifier la façon dont la liquidité est réorganisée hors chaîne après sa création, avec une clause de sauvegarde spéciale. Un LSP, nous les appellerons Bob, joue le rôle de passerelle entre les utilisateurs occasionnels et le réseau Lightning plus large. Bob peut prendre les pièces qu'il contrôle et créer une arborescence CTV qui crée un seul déploiement UTXO pour ouvrir des canaux à n'importe quel nombre arbitraire d'utilisateurs de son service LSP. Ce qui est bien avec CTV, c'est qu'il permet de faire cela sans que tout le monde soit en ligne en même temps. Bob peut simplement demander à tout le monde de signer l'état initial de sa chaîne un par un et de le conserver jusqu'à ce que tout le monde ait configuré la chaîne, et de simplement dépenser les fonds dans l'arborescence CTV lorsqu'il a configuré des chaînes avec chaque utilisateur.
Cela résout le problème du fait que tout le monde doit être en ligne en même temps pour configurer « l’usine » et commencer à utiliser Lightning. Grâce à CTV, une fois que Bob a dépensé des pièces dans l'arbre pour créer les chaînes Lightning de tout le monde, il n'a aucun moyen de reculer et de prendre les pièces (encore). Avec ce premier UTXO dans CTV confirmé en chaîne, tout le monde peut traiter ses chaînes comme ouvertes et il n'y a aucun risque qu'elles soient dépensées deux fois.
Maintenant la dernière partie, fermer les chaînes. Même si leur ouverture ne nécessite qu'un seul UTXO sur la chaîne en raison de CTV, leur fermeture nécessiterait quand même que l'intégralité de l'arborescence CTV se déploie sur la chaîne afin que tout le monde puisse soumettre l'état de sa chaîne, n'est-ce pas ? Faux. Il s'agit de la partie Timeout des Timeout Trees. Chaque branche de l'arborescence des délais d'attente possède une branche de script dans laquelle Bob peut récupérer tous les fonds après un délai.
Un diagramme d’un arbre de délai d’attente.Maintenant, je suis sûr que vous pensez "quoi !?" C’est là le véritable génie du fonctionnement de cette proposition. Étant donné que Bob peut balayer lui-même les UTXO en chaîne sans personne d'autre après le délai, ces canaux ont tous une date d'expiration à moins que les utilisateurs ne déploient réellement l'ensemble de l'arborescence et ne confirment le financement réel du canal en chaîne. Cela permet à Bob de faire quelque chose d'intéressant : lorsque ce timelock arrive, il peut ouvrir un tout nouvel arbre de délai d'attente avec tous les utilisateurs de l'arbre actuel et leur demander de déplacer tous leurs fonds de l'arbre expirant vers le nouveau. -chain sur Lightning, puis balayez le seul UTXO en chaîne du dernier arbre.
Cela permet une fermeture efficace de tous ces canaux en chaîne. Le seul problème qui reste maintenant est d'appliquer un HTLC en chaîne si l'autre partie cesse de coopérer. Eh bien… ce n'est pas vraiment un problème dans ce cas, ou plutôt c'est un problème de tout ou rien. La raison pour laquelle les canaux doivent être fermés pour appliquer un HTLC est si l'autre partie du canal cesse de répondre au milieu de son routage. Dans un arbre de délai d'attente, l'homologue de chaque utilisateur est Bob. Ainsi, si Bob, tant qu'il est honnête, ne répond pas à la mise à jour d'un HTLC ayant échoué ou réussi pour un utilisateur, il ne répond pas non plus pour aucun autre utilisateur. Dans ce cas, tout le monde peut toujours fermer ses chaînes en chaîne avant l'expiration du délai et cesser d'utiliser le LSP de Bob.
Récapitulation
Les utilisateurs devront toujours payer des frais pour les interactions en chaîne, il n'y a aucun moyen de contourner cela, et un arbre de délai d'attente entier se fermant de manière non coopérative sur la chaîne constituerait une empreinte en chaîne importante et coûteuse, mais c'est en fin de compte un problème. tout système de canaux multipartites devra répondre. Timeout Trees propose cependant des solutions convaincantes au cas coopératif de l'ouverture et de la fermeture d'un canal multipartite massif sans dégrader le modèle de confiance du système en quelque chose de gardien.
John a même proposé dans sa version la plus récente de l'article un système selon lequel les utilisateurs pourraient être pénalisés suffisamment pour les fermetures non coopératives pour couvrir le coût de Bob pour finalement balayer un groupe d'UTXO d'arbres fragmentés après le délai d'attente. Il existe potentiellement des moyens de faire l'inverse si l'inactivité ou la malhonnêteté de Bob est la raison pour laquelle les utilisateurs doivent fermer de manière non coopérative leur partie de l'arborescence.
En fin de compte, il s’agit d’une proposition très concrète et spécifique pour la conception d’une fabrique de canaux qui tente réellement de résoudre les véritables problèmes d’utilisation et de mise en œuvre au lieu d’un concept vague et à moitié défini. Il s’agit d’un progrès considérable pour remédier aux limitations d’évolutivité à long terme de Lightning.
Source primaire: Bitcoin Magazine