Décryptage du mécanisme B²Network : ZK+BitVM, le nouveau standard des layer 2 sur Bitcoin ?
TechFlow SélectionTechFlow Sélection
Décryptage du mécanisme B²Network : ZK+BitVM, le nouveau standard des layer 2 sur Bitcoin ?
Les solutions Rollup de la couche 2 (layer 2) dans l'écosystème Bitcoin présentent une complexité technique et des spécificités considérables.
Dédié à des analyses Web3 approfondiesRédaction : Haotian
D’Ethereum Plasma à Validium, puis aux Rollups dominants, et pour Bitcoin, des sidechains aux canaux d’état jusqu’à la vérification cliente, les couches 2 (Layer2) cherchent essentiellement un compromis équilibré entre sécurité, extensibilité et décentralisation.
Dans cette optique, j’ai comparé la solution ZK-Rollup et celle récemment très discutée de @BsquaredNetwork, en examinant notamment leurs différences et complexités techniques au niveau de la disponibilité des données (DA), de l'interopérabilité et des défis de sécurité.
Pour faciliter la comparaison, on peut établir approximativement une correspondance :
ETH Plasma = BTC Canaux d’état ; ETH Validium = BTC Sidechain ; ETH Rollup = BTC Vérification cliente.
On voit clairement que Plasma sur Ethereum correspond au réseau Lightning dans l’écosystème Bitcoin : il hérite de la sécurité de BTC, mais le contrat HTLC reste limité aux petits paiements. Validium sur Ethereum est comparable aux sidechains de Bitcoin : bien qu’offrant une forte scalabilité, leur consensus indépendant ne leur vaut pas une reconnaissance généralisée. En revanche, je considère que les Rollups Ethereum sont analogues à la vérification cliente sur Bitcoin, car ils trouvent un point d’équilibre entre sécurité, extensibilité et décentralisation — ce qui explique pourquoi les Rollups sont devenus une piste majeure sur Ethereum.
En suivant la logique des ZK-Rollups d’Ethereum, comment pourrait-on construire un Rollup Layer2 pour Bitcoin basé sur la vérification cliente ? Prenons @BsquaredNetwork comme exemple :
1) Partie vérification cliente :
Dans un ZK-Rollup complet sur Ethereum, la phase hors chaîne comprend le regroupement des transactions par le Séquenceur, puis la génération d’une preuve ZK SNARK et d’un arbre de Merkle, dont les données sont envoyées au Calldata de la chaîne principale. La preuve ZK SNARK est ensuite vérifiée par un système Prover, et la différence d’état finale (State diff) est envoyée à la chaîne principale. Celle-ci valide alors l’intégrité et la cohérence des données via la racine d’état (State root) combinée aux blocs du Calldata, aboutissant ainsi à la confirmation finale (Finality).
La partie cliente de Bsquare comprend principalement deux composantes : la couche Rollup et la couche DA. Le flux de travail de la couche Rollup est le suivant : le Séquenceur collecte et groupe les transactions, puis stocke une copie dans un environnement de stockage décentralisé. Ensuite, une preuve est générée via zkEVM, tandis que les données brutes (Raw data), l’arbre de Merkle et l’état Bitcoin sont agrégés en une preuve combinée (Aggregator Proof) et transmis ensemble aux nœuds B² de la couche DA.
Deux différences notables ici : premièrement, Bitcoin nécessite que les données brutes des transactions soient stockées dans un environnement de stockage décentralisé, là où les ZK-Rollups supposent un stockage local par défaut. Deuxièmement, Ethereum peut directement envoyer les données au Calldata de sa chaîne principale, mais le réseau Bitcoin a une capacité de stockage limitée et manque de capacité de vérification. Ainsi, Bsquare transfère ces données vers les nœuds B² dans l’environnement client.
2) Partie Disponibilité des Données (Data Availability)
Sur Ethereum, la chaîne principale assure la fonction DA pour les Rollups : envoyer les données au Calldata permet précisément à la chaîne principale de valider leur disponibilité. Comme Bitcoin ne dispose pas de telles capacités, la fonction DA est assumée par une couche DA construite dans l’environnement client.
Lorsque les nœuds B² reçoivent ces données agrégées du Rollup, ils effectuent une compilation de circuit, compressent les données, puis les inscrivent sous forme d’Inscriptions (inscriptions) sur la chaîne principale Bitcoin. Parallèlement, les nœuds B² exécutent un système Prover pour valider de manière décentralisée la preuve ZK et générer un Commitment (engagement) sur Bitcoin, qui est également gravé avec les autres données dans l’inscription.
Cela soulève deux questions :
1. Pourquoi ne pas utiliser une solution tierce comme Celestia pour la DA, plutôt que de construire sa propre couche ? Cela découle justement de la spécificité de l’écosystème Bitcoin : les nœuds B² doivent intégrer un indexeur capable d’analyser et d’indexer de façon décentralisée les inscriptions sur la chaîne Bitcoin. De plus, la preuve ZK doit être soumise sous forme de Commitment sur la chaîne principale, et les données doivent subir une pré-compilation de circuit pour être compressées avant inscription, afin de minimiser l’occupation de l’espace de stockage sur la chaîne principale.
2. Si la DA n’est pas assurée par la chaîne principale, pourquoi inscrire ces données Rollup sous forme d’inscriptions ? C’est pour conserver sur la chaîne principale un registre immuable des transactions, servant de base au processus ultérieur de contestation (Challenge).
3) Partie Contestation (Challenge)
Dans un ZK-Rollup, le contrat Rollup sur la chaîne principale peut recouper les données groupées dans le Calldata avec la différence d’état (State diff) fournie par le Prover, garantissant ainsi intégrité et cohérence — ceci grâce à la capacité native de vérification de la chaîne principale et aux avantages de la technologie ZK.
Or, dans un environnement Rollup Bitcoin, la chaîne principale n’a pas de capacité de vérification. La valeur de la technologie ZK réside donc principalement dans la compression efficace des données via SNARKs tout en assurant leur cohérence. Toutefois, si le Séquenceur hors chaîne falsifie les données dès la collecte, toute la chaîne repose sur des données erronées, et la confirmation finale ne peut rejeter ces données truquées. Il faut donc concevoir un mécanisme permettant de contester ces comportements malveillants.
Comment faire ? Si vous avez lu mon article sur BitVM, vous savez que BitVM est une proposition théorique permettant à Bitcoin d’effectuer des calculs Turing-complets. Toutefois, sa méthode de transmission des TXs via Taproot Tree consomme trop de frais de minage pour être réaliste. En revanche, emprunter la logique de mise en œuvre de BitVM pour concevoir un mécanisme de contestation change la donne.
Le mécanisme de contestation verrouille des BTC dans un UTXO sur la chaîne principale. Lorsqu’un utilisateur lance une contestation sur la chaîne Layer2 via BitVM, il peut récupérer les fonds verrouillés. Les inscriptions gravées sur Bitcoin, ainsi que les données brutes, arbres de Merkle et engagements publics des nœuds B², servent alors de preuves. Si la contestation démontre une incohérence entre les données des nœuds B² et celles inscrites sur la chaîne principale, non seulement les nœuds B² perdent leurs fonds verrouillés, mais ils doivent aussi annuler les transactions, puis mettre à jour l’indexeur et les données historiques.
En résumé,
il apparaît clairement que les solutions Layer2 Rollup dans l’écosystème Bitcoin présentent une grande complexité technique et des particularités marquées :
Par exemple, lors de la vérification cliente, toutes les données produites par le Séquenceur doivent être conservées dans un stockage décentralisé pour assurer la traçabilité ;
Par exemple, la couche DA doit implémenter un système de validation décentralisé hors chaîne, utilisant à la fois des engagements (Commitments) et des inscriptions gravées pour garantir la cohérence des données disponibles ;
Même avec l’utilisation de la technologie ZK, un mécanisme de contestation transparent et ouvert est indispensable pour assurer la sécurité. L’ensemble du processus consiste à trouver un équilibre acceptable entre décentralisation, sécurité et extensibilité. La réponse esquissée par ces explorations est claire : puisque la chaîne principale Bitcoin ne peut ni valider ni assurer la DA, on utilise les inscriptions pour graver une DA limitée sur la chaîne principale, complétée par un système de contestation Turing-complet basé sur les circuits BitVM, afin d’assurer transparence et sécurité du Rollup. On compense ainsi, via la technologie ZK et le système de contestation BitVM, les lacunes de Bitcoin en matière de DA et de vérification.
Après tout, même les Rollups Ethereum présentent encore des risques — comme la gouvernance par contrat multisignatures pouvant être mis à jour — et ne garantissent pas une sécurité absolue. Ce en quoi croit la communauté, c’est surtout un mécanisme d’interaction contractuel relativement transparent et ouvert. Alors même si on ne peut pas atteindre la sécurité absolue du consensus BTC, face à nous se tient désormais un mécanisme de contestation transparent et ouvert fondé sur BitVM. Bien que plus complexe techniquement, la logique tient debout. En somme, si ce paradigme Bitcoin Layer2 — combinant technologie ZK, vérification cliente, gravure DA et système de contestation BitVM — gagne progressivement l’adhésion du marché, pourrait-il devenir le nouveau standard des Rollups Bitcoin ?
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
Haotian | CryptoInsight
