Source: Bytecoin CKB

Dans l'article précédent "Comment fonctionne le Lightning Network (1)", nous avons exploré le fonctionnement du Lightning Network et les technologies de sécurité des canaux de paiement bidirectionnels connexes. Dans cet article d'aujourd'hui, nous continuerons à présenter le Lightning Network, en expliquant les principes et les technologies connexes de l'extension des canaux de paiement bidirectionnels pour former le Lightning Network.

Étendre les canaux de paiement bidirectionnels au réseau Lightning : technologie de routage multi-hop

Nous utilisons également Alice et Bob pour établir des canaux en tant que contexte de base, mais que faire si d'autres personnes dans le monde veulent également accéder à Lightning Network ? Existe-t-il un moyen de connecter tout le monde au réseau et de garantir la possibilité d'effectuer des paiements à n'importe qui dans le réseau ?

Pour résoudre ce problème, nous devons étendre les canaux de paiement bidirectionnels en Lightning Network et utiliser la technologie de routage multi-saut. Le sens littéral de "routage" est de trouver un chemin, dans le réseau Lightning, il s'agit de trouver le chemin de paiement spécifique formé par la connexion des canaux avant et arrière.

Pour illustrer le paiement de 2000 Satoshi de Alice à David, supposons qu'ils n'aient pas établi de canal de paiement entre eux, mais que des canaux de paiement aient été établis entre Alice et Bob, entre Bob et Carol, et entre Carol et David. Dans ce cas, Alice peut d'abord transférer de l'argent à Bob, puis de Bob à Carol, et enfin de Carol à David. Ainsi, il semble qu'un canal de paiement de Alice à David ait été établi, où Bob et Carol agissent en tant que nœuds de routage dans le réseau. Si des canaux de paiement ont également été établis entre Alice et Eva, et entre Eva et David, alors Alice peut également choisir de transférer d'abord de l'argent à Eva, puis d'Eva à David.

Du point de vue du chemin, il est évident qu'Alice transférer de l'argent à David via EVA est le choix le plus court, mais dans le processus opérationnel réel, le chemin le plus court ne sera pas toujours le meilleur choix en apparence, car d'autres facteurs doivent être pris en compte, tels que la capacité du canal, les frais de routage de Nœud, la disponibilité du Nœud de routage, etc.

Actuellement, les implémentations (clients) les plus courantes de BTCLightning Network, telles que LND développé par Lightning Labs et CLN (Core Lightning) développé par Blockstream, utilisent une variante de l'algorithme de Dijkstra pour le routage. Lightning Network Fiber Network de Nervos CKB utilisera également l'algorithme de Dijkstra pour trouver le chemin de routage optimal.

Sécuriser les routes : de HTLC à PTLC

Dans l'exemple ci-dessus où Alice doit payer David, comment pouvons-nous nous assurer que le nœud de routage Nœud ne retienne pas de manière malveillante les fonds ? Le système TradFi repose généralement sur la garantie de crédit d'institutions financières de grande envergure, mais Lightning Network est un réseau P2P et n'a pas de tiers indépendant des traders pour fournir une garantie de crédit. Nous avons besoin d'un mécanisme différent pour garantir la sécurité des transactions. C'est là que réside le rôle des HTLC (contrats à durée limitée hashés).

HTLC est composé de deux parties: la vérification de hash et la vérification d'expiration. Prenons l'exemple d'Alice qui veut payer 2000 Satoshi à David en choisissant Bob et Carol comme nœuds de routage dans le réseau pour comprendre le fonctionnement de HTLC.

1. Tout d'abord, David doit générer une valeur secrète R, n'importe quel mot, n'importe quel nombre peut servir de valeur secrète, puis calculer son hash H et l'envoyer à Alice. Cette valeur de hash H sera placée dans le script de verrouillage de la sortie de la transaction, seules les personnes connaissant la valeur secrète R correspondante peuvent utiliser cette sortie, et R est appelé "préimage" dans le Lightning Network. Si la valeur secrète R n'est pas révélée à temps, le paiement ne pourra pas être effectué, et l'expéditeur récupérera tous les fonds.
2. Ensuite, Alice utilise la valeur de hachage H reçue pour créer un HTLC, avec un verrouillage temporel réglé sur 5 blocs futurs, le montant de sortie étant de 2020 Satoshi, dont 20 Satoshi sont des frais pour le nœud de routage Bob. En termes simples, Alice paiera 2020 Satoshi à Bob tant qu'il pourra fournir la valeur secrète R dans les 5 blocs, sinon cet argent sera renvoyé à Alice.
3. Bob crée un HTLC dans son canal avec Carol en utilisant la même valeur de hachage H fournie par Alice. Le temps de verrouillage est fixé à 4 blocs futurs et le montant de sortie est de 2010 Satoshi, dont 10 Satoshi sont des frais pour le nœud de routage Carol. En termes simples, Bob paiera 2010 Satoshi à Carol tant qu'il pourra fournir la valeur secrète R dans les 4 blocs, sinon l'argent sera retourné à Bob.
4. Dans son canal avec David, Carol utilise la même valeur de hachage H pour créer un HTLC, avec un verrou temporel réglé sur 3 blocs à venir et un montant de sortie de 2000 Satoshi. En termes simples, Carol paiera à David 2000 Satoshi tant qu'il pourra fournir la valeur secrète R dans les 3 blocs à venir ; sinon, l'argent sera renvoyé à Carol.
5. David déverrouille l'HTLC mis en place par Carol avec la valeur secrète R et récupère 2000 Satoshi.
6. Après que David ait pris l'argent, Carol saura aussi la valeur secrète R, avec laquelle il déverrouillera le HTLC défini par Bob et prendra 2010 Satoshi. Après que Carol ait pris l'argent, Bob reçoit également la valeur secrète R. Il utilise R pour déverrouiller l'HTLC configurée par Alice et obtient 2020 Satoshi.

Grâce à ce mécanisme, Alice a réussi à payer 2000 Satoshi à David sans avoir à établir directement un canal de paiement. Tout au long du processus, les parties n'ont pas besoin de se faire mutuellement confiance, et le Nœud de routage a également reçu les frais qui lui revenaient. Même en cas d'interruption du paiement à un certain stade, grâce au mécanisme de verrouillage temporel, les parties ne subiront aucune perte et les fonds seront automatiquement restitués après expiration du délai de verrouillage.

Cependant, HTLC présente également un problème potentiel de confidentialité : toute la voie utilise la même valeur secrète (pré-image). Si une entité contrôle plusieurs nœuds sur le chemin de paiement, il est possible de déduire des informations complètes sur la transaction en comparant les entrées et les sorties de différents nœuds, voire de deviner l'expéditeur et le destinataire, ce qui affaiblit la protection de la vie privée réalisée par le réseau Lightning via le routage en oignon.

Pour résoudre ce problème, la communauté BTC a proposé le PTLC (Point Time Lock Contract). Dans le cadre du schéma PTLC, chaque saut du chemin utilise une valeur secrète différente, ce qui protège la confidentialité réalisée par le routage oignon. Le plan Nervos CKB Lightning Network Fiber Network prévoit d'introduire le PTLC à l'avenir pour renforcer davantage la protection de la vie privée de Lightning Network.

Conclusion

Avec l'avancement constant de la technologie, le Lightning Network continue d'être optimisé et amélioré. De LN-Penalty à eltoo en passant par Daric, de HTLC à PTLC, nous avons vu le Lightning Network s'améliorer constamment en termes de sécurité et de protection de la vie privée. À l'avenir, avec l'application de plus de technologies innovantes et l'amélioration de l'écosystème, le Lightning Network pourrait devenir une infrastructure clé pour promouvoir la popularité des cryptoactifs et contribuer à une véritable économie P2P.

Références