Les réseaux de couche 2 seront-ils la solution finale pour l'extension de Bitcoin ?
TechFlow SélectionTechFlow Sélection
Les réseaux de couche 2 seront-ils la solution finale pour l'extension de Bitcoin ?
Un article détaillant les solutions de couche 2 telles que les sidechains, le réseau Lightning, RGB et les rollups, ainsi que des propositions populaires au sein de la communauté centrale de Bitcoin comme Drivechain et Spacechain.
Dédié à des analyses Web3 approfondiesRédaction : Chakra Research
Outre les solutions natives de mise à l'échelle mentionnées dans le premier volet, une autre voie de scalabilité pour Bitcoin consiste à construire un protocole supplémentaire au-dessus du réseau Bitcoin, appelé couche 2 (Layer 2). Deux aspects sont cruciaux pour ces solutions Layer 2 : un pont bidirectionnel sécurisé et l'héritage de la sécurité du consensus de Bitcoin.
Chaîne latérale (Sidechain)
Le concept de chaîne latérale remonte à 2014 avec le document « Enabling Blockchain Innovations with Pegged Sidechains » soumis par Blockstream, constituant une approche relativement simple de mise à l'échelle.
Principe de fonctionnement
Une chaîne latérale est une blockchain indépendante du réseau principal, dotée de son propre protocole de consensus. Elle peut servir de terrain d'expérimentation pour des innovations sur la chaîne principale. Si un événement malveillant survient sur la chaîne latérale, les dommages restent confinés à celle-ci sans affecter la chaîne principale. Grâce à un protocole de consensus offrant un débit transactionnel plus élevé (TPS), elle peut étendre les capacités programmables du BTC.
Les chaînes latérales peuvent transférer des bitcoins entre différentes blockchains via un mécanisme de « two-way peg » ou « one-way peg ». Toutefois, en réalité, les BTC ne quittent jamais le réseau Bitcoin ; il faut donc recourir à un système d’ancrage pour lier les BTC présents sur la chaîne latérale à ceux du réseau Bitcoin.
Dans le cas du « one-way peg », l'utilisateur doit envoyer ses BTC depuis le réseau principal vers une adresse inaccessible (destruction), puis recevoir un équivalent en BTC sur la chaîne latérale. Ce processus n'est pas réversible. Le « two-way peg » améliore cette approche en permettant aux BTC de circuler librement entre la chaîne principale et la chaîne latérale. Contrairement à la destruction par envoi vers une adresse inutilisable, le « two-way peg » verrouille les BTC via des scripts de contrôle comme les multisignatures, puis frappe de nouveaux BTC sur la chaîne latérale. Lorsque l'utilisateur souhaite revenir sur le réseau principal, les BTC sur la chaîne latérale sont brûlés (burned) afin de libérer les BTC précédemment verrouillés sur la chaîne principale.
La mise en œuvre du « one-way peg » est bien plus simple que celle du « two-way peg », car elle n’exige pas la gestion d’états associés sur le réseau Bitcoin. Cependant, les actifs générés sur la chaîne latérale via ce mécanisme risquent de n’avoir aucune valeur, faute d’un mécanisme d’ancrage inverse.
Pour valider les transactions de verrouillage sur la chaîne principale et celles de destruction sur la chaîne latérale, plusieurs méthodes existent, offrant différents niveaux de sécurité. La plus simple consiste à utiliser la validation externe par des participants multisignatures, mais elle comporte un fort risque de centralisation. Une alternative préférable repose sur la preuve SPV (Simple Payment Verification) pour assurer une validation décentralisée. Toutefois, en raison du manque de fonctionnalités programmables sur Bitcoin, une telle vérification SPV n’est pas possible directement, obligeant généralement à recourir à un modèle de garde multisignature.
Problèmes et pistes
Deux critiques principales pèsent sur les chaînes latérales :
Dépendance aux validateurs pour le pont d'actifs : Étant donné que le réseau Bitcoin ne supporte pas encore les contrats intelligents, le transfert d'actifs entre chaînes ne peut être géré par une logique contractuelle sans confiance. Le retour vers Bitcoin nécessite donc un groupe de validateurs, introduisant une hypothèse de confiance et un risque de fraude.
Absence d’héritage de la sécurité de la chaîne principale : Comme la chaîne latérale fonctionne indépendamment, elle n’hérite pas de la sécurité du réseau principal et pourrait subir des attaques telles que des restructurations malveillantes de blocs.
Face à cela, diverses approches ont été proposées : s’appuyer sur une autorité (type consortium), sur la sécurité économique (PoS), sur les mineurs décentralisés de Bitcoin (minage fusionné - Merged Mining), ou encore sur des modules matériels de sécurité (HSM). La garde des fonds sur Bitcoin et la production de blocs sur la chaîne latérale peuvent être confiées à différents rôles, permettant ainsi des mécanismes de sécurité plus complexes.
Études de cas
Liquid
La première forme de chaîne latérale apparue est la chaîne latérale de type consortium, où plusieurs entités pré-sélectionnées agissent comme validateurs, chargés à la fois de la garde des fonds sur le réseau principal et de la production des blocs sur la chaîne latérale.
Liquid incarne ce modèle : 15 parties participent comme validateurs, sans divulguer leurs méthodes de gestion des clés privées. La validation requiert 11 signatures. La production des blocs sur la chaîne Liquid est également assurée par ces 15 membres. Cette faible centralisation permet un TPS élevé, atteignant ainsi l'objectif de scalabilité, principalement utilisé dans le domaine du DeFi.
Toutefois, cette architecture présente un risque notable de centralisation.
Rootstock (RSK)
RSK compte aussi 15 nœuds chargés de la garde des fonds sur le réseau principal, mais seulement 8 signatures sont nécessaires pour valider une opération. Contrairement à Liquid, les clés multisignatures sont gérées par des modules matériels de sécurité (HSM), et les instructions de retrait (peg-out) sont signées selon le consensus PoW, empêchant ainsi les validateurs détenteurs de clés de manipuler directement les fonds sous garantie.
Sur le plan du consensus, RSK utilise le minage fusionné (Merged Mining), tirant parti de la puissance de calcul du réseau principal pour assurer la sécurité des transactions sur la chaîne latérale. Lorsque la proportion du hachage consacré au minage fusionné est élevée par rapport au réseau principal, cela permet de mieux prévenir les doubles dépenses. RSK a amélioré le Merged Mining afin d’assurer la sécurité même avec un faible taux de hachage, en adoptant une méthode sensible aux fourches qui intervient hors chaîne pour consensuer sur les comportements de fork, réduisant ainsi les risques de double dépense.
Cependant, le Merged Mining modifie les incitations des mineurs et accroît le risque de MEV (valeur extrême de l’ordre des transactions), pouvant finalement compromettre la stabilité du système. À long terme, cela pourrait renforcer la centralisation du minage.
Stacks
Stacks ancre l’historique de sa chaîne dans les blocs Bitcoin en y incluant le hachage des blocs Stacks, héritant ainsi de la finalité de Bitcoin. Un fork sur Stacks ne peut se produire que si Bitcoin lui-même bifurque, ce qui renforce considérablement la résistance aux doubles dépenses.
sBTC introduit un nouveau jeton STX et un modèle incitatif basé sur un pont par mise en gage (staking bridge), permettant jusqu’à 150 validateurs sur le réseau principal. Ces validateurs doivent miser des jetons STX pour obtenir le droit d’approuver les dépôts et retraits. La sécurité de ce pont repose fortement sur la valeur des actifs misés. En cas de forte volatilité de cette valeur, la sécurité du pont peut être compromise. Si la valeur des actifs misés devient inférieure à celle des actifs en transit, les validateurs ont alors un motif de tricher.
D'autres propositions de chaînes latérales sont actuellement largement discutées dans la communauté.
Drivechain
L'une des propositions les plus remarquées est Drivechain, imaginée par Paul Sztorc en 2015. Ses technologies clés ont été attribuées aux BIP 300 (mécanisme d’ancrage) et BIP 301 (minage fusionné aveugle). Le BIP 300 définit précisément la logique d’activation d’une nouvelle chaîne latérale, similaire à l’activation d’un fork mou par signal des mineurs. Le BIP 301 permet aux mineurs Bitcoin de produire des blocs sur la chaîne latérale sans avoir à vérifier le contenu des transactions.
Les mineurs Bitcoin supervisent également l’approbation des retraits. Pour cela, ils créent d’abord une sortie OP_RETURN dans la transaction coinbase de leur bloc pour proposer un retrait, puis les autres mineurs peuvent voter pour ou contre cette proposition dans chaque nouveau bloc. Une fois qu’un seuil est atteint (13 150 blocs), le retrait est exécuté et confirmé par la chaîne principale.
En pratique, les mineurs contrôlent entièrement les fonds sur Drivechain. En cas de vol, les utilisateurs ne peuvent compter que sur un UASF (soft fork activé par les utilisateurs) pour se protéger, ce qui est extrêmement difficile à coordonner. De plus, le rôle unique des mineurs dans Drivechain amplifie le risque de MEV, comme cela a déjà été observé sur Ethereum.
Spacechain
Spacechain adopte une approche originale en utilisant un « Perpetual 1-way peg » (P1WP). Les utilisateurs brûlent des BTC pour obtenir un jeton sur Spacechain, contournant ainsi toute question de sécurité des fonds. Ce jeton ne sert qu’à enchérir pour l’espace bloc sur Spacechain, sans fonction de stockage de valeur.
Pour assurer la sécurité de la chaîne latérale, Spacechain utilise le minage fusionné aveugle. D'autres utilisateurs se disputent via des enchères publiques (avec ANYPREVOUT/APO) le droit de construire des blocs. Les mineurs Bitcoin doivent simplement s’engager à inclure l’en-tête du bloc Spacechain, sans avoir à valider le bloc latéral. Toutefois, le démarrage de Spacechain nécessite le soutien de Covanent, dont l’ajout en tant qu’opcode fait encore l’objet de discussions au sein de la communauté Bitcoin.
Globalement, Spacechain permet de créer une chaîne latérale bénéficiant de la même décentralisation et résistance à la censure que Bitcoin, tout en offrant davantage de programmabilité grâce à une fonction d’enchères sur l’espace bloc.
Softchain
Softchain est une proposition de sidechain 2wp formulée par Ruben Somsen, l’auteur de Spacechain, utilisant un mécanisme de consensus PoW FP pour garantir la sécurité de la chaîne latérale. Normalement, les nœuds complets Bitcoin n’ont besoin que de télécharger les en-têtes Softchain pour vérifier la preuve de travail. En cas de fork, ils téléchargent les blocs orphelins et l’ensemble des engagements UTXO correspondants pour valider la légitimité des blocs.
Concernant le mécanisme 2wp, lors d’un dépôt (peg-in), une transaction de dépôt est créée sur la chaîne principale, et Softchain référence cette transaction pour créditer les fonds. Pour un retrait (peg-out), une transaction de retrait est créée sur Softchain, que la chaîne principale référence pour récupérer les BTC, après une période de contestation prolongée. Ce mécanisme nécessite un soft fork, d'où le nom « Softchain ».
Cette solution impose un coût de validation supplémentaire aux nœuds complets Bitcoin, et une division du consensus Softchain pourrait perturber le consensus principal, représentant ainsi une menace potentielle pour le réseau Bitcoin.
Réseau Lightning (Lightning Network)
Le réseau Lightning a publié son livre blanc en 2015 et a été lancé officiellement en 2018. En tant que protocole de paiement peer-to-peer (p2p) de niveau 2 sur Bitcoin, il vise à traiter hors chaîne un grand volume de petites transactions fréquentes. Pendant longtemps, il a été considéré comme la solution de scalabilité la plus prometteuse pour Bitcoin.
Modules clés
La mise en œuvre du réseau Lightning repose sur plusieurs modules essentiels de Bitcoin, qui ensemble garantissent la sécurité des transactions Lightning.
Premièrement, les transactions pré-signées. Ce mécanisme n’est devenu sûr et utilisable qu’après la mise à jour SegWit. SegWit sépare les signatures des autres données transactionnelles, résolvant ainsi des problèmes comme la dépendance cyclique ou la falsification de transaction par un tiers. La sécurité des calculs hors chaîne dans Lightning repose sur des engagements irrévocables fournis par l’autre partie, matérialisés par des transactions pré-signées. Une fois qu’un utilisateur reçoit une telle transaction, il peut à tout moment la diffuser sur la chaîne pour faire valoir cet engagement.
Deuxièmement, la multisignature. Pour transférer fréquemment des fonds hors chaîne entre deux parties, un mécanisme est nécessaire où chacun conserve un certain contrôle. On utilise généralement une signature 2/2, garantissant que tout transfert nécessite l’accord mutuel des deux parties.
Cependant, la multisignature 2/2 pose un problème de vivacité : si l’autre partie ne coopère pas, l’utilisateur ne peut retirer aucun actif de l’adresse multisignature, entraînant une perte potentielle. Le verrouillage temporel (time lock) résout ce problème en signant préalablement un contrat de restitution avec time lock, garantissant qu’en cas d’inactivité d’une partie, l’autre peut récupérer ses fonds initiaux.
Enfin, le verrouillage par hachage (hash lock) permet de connecter plusieurs canaux d’état et de former un réseau. La préimage du hachage sert de médium de communication pour coordonner correctement le fonctionnement entre plusieurs entités.
Flux opérationnel
Canal bidirectionnel
Avant d'utiliser le réseau Lightning, deux parties doivent d'abord ouvrir un canal de paiement bidirectionnel sur Bitcoin. Elles peuvent ensuite effectuer autant de transactions hors chaîne que souhaité, puis soumettre l'état final sur Bitcoin pour règlement et fermer le canal.
Plus précisément, la mise en œuvre d'un canal implique les étapes suivantes :
-
Création d'une adresse multisignature. Les deux parties créent une adresse multisignature 2-sur-2 servant d'adresse de verrouillage des fonds. Chaque partie détient une clé privée de signature et fournit sa clé publique.
-
Initialisation du canal. Les deux parties diffusent une transaction sur chaîne pour verrouiller une certaine quantité de bitcoins dans l'adresse multisignature, formant ainsi le capital initial du canal. Cette transaction est appelée « transaction d’ancrage ».
-
Mise à jour de l'état du canal. Pendant les paiements, les deux parties échangent des transactions pré-signées pour mettre à jour l'état du canal. Chaque mise à jour génère une nouvelle « transaction d’engagement », reflétant la répartition actuelle des fonds. Cette transaction a deux sorties, correspondant chacune à la part de chaque partie.
-
Diffusion du dernier état. N'importe quelle partie peut à tout moment diffuser la dernière transaction d’engagement sur la blockchain pour retirer sa part. Pour empêcher la diffusion d’un ancien état, chaque transaction d’engagement dispose d’une « transaction de pénalité » associée : si l'autre partie triche, on peut alors récupérer la totalité de ses fonds.
-
Fermeture du canal. Lorsque les deux parties décident de fermer le canal, elles peuvent collaborer pour générer une « transaction de règlement », diffusant l'état final sur la blockchain. Les fonds verrouillés sont alors libérés vers les adresses personnelles de chacun.
-
Arbitrage sur chaîne. Si les deux parties ne parviennent pas à s'entendre lors de la fermeture, l'une d'elles peut unilatéralement diffuser la dernière transaction d’engagement, lançant un processus d’arbitrage. Si aucune objection n’est soulevée dans un délai défini (par exemple 1 jour), les fonds sont distribués selon cet état.
Réseau de paiement
Les canaux de paiement peuvent être interconnectés pour former un réseau, permettant des paiements multi-sauts via HTLC (Contrat de Vente à Livraison Conditionnelle par Hachage). L'HTLC utilise un verrouillage par hachage comme condition principale et une signature de paiement avec time lock comme condition de secours, permettant aux utilisateurs d'interagir autour de la préimage du hachage avant expiration.
Quand deux utilisateurs n'ont pas de canal direct, ils peuvent effectuer un paiement via des routes intermédiaires utilisant HTLC. Dans ce processus, la préimage du hachage (R) joue un rôle crucial, garantissant l’atomicité du paiement. En outre, les time locks sont configurés de manière décroissante le long du chemin, assurant à chaque relais suffisamment de temps pour traiter et transmettre le paiement.
Problèmes existants
En essence, le réseau Lightning contourne l’hypothèse de confiance externe liée au pont d’actifs grâce à des canaux d’état p2p, tout en utilisant des scripts de time lock pour fournir une garantie finale des actifs, offrant ainsi une protection contre les pannes. En cas d’inactivité de la contrepartie, un retrait unilatéral reste possible. Ainsi, le réseau Lightning présente une grande utilité pour les paiements, mais comporte aussi plusieurs limitations majeures :
-
Limite de capacité du canal. La capacité des canaux Lightning est limitée par les fonds initialement verrouillés, ce qui empêche les paiements excédant cette limite. Cela peut limiter certains usages, comme les transactions de marchandises.
-
Connexion et synchronisation continues. Pour recevoir et relayer efficacement les paiements, les nœuds Lightning doivent rester en ligne. Si un nœud est hors ligne trop longtemps, il peut manquer des mises à jour d’état, provoquant une désynchronisation. Cela représente un défi pour les utilisateurs individuels ou les appareils mobiles, augmentant aussi le coût d’exploitation des nœuds.
-
Gestion de la liquidité. L’efficacité du routage dépend de la répartition de la liquidité dans les canaux. Une distribution déséquilibrée peut rendre certains chemins inopérants, nuisant à l’expérience utilisateur. Maintenir un équilibre optimal nécessite des compétences techniques et des coûts financiers.
-
Fuites de confidentialité. Pour trouver un chemin de paiement viable, l’algorithme de routage doit connaître partiellement la capacité et la connectivité des canaux. Cela peut révéler des informations sensibles comme la répartition des fonds ou les partenaires commerciaux. L’ouverture et la fermeture des canaux peuvent aussi exposer l’identité des participants.
RGB
Le protocole RGB s'inspire initialement du concept de « vérification client » et de « sceau à usage unique » proposé par Peter Todd. Il a été formalisé en 2016 par Giacomo Zucco comme un protocole de deuxième couche pour Bitcoin, extensible et respectueux de la vie privée.
Idées fondamentales
Vérification client
La vérification sur blockchain consiste à diffuser des blocs composés de transactions, que chaque nœud calcule et valide. Cela crée un bien public : tous les nœuds aident chaque utilisateur à valider ses transactions, tandis que celui-ci paie des frais en BTC comme incitation. La vérification client, quant à elle, est centrée sur l’individu : la validation d’état n’est plus globale, mais réalisée uniquement par les participants à une transition d’état spécifique. Seuls les intervenants vérifient la validité de la transition, ce qui améliore fortement la confidentialité, allège la charge des nœuds et augmente la scalabilité.
Sceau à usage unique
Les transitions d’état p2p comportent un risque : si un utilisateur ne collecte pas l’historique complet, il peut être victime de fraude ou de double dépense. Le sceau à usage unique résout ce problème en utilisant un objet spécial qui ne peut être utilisé qu’une seule fois, garantissant ainsi l’unicité des dépenses. L’UTXO de Bitcoin est l’objet idéal pour ce rôle, sécurisé par le consensus et la puissance de calcul du réseau. Ainsi, les actifs RGB héritent de la sécurité de Bitcoin.
Engagement cryptographique
Le sceau à usage unique doit être combiné à un engagement cryptographique pour garantir que l’utilisateur soit informé d’une transition d’état et éviter les doubles dépenses. Un engagement consiste à annoncer qu’un événement s’est produit, sans en révéler les détails immédiatement, mais de façon irrévocable. On peut utiliser une fonction de hachage pour cet engagement. Dans RGB, l’engagement porte sur la transition d’état : lorsque l’UTXO est dépensé, le destinataire reçoit un signal de transfert, puis vérifie via les données transmises hors chaîne par l’émetteur si cet engagement est valide.
Flux opérationnel
RGB exploite le consensus de Bitcoin pour garantir la sécurité contre les doubles dépenses et la censure, tandis que toutes les validations d’état sont déplacées hors chaîne et effectuées uniquement par le client destinataire.
Pour émettre un actif RGB, l’émetteur doit créer un contrat RGB via une transaction, dont les informations sont engagées dans un script OP_RETURN d’une condition de dépense Taproot.
Lorsqu’un détenteur d’actif RGB souhaite le dépenser, il obtient des informations du destinataire, crée une transaction RGB, engage les détails de cette transaction dans un UTXO spécifié par le destinataire, puis envoie une transaction dépensant l’UTXO source et créant le nouvel UTXO cible. Dès que le destinataire observe que l’UTXO contenant l’actif RGB a été dépensé, il peut valider la validité de la transaction RGB via l’engagement inclus dans la transaction Bitcoin. Si la validation réussit, il considère avoir bien reçu l’actif.
Le destinataire d’un actif RGB doit recevoir du payeur : l’état initial du contrat et ses règles de transition, chaque transaction Bitcoin utilisée, chaque transaction RGB engagée dans ces transactions, ainsi que des preuves de validité de chaque transaction Bitcoin. Son client local utilise ces données pour valider la transaction RGB. L’UTXO Bitcoin sert de conteneur à l’état du contrat RGB. L’historique de chaque contrat peut être représenté par un graphe acyclique orienté. Le destinataire ne voit que l’historique lié à ses propres actifs, ignorant les autres branches.
Avantages et limites
Vérification allégée
Comparé à la vérification complète de blockchain, RGB réduit considérablement le coût de validation. L’utilisateur n’a pas besoin de parcourir tous les blocs historiques pour connaître l’état actuel, mais seulement de synchroniser l’historique relatif à ses actifs pour valider une transaction.
Cette vérification légère facilite les transactions p2p, réduit la dépendance aux fournisseurs de services centralisés et renforce la décentralisation.
Extensibilité
RGB hérite de la sécurité de Bitcoin via un simple engagement de hachage, et grâce à Taproot, consomme presque aucun espace supplémentaire sur la chaîne Bitcoin. Cela rend possible une programmation complexe des actifs. En utilisant l’UTXO comme conteneur, RGB bénéficie naturellement d’une concurrence : les actifs RGB sur différentes branches peuvent être dépensés simultanément sans se bloquer mutuellement.
Confidentialité
Contrairement aux protocoles classiques, seul le destinataire d’un actif RGB peut voir son historique de transfert. Une fois dépensé, il ne peut plus suivre les futurs mouvements. Cela préserve fortement la vie privée. De plus, les transactions RGB ne laissent aucune trace identifiable sur la chaîne Bitcoin, rompant tout lien apparent avec les UTXO.
En outre, RGB prend en charge les paiements aveugles (blind spending) : l’émetteur ignore dans quel UTXO exact le destinataire recevra les fonds, renforçant encore la confidentialité et la résistance à la censure.
Inconvénients
Après plusieurs retransmissions, un nouvel utilisateur recevant un actif RGB doit valider un historique long et complexe, entraînant un fardeau important et des délais de validation élevés, perdant ainsi la rapidité de confirmation. Pour les nœuds maintenus en permanence, la synchronisation continue limite ce problème.
La communauté examine actuellement la possibilité de réutiliser les calculs historiques. Des preuves ZK récursives pourraient permettre une vérification d’état en temps et taille constants.
Rollup
Aperçu
Le Rollup est la solution optimale de mise à l'échelle adoptée par l'écosystème Ethereum après des années d'exploration, passant des canaux d'état à Plasma avant d'aboutir au Rollup.
Un Rollup est une blockchain indépendante qui collecte des transactions en dehors de Bitcoin, regroupe plusieurs transactions en lots, les exécute, puis soumet les données de ce lot ainsi qu’un engagement d’état à la chaîne principale, réalisant ainsi un traitement hors chaîne et une mise à jour d’état. Pour maximiser la scalabilité, les Rollups utilisent souvent un séquenceur centralisé, améliorant l’efficacité d’exécution, sans sacrifier la sécurité, qui reste garantie par la vérification des transitions d’état sur la chaîne principale.
Avec la maturité des solutions Rollup dans l’écosystème Ethereum, la communauté Bitcoin commence à expérimenter ce modèle. Toutefois, la différence fondamentale réside dans la faible capacité programmable de Bitcoin, qui ne permet pas d’effectuer sur chaîne les calculs nécessaires au fonctionnement d’un Rollup. Actuellement, seules des variantes comme le Rollup souverain ou l’OP Rollup sont envisageables.
Classification
Selon la méthode de vérification des transitions d’état, on distingue deux grandes catégories : Optimistic Rollup et Validity Rollup (ZK Rollup).
L’Optimistic Rollup repose sur une validation optimiste : après soumission d’un lot, durant une période de contestation, toute personne peut examiner les données hors chaîne et soumettre une preuve de fraude à la chaîne principale pour sanctionner le séquenceur. Si aucune preuve valide n’est fournie après cette période, le lot est considéré comme valide et l’état est confirmé.
Le Validity Rollup utilise une preuve de validité : le séquenceur génère pour chaque lot une preuve concise (via zéro-connaissance) attestant que la transition d’état est correcte. Chaque mise à jour soumet cette preuve à la chaîne principale, qui la vérifie avant de confirmer l’état.
L’Optimistic Rollup est plus simple à mettre en œuvre et nécessite peu de modifications sur la chaîne. Mais il a un temps de confirmation long (lié à la période de contestation) et exige une forte disponibilité des données. Le Validity Rollup offre un temps de confirmation rapide, n’a pas besoin de période de contestation, et peut garder les données privées, mais la génération et la vérification des preuves zéro-connaissance sont très coûteuses en calcul.
Celestia a également introduit le concept de Rollup souverain : les données transactionnelles sont publiées sur une blockchain dédiée de disponibilité des données (DA layer), tandis que le Rollup souverain assure l’exécution et le règlement.
Explorations et discussions
Les Rollups sur Bitcoin en sont encore au stade préliminaire. En raison des différences fondamentales avec Ethereum concernant le modèle de comptabilité et le langage programmable, il est difficile de copier directement les expériences d’Ethereum. La communauté Bitcoin explore activement des solutions innovantes.
Rollup souverain
Le 5 mars 2023, Rollkit a annoncé être le premier cadre à supporter les Rollups souverains sur Bitcoin. Les développeurs peuvent désormais publier des données de disponibilité sur Bitcoin via Rollkit.
Inspiré par Ordinals, Rollkit utilise des transactions Taproot pour publier des données. Une transaction Taproot conforme aux standards du mempool peut contenir jusqu’à 390 Ko de données, tandis qu’une transaction non standard publiée directement par un mineur peut intégrer près de 4 Mo de données arbitraires.
Le rôle réel de Rollkit est de fournir une interface permettant aux Rollups souverains de lire et écrire des données sur Bitcoin, agissant comme un middleware, transformant ainsi Bitcoin en couche DA.
Cette idée suscite de nombreuses critiques. Beaucoup affirment qu’un Rollup souverain sur Bitcoin n’utilise ce dernier que comme un tableau d’affichage, sans hériter de sa sécurité. En effet, ne soumettre que les données transactionnelles améliore seulement la vivacité (tous les utilisateurs peuvent récupérer les données pour vérifier), mais la sécurité reste définie par le Rollup lui-même. Par ailleurs, l’espace bloc sur Bitcoin étant précieux, publier toutes les données transactionnelles n’est probablement pas une bonne décision.
OP Rollup & Validity Rollup
Bien que nombreux projets Bitcoin second couche s’intitulent « ZK Rollup », ils ressemblent davantage à des OP Rollup, même s’ils intègrent des éléments de preuve de validité. Or, la capacité programmable de Bitcoin ne permet pas encore de vérifier directement ces preuves.
Actuellement, l’ensemble des opcodes Bitcoin est très limité, incapable même de calculer une multiplication. La vérification de preuve de validité exige l’extension des opcodes, notamment via des contrats récursifs. Des propositions comme OP_CAT, OP_CHECKSIG ou OP_TXHASH font l’objet de vifs débats. Ajouter directement un OP_VERIFY_ZKP rendrait inutiles toutes les autres modifications, mais semble hautement improbable. En outre, la limite de taille de pile entrave les tentatives de vérification de preuves de validité dans les scripts Bitcoin, bien que plusieurs expérimentations soient en cours.
Comment fonctionne alors la preuve de validité ? La plupart des projets publient via inscription (inscription) sur Bitcoin le diff d’état et la preuve de validité du lot, puis utilisent BitVM pour une validation optimiste. Le pont BitVM remplace ici le modèle multisignature traditionnel : les opérateurs forment une alliance de N membres pour gérer les dépôts des utilisateurs. Avant un dépôt, l’alliance pré-signature l’UTXO futur, garantissant que seul un opérateur puisse valablement récupérer les fonds. Après obtention de cette pré-signature, les BTC sont verrouillés dans une adresse Taproot multisignature N/N.
Lorsqu’un utilisateur demande un retrait, le Rollup envoie sur Bitcoin la preuve de validité incluant la racine du retrait. L’opérateur avance les fonds pour satisfaire la demande, puis la validité est vérifiée via le contrat BitVM. Si tous les opérateurs jugent la preuve valide, ils remboursent l’opérateur via multisignature. Si un participant détecte une fraude, un processus de contestation s’engage, et le fautif est pénalisé (slash).
Ce processus est en réalité identique à l’OP Rollup, reposant sur une hypothèse de sécurité 1/N : tant qu’un seul vérificateur est honnête, le protocole reste sécurisé.
Cependant, la mise en œuvre technique de ce schéma peut s’avérer difficile. Sur Ethereum, Arbitrum a mis des années à développer son système, et ses preuves de fraude restent aujourd’hui accessibles uniquement à des nœuds autorisés. Optimism n’a annoncé le support des preuves de fraude qu’assez récemment, montrant à quel point la réalisation est ardue.
Quant à l’opération de pré-signature dans le pont BitVM, elle pourrait être rendue plus efficace avec le soutien de Covanent sur Bitcoin, mais cela attend encore le consensus communautaire.
Du point de vue de la sécurité, ce schéma tire du hachage des blocs Rollup inscrits sur Bitcoin une résistance aux restructurations et aux doubles dépenses, et bénéficie d’une sécurité 1/N grâce au pont optimiste. Toutefois, la résistance à la censure du pont pourrait encore être améliorée.
Conclusion : Les couches 2 ne sont pas une panacée
En examinant ces nombreuses solutions de couche 2, on constate facilement que chacune a des capacités limitées. Sous des hypothèses de confiance données, l’efficacité d’une couche 2 dépend largement des capacités natives de la couche 1 — c’est-à-dire de Bitcoin lui-même.
Sans la mise à jour SegWit ni les time locks, le réseau Lightning ne pourrait exister. Sans Taproot, les engagements RGB seraient impossibles. Sans OP_CAT ou autres opcodes Covanent, les Validity Rollups sur Bitcoin resteraient inaccessibles…
Beaucoup de Bitcoin Maximalistes pensent que Bitcoin ne devrait jamais changer ni ajouter de nouvelles fonctionnalités, et que toutes les lacunes doivent être corrigées par les couches 2. C’est irréaliste : les couches 2 ne sont pas une solution miracle. Nous avons besoin d’une couche 1 plus puissante pour construire des couches 2 plus sûres, efficaces et évolutives.
Dans le prochain article, nous explorerons les tentatives visant à améliorer la programmabilité de Bitcoin. 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
@ChakraChain
