Comment définir une couche 2 (L2) pour Bitcoin, ainsi qu'une L2 sous une perspective d'inclusivité ?
TechFlow SélectionTechFlow Sélection
Comment définir une couche 2 (L2) pour Bitcoin, ainsi qu'une L2 sous une perspective d'inclusivité ?
Le marché ne se définit pas seulement selon une perspective technologique, mais surtout selon une perspective écologique.
Dédié à des analyses Web3 approfondiesRédaction : jolestar
La récente controverse autour de la définition des L2 Bitcoin par Bitcoin Magazine a ravivé le débat sur ce qu’est véritablement un L2 Bitcoin. Ce genre de discussion a déjà eu lieu auparavant dans la communauté Ethereum. Alors, comment définir précisément un L2 ? On peut analyser cette question selon deux angles : technique et écosystème. Personnellement, je préconise une vision inclusive du concept de L2.
Définition technique d’un L2
D’un point de vue technique, il s’agit de distinguer clairement un L2 d’un L1 ou d’une solution centralisée. Deux critères me semblent essentiels :
1. Un L2 ne crée pas d’espace bloc supplémentaire. Toute technologie générant de nouveaux espaces bloc relève fondamentalement d’un L1.
2. Un L2 doit exploiter le L1 pour assurer la disponibilité des données et la sécurité. Les solutions créant un nouvel espace bloc sont par essence des L1.
Cependant, le marché ne se limite pas à une définition purement technique ; il adopte surtout une perspective écosystémique.
Définition écosystémique d’un L2
Dans une optique écosystémique, on examine comment un L2 utilise ou hérite des fonctionnalités offertes par le L1. Prenons l’exemple du Bitcoin et explorons les axes d’héritage et d’extension possibles.
Actifs BTC
C’est le scénario que tous les L2 cherchent à raconter : comment donner de nouvelles utilisations aux actifs BTC à l’échelle du trillion, que ce soit pour le trading ou le staking, offrant ainsi un large potentiel. Pour transférer des actifs d’un système blockchain vers un autre, un pont est nécessaire. La question centrale devient alors : comment inspirer la confiance dans ce pont tout en garantissant la sécurité des actifs ?
Sous cet angle, toute solution créant de nouveaux cas d’utilisation pour les actifs BTC via un pont peut être considérée comme un L2 Bitcoin. Même un ETF BTC pourrait être vu comme un L2 Bitcoin — un pont entièrement centralisé reposant sur la régulation légale pour assurer la sécurité. Ce qui préoccupe donc les gens n’est pas tant la décentralisation que la confiance. Les solutions décentralisées réduisent le coût de confiance pour les utilisateurs et ouvrent des opportunités aux nouveaux projets, mais concevoir un pont décentralisé sécurisé sur Bitcoin reste un défi majeur. Comment un L2 peut-il tirer parti des autres caractéristiques de Bitcoin pour renforcer la sécurité de ce pont ?
Par ailleurs, avec le développement des protocoles d’extension sur Bitcoin — Ordinals et ses protocoles dérivés (comme BRC20), Atomicals, RGB ou Taproot Assets — les nouveaux types d’actifs sur Bitcoin se multiplient. Concevoir un pont extensible, capable de supporter rapidement de nouveaux types d’actifs, constitue également un défi important.
Espace bloc Bitcoin
Bitcoin, réseau blockchain parmi les plus décentralisés, n’a pas encore pleinement exploité la valeur de son espace bloc. Le phénomène récent des inscriptions Ordinals peut être interprété comme une découverte de la valeur de Bitcoin en tant que couche de disponibilité des données (DA). Le protocole Ordinals définit un format de données extensible et normalisé, permettant une interprétation, une présentation et un échange uniformes des données gravées sur Bitcoin.
Comment les protocoles d’extension et les L2 sur Bitcoin peuvent-ils exploiter efficacement cet espace bloc ? C’est une piste d’exploration importante.
Capacité de programmation du réseau Bitcoin
Le langage Bitcoin Script offre des capacités limitées. Sa programmabilité des actifs repose principalement sur trois types de verrous : verrou temporel, verrou hash et verrou de clé privée. Grâce au Taproot, la complexité de Bitcoin Script peut augmenter significativement, rendant possible des solutions comme BitVM. Toutefois, le défi principal réside dans le fait que Bitcoin Script est sans état : il ne peut ni lire ni accumuler l’état de Bitcoin, mais seulement s’appuyer sur les entrées. Exploiter les scripts Bitcoin pour implémenter un mécanisme d’arbitrage reste donc un domaine à explorer.
Un autre axe concerne l’innovation cryptographique, notamment les protocoles basés sur l’échange de clés pour construire des mécanismes de jeu garantissant la sécurité, comme le Lightning Network. Babylon, avec sa « signature unique extractable », suscite aussi un grand intérêt, même si ses détails techniques restent non publiés.
État de Bitcoin
L’état de Bitcoin comprend plusieurs éléments :
1. Horodatage de Bitcoin
2. Nombre aléatoire (nonce) des blocs Bitcoin
3. UTXO de Bitcoin et leur propriété
4. Blocs de Bitcoin, ainsi que les nouveaux actifs et informations ajoutés aux UTXO
Nous pouvons utiliser ces dimensions pour analyser comment différents protocoles d’extension Bitcoin et projets L2 étendent les capacités de Bitcoin.
Comment étendre Bitcoin ?
Pont + environnement programmable
Étant donné les limitations inhérentes à la programmabilité de Bitcoin, une approche consiste à transférer les actifs Bitcoin vers un environnement plus programmable, comme une machine virtuelle EVM, afin d’ouvrir de nouveaux cas d’utilisation. Des projets comme BEVM ou Merlin illustrent cette voie. L’enjeu principal réside dans la conception du pont : 1. Le L2 peut-il tirer parti de la sécurité offerte par le L1 ? 2. La solution de cross-chain est-elle extensible ?
Ajout d’une couche de contrats intelligents sur Bitcoin
RGB exploite la caractéristique des UTXO de Bitcoin (utilisables une seule fois) pour mettre en œuvre un mécanisme de scellement unique. Il utilise également l’espace bloc de Bitcoin pour publier des engagements de transaction, offrant ainsi un environnement de programmation hors chaîne (offchain). Son avantage réside dans sa compatibilité parfaite avec le modèle UTXO, son indépendance vis-à-vis de l’état global et sa préservation de la confidentialité. Mais cela constitue aussi une limite, car cela restreint les scénarios de programmation. Dans cette direction, CKB avec RGB++ fait des compromis sur certaines caractéristiques de RGB, en proposant des modèles de programmation plus riches grâce au modèle cellulaire.
Calcul Offchain en mode Indexer
Le modèle d’indexation des inscriptions (« indexer ») peut être vu comme un modèle de calcul hors chaîne. Les actifs sont définis sur chaîne, mais leur validité est assurée par un calcul hors chaîne, tout en permettant un état global. Les inscriptions peuvent être perçues comme des actifs intermédiaires entre L1 et L2. Si le protocole inclut un mécanisme de migration intégré entre L1 et L2, cela permettrait la circulation des actifs entre les deux couches. En outre, si la logique de génération et de vérification des actifs inscrits est elle-même gravée sous forme de code sur Bitcoin, cela constitue aussi une extension de la capacité de programmation de Bitcoin, comme dans le cas de Bitseed.
L2 empilable (Stackable L2)
En utilisant des contrats intelligents pour implémenter un indexeur de protocole d’extension Bitcoin, on peut analyser tous les UTXO et états annexes présents sur Bitcoin, tout en autorisant les développeurs à déployer des applications via des contrats intelligents dans cet indexeur. Cela revient à ajouter une nouvelle couche de contrat intelligent à Bitcoin — c’est précisément la proposition de Rooch.
J’avais précédemment appelé ce modèle « Smart Indexer », mais le terme « indexeur » évoque trop souvent une lecture seule. J’introduis donc un nouveau terme : « Stackable L2 », désignant toutes les solutions d’extension où le L2 contient l’état complet du L1, héritant pleinement de tous ses états. Dans ce cas, les applications du L2 peuvent lire tous les états du L1 tout en créant de nouveaux états. Les actifs du L1 et du L2 peuvent être combinés en pile pour former de nouveaux actifs. La sécurité du L2 peut être assurée via une architecture modulaire. Je développerai davantage ce concept dans un prochain article.
En réalité, ces différentes approches peuvent être combinées entre elles.
Une vision inclusive du L2
Si l’on s’affranchit des détails d’implémentation et que l’on considère le concept de L2 de manière abstraite, on découvre qu’il forme plutôt un spectre continu : allant du CEX (extrême gauche) au L1 (extrême droite), toutes les solutions intermédiaires peuvent être incluses dans ce spectre. Les extrémités de ce spectre représentent deux modes de croissance distincts. Les CEX suivent une trajectoire fortement orientée produit et utilisateur, tandis que les L1, dont le cycle de construction est long, misent avant tout sur la narration et la vision stratégique. Les L2, situés au milieu, incarnent une croissance hybride.
Adopter une vision inclusive nous dispense de nous attarder excessivement sur la question du « vrai L2 ». Les nombreuses innovations techniques et solutions créées par l’industrie — Validium, Plasma, rollups souverains, rollups Op/Zk, couches d’exécution modulaires, compute décentralisé, sidechains, L2/L3, etc. — doivent toutes être considérées comme faisant partie de ce spectre. L’industrie explore activement, par combinaisons multiples, les infrastructures nécessaires aux nouvelles applications.
Les hypothèses variées des différents projets concernant les futures applications déterminent leurs choix d’assemblage et leurs modèles de croissance — certains pencheront légèrement vers le L1, d’autres vers le CEX. L’avenir reste incertain, et à ce stade, il est difficile de prédire quel modèle émergera. Une chose est sûre toutefois : après des années d’expérimentation, l’industrie dispose désormais de L1 à grande échelle et de CEX à grande échelle, et elle a besoin d’une couche intermédiaire tout aussi massive pour combler ce fossé.
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
@jolestar
