L'art de la liquidité : quel type de réseau de scaling hors chaîne pour le bitcoin avons-nous besoin ?
TechFlow SélectionTechFlow Sélection
L'art de la liquidité : quel type de réseau de scaling hors chaîne pour le bitcoin avons-nous besoin ?
Cet article explore l'évolution des réseaux de canaux et leurs tendances futures du point de vue de l'extension de la liquidité.
Dédié à des analyses Web3 approfondiesAuteur :Ben，fondateur de Discoco Labs
Préambule
Pendant longtemps, je me suis posé une question : quelle est la logique fondamentale du scaling natif sur Bitcoin ?
En approfondissant l'étude du réseau Lightning et en tentant d’y mettre en œuvre des services non détenus (non-custodial), nous avons ressenti un certain malaise. Bien que les canaux bilatéraux théoriquement offrent un débit transactionnel maximal, leurs problèmes pratiques de maintenance et d'utilisation sont bien plus nombreux que prévu. Le réseau Lightning n’a pas atteint ses objectifs initiaux dans le domaine des micro-paiements, principalement à cause de la liquidité. Même si de nombreuses infrastructures censées améliorer la liquidité ont été introduites, leurs effets concrets restent en deçà des attentes.
Au moment où cet article était rédigé, Mutiny Wallet, un portefeuille autogéré emblématique du réseau Lightning, a annoncé sa fermeture, suivie par son fournisseur de service de liquidité (LSP). La collaboration entre portefeuilles autogérés et LSP était considérée comme une direction clé pour l'avenir du réseau Lightning, ce qui ravive inévitablement les inquiétudes quant à son avenir. À ce stade, cet article explore, sous l’angle de l’extension de la liquidité, l’évolution du réseau de canaux et ses tendances futures.
1. Quels sont les problèmes actuels du réseau Lightning ?
La capacité limitée des blocs Bitcoin et leur temps de génération relativement long — environ 10 minutes en moyenne — s'écarte fortement de l'exigence d’un système monétaire peer-to-peer mondial. Face à cela, nous avons besoin d’une solution de scaling efficace : elle doit occuper peu d’espace dans les blocs, permettre un règlement rapide, et être nativement basée sur Bitcoin. C’est ainsi que le réseau Lightning est né.
Le réseau Lightning consiste à verrouiller des actifs sur la chaîne, puis à échanger hors chaîne une transaction dite « transaction d’engagement », ce qui est considéré comme une transaction terminée — d'où son affirmation de paiement instantané. Comparé au délai de confirmation de 10 minutes sur la chaîne principale de Bitcoin, cette expérience résout efficacement le principal frein aux paiements mineurs.
Cependant, plusieurs problèmes sont apparus progressivement dans le développement et l’utilisation pratique du réseau Lightning. Nous en résumons quatre points essentiels :
1.1 Difficulté élevée de maintenance des nœuds
Actuellement, le réseau Lightning repose sur un modèle de jeu P2P utilisant des transactions punitives. Pour surveiller en permanence si l’autre partie ne publie pas une ancienne version défavorable de l’état du canal, le modèle exige qu’un WatchTower soit constamment en ligne, ce qui oblige l’utilisateur à maintenir lui-même son nœud. De plus, il faut stocker localement la clé privée de pénalité et les données des transactions d’engagement, ce qui rend la barrière technique et le coût éducatif très élevés.
1.2 Interactivité forte
Dans le réseau Lightning, l’interactivité désigne généralement les opérations interactives requises pendant une transaction, notamment la signature, l’échange de transactions d’engagement ou de clés privées de pénalité. Par exemple, chaque mise à jour de l’état hors chaîne nécessite que les deux parties soient simultanément en ligne et signent une nouvelle transaction d’engagement. Cette exigence est très contraignante. En outre, la complexité induite par les HTLC et les routages multi-sauts reste difficile à surmonter.
1.3 Faible efficacité du capital
Mécanisme LN-Penalty des canaux bilatéraux revient, dans une certaine mesure, à ce que chaque utilisateur crée son propre compte bancaire tout en apportant ses propres réserves. Un problème typique est que même pour recevoir des fonds, l’utilisateur doit disposer de liquidité dans le canal, ce qui entraîne une faible efficacité du capital. De plus, la liquidité des canaux périphériques est rarement pleinement exploitée.
1.4 Coût élevé de gestion des canaux
Dans les canaux P2P, les déséquilibres de liquidité surviennent fréquemment. Les utilisateurs doivent donc recourir à divers outils pour ajuster la liquidité, tels que les swaps submersibles (submarine swaps) ou le collage de canaux (channel splicing). Mais ces techniques nécessitent des transactions supplémentaires sur la chaîne principale pour modifier la transaction de financement initiale (FundingTx). Globalement, tous ces ajustements sont coûteux, particulièrement lorsque les frais de transaction augmentent, un coût que les utilisateurs ne peuvent ignorer.
Imaginez la situation embarrassante pour un utilisateur qui pense effectuer des transactions bon marché via une technologie de couche 2, mais se retrouve soudain confronté à plusieurs frais de transaction sur la chaîne principale. Ce malaise devient encore plus flagrant lorsque les frais sur chaîne augmentent — véritablement un « tueur aux frais ».
Tous ces problèmes se traduisent clairement par une adoption limitée : croissance faible des utilisateurs, dont la majorité optent pour des solutions gérées (custodiales), comme le montre clairement le graphique ci-dessous.
Statistiques comparatives du nombre d'utilisateurs nouveaux du réseau Lightning choisissant des solutions de portefeuille gérées versus non gérées
On comprend aisément pourquoi : pour la plupart des utilisateurs ordinaires, maintenir eux-mêmes un nœud et un canal est trop difficile.
2. Quel type de réseau de scaling hors chaîne pour Bitcoin souhaitons-nous ?
Extrait du livre blanc du réseau Lightning
Selon le livre blanc du réseau Lightning, si chaque personne sur Terre ouvrait et fermait deux canaux par an, la taille nécessaire des blocs Bitcoin atteindrait 133 Mo. Comparé à la taille actuelle du bloc principal (1 Mo), voire 4 Mo avec SegWit et adresses P2TR, l’écart est immense. De plus, les ajustements de liquidité (swaps submersibles, collage de canaux) nécessitent des transactions supplémentaires sur chaîne, rendant le manque d’espace dans les blocs encore plus critique dans des scénarios réels.
Il apparaît donc que le réseau Lightning actuel peine à répondre aux besoins massifs des utilisateurs grand public à court terme. En outre, en raison de la limitation de la taille des blocs Bitcoin, son potentiel de scaling à long terme est sévèrement contraint.
La question se pose alors : quel type de réseau de scaling hors chaîne pour Bitcoin souhaitons-nous vraiment ?
2.1 État actuel du réseau Lightning
Pour comprendre les limites actuelles du réseau Lightning, revenons à ses principes de conception.
Le modèle actuel du réseau Lightning, appelé LN-Penalty, repose sur un modèle de canal bilatéral basé sur des transactions punitives. Sa sécurité dépend du stockage local de transactions contrebalançant l’adversaire, ainsi que de clés privées de pénalité, et exige une surveillance constante de la chaîne Bitcoin pour garder l’adversaire sous contrôle.
Dans ce modèle, l’exécution d’un nœud personnel est incontournable, car le stockage local et la fonction WatchTower sont indispensables — comme mentionné précédemment à plusieurs reprises.
Sur le plan de l’efficacité du capital et de la communication, le modèle dominant aujourd’hui consiste en un super-nœud LSP fournissant de la liquidité, tandis que les utilisateurs établissent des canaux avec ce super-nœud. Cela s’éloigne déjà du modèle maillé P2P initial. Dans son évolution naturelle, on retombe finalement sur un modèle classique hub-and-spoke.
L’illustration ci-dessous montre à gauche le réseau Lightning idéal, et à droite la réalité actuelle.
2.2 Caractéristiques d’un réseau de scaling hors chaîne idéal pour les consommateurs (toC)
Imaginons maintenant les caractéristiques qu’un réseau de scaling hors chaîne pour Bitcoin devrait posséder selon les besoins réels des utilisateurs finaux :
-
Un modèle non P2P, sans obligation pour l'utilisateur de maintenir un nœud, tout en assurant sécurité et simplicité d'utilisation
-
Lors d’un paiement, aucune connexion simultanée requise ; une opération asynchrone ou avec une partie hors ligne est possible
-
Amélioration de l'efficacité du capital, tout en respectant le principe non détenue (non-custodial)
-
Mécanisme de gestion de liquidité bon marché et efficace, voire sans intervention utilisateur
À partir de ces objectifs, cet article vous guidera vers les directions futures du scaling hors chaîne sur Bitcoin.
3. L’évolution du scaling natif sur BTC
Nous devons d’abord clarifier que le mécanisme central actuel du réseau Lightning, « LN-Penalty », repose sur deux éléments fondamentaux :
-
Stockage et surveillance continue des transactions d’engagement
-
Mécanismes multi-sauts impliquant plusieurs participants (HTLC/PTLC)
Ces éléments constituent la base du réseau Lightning actuel, et conduisent directement à une grande complexité dans la conception des nœuds :
-
Interactions cryptographiques complexes
-
Stockage local des transactions d’engagement et des clés privées de pénalité
-
WatchTower devant fonctionner sans interruption durant toute la durée du canal
Ces problèmes incitent à explorer des mécanismes de mise à jour d’état plus légers que « LN-Penalty ». Dans ce contexte, BIP118 (SIGHASH_ANYPREVOUT) apparaît comme une alternative potentielle.
3.1 LN-Symmetry : Introduire un mécanisme de versionnage dans la mise à jour d’état
BIP118 propose un mode de signature SIGHASH_ANYPREVOUT, permettant aux entrées d'une transaction de ne pas spécifier exactement la sortie précédente, et autorisant la mise à jour de la transaction précédente sans changer la signature. Contrairement à « LN-Penalty », cela réduit significativement la complexité des communications cryptographiques entre nœuds et les besoins de stockage. SIGHASH_ANYPREVOUT provient de l'article eltoo: A Simple Layer2 Protocol for Bitcoin. Récemment, dans les discussions autour du développement du réseau Lightning, le modèle amélioré basé sur cette proposition est appelé « LN-Symmetry ».
Bien que LN-Symmetry diminue la pression de stockage des transactions d’engagement locales, il n’élimine pas complètement la nécessité de surveillance. Même si Eltoo ne nécessite pas d’échanger transactions d’engagement ni signatures de clés privées, si un participant tente de publier un ancien état sur chaîne, l’autre partie doit toujours surveiller en temps réel et publier rapidement l’état le plus récent pour le remplacer. Cette tâche de surveillance nécessite toujours un WatchTower traditionnel, dont la fonction passe ici de punition à remplacement d’état. L’utilisateur doit toujours maintenir son propre nœud.
De plus, LN-Symmetry continue d’avoir besoin des mécanismes HTLC/PTLC pour garantir la collaboration entre plusieurs participants, conservant ainsi une charge de communication aussi lourde que celle du réseau Lightning actuel.
En résumé, l’amélioration apportée par LN-Symmetry au réseau Lightning actuel reste limitée. Il reste encore un long chemin avant d’atteindre nos objectifs.
Pour aller plus loin, nous introduisons maintenant la prochaine étape : Shared UTXO.
3.2 CoinPool : Réduire l’interactivité et les besoins en liquidité des canaux multipartenaires
Le premier article à introduire le concept de Shared UTXO est CoinPool: efficient off-chain payment pools for Bitcoin. Son objectif principal est de résoudre le problème d’interactivité multipartenaire dans le cadre du mécanisme de versionnage de SIGHASH_ANYPREVOUT.
Dans la conception LN-Symmetry, le nouveau mécanisme de mise à jour d’état d’Eltoo simplifie effectivement la gestion des canaux point-à-point. Toutefois, en cas de collaboration multipartenaire, la complexité intermédiaire persiste, surtout dans les paiements multi-sauts (HTLC/PTLC), nécessitant une coordination étroite et de multiples communications cryptographiques.
L’innovation de CoinPool réside dans l’utilisation du modèle Shared UTXO, permettant à plusieurs parties de collaborer sur un même UTXO doté d’un contrôle de version. Ainsi, plusieurs participants peuvent conjointement s’engager et gérer l’état d’un UTXO sans dépendre des mécanismes complexes HTLC/PTLC. Ses principaux avantages sont :
-
Réduction drastique de la complexité intermédiaire dans les canaux multipartaires : puisque tous les participants partagent le même UTXO, ils peuvent parvenir à un consensus simplement en signant la mise à jour de version de cet UTXO, sans avoir besoin de multiples transactions sur chaîne ou d’interactions complexes hors chaîne. Cela rend la gestion des canaux multipartaires beaucoup plus efficace.
-
Le mécanisme de mise à jour hors chaîne devient plus direct : les mises à jour d’état hors chaîne consistent désormais à signer collectivement une version donnée de l’UTXO. Cette méthode simplifie le processus, réduit les dépendances entre participants et les risques de conflits.
-
Élimination du besoin individuel en liquidité : grâce au modèle Shared UTXO, plusieurs participants partagent en réalité un même pool de liquidité, sans que chacun doive maintenir indépendamment une liquidité suffisante. Dans la conception CoinPool multipartenaire, les besoins en liquidité peuvent être fortement réduits ou redistribués. Les participants peuvent utiliser la liquidité du Shared UTXO pour effectuer des paiements, sans bloquer de gros montants dans leurs propres canaux. Cela améliore l’efficacité du capital et allège la pression financière individuelle.
CoinPool réussit, via le modèle Shared UTXO, à ramener la complexité intermédiaire des canaux multipartaires à un niveau acceptable, tout en préservant sécurité et efficacité. Plus important encore, il réduit la dépendance aux liquidités individuelles, offrant une solution plus légère et flexible pour la collaboration multipartenaire, dépassant ainsi les limitations du modèle LN traditionnel en matière d’interactivité et de gestion de liquidité.
Cependant, pourquoi une solution aussi avantageuse n’a-t-elle pas encore été largement adoptée ? Où se situe le problème ?
3.3 Pourquoi CoinPool n’a-t-il pas été concrètement mis en œuvre ?
Bien que CoinPool présente de nombreux avantages et soit vu comme un modèle idéal de scaling, il dépend de trop nombreuses mises à jour par soft fork, au point que sa mise en œuvre sur le réseau Bitcoin pourrait ne jamais arriver de notre vivant. Ces besoins portent principalement sur deux aspects :
3.3.1 Mise à jour du mécanisme d’état
Puisque CoinPool s’appuie sur Eltoo, il hérite du besoin de mise à jour du mécanisme d’état, notamment l’activation d’un nouveau mode de signature SIGHASH_ANYPREVOUT (APO). Or, comme chacun le sait, les mises à jour par soft fork sur Bitcoin progressent lentement, rendant impossible l’application concrète de cette technologie.
3.3.2 Besoin d’un mécanisme simplifié pour opérer sur Shared UTXO
Comme mentionné, chaque mise à jour d’état de Shared UTXO nécessite de recueillir les signatures de tous les participants partageant cette version. Si un participant se déconnecte, tout le système s’arrête — autrement dit, la « vivacité » (liveness) du système est mauvaise. Pour résoudre cela, il faut un mécanisme peu coûteux et non entièrement dépendant de la coopération pour mettre à jour Shared UTXO.
L’article CoinPool propose OP_MERKLESUB, utilisant une structure d’arbre de Merkle pour valider et mettre à jour l’état d’un participant spécifique. Bien que viable en théorie, ce type de contrat intelligent souffre de complexité logique et de difficulté à être générique et réutilisable — comme les contrats similaires **OP_TAPLEAFUPDATEVERIFY (TLUV)**. Des fonctions comme OP_EVICT, qui expulsent directement un participant non coopératif, sont trop spécifiques pour espérer passer une mise à jour du réseau Bitcoin.
Parmi ces propositions, OP_CheckTemplateVerify (CTV) attire de plus en plus l’attention. Contrairement à la construction d’un arbre de Merkle, CTV limite les dépenses via un modèle de transaction prédéfini. Non seulement simple à implémenter, CTV peut également lier une série d’UTXO hors chaîne à un seul UTXO sur chaîne via une chaîne d’engagements. Ces UTXO hors chaîne engagés sur chaîne sont à l’origine du concept de Virtual UTXO.
CTV suscite un fort engouement car il est à la fois simple et universel. Sa puissance permet non seulement des idées comme CoinPool, mais aussi des applications telles que les Rollups. On peut imaginer vérifier un ZKP-MerkleState via OP_CAT, puis engager directement l’état correspondant de la couche 2 dans le script via un Shared UTXO, construisant ainsi un véritable schéma de ZK-Rollup sur Bitcoin.
En résumé, l’implémentation de CoinPool bute principalement sur le besoin de deux composants : un mécanisme léger de mise à jour d’état (APO) et des opcodes pour manipuler Shared UTXO — tous deux nécessitant un soft fork sur Bitcoin. Ainsi, malgré sa publication il y a plusieurs années, CoinPool reste une solution théorique.
3.4 Bitcoin Clique : Primitif hors chaîne anti-double-dépense 2-AS
Dans la discussion précédente sur CoinPool, nous avons vu que son mécanisme APO nécessite un soft fork, irréalisable à court terme. Alors, si un nouveau primitif hors chaîne empêchant le double-dépense, sans dépendre d’un soft fork, existait, le problème serait grandement atténué. L’article Bitcoin Clique apporte un nouvel espoir. Il introduit un nouveau primitif cryptographique, la 2-shot-adaptor-signature (2-AS), offrant une nouvelle solution anti-double-dépense hors chaîne.
2-AS est un primitif basé sur la signature adaptateur Schnorr. Pour comprendre 2-AS, commençons par les bases de la signature Schnorr et des signatures adaptateurs.
3.4.1 Signature Schnorr
La signature Schnorr a une propriété de linéarité : plusieurs signatures peuvent être agrégées en une seule. Par exemple, deux signatures $S_1$ et $S_2$ peuvent être additionnées en $S = S_1 + S_2$, et les clés publiques correspondantes en $P = P_1 + P_2$.
3.4.2 Signature adaptateur
La signature adaptateur comporte plusieurs étapes : Gen, PSign, PVrfy, Adapt, Extract. Pour comprendre 2-AS, concentrons-nous sur PSign et Extract.
Ici, nous abordons la signature adaptateur par son usage plutôt que par sa cryptographie. En résumé, quand deux parties collaborent pour confirmer une signature, l’une utilise un « adaptateur » (souvent une clé publique) comme partie de la signature. Celui qui détient la clé privée associée (le secret) peut alors compléter la signature partielle (PSign) via « Adapt ». Cela ressemble-t-il à MuSig ? La particularité réside dans « Extract » : lorsque la signature complète est révélée, celui qui a lancé PSign peut extraire le secret (clé privée) à partir de la signature complète, de la signature partielle et de l’adaptateur (clé publique).
3.4.3 Combinaison : 2-AS
Maintenant que nous connaissons Schnorr et les signatures adaptateurs, voyons la magie de leur combinaison : 2-AS.
Supposons un VTXO, et que nous voulions garantir son impossibilité de double-dépense hors chaîne. Voici comment procéder :
-
Créer d’abord une sortie punitive, déverrouillable via une clé publique de pénalité, permettant de sanctionner l’utilisateur en cas de double-dépense.
-
Les contreparties collaborent via une signature adaptateur pour confirmer la transaction hors chaîne. Si l’utilisateur utilise deux fois la même entrée, le service provider peut confisquer les fonds.
-
À chaque mise à jour d’état, l’utilisateur doit générer une clé publique comme sortie punitive, dont la clé publique est formée par l’addition de deux paires de clés préétablies via la signature Schnorr.
Ainsi, avant chaque transaction, les clés publiques/privées sont préétablies, et la sortie punitive générée à l’avance. En cas de double-dépense, le service provider récupère la clé privée de la sortie punitive via les deux signatures adaptateurs.
3.4.4 Avantages et inconvénients de Bitcoin Clique
Bitcoin Clique n’est pas parfait. Un inconvénient majeur est la nécessité d’échanger continuellement les clés 2-AS pour construire la nouvelle clé publique punitive lors des mises à jour hors chaîne. De plus, ce schéma, basé sur CoinPool, exige que toutes les parties soient en ligne pour échanger les clés 2-AS et signer la nouvelle version de l’UTXO. La complexité et l’interactivité des communications restent donc élevées.
Plus important encore, ce modèle ressemble à StateChain : à chaque transfert hors chaîne, c’est la propriété d’un UTXO qui est transférée. Les systèmes utilisant des signatures anti-double-dépense comme 2-AS ne permettent pas de rendre la monnaie hors chaîne, limitant fortement les cas d’usage.
De plus, même avec un mécanisme SharedUTXO facile à manipuler et un primitif anti-double-dépense sans soft fork, tous les participants doivent être en ligne pour mettre à jour l’état. Exiger que des personnes non concernées soient en ligne pour une mise à jour est irrationnel. Éliminer totalement le besoin de liquidité n’est pas non plus souhaitable : sans liquidité, pas de monnaie rendue, et tous les montants doivent être identiques à cause du problème de sortie.
Ainsi, il n’existe actuellement aucun schéma de scaling hors chaîne basé sur UTXO, non canal, supportant des montants dynamiques. Ethereum a connu des difficultés similaires, connues sous le nom de « piège Plasma ». Voir l’article *Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma*.
Synthèse des leçons :
-
Besoin de liquidité pour des paiements à montants dynamiques (avec monnaie rendue) : il faut conserver la conception de canal, évitant aussi le problème de sortie.
-
Réduire la dépendance à la présence simultanée de tous les participants : nous ne voulons pas que chaque utilisateur soit en ligne à chaque mise à jour. La mise à jour de Shared UTXO ne devrait concerner que les parties impliquées.
Fort de ces constatations, poursuivons vers des solutions plus optimisées.
3.5 Usines de canaux et canaux virtuels
Dans les sections précédentes, nous avons compris qu’il fallait à la fois conserver la conception de canal et bénéficier des gains hors chaîne à faible coût offerts par Shared UTXO. Un concept longuement discuté dans le domaine du réseau Lightning entre alors en jeu : l’usine de canaux (Channel Factory).
Nous avons mentionné que les UTXO hors chaîne engagés par un UTXO sur chaîne sont appelés Virtual UTXO. Si l’on utilise un Virtual UTXO comme FundingTx d’un canal, on obtient un nouveau concept : le canal virtuel (Virtual Channel). Dans ce Shared UTXO, les canaux virtuels sont reliés par des Virtual HTLC. Tout devient hors chaîne, entièrement « virtualisé ». Cela semble une solution idéale : réaliser la plupart des fonctions hors chaîne, y compris l’ajustement de liquidité. Le scaling du réseau Lightning semblerait alors résolu.
Mais est-ce vraiment si beau ?
En raison de ses caractéristiques héritées de Shared UTXO, l’usine de canaux nécessite une collaboration multipartite pour ouvrir et fermer les canaux. Si un utilisateur ne peut pas coopérer à temps (déconnecté ou non-réactif), cela peut bloquer toute l’usine. Comme les mises à jour d’état nécessitent des signatures multipartites, toute absence ou comportement malveillant d’un participant peut empêcher les autres de fermer le canal et retirer leurs fonds.
En outre, ce design a un défaut évident : bien qu’il réduise le coût d’ouverture/fermeture de canaux, la sécurité entre canaux repose encore sur les transactions d’engagement et les HTLC. Les problèmes d’intercommunication persistent, et la complexité de mise en œuvre est même supérieure à celle du LN-Penalty actuel.
3.6 ARK JoinPool et canaux temporaires
À partir de l’exemple précédent de l’usine de canaux, nous tirons une conclusion : dans une conception de canal basée sur Shared UTXO, il ne faut probablement pas conserver le modèle classique « LN-Penalty », mais il faut garder les avantages des canaux :
-
Montants dynamiques grâce à la liquidité ;
-
Sortie facile.
À partir de là, une conception innovante de canaux temporaires utilisant JoinPool émerge : le protocole ARK.
3.6.1 JoinPool : Seules les personnes concernées participent à la mise à jour
Comme indiqué précédemment, CoinPool offre un potentiel énorme pour le scaling hors chaîne multipartenaire, en supprimant la nécessité de liquidité, de multi-sauts ou de HTLC complexes et fragiles. Mais le problème majeur de CoinPool est la disponibilité requise : tous les utilisateurs du Shared UTXO doivent être en ligne pour chaque mise à jour d’état, même ceux dont l’état n’a pas changé. Cela rend inévitable le maintien d’un nœud personnel.
Pour résoudre ce problème, un nouveau modèle est proposé : JoinPool. L’idée centrale de JoinPool est que, lorsqu’un utilisateur veut mettre à jour son état hors chaîne, seuls les participants concernés rejoignent ensemble un nouveau Shared UTXO représentant cet état. Ainsi, les utilisateurs non concernés n’ont pas besoin d’être en ligne. Dans JoinPool, l’utilisateur n’a besoin d’être en ligne que lorsqu’il fait une transaction.
Mais nous savons que le fonctionnement continu du nœud Lightning sert non seulement à garder la clé privée en ligne pour signer, mais aussi à ce que chaque membre du canal surveille via un WatchTower si l’adversaire publie une transaction d’engagement défavorable. Cela nous amène au deuxième problème à résoudre.
3.6.2 Transfert du rôle du WatchTower : l’utilisateur n’a plus besoin de maintenir son nœud
Dans le modèle classique LN-Penalty, chaque utilisateur construit son propre WatchTower pour surveiller et punir la publication d’un ancien état. Dans ce modèle, tous les participants sont des nœuds Lightning pairs. Chaque transaction peut impliquer un canal avec un nœud différent. Mais dans ARK, tous les utilisateurs interagissent avec un ASP (ARK Service Provider), jamais directement entre eux.
Pour l’ASP, dès qu’un VTXO est transmis hors chaîne, l’utilisateur signe une transaction de renonciation. Idéalement, le VTXO hors chaîne ne sera jamais publié sur chaîne, mais réutilisé indéfiniment. Si un VTXO est utilisé hors chaîne et publié sur chaîne, cela constitue un double-dépense, et l’ASP confisque les fonds via la transaction de renonciation signée hors chaîne. L’ASP surveille tous les VTXO historiques pour empêcher des retraits malveillants depuis des VTXO déjà dépensés hors chaîne.
Cela transfère la responsabilité du WatchTower des utilisateurs ordinaires à l’opérateur. Comparé au réseau Lightning, c’est une avancée majeure : enfin, les utilisateurs n’ont plus besoin de faire fonctionner leur propre nœud pour assurer leur sécurité.
Récapitulatif d’autres solutions visant à simplifier le fonctionnement du nœud utilisateur :
-
Hébergement cloud des nœuds Lightning
Certaines solutions hébergent les nœuds Lightning sur le cloud pour réduire la barrière d’entrée. Mais cela va à l’encontre de l’hypothèse de sécurité du réseau Lightning. Dans ce contexte, le stockage des clés privées et des transactions d’engagement est crucial. Utiliser une clé distante ne garantit pas la sécurité.
En réalité, cela transforme un jeu bilatéral en un jeu ternaire impliquant moi, mon adversaire et le prestataire cloud. Après une transaction, si l’état n’est pas encore sur chaîne, le prestataire peut supprimer la transaction d’engagement dans mon nœud cloud, permettant à mon adversaire de publier un état favorable. Il existe donc un risque de collusion entre le prestataire cloud et l’adversaire.
-
CRAB et Sleepy CRAB
Le protocole CRAB (Channel Resistant Against Bribery) proposé par Aumayr et al. utilise un mécanisme de dépôt combiné à des incitations aux mineurs pour sécuriser les canaux de paiement, notamment en cas de déconnexion. Cela réduit la dépendance aux WatchTowers tiers. Toutefois, ce mécanisme aggrave le problème de « liquidité entrante », car l’utilisateur doit bloquer davantage de fonds non liés à la transaction. Bien que cela assure la sécurité, cela nuit à la fluidité et à l’efficacité du capital. De plus, ces solutions exigent toujours que l’utilisateur fasse fonctionner son nœud, même si la disponibilité en ligne est moins stricte.
3.6.3 Canaux temporaires : l’utilisateur n’a plus besoin de gérer la liquidité du canal
On peut se demander pourquoi le fournisseur ASP injecterait de la liquidité dans les canaux JoinPool ? Parce que pour utiliser un VTXO sur le réseau ARK, l’utilisateur doit d’abord déposer son UTXO avec l’opérateur dans une adresse multisignature, similaire à une FundingTx, en échange d’un VTXO. En réalité, chaque transaction hors chaîne utilise les fonds de l’opérateur, mais l’utilisateur cède ses fonds bloqués en multisig avec l’opérateur.
Le canal ARK est qualifié de « temporaire » car il présente deux caractéristiques : unicité et unidirectionnalité.
-
Unidirectionnalité : dans un canal unidirectionnel, les fonds ne circulent que d’un initiateur prédéfini vers un destinataire.
-
Financement unique : le canal ARK ne nécessite qu’un seul versement initial. Une fois financé, aucune maintenance de liquidité n’est requise.
Dans cette conception de canal temporaire, après le financement, aucun rééquilibrage n’est nécessaire. Contrairement au réseau Lightning, ni l’utilisateur ni le fournisseur de liquidité n’ont à gérer la liquidité du canal. Le seul changement possible est le retrait de l’utilisateur.
3.6.4 Résumé du protocole ARK
En résumé, le protocole ARK représente un progrès spectaculaire par rapport au réseau Lightning en termes d’expérience utilisateur :
-
L’utilisateur n’a pas besoin de maintenir son propre nœud
-
L’utilisateur n’a pas besoin de gérer la liquidité du canal, pas de problème de liquidité entrante
-
Supporte les interactions asynchrones, pas besoin que les deux parties soient en ligne simultanément
4. Changement de paradigme du scaling natif sur Bitcoin
Grâce à cette analyse, nous avons exploré plusieurs schémas de scaling hors chaîne basés sur Shared UTXO. Initialement conçu pour résoudre les problèmes de liquidité, Shared UTXO a conduit à des avantages inattendus au fil de l’évolution des protocoles.
Cela marque une nouvelle direction pour le scaling hors chaîne sur Bitcoin — un véritable changement de paradigme par rapport au modèle initial du réseau Lightning :
-
Passage du modèle P2P à l’introduction d’un opérateur non fiable (trustless)
La logique du scaling hors chaîne évolue du modèle bilatéral « utilisateur à utilisateur » du réseau Lightning initial vers un modèle « utilisateur contre opérateur ». La différence ? L’utilisateur n’a pas besoin de faire confiance à cet opérateur tiers.
-
L’utilisateur n’a plus besoin de maintenir un nœud pour sécuriser ses actifs
Les modèles traditionnels comme LN-Penalty ou les recherches récentes comme CRAB exigent que l’utilisateur bloque des garanties pour sécuriser ses fonds, et reste en ligne tout au long de la durée du canal. Les futures solutions n’auront plus besoin de ces opérations. Et surtout, elles restent non détenues : l’utilisateur conserve toujours le contrôle de ses actifs.
-
La gestion de la liquidité passe de l’utilisateur à l’opérateur
Dans les modèles LN-Penalty classiques ou améliorés, l’utilisateur doit ajuster lui-même la liquidité de son canal, notamment en cas de déséquilibre. Cela demande une expertise, et devient complexe sans LSP. Avec le transfert de cette responsabilité à un opérateur tiers, l’utilisateur n’a plus à s’en soucier. Cela simplifie grandement l’expérience et élimine les obstacles à l’entrée.
-
Efficacité du capital et potentiel fortement améliorés
Les nouveaux protocoles évoluent vers un modèle P2POOL, fondamentalement différent du réseau Lightning actuel en matière d’efficacité du capital. Dans LN-Penalty, chaque utilisateur doit fournir sa propre liquidité, mais celle-ci reste souvent inutilisée (paiements rares et inégalement répartis), gaspillant ainsi le capital. Dans les nouvelles conceptions, la liquidité est centralisée dans des pools, ouvrant des possibilités infinies pour les futurs scénarios DeFi.
Ce changement de paradigme montre que la gestion de la liquidité est l’essence de l’évolution du scaling natif sur Bitcoin, et restera la principale trajectoire future.
À l’avenir, avec les progrès technologiques et l’émergence de nouvelles solutions, la voie du scaling hors chaîne sur Bitcoin s’annonce plus prometteuse que jamais. Nous continuerons à approfondir cette recherche — restez à l’écoute pour nos prochains résultats.
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
@blapta
