Nouvelle narration de l'histoire des couches 2 du BTC : principes de conception centrés sur les Rollups
TechFlow SélectionTechFlow Sélection
Nouvelle narration de l'histoire des couches 2 du BTC : principes de conception centrés sur les Rollups
La version Bitcoin centrée sur les Rollup repose essentiellement sur la garantie que la valeur et la sécurité du BTC puissent être transférées vers les Rollup.
Dédié à des analyses Web3 approfondiesRédaction : Zuo Ye
La voie de mise à l'échelle du Bitcoin n'est pas équivalente à une couche 2 (L2) du BTC.
Au début de l'année, j'ai résumé la trajectoire technologique des L2 du BTC, principalement divisée en deux parties : la montée en puissance de la sécurité et de la valeur du BTC d'une part, et la descente vers l'exécution des transactions sur L2 et leur finalisation d'autre part. En seulement moins de trois mois, le nombre de projets L2 du BTC a atteint près de cent. Pourtant, certaines questions fondamentales restent floues, et la première étape consiste à clarifier les définitions.
Dans l’histoire du développement du Bitcoin, trois approches pratiques ont longtemps coexisté pour la mise à l’échelle. La première est la mise à jour du réseau principal (mainnet), comme SegWit ou Taproot. La deuxième concerne les solutions hors chaîne, telles que la vérification côté client, le réseau Lightning ou les sidechains. Enfin, la troisième voie consiste en un fork direct, comme Dogecoin, BSV ou BCH.
Choix stratégiques pour la mise à l'échelle du Bitcoin
Entre ces différentes options complexes, il est difficile de définir clairement ce qu’est une véritable L2 du BTC. En m'inspirant de l'évolution d'Ethereum, je propose ici deux critères essentiels :
-
Une L2 doit d'abord être une blockchain autonome capable de gérer indépendamment le calcul et l'exécution des transactions, puis soumettre leurs résultats au Bitcoin pour règlement final ;
-
La sécurité de la L2 doit être entièrement garantie par la couche 1 (L1), sa valeur sous-jacente reposant sur le BTC, et son jeton natif ne doit pas interférer avec les fonctions du BTC.
Selon ces critères, ni les mises à jour du mainnet ni les forks ne relèvent du concept de L2. Il convient donc de se concentrer sur la classification des solutions hors chaîne. Par exemple, le réseau Lightning constitue un cas particulier : c’est un « canal » qui ne peut guère être considéré comme une blockchain publique à part entière. Quant aux sidechains, elles disposent de leur propre consensus et fonctionnement, mais leur sécurité n’est pas strictement équivalente à celle du Bitcoin. Toutefois, la véritable L2 devrait émerger de cette catégorie. Poursuivons donc notre analyse.
L2 du BTC = Réseau Lightning + Sidechains.
D'après les critères précédents, une L2 du BTC devrait être un produit hybride combinant les avantages du réseau Lightning — dépendance totale au mainnet Bitcoin — et ceux des sidechains — fonctionnement indépendant. Autrement dit, retenir le meilleur des deux mondes tout en évitant leurs inconvénients.
Ainsi, les solutions actuelles de L2 du BTC doivent encore évoluer, notamment en tenant compte du fait que le modèle UTXO du Bitcoin est incompatible avec les mécanismes de contrats intelligents nécessaires aux L2. Le Bitcoin ne permet pas d’annuler une transaction passée, ce qui oblige les L2 à résoudre ce problème elles-mêmes, soit via des mises à jour hors chaîne, soit grâce à des mécanismes d’indexation externes.
Ensuite, l’autonomie excessive de certaines L2 pose problème : certaines se contentent de stocker l’en-tête des blocs Bitcoin comme preuve de synchronisation entre L2 et L1, ou bien utilisent les scripts Bitcoin uniquement pour y inscrire les données de règlement (DA), sans envisager la récupération ou la vérification ultérieure de ces informations.
La situation actuelle des L2 du BTC est propice aux abus, menaçant la sécurité et la confiance. Je pense qu’il faut passer d’une vision centrée sur les L2 à une nouvelle phase centrée sur les Rollups : tirer pleinement parti de la sécurité du mainnet Bitcoin tout en résolvant les problèmes de calcul à grande échelle.
L2 du BTC ≠ Rollup.
-
Construire un système PoS sur le BTC pour assurer la sécurité, avec un accès sans permission et un mécanisme de destruction, différent des systèmes actuels basés sur des actifs emballés (wrapped assets).
-
Les rendements du stake doivent être exprimés exclusivement en BTC, et le jeton du projet ne doit pas entrer en conflit fonctionnel avec le BTC.
-
La couche de calcul du Rollup doit répondre simultanément aux besoins de traitement à grande échelle et de confidentialité, en utilisant la cryptographie pour contrer les tendances centralisatrices.
-
Le Rollup ne doit pas construire une couche DA supplémentaire, mais utiliser strictement le Bitcoin comme solution de disponibilité des données (DA).
Pour résumer, un Rollup idéal utiliserait le BTC comme frais de gaz natifs et récompenses de staking, exploiterait un mécanisme de double ancrage (2WP) pour permettre la circulation inter-chaînes, et diffuserait un actif xBTC fidèlement indexé 1:1 entre les L2 du BTC et les ponts inter-L2. Grâce à la computation confidentielle et aux preuves ZK, il garantirait l’anonymat complet et la vie privée des utilisateurs dès l’origine et tout au long du processus. Le jeton du projet participerait au fonctionnement du Rollup sans entrer en conflit avec le rôle du BTC.
Un Rollup ressemble à un pont, à une chaîne, et aussi à une L2
Fonctionnement d’un BTC Rollup
Il faut d’abord libérer nos esprits : combiner un socle PoW avec une couche supérieure PoS constitue actuellement la meilleure solution. Les revenus du staking dépendent du soutien de la valeur sous-jacente, et les progrès techniques viennent davantage de l’intégration ingénierie que d’innovations radicales. Débattre entre ZK et OP n’a plus grand sens. Le stockage des résultats n’est pas synonyme de disponibilité des données (DA). Par ailleurs, il est inutile de trop s’acharner sur les designs centralisés ou décentralisés : aucun système ne peut rivaliser avec le Bitcoin en termes de décentralisation. Même dans le cas d’Ethereum OP, les mécanismes réels de preuve de faute et de récupération sont encore théoriques ou en cours de route, et seront probablement pilotés par l’équipe du projet, à court ou long terme.
Par conséquent, un design plus pertinent consiste à limiter autant que possible l’intervention humaine via des moyens techniques, tout en assurant une stabilité durable du projet. Dans les L2 d’Ethereum, on parle de retraits forcés (forced withdrawals) et de capsules d’évacuation (escape hatches), garantissant la sécurité des fonds des utilisateurs même en cas d’arrêt du projet. Pour un BTC Rollup, la difficulté réside dans la capacité à retourner les actifs mappés vers le mainnet Bitcoin lors d’un dysfonctionnement, ainsi que dans la protection de la confidentialité pendant les calculs du Rollup, surtout durant ses premières phases peu décentralisées.
Examinons d’abord le premier point : les actifs mappés du BTC, tels que les versions décentralisées de WBTC. Ils doivent circuler sur le Rollup tout en assurant la sécurité. D’un côté, l’entrée du BTC soutient la valeur du Rollup ; de l’autre, le BTC du Rollup doit pouvoir être rapatrié sur le mainnet en cas de panne.
Les solutions existantes sont essentiellement des variantes de ponts inter-chaînes, différenciées selon qu’il s’agit de ponts de communication, d’actifs ou de ponts centralisés. À ce jour, il semble difficile d’imaginer de nouvelles solutions. Le pontage des actifs constitue la première étape vers la construction d’un système PoS.
Toutefois, des innovations restent possibles dans le staking et les rendements associés. On pourrait par exemple sauter l’étape représentée par Lido et adopter directement la technologie DVT (Distributed Validator Technology) pour construire un système de staking pleinement décentralisé. Ou encore, s’appuyer sur le BTC, WBTC ou le BTC recomposé émis par BounceBit pour créer un système hybride de staking recomposé, afin de réduire l’impact sécuritaire sur le BTC en période de crise.
Après le pontage et la mise en place du DVT ou d’un système de staking hybride, la couche de calcul du Rollup reste longtemps négligée. Or, elle doit être capable de gérer seule quatre phases clés d’une blockchain publique : débit de données, mise à jour d’état, stockage des résultats et diffusion des données. Deux aspects méritent d’être discutés : l’efficacité et la confidentialité.
-
L’efficacité est facile à comprendre : par exemple, via des mécanismes parallèles ou concurrents. Une fois passé l’euphorie initiale (FOMO), les Rollups Bitcoin devront rivaliser en efficacité avec ceux d’Ethereum, et l’accélération a déjà été prouvée efficace par Solana.
-
Le problème de la confidentialité est souvent ignoré. Bien que le mécanisme PoW du Bitcoin rende toute censure presque impossible, les Rollups, dans leurs débuts, risquent de connaître le même sort que les systèmes PoS d’Ethereum : certains nœuds peuvent être soumis à ou coopérer avec des mécanismes de censure. Cette question ne peut être résolue par un simple design décentralisé — aucune solution ne peut égaler le PoW du BTC. Il faut donc recourir à la computation confidentielle.
Enfin, il y a la question de la disponibilité des données (DA). Selon le critère utilisé pour distinguer les L2 d’Ethereum et les Rollups, toute solution n’utilisant pas le mainnet comme couche DA ne peut être qualifiée de Rollup. Cela touche à la promesse finale de sécurité. Si une L2/Rollup renonce volontairement à la sécurité offerte par la L1, elle doit être exclue. En raison du fonctionnement spécifique du BTC, un design complémentaire est nécessaire.
Mécanismes de DA
-
L’usage combiné de validation optimiste et de preuves ZK devient dominant : les transactions du Rollup sont finalement confirmées par le mainnet. La preuve de fraude suit un mécanisme optimiste — confirmation préalable, vérification ensuite, activation après délai. Pour la génération des preuves, le ZK permet une forte compression des données, particulièrement cruciale pour les Rollups BTC, car l’espace sur Bitcoin est extrêmement coûteux.
-
Le mécanisme d’inscription (inscriptions) peut jouer un rôle accru au niveau des transactions. Sur les Rollups ETH, si une preuve de fraude est contestée et acceptée par Ethereum, le mainnet confisque les actifs mis en jeu par le soumissionnaire. Mais sur un BTC Rollup, cette confiscation doit se faire hors chaîne, car un script Bitcoin, une fois écrit, ne peut être modifié. Seule une mise à jour (Update) est possible via un nouvel enregistrement dans un nouveau bloc ; une réécriture (Overwrite) est impossible.
-
Le réseau d’indexeurs doit assumer la charge des mises à jour des transactions et doit être décentralisé.
En conclusion, nous pouvons maintenant concevoir l’architecture complète d’un BTC Rollup en quatre étapes : xBTC → staking → calcul → DA. Les principaux défis portent sur la conception du système de staking et des actifs mappés, la confidentialité des calculs sur chaîne, et la conception finale de la couche DA.
En outre, conformément au principe selon lequel le jeton du projet ne doit pas entrer en conflit avec le BTC, celui-ci devrait jouer un rôle à l’intérieur du Rollup, par exemple dans la construction du système DVT, la maintenance décentralisée des indexeurs, ou encore dans le développement de l’écosystème et le gouvernance.
Grande vision : comparaison transversale et verticale des L2 du BTC
Explication de l'architecture
Si l’on applique mes critères stricts du Rollup, de nombreux projets seraient exclus de la discussion. J’élargis donc le champ pour inclure ceux qui présentent certaines caractéristiques mentionnées, afin de permettre une évaluation intuitive.
Suivant les quatre étapes décrites, comparons brièvement les principales solutions technologiques actuelles. Il convient de noter que chaque étape dépend de la précédente, mais nous supposerons que les conditions préalables sont remplies et ne les répéterons pas. Par exemple, après le pontage vient le staking : lorsqu’on parlera du staking, on ne reviendra pas sur les modalités du pontage, et ainsi de suite.
En matière de pontage d’actifs, ZetaChain et Zeus Network correspondent le mieux aux standards. Le premier relie l’écosystème Bitcoin à celui compatible EVM, le second à l’écosystème Solana. Leurs implémentations présentent toutefois quelques différences.
ZetaChain a créé un standard ZRC-20 similaire au ERC-20, permettant un mapping 1:1 du BTC en zBTC. Pour renforcer son concept « Omni-chain », zBTC dispose d’un mécanisme d’échange interne et n’est pas réellement transféré vers la chaîne cible, transformant ainsi zBTC en un actif omniprésent. Ce type d’actif mappé exige un design mécanique solide : ZetaChain utilise des observateurs (observers) et des signataires (signers) pour surveiller les transactions et événements sur la chaîne Bitcoin, et atteindre un consensus sur ZetaChain, permettant ainsi l’interaction avec des blockchains sans contrats intelligents comme Bitcoin.
Théoriquement, ZetaChain est un pont inter-chaînes universel, allant au-delà de la connexion entre Bitcoin et l’écosystème EVM. Ici, l’accent est mis sur la manière dont des blockchains sans contrats intelligents comme Bitcoin peuvent intégrer l’environnement EVM. On constate que ZetaChain est à la fois un pont de messages et un pont d’actifs.
Zeus Network, quant à lui, affirme être une couche de communication plutôt qu’un pont inter-chaînes. Son design fournit une interface standardisée permettant à différentes blockchains d’échanger informations et valeurs.
Par exemple, verrouiller du BTC sur une adresse Bitcoin spécifique et libérer un actif équivalent sur Solana, permettant non seulement le transfert effectif du BTC, mais aussi l’exécution de contrats intelligents sur Solana, influençant ainsi les comportements sur le réseau Bitcoin.
On perçoit ici une nuance sémantique : théoriquement, aucun transfert réel d’actifs n’est nécessaire entre deux chaînes, mais en pratique, on ne peut pas non plus transférer réellement du BTC sur Solana. Ponts d’actifs ou d’informations, tous nécessitent l’intervention d’un tiers pour la communication et l’appel mutuel. La différence réside simplement dans le degré d’implication.
Une fois les actifs pontés, un système de staking apparaît. Le staking vise à imiter la promesse de sécurité du réseau ETH, à travers quatre mécanismes : Stake, LSDFI, Restake et LRTFi. Tous reposent sur le principe que le staking sécurise le mainnet, et que des jetons équivalents participent à la DeFi pour générer des rendements, avec des niveaux variables de complexité (« mise en abyme »).
Dans la pratique Bitcoin, Merlin Chain incarne le système de staking, tandis que BounceBit représente le LRTFi. Leur objectif commun est d’inciter les utilisateurs à conserver leurs actifs dans leur écosystème, non pas simplement pour générer des intérêts, mais pour étendre les frontières de l’écosystème tout en préservant la sécurité — une ère d’utilisabilité commence à poindre.
Outre ses stratégies agressives, Merlin Chain développe activement son écosystème grâce à un système multisignature sur le L1 BTC et des contrats intelligents sur le L2, créant ainsi des scénarios d’utilisation sur L2 comme Merlin Swap, Merlin Starter, etc. Actuellement, c’est probablement la L2 la plus dynamique. Issue du même moule que ZKFair sur ETH, tous deux produits de Lumoz, elle collabore avec Cobo pour construire un système de gestion d’actifs sur L2, avec une TVL de 3,6 milliards de dollars, l’un des plus élevés.
BounceBit va plus loin — ou peut-être recule davantage.
Son progrès réside dans la création d’actifs re-stakés via des plateformes d’échange : les utilisateurs déposent du BTC sur Binance, obtiennent un actif emballé sur BNB Chain, et peuvent participer à des activités CeFi et DeFi. Grâce à la technologie de custody, BounceBit émet des actifs LRTFi tout en conservant le BTC, et construit un environnement compatible EVM connecté au monde on-chain.
Dans le fonctionnement global, les CEX et le custody sont fondamentaux. Ce qui distingue BounceBit, c’est de relancer la liquidité du BTC verrouillé, l’intégrant dans une logique d’appréciation d’actifs. Sa TVL atteint 700 millions de dollars, et permet de staker à la fois du BTC et son propre jeton. Son approche repose sur davantage de mesures centralisées pour réduire les risques liés au BTC.
Mais cela constitue seulement une légère amélioration de WBTC, voire non éprouvée à long terme, et sa sécurité pourrait bien être inférieure à celle du vétéran WBTC.
Vient ensuite la phase de calcul on-chain, où deux problèmes se posent : la centralisation de l’ordonnanceur (sequencer) et sa décentralisation, puis les questions de compatibilité et d’efficacité du calcul.
La centralisation du sequencer est un mal chronique des L2 ETH. Un sequencer centralisé améliore fortement l’efficacité, limite les attaques MEV et améliore l’expérience utilisateur. Mais cela entraîne un fort risque de centralisation, faisant du projet l’entité de facto en charge du réseau.
B² Network tente d’utiliser son jeton natif BSQ pour construire un réseau de séquenceurs décentralisés, équivalent à un réseau incitatif nécessitant plusieurs rôles — soumissionnaires, validateurs, challengers — pour maintenir le système, réduisant ainsi la centralisation par une gouvernance plus complexe.
La compatibilité EVM ou SVM est relativement facile à obtenir, mais la communication inter-L2 est plus complexe. L’efficacité du calcul requiert des approches massives de parallélisation ou de concurrence, mais aucun projet marquant n’est encore visible.
Quant à la protection de la vie privée dans le calcul on-chain, bien que des solutions ZK-Rollup existent, elles servent principalement à compresser les données, surtout au moment de la publication DA. Aucun projet notable ne se concentre spécifiquement sur la confidentialité du processus de calcul.
Enfin, concernant la publication des données DA, il faut l’analyser conjointement avec le mécanisme ZK. Contrairement aux L2 ETH, les L2 BTC utilisent le ZK principalement pour compresser les données — Bitlayer en est un exemple.
Bitlayer adopte un mécanisme de validation optimiste pour réduire la complexité, compresse les données via ZK, et les inscrit de manière similaire aux inscriptions. En pratique, les lots de transactions sont présumés valides sauf preuve du contraire. Cela permet un traitement rapide hors chaîne, suivi d’un envoi compressé sur le réseau Bitcoin, réduisant charge et coût. En cas de fraude, un participant peut lancer un défi, provoquant un rollback d’état et la sanction du malveillant, assurant ainsi la sécurité.
Cependant, construire un mécanisme de rollback d’état basé sur Bitcoin n’est pas simple et exigera encore de longues recherches.
Conclusion
Partant des solutions de mise à l’échelle du Bitcoin, j’ai tenté de dessiner à quoi devrait ressembler une architecture centrée sur les Rollups à la manière Bitcoin. L’enjeu central est de transférer la valeur et la sécurité du BTC vers le Rollup, tout en se distinguant clairement des schémas actuels d’actifs emballés. Sur le plan technique, les approches basées sur le pontage d’actifs et les systèmes de staking sont devenues des choix communs. Toutefois, la manière de garantir la décentralisation et de bien articuler les rôles du BTC et du jeton du projet reste floue.
Néanmoins, la voie centrée sur les Rollups reste aujourd’hui la plus aboutie, bien plus mature que les solutions basées sur le modèle UTXO ou la vérification côté client. Au milieu, deux points clés émergent : la computation confidentielle et la décentralisation du sequencer. Enfin, pour la couche DA, les inscriptions offrent déjà des pistes inspirantes. Le seul vrai frein demeure le coût.
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
@zuoyeweb3
