Analyse du système Fiber : une expérience ambitieuse qui connecte le Lightning Network à CKB

Le 23 août, l’équipe officielle de CKB a publié Fiber Network (réseau de fibres), un projet basé sur Lightning Network de CKB. Cette nouvelle a rapidement suscité un vif débat dans la communauté et a entraîné une hausse de près de 30 % du prix de CKB en une journée. Cette réaction intense s’explique principalement par le puissant attrait narratif de Lightning Network et par les nombreuses améliorations apportées par Fiber de CKB au Lightning Network traditionnel.

Par exemple, Fiber peut prendre en charge nativement plusieurs types d’actifs, tels que CKB, BTC, des stablecoins, etc., et les frais de transaction de CKB sont beaucoup plus bas que ceux de BTC, et la vitesse de réponse est rapide. Ainsi, Fiber peut réaliser une percée en termes d’expérience utilisateur. En termes de confidentialité et de sécurité, Fiber a également apporté de nombreuses améliorations.

En outre, Fiber et BTCLightning Network peuvent interconnecter pour former un réseau P2P plus important, lors d’événements hors ligne précédents, CKB a même indiqué officiellement qu’il mettrait en place 100 000 Nœuds physiques dans Fiber et Lightning Network pour promouvoir l’amélioration et le progrès du Réseau de paiement P2P. Il ne fait aucun doute que c’est une histoire sans précédent.

Si la vision officielle de CKB est réalisée à l’avenir, ce sera une énorme information positive pour Lightning Network, CKB et l’écosystème BTC. Selon les données de la mempool, plus de 300 millions de dollars sont actuellement placés dans le réseau BTCLightning, avec environ 12 000 nœuds et près de 50 000 canaux de paiement construits entre eux.

Et sur spendmybtc.com, nous pouvons également voir de plus en plus de commerçants accepter les paiements via le réseau Lightning Network. Plus le BTC sera reconnu, plus la popularité du réseau Lightning Network et des solutions de paiement hors chaîne telles que Fiber augmentera.

Dans le but de fournir une interprétation systématique de la solution technique de Fiber, ‘Geek Web3’ a rédigé ce rapport de recherche sur la solution globale de Fiber. En tant que solution de mise en œuvre du Lightning Network basée sur CKB, Fiber présente des similitudes globales avec le Lightning Network de BTC, mais comporte de nombreuses optimisations dans les détails.

**L’architecture globale de Fiber se compose des quatre éléments principaux suivants : Payment Channel, WatchTower, Multi-Hop Routing et Cross-Domain Payment. **Commençons par expliquer les « canaux de paiement » les plus importants.

Le réseau Lightning et la base de Fiber : les canaux de paiement

Les canaux de paiement sont essentiellement des transactions / échanges hors chaîne, qui sont soumis à des ‘Règlements’ hors chaîne ultérieurs. Étant donné que les transactions sont effectuées instantanément hors chaîne, elles peuvent souvent se libérer des limitations de performance de mainchain telles que BTC.

Supposons qu’Alice et Bob ouvrent un canal ensemble. Ils commencent par construire un compte multi-signature off-chain, dans lequel ils déposent chacun 100 yuans, constituant ainsi leur solde respectif dans le canal off-chain. Ensuite, les deux parties peuvent effectuer plusieurs transactions dans le canal, et lorsqu’elles quittent le canal, le solde final est synchronisé off-chain, et le règlement final est effectué aux deux parties par le compte multi-signature, c’est-à-dire le “Règlement”.

Par exemple, au début, les deux parties ont 100 yuans chacune. Ensuite, Alice transfère 50 yuans à Bob, puis 10 yuans, puis Bob transfère 30 yuans à Alice. Finalement, les soldes des deux parties sont les suivants: Alice - 70, Bob - 130. Tout le monde peut facilement constater que la somme des soldes des deux est restée la même. L’exemple de l’abaque dans l’image ci-dessus peut bien expliquer ce point.

Si l’une des parties quitte le canal, le solde actuel Alice: 70/Bob: 130 est synchronisé hors chaîne, et les 200 yuans dans le compte commun sont transférés à chacun en fonction de leur solde respectif, pour finaliser le règlement. Le processus ci-dessus semble simple, mais il faut tenir compte de nombreuses situations complexes lors de la mise en œuvre.

Tout d’abord, vous ne savez pas vraiment quand l’autre partie souhaite sortir du canal. Prenez l’exemple ci-dessus, Bob peut sortir après la deuxième transaction, ou même après la première transaction, et le canal de paiement ne l’oblige pas à le faire, il permet aux participants de sortir librement. Pour ce faire, il faut supposer que quelqu’un peut sortir à tout moment, et n’importe quelle partie peut soumettre le solde final hors chaîne pour un règlement.

Il y a donc une configuration de ‘transaction d’engagement’ qui est utilisée pour déclarer le solde le plus récent des deux parties du canal. Chaque transaction génère une ‘transaction d’engagement’ correspondante lorsque le transfert d’argent a lieu. Si vous souhaitez quitter le canal, vous pouvez soumettre la dernière ‘transaction d’engagement’ à off-chain pour retirer votre argent du compte en plusieurs signatures.

Nous pouvons tirer la conclusion suivante : les transactions de promesse sont utilisées pour régler les soldes des deux parties hors de la chaîne. À tout moment, l’une ou l’autre des parties peut mettre à jour les transactions de promesse les plus récentes sur la chaîne, puis quitter le canal.

Cependant, il y a un scénario malveillant important ici : Bob peut soumettre des soldes expirés et des transactions de promesse off-chain, comme le Commit Tx3 généré dans le graphique ci-dessus, le solde de Bob est de 130, mais Bob, dans le but de faire des profits, soumet le Commit Tx2 expiré off-chain, déclarant que son solde est de 160, et cet état de solde n’est pas en temps réel, ce qui correspond à une «Double dépense» typique.

Pour éviter de tels scénarios de double dépense, des mesures punitives appropriées doivent être prises, et la conception de ces mesures punitives est précisément au cœur du canal de paiement 1 pour 1. Comprendre cette partie est essentiel pour une véritable compréhension du canal de paiement. Dans la conception du canal, si l’une ou l’autre des parties soumet un état expiré et un Commit Tx à off-chain, non seulement elles n’obtiendront pas ce qu’elles veulent, mais elles risquent également de perdre tous leurs fonds au profit de l’autre partie.

Ici, les concepts de “transaction d’engagement asymétrique” et de "révocation de Clé secrète " sont très importants. Commençons par expliquer la “transaction d’engagement asymétrique”. Prenons l’exemple de Commit Tx3 précédent, le schéma ci-dessous est un schéma de transaction d’engagement :

Cette transaction de promesse est construite par Bob et envoyée à Alice pour que l’autre partie la traite elle-même. Comme le montre l’image, il s’agit d’un transfert de BTC déclarant que 70 yuans de l’ensemble de comptes multi-signatures sont donnés à Alice et 130 yuans sont donnés à Bob, mais les conditions de déverrouillage de l’argent sont “asymétriques”, les restrictions auxquelles Alice est confrontée sont plus strictes et sont plus favorables à Bob.

Après avoir reçu la transaction d’engagement construite par Bob, Alice peut ajouter sa propre signature pour satisfaire à la condition 2/2 multi-signatures. Ensuite, Alice peut soumettre activement la “transaction d’engagement” à la chaîne, ce qui lui permet de quitter le canal. Si elle ne le fait pas, elle peut continuer à effectuer des transferts dans le canal.

Ici, nous devons faire attention : cette transaction d’engagement est initiée par Bob, avec des conditions défavorables à Alice, qui ne peut que l’accepter ou la refuser. Nous devons trouver un moyen de laisser à Alice une certaine autonomie. Dans la conception du canal de paiement, seul Alice peut déclencher la transaction d’engagement “défavorable à elle-même” hors chaîne, car cette transaction d’engagement doit être signée par 2/2 multi-sig, et après que Bob ait construit la transaction localement, il n’a que sa signature, sans celle d’Alice.

Et Alice peut “recevoir uniquement la signature de Bob sans lui envoyer sa propre signature”, ce qui est similaire à un contrat défavorable pour vous, qui nécessite une double signature de votre part et de l’autre partie. L’autre partie signe d’abord le document et vous le remet, mais vous pouvez empêcher l’autre partie d’obtenir la signature. Si vous souhaitez que le contrat soit effectif, vous le signez puis le publiez, sinon vous ne le signez pas ou ne le publiez pas. Il est évident que dans l’exemple ci-dessus, Alice a le moyen de restreindre Bob.

Ensuite, passons à l’essentiel : à chaque fois qu’une transaction a lieu dans le canal, une paire de transactions d’engagement apparaît, avec deux versions similaires en miroir, comme ci-dessous. Alice et Bob peuvent chacun construire des transactions d’engagement favorables à eux-mêmes, déclarer le solde/le montant à recevoir lors de la fermeture, puis envoyer le contenu de la transaction à l’autre partie pour traitement.

Il est intéressant de noter que les deux opérations d’engagement ont le même « montant à recevoir à la sortie » mais des conditions de retrait différentes, d’où l’origine de la « transaction d’engagement asymétrique ». **

Nous avons expliqué plus tôt que chaque transaction de promesse nécessite une signature 2/2 pour être validée. Une transaction de promesse avantageuse pour Bob, construite localement, ne satisfait pas la condition de signature 2/2, alors qu’une transaction de promesse qui satisfait cette condition est retenue par Alice et ne peut pas être soumise par Bob. Cela crée un équilibre. Il en va de même dans l’autre sens.

Ainsi, Alice et Bob ne peuvent soumettre que des transactions d’engagement qui leur sont défavorables. Dès que l’une des parties soumet Commit Tx à la chaîne et qu’elle est effective, le canal est fermé. En revenant au scénario de «Double dépense», que se passe-t-il si quelqu’un soumet une transaction d’engagement expirée à la chaîne ?

Il convient de mentionner quelque chose appelé "撤销Clé secrète ". ** Si Bob soumet une transaction de promesse expirée à la chaîne, Alice peut récupérer l’argent dû à Bob en utilisant la clé secrète de révocation. **

Nous regardons le schéma ci-dessous, supposons que la dernière transaction d’engagement soit Commit Tx3, Commit Tx2 a expiré, si Bob soumet le Tx2 expiré à off-chain, Alice peut retirer l’argent de Bob avec la révocation de la Clé secrète de Tx2 (Alice doit agir dans la plage de verrouillage temporel).

Cependant, pour le dernier Tx3, Alice n’a pas révoqué la Clé secrète, et ne pourra obtenir la Clé secrète révoquée de Tx3 qu’après l’apparition de Tx4 dans le futur. Cela est déterminé par les caractéristiques de la cryptographie à clé publique/privée et de l’UTXO. Pour des raisons de longueur, cet article ne va pas approfondir les principes de mise en œuvre de la révocation de Clé secrète.

Nous pouvons retenir la conclusion : tant que Bob ose soumettre des transactions de promesse expirées sur la chaîne, Alice peut utiliser la révocation de la Clé secrète  pour prendre l’argent de Bob en guise de punition. Inversement, si Alice agit mal, Bob peut également la punir de cette manière. Ainsi, les canaux de paiement 1 sur 1 peuvent éviter efficacement la Double dépense, tant que les participants sont rationnels et n’osent pas agir malhonnêtement.

En ce qui concerne ce canal de paiement, Fiber basé sur CKB est nettement optimisé par rapport à BTCLightning Network et peut prendre en charge nativement le transfert / la transaction de plusieurs types d’actifs tels que CKB, BTC et RGB ++ Stable Coin, tandis que Lightning Network ne peut prendre en charge nativement que BTC. Après le lancement de Taproot Asset, BTCLightning Network ne pourra toujours pas prendre en charge les actifs non-BTC nativement, mais seulement indirectement les Stable Coin.

(Source de l’image: Dapangdun)

De plus, étant donné que Fiber dépend de la mainchain Layer1, qui est CKB, les frais de transaction pour l’ouverture et la fermeture des canaux sont beaucoup plus bas, ce qui n’entraîne pas la même perte importante de frais pour les utilisateurs que le Lightning Network de BTC, ce qui constitue un avantage évident en termes d’expérience utilisateur.

Sécurité à toute épreuve : WatchTower Tour de guet

Le problème avec la révocation de la Clé secrète mentionnée précédemment est le suivant : Les participants du canal doivent surveiller en permanence l’autre partie pour éviter qu’elle ne soumette des transactions de promesses expirées de manière sournoise. Cependant, personne ne peut garantir une disponibilité 24 heures sur 24. Que faire si l’autre partie agit mal pendant que vous êtes hors ligne ?

À cet égard, à la fois Fiber et BTCLightning Network ont conçu une WatchTower pour surveiller les activités hors chaîne des utilisateurs 24 heures sur 24. Si quelqu’un soumet une transaction de promesse expirée dans le canal, WatchTower la traitera rapidement pour garantir la sécurité du canal et des fonds.

Les explications spécifiques sont les suivantes : Pour chaque transaction de promesse expirée, Alice ou Bob peut préparer à l’avance la transaction de punition correspondante (en révoquant la clé secrète pour traiter la transaction de promesse expirée, le bénéficiaire se déclarant lui-même), puis envoyer le texte clair de la transaction de punition à WatchTower. Une fois que WatchTower détecte que quelqu’un soumet une transaction de promesse expirée à la chaîne, il soumettra également la transaction de punition à la chaîne pour une punition ciblée.

Afin de protéger la vie privée des participants des canaux, Fiber ne permet aux utilisateurs de fournir que le hash de la transaction de promesse expirée avec le texte clair de la transaction de punition à WatchTower. Ainsi, WatchTower ne connaît pas le texte clair de la transaction de promesse au début, mais seulement son hash. À moins qu’une personne ne soumette réellement la transaction de promesse expirée off-chain, WatchTower ne verra alors le texte clair et soumettra rapidement la transaction de punition sur la chaîne. De cette façon, sauf si quelqu’un agit mal, WatchTower ne verra pas les enregistrements de transactions des participants du canal (même s’il les voit, il ne peut voir qu’une seule transaction).

Ici, nous devons mentionner l’optimisation de Fiber par rapport à BTCLightning Network. Le mécanisme de sanction lié à l’annulation de la Clé secrète mentionné ci-dessus est appelé « LN-Penalty », et LN-Penalty de BTCLightning Network présente des inconvénients évidents : WatchTower doit conserver tous les hash des transactions de promesse expirées et les Clé secrète d’annulation correspondantes, ce qui entraîne une pression de stockage non négligeable.

Dès 2018, la communauté BTC a proposé une solution appelée “eltoo” pour résoudre ce problème, mais elle nécessite le support de BTCfork pour l’opération SIGHASH_ANYPREVOUT. L’idée est que lorsque la transaction de promesse expirée est confirmée, la dernière transaction de promesse peut la pénaliser, de sorte que l’utilisateur n’a besoin de conserver que la dernière transaction de promesse. Cependant, l’opération SIGHASH_ANYPREVOUT n’a pas encore été activée, et cette solution tarde à être mise en œuvre.

Et ** Fiber implémente le protocole Daric, modifiant la conception de la Clé secrète de révocation, de sorte qu’une même Clé secrète de révocation puisse être utilisée pour plusieurs transactions de promesse expirées. Cela permet de réduire considérablement la pression de stockage sur WatchTower et les clients utilisateurs. **

Système de transport dans les réseaux : routage multi-sauts et HTLC/PTLC

Le canal de paiement mentionné précédemment ne s’applique qu’aux transactions en tête-à-tête, tandis que le Lightning Network prend en charge les paiements multi-sauts, c’est-à-dire, en routant via un nœud intermédiaire, permettant ainsi des transferts entre deux parties qui n’ont pas directement établi de canal. Par exemple, Alice et Ken n’ont pas de canal, mais Ken a un canal avec Bob, et Bob a un canal avec Alice, Bob peut alors agir en tant que nœud intermédiaire entre Alice et Ken, permettant des transactions entre eux. Le “chemin multi-sauts” fait référence à la construction d’un chemin de transfert via plusieurs intermédiaires.

Le « routage multi-sauts » améliore la flexibilité et la couverture du réseau. Cependant, l’expéditeur doit être au courant de l’état de tous les nœuds et canaux publics. Dans la fibre, tous les canaux publics, c’est-à-dire les structures de réseau, sont entièrement publics, et n’importe quel nœud peut accéder aux informations réseau dont disposent les autres noeuds. Étant donné que l’état de l’ensemble du réseau dans le réseau Lightning est en constante évolution, Fiber utilisera l’algorithme Dijkstra Shortest Path pour trouver le chemin de routage le plus court, maintenir le nombre d’intermédiaires aussi petit que possible, puis mettre en place un chemin de transfert entre les deux parties. **

Cependant, il est nécessaire de résoudre le problème de crédibilité de l’intermédiaire Nœud : comment pouvez-vous vous assurer qu’il est honnête, par exemple, Alice et Ken ont mentionné auparavant qu’il y avait un intermédiaire Bob, et maintenant Alice veut transférer 100 yuans à Ken, Bob pourrait retenir cet argent à tout moment. Il doit y avoir un moyen d’empêcher l’intermédiaire de faire du mal, HTLC et PTLC sont utilisés pour résoudre de tels problèmes.

假设Alice要向Daniel付款100块，但他们之间没有建立通道。而Alice发现，可以通过Bob和Carol这两个intermédiaire向Daniel付款。这里面要引入HTLC作为支付渠道，首先Alice向Daniel发起请求，然后Daniel发给Alice一个哈希r，但Alice不知道r对应的Texte clairR。

Par la suite, Alice construit des modalités de paiement via HTLC dans le canal avec Bob : Alice est prête à payer 102 pièces à Bob, mais ce dernier doit révéler la clé R dans les 30 minutes, sinon Alice retirera l’argent. De même, Bob crée à son tour un HTLC avec Carol : il s’engage à payer 101 pièces à Carol, mais cette dernière doit révéler la clé R dans les 25 minutes, sinon Bob retirera l’argent.

Carol如法炮制，在和Daniel的通道中创建HTLC：Carol愿意支付100块，但Daniel要在20分钟内告诉她R的Texte clair，否则钱会被Carol收回。

Daniel comprend que la clé R demandée par Carol est en fait ce qu’Alice veut, car personne d’autre que Alice ne se soucie de ce que contient R. Ainsi, Daniel coopérera avec Carol, lui dira le contenu de R et recevra 100 dollars d’elle, ce qui permettra à Alice d’atteindre son objectif : donner 100 dollars à Carol.

Ce qui se passe ensuite n’est pas difficile à imaginer : Carol donne la clé R à Bob et reçoit 101 yuans ; Bob donne ensuite la clé R à Alice et reçoit 102 yuans. En observant les gains et les pertes de chacun, on peut constater qu’Alice perd 102 yuans, que Bob et Carol gagnent nettement 1 yuan et que Daniel obtient 100 yuans. Les 1 yuan gagnés par Bob et Carol sont les frais qu’ils prélèvent à Alice.

Même si quelqu’un dans le chemin de paiement ci-dessus, comme Carol, ne donne pas la clé R à Bob en aval, cela ne causera pas de perte à Bob: il peut retirer le HTLC construit après un certain temps. Cela s’applique également à Alice.

Cependant, le Lightning Network a également des problèmes : les chemins ne doivent pas être trop longs, car plus il y a d’intermédiaires dans le chemin, plus la fiabilité du paiement est susceptible de tomber : certains intermédiaires peuvent être hors ligne ou avoir des soldes insuffisants pour construire des HTLC spécifiques (par exemple, chaque intermédiaire dans l’exemple précédent devait avoir au moins 100 yuans). Ainsi, chaque ajout d’un Nœud intermédiaire dans le chemin augmente la probabilité d’erreur.

De plus, le **HTLC peut potentiellement divulguer la vie privée. Bien que le routage en oignon puisse protéger la vie privée de manière appropriée, **par exemple en chiffrant les informations de routage à chaque saut, sauf pour l’initiateur initial Alice, chaque personne ne connaît que les voisins adjacents, sans connaître le chemin complet, **mais en réalité, le HTLC est toujours facilement inféré en termes d’association. **Nous jetons un coup d’œil à ce chemin ci-dessous du point de vue de Dieu.

Supposons que Bob et Daniel sont deux nœuds contrôlés par la même entité, et reçoivent chaque jour de nombreux HTLC de la part de différentes personnes. Ils constatent que chaque fois qu’Alice et Carol envoient un HTLC, la clé secrète à connaître est toujours la même, et que le destinataire suivant, Eve, connecté à Daniel, connaît toujours le contenu de la clé secrète R. Ainsi, Daniel et Bob peuvent deviner qu’il existe un chemin de paiement entre Alice et Eve, car ils sont toujours liés à la même clé secrète, ce qui leur permet de déduire la relation entre Alice et Eve et de surveiller cette dernière.

Pour ce faire, Fiber utilise le PTLC, qui améliore la confidentialité par rapport au HTLC. Chaque PTLC dans le chemin de paiement est déverrouillé avec une Clé secrète différente, de sorte que l’observation pure de la Clé secrète demandée par le PTLC ne permet pas de déterminer leur corrélation mutuelle. En combinant le PTLC avec le routage en oignon, Fiber devient une solution idéale pour les paiements privés.

En outre, le réseau Lightning traditionnel est confronté à une situation d’“attaque de cycle de transaction de remplacement” (replacement cycling attack), qui peut permettre le vol d’actifs de l’intermédiaire du chemin de paiement. Cette découverte a même conduit le développeur Antoine Riard à abandonner le travail de développement sur le réseau Lightning. Jusqu’à présent, le réseau Lightning BTC n’a pas pris de mesures fondamentales pour résoudre ce problème, ce qui en fait un point douloureux.

Actuellement, l’officiel CKB peut résoudre ce scénario d’attaque sur Fiber en améliorant au niveau du pool de transactions. Étant donné que les attaques de remplacement de transaction et leurs solutions sont assez complexes, cet article n’a pas l’intention de continuer à expliquer en détail. Si cela vous intéresse, vous pouvez lire l’article suivant de BTCStudy ainsi que les documents officiels de CKB.

Dans l’ensemble, Fiber a apporté des améliorations considérables à la fois en termes de confidentialité et de sécurité par rapport au réseau Lightning traditionnel.

Les paiements atomiques inter-chaînes entre Fiber et BTCLightning Network

En utilisant HTLC et PTLC, Fiber peut réaliser des paiements inter-domaines avec BTCLightning Network, et garantir l’atomicité des actions inter-domaines, c’est-à-dire que toutes les étapes liées aux paiements inter-domaines réussissent toutes ensemble ou échouent toutes ensemble, sans qu’il y ait de succès partiel ou d’échec partiel.

Une fois que l’atomicité inter-domaines est garantie, cela peut garantir que les pertes de propriété ne seront pas causées par le croisement inter-domaines, ce qui permet à Fiber et BTCLightning Network de s’interconnecter, par exemple en établissant des chemins de paiement dans un réseau hybride composé de Fiber et Lightning Network, en transférant directement des fonds de Fiber à des utilisateurs de BTCLightning Network (destinataires limités à BTC), et en échangeant des actifs CKB et RGB++ contre des BTC équivalents dans BTCLightning Network via Fiber.

Nous allons expliquer brièvement le principe : supposons qu’Alice exécute un Nœud dans le réseau Fiber, tandis que Bob exécute un Nœud dans le réseau BTCLightning. Alice souhaite transférer de l’argent à Bob, elle peut le faire en passant par l’intermédiaire Ingrid. Plus précisément, Ingrid exécutera un Nœud à la fois dans le réseau Fiber et dans le réseau BTCLightning, agissant en tant qu’intermédiaire dans le chemin de transfert.

Si Bob veut recevoir 1 BTC, Alice peut négocier le taux de change avec Ingrid, par exemple en échangeant 1 CKB contre 1 BTC. Alice peut envoyer 1,1 CKB à Ingrid dans Fiber, puis Ingrid envoie 1 BTC à Bob dans le réseau Lightning Network, en conservant 0,1 CKB comme frais.

Ingrid

Il est important de noter que les transactions dans BTCLightning Network et Fiber sont toutes deux des opérations atomiques, ce qui signifie que soit les deux HTLC sont déverrouillés et le paiement transfrontalier est effectué avec succès, soit aucun des deux n’est déverrouillé et le paiement transfrontalier échoue, sans qu’Alice donne de l’argent à Bob et que ce dernier ne le reçoive pas.

（En fait, intermédiaireIngrid peut choisir de ne pas déverrouiller l’HTLC d’Alice une fois qu’elle connaît la clé R, mais cela endommagerait l’intermédiaireIngrid, pas l’utilisateur Alice. Ainsi, la conception de Fiber est sûre pour l’utilisateur）

Ce mode ne nécessite pas de faire confiance à un tiers pour effectuer des transactions entre différents réseaux P2P, et ne nécessite presque aucune modification.

Autres avantages de Fiber par rapport à BTC Lightning Network

Nous avons mentionné précédemment que Fiber prend en charge les actifs natifs CKB ainsi que les actifs RGB++ (en particulier les stablecoins), ce qui lui confère un potentiel considérable dans les scénarios de paiement en temps réel, et le rend plus adapté aux besoins de paiement de petites sommes au quotidien.

En outre, BTCLightning Network a un point douloureux majeur, qui est le problème de Liquidité gestion. Vous vous souviendrez peut-être de ce que nous avons dit au début, le solde global dans le canal de paiement est fixe, si le solde d’une partie est épuisé, il ne peut pas transférer d’argent à l’autre partie à moins que cette dernière ne lui transfère d’abord de l’argent, à ce moment-là, il faudra réinjecter des fonds ou ouvrir un nouveau canal.

Par ailleurs, dans un réseau multi-sauts complexe, un solde insuffisant dans certains Nœud intermédiaires peut empêcher les transferts sortants, ce qui peut entraîner l’échec de l’ensemble du chemin de paiement. Il s’agit là d’un des problèmes majeurs du Lightning Network, et la solution ne peut être autre que de fournir des solutions d’injection de Liquidité efficaces pour garantir que la plupart des Nœud puissent injecter des fonds à tout moment.

Cependant, dans le réseau BTCLightning, les étapes d’injection de Liquidité, d’ouverture ou de fermeture de canal sont effectuées sur la chaîne BTC. Si les frais de transaction BTC sont très élevés, cela aura un impact négatif sur l’expérience utilisateur des canaux de paiement. Supposons que vous souhaitiez ouvrir un canal d’une capacité de 100 dollars, mais que l’opération de création du canal coûte 10 dollars de frais. Dans ce cas, le capital de ce canal sera réduit de 10% dès son initialisation, ce qui est inacceptable pour la plupart des gens ; il en va de même pour l’injection de Liquidité, etc.

Fiber a des avantages considérables à cet égard. Tout d’abord, le TPS de CKB est beaucoup plus élevé que celui de BTC, les frais étant de l’ordre des centimes. Deuxièmement, afin de résoudre le problème de l’insuffisance de Liquidité qui empêche les transferts, Fiber prévoit de collaborer avec Mercury layer pour proposer une nouvelle solution qui permettra de se débarrasser des opérations off-chain pour l’injection de Liquidité, résolvant ainsi les problèmes d’UX et de coûts.

Jusqu’à présent, nous avons systématiquement résumé l’architecture technique globale de Fiber, et le résumé approximatif de la comparaison avec le réseau BTCLightning est illustré dans le schéma ci-dessus. Étant donné que Fiber et Lightning Network impliquent eux-mêmes de nombreuses connaissances diverses, un simple article ne peut peut-être pas couvrir tous les aspects. À l’avenir, nous lancerons une série d’articles sur les sujets de Lightning Network et de Fiber, restez à l’écoute.