Lightning Network Liquidité Introduction du plan de gestion

Auteur : RGB++ Fans ; Source : ByteDance CKB

Dans les articles de vulgarisation précédents, nous avons déjà brièvement expliqué les concepts fondamentaux liés au Lightning Network, tels que les canaux de paiement, les itinéraires à sauts multiples, l’HTLC, etc.

Nous avons mentionné que pour effectuer des transferts sur le réseau Lightning, il est souvent nécessaire de passer par plusieurs nœuds intermédiaires pour établir un chemin, et les nœuds intermédiaires ont souvent des soldes limités, ce qui finit par affecter le taux de réussite des paiements. Afin de garantir que les nœuds sur le chemin disposent de suffisamment de fonds et d’améliorer l’expérience utilisateur, il est nécessaire de réguler la liquidité par le biais de certaines solutions de gestion de la liquidité. Toutefois, pour comprendre en profondeur la gestion de la liquidité, nous devons d’abord introduire quelques concepts de base, tels que les soldes locaux et distants (Local and Remote Balance), la capacité entrante et sortante (Inbound and Outbound Capacity), etc.

Dans le passé, nous avons mentionné que l’unité de base du Lightning Network est le Nœud et le canal, ce dernier étant une installation de transfert off-chain 1 sur 1 basée sur le réseau Bitcoin. Lors de l’initialisation du canal, les deux parties transféreront une certaine somme d’argent comme solde initial. Le solde de votre côté est appelé “solde local”, et le solde du côté de votre correspondant est appelé “solde distant”. Le solde local détermine combien vous pouvez transférer à votre correspondant, limitant ainsi votre capacité de paiement, c’est-à-dire votre “capacité d’envoi”. Le solde distant détermine combien votre correspondant peut vous transférer, limitant ainsi votre “capacité de réception”, c’est-à-dire votre capacité de recevoir des paiements.

Bien que les soldes respectifs des deux parties puissent être modifiés fréquemment avant la fermeture du canal, la capacité totale du canal après l’agrégation des deux ne peut être modifiée, sauf si vous redémarrez complètement le canal ou injectez des fonds via une “concaténation de canaux”.

(Ce schéma montre les soldes respectifs de vous et de Robert, votre solde local est de 5, votre solde distant est de 3, et la capacité totale du canal est de 8)

Après avoir compris les concepts de base ci-dessus, nous examinons maintenant ce que la gestion de Liquidité dans Lightning Network vise à résoudre. Le schéma de connexion Nœud simplifié dans le graphique ci-dessous montre que vous (coin inférieur gauche) êtes connecté à un seul Nœud LNTop. Étant donné que votre solde distant est de 3, vous pouvez recevoir un transfert d’au plus 3 dollars. Si Sophie veut vous transférer 1 dollar, elle échouera en raison du manque de solde disponible du Nœud intermédiaire à LNTop (encadré rouge, la capacité de débit de ce Nœud à LNTop est de 0).

On peut dire que la capacité des canaux est l’un des problèmes majeurs rencontrés par le Lightning Network au début. **Si la liquidité est mieux répartie dans l’ensemble du réseau, de tels problèmes seront atténués de manière efficace. Les solutions à ce problème sont souvent appelées « gestion de la liquidité », **comme la connexion des clients à plusieurs nœuds avec une liquidité abondante via le marché de location (Lightning Pool), l’ouverture/fermeture de nouveaux canaux selon les besoins, ou l’introduction de méthodes telles que la jonction des canaux, la rééquilibrage des canaux (Channel Rebalancing), etc., pour réguler les soldes dans les canaux, qu’ils soient hors chaîne ou sur chaîne.

Certains portefeuilles offrent encore des fonctionnalités de gestion de canal automatisées, gérant intelligemment les canaux en fonction des habitudes de paiement des utilisateurs et de l’état du réseau, afin de garantir une Liquidité suffisante pour les transferts. Les nouveaux utilisateurs peuvent également adopter un mode d’“investissement unilatéral” lors de leur première connexion au Lightning Network, c’est-à-dire laisser seulement la contrepartie du canal investir, sans investir eux-mêmes au moment de l’initialisation du canal, ce qui permet de réduire les coûts économiques pour l’utilisateur, mais au prix de ne pas avoir la capacité/initiale de payer à l’extérieur.

Nous allons maintenant approfondir la vulgarisation des techniques couramment utilisées dans le cadre de la gestion de Liquidité du Lightning Network. Tout d’abord, permettez-nous de comprendre le ‘prêt de canaux’, qui vise principalement à résoudre le problème de ‘capacité d’entrée’ des Nœuds. Lorsque d’autres personnes souhaitent vous transférer des fonds, vous devez vous assurer de pouvoir leur fournir un chemin de paiement réussi, ce qui implique des exigences pour chaque Nœud inclus dans le chemin, telles qu’un solde suffisant ou une capacité de sortie adéquate. Comme mentionné précédemment, le scénario d’échec du chemin est dû à un manque de Liquidité dans les canaux établis entre certains Nœuds intermédiaires et d’autres Nœuds.

La création d’un canal a un coût, car les participants doivent souvent bloquer une partie des fonds, ce qui entraîne un coût d’opportunité. L’idée de ce que l’on appelle le channel leasing est de permettre aux opérateurs de Nœud de commercer directement par des moyens orientés vers le marché, et de permettre à Nœud disposant de fonds excédentaires de prendre l’initiative de construire des canaux pour d’autres Nœuds par le biais du système de « leasing ». **Par exemple, si vous êtes un commerçant qui a besoin de recevoir de l’argent d’autres personnes à tout moment, vous avez une forte demande pour la limite, et votre « capacité de collecte » en une journée doit dépasser 200 BTC.

Ainsi, vous avez conclu un protocole avec 4 grands nœuds via Lighting Pool, et ces 4 nœuds ont établi un canal avec vous pour une durée de 24 heures, verrouillant chacun 50 BTC et vous offrant un solde à distance de 50 BTC chacun, de sorte que votre capacité de réception dans chaque canal sera de 50 BTC. Si quelqu’un vous transfère de l’argent, vous pouvez utiliser l’un des 4 nœuds comme intermédiaire pour établir un chemin de paiement.

Sur 1ml.com, nous pouvons voir plusieurs opérateurs de Nœud du réseau Lightning Network connus, ces Nœuds disposent de fonds excédentaires et ont établi plusieurs canaux avec d’autres Nœuds, permettant de générer des revenus en louant de la Liquidité.

En plus de la location de piscines mentionnée ci-dessus, il y a aussi Liquidité publicitaire (Liquidity Advertisement), les fournisseurs de Liquidité peuvent diffuser leurs prix et la durée de leur canal en utilisant les messages gossip de Lightning Nœud, et les Nœud qui acceptent les prix peuvent ouvrir des canaux avec eux. Ce type de solution basée sur la location sera combiné avec le système de Marge pour éviter qu’une partie ne se désiste soudainement.

Actuellement, des développeurs de Lightning Labs et d’autres développeurs de la Lightning Network, ainsi que Fiber, cherchent à optimiser les scénarios de location de Liquidité avec des investissements à sens unique, par exemple, Fiber prévoit d’introduire un mécanisme de paiement Liquidité basé sur les fonctionnalités du contrat intelligent CKB. Un fournisseur de services LSP spécifié, Nœud, établira des canaux avec les utilisateurs et fournira gratuitement de la capacité d’entrée pendant un certain temps pour répondre à leurs besoins de paiement. Une fois que les utilisateurs ont reçu de l’argent, le contrat récupérera automatiquement les coûts. Le mécanisme de mise en garantie Liquidité associé à ce type de scénario est également en discussion.

En gros, la location de canal est souvent utilisée pour résoudre les problèmes de connexion et d’obtention de Liquidité entre les Nœuds, tandis que le plan de raccordement de canal ci-dessous effectuera un financement / retrait via des opérations off-chain, modifiant directement le solde total des deux parties dans le canal. Normalement, l’ouverture et la fermeture du canal nécessitent des signatures 2/2, réallouant les actifs off-chain détenus conjointement par les deux parties, tandis que dans le cadre initial du Lightning Network, une fois le canal ouvert, le solde total du canal ne peut être modifié que si le canal est fermé et rouvert.

Et le canal de raccordement est une nouvelle solution proposée plus tard, qui permet de ne pas fermer les canaux existants. Sous la coopération des parties prenantes, il est possible de restructurer et de mettre à jour directement, off-chain, les UTXO communs aux deux parties du canal, par exemple, en ajoutant de nouveaux actifs sur la base des actifs existants pour que les parties prenantes les contrôlent conjointement, modifiant ainsi le solde global du canal. Le schéma ci-dessous résume brièvement cette idée, où à gauche se trouvent les actifs off-chain correspondant à l’ancien canal (UTXO1), contrôlés par la signature multiple d’Alice et de Bob. Ensuite, les deux parties lancent le raccordement du canal, ajoutant un autre actif (UTXO2) pour une gestion conjointe. En fin de compte, la quantité d’actifs (UTXO3) communs aux deux parties du canal augmente, et sa capacité également.

La connexion de canal peut également être utilisée pour réduire les fonds excédentaires dans le canal, transférer les actifs inutilisés temporairement hors du canal et améliorer l’efficacité de l’utilisation des fonds. Par rapport aux deux interactions off-chain nécessaires pour fermer/réinitialiser traditionnellement un canal, la connexion de canal ne nécessite qu’une seule opération off-chain, ce qui peut réduire considérablement les coûts. Bien que la connexion de canal présente des avantages évidents, en raison de raisons historiques, cette solution n’est pas encore complètement mature et son adoption à grande échelle nécessitera encore du temps.

Après avoir compris le raccordement des canaux, nous continuons à présenter la pensée de l’équilibrage des canaux (Channel Rebalancing), qui est également un moyen d’ajuster les soldes hors chaîne des différents canaux sans fermer ou modifier la capacité totale des canaux (en ignorant les frais). Supposons que vous exécutiez un client Lightning Network et que vous ayez établi un total de trois canaux de paiement avec d’autres nœuds:

• Canal 1 : Établi avec Nœud X, capacité totale de 1 BTC
• Canal 2: Établi avec Nœud Y, capacité totale de 0,5 BTC
• Canal 3 : établi avec Nœud Z, capacité totale de 0.5 BTC

La répartition des fonds de chaque canal est la suivante :

• Canal 1: Votre solde local : 0.9 BTC Solde à distance : 0.1 BTC
• Canal 2: Votre solde local: 0.1 BTC Solde à distance: 0.4 BTC
• Canal 3: Votre solde local: 0.1 BTC Solde à distance: 0.4 BTC

Le problème maintenant est que dans les canaux 2 et 3, vous n’avez pas assez de capacité sortante, et vous pouvez transférer jusqu’à 0,1 BTC à la contrepartie, ce qui n’est pas suffisant pour répondre aux besoins des transferts importants. Dans le même temps, le canal 1 a un excédent de 0,9 BTC, mais vous n’en aurez tout simplement pas besoin à court terme. De toute évidence, la meilleure façon d’y parvenir est de transférer les fonds excédentaires du canal 1 vers les deux autres canaux. Vous avez donc l’intention de transférer 0,4 BTC du solde local du canal 1 vers le canal 2 et 0,4 BTC vers le canal 3. Pour ce faire, vous devrez effectuer deux paiements circulaires.

Le mode opératoire spécifique est indiqué dans la figure ci-dessus. Vous pouvez transférer directement 0.8 BTC à Nœud X, qui transfère ensuite 0.4 BTC chacun à Y et Z, puis Y et Z vous transfèrent respectivement 0.4 BTC dans les canaux 2 et 3 pour augmenter votre solde local, de sorte que vous disposiez de fonds suffisants pour les futures transactions importantes.

En observant le graphique ci-dessus, il est facile de voir que l’essence du paiement en boucle est de vous transférer de l’argent à vous-même, en déplaçant vos soldes entre différents canaux, afin de répartir les soldes globaux selon vos attentes. Cependant, cette méthode ne peut pas augmenter arbitrairement le solde total des deux parties dans n’importe quel canal. De plus, sa mise en œuvre nécessite les hypothèses suivantes : X a suffisamment de fonds transférables avec Y et Z, en d’autres termes, les paiements en boucle nécessitent souvent que les nœuds pertinents aient une certaine réserve de liquidité.

Le paiement en boucle est une mise en œuvre de la pensée de rééquilibrage des canaux, et le plan de rééquilibrage peut également être combiné avec d’autres méthodes dans la pratique, telles que les échanges de sous-marins. Maintenant, permettez-nous de présenter les échanges de sous-marins, dont l’idée principale est d’échanger des fonds hors chaîne avec des fonds hors chaîne sans fermer le canal en utilisant des méthodes telles que HTLC.

Le scénario le plus simple d’échange de sous-marins est le dépôt off-chain dans le canal. Supposons qu’Alice et Bob aient établi un canal 1 à 1, mais après un certain temps, le solde local d’Alice est presque épuisé et elle ne peut plus effectuer de paiements sortants. À ce stade, si Alice doit injecter plus de fonds, elle doit fermer le canal puis le redémarrer. Cependant, ce canal est loué, il n’est donc pas rentable de le fermer à l’avance. Que faire dans ce cas ?

Si l’échange se fait via un sous-marin, le processus sera relativement simple, mais il faudra utiliser HTLC. Tout d’abord, Alice peut générer un nombre aléatoire R, en prendre le hash H®. Ensuite, Alice peut envoyer des BTC à l’Adresse de Bob hors chaîne, sous réserve des conditions de déverrouillage de HTLC. Pour déverrouiller ces BTC hors chaîne, Bob doit connaître l’antécédent R correspondant à H®.

Bob effectue une transaction avec Alice via HTLC sur le canal off-chain, mais dans l’autre sens : Alice doit présenter R avant de pouvoir débloquer l’argent payé par Bob. Dès qu’Alice présente la valeur de R, Bob peut l’utiliser pour débloquer les BTC verrouillés par Alice sur off-chain. Ensuite, le solde local d’Alice dans le canal augmente, tandis que le solde des actifs off-chain diminue de manière équivalente (en supposant qu’il n’y a pas de frais), ce qui correspond à un échange 1:1 de base (pour faciliter l’explication du principe, l’ordre d’opération habituel d’échange de sous-marins n’a pas été strictement suivi ci-dessus. En réalité, la plupart du temps, l’une des parties crée d’abord un HTLC off-chain, puis l’autre partie crée un HTLC symétrique off-chain).

Les scénarios ci-dessus sont principalement utilisés pour échanger des actifs hors-chaîne contre un solde hors-chaîne. Il suffit d’inverser les opérations d’Alice et de Bob pour les échanger contre des retraits, convertissant ainsi le solde hors-chaîne en actifs hors-chaîne. L’échange sous-marin est sécurisé grâce à des fonctionnalités combinées telles que HTLC et les verrous temporels. Même si l’autre partie refuse de coopérer en cours de route, l’argent verrouillé dans HTLC est sécurisé car l’autre partie ne connaît pas la Clé secrète pour déverrouiller HTLC. Après l’expiration du verrou temporel, vous pouvez récupérer votre capital.

Cependant, il est important de noter que dans les scénarios mentionnés ci-dessus, bien que votre capital ne soit pas volé, une des parties doit créer un verrouillage de fonds HTLC hors chaîne, ce qui entraînera inévitablement une usure des frais de transaction. Si l’autre partie est malhonnête, cela aura certainement un impact sur vous. Pour résoudre ces problèmes, les échanges sous-marins ont souvent recours à des mesures auxiliaires telles que les dépôts préalables, les systèmes de réputation et autres sanctions.

Pour récapituler, l’idée principale du sous-marin swap est de permettre l’échange flexible d’actifs off-chain/off-chain. En suivant cette approche de rééquilibrage du canal, il est possible de mettre en œuvre des mesures d’ajustement de Liquidité plus optimales. Voici un exemple simple :

Cependant, en résumant les points de connaissance ci-dessus, nous pouvons facilement constater que les opérations d’ajustement Liquidité telles que l’échange de sous-marins et le raccordement de canaux, la location de canaux, etc. laisseront des traces d’opération off-chain et entraîneront des frais de transaction. Si de telles opérations sont effectuées fréquemment, elles causeront inévitablement une pression sur les coûts économiques et l’expérience utilisateur des utilisateurs. Étant donné que BTCLightning Network dépend de BTC Mainnet, les interactions off-chain fréquentes ne sont pas réalistes, tandis que Fiber basée sur CKB est confrontée à une pression relativement faible dans l’expérience de gestion Liquidité. Cependant, quel que soit le cas, Lightning Network et Fiber approfondissent la recherche sur les solutions Liquidité mises à jour et peuvent trouver un chemin plus approprié à l’avenir en coopération active avec des équipes de projets tels que Mercury Layer.