Résumé: Les ponts ZK déploient des contrats intelligents sur la Chaîne A pour recevoir et vérifier directement les en-têtes de bloc et les preuves de connaissance nulle correspondantes de la Chaîne B, confirmant la validité des messages inter-chaînes. Il s'agit du schéma de pont le plus sécurisé.

• Les ponts Optimistic/OP utilisent des preuves de fraude pour contester les messages de chaîne croisée invalides sur la chaîne. La présence d'un seul challenger fiable peut garantir la sécurité du pool de fonds du pont de chaîne croisée.
• En raison de limitations techniques, le mainnet Bitcoin ne peut pas directement déployer de ponts ZK, mais peut réaliser des ponts optimistes grâce à BitVM et des preuves de fraude. Des équipes comme Bitlayer et Citrea ont adopté le schéma de pont BitVM, introduisant la pré-signature et incorporant des concepts de canal, permettant aux utilisateurs de prédéfinir le processus de traitement après l'exécution du dépôt, empêchant le pont inter-chaînes de détourner les dépôts des utilisateurs.
• Le pont BitVM fonctionne essentiellement selon un modèle de "prépaiement-remboursement", avec des nœuds Opérateurs spécifiques fournissant des fonds aux utilisateurs de retrait. Les Opérateurs peuvent périodiquement demander un remboursement à partir d'une adresse de dépôt publique. Si un Opérateur soumet une fausse demande de remboursement, il peut être contesté et réduit par n'importe qui.
• Bien que théoriquement sécurisé, le pont BitVM présente des problèmes de vivacité/utilisabilité et ne répond pas aux besoins spécifiques des utilisateurs en matière d'indépendance financière et de lutte contre le blanchiment d'argent (car il utilise essentiellement un modèle de pool de fonds). Bitlayer aborde cette question avec une solution de pont OP-DLC. Cette solution, similaire à DLC.link, introduit des preuves de fraude basées sur des canaux et des DLC pour prévenir les malversations des oracles.
• Étant donné la difficulté de mettre en œuvre BitVM et des preuves de fraude, les ponts DLC seront déployés en premier comme substitut temporaire. Tant que les risques de confiance des oracles sont résolus et que des oracles tiers plus fiables et matures sont intégrés, les ponts DLC peuvent devenir un schéma de vérification de retrait plus sûr que les ponts multi-signatures à l'étape actuelle.

Introduction: Depuis la folie des inscriptions de l'année dernière, l'écosystème Bitcoin est entré dans une période de croissance rapide. En seulement six mois, le nombre de projets sous la bannière de BTC Layer2 a atteint près de 100. Il est simplement devenu un nouveau continent plein de chaos, où les opportunités et les arnaques coexistent. Il n'est pas exagéré de dire que l'écosystème Bitcoin actuel est déjà un "creuset multiethnique" d'Ethereum, Cosmos et Celestia, CKB et l'écosystème natif de Bitcoin. Associé au manque de voix autoritaires, l'écosystème Bitcoin ressemble simplement à celui du XIXe siècle. Comme les États-Unis, il est devenu un nouveau monde qui attire des forces de tous horizons. Si cela apporte prospérité et vitalité à l'ensemble du récit Web3, cela introduit également d'énormes risques.

De nombreux projets ont commencé à faire de la publicité sans même avoir publié de solutions techniques, en utilisant le nom de la couche 2 native, affirmant qu'ils peuvent hériter complètement de la sécurité du réseau principal de Bitcoin; certains utilisent même des techniques de propagande pour créer des concepts, inventant une série de noms et termes étranges pour promouvoir leur propre supériorité. Bien que la vantardise soit déjà l'état actuel de l'écosystème Bitcoin, il existe encore de nombreux KOLs de premier plan qui ont fait des appels objectifs.

Il n'y a pas si longtemps, Monanaut, le fondateur du navigateur blockchain Mempool, a critiqué publiquement les problèmes actuels de l'écosystème Bitcoin. Il a vivement souligné que si un Layer 2 Bitcoin utilise simplement un pont de retrait multi-signature et ne permet pas aux utilisateurs de retirer des actifs à tout moment de manière décentralisée, un tel projet n'est pas un vrai Layer 2. Fait intéressant, Vitalik a précédemment souligné que le Layer 2 devrait au moins être plus sécurisé en termes de sécurité que les systèmes qui reposent uniquement sur des multi-signatures.

On peut dire que Monanaut et Vitalik ont pointé du doigt les problèmes techniques de Bitcoin Layer 2 : de nombreux ponts de retrait L2 sont essentiellement des ponts multi-signatures. Soit plusieurs institutions bien connues détiennent chacune une clé, soit une signature décentralisée basée sur POS est utilisée, mais dans tous les cas, son modèle de sécurité est basé sur l'hypothèse de majorité d'honnêteté, c'est-à-dire qu'il suppose que la majorité des participants à la multi-signature ne collaborent pas pour faire le mal.

Ce genre de solution de pont de retrait qui repose fortement sur l'aval de crédit n'est en aucun cas une solution à long terme. L'histoire nous a montré que les ponts à signatures multiples auront tôt ou tard divers problèmes. Seule la confiance est minimisée ou la garde d'actifs a tendance à être complètement sans confiance. Ce n'est que de cette manière qu'elle peut résister à l'épreuve du temps et des pirates informatiques. Mais la situation actuelle de l'écosystème Bitcoin est que de nombreux acteurs de projets n'ont même pas publié de feuille de route technique pour le pont de retrait. Il n'y a pas d'idée de conception établie sur la manière dont le pont devrait être fiable ou minimisé.

Mais ce n'est pas tout de l'écosystème Bitcoin. Il y a encore des chefs de projet qui ont exprimé leurs opinions sur les idées d'optimisation du pont de retrait. dans le texte, nous analyserons brièvement le pont Bitlayer et Citrea BitVM, et présenterons le pont OP-DLC proposé par Bitlayer pour remédier aux lacunes du pont BitVM, afin que plus de personnes puissent comprendre les risques et les idées de conception des ponts inter-chaînes. Ceci est crucial pour la majorité des participants à l'écosystème Bitcoin.

Pont optimiste : Un schéma de vérification de pont basé sur la preuve de fraude

En fait, l'essence du pont inter-chaînes est très simple, il s'agit de prouver à la chaîne B qu'un certain événement s'est produit sur la chaîne A. Par exemple, si vous transférez des actifs de l'ETH vers Polygon, vous avez besoin du pont inter-chaînes pour vous aider à prouver que vous avez effectivement transféré des actifs à une adresse spécifique sur la chaîne ETH, puis vous pouvez recevoir le même montant de fonds sur la chaîne Polygon.

Les ponts inter-chaînes traditionnels utilisent généralement une signature multi-témoins. Ils désignent plusieurs témoins sous la chaîne. Les témoins exécuteront les nœuds de chaque chaîne publique et surveilleront si quelqu'un a déposé des fonds à l'adresse de paiement du pont inter-chaînes.

Le modèle de sécurité de ce type de pont inter-chaînes est essentiellement le même que celui des portefeuilles multi-signatures. Le modèle de confiance doit être déterminé en fonction de la méthode de configuration multi-signature telle que M/N, mais à la fin, il suit essentiellement l'hypothèse de la majorité honnête, ce qui signifie que la plupart des notaires ne sont par défaut pas malveillants et le taux de tolérance aux fautes est relativement limité. De nombreux cas de vol de ponts inter-chaînes à grande échelle qui se sont produits auparavant se sont essentiellement tous produits sur ce type de ponts multi-signatures, soit en raison d'un vol, soit par des pirates informatiques.

En revanche, le « pont optimiste » basé sur le protocole anti-fraude et le « pont ZK » basé sur ZK sont beaucoup plus sûrs. Si l’on prend l’exemple de ZK Bridge, il mettra en place un contrat de validation dédié sur la chaîne cible pour vérifier directement le certificat de retrait sur la chaîne, éliminant ainsi le besoin de dépendre de témoins hors chaîne.

Par exemple, un pont ZK couvrant ETH et Polygon déploiera un contrat de vérificateur sur Polygon, appelons-le Verifier pour l'instant. Le nœud Relayer du pont ZK transmettra l'en-tête de bloc Ethereum le plus récent et la preuve ZK prouvant la validité au Verifier, qui le vérifiera. Cela revient à avoir le contrat Verifier synchronisé sur la chaîne Polygon et à vérifier l'en-tête de bloc Ethereum le plus récent. La racine de Merkle enregistrée dans l'en-tête de bloc est liée à l'ensemble de transactions contenu dans le bloc et peut être utilisée pour vérifier si une certaine transaction est incluse dans le bloc.

Si le bloc Ethereum avec une hauteur de bloc de 101 contient 10 déclarations de transfert inter-chaînes d'ETH vers Polygon, Relayer générera une preuve de Merkle liée à ces 10 transactions et soumettra la preuve au contrat Verifier sur la chaîne Polygon :

Le bloc Ethereum n°101 contient 10 transactions inter-chaînes d'ETH vers Polygon. Bien sûr, le pont ZK peut convertir la preuve de Merkle en ZK et soumettre directement la preuve ZK au contrat Vérificateur. Pendant tout ce processus, les utilisateurs n'ont besoin de faire confiance qu'au fait que le contrat intelligent du pont inter-chaînes n'a pas de failles, et que la technologie de preuve de connaissance nulle elle-même est sûre et fiable. Il n'est pas nécessaire d'introduire trop d'hypothèses de confiance comme c'est le cas avec les ponts traditionnels à multi-signatures.

et le “Pont Optimiste” est légèrement différent. Certains ponts optimistes conservent des paramètres similaires à ceux des témoins, mais introduisent des preuves de fraude et des fenêtres de contestation. Après que le témoin génère une signature multiple pour le message inter-chaîne, bien qu'il soit soumis à la chaîne cible, sa validité ne sera pas reconnue immédiatement. Il doit passer une période de fenêtre et personne ne le remet en question avant qu'il ne puisse être jugé comme valide. C'est en fait quelque peu similaire à l'idée de Rollup Optimiste. Bien sûr, le Pont Optimiste a d'autres modèles de produit, mais en fin de compte, la sécurité est garantie par le protocole de preuve de fraude.

L'hypothèse de confiance du pont multi-signature M/N est N-(M-1)/N. Vous devez supposer que le nombre de personnes malveillantes dans le réseau est au plus M-1, et que le nombre de personnes honnêtes est au moins N-(M-1). L'hypothèse de confiance du pont ZK est négligeable, tandis que l'hypothèse de confiance du pont optimiste basé sur la preuve de fraude est de 1/N. Un seul des N témoins doit être honnête et prêt à contester les messages transversaux invalides soumis à la chaîne cible pour assurer la sécurité du pont.

À l'heure actuelle, en raison de limitations techniques, seul le pont ZK dans la direction du dépôt de Bitcoin vers la couche 2 peut être implémenté. Si la direction est inversée et que des retraits sont effectués de la couche 2 vers la chaîne Bitcoin, seuls les ponts multi-signatures ou les ponts optimistes, ou des modèles de type canaux sont pris en charge. (Le pont OP-DLC à décrire ci-dessous ressemble davantage à un canal). Pour mettre en œuvre un pont optimiste sur la chaîne Bitcoin, une preuve de fraude doit être introduite, et BitVM a créé de bonnes conditions pour la mise en œuvre de cette technologie.

dans les articles précédentsUne interprétation minimaliste de BitVM : Comment vérifier les preuves de fraude sur la chaîne BTC, nous avons brièvement introduit, L'essence de la preuve de fraude de BitVM consiste à décomposer les tâches de calcul complexes effectuées hors chaîne en un grand nombre d'étapes simples, puis à sélectionner une certaine étape à vérifier directement sur la chaîne Bitcoin.. Cette idée est similaire aux rollups optimistes d'Ethereum tels qu'Arbitrum et Optimism.

(La documentation de BitVM2 mentionne qu'une tâche informatique sera divisée en un grand nombre d'étapes intermédiaires grâce à des signatures de Lamport, puis n'importe qui peut contester une étape intermédiaire)

Bien sûr, la déclaration ci-dessus est encore relativement obscure, mais je crois que la plupart des gens ont déjà compris le sens du certificat de fraude. Dans l'article d'aujourd'hui, en raison des limites d'espace globales, nous n'avons pas l'intention d'expliquer les détails de mise en œuvre technique de BitVM et du protocole de preuve de fraude, car cela implique une série de processus d'interaction complexes.

Nous allons brièvement présenter BitLayer, Citrea, BOB et même le pont BitVM natif officiellement conçu par BitVM du point de vue de la conception du produit et du mécanisme, et comment Bitlayer soulage le goulot d'étranglement du pont BitVM grâce au pont OP-DLC, pour vous montrer comment concevoir une solution de pont de retrait supérieure sur la chaîne Bitcoin.

(Schéma du solution de pontage de Bitlayer)

Une brève analyse du principe de pont BitVM entre Bitlayer et Citrea

ci-dessous, nous utilisons la solution de pont BitVM annoncée par Bitlayer, Citrea et Bob comme matériel pour illustrer le processus opérationnel général du pont BitVM.

Dans ses documents officiels et ses blogs techniques, la partie du projet susmentionnée a clairement expliqué les idées de conception de produit du pont de retrait BitVM (actuellement à l'étape théorique). Tout d'abord, lorsqu'un utilisateur retire de l'argent via le pont BitVM, il ou elle doit utiliser le contrat de pont sur la couche 2 pour générer une déclaration de retrait. Les paramètres clés suivants sont spécifiés dans la déclaration de retrait:

Le nombre de BTC mappés que le retraitant doit détruire en L2 (comme 1 BTC);

Les frais de traitement de chaîne croisée que le retraitant a l'intention de payer (supposé être 0,01 BTC) ;

L'adresse de retrait du retraitant en L1: reçu L1;

Le montant du retrait du retirant (c.-à-d. 1 — 0.01 = 0.99BTC)

Ensuite, la déclaration de retrait ci-dessus sera incluse dans le bloc Layer2. Le pont BitVM Le nœud Relayer synchronisera le bloc Layer2, surveillera la déclaration de retrait qui y est contenue et la transférera au nœud Opérateur, qui paiera l'utilisateur de retrait.

Ce qu'il faut noter ici, c'est que l'opérateur paie d'abord les utilisateurs sur la chaîne Bitcoin de sa propre poche, c'est-à-dire qu'il "avance" des fonds pour le pont BitVM, puis demande une indemnisation au fonds de la piscine du pont BitVM.

Lors de la demande de remboursement, l'opérateur doit fournir une preuve de paiement anticipé sur la chaîne Bitcoin (c'est-à-dire prouver qu'il a transféré de l'argent à l'adresse spécifiée par l'utilisateur de retrait sur L1, et doit extraire l'enregistrement de transfert spécifique contenu dans le bloc Bitcoin). En même temps, l'opérateur doit également émettre une déclaration de retrait générée par le retraité en L2 (à travers Merkle Proof, il est prouvé que la déclaration de retrait émise provient du bloc L2 et n'est pas fabriquée de toutes pièces). Ensuite, l'opérateur doit prouver ce qui suit:

Les fonds avancés par l'opérateur au tireur pour le compte du pont BitVM sont égaux au montant demandé par le tireur dans la déclaration;

Lorsque l'opérateur demande un remboursement, le montant du remboursement ne doit pas dépasser le montant de BTC mappé détruit par le retrait dans la couche 2;

L'opérateur a effectivement traité toutes les déclarations de retrait L2-L1 dans un laps de temps, et chaque déclaration de retrait peut être associée à l'enregistrement de transfert de retrait sur la chaîne Bitcoin;

Il s'agit essentiellement d'une punition pour l'Opérateur qui ment sur le montant de l'avance ou refuse de traiter le relevé de retrait (ce qui peut résoudre le problème de résistance à la censure du pont de retrait). L'Opérateur doit comparer et vérifier hors chaîne les champs clés du certificat de paiement anticipé et du relevé de retrait pour prouver que le montant de BTC impliqué dans les deux est égal.

Si l'opérateur du pont de retrait rapporte faussement le montant avancé, cela signifie que l'opérateur affirme que la preuve de paiement sur L1 correspond à l'état de retrait émis par le retraitant de L2, mais la situation réelle est que les deux ne correspondent pas.

De cette manière, cela prouve que la ZKP de Payment Proof = Withdrawal Statement doit être incorrecte. Dès que cette ZKP est publiée, le Challenger peut indiquer quelle étape est incorrecte et la contester grâce au protocole de preuve de fraude de BitVM2.

Ce qui doit être souligné, c'est que Bitlayer, Citrea, BOB, ZKBase, etc. ont tous adopté la dernière route BitVM2, qui est la nouvelle version de la solution BitVM. Cette solution ZKisera les tâches de calcul hors chaîne, c'est-à-dire générer une preuve ZK pour le processus de calcul hors chaîne, puis vérifier la preuve, et ensuite convertir le processus de vérification de ZKP en adapté à la forme de BitVM pour faciliter les défis ultérieurs.

en même temps, en utilisant Lamport et la pré-signature, le défi interactif multi-tours de l'original BitVM peut être optimisé en un défi non interactif à un seul tour, réduisant considérablement la difficulté du défi.

Le processus de défi de BitVM nécessite l'utilisation de quelque chose appelé « engagement », c'est-à-dire Engagement. Expliquons ce qu'est un « engagement ». En général, quelqu'un qui publie un « engagement » sur la chaîne Bitcoin affirmera que certaines données stockées hors chaîne/les tâches de calcul se produisant hors chaîne sont exactes, et la déclaration pertinente publiée sur la chaîne est un « engagement ».

On peut comprendre approximativement l'Engagement comme un hachage d'une grande quantité de données hors chaîne. La taille de l'Engagement lui-même est souvent très compressée, mais il peut être lié à une grande quantité de données hors chaîne grâce à des méthodes telles que l'Arbre de Merkle, et ces données hors chaîne associées n'ont pas besoin d'être téléchargées sur la chaîne.

Dans la solution de pont BitVM de BitVM2 et Citrea et BitLayer, si quelqu'un pense qu'il y a un problème avec l'engagement émis par l'opérateur de pont de retrait sur la chaîne, et que l'engagement est associé à un processus de vérification ZKP invalide, il ou elle peut lancer un défi, et l'autorité de défi est sans autorisation. (Le processus d'interaction à l'intérieur est relativement compliqué et ne sera pas expliqué ici)

Étant donné que l’opérateur avance des fonds pour le pool de fonds BitVM pour payer le retrait, puis demande ensuite un remboursement au pool de fonds, lors de la demande, l’opérateur doit émettre un engagement pour prouver que l’argent qu’il transfère au retrait sur L1 est égal au retrait. Le payeur déclare sur L2 qu’il veut recevoir l’argent. Si l’Engagement a dépassé la période de contrôle de la fraude et n’a pas été contesté, l’Opérateur peut retirer le montant de remboursement dont il a besoin.

Ici, nous voulons expliquer comment le pool de fonds public du pont BitVM est maintenu, et c'est précisément la partie la plus critique du pont inter-chaînes. Comme nous le savons tous, les fonds que le pont inter-chaînes peut payer au tiré proviennent des actifs contribués par les déposants ou autres LP, et l'argent avancé par l'opérateur sera finalement retiré du pool de fonds public, donc tout dépend uniquement des fonds. En raison du transfert, le montant du dépôt du déposant absorbé par le pont BitVM doit être égal au montant de retrait du retirant. Ainsi, comment conserver les fonds de dépôt est une question très importante.

Dans la plupart des solutions de pontage de la couche 2 de Bitcoin, les actifs publics sont souvent gérés via une multi-signature. Les dépôts des utilisateurs sont regroupés dans un compte multi-signature. Lorsqu'un retrait doit être effectué, ce compte multi-signature est responsable du paiement. Il y a évidemment un énorme risque de confiance dans cette solution.

Le pont BitVM de Bitlayer et Citrea adopte des idées similaires au réseau Lightning et aux canaux. Avant de faire un dépôt, l'utilisateur communiquera d'abord avec l'Alliance BitVM et demandera à ce dernier de pré-signer pour obtenir les effets suivants :

Après que l'utilisateur transfère le dépôt à l'adresse de recharge, l'argent sera directement verrouillé dans une adresse Taproot et ne pourra être collecté que par l'opérateur du pont. De plus, l'opérateur ne pourra réclamer les fonds de l'adresse Taproot du dépôt susmentionné qu'après avoir avancé les fonds de retrait à l'utilisateur. Après la fin de la période de contestation, l'opérateur pourra retirer une certaine somme des dépôts des utilisateurs.

Dans la solution de pont BitVM, il existe une Fédération BitVM (Fédération BitVM) formée par N membres, qui planifient les dépôts des utilisateurs. Cependant, ces N membres ne peuvent pas détourner les dépôts des utilisateurs de manière privée, car les utilisateurs exigeront que l'Alliance BitVM pré-signer avant de transférer de l'argent à l'adresse désignée pour garantir que ces dépôts ne peuvent être réclamés légalement que par l'Opérateur.

(Diagramme de la solution de pont optimiste de BitVM2)

Pour résumer à un niveau élevé, BitVM Bridge adopte des idées similaires à celles des canaux et des réseaux d'éclairage, permettant aux utilisateurs de "vérifier par eux-mêmes" et empêchant l'Alliance BitVM de manipuler le pool de dépôts sans autorisation grâce à la pré-signature. L'argent dans le pool de dépôts ne peut être utilisé que pour rembourser l'opérateur. Si un opérateur falsifie le montant de l'avance, n'importe qui peut fournir une preuve de fraude et la contester.

Si la solution ci-dessus peut être mise en œuvre, le pont BitVM deviendra l'un des ponts de retrait de Bitcoin les plus sûrs : Il n'y a pas de problèmes de sécurité avec ce pont, seulement des problèmes de disponibilité/fiabilité. Lorsque les utilisateurs essaient de déposer des fonds sur BitVM, ils peuvent être censurés ou refusés de coopérer par l'Alliance BitVM, ce qui entraîne l'incapacité de déposer des fonds avec succès. Cependant, cela n'a rien à voir avec la sécurité mais est un problème de fiabilité/disponibilité.

Cependant, la mise en œuvre du pont BitVM est relativement difficile. De plus, il ne peut pas répondre aux besoins de certains grands investisseurs qui ont des exigences relativement élevées en matière de transparence des fonds : ces personnes peuvent être impliquées dans des questions de lutte contre le blanchiment d’argent et ne pas vouloir mélanger leurs propres fonds avec ceux d’autres personnes, mais le pont BitVM acceptera uniformément l’argent des déposants. , d’une certaine manière, c’est une piscine où beaucoup d’argent est mélangé.

Afin de résoudre le problème d'activité de pont BitVM mentionné ci-dessus et de fournir un canal d'entrée et de sortie de fonds indépendant et propre pour les personnes ayant des besoins spécifiques, l'équipe BitLayer a ajouté une solution de pont inter-chaînes supplémentaire appelée OP-DLC. En plus du pont optimiste de BitVM2, un pont DLC similaire à DLC.link est utilisé. Fournir aux utilisateurs deux entrées et sorties, le pont BitVM et le pont OP-DLC, pour réduire la dépendance au pont BitVM et même à l'Alliance BitVM.

(schéma de circuit DLC)

DLC: Contrat de journal prudent

DLC (Discreet Log Contracts) est appelé contrat de journal discret. Il a été proposé par l'Initiative de la monnaie numérique du MIT. Cette technologie a d'abord été utilisée pour mettre en œuvre un contrat intelligent léger sur Bitcoin. Il ne nécessite pas que le contenu du contrat soit téléchargé sur la chaîne. À travers des méthodes telles que la communication interactive hors chaîne et la pré-signature, des fonctions de contrat intelligent protégeant la vie privée sont mises en œuvre sur la chaîne Bitcoin. Ci-dessous, nous utilisons un cas de jeu pour illustrer le principe de fonctionnement du DLC.

Supposons qu'Alice et Bob veuillent parier sur le résultat du match entre le Real Madrid et Barcelone qui aura lieu trois jours plus tard, et que chacun d'eux paie 1 btc. Si le Real Madrid gagne, Alice peut obtenir 1,5 BTC, et Bob ne peut récupérer que 0,5 BTC, ce qui équivaut à ce qu'Alice gagne 0,5 BTC, et Bob perd 0,5 BTC ; si Barcelone gagne, Alice ne peut récupérer que 0,5 BTC, et Bob peut emporter 1,5 BTC. En cas d'égalité, les deux joueurs récupéreront chacun 1 BTC.

Si nous voulons rendre le processus de jeu sans confiance, nous devons trouver des moyens d’empêcher toute partie de tricher. Si nous utilisons simplement 2/2 multi-signature ou 2/3 multi-signature, ce n’est évidemment pas assez fiable. DLC fournit sa propre solution à ce problème (en s’appuyant sur des oracles tiers). L’ensemble du flux de travail peut être grossièrement divisé en quatre parties.

Prenons l'exemple précédent d'Alice et Bob. Tout d'abord, les deux parties créent une transaction de fonds hors chaîne, qui peut verrouiller 1 BTC de chacun sur l'adresse multi-signature 2/2. Si cette transaction de fonds prend effet, les 2 BTC sur l'adresse multi-signature doivent être autorisés par les deux parties avant de pouvoir être dépensés.

Bien sûr, cette transaction de fonds n'est pas encore téléchargée sur la chaîne, mais reste locale aux clients Alice et Bob hors chaîne. Ils savent tous quelles seront les conséquences après que cette transaction prend effet. Pour l'instant, les deux parties ne font que des déductions théoriques puis parviennent à une série d'accords basés sur les résultats des déductions.

Dans la première phase de la création de DLC, ce que nous pouvons déterminer, c'est que les deux parties bloqueront leur 1 BTC dans une adresse multi-signature à l'avenir.

Dans la deuxième étape, les deux parties continuent à déduire les événements futurs possibles et les résultats : Par exemple, lorsque les résultats du match de football sont annoncés, il peut y avoir plusieurs possibilités telles que Alice gagne et Bob perd, Alice perd et Bob gagne, un match nul, etc. Cela entraînera des résultats de distribution différents des Bitcoins dans l'adresse multi-signature 2/2 susmentionnée.

Des résultats différents doivent être déclenchés par des instructions commerciales différentes. Ces "Instructions de transaction qui peuvent être téléchargées sur la chaîne à l'avenir" sont appelées CET, c'est-à-dire Contrat d'Exécution de Transaction. Alice et Bob doivent déduire tous les CET à l'avance et générer un ensemble de données de transaction contenant tous les CET.

Par exemple, en fonction des résultats possibles du pari entre Alice et Bob mentionné ci-dessus, Alice crée les CET suivants :

CET1：Alice peut obtenir 1,5 BTC de l'adresse multi-signature, et Bob peut obtenir 0,5 BTC;

CET2: Alice peut obtenir 0.5 BTC de l'adresse multi-signature, et Bob peut obtenir 1.5 BTC;

CET3: Les deux parties peuvent recevoir 1 BTC chacune.

Prenons CET1 comme exemple (Alice reçoit 1.5 BTC, Bob reçoit 0.5 BTC) :

La signification de cette transaction est de transférer 1,5 BTC à l'adresse multi-signature à une adresse Taproot déclenchée par les résultats de sortie d'Alice et de la machine oracle, et de transférer les 0,5 BTC restants à l'adresse de Bob. Les événements correspondants à ce moment-là sont : le Real Madrid gagne, Alice gagne 0,5 BTC et Bob perd 0,5 BTC.

Bien sûr, pour dépenser ces 1,5 BTC, Alice doit obtenir la signature du résultat "Real Madrid gagne" envoyée par l'oracle. En d'autres termes, seulement lorsque l'oracle produit le message "Real Madrid gagne", Alice peut transférer les 1,5 BTC. Quant au contenu de CET2 et CET3, nous pouvons les déduire de la même manière et n'entrerons pas dans les détails ici.

Il convient de noter que CET est essentiellement une transaction qui doit être téléchargée sur la chaîne pour prendre effet. Que se passera-t-il si Alice diffuse CET1 à l'avance, ou dans le cas de «Barcelone gagne», met toujours CET1 sur la chaîne qui ne peut être déclenchée avec succès qu'après la victoire du «Real Madrid»?

Dans le diagramme précédent, nous avons mentionné qu'après que CET1 soit mis sur la chaîne, les 2 BTC bloqués dans l'adresse multi-signature d'origine seront transférés, 0,5 BTC seront transférés à Bob et 1,5 BTC seront transférés à une adresse Taproot. La machine oracle produit la sortie "Seulement après la victoire du Real Madrid". Alice peut-elle débloquer les BTC bloqués dans l'adresse Taproot. Résultats comme indiqué ci-dessous.

En même temps, cette adresse Taproot est soumise à un verrouillage temporel. Si Alice ne peut pas retirer avec succès 1,5 BTC dans la période spécifiée par le verrouillage temporel, Bob a le droit de prendre l'argent directement.

Par conséquent, tant que l'oracle est honnête, Alice ne peut pas emporter les 1.5 BTC. Lorsque la période de verrouillage temporel expire, Bob peut emporter les 1.5 BTC. En plus des 0.5 BTC transférés directement à Bob lorsque CET1 a été téléchargé sur la chaîne, tout l'argent appartiendra finalement à Bob.

Pour Alice, peu importe qu'elle gagne ou perde à la fin, la chose la plus bénéfique à faire est de mettre le CET correct sur la chaîne. Mettre le CET invalide sur la chaîne lui fera perdre plus d'argent.

En fait, lorsque le CET susmentionné a été construit, la signature de schnorr de Taproot a été améliorée, ce qui peut être compris comme l'utilisation de la clé publique de l'oracle + des résultats d'événements pour construire des adresses indépendantes pour différents résultats. Après cela, seuls lorsque la machine oracle annonce la signature correspondant à un certain résultat, les BTC verrouillés à l'adresse correspondant au résultat peuvent être dépensés.

Bien sûr, il y a ici une possibilité supplémentaire. Et si Alice sait qu'elle a perdu et tout simplement ne met pas le CET1 qu'elle a construit sur la chaîne ? Cela est facile à résoudre car Bob peut construire un CET personnalisé pour le problème de "Alice perd, Bob gagne". L'effet obtenu par ce CET est fondamentalement le même que le CET construit par Alice, mais les détails spécifiques sont différents, mais le résultat est le même.

Ce qui est décrit ci-dessus est le processus de construction de CET le plus critique. La troisième étape de la DLC consiste pour Alice et Bob à communiquer, vérifier la transaction CET construite par l'autre partie et apposer leur propre signature sur le CET. Après vérification correcte, ils peuvent se faire confiance mutuellement et investir chacun 1 BTC, verrouillant les adresses initiales à signatures multiples 2/2 mentionnées d'Alice et de Bob, puis attendre qu'un certain CET soit téléchargé sur la chaîne pour déclencher le processus ultérieur.

Enfin, après que la machine oracle annonce les résultats et obtient la signature de la machine oracle sur les résultats, l'une ou l'autre partie peut mettre le CET correct sur la chaîne et permettre aux 2 BTC verrouillés dans l'adresse multi-signature d'être redistribués. Si le perdant met d'abord le CET incorrect sur la chaîne, s'il met le CET correct sur la chaîne, il perdra tout son argent. Si vous mettez le CET correct sur la chaîne, le perdant peut récupérer 0,5 BTC.

Quelqu'un pourrait demander, comment le DLC est-il différent d'une signature multiple 2/3 normale? Tout d'abord, si plus de 2/3 sont signés, deux parties peuvent comploter pour voler tous les actifs, et le DLC permet aux adversaires de limiter tous les scénarios en créant un ensemble de CET à l'avance. Même si l'oracle participe à la collusion, les dommages causés sont souvent limités.

Deuxièmement, la multi-signature exige que toutes les parties signent des transactions spécifiques à téléverser sur la chaîne, alors que sous le cadre du DLC, l'oracle a seulement besoin de signer les résultats d'événements spécifiques. Il n'a pas besoin de connaître le contenu des CET/transactions à téléverser sur la chaîne. Il n'a même pas besoin de savoir qu'il y a deux personnes, Alice et Bob. Il a juste besoin d'agir comme un oracle ordinaire. Il interagit simplement avec l'utilisateur normalement comme une machine.

Nous pouvons penser que l'essence de DLC est de transformer la confiance des participants de la signature multiple en confiance en les oracles. Tant que la machine oracle ne participe pas à des actes malveillants, il peut être assuré que la conception du protocole DLC est suffisamment fiable. Théoriquement, DLC peut utiliser un oracle tiers relativement mature et complet pour éviter de faire le mal. DLC.link et BitLayer profitent de cette fonctionnalité de DLC pour transférer la question de confiance du pont à l'oracle tiers.

De plus, le pont Bitlayer's DLC prend également en charge les nœuds oracle auto-construits, ajoutant ainsi une couche de preuve de fraude par dessus. Lorsque l'oracle auto-construit place des CET invalides sur la chaîne, n'importe qui peut le contester. En ce qui concerne le principe de son pont OP-DLC, nous le décrirons brièvement ci-dessous.

Pont OP-DLC : Canal DLC + Preuve de fraude

Nous expliquons le principe de fonctionnement du pont OP-DLC de l'ensemble du processus de dépôt et de retrait. Supposons qu'Alice dépose maintenant 1 Bitcoin sur L2 via le pont OP-DLC. Selon le mécanisme de transaction en deux étapes, M. Alice génère une transaction de pré-financement, comme le montre l'exemple ci-dessous :

C'est en fait le premier transfert de 1 BTC à l'adresse Taproot contrôlée conjointement par Alice et les membres de l'alliance BitVM, puis démarrez une série de processus pour créer le CET. Si un membre de l'alliance BitVM Bridge refuse de coopérer avec la demande de dépôt d'Alice, Alice peut retirer l'argent immédiatement après l'expiration du verrouillage temporel.

Si les membres de l'Alliance BitVM sont prêts à coopérer avec Alice, les deux parties peuvent utiliser une communication hors chaîne pour générer d'abord une transaction de dépôt de fonds formelle (pas encore sur la chaîne), ainsi que tous les CET dans le scénario de retrait. Après que la génération et la vérification du CET sont terminées, les deux parties peuvent soumettre la transaction de fonds à la chaîne.

Dans les données de témoin/signature de la transaction du fonds, Alice spécifiera son adresse de paiement dans Layer 2 ; Après que la transaction de fonds soit téléchargée sur la chaîne, Alice peut soumettre les données de transaction de fonds ci-dessus au contrat pont sur Layer 2 pour prouver qu'elle a terminé l'action de dépôt sur la chaîne Bitcoin et est éligible pour que le contrat pont L2 libère le jeton à l'adresse de paiement désignée.

Après que la transaction du Fonds est déclenchée, le dépôt est en fait verrouillé dans l'adresse multi-signature Taproot contrôlée conjointement par Alice et les membres de l'alliance BitVM. Cependant, il convient de noter que la multi-signature ne peut déverrouiller que les BTC verrouillés par l'adresse via le CET, et l'Alliance BitVM ne peut pas transférer l'argent sans raison.

Ensuite, analysons les CET construits à l'avance par Alice et l'Alliance BitVM. Ces CET sont utilisés pour répondre à des scénarios potentiels de retraits futurs. Par exemple, Alice a peut-être déposé 1 BTC, mais elle n'a retiré que 0,3 BTC lors de son premier retrait, et les 0,7 BTC restants ont été remis au pool de fonds public de l'Alliance BitVM. Pour contrôler, mais si vous souhaitez retirer de l'argent, vous ne pouvez passer que par le pont BitVM mentionné ci-dessus.

Ou utilisez simplement ces 0.7 BTC pour initier un nouveau dépôt de pré-financement. En tant qu'actif nouvellement ajouté au pont DLC, vous pouvez répéter le processus de transaction de fonds et de construction de CET mentionné ci-dessus.

Le processus ci-dessus n'est pas difficile à comprendre. En fait, le déposant Alice et l'alliance bitVM agissent en tant que contreparties l'une de l'autre, créent des CET pour des événements de retrait de montants différents, puis laissent l'oracle lire l'état de retrait initié par Alice dans Layer 2 pour déterminer quelle transaction Alice veut déclencher. Un CET (combien d'argent vous voulez retirer).

Le risque ici est que la machine oracle puisse colluder avec l'alliance BitVM. Par exemple, Alice déclare qu'elle veut retirer 0,5 BTC, mais la machine oracle falsifie l'état de retrait, ce qui conduit finalement à "Alice retire 0,1 BTC et l'alliance BitVM reçoit 0,9 BTC." Erreur CET sur la chaîne.

Il existe plusieurs solutions à ce problème. La première consiste à utiliser un oracle tiers avec une conception relativement complète. Empêcher une telle collusion (il est extrêmement difficile pour l'alliance BitVM de collusionner avec des oracles à ce moment), ou laisser l'oracle effectuer du staking, l'oracle doit publier régulièrement un engagement sur la chaîne Bitcoin, indiquant qu'il a traité honnêtement la demande de retrait du demandeur. N'importe qui peut contester l'engagement grâce au protocole de preuve de fraude de BitVM. Si le défi est réussi, le mauvais oracle sera pénalisé.

Sous la conception du pont OP-DLC, les utilisateurs peuvent toujours "participer" à leurs propres actifs pour éviter que les actifs ne soient détournés par l'Alliance BitVM. De plus, cette conception de type canal apporte plus d'autonomie aux utilisateurs, et il n'est pas nécessaire de mélanger ses propres fonds avec ceux d'autres personnes. C'est plus comme une solution de dépôt et de retrait pair à pair (P2P)

De plus, étant donné que la solution BitVM prendra du temps à être mise en œuvre, avant sa mise en œuvre, le pont DLC sera un modèle de traitement de pont plus fiable par rapport à la solution simple de multi-signature. Cette solution peut également être utilisée comme deux entrées majeures de dépôt et de retrait utilisées en parallèle avec le pont BitVM. Si l'une d'entre elles échoue, l'utilisateur peut utiliser l'autre entrée, ce qui est également une bonne méthode de tolérance aux pannes.

Résumé

La solution de pont BitVM de BitLayer et Citrea est essentiellement un modèle de "paiement anticipé-remboursement", il y a un nœud Opérateur dédié pour transférer de l'argent aux utilisateurs de retrait, et l'Opérateur peut régulièrement demander un remboursement à l'adresse de dépôt public. Si un opérateur fait une fausse demande de remboursement, il peut être contesté et réduit par n'importe qui.

La solution de BitVM2 introduit la pré-signature et combine l'idée d'un canal pour permettre aux utilisateurs de limiter le processus de traitement post-dépôt avant de faire un dépôt formel, et ne donne pas aux responsables du pont inter-chaînes l'opportunité de s'approprier des dépôts d'utilisateurs.

Il n'y a pas de problèmes de sécurité avec ce pont en théorie, mais il y a des problèmes de vivacité/disponibilité, et il ne peut pas répondre aux besoins des utilisateurs spécifiques en matière d'indépendance financière et de lutte contre le blanchiment d'argent (il s'agit essentiellement d'un modèle de pool de fonds), et il est également très difficile à mettre en œuvre.

À cette fin, Bitlayer a ajouté une solution de pont appelée OP-DLC, similaire à DLC.link, et introduit la preuve de fraude sur la base des canaux et du DLC pour empêcher la machine oracle du pont DLC de faire le mal.

Mais comme BitVM est trop difficile à mettre en œuvre, le pont DLC sera d'abord mis en place et deviendra un remplacement temporaire, aussi longtemps que le risque de confiance de la machine oracle est résolu et qu'une machine oracle tierce plus fiable et mature est intégrée, le pont DLC peut devenir une solution de vérification de retrait plus sécurisée que le pont multi-signature à ce stade.

Avertissement：

1. Cet article est repris de [ 极客web3]. Tous les droits d'auteur appartiennent à l'auteur original [Faust & Nickqiao]. Si vous avez des objections à cette reproduction, veuillez contacter lePorte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf indication contraire, il est interdit de copier, distribuer ou plagier les articles traduits.