Transférer le titre original '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'

Le 23 août, CKB a officiellement lancé le Fiber Network, une solution de réseau Lightning basée sur CKB. Cette nouvelle a rapidement suscité d’intenses discussions dans la communauté, ce qui a entraîné une hausse de près de 30 % du prix de CKB en une seule journée. La forte réaction peut être attribuée au récit convaincant du Lightning Network et au fait que la fibre offre une solution améliorée par rapport au réseau Lightning traditionnel avec de nombreuses améliorations. Par exemple, Fiber prend en charge plusieurs types d’actifs en mode natif, notamment CKB, BTC et stablecoins, et bénéficie des frais de transaction moins élevés et des temps de réponse plus rapides de CKB, ce qui permet des avancées significatives en matière d’expérience utilisateur. De plus, Fiber a apporté plusieurs optimisations en termes de confidentialité et de sécurité. De plus, la fibre optique et le réseau Lightning BTC peuvent s’interconnecter, formant ainsi un réseau P2P plus vaste. Les responsables de CKB ont même mentionné qu’ils prévoyaient de mettre en place 100 000 nœuds physiques dans la fibre optique et le réseau Lightning lors d’événements hors ligne pour améliorer et faire progresser le réseau de paiement P2P. Il s’agit sans aucun doute d’une histoire grandiose et sans précédent

Si la vision officielle de CKB se réalise à l'avenir, ce serait un avantage significatif pour le Lightning Network, CKB et l'écosystème Bitcoin dans son ensemble. Selon les données de la mempool, le Lightning Network BTC détient actuellement plus de 300 millions de dollars de fonds, avec environ 12 000 nœuds et près de 50 000 canaux de paiement établis entre eux.

Sur spendmybtc.com, nous pouvons observer qu'un nombre croissant de commerçants soutiennent les paiements du Lightning Network. Avec la reconnaissance croissante du BTC, la montée en puissance des solutions de paiement hors chaîne comme le Lightning Network et Fiber devrait gagner en momentum. Pour analyser de manière systématique la solution technique de Fiber, "Geek Web3" a produit ce rapport de recherche sur la solution globale de Fiber. En tant qu'implémentation du Lightning Network basée sur CKB, les principes de Fiber sont largement cohérents avec le Lightning Network de Bitcoin, mais incluent des optimisations dans de nombreux détails. L'architecture globale de Fiber comprend quatre composants principaux : les canaux de paiement, WatchTower, l'acheminement multi-sauts et les paiements inter-domaines. Commençons par expliquer le composant le plus important : les canaux de paiement.

Les fondations du réseau Lightning et de Fiber : canaux de paiement

Les canaux de paiement déplacent essentiellement les transactions hors de la chaîne, avec l'état final réglé sur la chaîne après un certain temps. Étant donné que les transactions sont effectuées hors chaîne, elles contournent souvent les limitations de performance de la chaîne principale, comme le BTC. Par exemple, si Alice et Bob ouvrent un canal ensemble, ils créent d'abord un compte multi-signature sur la chaîne et déposent des fonds, disons 100 unités chacun, en tant que solde dans le canal hors chaîne. Ils peuvent ensuite effectuer plusieurs transactions dans le canal, et lorsqu'ils ferment le canal, ils synchronisent les soldes finaux sur la chaîne, avec le compte multi-signature effectuant des paiements aux deux parties - c'est le « règlement ».

Par exemple, si les deux parties commencent avec 100 unités chacune, et qu'Alice transfère 50 unités à Bob, suivies d'un autre transfert de 10 unités, puis que Bob transfère 30 unités à Alice, leurs soldes finaux seraient : Alice - 70 unités, Bob - 130 unités. Le solde total reste inchangé, comme le montre l'exemple des perles d'abaque. Si l'une des parties quitte le canal, les soldes finaux (Alice : 70, Bob : 130) sont synchronisés sur la chaîne, et les 200 unités du compte multi-signature sont distribuées selon ces soldes finaux pour compléter le règlement.

Bien que ce processus semble simple, il implique des considérations complexes en pratique. Vous ne pouvez pas prédire quand l'autre partie choisira de sortir du canal. Par exemple, Bob pourrait sortir après la deuxième transaction ou même après la première, car le canal permet aux participants de sortir librement. Pour remédier à cela, le système suppose que n'importe qui pourrait sortir à tout moment, et que l'une ou l'autre partie pourrait soumettre le solde final à la chaîne pour règlement. Cela est géré par le biais de «transactions d'engagement», qui enregistrent les derniers soldes dans le canal. Chaque transaction génère une transaction d'engagement correspondante. Pour sortir du canal, vous soumettez la transaction d'engagement la plus récente à la chaîne pour retirer votre part du compte multi-signature.

Nous pouvons conclure que les transactions d’engagement sont utilisées pour régler les soldes des deux parties dans le canal on-chain, l’une ou l’autre partie pouvant soumettre la dernière transaction d’engagement pour sortir du canal. Cependant, il existe un scénario malveillant crucial : Bob peut soumettre une transaction de solde et d’engagement obsolète à la chaîne. Par exemple, après avoir généré Commit Tx3, le solde de Bob est de 130 unités. Mais à son avantage, Bob pourrait soumettre le Commit Tx2 obsolète, qui affiche un solde de 160 unités. Ce solde obsolète représente une attaque classique de « double dépense ».

Pour éviter de tels scénarios de double dépense, il doit y avoir des mesures de pénalité appropriées. La conception de ces mesures de pénalité est au cœur du système des canaux de paiement individuels, et il est essentiel de les comprendre pour comprendre le fonctionnement des canaux de paiement. Dans la conception du canal, si l’une ou l’autre des parties soumet une transaction d’état et d’engagement obsolète à la chaîne, au lieu d’en bénéficier, elle constatera que l’autre partie peut retirer tous les fonds. Cela utilise les concepts de « transactions d’engagement asymétriques » et de « clés de révocation », qui sont cruciaux. Expliquons d’abord les « transactions d’engagement asymétriques » en utilisant Commit Tx3 comme exemple.

Dans ce scénario, Bob crée une transaction de promesse et l'envoie à Alice pour qu'elle s'en occupe. Comme le montre, cette transaction implique un transfert de Bitcoin, déclarant que 70 unités du compte multi-signature sont allouées à Alice et 130 unités à Bob. Cependant, les conditions de déverrouillage sont 'asymétriques', imposant des restrictions plus sévères à Alice et bénéficiant à Bob.

Lorsque Alice reçoit la transaction d'engagement de Bob, elle peut ajouter sa signature pour répondre à l'exigence de multi-signature 2/2. Alice peut ensuite choisir de soumettre cette transaction d'engagement on-chain pour sortir du canal. Sinon, elle peut continuer à effectuer des transactions dans le canal si elle ne la soumet pas.

Il est crucial de noter que cette transaction d’engagement est construite par Bob et a des conditions défavorables à Alice. Alice a le choix de l’accepter ou de la rejeter, mais nous devons nous assurer qu’elle conserve une certaine autonomie. Dans la conception des canaux de paiement, seule Alice peut soumettre la transaction d’engagement « défavorable » à la chaîne car les transactions d’engagement nécessitent une multi-signature 2/2. Une fois que Bob a construit la transaction localement, elle n’a que sa signature et n’a pas la signature d’Alice.

Alice peut « accepter la signature de Bob mais ne pas révéler la sienne ». C’est similaire à un contrat qui nécessite une double signature. Si Bob signe d’abord et envoie le contrat à Alice, elle peut choisir de ne pas fournir sa signature. Pour que le contrat soit effectif, Alice devait le signer, puis le soumettre. Dans le cas contraire, elle peut s’abstenir de le signer ou de le soumettre. Ainsi, dans ce cas, Alice a les moyens de limiter les actions de Bob.

Le point clé est le suivant : Chaque fois qu'une transaction a lieu dans le canal, une paire de transactions d'engagement est générée, avec deux versions en miroir, comme illustré ci-dessous. Alice et Bob peuvent chacun créer des transactions d'engagement qui leur sont favorables, spécifiant leurs soldes respectifs ou les montants à recevoir à la sortie, puis envoyer ces transactions à l'autre pour qu'il les traite.

Fait intéressant, alors que les deux transactions d'engagement déclarent le même "montant à recevoir à la sortie", leurs conditions de retrait diffèrent. Cela illustre le concept de "transactions d'engagement asymétriques" mentionné précédemment.

Comme expliqué précédemment, chaque transaction d'engagement nécessite une signature multiple 2/2 pour être valide. La transaction d'engagement créée par Bob qui lui est favorable ne répond pas à l'exigence de signature multiple 2/2, tandis que la transaction d'engagement qui répond à cette exigence est détenue par Alice et ne peut être soumise que par elle, créant ainsi un mécanisme de contrôle et d'équilibre. La même logique s'applique dans l'autre sens.

Ainsi, Alice et Bob ne peuvent soumettre que des transactions d'engagement défavorables à eux-mêmes. Si l'une des parties soumet une transaction d'engagement à la chaîne et qu'elle devient effective, le canal est fermé.

En ce qui concerne le scénario de « double-dépense » précédemment discuté, si quelqu'un soumet une transaction d'engagement obsolète à la chaîne, le concept de « clés de révocation » entre en jeu. Par exemple, si Bob soumet la transaction obsolète Tx2 à la chaîne, Alice peut utiliser la clé de révocation associée à Tx2 pour retirer les fonds que Bob était censé recevoir.

Dans le diagramme d'exemple, en supposant que la dernière transaction d'engagement soit Commit Tx3 et que Tx2 soit obsolète, si Bob soumet la transaction obsolète Tx2, Alice peut agir pendant la période de verrouillage temporel en utilisant la clé de révocation de Tx2 pour retirer les fonds de Bob.

Concernant le dernier Tx3, Alice ne possède pas sa clé de révocation et ne la recevra qu'après la création future de Tx4. Cela est dû à la nature de la cryptographie à clé publique/privée et aux propriétés des UTXO. Pour des raisons de concision, les détails de mise en œuvre des clés de révocation ne sont pas discutés ici.

La principale conclusion est que si Bob ose soumettre une transaction d'engagement obsolète à la chaîne, Alice peut utiliser la clé de révocation pour retirer les fonds de Bob en guise de pénalité. De même, si Alice agit de manière malveillante, Bob peut lui appliquer la même pénalité. Ce mécanisme garantit que les canaux de paiement un à un empêchent efficacement les doubles dépenses, car les participants rationnels éviteraient les actions malveillantes.

Dans ce contexte, Fiber, basé sur CKB, offre des améliorations substantielles par rapport au Lightning Network de Bitcoin. Il prend en charge nativement les transactions et les transferts de plusieurs types d'actifs, y compris CKB, BTC et les stablecoins RGB++, tandis que le Lightning Network prend en charge nativement uniquement le Bitcoin. Même avec la mise à niveau de l'actif Taproot, le Lightning Network de Bitcoin ne peut toujours pas prendre en charge nativement les actifs non-BTC et ne peut soutenir indirectement que les stablecoins.

(Source des images : Dapangdun) De plus, comme Fiber s'appuie sur CKB en tant que chaîne principale de couche 1, les frais d'ouverture et de fermeture des canaux sont nettement plus bas par rapport au Lightning Network de BTC. Cela réduit les coûts de transaction pour l'utilisateur, ce qui représente un avantage clair en termes d'expérience utilisateur (UX).

Sécurité 24/7 : WatchTower

Un défi avec les clés de révocation est que les participants au canal doivent constamment se surveiller mutuellement pour empêcher la soumission de transactions d'engagement obsolètes. Cependant, personne ne peut être en ligne 24h/24 et 7j/7, alors que se passe-t-il si une partie agit de manière malveillante pendant que l'autre est hors ligne? Fiber et le réseau Bitcoin Lightning abordent tous deux ce problème grâce à la conception des WatchTowers.

Les WatchTowers sont conçus pour surveiller en permanence les activités on-chain. Si quelqu'un soumet une transaction d'engagement obsolète, le WatchTower prendra des mesures opportunes pour protéger le canal et les fonds. Voici comment ça marche :

Lorsqu'une transaction de commitment est publiée, Alice ou Bob peuvent préparer à l'avance une transaction de pénalité correspondante (en utilisant la clé de révocation pour gérer la transaction de commitment obsolète, avec le bénéficiaire déclaré comme eux-mêmes). Ils fournissent ensuite le texte en clair de cette transaction de pénalité au WatchTower.

Lorsque WatchTower détecte qu'une transaction d'engagement obsolète est soumise à la chaîne, il soumettra également la transaction de pénalité préparée, appliquant la pénalité et protégeant l'intégrité du canal.

Fiber protège la vie privée des participants en demandant aux utilisateurs d'envoyer uniquement le « hash de la transaction d'engagement obsolète + le texte en clair de la transaction de pénalité » à la WatchTower. De cette façon, la WatchTower ne connaît initialement que le hash de la transaction d'engagement, pas son texte en clair. La WatchTower ne voit le texte en clair que si quelqu'un soumet réellement la transaction d'engagement obsolète sur la chaîne, à ce moment-là, elle soumettra également la transaction de pénalité. Cela garantit que la WatchTower ne verra l'historique des transactions d'un participant que s'il y a une faute réelle, et même dans ce cas, elle ne verra qu'une seule transaction.

En termes d'optimisation, Fiber améliore l'approche des mécanismes de pénalité du Lightning Network de Bitcoin. La “LN-Penalty” du Lightning Network présente un inconvénient notable : les WatchTowers doivent stocker tous les hachages des transactions d'engagement obsolètes et les clés de révocation correspondantes, ce qui entraîne une pression de stockage significative. En 2018, la communauté Bitcoin a proposé une solution appelée “eltoo” pour résoudre ce problème. Eltoo permettrait à la dernière transaction d'engagement de pénaliser les transactions obsolètes, réduisant ainsi le besoin de stocker toutes les transactions précédentes. Cependant, cette solution nécessite l'activation de l'opcode SIGHASH_ANYPREVOUT, qui n'a pas encore été implémenté.

D'autre part, Fiber utilise le protocole Daric, qui modifie la conception de la clé de révocation pour rendre une seule clé de révocation applicable à plusieurs transactions d'engagement obsolètes. Cette approche réduit considérablement les exigences de stockage pour les WatchTowers et les clients utilisateurs.

En ce qui concerne les systèmes de trafic réseau : Les canaux de paiement conviennent aux transactions de type un à un, mais le Lightning Network prend en charge les paiements à plusieurs sauts, permettant des transactions entre des parties qui n'ont pas de canal direct en acheminant les paiements via des nœuds intermédiaires. Par exemple, si Alice et Ken n'ont pas de canal direct mais que Ken et Bob en ont un, et que Bob et Alice en ont un, Bob peut agir comme intermédiaire pour faciliter les transactions entre Alice et Ken.

Le « routage multi-sauts » améliore la flexibilité et la couverture du réseau. Toutefois, les expéditeurs doivent connaître l’état de tous les nœuds et canaux publics. Dans Fiber, l’ensemble de la structure du réseau, y compris tous les canaux publics, est entièrement transparent, ce qui permet à n’importe quel nœud d’accéder aux informations du réseau à partir d’autres nœuds. Étant donné que l’état du réseau dans le réseau Lightning change constamment, Fiber utilise l’algorithme de Dijkstra pour trouver le chemin de routage le plus court, minimisant ainsi le nombre d’intermédiaires et établissant un chemin de transaction entre les deux parties.

Pour résoudre le problème de confiance avec les intermédiaires : Comment pouvez-vous vous assurer qu'ils sont honnêtes ? Par exemple, si Alice doit effectuer un paiement de 100 unités à Ken, mais que Bob, qui est un intermédiaire entre eux, pourrait retenir les fonds. HTLC et PTLC sont utilisés pour prévenir un tel comportement malveillant. Supposons qu'Alice veuille payer Daniel 100 unités, mais qu'ils n'aient pas de canal direct. Alice découvre qu'elle peut acheminer le paiement par les intermédiaires Bob et Carol. HTLC est introduit en tant que canal de paiement : Alice initie d'abord la demande à Daniel, qui fournit ensuite à Alice un hachage r, mais Alice ne connaît pas l'image pré-image R correspondant à r.

Ensuite, Alice construit les modalités de paiement avec Bob via HTLC : Alice est prête à payer Bob 102 unités, mais Bob doit révéler la clé R dans les 30 minutes ; sinon, Alice retirera l'argent. De même, Bob crée un HTLC avec Carol : Bob paiera Carol 101 unités, mais Carol doit révéler la clé R dans les 25 minutes ; sinon, Bob retirera l'argent. Carol fait de même avec Daniel : Carol est prête à payer Daniel 100 unités, mais Daniel doit révéler la clé R dans les 20 minutes ; sinon, Carol retirera l'argent.

Daniel comprend que la clé R demandée par Carol est en fait ce qu'Alice veut, car seule Alice s'intéresse à la valeur de R. Ainsi, Daniel coopère avec Carol, fournit la clé R et reçoit 100 unités de la part de Carol. De cette façon, Alice atteint son objectif de payer Daniel 100 unités.

Par la suite, Carol fournit la clé R à Bob et reçoit 101 unités. Bob fournit ensuite la clé R à Alice et reçoit 102 unités. En observant les gains et les pertes de chacun, Alice perd 102 unités, Bob et Carol gagnent chacun un bénéfice net de 1 unité, et Daniel reçoit 100 unités. L'unité gagnée par Bob et Carol est leur commission extraite d'Alice.

Même si quelqu'un sur le chemin de paiement, comme Carol, ne parvient pas à fournir la clé R au flux descendant Bob, cela ne se traduit pas par une perte pour Bob : après le délai d'attente, Bob peut retirer l'HTLC qu'il a construit. Il en va de même pour Alice. Cependant, le réseau Lightning a ses problèmes : les chemins ne doivent pas être trop longs. Si le chemin est trop long avec trop d'intermédiaires, cela peut réduire la fiabilité du paiement. Certains intermédiaires peuvent être hors ligne ou ne pas avoir un solde suffisant pour construire un HTLC spécifique (par exemple, chaque intermédiaire dans l'exemple précédent doit détenir plus de 100 unités). Par conséquent, l'ajout de plus d'intermédiaires augmente la probabilité d'erreurs.

De plus, les HTLC peuvent compromettre la confidentialité. Bien que l'acheminement en oignon puisse offrir une certaine protection de la vie privée en cryptant les informations d'acheminement à chaque saut, de sorte que chaque participant ne connaisse que ses voisins immédiats et non le chemin complet, les HTLC restent vulnérables à l'inférence des relations. D'un point de vue plus élevé, le chemin d'acheminement complet peut toujours être déduit.

Supposons que Bob et Daniel soient contrôlés par la même entité et reçoivent de nombreux HTLCs chaque jour. Ils remarquent que la clé R demandée par Alice et Carol est toujours la même et que le nœud aval Eve, connecté à Daniel, connaît toujours le contenu de la clé R. Par conséquent, Daniel et Bob peuvent déduire qu'il existe un chemin de paiement entre Alice et Eve, car ils traitent toujours avec la même clé et peuvent surveiller leur relation. Pour remédier à cela, Fiber utilise des PTLCs, qui améliorent la confidentialité des HTLCs en utilisant des clés différentes pour déverrouiller chaque PTLC dans le chemin de paiement. Observer uniquement les PTLCs ne peut pas déterminer les relations entre les nœuds. En combinant les PTLCs avec l'acheminement en oignon, Fiber devient une solution idéale pour les paiements respectueux de la vie privée.

De plus, le réseau Lightning traditionnel est vulnérable à une « attaque de cycle de remplacement », qui peut entraîner le vol d'actifs auprès des intermédiaires dans le chemin de paiement. Ce problème a conduit le développeur Antoine Riard à se retirer du développement de Lightning Network. À l'heure actuelle, le réseau Bitcoin Lightning ne dispose pas d'une solution fondamentale à ce problème, ce qui en fait un point douloureux. Actuellement, CKB aborde ce scénario d'attaque grâce à des améliorations au niveau du pool de transactions, permettant à Fiber de mitiGate le problème. Comme l'attaque de cycle de remplacement et ses solutions sont assez complexes, cet article n'approfondira pas davantage. Les lecteurs intéressés peuvent se référer aux articles connexes de BTCStudy et aux ressources officielles de CKB pour plus d'informations.

Dans l'ensemble, Fiber représente une amélioration significative par rapport au réseau Lightning traditionnel, tant en termes de confidentialité que de sécurité. Fiber améliore les paiements atomiques inter-domaines entre lui-même et le réseau Lightning Bitcoin.

En utilisant HTLC et PTLC, Fiber peut réaliser des paiements inter-domaines avec le réseau Bitcoin Lightning, garantissant l'« atomicité des actions inter-domaines », c'est-à-dire que toutes les étapes de la transaction inter-domaines réussissent complètement ou échouent complètement, sans succès ou échec partiels. Avec l'assurance de l'atomicité inter-domaines, le risque de perte d'actifs est atténué. Cela permet à Fiber de se connecter au réseau Bitcoin Lightning, permettant des paiements directs de Fiber aux utilisateurs du réseau BTC Lightning (le destinataire étant limité au BTC) et permettant des conversions de CKB.

Convertir des actifs B et RGB++ en Bitcoin équivalent au sein du réseau BTC Lightning.

Voici une explication simplifiée du processus : Supposons qu'Alice exploite un nœud dans le réseau Fiber, et que Bob exploite un nœud dans le réseau Bitcoin Lightning. Si Alice souhaite transférer de l'argent à Bob, elle peut le faire via un intermédiaire inter-domaines, Ingrid. Ingrid exécutera des nœuds à la fois dans les réseaux Fiber et BTC Lightning, agissant en tant qu'intermédiaire dans le chemin de paiement.

Si Bob veut recevoir 1 BTC, Alice peut négocier un taux de change avec Ingrid, fixant 1 CKB égal à 1 BTC. Ensuite, Alice enverrait 1,1 CKB à Ingrid dans le réseau Fiber, et Ingrid enverrait 1 BTC à Bob dans le réseau Bitcoin Lightning, en conservant 0,1 CKB en tant que frais.

Le processus implique l'établissement d'un chemin de paiement entre Alice, Ingrid et Bob, en utilisant HTLC. Bob doit fournir à Ingrid la clé R pour recevoir les fonds. Une fois qu'Ingrid a la clé R, elle peut débloquer les fonds qu'Alice a verrouillés dans le HTLC.

Les actions interdomaines entre le réseau Lightning BTC et Fiber sont atomiques, c'est-à-dire que les deux HTLC doivent être déverrouillés et le paiement interdomaine doit être exécuté avec succès, ou aucun des deux ne doit être déverrouillé et le paiement échoue. Cela garantit qu'Alice ne perd pas d'argent si Bob ne le reçoit pas.

Ingrid pourrait potentiellement ne pas déverrouiller l'HTLC d'Alice après avoir connaissance de la clé R, mais cela nuirait à Ingrid, pas à Alice. Par conséquent, la conception de Fiber garantit la sécurité des utilisateurs et ne nécessite aucune confiance envers des tiers, permettant ainsi des transferts entre différents réseaux P2P avec des modifications minimales.

Autres avantages de Fiber par rapport au réseau Lightning BTC

Plus tôt, nous avons mentionné que Fiber prend en charge les actifs natifs CKB et les actifs RGB++ (en particulier les stablecoins), ce qui lui confère un potentiel important pour les paiements en temps réel et le rend bien adapté aux petites transactions quotidiennes.

En revanche, un problème majeur avec le réseau Lightning de Bitcoin est la gestion de la liquidité. Comme nous l'avons discuté au début, le solde total dans un canal de paiement est fixe. Si le solde d'une partie est épuisé, elle ne peut pas transférer de fonds à l'autre partie à moins que l'autre partie n'envoie de l'argent en premier. Cela nécessite le rechargement des fonds ou l'ouverture d'un nouveau canal.

De plus, dans un réseau multi-sauts complexe, si certains nœuds intermédiaires ont un solde insuffisant et ne peuvent pas transmettre les paiements, cela peut entraîner l'échec de l'ensemble du chemin de paiement. Il s'agit là d'un des points douloureux du Lightning Network. La solution typique consiste à fournir des mécanismes efficaces d'injection de liquidités pour garantir que la plupart des nœuds peuvent injecter des fonds au besoin.

Cependant, dans le réseau Lightning Bitcoin, l'injection de liquidités, ainsi que l'ouverture ou la fermeture de canaux, se produit sur la blockchain Bitcoin. Si les frais du réseau Bitcoin sont très élevés, cela a un impact négatif sur l'expérience utilisateur des canaux de paiement. Par exemple, si vous souhaitez ouvrir un canal d'une capacité de 100 $ mais que les frais de configuration sont de 10 $, cela signifie que 10 % de vos fonds sont consommés uniquement pour mettre en place le canal, ce qui est inacceptable pour la plupart des utilisateurs. Le même problème s'applique à l'injection de liquidités.

En revanche, Fiber offre des avantages significatifs. Tout d'abord, le TPS (transactions par seconde) de CKB est beaucoup plus élevé que celui de Bitcoin, avec des frais atteignant des coûts de l'ordre du centime. Deuxièmement, pour résoudre le problème des pénuries de liquidités et garantir des transactions fluides, Fiber prévoit de collaborer avec Mercury Layer pour introduire de nouvelles solutions qui éliminent le besoin d'opérations on-chain pour l'injection de liquidités, résolvant ainsi les problèmes d'UX et de coûts.

Nous avons maintenant systématiquement présenté l'architecture technique globale de Fiber, avec un résumé le comparant au réseau Bitcoin Lightning, comme le montre l'image ci-dessus. Étant donné la complexité et l'étendue des sujets couverts par Fiber et le réseau Lightning, un seul article ne peut pas aborder tous les aspects. Nous publierons à l'avenir une série d'articles axés sur différents aspects du réseau Lightning et de Fiber. Restez à l'écoute pour plus de mises à jour.

Avertissement：

1. Cet article est repris de [Gate.io]Geek web3]. Transférer le titre original 'Interprétation du système Fiber: une grande expérience pour greffer le réseau Lightning sur CKB'. Tous les droits d’auteur appartiennent à l’auteur original [Faust & Nickqiao, web3 geek]. S'il y a des objections à cette reproduction, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité: Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.