Analyse systématique de Fiber : une vaste expérimentation visant à greffer le réseau Lightning sur CKB
TechFlow SélectionTechFlow Sélection
Analyse systématique de Fiber : une vaste expérimentation visant à greffer le réseau Lightning sur CKB
Ceci est probablement l'analyse la plus systématique sur Fiber.
Dédié à des analyses Web3 approfondiesRédaction : Faust & Nickqiao, Geek Web3
Le 23 août, l'équipe officielle de CKB a publié Fiber Network (réseau en fibre optique), une solution de réseau Lightning basée sur CKB. Dès sa diffusion, cette nouvelle a rapidement suscité des discussions animées au sein de la communauté, provoquant une hausse de près de 30 % du prix du CKB en une seule journée. L'enthousiasme s'explique principalement par le fort potentiel narratif du réseau Lightning, et par le fait que Fiber apporte plusieurs améliorations significatives par rapport aux solutions traditionnelles de Lightning Network.
Par exemple, Fiber prend nativement en charge plusieurs types d'actifs comme le CKB, le BTC ou les stablecoins. De plus, les frais de transaction sur CKB sont bien inférieurs à ceux du BTC, avec des temps de réponse plus rapides, permettant ainsi à Fiber de réaliser des percées notables en matière d'expérience utilisateur (UX). En termes de confidentialité et de sécurité, Fiber a également introduit de nombreuses optimisations.
En outre, Fiber peut interagir avec le réseau Lightning du BTC, formant un vaste réseau pair-à-pair (P2P). Lors d'événements hors ligne, l'équipe CKB a même annoncé son intention de déployer 100 000 nœuds physiques dans les réseaux Fiber et Lightning afin de perfectionner et faire progresser le réseau P2P de paiement. Il s'agit sans aucun doute d'une vision extraordinairement ambitieuse.
Si la vision de l'équipe CKB venait à se concrétiser, ce serait une excellente nouvelle non seulement pour le réseau Lightning, mais aussi pour CKB et tout l'écosystème Bitcoin. D’après les données de mempool, plus de 300 millions de dollars ont déjà été alloués au réseau Lightning du BTC, avec environ 12 000 nœuds et près de 50 000 canaux de paiement établis entre eux.
Sur spendmybtc.com, on observe de plus en plus de commerçants acceptant les paiements via Lightning. Plus la reconnaissance du BTC s’étendra, plus l’élan des solutions de paiement hors chaîne telles que Lightning et Fiber ne cessera de croître.
Afin d'offrir une analyse systématique de la technologie sous-jacente à Fiber, Geek Web3 a rédigé ce rapport technique complet sur l'architecture globale de Fiber. Bien que le principe de fonctionnement de Fiber repose largement sur celui du Lightning Network du Bitcoin, il comporte de nombreuses optimisations techniques spécifiques.
L'architecture générale de Fiber comprend quatre composants clés : les canaux de paiement, le WatchTower (tour de surveillance), le routage multi-sauts, et les paiements inter-domaines. Commençons par expliquer le plus fondamental : « le canal de paiement ».
Le socle du réseau Lightning et de Fiber : les canaux de paiement
Un canal de paiement consiste essentiellement à déplacer les transferts et transactions hors chaîne, puis à soumettre l'état final à la blockchain pour « règlement » après une certaine période. Les transactions étant exécutées instantanément hors chaîne, elles peuvent échapper aux limitations de performance inhérentes aux blockchains principales comme BTC.
Supposons qu'Alice et Bob ouvrent conjointement un canal. Ils créent d'abord un compte multisignature sur chaîne et y déposent des fonds, par exemple 100 unités chacun, servant de solde initial dans le canal hors chaîne. Ils peuvent ensuite effectuer plusieurs transferts à l’intérieur du canal. À la fermeture du canal, le solde final est synchronisé sur la chaîne et distribué via le compte multisig — c’est ce qu’on appelle le « règlement ».
Par exemple, au départ, Alice et Bob ont chacun 100 unités. Ensuite, Alice transfère 50 unités à Bob, puis 10 unités supplémentaires, avant que Bob ne renvoie 30 unités à Alice. Le solde final devient alors : Alice — 70, Bob — 130. On constate facilement que la somme totale reste inchangée, comme illustré par les boules d’un boulier qui se déplacent d’un côté à l’autre.
Si l'un des deux quitte le canal, le solde actuel (Alice : 70 / Bob : 130) est envoyé sur chaîne, et les 200 unités du compte multisig sont distribuées selon les soldes respectifs, achevant ainsi le règlement. Ce processus semble simple, mais en pratique, de nombreux cas complexes doivent être pris en compte.
Tout d’abord, vous ne savez jamais quand l’autre partie décidera de quitter le canal. Dans l'exemple ci-dessus, Bob pourrait décider de sortir juste après la deuxième transaction, ou même après la première. Le canal ne l’interdit pas : chaque participant peut librement décider de partir. Pour cela, il faut supposer qu’à tout moment, l’un des deux pourrait soumettre le solde final à la chaîne pour clôturer le canal.
C’est pourquoi existe le concept de « transaction d’engagement » (commitment transaction). Chaque transaction d’engagement représente le dernier état des soldes entre les deux parties dans le canal. Une nouvelle transaction d’engagement est générée à chaque transfert. Si vous souhaitez quitter le canal, vous pouvez soumettre la dernière transaction d’engagement à la chaîne pour récupérer votre part depuis le compte multisig.
Retenons cette conclusion : les transactions d’engagement servent à régler les soldes sur chaîne. À tout moment, une partie peut soumettre la dernière transaction d’engagement pour clôturer le canal.
Mais un scénario malveillant important existe : Bob pourrait soumettre une ancienne transaction d’engagement périmée. Par exemple, après la création de Commit Tx3, le solde de Bob est de 130. Mais pour profiter, Bob soumettrait Commit Tx2 expirée, affirmant avoir un solde de 160, alors que cet état n’est plus à jour. C’est un cas typique de « double dépense ».
Pour éviter ces doubles dépenses, des mesures punitives sont nécessaires. La conception de ces sanctions constitue précisément le cœur du mécanisme du canal 1-à-1. Comprendre cela, c’est vraiment comprendre les canaux de paiement. Dans ce système, si une partie soumet un ancien état ou une ancienne transaction d’engagement, elle n’obtient pas gain de cause, mais voit plutôt ses fonds entièrement confisqués par l’autre partie.
Cela repose sur deux concepts cruciaux : les « transactions d’engagement asymétriques » et les « clés de révocation ». Expliquons d’abord les « transactions d’engagement asymétriques ». Reprenons l’exemple de Commit Tx3 ; voici un schéma illustratif :
Cette transaction d’engagement est construite par Bob, puis envoyée à Alice pour traitement. Comme montré, il s’agit d’une transaction Bitcoin indiquant que 70 unités vont à Alice et 130 à Bob, mais les conditions de déblocage sont « asymétriques » : Alice fait face à des contraintes plus strictes, tandis que Bob bénéficie d’un avantage.
Après réception de la transaction d’engagement construite par Bob, Alice peut ajouter sa signature pour satisfaire le multisig 2/2, puis soumettre activement cette « transaction d’engagement » sur chaîne, ce qui lui permet de quitter le canal. Si elle ne le fait pas, elle continue les transferts dans le canal.
Il faut noter que cette transaction est construite activement par Bob, avec des conditions désavantageuses pour Alice, qui ne peut que l’accepter ou la refuser. Il faut donc offrir à Alice un certain contrôle. Dans la conception du canal, seul Alice peut déclencher sur chaîne une transaction d’engagement désavantageuse pour elle-même, car celle-ci nécessite une signature multisig 2/2. Or, Bob, ayant construit localement la transaction, ne possède que sa propre signature, pas celle d’Alice.
Et Alice peut choisir de recevoir la signature de Bob, mais de ne pas lui envoyer la sienne — comme un contrat défavorable nécessitant deux signatures : l’autre signe d’abord et vous transmet le document, mais vous pouvez refuser de signer ou de divulguer votre signature. Vous activez le contrat si vous signez et publiez, sinon non. Clairement, dans ce cas, Alice peut contrôler Bob.
Vient maintenant l’élément central : chaque fois qu’un transfert a lieu dans le canal, une paire de transactions d’engagement est générée, deux versions symétriques l’une de l’autre, comme ci-dessous. Alice et Bob peuvent chacun construire une transaction d’engagement favorable à leur situation, y déclarer leur solde et montant à percevoir lors de la sortie, puis envoyer la transaction à l’autre pour traitement.
Curieusement, bien que les deux transactions d’engagement déclarent le même montant à percevoir à la sortie, leurs conditions de retrait diffèrent — d’où vient le terme « transaction d’engagement asymétrique » mentionné précédemment.
Nous avons vu que chaque transaction d’engagement nécessite une validation multisig 2/2 pour être effective. La transaction d’engagement construite localement par Bob, favorable à lui-même, ne remplit pas cette condition 2/2, tandis que celle satisfaisant à 2/2 est détenue par Alice. Bob ne peut donc pas la soumettre — seul Alice peut le faire, créant ainsi un équilibre. Le raisonnement inverse est similaire.
Ainsi, Alice et Bob ne peuvent que soumettre activement une transaction d’engagement désavantageuse pour eux-mêmes. Dès qu’un participant soumet une transaction d’engagement valide sur chaîne, le canal est fermé. Revenons au scénario initial de « double dépense » : que se passe-t-il si quelqu’un soumet une ancienne transaction d’engagement ?
C’est là qu’intervient la « clé de révocation ». Si Bob soumet une ancienne transaction d’engagement sur chaîne, Alice peut utiliser la clé de révocation pour retirer l’argent que Bob aurait dû obtenir.
Regardons l’image suivante : supposons que la dernière transaction d’engagement soit Commit Tx3, et que Commit Tx2 soit expirée. Si Bob soumet l’ancienne Tx2 sur chaîne, Alice peut utiliser la clé de révocation associée à Tx2 pour retirer les fonds de Bob (à condition d’agir dans le délai du verrouillage temporel).
Pour la dernière transaction Tx3, Alice ne dispose pas de la clé de révocation, qu’elle obtiendra uniquement lorsque Tx4 sera générée. Cela découle des propriétés de la cryptographie à clé publique/privée et du modèle UTXO. En raison de la longueur de cet article, nous n’entrerons pas dans les détails de l’implémentation de la clé de révocation.
Retenons la conclusion : si Bob ose soumettre une ancienne transaction d’engagement sur chaîne, Alice peut utiliser la clé de révocation pour s’emparer de ses fonds, comme sanction. Inversement, si Alice agit malicieusement, Bob peut faire de même. Ainsi, dans un canal 1-à-1, les doubles dépenses sont efficacement évitées tant que les participants sont rationnels.
Concernant les canaux de paiement, Fiber basé sur CKB apporte de grandes améliorations par rapport au Lightning Network du Bitcoin. Il prend nativement en charge plusieurs types d’actifs (CKB, BTC, stablecoins RGB++), alors que le Lightning Network ne supporte nativement que le Bitcoin. Même après le déploiement de Taproot Assets, le Lightning Network du Bitcoin ne pourra toujours pas supporter nativement d’autres actifs que le BTC, seulement indirectement les stablecoins.
Source image : Dapangdun
De plus, comme Fiber repose sur CKB comme couche 1, les coûts de création et de fermeture de canaux sont beaucoup plus faibles. Contrairement au Lightning Network du BTC, cela n’entame pas excessivement les frais utilisateurs, ce qui constitue un avantage manifeste en UX.
La sécurité permanente : le WatchTower (Tour de surveillance)
Il existe un problème avec les clés de révocation mentionnées plus haut : les participants doivent surveiller en permanence l’autre partie pour empêcher toute soumission clandestine d’une ancienne transaction d’engagement. Mais personne ne peut rester connecté 24 heures sur 24. Que faire si l’autre partie agit malicieusement pendant que vous êtes déconnecté ?
Pour cela, à la fois Fiber et le Lightning Network du Bitcoin intègrent un système de WatchTower, qui surveille continuellement l’activité sur chaîne au nom des utilisateurs. Dès qu’une ancienne transaction d’engagement est soumise, le WatchTower intervient immédiatement pour garantir la sécurité du canal et des fonds.
Voici comment cela fonctionne : pour chaque ancienne transaction d’engagement, Alice ou Bob peut préalablement construire une « transaction de punition » (utilisant la clé de révocation, avec bénéficiaire déclaré comme soi-même), puis envoyer le texte intégral de cette transaction au WatchTower. Dès que le WatchTower détecte la soumission d’une ancienne transaction d’engagement, il soumet immédiatement la transaction de punition pour appliquer la sanction.
Pour protéger la vie privée des participants, Fiber impose que l’utilisateur envoie uniquement le « hachage de l’ancienne transaction d’engagement + le texte intégral de la transaction de punition » au WatchTower. Ainsi, initialement, le WatchTower ne connaît pas le contenu de la transaction d’engagement, seulement son hachage. Seulement si une ancienne transaction est réellement soumise, le WatchTower voit le contenu, puis soumet aussitôt la transaction de punition. Par conséquent, sauf en cas de comportement malveillant, le WatchTower ne voit jamais l’historique des transactions des participants (et même s’il en voit, ce n’est que partiellement).
Précisons ici une amélioration de Fiber par rapport au Lightning Network du Bitcoin. Ce mécanisme de punition lié à la clé de révocation est appelé « LN-Penalty ». Or, le LN-Penalty du Lightning Network du Bitcoin présente un inconvénient majeur : le WatchTower doit stocker tous les hachages des anciennes transactions d’engagement et leurs clés de révocation correspondantes, ce qui crée une pression de stockage importante.
Dès 2018, la communauté Bitcoin a proposé une solution appelée « eltoo » pour résoudre ce problème, mais elle nécessite un fork pour activer l’opcode SIGHASH_ANYPREVOUT. L’idée est que, lorsque l’ancienne transaction d’engagement est publiée, la dernière transaction d’engagement puisse la remplacer et annuler son effet, permettant ainsi aux utilisateurs de ne conserver que la dernière. Cependant, l’opcode SIGHASH_ANYPREVOUT n’a toujours pas été activé, rendant cette solution inapplicable.
En revanche, Fiber implémente le protocole Daric, modifiant la conception de la clé de révocation pour qu’une même clé puisse s’appliquer à plusieurs anciennes transactions d’engagement. Cela réduit considérablement la pression de stockage sur le WatchTower et les clients utilisateurs.
Le système de transport du réseau : routage multi-sauts et HTLC/PTLC
Les canaux de paiement décrits précédemment s’appliquent uniquement aux échanges 1-à-1. Or, le réseau Lightning permet les paiements multi-sauts : en utilisant des nœuds intermédiaires comme relais, deux parties sans canal direct peuvent transférer des fonds. Par exemple, Alice et Ken n’ont pas de canal commun, mais Ken a un canal avec Bob, et Bob avec Alice. Bob peut alors servir d’intermédiaire entre Alice et Ken, permettant un transfert indirect. Le « routage multi-sauts » désigne précisément l’établissement d’un chemin de transfert via plusieurs intermédiaires.
Le routage multi-sauts améliore la flexibilité et la couverture du réseau. Toutefois, l’émetteur doit connaître l’état des nœuds publics et des canaux disponibles. Dans Fiber, tous les canaux publics et la structure du réseau sont entièrement accessibles. Chaque nœud peut accéder aux informations réseau des autres. Étant donné que l’état du réseau évolue constamment, Fiber utilise l’algorithme de Dijkstra pour trouver le chemin le plus court, minimisant ainsi le nombre d’intermédiaires, puis établit un chemin de transfert entre deux parties.
Cependant, un problème de confiance des nœuds intermédiaires subsiste : comment garantir leur honnêteté ? Par exemple, si Alice veut transférer 100 unités à Ken via Bob, Bob pourrait retenir l’argent. Il faut donc empêcher les intermédiaires malveillants. C’est là que HTLC et PTLC entrent en jeu.
Supposons qu’Alice veuille payer 100 unités à Daniel, sans canal direct. Elle découvre qu’elle peut passer par deux intermédiaires, Bob et Carol. Un HTLC (Hashed Time-Locked Contract) est utilisé comme canal de paiement. Initialement, Alice envoie une demande à Daniel, qui lui renvoie un hachage r, mais Alice ignore la valeur originale R correspondante à r.
Ensuite, Alice crée dans son canal avec Bob une clause HTLC : elle paiera 102 unités à Bob, à condition que Bob fournisse la clé R dans les 30 minutes, sinon elle récupère les fonds. De même, Bob crée un HTLC avec Carol : il paiera 101 unités à Carol, si elle fournit R dans les 25 minutes, sinon il récupère l’argent.
Carol fait de même avec Daniel : elle paiera 100 unités, si Daniel lui donne R dans les 20 minutes, sinon elle récupère les fonds.
Daniel comprend que la clé R demandée par Carol est exactement celle qu’Alice cherche, car personne d’autre qu’Alice ne s’intéresserait à R. Il coopère donc avec Carol, lui donne R et reçoit 100 unités. Alice atteint ainsi son objectif : transférer 100 unités à Daniel.
Ensuite, Carol transmet R à Bob et reçoit 101 unités ; Bob transmet R à Alice et reçoit 102 unités. En examinant les gains et pertes, on voit qu’Alice perd 102 unités, Bob et Carol gagnent chacun 1 unité, Daniel reçoit 100 unités. Ces 1 unité gagnées par Bob et Carol représentent les frais de service prélevés sur Alice.
Même si un intermédiaire bloque le processus — par exemple, si Carol ne transmet pas R à Bob — Bob ne subit aucune perte : passé le délai, il peut annuler l’HTLC. Même logique pour Alice.
Mais le réseau Lightning a un problème : les chemins ne doivent pas être trop longs. Plus le chemin est long, plus il y a d’intermédiaires, ce qui diminue la fiabilité du paiement : certains intermédiaires peuvent être hors ligne, ou n’avoir pas assez de fonds pour créer un HTLC spécifique (par exemple, chaque intermédiaire doit disposer d’au moins 100+ unités). Chaque nœud ajouté augmente donc la probabilité d’échec.
De plus, HTLC peut compromettre la confidentialité. Bien que le routage en oignon (onion routing) protège partiellement la vie privée — en chiffrant chaque étape du routage, chaque participant ne connaît que ses voisins immédiats, pas le chemin complet — HTLC reste vulnérable à l’inférence de corrélation. Prenons une vue omnisciente du chemin suivant :
Supposons que Bob et Daniel soient deux nœuds contrôlés par la même entité, recevant quotidiennement de nombreux HTLC. Ils remarquent que chaque fois qu’Alice et Carol envoient un HTLC, la clé demandée est toujours identique, et que Eve, connectée à Daniel, connaît toujours R. Ainsi, Daniel et Bob peuvent deviner qu’un chemin de paiement existe entre Alice et Eve, car ils sont constamment liés à la même clé, permettant d’inférer la relation entre Alice et Eve et de la surveiller.
Pour cela, Fiber adopte PTLC (Point Time-Locked Contract), une amélioration de HTLC en matière de confidentialité. Chaque PTLC dans le chemin utilise une clé différente, rendant impossible l’identification de corrélations par simple observation. En combinant 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 vulnérable à une attaque appelée « replacement cycling attack », pouvant entraîner le vol des actifs des intermédiaires. Cette découverte a même conduit le développeur Antoine Riard à quitter le développement du Lightning Network. À ce jour, aucune solution fondamentale n’a été mise en œuvre dans le Lightning Network du Bitcoin, ce qui en fait un point sensible.
Actuellement, l’équipe CKB a modifié le niveau du pool de transactions, permettant à Fiber de résoudre ce type d’attaque. Étant donné que l’attaque « replacement cycling » et sa solution sont très complexes, nous ne développerons pas davantage ici. Les lecteurs intéressés peuvent consulter les articles de BTCStudy ou les documents officiels de CKB.
En résumé, que ce soit en termes de confidentialité ou de sécurité, Fiber apporte des améliorations substantielles par rapport au réseau Lightning traditionnel.
Paiements atomiques inter-domaines entre Fiber et le réseau Lightning du Bitcoin
Grâce à HTLC et PTLC, Fiber peut réaliser des paiements inter-domaines avec le réseau Lightning du Bitcoin, tout en garantissant l’« atomicité inter-domaines » : toutes les étapes liées au transfert doivent réussir ensemble ou échouer ensemble, sans résultat partiel.
Une fois l’atomicité garantie, le risque de perte de fonds lors des transferts inter-domaines est éliminé. Cela permet à Fiber et au réseau Lightning du Bitcoin de s’interconnecter : par exemple, créer un chemin de paiement dans un réseau hybride, transférer directement depuis Fiber vers un utilisateur du Lightning Network du BTC (destinataire limité au BTC), ou encore échanger des actifs CKB et RGB++ sur Fiber contre des bitcoins équivalents sur le réseau Lightning du BTC.
Expliquons brièvement le principe : supposons qu’Alice exécute un nœud dans Fiber, et Bob un nœud dans le réseau Lightning du BTC. Alice souhaite transférer de l’argent à Bob. Elle peut utiliser un prestataire de transit inter-domaines, Ingrid, pour effectuer ce transfert. Ingrid exécute des nœuds à la fois dans Fiber et dans le réseau Lightning du BTC, servant d’intermédiaire.
Si Bob souhaite recevoir 1 BTC, Alice et Ingrid conviennent d’un taux d’échange (1 CKB = 1 BTC). Alice envoie 1,1 CKB à Ingrid via Fiber, puis Ingrid envoie 1 BTC à Bob via le réseau Lightning du BTC, gardant 0,1 CKB comme frais.
Concrètement, cela revient à établir un chemin de paiement entre Alice, Ingrid et Bob (Alice → Ingrid → Bob), en utilisant HTLC. Comme expliqué précédemment, pour recevoir l’argent, Bob doit fournir la clé R à Ingrid. Une fois qu’Ingrid obtient R, elle peut déverrouiller les fonds bloqués par Alice dans l’HTLC.
Important : les deux opérations inter-domaines, dans le réseau Lightning du BTC et dans Fiber, sont atomiques. Soit les deux HTLC sont débloqués et le paiement réussi, soit aucun n’est débloqué et le paiement échoue. Impossible qu’Alice paie sans que Bob reçoive.
(Techniquement, Ingrid pourrait, après avoir obtenu R, ne pas débloquer l’HTLC d’Alice — mais dans ce cas, c’est Ingrid qui subit la perte, pas l’utilisateur Alice. Ainsi, le design de Fiber protège l’utilisateur.)
Cette méthode permet des transferts entre différents réseaux P2P sans confiance en tiers, presque sans modification nécessaire.
Autres avantages de Fiber par rapport au réseau Lightning du BTC
Comme mentionné précédemment, Fiber prend en charge nativement les actifs CKB et les actifs RGB++ (notamment les stablecoins), ce qui lui confère un énorme potentiel dans les scénarios de paiement instantané, particulièrement adapté aux petits paiements quotidiens.
En outre, le réseau Lightning du Bitcoin souffre d’un problème majeur : la gestion de la liquidité. Rappelez-vous que le solde total dans un canal est fixe. Si l’un des deux participants épuise son solde, il ne peut plus transférer à l’autre, sauf si l’autre lui envoie d’abord des fonds. Il faut alors réinjecter des fonds ou ouvrir un nouveau canal.
De plus, dans un réseau multi-sauts complexe, si un nœud intermédiaire manque de liquidité, il peut empêcher tout le chemin de paiement de fonctionner. C’est l’un des points faibles du Lightning Network. Les solutions consistent à proposer des méthodes efficaces d’injection de liquidité pour que la majorité des nœuds puissent injecter des fonds à tout moment.
Cependant, dans le Lightning Network du BTC, l’injection de liquidité, l’ouverture ou la fermeture de canaux se font sur la chaîne BTC. Si les frais du réseau BTC sont très élevés, cela nuit gravement à l’expérience utilisateur (UX). Imaginons vouloir ouvrir un canal de 100 dollars, mais que l’opération coûte 10 dollars de frais — cela grignote dès le départ 10 % de vos fonds, ce que la plupart des gens ne peuvent accepter. Même chose pour l’injection de liquidité.
Face à cela, Fiber dispose d’un avantage marqué. D’abord, le TPS de CKB est bien supérieur à celui du BTC, et les frais peuvent descendre au niveau du centime. Ensuite, pour résoudre le problème de transferts impossibles faute de liquidité, Fiber prévoit de collaborer avec Mercury Layer pour proposer une nouvelle solution, permettant d’effectuer l’injection de liquidité hors chaîne, résolvant ainsi les problèmes d’UX et de coût.
Jusqu’ici, nous avons passé en revue de manière systématique l’architecture technique globale de Fiber. La comparaison synthétique entre Fiber et le réseau Lightning du Bitcoin est résumée dans l’image ci-dessus. Étant donné la complexité et la richesse des sujets liés à Lightning et Fiber, un seul article ne peut tout couvrir. Nous publierons prochainement une série d’articles approfondis sur le réseau Lightning et Fiber. Restez à l’écoute.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
