Le premier coup de tonnerre du marché haussier : les L2 de BTC couronneront le roi de l'alpha
TechFlow SélectionTechFlow Sélection
Le premier coup de tonnerre du marché haussier : les L2 de BTC couronneront le roi de l'alpha
Cet article dresse un état des lieux des méthodes mises en œuvre par les principaux réseaux Layer 2 (L2) du marché pour le BTC, ainsi que de la manière dont ils intègrent l'actif BTC et assurent la sécurité.
Dédié à des analyses Web3 approfondiesAuteur : blockpunk
Comme mentionné dans le précédent fil Twitter, le développement massif des « inscriptions » a stimulé la prospérité de l'écosystème BTC, mais a également accru la concurrence pour les ressources du réseau BTC. Les coûts élevés des frais, combinés à la hausse prévisible du prix du BTC à l'avenir, augmentent continuellement la centralisation d'accès aux acteurs de l'écosystème BTC.
Cela pousse de plus en plus de personnes à discuter activement des solutions de mise à échelle pour BTC, attirant ainsi l’attention de la communauté et des investisseurs.
-
Naturellement, tout le monde s’accorde à observer les solutions de mise à échelle par amélioration directe de la couche L1 du BTC. La discussion la plus audacieuse consiste simplement à lever certaines restrictions sur les scripts OP, afin d’exploiter davantage le potentiel résiduel de BTC sous Taproot (comme les discussions autour de CTV et CAT).
-
Face aux avancées et résultats théoriques des rollups et mises à niveau d’ETH, les projets de couche 2 (L2) pour BTC sont devenus le sujet dominant des débats sur la scalabilité, offrant aussi la solution la plus rapide à mettre en œuvre. Des projets grand public devraient être lancés dans les deux ou trois mois à venir, devenant inévitablement le principal moteur spéculatif.
En raison de la forte centralisation de la gouvernance du BTC — il n’existe aucun « clergé » pour guider la communauté — ses conceptions de L2 sont extrêmement diversifiées. Cet article examine quelques protocoles emblématiques de L2 sur BTC afin d’explorer les possibilités de mise à échelle.
Ici, j’ai globalement classé les L2 du BTC en catégories telles que sidechains, rollups, couches DA (disponibilité des données), et indexation décentralisée, regroupant les projets similaires. Toutefois, les solutions de mise à échelle du BTC ne peuvent pas encore être strictement définies, et ma classification pratique reste approximative.
-
Cet article adopte une approche centrée sur les réalisations techniques ; beaucoup de ces projets en sont encore au stade conceptuel. Sur le plan de la compétition entre actifs de couche 2, la technologie et la sécurité déterminent le plancher du projet. La technologie est un billet d’entrée, qu’il soit en première classe, en économie ou même accroché à l’extérieur — tant qu’un actif atteint un seuil minimal, il peut faire l’objet de spéculation.
-
Du point de vue de l’actif lui-même, deux aspects sont cruciaux : premièrement, la capacité de la L2 à créer des actifs, qu’il s’agisse d’introduire des inscriptions ou de manipuler artificiellement les prix, ce qui ne peut pas être évalué uniquement au niveau technique ; deuxièmement, sa capacité à attirer le dépôt de BTC depuis la L1, ce qui constitue le critère fondamental de comparaison. Cela repose fortement sur la sécurité du pont, car « pas mes clés, pas mon Bitcoin » est un dogme fondamental, étroitement lié à la conception du système.
L’écosystème BTC finira-t-il par surpasser celui d’ETH ? Cet article pourrait vous fournir quelques éléments de réponse.
Avant tout, présentons brièvement les innovations préalables permises par la mise à jour Taproot :
-
La signature Schnorr introduit sur BTC une méthode de multisignature pouvant inclure jusqu’à 1000 participants, formant la base technique de nombreux ponts L2 ;
-
MAST permet de combiner via un arbre de Merkle les scripts d’un grand nombre d’UTXO, rendant possible une logique plus complexe, ouvrant ainsi la voie aux systèmes de preuve sur L2 ;
-
Tapscript améliore les scripts de Bitcoin, autorisant une série de scripts de vérification pour déterminer si un UTXO peut être dépensé, rendant possibles des opérations comme les retraits ou les sanctions sur L2.
I. Sidechains
L’avantage des sidechains réside dans leur rapidité de déploiement et leur capacité à développer rapidement des fonctionnalités. Leur sécurité dépend essentiellement de leur propre réseau, ce qui les place comme un simple « passager accroché » au train de sécurité du BTC. Le point critique est le pont cross-chain, unique lien avec BTC.
BEVM
En réalité, la plupart des L2 BTC suivent, comme BEVM, l’approche des sidechains popularisée par ETH.
BEVM exploite Taproot pour déployer sur la L1 BTC une adresse multi-signatures, exécutant parallèlement une sidechain EVM, où un contrat intelligent gère les demandes de retrait de BTC. Le gaz sur BEVM utilise le BTC transféré via le pont.
Au dépôt, les opérateurs du pont synchronisent les données BTC et notifient la sidechain ; les nœuds BEVM exécutent aussi un client léger pour valider les en-têtes des blocs BTC. Au retrait, les gardiens du pont signent la transaction, et une fois le seuil de signatures atteint, le retrait est effectué. Ce mécanisme assure l’interopérabilité d’actifs entre sidechain et BTC.
Contrairement aux anciennes solutions comme $RSK ou $STX, BEVM utilise les multisignatures Taproot pour implémenter une signature seuil, ce qui permet théoriquement un nombre plus élevé de gestionnaires du pont, augmentant ainsi la tolérance aux pannes et la décentralisation.
Cependant, BEVM n’utilise aucune sécurité du BTC, se contentant d’interconnecter les actifs. Ses nœuds exécutent une logique interne et une EVM indépendante, sans publier de preuves sur BTC, donc sans disponibilité de données (DA) sur L1.
La résistance à la censure dépend entièrement du réseau lui-même. Si les nœuds refusent de traiter votre demande de retrait, vous ne pourrez pas récupérer vos BTC sur la L1 — un risque latent.
L’avantage de cette approche réside dans sa rapidité de mise en œuvre et de validation. L'utilisation innovante des multisignatures Taproot renforce aussi la sécurité du pont, ce qui fait de BEVM l’une des rares sidechains BTC déjà déployées en mainnet.
Map Protocol
Map est une sidechain EVM axée sur les inscriptions, qui choisit de transférer les BRC20 de la L1 BTC vers une EVM pour y exécuter certaines applications de base.
Map exploite un indexeur BRC20 amélioré. Pour transférer un BRC20, l’utilisateur doit envoyer une nouvelle transaction contenant dans son JSON la chaîne cible et l’adresse de destination, permettant à Map de l’indexer et de le rendre visible sur la sidechain. Le retrait est ensuite validé par un comité de signatures fonctionnant selon le mécanisme PoS de Map.
Le registre BRC20 tourne en réalité sur l’indexeur, et la L1 BTC n’est qu’une source de données accessible.
Grâce à des frais plus bas, la sidechain Map héberge des outils comme LessGas pour frapper des BRC20, le marché d’inscriptions SATSAT, et facilite le pontage BRC20 via Roup. Axée sur les inscriptions, elle attire une niche d’utilisateurs.
Map utilise un consensus PoS classique, publiant périodiquement des points de contrôle sur la L1 BTC pour renforcer sa sécurité. Mais en dehors de la protection contre les attaques longues, Map n’hérite pas de la sécurité du BTC, ni n’améliore significativement la résistance à la censure, la vérification des changements d’état ou la fiabilité des données.
BitmapTech Merlin Chain
Sidechain BTC lancée par Brc420. Merlin Chain utilise la solution MPC du portefeuille Cobo pour réaliser le pont cross-chain, un choix relativement conservateur : le nombre de signataires MPC est limité, offrant donc moins de sécurité comparé aux multisignatures BTC modernisées par Taproot, bien que la technologie MPC soit largement éprouvée.
Merlin intègre l’abstraction de compte de ParticleNetwork, permettant aux utilisateurs de conserver leurs portefeuilles et adresses BTC pour interagir avec la sidechain — une excellente expérience utilisateur. À l’inverse, obliger les utilisateurs BTC à utiliser Metamask relève de la paresse et d'une approche brutale.
Brc420 et Bitmap ayant une forte visibilité, ils ont déjà acquis une large base d’utilisateurs. Merlin poursuit sur la voie des inscriptions, en prenant en charge plusieurs types d’actifs inscrits depuis la L1, et en proposant un service de gravure d’inscriptions sur la sidechain.
ckBTC
ckBTC est une intégration de BTC sur ICP réalisée par une approche purement cryptographique, sans recourir à un pont tiers ni à un dépositaire.
ICP est une blockchain L1 indépendante dont le consensus repose sur un schéma de signature seuil BLS. La technologie ChainKey, liée à ce mécanisme, permet au réseau ICP de gérer collectivement une adresse multisignature BTC, recevoir des BTC, et contrôler ces fonds via une signature agrégée issue du consensus, pour permettre les retraits.
ICP copie aussi dans son réseau le modèle de comptes reflétant tous les UTXO de BTC, permettant à ses contrats intelligents de lire l’état du BTC — équivalent à exécuter tous les nœuds BTC au sein du réseau ICP.
Étant donné que cette signature seuil est étroitement liée à l’algorithme de décision d’ICP, la sécurité de ckBTC dépend uniquement des réseaux ICP et BTC, sans hypothèse de confiance supplémentaire.
Ainsi, l’approche de ckBTC utilisant le schéma de signature seuil ChainKey représente actuellement la méthode la plus sûre pour un pont BTC. Toutefois, pour le demandeur de retrait, si le réseau IC tombe en panne ou rejette la transaction, il ne peut pas forcer le retrait depuis la L1 BTC. Par ailleurs, ICP étant une L1 autonome, sa sécurité est garantie par elle-même, indépendamment de BTC.
II. Disponibilité des données (Data Availability)
BTC est la source de données fiable la plus robuste au monde. Il devient donc naturel d’en faire une source de confiance pour les données.
De même, inspiré par Celestia, bien que le stockage sur BTC soit très coûteux, une base de consensus émerge pour en faire une couche DA.
En essence, les ordinaux et tout l’écosystème d’inscriptions exploitent déjà BTC comme couche DA. Presque toutes les « L2 BTC » envoient des données vers BTC, mais souvent de manière symbolique, exprimant un bel idéal. Voici quelques conceptions plus marquantes.
Nubit
Nubit est un protocole DA conçu pour étendre les cas d’usage de disponibilité des données sur BTC, attirant l’attention grâce à un financement incluant Bounce Finance et domo.
En bref, Nubit orchestre via un consensus PoS une chaîne DA similaire à Celestia, et publie régulièrement ses propres données DA — en-têtes de blocs, racines d’arbres de Merkle, etc. — sur la L1 BTC.
Ainsi, Nubit s’appuie sur la L1 BTC pour sauvegarder ses données DA, puis vend cet espace de stockage comme couche DA à d’autres utilisateurs ou rollups (une sorte de « poupée russe DA »). Nubit n’a pas de fonctionnalité de contrat intelligent, nécessitant donc un rollup construit au-dessus de sa couche DA.
Les utilisateurs envoient des données à la couche DA de Nubit. Après confirmation par le consensus PoS de Nubit, ces données entrent en « confirmation douce ». Puis, après un certain temps, la racine des données de Nubit est publiée sur BTC. Une fois la transaction BTC confirmée, les données initiales atteignent la confirmation finale. Ensuite, l’utilisateur doit publier un tag sur BTC pour permettre aux nœuds complets de Nubit de retrouver les données via un arbre de Merkle.
Initialement, le consensus PoS de Nubit sera sécurisé par le staking BTC de Babylon (présenté plus loin). Les utilisateurs paient les frais de stockage en BTC via le réseau Lightning, évitant ainsi les problèmes de pont. Un retrait d’urgence peut être effectué en fermant le canal, sans interaction directe avec le réseau PoS de Nubit.
Nubit ressemble à une version Bitcoin de Celestia : pas de contrats complexes, paiement en BTC via Lightning (le plus décentralisé), donc assez sobre. Bien que Lightning soit suffisamment fiable, son expérience utilisateur laisse à désirer, et il peine à supporter de gros volumes (problème classique des canaux d’état).
La relation entre Nubit et BTC reste ténue : la sécurité de la chaîne 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 inscriptions devraient-ils passer par Nubit plutôt que de publier directement sur BTC ? C’est la question centrale que Nubit doit répondre, car ses frais ne semblent pas un moteur suffisant.
Son avantage principal face à la DA BTC ? Nubit prend en charge la vérification par échantillonnage des données (DAS) par des nœuds légers, impossible sur BTC. Cela signifie que la vérification de la DA ne nécessite plus de télécharger un nœud complet BTC.
Peut-on obtenir un consensus communautaire pour des inscriptions non directement basées sur BTC ? Nubit tente de remplacer la DA de la L1 BTC par sa propre couche DA. Le défi n’est pas tant technique que social — un énorme obstacle… mais aussi une immense opportunité.
VedaVeda
Le protocole VedaVeda lit des inscriptions Ordinals spécifiques sur la L1 BTC, les interprétant comme des requêtes de transaction, puis les exécute dans une EVM sous-jacente à la chaîne BTC. L’utilisateur signe avec sa clé privée BTC une transaction compatible EVM, puis la frappe comme inscription sur BTC.
Les nœuds EVM de Veda analysent les blocs BTC ; dès qu’une transaction est confirmée, l’EVM exécute la requête, modifiant l’état. En somme, BTC devient la file d’attente de transactions non confirmées de l’EVM Veda. Toutefois, comme BTC est bien moins performant qu’ETH, et que la quantité de données inscriptibles par bloc est limitée, l’EVM Veda ne peut exécuter qu’un petit volume de requêtes.
BTC est la source de données de tous les états de Veda. Quiconque scanne tous les blocs BTC contenant des requêtes Veda peut reconstruire l’état complet de l’EVM. On peut donc faire confiance à Veda EVM de manière optimiste, sans hypothèse de sécurité complexe.
Mais Veda ne met pas BTC à l’échelle. Imaginez un réseau Ethereum avec un intervalle de blocs de 10 minutes, un TPS de 5, mais des dizaines de milliers de nœuds et une puissance de calcul PoW énorme. Veda étend simplement les fonctionnalités de BTC en ajoutant la logique de contrats intelligents. Cela ne résout en rien le problème de la concurrence pour les ressources.
Babylon
Babylon est un protocole permettant à d'autres blockchains de partager la sécurité du BTC, composé de deux parties : le service de staking BTC et le service d’horodatage BTC.
Babylon permet de staker du BTC pour assurer la sécurité économique d’une chaîne PoS (similaire au restaking d’ETH), entièrement par des moyens cryptographiques, sans pont ni tiers dépositaire.
Un staker BTC envoie sur BTC une transaction à deux sorties UTXO : la première contient un script de verrouillage temporel, permettant au staker de récupérer ses BTC après expiration ; la seconde va vers une adresse temporaire BTC, dont la paire clé publique/privée respecte la norme cryptographique « One-Time Signature Extractable (EOTS) ».
Quand un staker BTC exécute un nœud sur une chaîne PoS, il signe avec sa clé EOTS le bloc valide. S’il reste honnête et ne signe qu’un seul bloc par hauteur, il obtient la récompense du validateur. S’il triche en signant deux blocs à la même hauteur, sa clé EOTS peut être décryptée, permettant à quiconque de transférer ses BTC mis en jeu — une sanction automatique.
Ce mécanisme incite les stakers à rester honnêtes. Babylon propose aussi un service d’horodatage BTC : publier les points de contrôle de toute blockchain dans les op_return de BTC, renforçant ainsi sa sécurité.
Nubit prévoit d’utiliser le service de staking BTC de Babylon pour renforcer sa sécurité. Babylon utilise une approche purement cryptographique pour les dépôts, retraits et sanctions, offrant une haute sécurité. Mais pour les chaînes utilisatrices, cela impose des contraintes économiques, et reste moins vérifiable que les rollups ETH. Le service d’horodatage publie bien les données L2 sur BTC, mais vérifier l’intégralité des blocs BTC nécessite un nœud complet, ce qui est coûteux. De plus, BTC L1 n’a pas de contrats intelligents, donc ne peut pas valider la justesse de ces données.
III. Rollups
Grâce aux Ordinals, Bitcoin peut stocker toutes sortes de données, devenant une base de données hautement sécurisée. Publier les preuves d’un rollup sur le réseau BTC garantit qu’elles ne peuvent pas être altérées, mais ne prouve pas la validité ou la justesse des transactions internes du rollup.
Le problème central des rollups BTC est la vérification. La plupart opteront probablement pour un modèle de rollup souverain (vérification cliente), où les validateurs synchronisent hors chaîne toutes les données du rollup et les vérifient eux-mêmes.
Mais cela n’exploite pas pleinement la force maximale de Bitcoin : son consensus PoW soutenu par des dizaines de milliers de nœuds, capable de garantir la sécurité du rollup. L’idéal serait que le réseau BTC puisse activer la vérification des preuves du rollup, comme sur ETH, et rejeter les blocs invalides. En outre, 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 si les nœuds ou le séquenceur du rollup tombent en panne ou refusent les transactions, via une sortie d’urgence sécurisée.
Pour BTC, qui n’a pas de contrats intelligents mais seulement des scripts, on pourrait exploiter MAST pour composer des circuits logiques vérifiables. C’est difficile, mais conforme à l’esprit originel de BTC.
BitVM
BitVM est le protocole d’extension le plus suivi sur BTC, une sorte de rollup optimiste.
BitVM introduit de façon innovante un mécanisme de défis de fraude sur BTC : un prouveur et un challenger déposent chacun la même quantité de BTC dans une transaction (en entrée), dont la sortie contient un circuit logique. Les scripts BTC peuvent être vus comme des portes logiques simples, les briques 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 »).
Dans BitVM, un grand circuit composé de nombreux scripts BTC contient une preuve de fraude, dont la structure dépend des blocs assemblés par le séquenceur du rollup. Le challenger peut envoyer des hachages successifs à ce circuit, chaque script correspondant étant exécuté par un vérificateur qui en révèle la sortie, prouvant ainsi la justesse du résultat.
Via une série de transactions, le challenger peut défier le prouveur jusqu’à ce que chaque porte du circuit soit validée. Ainsi, le réseau BTC achève la vérification du rollup, et le prouveur récupère ses fonds. Sinon, le challenger remporte les BTC du prouveur. Dit simplement, BitVM pour BTC est ce que OP est à ETH — offrant la plus haute sécurité parmi les solutions de mise à échelle. Mais BitVM génère un volume énorme de transactions, très coûteuses, nécessitant de nombreuses pré-signatures hors chaîne, donc d’intenses calculs préalables.
Bien sûr, contrairement aux rollups optimistes/zk d’ETH, BitVM n’a pas de canal de retrait d’urgence : au moins un nœud honnête sur le réseau L2 est requis pour un retrait normal.
Néanmoins, c’est actuellement le meilleur niveau de sécurité possible pour une L2 BTC : publication de DA, vérification L1 de la validité des données rollup, pont BTC minimisant la confiance — seule la « sortie d’urgence » manque.
Ainsi, BitVM semble encore lointain, mais les récents débats sur le déblocage de l’op_cat pourraient ouvrir de nouvelles perspectives. L’opcode op_cat permet de concaténer deux chaînes, jusqu’à 520 octets. Cette concaténation permet des calculs plus complexes sur BTC. Par exemple, BitVM pourrait ainsi enchaîner des centaines de portes logiques dans un même script, traitant bien plus de circuits binaires en moins de transactions — un gain de vitesse quasi centuplé. Les combinaisons complexes de scripts BTC par BitVM inspirent désormais de nombreux projets L2, qui proposent de nouvelles approches de « preuves de fraude » sur BTC.
Bison Network
Bison Network est un rollup souverain ZK-STARK basé sur Bitcoin. Un rollup souverain utilise la L1 uniquement comme tableau d’affichage des données (DA), sans vérifier la justesse des transactions du rollup, celles-ci étant validées par ses propres nœuds.
Bison soumet ses preuves zk dans les Ordinals BTC. Les utilisateurs peuvent télécharger ces preuves et exécuter un client local 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 BTC. Quand un utilisateur dépose du BTC sur Bison Rollup, celui-ci est réparti dans plusieurs portefeuilles multisignatures. Ces portefeuilles supportent les DLC (Contrats Log discrets), une technologie reposant sur Taproot, combinant multisignatures et scripts à verrouillage temporel pour des contrats logiques simples. À chaque dépôt, l’utilisateur et le réseau Bison doivent signer des transactions futures pour différents scénarios :
-
Transfert à un tiers
-
Retrait vers la L1 BTC
-
Absence prolongée de retrait
Une fois signées, ces transactions ne sont pas publiées. Pour s’exécuter, elles nécessitent un oracle. Le contrôle du portefeuille multisignature implique trois parties : l’utilisateur, Bison Rollup, et l’oracle. Deux signatures suffisent pour prendre le contrôle.
Les DLC agissent comme des instructions if-do sur Bitcoin : l’oracle fournit la condition « if », et l’action « do » lance l’une des trois transactions signées. L’oracle est connecté au contrat-pont de Bison. Si le pont reçoit une demande de transfert, l’oracle envoie la transaction signée du cas ①, donnant le contrôle au réseau Bison pour distribution ; s’il reçoit une demande de retrait, il envoie la transaction ②, transférant le contrôle à l’utilisateur ; sinon, après expiration du verrou, le contrôle revient à l’utilisateur.
Ainsi, Bison implémente un mécanisme de retrait du rollup, doté d’un canal d’évacuation simple. Toutefois, le point faible réside dans l’oracle : une information erronée entraîne la perte d’actifs. On pourrait envisager une solution décentralisée, comme Chainlink. L’utilisation des DLC pour un « pont sans confiance » explore pleinement le potentiel des scripts BTC. http://DLC.link l’utilise déjà pour transférer du BTC vers ETH ou STX. Bison Rollup, bien qu’ayant introduit un tiers, offre un simple « canal d’évacuation », mais n’assure toujours pas la vérification L1 des preuves du rollup.
B² Network
B² Network est un rollup zk sur BTC combinant « engagement et défi ». Il comporte deux couches : la couche rollup et la couche DA. La couche rollup utilise zkEVM pour exécuter la logique des contrats intelligents, incluant modules de réception, ordonnancement et empaquetage des transactions, production de preuves zk, abstraction de comptes compatibles BTC, et synchronisation des données L1 BTC (soldes BTC et BRC20).
La couche DA stocke les données du rollup. Ses nœuds effectuent une vérification zk hors chaîne. Après vérification, les nœuds DA écrivent les données du rollup dans des inscriptions Ordinals BTC, incluant la position des données DA, la racine de l’arbre de Merkle des transactions, les données de preuve zk, et le hachage de la précédente inscription de preuve BTC. La vérification est au cœur du système.
Sur ETH, le contrat-pont vérifie directement la preuve zk sur L1. Sur BTC, aucune fonctionnalité de contrat intelligent n’existe, et la vérification zk est trop complexe pour être implémentée par des scripts BTC (trop coûteux, risque de dépasser la limite du bloc). B² introduit donc davantage de calculs hors chaîne, transformant la vérification directe en un « défi de fraude » similaire à un modèle optimiste.
B² décompose la preuve zk en différents scripts, organisés en arbre binaire MAST. Les nœuds B² envoient une transaction contenant du BTC comme récompense pour un défi de fraude.
Dès qu’une transaction contenant un « défi de fraude » est confirmée sur BTC L1, 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 les transactions rollup sont annulées. Si aucun défi n’est lancé durant la période de verrouillage, le nœud récupère ses BTC et le rollup est définitivement confirmé.
Dans B² Network, la première transaction confirme l’immutabilité de la preuve zk. Bien que BTC ne puisse pas vérifier directement la transaction zk, le « défi de fraude » dans la deuxième transaction réalise indirectement une vérification L1, garantissant l’efficacité des transactions rollup et renforçant la sécurité — une innovation remarquable. L’intégration de l’abstraction de compte permet d’utiliser les portefeuilles BTC existants sans changer les habitudes, ce qui est très positif. Toutefois, pour le retrait du BTC de la L2, B² utilise toujours un pont multisignature, sans introduire de « canal d’évacuation ».
SatoshiVM
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 publie sur BTC, puis envoie une transaction contenant du BTC comme « défi de fraude », le challenger remportant la récompense en cas de succès.
La différence réside dans l’ajout de deux verrous temporels dans le « défi de fraude », marquant le début et la fin du défi. En comparant combien de blocs ont été attendus avant le transfert BTC, on peut facilement déterminer si la preuve zk était correcte. Pour le pont cross-chain, seule une solution multisignature classique est utilisée, sans innovation notable.
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
Ajouter aux favorisPartager sur les réseaux sociaux
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
@blockpunk2077
