Pont BitVM et OP-DLC : réflexions sur la conception des ponts inter-chaînes de nouvelle génération pour Bitcoin Layer2
TechFlow SélectionTechFlow Sélection
Pont BitVM et OP-DLC : réflexions sur la conception des ponts inter-chaînes de nouvelle génération pour Bitcoin Layer2
Comprendre la conception des nouveaux ponts blockchain entre Bitcoin via Bitlayer et Citrea
Dédié à des analyses Web3 approfondiesAuteurs : Faust & Nickqiao, Geek web3
Résumé :
-
Les ponts ZK déployent des contrats intelligents sur la chaîne A pour directement recevoir et vérifier les en-têtes de blocs et les preuves à connaissance nulle (ZK) correspondantes de la chaîne B, confirmant ainsi la validité des messages inter-chaînes. Il s'agit de la solution de pont la plus sécurisée. Les ponts optimistes / OP reposent sur des preuves de fraude pour contester les messages inter-chaînes invalides directement sur la chaîne : tant qu’un seul challenger fiable existe, la sécurité du pool de fonds du pont est garantie.
-
En raison de limitations techniques, le réseau principal Bitcoin ne peut pas directement déployer de pont ZK, mais un pont optimiste peut être réalisé via BitVM et les preuves de fraude. Des projets comme Bitlayer et Citrea adoptent une architecture de pont BitVM intégrant des pré-signatures et l'idée de canaux, permettant aux utilisateurs, avant tout dépôt officiel, de définir précisément le traitement post-dépôt, éliminant ainsi toute possibilité pour l'équipe du pont d'utiliser abusivement les dépôts des utilisateurs.
-
Le pont BitVM repose essentiellement sur un modèle « avance - remboursement », avec des nœuds Operator spécifiques qui versent immédiatement les fonds aux utilisateurs demandant un retrait. Ces Operators peuvent régulièrement demander un remboursement auprès d'une adresse publique de dépôt. Toute demande de remboursement frauduleuse peut être contestée par n’importe qui et entraîner une pénalité (slash).
-
Théoriquement, le pont BitVM ne présente aucun problème de sécurité, mais souffre de problèmes de vivacité/disponibilité et ne répond pas aux besoins spécifiques d’utilisateurs exigeant indépendance financière ou conformité anti-blanchiment (il reste fondamentalement basé sur un modèle de pool de fonds). Pour pallier cela, Bitlayer a ajouté un schéma de pont nommé OP-DLC, similaire à DLC.link, introduisant des preuves de fraude sur la base de canaux et de contrats DLC afin de prévenir la malhonnêteté des oracles du pont DLC.
-
Étant donné la grande difficulté technique de mise en œuvre de BitVM et des preuves de fraude, le pont DLC sera déployé en premier et servira temporairement de solution alternative. Dès lors que le risque de confiance lié à l’oracle est résolu et qu’un oracle tiers fiable et mature est intégré, le pont DLC peut devenir, dès aujourd’hui, un mécanisme de validation de retrait plus sûr que les ponts multisignatures.
Introduction
Depuis le boom des inscriptions l’année dernière, l’écosystème Bitcoin connaît une croissance explosive. En seulement six mois, près de 100 projets se revendiquant de « Layer2 BTC » ont vu le jour, transformant cet espace en une nouvelle terre d’opportunisme où s’entremêlent innovations et escroqueries. On peut sans exagérer dire que l’écosystème actuel de Bitcoin ressemble à un creuset multiculturel réunissant les paradigmes d’Ethereum, Cosmos et Celestia, Nervos CKB, et les solutions natives Bitcoin. Dépourvu d’autorité centrale, il rappelle les États-Unis du XIXe siècle — une frontière accueillant toutes sortes d’acteurs. Cette diversité apporte certes vitalité au récit Web3, mais aussi des risques considérables.
De nombreux projets lancent des campagnes de promotion effrénées sans même avoir publié leur solution technique, prétendant offrir une « véritable Layer2 native » capable d’hériter pleinement de la sécurité du réseau Bitcoin. Certains vont jusqu’à inventer des termes obscurs et fantaisistes pour asseoir une supériorité imaginaire. Bien que l’autopromotion soit devenue la norme dans cet écosystème, certains influenceurs de premier plan continuent d’émettre des critiques objectives.
Récemment, Monanaut, fondateur de l’explorateur blockchain Mempool, a critiqué ouvertement les défauts actuels de l’écosystème Bitcoin, soulignant avec acuité que si un Layer2 Bitcoin repose uniquement sur un pont de retrait multisig, incapable de permettre aux utilisateurs de retirer leurs actifs de façon non censurable, alors ce projet ne peut être considéré comme une véritable Layer2. Fait intéressant, Vitalik avait auparavant également affirmé qu’un Layer2 devrait être, en matière de sécurité, au moins plus robuste qu’un système basé sur une simple multisignature.
En somme, Monanaut et Vitalik ont mis le doigt sur un problème technique majeur des Layer2 Bitcoin : beaucoup de ponts de retrait sont en réalité des ponts multisig, soit avec quelques institutions connues détenant chacune une clé, soit utilisant une signature décentralisée basée sur POS. Quoi qu’il en soit, leur modèle de sécurité repose sur l’hypothèse d’une majorité honnête — c’est-à-dire que la plupart des signataires ne comploteront pas pour tricher.
Une telle solution, fortement dépendante de la confiance, n’est clairement pas viable à long terme. L’histoire nous a montré que les ponts multisig finissent toujours par subir des incidents variés. Seules des méthodes de gestion d’actifs minimisant la confiance, voire tendant vers la non-confiance, peuvent résister à l’épreuve du temps et des hackers. Pourtant, dans l’écosystème Bitcoin actuel, de nombreux projets n’ont même pas publié de feuille de route technique pour leur pont, ni aucune idée concrète sur comment le rendre non censurable ou à confiance minimale.
Mais ce constat n’est pas universel. Certains projets travaillent activement à améliorer leurs architectures de pont. Dans cet article, nous analyserons brièvement les ponts BitVM de Bitlayer et Citrea, puis présenterons le pont OP-DLC proposé par Bitlayer pour compenser les limites du pont BitVM, afin que davantage de participants comprennent les risques et les choix architecturaux des ponts inter-chaînes — une compréhension cruciale pour tous ceux impliqués dans l’écosystème Bitcoin.
Pont optimiste : un schéma de validation basé sur les preuves de fraude
En réalité, le pont inter-chaînes est simple : il s’agit de prouver qu’un événement s’est bien produit sur la chaîne A depuis la chaîne B. Par exemple, lorsque vous transférez des actifs d’ETH vers Polygon, le pont doit prouver que vous avez bien envoyé des fonds à une adresse spécifique sur Ethereum, afin que vous puissiez recevoir un montant équivalent sur Polygon.
Les ponts traditionnels utilisent généralement des signataires (witnesses) multisig, désignant hors chaîne plusieurs observateurs qui doivent exécuter des nœuds des différentes blockchains pour surveiller les dépôts effectués sur les adresses de réception du pont.
Le modèle de sécurité de ces ponts est similaire à celui d’un portefeuille multisig : selon le paramétrage (M/N), on établit un modèle de confiance basé sur l’hypothèse d’une majorité honnête — c’est-à-dire que la plupart des notaires sont supposés bienveillants. Ce modèle offre une tolérance aux pannes très limitée. La plupart des vols massifs de ponts inter-chaînes ont eu lieu sur ce type d’architecture, par complicité interne ou attaque par piratage.
En comparaison, les « ponts optimistes », basés sur un protocole de preuve de fraude, ainsi que les « ponts ZK », sont nettement plus sûrs. Prenons le pont ZK : il installe un contrat validateur dédié sur la chaîne cible, qui valide directement sur chaîne les preuves de retrait, éliminant ainsi le besoin de signataires hors chaîne.
Par exemple, un pont ZK entre ETH et Polygon déployerait un contrat validateur, appelé Verifier, sur Polygon. Un nœud Relayer du pont transmettrait alors à ce Verifier l’en-tête du dernier bloc Ethereum accompagné d’une preuve ZK. Le Verifier validerait cette preuve. Cela revient à synchroniser et vérifier sur Polygon l’en-tête du dernier bloc Ethereum. L’en-tête contient un root Merkle lié aux transactions incluses dans le bloc, permettant de vérifier la présence d’une transaction spécifique.
Si le bloc Ethereum numéro 101 contient 10 déclarations de transfert inter-chaînes vers Polygon, le Relayer génère les preuves Merkle associées à ces 10 transactions et les soumet au contrat Verifier sur Polygon, prouvant que :
Le bloc 101 d’Ethereum contient 10 transactions de transfert ETH → Polygon. Le pont ZK peut même transformer ces preuves Merkle en preuves ZK, soumettant directement une preuve ZK au contrat Verifier. Durant tout ce processus, l’utilisateur n’a besoin de faire confiance qu’à l’absence de vulnérabilité dans le contrat intelligent du pont et à la fiabilité intrinsèque de la technologie ZK — contrairement aux ponts multisig traditionnels qui exigent de multiples hypothèses de confiance.
Le « pont optimiste / Optimistic Bridge » fonctionne légèrement différemment : certains conservent des signataires, mais introduisent des preuves de fraude et une période de contestation. Après qu’un signataire ait généré une signature multisig sur un message inter-chaînes, celle-ci est soumise à la chaîne cible, mais sa validité n’est pas immédiate. Elle n’est confirmée qu’après expiration de la fenêtre de contestation sans opposition. Cette logique rappelle fortement celle des Rollups optimistes (Optimistic Rollup). Bien sûr, il existe d’autres variantes de ponts optimistes, mais tous tirent leur sécurité du protocole de preuve de fraude.
Dans un pont multisig M/N, l’hypothèse de confiance est (N-(M-1))/N : on suppose que le nombre d’acteurs malveillants ne dépasse pas M-1, donc que les honnêtes sont au moins N-(M-1). Pour un pont ZK, l’hypothèse de confiance est négligeable. Pour un pont optimiste basé sur la preuve de fraude, elle est 1/N : il suffit qu’un seul des N signataires soit honnête et prêt à contester un message invalide soumis à la chaîne cible pour garantir la sécurité du pont.
Actuellement, en raison de contraintes techniques, seuls les ponts ZK dans le sens Bitcoin → Layer2 sont réalisables. Pour le sens inverse (Layer2 → Bitcoin), seuls les ponts multisig, les ponts optimistes ou des modèles de type canal sont supportés (le pont OP-DLC décrit ci-dessous relève davantage du modèle de canal). Pour implémenter un pont optimiste sur Bitcoin, il faut introduire des preuves de fraude, et BitVM crée les conditions techniques favorables à cette réalisation.
Dans un précédent article intitulé « Interprétation simplifiée de BitVM : comment vérifier des preuves de fraude sur la chaîne BTC », nous avons expliqué que la preuve de fraude BitVM consiste à décomposer une tâche de calcul complexe hors chaîne en nombreuses étapes simples, puis à en vérifier une étape spécifique directement sur la chaîne Bitcoin. Cette approche est proche de celles utilisées par Arbitrum ou Optimism sur Ethereum.
(Selon la documentation BitVM2, une signature Lamport permettrait de diviser une tâche de calcul en nombreuses étapes intermédiaires, permettant à quiconque de contester une étape spécifique)
Certes, cette explication reste un peu obscure, mais la plupart des lecteurs connaissent déjà bien le concept de preuve de fraude. Dans cet article, en raison de sa longueur, nous ne détaillerons pas les aspects techniques de BitVM ou du protocole de preuve de fraude, car cela impliquerait des flux d’interaction complexes.
Nous allons plutôt présenter succinctement, sous l’angle du design produit et du mécanisme, les ponts BitVM natifs proposés par Bitlayer, Citrea, BOB ou encore l’équipe BitVM officielle, ainsi que la manière dont Bitlayer propose d’atténuer les goulots d’étranglement du pont BitVM via son pont OP-DLC, afin de montrer comment concevoir des solutions de pont de retrait plus performantes sur Bitcoin.
(Schéma des solutions de pont de Bitlayer)
Analyse simplifiée du principe des ponts BitVM de Bitlayer et Citrea
Dans ce qui suit, nous utiliserons les schémas de pont BitVM publiés par Bitlayer, Citrea et Bob pour illustrer le fonctionnement général du pont BitVM.
Dans leurs documents officiels et blogs techniques, ces projets ont clairement exposé la logique de conception du pont de retrait BitVM (actuellement au stade théorique). Lorsqu’un utilisateur initie un retrait via le pont BitVM, un contrat Bridge sur la Layer2 génère une déclaration de retrait contenant les paramètres clés suivants :
-
La quantité de BTC mappés à brûler sur la L2 (ex : 1 BTC) ;
-
Les frais inter-chaînes que l’utilisateur souhaite payer (ex : 0,01 BTC) ;
-
L’adresse de réception sur L1 : L1_receipt ;
-
Le montant que l’utilisateur doit recevoir (soit 1 – 0,01 = 0,99 BTC)
Ensuite, cette déclaration de retrait est incluse dans un bloc de la Layer2. Les nœuds Relayer du pont BitVM surveillent les blocs de la Layer2, détectent les déclarations de retrait et les transmettent aux nœuds Operator, qui versent alors les fonds aux utilisateurs.
Il est important de noter que l’Operator avance lui-même les fonds sur la chaîne Bitcoin pour l’utilisateur, c’est-à-dire qu’il « avance » les fonds au pont BitVM, puis demande un remboursement auprès du pool de fonds du pont.
Pour demander un remboursement, l’Operator doit fournir une preuve de paiement sur la chaîne Bitcoin (prouvant qu’il a bien versé les fonds à l’adresse spécifiée par l’utilisateur, en extrayant l’enregistrement de transfert spécifique contenu dans un bloc Bitcoin). En outre, l’Operator doit produire la déclaration de retrait générée par l’utilisateur sur la L2 (via une preuve Merkle, prouvant que la déclaration provient bien d’un bloc L2 et n’a pas été fabriquée). Ensuite, l’Operator doit prouver les éléments suivants :
-
Le montant avancé par l’Operator à l’utilisateur correspond exactement au montant demandé dans la déclaration ;
-
Le montant demandé en remboursement ne dépasse pas la quantité de BTC mappés brûlés sur la Layer2 ;
-
L’Operator a bien traité toutes les déclarations de retrait L2→L1 sur une période donnée, chaque déclaration pouvant être appariée à un enregistrement de transfert sur la chaîne Bitcoin ;
Il s’agit fondamentalement d’une sanction contre un Operator qui ment sur le montant avancé ou refuse de traiter une déclaration de retrait (ce qui résout le problème de censure du pont). L’Operator doit comparer hors chaîne les champs clés de la preuve de paiement et de la déclaration de retrait, et prouver que les montants en BTC correspondent.
Si l’Operator du pont BitVM ment sur le montant avancé, cela signifie qu’il affirme que la preuve de paiement (payment proof) sur L1 correspond à la déclaration de retrait (withdrawal statement) sur L2, alors qu’en réalité elles ne correspondent pas.
Dans ce cas, la preuve ZK affirmant que Payment Proof = Withdrawal Statement contiendra nécessairement une erreur. Dès que cette preuve ZK est publiée, un challenger peut pointer l’étape erronée et lancer un défi via le protocole de preuve de fraude BitVM2.
Il convient de souligner que Bitlayer, Citrea, BOB, ZKBase et d'autres adoptent tous la nouvelle approche BitVM2, c’est-à-dire la version mise à jour du schéma BitVM, qui transforme les tâches de calcul hors chaîne en preuves ZK. Autrement dit, une preuve ZK est générée pour le processus de calcul hors chaîne, puis cette preuve est vérifiée, et le processus de vérification est ensuite adapté à BitVM pour faciliter les défis ultérieurs.
En outre, l'utilisation combinée des signatures Lamport et des pré-signatures permet d'optimiser le processus de défi interactif multi-étapes du BitVM initial en un défi non interactif en une seule étape, réduisant ainsi considérablement la difficulté du défi.
Le processus de défi BitVM nécessite un élément appelé « engagement » (commitment). Expliquons ce qu'est un « engagement ». Généralement, une personne publiant un « engagement » sur la chaîne Bitcoin affirme que certaines données stockées hors chaîne ou une tâche de calcul sont exactes, et la déclaration publiée sur la chaîne constitue cet « engagement ».
On peut assimiler approximativement un engagement au hachage d'un grand ensemble de données hors chaîne. La taille de l'engagement est souvent fortement compressée, mais il peut être lié, via un arbre de Merkle ou autre méthode, à une grande quantité de données hors chaîne, qui n'ont pas besoin d'être inscrites sur la chaîne.
Dans les schémas de pont BitVM2 de Citrea, BitLayer et d'autres, si quelqu'un pense que l'engagement publié sur la chaîne par l'Operator du pont de retrait est incorrect, et que cet engagement est lié à un processus de vérification ZKP invalide, il peut lancer un défi, et ce droit de défi est accessible à tous (permissionless). (Les flux d'interaction internes sont complexes et ne seront pas développés ici.)
Puisque l'Operator avance les fonds du pool BitVM pour payer les retraits, puis demande un remboursement à ce pool, lors de la demande, il doit publier un engagement prouvant que le montant transféré sur L1 à l'utilisateur correspond exactement au montant que l'utilisateur a déclaré vouloir recevoir sur L2. Si cet engagement n'est pas contesté pendant la période de défi, l'Operator peut retirer le montant de remboursement demandé.
Nous devons maintenant expliquer comment le pool de fonds public du pont BitVM est maintenu, car c'est justement la partie la plus critique du pont inter-chaînes. Tout le monde sait que les fonds que le pont peut verser aux retraits proviennent des dépôts des utilisateurs ou d'autres fournisseurs de liquidités (LP). Les fonds avancés par l'Operator doivent finalement être récupérés depuis le pool public. En regardant simplement le résultat du transfert des fonds, le montant total des dépôts (Deposit) absorbés par le pont BitVM doit être égal au montant total des retraits (Withdraw). La question de savoir comment gérer les fonds déposés est donc cruciale.
Dans la plupart des schémas de pont des Layer2 Bitcoin, les actifs publics sont gérés par multisignature. Les dépôts des utilisateurs sont regroupés dans un compte multisig, et lorsque des fonds doivent être versés à un utilisateur en retrait, ce compte multisig effectue le transfert. Ce schéma comporte évidemment un risque de confiance élevé.
Les ponts BitVM de Bitlayer et Citrea adoptent une approche similaire au réseau Lightning et aux canaux : avant de déposer, l'utilisateur communique avec la Fédération BitVM (BitVM Federation) pour obtenir une pré-signature, permettant d'obtenir le résultat suivant :
Une fois que l'utilisateur a transféré son dépôt à l'adresse de recharge, ces fonds sont directement verrouillés dans une adresse Taproot, qui ne peut être dépensée que par l'Operator du pont. De plus, l'Operator ne peut récupérer ces fonds qu'après avoir avancé les fonds de retrait à l'utilisateur, en demandant un remboursement à partir de cette adresse Taproot du dépôt. À l'issue de la période de défi, l'Operator peut retirer un montant spécifique du dépôt de l'utilisateur.
Dans le schéma du pont BitVM, il existe une Fédération BitVM composée de N membres, chargée d'orchestrer les dépôts des utilisateurs. Mais ces N membres ne peuvent pas s'approprier illégalement les dépôts des utilisateurs, car avant de transférer de l'argent à l'adresse désignée, l'utilisateur exige que la Fédération BitVM effectue une pré-signature, garantissant que ces dépôts ne peuvent être légalement réclamés que par l'Operator.
(Schéma de BitVM2 pour son schéma de pont optimiste)
En résumé, le pont BitVM adopte une logique similaire à celle des canaux et du réseau Lightning, permettant à l'utilisateur de « vérifier par lui-même » (verify by yourself), empêchant grâce à la pré-signature la Fédération BitVM de manipuler arbitrairement le pool de dépôts. L'argent du pool ne peut servir qu'à rembourser l'Operator. Si l'Operator fait une fausse déclaration sur le montant avancé, n'importe qui peut publier une preuve de fraude et lancer un défi.
Si ce schéma peut être mis en œuvre, le pont BitVM deviendra l'un des ponts de retrait Bitcoin les plus sûrs : il n'y a pas de problème de sécurité, seulement des problèmes de vivacité/disponibilité. Lorsqu'un utilisateur tente de déposer des fonds sur BitVM, il pourrait être censuré ou refusé par la Fédération BitVM, l'empêchant ainsi de déposer correctement. Mais cela relève de la vivacité/disponibilité, pas de la sécurité.
Cependant, la mise en œuvre du pont BitVM est très difficile, et ne peut pas non plus satisfaire les besoins spécifiques des gros acteurs exigeant une transparence financière : ces derniers pourraient avoir des préoccupations anti-blanchiment et ne souhaiteraient pas que leurs fonds soient mélangés avec ceux d'autres personnes. Or, le pont BitVM regroupe tous les dépôts dans un pool, qui devient en quelque sorte un « chaudron » mêlant de nombreuses sources de fonds.
Pour résoudre les problèmes de vivacité du pont BitVM et offrir à certains utilisateurs aux besoins particuliers un canal d'entrée-sortie financier indépendant et propre, l'équipe BitLayer a ajouté un schéma de pont inter-chaînes appelé OP-DLC, utilisant en complément du pont optimiste BitVM2 un pont DLC similaire à DLC.link, offrant ainsi aux utilisateurs deux options de sortie : le pont BitVM et le pont OP-DLC, réduisant ainsi la dépendance vis-à-vis du pont BitVM et de la Fédération BitVM.
(Schéma de principe du DLC)
DLC : Contrats de Journal Discrets
Le DLC (Discreet Log Contracts), ou « Contrats de Journal Discrets », a été proposé par le Digital Currency Initiative du MIT. Cette technologie permet initialement de mettre en œuvre des contrats intelligents légers sur Bitcoin, capables de fonctionner sans publier le contenu du contrat sur la chaîne, en utilisant des communications interactives hors chaîne et des pré-signatures pour réaliser des fonctions de contrats intelligents privés sur Bitcoin. Nous allons expliquer le fonctionnement du DLC à travers un exemple de pari sportif.
Supposons qu'Alice et Bob veulent parier sur le match Real Madrid-Barcelone dans trois jours, chacun misant 1 BTC. Si le Real Madrid gagne, Alice reçoit 1,5 BTC et Bob récupère 0,5 BTC, ce qui revient à un gain de 0,5 BTC pour Alice et une perte équivalente pour Bob. Si Barcelone gagne, Alice récupère 0,5 BTC et Bob empoche 1,5 BTC. En cas de match nul, chacun récupère 1 BTC.
Pour rendre ce pari non censurable, il faut empêcher toute tricherie. Une simple multisignature 2/2 ou 2/3 ne suffit pas. Le DLC propose une solution (qui dépend d’un oracle tiers). Le processus global peut être divisé en quatre grandes étapes.
Reprenons l'exemple d'Alice et Bob. Tout d'abord, ils créent hors chaîne une transaction « fund » qui verrouille leurs 1 BTC respectifs dans une adresse multisig 2/2. Si cette transaction est validée, les 2 BTC dans cette adresse ne peuvent être dépensés que si les deux parties autorisent.
Bien entendu, cette transaction « fund » n'est pas encore publiée sur la chaîne ; elle reste localement stockée dans les clients d'Alice et Bob. Ils savent tous deux quelles en seraient les conséquences si elle était validée. Pour l'instant, ils ne font que des simulations théoriques, puis concluent une série d'accords basés sur ces simulations.
À la première étape de création du DLC, on peut affirmer que les deux parties verrouilleront à l'avenir chacune 1 BTC dans une adresse multisig commune.
Deuxièmement, les deux parties poursuivent la simulation des événements futurs possibles et de leurs résultats : par exemple, après l'annonce du résultat du match, plusieurs scénarios sont possibles (Alice gagne/Bob perd, Alice perd/Bob gagne, match nul), conduisant à différentes distributions des 2 BTC verrouillés dans l'adresse multisig.
Chaque résultat doit être déclenché par une instruction de transaction différente. Ces « instructions de transaction susceptibles d'être publiées à l'avenir » sont appelées CET (Contract Execution Transaction). Alice et Bob doivent anticiper tous les CET possibles et générer un jeu complet de données de transaction.
Par exemple, selon les différents résultats possibles du pari entre Alice et Bob, Alice crée les CET suivants :
-
CET1 : Alice peut récupérer 1,5 BTC de l'adresse multisig, Bob récupère 0,5 BTC ;
-
CET2 : Alice peut récupérer 0,5 BTC de l'adresse multisig, Bob récupère 1,5 BTC ;
-
CET3 : Chaque partie récupère 1 BTC.
Prenons l'exemple du CET1 (Alice obtient 1,5 BTC, Bob obtient 0,5 BTC) :
Cette transaction signifie que 1,5 BTC de l'adresse multisig sont transférés vers une adresse Taproot déclenchée conjointement par Alice et par le résultat signé de l'oracle, tandis que 0,5 BTC sont transférés à l'adresse de Bob. Ce scénario correspond à : le Real Madrid gagne, Alice gagne 0,5 BTC, Bob perd 0,5 BTC.
Bien sûr, pour dépenser ces 1,5 BTC, Alice doit obtenir la signature de l'oracle attestant que « le Real Madrid a gagné ». Autrement dit, Alice ne pourra transférer ces 1,5 BTC que lorsque l'oracle aura publié le message « victoire du Real ». Quant aux contenus de CET2 et CET3, on peut raisonner de manière analogue, sans entrer ici dans les détails.
Il faut noter que le CET est essentiellement une transaction en attente de publication sur la chaîne. Que se passe-t-il si Alice diffuse prématurément CET1, ou si elle publie CET1 alors que « Barcelone a gagné », alors que CET1 ne devrait être déclenché que si « le Real Madrid a gagné » ?
Sur le schéma précédent, on voit que si CET1 est publié, les 2 BTC verrouillés dans l'adresse multisig originale sont transférés : 0,5 BTC à Bob, et 1,5 BTC vers une adresse Taproot, que seule Alice peut débloquer après réception de la signature « Real Madrid gagne » de l'oracle. Résultat illustré ci-dessous.
En outre, cette adresse Taproot est soumise à un verrou temporel (timelock). Si, durant la période définie par le timelock, Alice ne parvient pas à récupérer les 1,5 BTC, Bob a le droit de s'approprier ces fonds.
Ainsi, tant que l'oracle est honnête, Alice ne peut pas récupérer ces 1,5 BTC. Une fois le délai écoulé, Bob peut s'emparer de la somme. Ajoutés aux 0,5 BTC que CET1 a déjà transférés à Bob, Bob récupère finalement la totalité des fonds.
Pour Alice, quelle que soit l'issue, la meilleure stratégie est de publier le bon CET ; publier un CET invalide lui ferait perdre davantage d'argent.
En réalité, lors de la construction du CET, la signature schnorr de Taproot a été améliorée : on peut comprendre cela comme l'utilisation de la clé publique de l'oracle + le résultat de l'événement pour construire des adresses indépendantes selon chaque résultat. Ensuite, seule la signature correspondant à un résultat donné permettra de dépenser les BTC verrouillés sur l'adresse associée.
Bien sûr, un autre scénario est possible. Supposons qu'Alice sache qu'elle a perdu et décide de ne pas publier son CET1. Que faire dans ce cas ? C’est simple : Bob peut créer un CET personnalisé pour l’événement « Alice perd, Bob gagne », ayant un effet similaire au CET d’Alice, avec des détails différents mais un résultat identique.
Ce qui précède décrit le processus crucial de construction des CET. La troisième étape du DLC consiste pour Alice et Bob à communiquer, à vérifier mutuellement les CET créés par l'autre, à y apposer leur signature, puis, une fois tout vérifié, à chacun déposer 1 BTC dans l'adresse multisig 2/2 mentionnée au départ, en attendant qu'un CET soit publié pour déclencher la suite.
Enfin, lorsque l'oracle publie le résultat et que sa signature est disponible, n'importe quelle partie peut publier le CET correct, redistribuant les 2 BTC verrouillés. Si le perdant publie prématurément un CET incorrect, il perd tous ses fonds. S'il publie le bon CET, il peut encore récupérer 0,5 BTC.
On pourrait se demander : Quelle est la différence entre un DLC et une multisignature 2/3 classique ? Premièrement, dans un schéma 2/3, deux parties peuvent s'entendre pour voler tous les fonds. Avec le DLC, en préconstruisant l'ensemble des CET, les adversaires se limitent mutuellement à tous les scénarios possibles. Même si l'oracle comparaît, les pertes restent généralement limitées.
Deuxièmement, dans une multisig, toutes les parties doivent signer la transaction précise à publier. En revanche, dans le cadre du DLC, l'oracle n'a besoin que de signer le résultat d'un événement spécifique, sans connaître le contenu du CET ou de la transaction à publier, voire sans savoir qu'Alice et Bob existent. Il interagit simplement comme un oracle normal avec les utilisateurs.
On peut considérer que le DLC transforme la confiance accordée aux signataires en confiance accordée à l'oracle. Tant que l'oracle n'est pas malhonnête, le protocole DLC est suffisamment non censurable. Théoriquement, le DLC peut utiliser un oracle tiers mature et éprouvé pour éviter les comportements malveillants. C’est ce que font DLC.link et BitLayer, en reportant le problème de confiance du pont sur un oracle tiers.
En outre, le pont DLC de Bitlayer prend en charge des nœuds d'oracle auto-hébergés, auxquels il ajoute une couche de preuve de fraude : si l'oracle auto-géré publie un CET invalide, n'importe qui peut le contester. Nous développerons ci-dessous le principe de son pont OP-DLC.
Pont OP-DLC : canal DLC + preuve de fraude
Nous allons expliquer le fonctionnement du pont OP-DLC à travers le processus complet de dépôt et de retrait. Supposons qu'Alice dépose 1 BTC via le pont OP-DLC sur la L2. Selon un mécanisme en deux étapes, Alice génère d'abord une transaction « pre-fund », comme illustré ci-dessous :
Il s'agit en réalité de transférer d'abord 1 BTC vers une adresse Taproot contrôlée conjointement par Alice et un membre de la Fédération BitVM, puis d'initier le processus de création des CET. Si la Fédération BitVM refuse de coopérer avec la demande de dépôt d'Alice, Alice peut récupérer immédiatement ses fonds après expiration du timelock.
Si la Fédération BitVM accepte de coopérer, les deux parties génèrent hors chaîne une transaction de dépôt formelle (fund transaction, non encore publiée) et tous les CET possibles pour les scénarios de retrait. Une fois les CET générés et vérifiés, les deux parties publient la transaction fund sur la chaîne.
Dans les données Witness/signature de la transaction fund, Alice spécifie son adresse de réception sur la Layer2. Une fois la transaction fund publiée, Alice peut soumettre ces données au contrat de pont sur la L2 pour prouver qu'elle a bien effectué un dépôt sur la chaîne Bitcoin, ce qui lui donne droit à la libération de jetons sur l'adresse désignée par le contrat de pont L2.
Une fois la transaction fund validée, les fonds restent verrouillés dans une adresse Taproot multisig contrôlée conjointement par Alice et la Fédération BitVM. Mais attention : cette multisig ne peut être débloquée que par les CET. La Fédération BitVM ne peut pas transférer les fonds arbitrairement.
Examinons maintenant les CET pré-construits par Alice et la Fédération BitVM. Ces CET couvrent les scénarios potentiels de retrait futurs. Par exemple, Alice a déposé 1 BTC, mais lors de son premier retrait, elle ne retire que 0,3 BTC, et laisse les 0,7 BTC restants à la disposition du pool public de la Fédération BitVM, mais pour tout nouveau retrait, elle devra passer par le pont BitVM décrit précédemment.
Ou bien, elle pourrait utiliser ces 0,7 BTC pour initier un nouveau dépôt « pre-fund », comme un nouvel actif déposé sur le pont DLC, et répéter le processus de transaction fund et de construction de CET décrit précédemment.
Ce processus est simple : Alice et la Fédération BitVM agissent comme adversaires, créant des CET pour différents montants de retrait, puis l’oracle lit la déclaration de retrait d’Alice sur la L2 pour déterminer quel CET elle souhaite activer (combien elle veut retirer).
Le risque ici est que l’oracle puisse conspirer avec la Fédération BitVM. Par exemple, si Alice déclare vouloir retirer 0,5 BTC, l’oracle pourrait falsifier la déclaration, faisant ainsi publier un CET erroné où « Alice récupère 0,1 BTC, la Fédération BitVM reçoit 0,9 BTC ».
Plusieurs solutions existent. La première consiste à utiliser un oracle tiers bien conçu, rendant très difficile toute collusion avec la Fédération BitVM. Ou bien, l’oracle peut être mis en gage (staking) : il doit publier régulièrement sur la chaîne Bitcoin un engagement attestant qu’il a honnêtement traité les demandes de retrait. N’importe qui peut contester cet engagement via le protocole de preuve de fraude BitVM ; en cas de succès, l’oracle malhonnête est pénalisé (slashed).
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
@godrealmx
