Introduction

BOB est une L2 hybride unique conçue pour combiner la sécurité de Bitcoin et la programmabilité d'Ethereum. Les L2 hybrides héritent de la sécurité de Bitcoin, le réseau le plus sûr et le plus décentralisé. La sécurité de Bitcoin est ensuite utilisée pour créer des ponts de confiance minimisés vers Bitcoin, Ethereum et d'autres L1. Par conséquent, la L2 hybride ne dépendra pas de passerelles tierces pour l'interopérabilité et résoudra le problème de la liquidité fragmentée de la multichaîne BTC.

En fusionnant la sécurité et le capital de Bitcoin avec l'innovation et la polyvalence de DeFi d'Ethereum, BOB placera Bitcoin au cœur de DeFi - débloquant de nouveaux cas d'utilisation et des trillions de liquidités. Cela fera de BOB le foyer idéal pour Bitcoin DeFi : le meilleur et le plus sûr endroit pour obtenir un rendement sur votre Bitcoin.

En 2024, nous avons publié le livre blanc Hybrid L2, qui présente la vision hybride et la conception de haut niveau de la BOB hybride L2, ainsi que la feuille de route en trois phases pour faire passer la BOB de l'ETH L2 à l'Hybrid L2.

Dans cet article, nous décrivons comment BOB atteindra la phase 2: un rollup ETH avec finalité Bitcoin et un pont BTC alimenté par BitVM. Dans le cadre de cette mise à niveau, BOB atteindra les cinq nouvelles propriétés suivantes :

  1. Validité de l'état via des preuves ZK : Les blocs BOB sont vérifiés cryptographiquement et prouvés corrects pour éviter les défaillances de sécurité. Le séquençage des transactions se fait ainsi sans confiance, ce qui permet la décentralisation du séquenceur et améliore les délais de finalisation.
  2. Finalité par la mise en jeu de bitcoins : BOB dispose d'une chaîne canonique unique à travers tout pont natif, renforcée par la finalité Bitcoin via la mise en jeu de BTC. Si des fournisseurs de finalité (FPs) signent des chaînes concurrentes, leur mise en BTC sera réduite.
  3. Pont Bitcoin natif via BitVM : BOB disposera d'un pont Bitcoin natif basé sur la conception BitVM2 coécrite.
  4. Retraits rapides : En utilisant des preuves de validité et des FP, les retraits de BOB vers Bitcoin et Ethereum prendront quelques heures au maximum.
  5. Disponibilité de données hybrides : Les utilisateurs de BOB peuvent inclure des transactions sur BOB en envoyant une transaction sur le réseau principal de Bitcoin. Cela permet d'effectuer des retraits vers Bitcoin sans que le séquenceur ne puisse censurer les transactions.

‍

Blocs de construction de la phase 2

Dans la phase 1, BOB a lancé son réseau principal en tant qu'OP Stack rollup sur Ethereum, prenant en charge les actifs BTC d'Ethereum (wBTC, SolvBTC, LBTC, tBTC, ...). BOB continuera à utiliser les blobs EIP-4844 d'Ethereum comme DA et supportera le pontage vers Ethereum via les contrats de pontage standard d'OP.

Dans la phase 2, BOB introduit trois blocs de construction pour ajouter la validité de l'état ("ZK rollup"), la finalité Bitcoin, et un pont BTC natif.

  1. Preuves de validité : En utilisant les SNARKs sur les propositions d'état BOB, tout tiers, client léger ou chaîne externe peut vérifier cryptographiquement que les propositions d'état BOB sont correctement créées. Les preuves de validité sont publiées et vérifiées sur Ethereum. Cela garantit que le séquenceur BOB ne peut pas produire de blocs invalides et fait de BOB un rollup de validité (parfois appelé "rollup ZK"). Les preuves de validité constituent également la base des ponts natifs vers Bitcoin (via BitVM) et Ethereum.
  2. Fournisseurs de Finalité (FPs) en BTC : BOB introduit les FPs avec mise en jeu en BTC, alimentés par Babylon. Les FPs misent des BTC sur Bitcoin et signent les propositions d'état de BOB. Si les FPs signent plus d'une version de la chaîne BOB, leur BTC est réduit sur Bitcoin (les clés privées sont divulguées, en savoir plus ici). La réduction pour équivoque introduit un coût économique élevé pour les tentatives de fork de la chaîne BOB, offrant ainsi des garanties de finalité plus solides. Cette propriété joue un rôle essentiel dans la conception de la L2 hybride, car elle garantit un fonctionnement cohérent des ponts BTC et ETH natifs. Alors qu'un séquenceur corrompu ne peut pas créer de blocs BOB invalides (en raison des preuves de validité), il pourrait créer deux versions valides mais conflictuelles de la chaîne BOB (par exemple, contenant une double dépense) et tenter de créer une incohérence à travers les ponts BTC et ETH. La finalité BTC-staked empêche cela en imposant une seule version canonique de BOB, vérifiée à la fois sur Bitcoin et Ethereum.
  3. BitVM : BitVM est un mécanisme permettant d'exécuter des programmes arbitraires sur Bitcoin de manière optimiste : l'exécution a lieu en dehors de la chaîne, mais en cas d'échec, les litiges sont résolus et appliqués sur la chaîne. Nous utilisons BitVM pour créer un pont de confiance minimisé entre Bitcoin et BOB. Plus précisément, nous créons un pont client léger bidirectionnel : BOB peut déjà vérifier les dépôts sur Bitcoin, BitVM nous permet de vérifier les retraits sur BOB et d'assurer un traitement correct sur la chaîne principale de Bitcoin. Ainsi, nous vérifions la preuve SNARK sur l'état de BOB ainsi que la finalité de BTC en utilisant le mécanisme anti-fraude de BitVM.

‍

La conception hybride L2 de BOB

Nous utilisons maintenant ces trois éléments pour créer la toute première L2 hybride :

  1. Validité du rollup et finalité du bitcoin : Combinant les preuves de validité et les FP misant sur la BTC, la L2 hybride BOB assure la sécurité des transactions et la finalité rapide garantie par la BTC. Les PF s'engagent à ce que l'état BOB soit valide en présentant une preuve de validité et en fournissant des signatures sur les propositions d'état BOB, pondérées par leur enjeu en BTC.
  2. Pont Bitcoin natif : En s'appuyant sur les Validity Proofs, les BTC-Staked FP et BitVM, BOB ajoute un pont Bitcoin natif. Dans BitVM, les opérateurs réclament des BTC aux instances BitVM par le biais d'une combinaison complexe de diverses preuves du fonctionnement du pont et de la finalisation de l'état BOB.
  3. Pont et règlement en Ethereum natif : Intégrant les preuves de validité et les FP mis en jeu en BTC, les promoteurs de l'Ethereum natif affirment que le BOB est valide et finalisé par les FP pour compléter les retraits des utilisateurs vers l'Ethereum.

Validité du rollup et finalité du bitcoin

Le séquenceur BOB produit des blocs toutes les 2 secondes. Après la création d'un certain nombre de blocs BOB, l'état de BOB est finalisé, à la manière d'un point de contrôle. Pour ce faire, le séquenceur BOB génère une preuve de validité SNARK de BOB, comprenant tous les blocs produits depuis le dernier point de contrôle/preuve. Cette preuve vérifie cryptographiquement que toutes les transactions traitées sont valides.

Le séquenceur soumet le hachage de la proposition d'état, la signature et la preuve de validité aux PF ayant misé sur BTC. Les PF doivent avoir misé des BTC sur Bitcoin pour être qualifiés de PF BOB et reçoivent en retour une partie des frais du séquenceur sous forme de récompenses de mise. Nous considérons qu'une proposition d'état BOB est définitive une fois qu'elle a été approuvée par au moins ⅔ des BTC mis en jeu. En outre, l'engagement signé pour l'état BOB est régulièrement vérifié dans Bitcoin. Après 100 blocs Bitcoin, le point de contrôle est considéré comme finalisé.

Cette combinaison de preuve de validité et de finalité Bitcoin est ensuite utilisée pour vérifier et exécuter correctement les dépôts et les retraits pour les ponts Bitcoin et Ethereum natifs.

‍

Pont Bitcoin natif

Dans BitVM, ce que l'on appelle les opérateurs permettent aux utilisateurs d'entrer et de sortir des BTC de la BOB. Les opérateurs et les utilisateurs créent une instance BitVM pour chaque dépôt où l'utilisateur bloque un montant de BTC, et reçoit bobBTC sur BOB. Lorsqu'un utilisateur effectue un retrait, l'opérateur lui envoie d'abord des BTC à partir de son propre portefeuille (fronting the BTC), puis récupère les BTC du dépôt BitVM. L'opérateur ne peut réclamer les BTC à BitVM que s'il peut prouver (1) qu'il a fourni des BTC à un utilisateur effectuant un retrait et (2) que la demande de retrait correspondante (qui brûle des bobBTC) a été finalisée. Ce processus est optimiste : l'opérateur initie le processus de réclamation de BTC (sous la forme d'un SNARK), déclarant qu'il/elle a correctement traité la demande de retrait, et peut être contesté par n'importe quel utilisateur observateur pendant une fenêtre de temps prédéfinie ("période de contestation").

En cas de contestation, l'opérateur et le contestataire vérifient une petite partie du programme de vérification SNARK sur Bitcoin en script Bitcoin. Si le challenger réussit à prouver que l'opérateur triche, le BTC reste dans l'instance BitVM, et l'opérateur est éliminé et retiré du pont. Si l'opérateur est honnête, il reçoit le BTC de l'instance BitVM et le challenger est éliminé.

‍

‍

Pour BOB en particulier, l'opérateur fait la déclaration suivante pour une instance BitVM : Ils combinent la transaction Bitcoin de retrait (= la transaction PegOut) avec la preuve que le BTC bridgé sur BOB a été brûlé sur un bloc finalisé, c'est-à-dire un bloc BOB qui fait partie d'une proposition d'état finalisé. Ils prouvent également que la transaction PegOut et la référence du point de contrôle BOB (dans le cadre du point de contrôle de l'état BOB signé par les preneurs de BTC sur Bitcoin) sur Bitcoin se trouvent sur la même chaîne.

Pour une présentation plus approfondie de BitVM, des différences entre les approches de conception possibles et des dernières mises à jour, voir notre Rapport sur l'état d'avancement de BitVM.

‍

Pont et règlement en Ethereum natif

Il existe deux types de rollup populaires sur Ethereum : Les rollups optimistes et les rollups de validité. Dans les rollups optimistes, les propositions d'état régulières peuvent être contestées au cours d'une fenêtre temporelle prédéfinie. Si une proposition d'état n'est pas contestée avec succès, elle est considérée comme finalisée. Dans les rollups de validité, une proposition d'état est accompagnée d'une preuve ZK garantissant la validité de l'état. La preuve est vérifiée sur Ethereum et, si elle est valide, l'état est immédiatement finalisé.

Dans le cadre de la phase 2, BOB deviendra un rollup de validité. Cela garantit que l'état finalisé utilisé pour BitVM est également utilisé pour Ethereum. La preuve de validité de BOB est différente des autres rollups de validité. Elle combine deux preuves : (1) la validité du bloc BOB empêchant les défaillances de sécurité et (2) une preuve que les PF ont attesté de la chaîne canonique de BOB. La preuve concernant les FP comprend la présence d'au moins ⅔ de FP en BTC, un point de contrôle des signatures des FP sur Bitcoin et le fait que le point de contrôle a au moins 100 confirmations sur Bitcoin.

Nous pouvons fréquemment finaliser l'état de BOB sur Ethereum en soumettant cette preuve de validité combinée. Ceci, à son tour, réduit le temps de retrait vers Ethereum de la norme actuelle de 7 jours d'un rollup optimiste à seulement quelques heures - comme c'est la norme pour les rollups de validité.

‍

Disponibilité des données hybrides

De par leur conception, les utilisateurs peuvent inclure une transaction sur BOB en soumettant une transaction sur Ethereum, ce qui les protège contre la censure des séquenceurs. Les preuves de validité et les règlements sur Ethereum étant ouverts à tous, les utilisateurs peuvent forcer le retrait de leurs actifs vers Ethereum dans les situations d'urgence.

Récemment, BOB a introduit le concept novateur de disponibilité hybride des données, où le bitcoin est ajouté au pipeline de dérivation d'un rollup ETH. De la même manière que les utilisateurs peuvent envoyer des transactions arbitraires avec un dépôt dans le contrat OptimismPortal sur Ethereum, nous permettons aux utilisateurs d'envoyer des transactions arbitraires à BOB sur Bitcoin. Le principal cas d'utilisation est d'inclure des transactions de retrait sur BOB vers Bitcoin si le séquenceur est hors ligne ou censure les utilisateurs sur la L2.

Dans l'article complet, nous expliquons comment l'ajout de Bitcoin au pipeline de dérivation permet de résister à la censure de Bitcoin pour les transactions L2.

‍

Perspectives pour la phase 3 : sécurité totale du bitcoin

Si Bitcoin ajoute une fonctionnalité permettant de vérifier les preuves de validité nativement dans le script Bitcoin, BOB peut se régler directement sur Bitcoin avec une sécurité Bitcoin totale. Cela représente l'état idéal de la phase 3 : une sécurité totale de Bitcoin qui peut être prouvée par un client léger de Bitcoin pour n'importe quelle autre chaîne. Cela signifie que BOB règle sur Bitcoin et que la finalisation (des ponts) sur d'autres chaînes se fait en vérifiant Bitcoin. Il s'agit d'une hypothèse de confiance raisonnable : si Bitcoin échoue, il est probable que toutes les autres chaînes échoueront également.

En l'absence d'une fourche Bitcoin permettant des vérificateurs ZK sur la chaîne, BOB devra s'appuyer sur la vérification optimiste via BitVM. Pour réaliser des rollups optimistes sur Bitcoin sans hypothèses de confiance supplémentaires, il faut utiliser la chaîne principale de Bitcoin comme couche de disponibilité des données. À l'heure actuelle, les coûts de la DA de Bitcoin sont onéreux(voir le rapport Galaxy) et posent un défi en termes d'économie.

Par conséquent, pour achever la transition vers la phase 3, BOB doit atteindre une échelle suffisante en termes d'utilisateurs actifs pour que les frais supplémentaires de disponibilité des données n'augmentent pas les frais de transaction au-delà de ceux des L2 concurrentes d'Ethereum. Les couches alternatives de disponibilité des données peuvent être considérées comme un compromis entre le coût et la sécurité, car elles introduisent des hypothèses de confiance supplémentaires par rapport à Bitcoin.

Il est important de souligner que l'utilisation d'une couche DA alternative avec une vérification BitVM pour la finalité du rollup n'apporte pas d'avantages par rapport à la conception de la phase 2 : la sécurité (généralement PoS) de la couche DA doit être fiable. En outre, une telle construction nécessite la vérification d'une preuve de client léger pour le consensus (PoS alternatif) de l'AN dans BitVM, ce qui est une question de recherche ouverte.

Par conséquent, la phase 2 de BOB est la solution la plus sûre et la plus pratique pour BTC DeFi aujourd'hui, en particulier parce que la mise de BTC est réduite en cas d'équivoque.

‍

Conclusion

Nous avons présenté le plan technique pour faire évoluer BOB vers la toute première L2 hybride : un rollup Ethereum avec une finalité Bitcoin et des ponts natifs, minimisant la confiance, pour les actifs BTC et ETH.

Nous commencerons à déployer l'Hybrid L2 sur le réseau test au cours des prochaines semaines et achèverons la mise à niveau vers le réseau principal après des audits réussis. Parallèlement, nous achevons une spécification technique complète comprenant des preuves de sécurité qui seront publiées sous peu. Le pont BitVM de BOB est déjà lancé sur le réseau de test, et l'intégration des opérateurs commencera bientôt.

‍