Bitcoin Layer 2 : Solutions de mise à l'échelle, défis et perspectives futures
TechFlow SélectionTechFlow Sélection
Bitcoin Layer 2 : Solutions de mise à l'échelle, défis et perspectives futures
Cet article explore en profondeur les perspectives de développement des technologies Bitcoin L2 et leur impact potentiel sur le marché.
Dédié à des analyses Web3 approfondiesRédigé par : BlockPunk@Researcher of Trustless Labs
1. Introduction
Alors que le réseau Bitcoin continue de croître et que la technologie des inscriptions connaît un essor fulgurant, l’écosystème BTC traverse un moment charnière. La demande croissante pour des solutions d’extension du réseau devient pressante, notamment en raison de la compétition accrue pour les ressources réseau et de la hausse des frais de transaction induite par les inscriptions. Ce rapport explore en profondeur les perspectives technologiques des couches 2 (L2) sur Bitcoin ainsi que leurs impacts potentiels sur le marché, en mettant particulièrement l'accent sur la manière dont ces technologies peuvent intégrer des actifs BTC et renforcer la sécurité. Nous analyserons en détail différentes approches mises en œuvre pour les L2 Bitcoin — chaînes latérales (sidechains), Rollups, couches DA (disponibilité des données) — ainsi que leur capacité à inciter les dépôts d’actifs BTC depuis la couche 1 (L1) et à créer de nouveaux types d’actifs.
Par ailleurs, après que la technologie des inscriptions ait lancé une nouvelle vague de distribution d’actifs, nous faisons face à de nouveaux défis et opportunités. La capitalisation maximale atteinte grâce à des modèles basés sur la distribution équitable ou des récits « meme » souligne désormais l’urgence de construire davantage pour franchir ce plafond. Dans ce processus, la fourniture de fonctionnalités et la définition des actifs sous-jacents gagnent en importance. Les sidechains fondées sur les inscriptions permettent non seulement d’abaisser le seuil d’entrée pour les utilisateurs, mais aussi d’introduire des contrats intelligents complets, ouvrant ainsi la voie à de nouvelles applications dans les domaines DeFi, SocialFi et GameFi. Le concept de programmation orientée indexeur propose une approche inédite qui part des propriétés natives mêmes des inscriptions pour envisager l’extension fonctionnelle et commerciale. Cela pourrait non seulement alléger la charge serveur, mais également conduire à la création d’une toute nouvelle chaîne d’inscriptions.
Quatre vagues de transformation
L’écosystème Bitcoin est en train de traverser une série de bouleversements transformatifs qui redéfinissent non seulement le consensus communautaire, mais aussi impulsent fortement l’avancement technologique et culturel. Du consensus autour de la distribution équitable à la renaissance culturelle du BTC, puis à l’explosion des solutions d’extension « basées sur les inscriptions », jusqu’à la quête finale de schémas d’extension plus aboutis, l’écosystème BTC est en pleine mutation rapide.
La première vague fut celle du consensus communautaire autour de la distribution équitable. BRC20 a créé un nouveau type d’actif radicalement différent des FT et NFT, représentant une innovation primaire dans l’univers blockchain et incarnant l’essor de la culture populaire.
La deuxième vague, que nous vivons actuellement, correspond à la renaissance culturelle du BTC, où de gros capitaux et des bourses rejoignent le consensus. De plus en plus de développeurs s’investissent dans l’univers des inscriptions, lançant de nombreux protocoles prometteurs qui débordent même vers d’autres blockchains. La culture BTC domine tout, bien qu’elle suscite également certains problèmes collatéraux.
La troisième vague pourrait être l’explosion des solutions d’extension « basées sur les inscriptions ». Le développement massif de la deuxième vague a enrichi l’écosystème BTC, mais a exacerbé la concurrence pour les ressources du réseau BTC, entrant en conflit avec les puristes conservateurs du BTC. En outre, la mauvaise expérience utilisateur freine l’arrivée de nouveaux utilisateurs. Ainsi, étendre les inscriptions elles-mêmes (plutôt que d’étendre directement BTC) apparaît comme une nécessité urgente. Toutefois, développer directement des solutions L2 basées sur BTC (comme BitVM) reste complexe et long. Des solutions intermédiaires seront donc adoptées en priorité : au cours des six prochains mois, nous assisterons probablement à l’émergence de nombreuses nouvelles sidechains BTC, utilisant les inscriptions comme actifs natifs (contrairement aux stx), transférant les inscriptions de la chaîne principale via des ponts inter-chaînes.
La quatrième vague symbolise la pleine maturité des schémas d’extension finaux « basés sur BTC », incluant des capacités complètes de contrats intelligents, de meilleures performances, et une sécurité forte partagée avec BTC. Les actifs d’inscription à haute valeur exigeront une sécurité accrue, rendant indispensables des solutions d’extension L2 plus natives, orthodoxes et sécurisées. Ces solutions utiliseront la chaîne BTC comme couche DA, y téléverseront des preuves, voire permettront à la propre validation du réseau BTC, comme c’est le cas avec BitVM ou le protocole AVM d’Atomicals. Grâce à cette garantie d’orthodoxie forte, davantage de BTC seront progressivement absorbés par l’écosystème des inscriptions.
Finalement, nous obtiendrons une expérience, des performances et des fonctionnalités contractuelles presque identiques à celles d’Ethereum et de ses L2, soutenues par l’immense communauté et les capitaux du BTC, centrées culturellement sur la « distribution équitable » et utilisant les « inscriptions » comme actifs natifs — donnant naissance à un tout nouvel écosystème.
Défis et opportunités coexistent
Le développement massif des inscriptions a stimulé la prospérité de l’écosystème BTC, mais a aussi accru la concurrence pour ses ressources réseau. Les frais excessifs, combinés à la hausse prévisible du prix du BTC, continuent d’élever le seuil d’entrée pour les nouveaux participants. Cela pousse à discuter davantage des solutions d’extension du BTC et attire l’attention de la communauté et des investisseurs. Bien sûr, on évite soigneusement toute proposition de mise à niveau directe de la couche 1 BTC. Même les discussions les plus audacieuses se limitent à lever certaines restrictions des scripts OP, explorant davantage le potentiel résiduel de Taproot (comme les discussions autour de CTV et CAT).
Face aux avancées théoriques et pratiques d’Ethereum en matière de Rollup et d’architecture modulaire, les L2 Bitcoin sont devenues le sujet dominant des discussions d’extension, offrant la solution la plus rapide à mettre en œuvre. Les premiers projets devraient lancer leurs versions publiques dans les deux à trois mois à venir, devenant ainsi le récit spéculatif central. En raison de la gouvernance fortement décentralisée du BTC, sans « église » centrale pour guider la communauté, les conceptions L2 sont extrêmement diversifiées. Ce document examinera donc les principaux projets et protocoles BTC L2 du marché afin d’envisager les possibilités d’extension du BTC.
Nous classerons grossièrement les L2 BTC en sidechains, Rollups, couches DA et indexeurs décentralisés, regroupant les projets similaires. Comme personne n’a encore le pouvoir de définir officiellement les solutions d’extension BTC, notre classification ici ne prétend pas à la rigueur académique.
Ce rapport abordera principalement les aspects techniques d’implémentation, sachant que bon nombre de ces conceptions sont encore au stade théorique. En matière de concurrence entre actifs L2, la technologie et la sécurité fixent le plancher du projet — la technologie est le billet d’entrée, qu’il soit en classe affaires, économique ou même un simple strapontin. Mais du point de vue de l’actif, deux éléments sont cruciaux : premièrement, la capacité du L2 à créer de nouveaux actifs, qu’il s’agisse d’importer des inscriptions ou de générer sa propre dynamique ; deuxièmement, sa capacité à attirer des dépôts de BTC depuis la L1 sera un atout compétitif clé. Cela repose fortement sur la sécurité des ponts inter-chaînes, car « not my keys, not my Bitcoins » reste un dogme fondamental, rendant la conception de la solution primordiale.
L’adoption de l’écosystème BTC dépassera-t-elle un jour celle d’Ethereum ? Ce document pourrait vous apporter quelques pistes de réponse.
Avant d’entrer dans l’analyse technique des L2 BTC, présentons brièvement les innovations préalables introduites par la mise à jour Taproot :
-
La signature Schnorr permet désormais des multisignatures impliquant jusqu’à 1000 participants sur BTC, formant la base technique de nombreux ponts L2 ;
-
MAST permet de combiner plusieurs scripts UTXO via un arbre de Merkle, rendant possible des logiques complexes et ouvrant la voie à des systèmes de preuve sur L2 ;
-
Tapscript améliore le script Bitcoin en autorisant une série de vérifications pour déterminer si un UTXO peut être dépensé, rendant possibles des opérations telles que le retrait ou la confiscation sur L2.
2. Aperçu des technologies L2 BTC
Sidechains
Les sidechains permettent l’extension du réseau en créant une chaîne parallèle à la chaîne principale, dotée de son propre mécanisme de consensus et de règles de génération de blocs, reliant les actifs via un pont inter-chaînes avec la chaîne principale BTC.
Tout doit fonctionner — l’utilisabilité prime avant tout. L’avantage principal des sidechains est leur rapidité de déploiement, axée sur le développement rapide de la logique métier. Leur sécurité dépend essentiellement de leur propre réseau, comparable à un « billet accroché » au train de la sécurité BTC. Le composant critique est le pont BTC, unique point de connexion.
1.@BTClayer2BEVM
La plupart des L2 BTC suivent, comme BEVM, la logique des sidechains déjà utilisée pour étendre Ethereum. BEVM déploie une adresse multisignature sur la L1 BTC grâce à Taproot, et fait fonctionner une sidechain EVM sur laquelle est déployé un contrat intelligent acceptant les demandes de retrait de BTC. Le gaz de BEVM utilise le BTC transféré via pont. À l’approvisionnement, les opérateurs du pont synchronisent les données BTC et en informent la sidechain ; les nœuds BEVM exécutent également un client léger pour valider les en-têtes de bloc BTC. Au retrait, les gardiens du pont signent la transaction, et une fois le seuil de signatures atteint, la transaction de retrait de BTC est envoyée. Cela permet l’interopérabilité des actifs entre sidechain et BTC.
Contrairement aux anciennes solutions comme $RSK ou $STX, BEVM utilise la multisignature Taproot pour implémenter une signature seuil, permettant théoriquement un nombre plus élevé de gestionnaires de pont, augmentant ainsi la tolérance aux pannes et la décentralisation. Toutefois, BEVM n’hérite d’aucune sécurité de BTC, se contentant d’assurer l’interopérabilité des actifs. Ses nœuds fonctionnent selon un consensus interne et un EVM indépendants, sans téléverser de preuves sur BTC, donc sans couche DA. L’immutabilité des transactions dépend uniquement du réseau lui-même. Si les nœuds refusent de traiter votre transaction de retrait, vous ne pourrez plus récupérer vos BTC sur la L1 — un risque potentiel.
L’avantage de cette approche réside dans sa rapidité d’implémentation et de validation. La mise en œuvre maison par BEVM de la multisignature Taproot améliore également la sécurité du pont. BEVM fait partie des rares sidechains BTC déjà déployées en production.
2. @MapProtocolMap Protocol
Map est une sidechain EVM spécialisée dans les inscriptions, choisissant de faire passer les BRC20 de la L1 BTC vers l’environnement EVM pour exécuter des opérations à faible coût. Map exploite un indexeur BRC20 amélioré : lorsqu’un utilisateur transfère un BRC20 via pont, il envoie une nouvelle transaction contenant dans le JSON les informations de chaîne cible et d’adresse, permettant à Map de l’indexer et de le rendre visible sur la sidechain. Le retrait du BRC20 est initié par un comité de signatures fonctionnant selon le mécanisme PoS de Map. Le grand livre BRC20 tourne essentiellement dans l’indexeur, tandis que la L1 BTC agit comme source de données disponibles.
Grâce aux frais réduits de la sidechain, Map héberge des outils comme LessGas pour frapper des BRC20, le marché d’inscriptions SATSAT, et assure le pontage BRC20 via Roup. Cette orientation centrée sur les inscriptions attire une base d’utilisateurs fidèle. Map utilise un consensus PoS classique et téléverse périodiquement des points de contrôle vers la L1 BTC pour renforcer sa sécurité contre les attaques à long terme.
3. @BitmapTechMerlin Chain
Sidechain BTC lancée par BRC420. Merlin Chain opte pour la solution MPC du portefeuille Cobo afin de réaliser le pontage BTC, un choix relativement conservateur : le nombre de signataires MPC étant limité, la sécurité est moindre comparée à la multisignature BTC post-Taproot, bien que l’approche MPC soit éprouvée.
Merlin adopte l’abstraction de compte de ParticleNetwork, permettant d’utiliser directement les portefeuilles et adresses Bitcoin pour interagir avec la sidechain, préservant ainsi les habitudes des utilisateurs — une initiative louable. En comparaison, obliger les utilisateurs BTC à revenir à MetaMask semble paresseux et brutal.
BRC420 et Bitmap bénéficient d’une forte notoriété et ont déjà rassemblé une large communauté. Merlin poursuit autour des inscriptions, prenant en charge le pontage de divers actifs d’inscription depuis la L1 et proposant un service de gravure d’inscriptions sur la sidechain.
4. @dfinityckBTC
ckBTC est une intégration BTC dans ICP réalisée entièrement par des méthodes cryptographiques pures, sans recourir à aucun pont tiers ni dépôt. ICP est une blockchain L1 indépendante, dont le consensus repose sur un schéma de signature seuil BLS unique. La technologie ChainKey, liée à la signature seuil du consensus, permet au réseau ICP de gérer collectivement une adresse multisignature BTC, recevoir des BTC, et contrôler ces BTC via une signature agrégée issue du consensus, permettant ainsi les retraits. ICP reproduit également intégralement le modèle UTXO de BTC dans un modèle de comptes, permettant aux contrats intelligents du réseau de lire l’état BTC — équivalent à exécuter un nœud complet BTC au sein d’ICP.
Comme cette signature seuil est étroitement liée au consensus d’ICP, la sécurité de ckBTC dépend uniquement des réseaux ICP et BTC, sans hypothèse de confiance tierce supplémentaire. Ainsi, le schéma de signature seuil ChainKey utilisé par ICP représente actuellement l’approche la plus sûre pour un pont BTC. Toutefois, pour le retrait, si le réseau IC tombe en panne ou refuse la transaction, il est impossible de forcer le retrait depuis la L1 BTC. Par ailleurs, en tant que L1 indépendante, la sécurité d’ICP est autonome et non liée à celle de BTC.
Couches DA
Les couches DA stockent des données sur la chaîne BTC tout en externalisant les calculs hors chaîne ou vers d'autres chaînes, visant à tirer parti de la sécurité de BTC tout en améliorant les performances.
BTC est la source de données fiable la plus robuste au monde, rendre BTC source de données de confiance devient donc une démarche naturelle. Forts du cadre théorique de @CelestiaOrg , bien que le stockage sur BTC soit très coûteux, un consensus commence à émerger autour de son rôle de couche DA. En réalité, Ordinals et tout l’écosystème des inscriptions exploitent déjà BTC comme couche DA. Presque tous les « L2 BTC » envoient des données vers BTC, mais cela reste souvent symbolique, reflétant surtout une aspiration. Voici quelques conceptions remarquables.
1. @nubit_orgNubit
Nubit est un protocole DA étendant les scénarios de disponibilité des données pour BTC, attirant l’attention grâce à un financement impliquant Bounce Finance et Domo. En résumé, Nubit organise, via un consensus PoS, une chaîne DA similaire à Celestia, et téléverse régulièrement ses propres données DA (comme les en-têtes de blocs et racines d’arbres de Merkle) sur la L1 BTC. Ainsi, Nubit est lui-même sauvegardé par la L1 BTC, tandis que Nubit vend ensuite son espace de stockage comme couche DA à d’autres utilisateurs ou chaînes Rollup (DA imbriqué). Nubit n’a pas de fonctionnalité de contrat intelligent et nécessite qu’un Rollup soit construit dessus. Lorsqu’un utilisateur téléverse des données sur la couche DA de Nubit, celles-ci passent par un consensus PoS et entrent en « confirmation douce ». Puis, après un certain temps, Nubit téléverse la racine des données sur BTC. Une fois la transaction BTC confirmée, les données initiales atteignent la confirmation finale. L’utilisateur doit ensuite téléverser un tag sur BTC pour permettre aux nœuds complets Nubit de retrouver les données originales via un arbre de Merkle.
Le consensus PoS de Nubit est initialement soutenu par le service de staking BTC de Babylon (présenté plus loin). Les utilisateurs paient les frais de stockage en BTC, pour lesquels Nubit utilise le réseau Lightning. L’absence de pont élimine les risques associés, et l’utilisateur peut annuler le canal pour un retrait d’urgence, sans interaction directe avec le réseau PoS de Nubit. Nubit ressemble ainsi à une version Bitcoin de Celestia, sans fonctions complexes de contrats intelligents, utilisant le réseau Lightning — le plus décentralisé — pour les paiements BTC, restant sobre. Bien que le réseau Lightning soit suffisamment dénué de confiance, l’expérience utilisateur laisse à désirer, rendant difficile le traitement de gros montants (problème d’épuisement des canaux d’état). La relation entre Nubit et la L1 BTC est mince : la sécurité du réseau n’est pas garantie par BTC, et les données sur BTC ne sont vérifiées que par les clients nœuds complets de Nubit.
Pourquoi les Rollups ou les données d’inscription passeraient-ils par Nubit plutôt que d’être directement téléversés sur BTC ? C’est la question cruciale à laquelle Nubit doit répondre. Un coût inférieur ne suffit peut-être pas comme moteur principal. Son avantage relatif majeur par rapport à la DA BTC serait la prise en charge par Nubit de la vérification par échantillonnage de données (DAS) pour les nœuds légers, impossible sur BTC, ce qui signifie que la vérification DA ne nécessite plus le téléchargement d’un nœud complet BTC. Pourra-t-on maintenir le consensus communautaire sur des inscriptions non entièrement ancrées sur Bitcoin ? Nubit tente de remplacer la couche DA de la L1 BTC par sa propre couche DA — moins une question technique qu’un défi colossal de consensus communautaire. Bien sûr, c’est aussi une immense opportunité.
2. @Veda_bitcoinVeda
Le protocole Veda lit des inscriptions spécifiques sur la L1 BTC, les interprète comme des requêtes de transaction, puis les exécute dans un environnement EVM hors chaîne. L’utilisateur signe avec sa clé privée BTC une transaction compatible EVM, puis la grave sous forme d’inscription sur BTC. Les nœuds EVM de Veda analysent les blocs BTC ; dès que la transaction est confirmée sur BTC, l’EVM exécute la requête, générant un changement d’état. En réalité, BTC devient ainsi la file d’attente de transactions non confirmées du EVM Veda. Toutefois, comme les performances de BTC sont bien inférieures à celles du EVM Ethereum, et que la quantité de données inscriptibles dans un bloc BTC est limitée, le EVM Veda réussira toujours à exécuter toutes les requêtes EVM envoyées sur BTC.
BTC constitue la source de données de tous les états de Veda. N’importe qui peut restaurer l’état complet du EVM en analysant toutes les requêtes Veda dans les blocs BTC. On peut donc faire confiance de façon optimiste au EVM Veda, sans hypothèse de sécurité complexe. Toutefois, Veda ne peut pas étendre les performances de BTC. On peut voir Veda comme un réseau Ethereum avec un intervalle de bloc de 10 minutes, un TPS de 5, mais disposant de dizaines de milliers de nœuds et d’une puissance de calcul PoW colossale. Il étend simplement les fonctionnalités de BTC en y ajoutant des contrats intelligents. Fondamentalement, cela ne résout pas le problème de la compétition pour les ressources.
3. @babylon_chainBabylon
Babylon est un protocole permettant à d'autres blockchains de partager la sécurité du BTC, comprenant deux composantes : un service de staking BTC et un service d’horodatage BTC. Babylon permet de staker du BTC pour fournir une garantie économique de sécurité à une chaîne PoS (similaire au restaking ETH), le processus étant entièrement cryptographique, sans nécessiter de pont ou de tiers dépositaire.
Un staker BTC peut envoyer sur BTC une transaction à deux sorties UTXO pour staker : la première sortie contient un script avec verrouillage temporel, permettant au staker de récupérer ses BTC à échéance via sa clé privée ; la seconde sortie va vers une adresse temporaire BTC dont la paire clé publique/privée satisfait la norme cryptographique « signature unique extractable (EOTS) ». Lorsqu’un staker BTC exécute un nœud d’une chaîne PoS, après avoir validé un seul bloc valide, il signe ce bloc avec la clé privée EOTS.
Si le staker (aussi validateur de la chaîne PoS) reste honnête et ne signe qu’un seul bloc valide à chaque hauteur, il reçoit la récompense du validateur. S’il triche en signant deux blocs à la même hauteur, sa clé privée EOTS peut être inversée, permettant à quiconque de transférer ses BTC mis en jeu, réalisant ainsi la confiscation. Ceci incite les stakers à rester honnêtes. Babylon fournit également un service d’horodatage BTC, consistant à téléverser les points de contrôle de n’importe quelle blockchain dans le champ op_return de BTC, renforçant ainsi la sécurité.
Le projet Nubit mentionné précédemment prévoit d’utiliser le service de staking BTC de Babylon pour renforcer sa sécurité. Babylon utilise des méthodes purement cryptographiques pour le dépôt, le retrait et la confiscation du BTC, offrant une sécurité élevée. Toutefois, pour les chaînes utilisant ce service, cela impose des contraintes économiques, restant encore éloigné de la vérifiabilité des solutions Rollup ETH. Le service d’horodatage téléverse bien les données L2 sur BTC, mais vérifier directement tous les blocs BTC nécessite un nœud complet, ce qui reste inaccessible. De plus, la L1 BTC n’ayant pas de contrats intelligents, elle ne peut pas valider la justesse de ces données.
Rollups
Les Rollups utilisent la couche données de BTC pour stocker les états et transactions, tout en traitant les calculs et modifications d’état hors chaîne, soumettant des preuves ou données de modification d’état à la chaîne principale BTC pour assurer la sécurité.
Le problème central des Rollups BTC est la vérification. Grâce aux Ordinals, Bitcoin peut stocker diverses données, devenant ainsi une base de données hautement sécurisée. Téléverser les données de preuve d’un Rollup sur le réseau BTC garantit effectivement leur immuabilité, mais ne garantit pas la validité ou l’exactitude des transactions internes au Rollup. La plupart des Rollups BTC opteront probablement pour un modèle de Rollup souverain (vérification client), où les validateurs synchronisent hors chaîne toutes les données du Rollup et les vérifient eux-mêmes. Toutefois, cela ne tire pas parti de la force maximale de Bitcoin, à savoir le consensus PoW assuré par des dizaines de milliers de nœuds, pour garantir la sécurité du Rollup. L’état idéal serait que le réseau BTC puisse activement valider les preuves du Rollup, comme sur ETH, et rejeter les données de bloc invalides. De plus, il faut garantir que les actifs du Rollup puissent être retirés de façon décentralisée vers le réseau BTC même dans les cas extrêmes — par exemple, si les nœuds ou ordonneurs du Rollup tombent en panne ou refusent les transactions, un passage de secours sécurisé doit exister. Pour BTC, qui n’a pas de contrats intelligents mais seulement des scripts, on pourrait exploiter MAST pour combiner des scripts en circuits logiques vérifiables. Bien que difficile, c’est l’approche la plus native pour BTC.
1. @ZeroSync_BitVM
BitVM est le protocole d’extension le plus attendu sur BTC, une sorte de Rollup optimiste. BitVM innove en proposant un mécanisme de défi de fraude sur BTC : le prouveur et le challenger déposent chacun une somme identique de BTC dans une même transaction (comme entrée), dont la sortie contient un circuit logique. Les scripts BTC peuvent être vus comme des portes logiques simples, les composants de base de l’informatique. En combinant ces portes logiques en structure arborescente, on forme un circuit logique spécifique (imaginez l’ordinateur humain de « The Three-Body Problem »).
BitVM encode une preuve de fraude dans un circuit composé de nombreux scripts BTC. Ce circuit est structuré selon les séries de nœuds empaquetés par l’ordonnateur du Rollup. Le challenger peut continuer à envoyer des valeurs hash vers ce circuit de preuve de fraude, le vérificateur exécute les scripts correspondants et révèle les sorties pour confirmer la justesse du résultat. Via une série de transactions, le challenger peut continuer à défier le prouveur jusqu’à ce que chaque porte du circuit soit vérifiée correcte. Ainsi, le réseau BTC complète la vérification du Rollup, et le prouveur récupère ses fonds. Sinon, le challenger remporte les BTC mis en jeu par le prouveur. Pour simplifier, la relation entre BitVM et BTC est semblable à celle entre Optimism et Ethereum, offrant le niveau de sécurité le plus élevé parmi toutes les solutions d’extension. BitVM engendre un nombre énorme de transactions, très coûteuses, et nécessite de nombreuses pré-signatures hors chaîne avant la vérification en chaîne.
Bien sûr, contrairement aux Rollups Optimistes/ZK d’ETH, BitVM ne dispose pas de canal de retrait d’urgence vers BTC. Un nœud honnête au minimum sur le réseau L2 est nécessaire pour un retrait normal. Malgré cela, c’est actuellement la garantie de sécurité la plus élevée possible pour un L2 BTC : téléversement de la DA, validation par la L1 BTC de la validité des données Rollup, pont BTC minimisant la confiance, seul manque un « passage de secours d’urgence ». L’implémentation de BitVM semble donc lointaine, mais les récentes discussions dans la communauté BTC sur le déblocage du script op_cat pourraient ouvrir de nouvelles perspectives. L’opcode op_cat permet de concaténer deux chaînes de caractères, jusqu’à 520 octets. Cette concaténation de données permet des calculs plus complexes sur Bitcoin. Par exemple, BitVM pourrait ainsi connecter des centaines de portes logiques dans un même script, traitant bien plus de circuits binaires en moins de transactions, gagnant ainsi près de 100 fois en vitesse. La combinaison complexe de scripts BTC par BitVM a également inspiré de nombreux projets L2, qui proposent désormais de nouvelles approches de « défi de fraude » sur BTC.
2. @Bison_LabsBison Network
Bison Network est un Rollup souverain ZK-STARK basé sur Bitcoin. Un Rollup souverain utilise la L1 comme tableau d’affichage des données de blocs (DA), sans vérifier la justesse des transactions du Rollup, celles-ci étant validées par les propres nœuds du Rollup. Bison soumet la preuve ZK du Rollup dans les Ordinals BTC. L’utilisateur peut télécharger la preuve depuis BTC et exécuter son propre client pour vérifier les transactions du Rollup. Pour vérifier l’état complet, une synchronisation de nœud complet est nécessaire.
La particularité de Bison réside dans la conception de son pont avec la L1 BTC. Quand un utilisateur dépose du BTC sur Bison Rollup, celui-ci est divisé entre plusieurs portefeuilles multisignatures contenant du BTC. Ces portefeuilles supportent les Contrats Log Discrets (DLC), une technologie basée sur Taproot, utilisant la multisignature BTC et des scripts de verrouillage temporel pour former de simples contrats logiques. Lors du dépôt, l’utilisateur doit signer avec le réseau Bison les transactions d’exécution futures dans tous les scénarios : a. transfert à un tiers ; b. retrait vers la L1 BTC ; c. absence prolongée de retrait. Ces transactions ne sont pas publiées sur BTC ; pour s’exécuter, elles nécessitent un oracle. Trois entités contrôlent le portefeuille multisignature : l’utilisateur, Bison Rollup et l’oracle. Deux signatures suffisent pour prendre le contrôle des BTC.
Le DLC agit comme une instruction if-do sur Bitcoin. L’oracle fournit la condition if, et l’action do consiste à envoyer l’une des trois transactions signées. L’oracle est lié au contrat de pont de Bison Rollup : s’il reçoit une demande de transfert à un tiers, il envoie la transaction pré-signée du cas a., transférant le contrôle au réseau Bison pour redistribution ; s’il reçoit une demande de retrait, il active le cas b., transférant le contrôle à l’utilisateur ; sinon, au bout du délai, le cas c. s’active, rendant le contrôle à l’utilisateur. Ainsi, Bison implémente un retrait depuis le Rollup et établit un simple passage de secours. Toutefois, le point faible réside dans l’oracle : une information erronée entraîne la perte des actifs. Une décentralisation partielle, comme avec Chainlink, pourrait être envisagée. Le « pont sans confiance » via DLC exploite pleinement le potentiel des scripts BTC. http://DLC.link l’utilise déjà pour transférer BTC vers ETH ou STX. Bien que Bison introduise un tiers externe pour un passage de secours rudimentaire, il ne parvient toujours pas à faire valider la preuve du Rollup par la L1 BTC.
3. @BsquaredNetworkB² Network
B² Network est un Rollup ZK hybride sur BTC, intégrant un mécanisme de « défi d’engagement ». Le réseau comporte deux couches : la couche Rollup et la couche DA. La couche Rollup utilise zkEVM pour exécuter la logique des contrats intelligents, comprenant plusieurs modules : réception, ordonnancement et empaquetage des transactions, génération de preuves ZK, abstraction de compte compatible adresse BTC, lecture synchronisée des données L1 BTC (soldes BTC et BRC20). La couche DA fournit le stockage des données pour le Rollup : ses nœuds effectuent une vérification zk hors chaîne des transactions Rollup. Après vérification, les nœuds DA écrivent les données Rollup dans les inscriptions Ordinals de BTC, incluant la position des données Rollup dans la couche DA, la racine de l’arbre de Merkle des transactions, les données de preuve ZK, et le hash de la précédente inscription de preuve BTC.
La vérification de la preuve est au cœur du système. Sur ETH, le contrat de pont valide directement la preuve ZK sur la L1. Sur BTC, aucune fonction de contrat intelligent n’existe, et la logique complexe de vérification ZK ne peut être implémentée par combinaison de scripts BTC (coût prohibitif, risque de dépasser la limite du bloc). B² introduit donc davantage de calcul hors chaîne, transformant la validation directe de la preuve ZK par la L1 en un mécanisme de « défi de fraude » similaire à un Rollup optimiste. B² décompose la preuve ZK en différents scripts, superposés en un arbre binaire MAST. Les nœuds B² envoient une transaction contenant du BTC comme récompense pour un défi de fraude.
Une fois la transaction contenant le « défi de fraude » confirmée sur la L1 BTC, le challenger peut télécharger les données brutes depuis la couche DA et exécuter les scripts hors chaîne. Si le résultat final diffère de celui soumis par le nœud B², cela indique une malversation, et le challenger obtient le contrôle du BTC verrouillé dans le script racine, tandis que toutes les transactions Rollup sont annulées. En l’absence de défi durant la période verrouillée, le nœud récupère son BTC et le Rollup atteint la confirmation finale.
Dans B² Network, la première transaction confirmée garantit l’immutabilité de la preuve ZK. Bien que BTC ne puisse pas valider directement la transaction ZK, le « défi de fraude » dans une seconde transaction permet indirectement une validation par la L1, assurant la validité des transactions du Rollup et renforçant la sécurité — une innovation remarquable. B² Network mérite aussi des éloges pour son abstraction de compte, permettant aux utilisateurs d’interagir avec le Rollup via leurs portefeuilles BTC sans changer leurs habitudes. Toutefois, pour le retrait d’actifs BTC depuis la L2, il utilise toujours un pont multisignature, sans implémenter de « passage de secours ».
4. @SatoshiVMSatoshiVM
SatoshiVM est également un Rollup ZK basé sur BTC, avec une logique similaire à B² Network : après génération de la preuve zk, le prouveur la téléverse sur BTC, puis envoie une transaction contenant du BTC pour un « défi de fraude », le challenger victorieux remportant la récompense. La différence réside dans l’ajout par SatoshiVM de deux verrous temporels dans le « défi de fraude », marquant respectivement le début et la fin du défi. En comparant le nombre de blocs écoulés avant le transfert du BTC, on peut facilement déterminer si la preuve ZK est correcte. Quant au pont inter-chaînes, il n’utilise qu’une solution multisignature classique, sans originalité notable.
5. @chainway_xyzChainway
Chainway est un Rollup souverain ZK sur BTC, utilisant non seulement Bitcoin comme couche de publication de données, mais aussi les données BTC comme source pour produire les preuves ZK. Le prouveur Chainway doit scanner chaque bloc BTC sans exception. Il lit l’en-tête du bloc, la preuve zk précédente, et les « transactions obligatoires » gravées dans le bloc, pour générer une preuve ZK complète. À chaque bloc BTC, Chainway soumet une transaction gravant la preuve ZK, créant ainsi une preuve récursive.
Les « transactions obligatoires » gravées sous forme d’inscription Ordinals dans les blocs BTC constituent la méthode « anti-censure » définie par Chainway. Si les nœuds Rollup tombent en panne ou refusent systématiquement les transactions de retrait des utilisateurs, ceux-ci peuvent graver directement leur demande dans un bloc Bitcoin. Les nœuds doivent inclure ces « transactions obligatoires » dans les blocs Rollup, sinon la contrainte du circuit ZK n’est pas satisfaite et la génération de preuve échoue.
Dans un récent tweet, Chainway affirme s’inspirer de BitVM et avoir trouvé une méthode pour valider la preuve ZK sur Bitcoin, permettant ainsi un règlement final sur la L1 BTC. Actuellement, Chainway repose sur la vérification locale par client souverain. Bien que les « transactions obligatoires » atténuent partiellement le problème de censure par les nœuds, elles ne permettent pas encore un véritable règlement final des actifs sur la L1 BTC.
6. @QEDProtocolQED Protocol
QED Protocol est un Rollup ZK sur BTC fonctionnant sur zkEVM. Contrairement aux autres Rollups ZK, QED ne génère pas de preuve ZK pour l’ensemble des transactions du Rollup, mais uniquement pour les transactions de retrait vers la L1 BTC. Inspiré de BitVM, QED assemble des scripts en circuits logiques afin de valider sur la L1 BTC la preuve ZK des transactions de retrait. Ces circuits logiques incluent 1000 UTXO, permettant une validation directe mais à un coût énorme.
3. L2 des inscriptions — Repenser l’extension du BTC
Après une vague spectaculaire de distribution d’actifs, le récit principal des inscriptions est désormais établi, et de nouveaux défis et opportunités se profilent. Se reposer uniquement sur la distribution équitable ou des récits « meme » semble limiter la capitalisation à environ 200 millions, un plafond difficile à franchir sans construction solide (la fin de la distribution équitable menant au PUA). Dans un retour à la rationalité, l’utilité devient primordiale : soit offrir davantage de fonctionnalités, soit servir d’actif de base.
Les sidechains « basées sur les inscriptions » pourraient représenter la prochaine étape importante. Nous les appelons sidechains plutôt que L2 car ces « L2 » n’utilisent pas la sécurité de BTC. Mais comme Polygon par rapport à ETH, les L2 d’inscriptions peuvent efficacement abaisser le seuil d’entrée pour les utilisateurs tout en trouvant un compromis avec les puristes conservateurs du BTC. Plus important encore, la capacité complète de contrats intelligents ouvrira de nouvelles dimensions aux inscriptions : DeFi, SocialFi, GameFi, etc.
BRC20 et ses nombreuses variantes inscrivent les informations de jeton dans des fichiers Json lisibles par l’homme, offrant une flexibilité extrême, permettant de diviser les inscriptions en quantités arbitraires via le champ « amt ». Cette flexibilité convient parfaitement aux interactions avec les L2 d’inscriptions : une fois que la L2 a lu le Json et reconstruit l’état BRC20, les activités DeFi et autres deviennent faciles à déployer. En tant que nouveau type d’actif distinct des FT et NFT, les L2 d’inscriptions peuvent bâtir leur activité autour des inscriptions elles-mêmes, idéalement avec des actifs natifs également sous forme d’inscription. Si une L2 d’inscription se contente de transformer les inscriptions en FT standard et de copier les modèles DeFi d’Ethereum, elle perdra en attrait, car pour les traders actuels, le trading de FT offre un rapport qualité-prix faible. L’index BRC20 est déjà un grand livre ; en lisant cet index, on peut créer une chaîne EVM prolongeant les attributs des inscriptions, et continuer à lancer de nombreuses applications innovantes différentes des paradigmes DeFi traditionnels.
Programmation orientée indexeur
Les sidechains BRC20 et autres inscriptions Json doivent-elles nécessairement suivre le modèle ETH ? En réalité, EVM semble ennuyeux ; nous n’avons pas besoin de réinventer une multitude de L2. Peut-être serait-il plus intéressant de partir des propriétés natives des inscriptions pour repenser l’extension fonctionnelle et commerciale.
BRC20 est un système de jetons basé sur un registre on-chain et un traitement off-chain, utilisant BTC comme stockage. Pour ce type d’extension, on pourrait envisager d’ajouter davantage de logique métier directement sur les serveurs d’indexation hors chaîne. Par exemple, introduire dans le champ « op » du Json de nouveaux primitives autres que « mint », « deploy » et « transfer », permettant des actions comme la mise en ordre, le prêt, la destruction ou l’autorisation. Ces combinaisons d’« op » pourraient ensuite évoluer vers des fonctions swap, prêt, voire des applications complexes de SocialFi et GameFi, formant une Inscription-Fi. C’est ce qu’on appelle la programmation orientée indexeur, analogue à la programmation des interfaces serveur en Web2. Sa mise en œuvre est simple, pouvant commencer sur un seul serveur d’indexation, mais ses effets sont immédiatement significatifs. Des projets comme UniSat (fonction swap), BRC100, ORC20 ou Tap sont déjà des pionniers de cette approche d’extension Json, capables d’apporter rapidement des changements. Introduire des primitives cryptographiques est passionnant, bien sûr, mais la décentralisation reste un enjeu permanent. La programmation orientée indexeur alourdit inévitablement les serveurs, rendant plus difficile la gestion communautaire. Les services complexes exigent un consensus fort, conduisant finalement au développement d’une plateforme de contrats intelligents. Alors, si l’on décentralise le grand livre au sein de l’indexeur, pourrait-on créer une nouvelle chaîne d’inscriptions ?
En réalité, @unisat_wallet suit précisément cette logique avec ses services postérieurs basés sur $sats : swap et pool sont implémentés directement dans son indexeur. Pour obtenir un consensus sur la sécurité des fond
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
@TrustlessLabs
