Un prototype de pont BitVM entre BOB et Bitcoin a été testé avec succès, marquant une étape importante dans notre mission Hybrid L2 pour combiner le meilleur de Bitcoin et Ethereum.

Le prototype s'appuie sur la dernière version de BitVM2 pour faciliter la mise en place d'un pont Bitcoin à confiance réduite. Il a été développé en étroite collaboration avec Fiamma, l'undes principaux développeurs de BitVM et une société d'infrastructure à zéro connaissance.

Cela fait suite à l'annonce de notre prochaine intégration avec Babylon, qui apportera la finalité Bitcoin au réseau BOB via le protocole de jalonnement Bitcoin de Babylon. Ensemble, ces deux développements permettent à BOB de passer à la phase 2 de la feuille de route Hybrid L2.

BOB sera la première solution de niveau 2 à hériter de la sécurité de Bitcoin et à développer un prototype de pont basé sur BitVM.

Lisez la suite pour en savoir plus.

‍

Qu'est-ce que BitVM ?

BitVM est un mécanisme permettant d'exécuter des programmes sur Bitcoin de manière optimiste. L'exécution se fait en dehors de la chaîne, mais en cas d'échec, les litiges sont résolus et appliqués sur la chaîne. Pensez à l'optimisme, mais sur Bitcoin. Les deux principaux cas d'utilisation sont les rollups Bitcoin et les ponts à confiance réduite. Dans les deux cas, nous voulons permettre aux utilisateurs de déposer et de retirer des BTC d'une L2 sans faire confiance à un tiers.

Les ponts existants reposent généralement sur des entités centralisées - telles que Wrapped Bitcoin (wBTC) et Coinbase Wrapped Bitcoin (cbBTC) - ou sur des réseaux semi-confidentiels comme tBTC, où la sécurité dépend de l'honnêteté de la majorité des participants. En revanche, les ponts BitVM2 introduisent un modèle de sécurité supérieur : Les dépôts en BTC ne peuvent pas être volés tant qu'il existe un seul nœud honnête et en ligne dans le réseau, et ce nœud peut être le déposant lui-même.

La version la plus récente et la plus pratique est BitVM2. Veuillez vous référer à notre dernier document pour une spécification complète du protocole.

Alexei Zamyatin, cofondateur de BOB, contributeur actif et co-auteur de la conception technique de BitVM2, a souligné l'importance de la réalisation d'aujourd'hui :

"La sécurité de Bitcoin et la réduction de la confiance dans les BTC sont ce qui différencie Bitcoin L2s de toutes les autres chaînes. La sécurité du réseau le plus robuste et le plus décentralisé, associée à un moyen de déposer et de retirer des BTC sans faire confiance à un tiers. Jusqu'à présent, cela n'a pas été possible, car presque tous les ponts BTC sont des multisigs de confiance. Ce n'est qu'aujourd'hui, pour la première fois dans l'histoire de Bitcoin, que nous disposons enfin d'un plan et d'un prototype pour y parvenir dans la pratique avec BitVM2".

‍

Flux du protocole BitVM2

  1. Compression d'un programme dans un vérificateur SNARK, implémenté dans Bitcoin Script. En utilisant le système de preuve Groth16, nous obtenons une taille d'environ 1 Go.
  2. Diviser le vérificateur en sous-programmes de 4 Mo maximum chacun, de façon à ce que chacun puisse être exécuté dans une transaction Bitcoin.
  3. L'opérateur s'engage à respecter le programme pendant l'installation.
  4. Lors d'une tentative de retrait de fonds de BitVM2, l'opérateur peut être contesté par n'importe qui, par exemple si le déballage (peg-out) n'a pas été effectué correctement.
  5. En cas de contestation, l'opérateur doit révéler tous les résultats des programmes intermédiaires.
  6. Si l'opérateur triche, l'un des résultats du sous-programme revendiqué sera erroné. N'importe qui peut réfuter l'opérateur en exécutant ce sous-programme spécifique dans une transaction Bitcoin, montrant ainsi que l'opérateur a revendiqué un faux calcul.
  7. C'est fait ! L'opérateur fautif est expulsé et ne peut accéder aux fonds BitVM en raison d'une transaction de dépense invalidée.

‍

Flux du pont BitVM

Le pont BitVM utilise BitVM2 pour mettre en œuvre un pont client léger sur Bitcoin. La L2 vérifie Bitcoin, Bitcoin vérifie la L2. La partie la plus intéressante est le déballage, également appelé peg-out, qui a longtemps été un défi pour les protocoles DeFi de Bitcoin.

  1. Les opérateurs versent des BTC à l'utilisateur qui effectue un retrait à partir de leurs propres fonds et récupèrent ensuite les BTC auprès de BitVM.
  2. BitVM vérifie que pour une transaction un-wrap sur la L2, il y a un peg-out correct sur Bitcoin.
  3. Si tout est correct, l'opérateur se fait rembourser les BTC.

‍

En cas de fonctionnement correct, le processus de transition s'effectue en moins d'une heure dans chaque sens, ce qui est beaucoup plus rapide que les passerelles Ethereum L1 ou L2 existantes vers le bitcoin.

‍

Un partenariat stratégique avec Fiamma

Pour accélérer la mise en œuvre de BitVM2, BOB a fait équipe avec Fiamma, le pionnier à l'origine des premiers produits utilisant BitVM2, notamment le premier pont BitVM (Fiamma Bridge) et la première couche de vérification alimentée par BitVM sur Bitcoin (Fiamma Layer).

Ce partenariat a joué un rôle déterminant dans le succès du prototype de pont BitVM de BOB. Ensemble, BOB et Fiamma ont déployé l'infrastructure clé du pont et testé une première version du logiciel de vérification du consensus de BOB. Ceci fait suite à l'investissement stratégique de BOB dans Fiamma au début de ce mois, dont l'infrastructure et l'expertise sont en mesure de soutenir le déploiement rapide de BitVM sur BOB, en commençant par ce prototype de pont BitVM.

Cyimon Chen, cofondateur de Fiamma et contributeur principal de BitVM, a déclaré à propos de l'étape franchie aujourd'hui :

"Nous sommes ravis d'annoncer notre partenariat avec l'équipe de BOB ! Nous apprécions profondément les idées précieuses d'Alexei et de son équipe au cours de nos discussions. Nous sommes impatients d'intégrer le pont BitVM dans BOB, ce qui en fera la première couche 2 de Bitcoin avec un pont à confiance réduite. Nous espérons que le prototype du pont BitVM de BOB sera le premier d'une longue série d'annonces impressionnantes résultant de notre partenariat stratégique".

‍

Faire progresser la feuille de route hybride L2 du BOB

En début de semaine, BOB a annoncé son projet d'intégration avec Babylon, le principal protocole de mise en jeu de BTC, qui fera de BOB un réseau sécurisé par Bitcoin et fournira une finalité Bitcoin à sa blockchain.

Le pontage minimisé par la confiance et la finalité du bitcoin sont des éléments essentiels de la conception hybride de BOB, qui vise à combiner la sécurité et la liquidité du bitcoin avec l'innovation et la polyvalence du DeFi d'Ethereum, faisant de BOB le foyer du BTC DeFi.

Cette combinaison permettra :

  • Sécurité renforcée : Les transactions sur BOB seront ancrées dans la sécurité de Bitcoin.
  • Transferts de BTC en toute transparence : Les utilisateurs pourront transférer des BTC entre Bitcoin et BOB sans devoir faire confiance à des intermédiaires.
  • Retraits plus rapides : La finalité du bitcoin accélérera les délais de retrait sur le pont Ethereum natif de BOB.

Pour en savoir plus sur ce que cela signifie, veuillez lire le document de vision Hybrid L2 de BOB.

‍

Quelle est la prochaine étape ?

Après la livraison de ce prototype, la BOB prévoit de déployer le pont BitVM sur le réseau test de la BOB au début de 2025, le déploiement du réseau principal devant suivre après la réussite de l'audit et de l'intégration des partenaires.

Une fois que BOB aura achevé son intégration avec Babylon et sera un réseau sécurisé en bitcoins (BSN), le principal mécanisme de sécurité pour le pont BitVM sera la finalité en bitcoins par le biais de la mise en jeu de BTC. Nous travaillons activement avec Babylon pour mettre en œuvre ce mécanisme.

En attendant, gardez un œil sur nos réseaux sociaux pour être informé du lancement du pont BitVM, et de tous les autres développements passionnants que nous avons prévus.

Pour les développeurs et tous ceux qui aiment approfondir la technologie, les sections suivantes expliquent plus en détail les développements spécifiques qui sous-tendent le prototype de la passerelle. Vous y trouverez également des liens vers les transactions d'essai du prototype.

‍

Détails techniques du pont BitVM

Prover spécialisé basé sur zkVM

En intégrant l'infrastructure de base de Fiamma, nous avons développé un premier prototype de notre prouveur basé sur zkVM pour valider la construction de blocs sur BOB. Dans cette première version, nous avons fourni des données d'entrée à notre prouveur SNARK :

  • Transactions Ethereum L1 soumettant de nouvelles racines de sortie au contrat L2OutputOracle.
  • Les en-têtes de bloc L2 jusqu'à ce "point de contrôle" pour un bloc cible.
  • Reçus d'exécution pour le bloc L2 cible.

Nous nous sommes assurés que l'auteur de la proposition approuvée avait signé correctement et que la racine de sortie correspondait au dernier bloc L2. Nous avons également vérifié que tous les blocs menant à notre bloc cible étaient dans le bon ordre. Ensuite, dans les enregistrements de transaction du bloc cible, nous avons confirmé l'existence d'un "événement de combustion" spécifique qui identifiait de manière unique l'instance BitVM créée lors de la configuration initiale.

Contrat de bridge et SPV Bitcoin Full Relay

La plupart de notre logique de contrat intelligent est définie dans un nouveau contrat "Bridge", qui permet de frapper des jetons ERC20 sur BOB, et permet aux opérateurs de traiter les demandes de peg-out.

En interne, il existe également un "relais complet" du SPV Bitcoin, que nous vérifions pour nous assurer que les transactions Bitcoin sont incluses.

Processus d'encaissement et de décaissement

En supposant qu'un utilisateur, Alice, veuille faire un pont entre la BTC et la BOB et ensuite retirer, le protocole de pont BitVM étape par étape est exécuté comme suit. Note : "peg-in" et "peg-out" se réfèrent à l'entrée et à la sortie de la passerelle, selon les définitions utilisées dans le code et le document BitVM.

Peg-In :

  • Alice se coordonne avec le comité* pour mettre en place une nouvelle instance BitVM et obtient un identifiant unique (hors chaîne).
  • Alice envoie des BTC à l'adresse Bitcoin désignée, en se référant à l'ID.
  • Le comité soumet le tx Bitcoin et la preuve d'inclusion au contrat intelligent Bridge sur BOB, qui vérifie (à l'aide du relais SPV) que la transaction de dépôt a été incluse dans la chaîne principale Bitcoin avec au moins 6 confirmations.
  • Si tout se passe bien, le contrat intelligent frappe un jeton ERC20 enveloppé de BTC pour Alice à un ratio de 1:1 par rapport au dépôt de BTC. Alice peut alors utiliser ce jeton dans n'importe quel protocole DeFi de BOB, comme n'importe quel autre jeton ERC20.

‍

* Le comité dit "d'émulation de convention" est utilisé pour simuler les codes d'opération de convention manquants sur Bitcoin. Ce comité est nécessaire pour pré-signer des transactions Bitcoin spécifiques qui garantissent que l'opérateur ne peut dépenser les dépôts BTC que d'une manière qui peut être contestée, empêchant ainsi le vol. Plus précisément, il s'agit d'un comité m-of-m, où m peut être très grand (des centaines de signataires échantillonnés de manière aléatoire). Tant que l'un de ces signataires est honnête, la configuration est sûre. Alice elle-même peut participer à cette configuration. Ce comité peut éventuellement être remplacé si Bitcoin ajoute un nouvel opcode comme TXHASH ou OP_CAT.

‍

Sortie de la boîte à boutons :

  • Alice bloque la BTC ERC20 enveloppée dans le contrat intelligent Bridge sur BOB et attend qu'un opérateur accepte la demande.
  • L'un des opérateurs envoie alors le montant correspondant en BTC à l'adresse d'Alice sur Bitcoin, et fournit une preuve d'inclusion au contrat intelligent Bridge sur BOB après qu'il y ait eu au moins 6 confirmations. Le contrat intelligent émet un événement "burn".

Note : le peg-out est terminé pour Alice à ce stade. L'opérateur " avance " les BTC à partir de son propre solde. Dans les étapes suivantes, l'opérateur récupère ce montant des dépôts de BitVM pour terminer le processus. Cette logique peut être comparée à celle d'un pont de liquidité sur Ethereum.

  • Le séquenceur BOB produit un bloc contenant l'événement "burn", qui est ensuite utilisé comme entrée pour l'analyseur ZK décrit ci-dessus.
  • L'opérateur initie un retrait des dépôts BitVM en bitcoins. Dans un délai de 7 jours, tout le monde peut vérifier l'exactitude du peg-out et, en cas d'erreur, contester l'opérateur.
  • Option 1 : Tout est correct. Si l'opérateur a exécuté le peg-out correctement (montant correct, destinataire, dans le temps requis, ...), il ne sera pas contesté et réclamera les BTC des dépôts BitVM après 7 jours.
  • Option 2 : Erreur et contestation. Si l'opérateur a essayé de tricher (par exemple, il n'a pas envoyé de BTC à Alice, mais il essaie quand même de les récupérer), il sera mis au défi - à condition qu'il y ait au moins un utilisateur honnête et en ligne dans le réseau. L'opérateur est alors obligé de publier des données supplémentaires sur l'exécution du vérificateur SNARK (transaction "Assert"), ce qui permet aux challengers de prouver au réseau Bitcoin que l'opérateur triche (avec une transaction supplémentaire). Si l'opérateur ne publie pas la transaction Asset ou s'il a effectivement triché (c'est-à-dire que le vérificateur SNARK ne peut pas s'être exécuté correctement), sa tentative de retrait échouera et il sera retiré de l'ensemble des opérateurs.

‍

Notez que dans le cas du peg-out, nous avons la possibilité de soustraire les frais dans le contrat intelligent afin que l'opérateur puisse récupérer plus lors de la récupération de l'instance BitVM.

‍

Prototype de pont BitVM en action

Pour illustrer le fonctionnement de ce prototype, examinons quelques exemples de transactions sur Bitcoin Signet.

Tout d'abord, la transaction "peg-in", au cours de laquelle l'utilisateur bloque ses BTC :

‍

Le chemin du bonheur

Dans le cas optimal (où l'opérateur est honnête), il remet les BTC à l'utilisateur dans pegout_tx et récupère ensuite les fonds (sans contestation) dans happy_take_tx:

‍

Chemin malheureux (avec défi réussi)

Lorsqu'un opérateur tente de réclamer la BTC sans preuve ZK réussie, un challenger peut fournir un disprove_tx qui prouve à BitVM que l'assert_tx n'était pas valide :

‍

Chemin malheureux (avec défi infructueux)

Si un opérateur est mis en cause sur un peg-out valide, il fournit un assert_tx qui ne peut pas être réfuté. Il récupère alors les fonds dans unhappy_take_tx :

‍

Prochaines étapes du développement

Le prototype actuel présente encore quelques limites et est en cours de développement. Prochaines étapes menant à une version testnet de pré-lancement :

‍

  • Ajouter des vérifications de finalité Bitcoin via Babylon, y compris un client léger ZK pour vérifier correctement cela sur Bitcoin.
  • Intégrer avec BOB Bridge et Stake pour améliorer l'UX, en cachant la complexité aux utilisateurs.
  • Il existe des limites pratiques à l'affichage de certains engagements sur la chaîne en raison de contraintes de taille (par exemple, actuellement le tx assert manque d'engagements de données). Nous examinons cette question avec Fiamma.
  • Ajustement de l'économie pour s'assurer que les opérateurs sont payés équitablement et sont incités à exploiter le pont BitVM.

‍