Le 23 avril 2025, un internaute nommé Brain a demandé de l'aide sur Twitter par l'intermédiaire d'un ami, affirmant que plus de 100 000 $ d'actifs unibtc étaient bloqués par les autorités de Bedrock et ne pouvaient pas être retirés lors d'une opération d'arbitrage sur une chaîne Layer2 de Bitcoin.
Selon la divulgation de la partie W, le 17 avril, il a découvert que le unibtc émis par Bedrock avait un prix anormal sur une certaine chaîne L2 de Bitcoin et se détachait de BTC. W pense que le détachement est temporaire et que cela va bientôt revenir à l'ancrage. Il y a une bonne opportunité d'arbitrage ici, il a donc transféré une partie de son BTC vers cette chaîne L2 de Bitcoin, l'a échangé contre du unibtc et attendra qu'il revienne à l'ancrage pour le vendre.
Seulement 24 heures après le découplage, unibtc avait déjà rétabli son ancrage, mais lorsque W a essayé de vendre les unibtc en sa possession, il a découvert que le pool de liquidité unibtc-BTC sur la chaîne avait été retiré par les officiels de Bedrock, et que ce jeton était le seul canal de sortie du marché secondaire unibtc sur cette chaîne. Ne pouvant pas se débarrasser de ses unibtc, W a essayé de transférer unibtc vers d'autres chaînes.
Lorsqu'il a trouvé le seul pont cross-chain sur la chaîne qui prend en charge unibtc (appelé Free), il a reçu un message indiquant : "La transaction nécessite une autorisation de signature de la part du projet." W a contacté le service client du pont Free, et l'interlocuteur a expliqué : "La clé multisignature du cross-chain unibtc est hébergée par Bedrock, sans leur permission, les utilisateurs ne peuvent pas transférer unibtc vers d'autres chaînes."
Il n'y a pas moyen, W ne peut que contacter les personnes concernées par Bedrock pour poser la question. La première réponse de leur part est : « Nous pouvons vous permettre de retirer le capital, mais il faut soumettre à l'examen si vous pouvez retirer les bénéfices générés par l'arbitrage. »
À ce stade, W réalise que le chemin de sortie de unibtc sur cette chaîne est complètement coupé, et les unibtc d'une valeur d'environ 200 000 U qu'il détient sont "temporairement gelés" - il n'a aucun moyen de les vendre sur cette chaîne, ni de les transférer sur une autre chaîne. À ce moment-là, il se sentait très impuissant, ne souhaitant qu'un retrait sans encombre de son capital.
Cependant, l'attitude des personnes concernées par BedRock est devenue ambiguë - elles ne précisent ni quand W pourra retirer son capital, ni ne fournissent aucun engagement écrit, prétextant des raisons telles que "examen des risques" et "vérification technique" pour retarder.
Après un certain retard, BedRock a affirmé que le dépeggement de unibtc provenait du fait que des personnes sur la plateforme LayerBank empruntaient massivement des actifs unibtc et procédaient à une vente à découvert. Ensuite, les personnes de BedRock ont suggéré à W de "tenir LayerBank responsable". Cependant, W n'a pas reçu de réponse de LayerBank pendant une longue période après les avoir contactés.
Dans une situation désespérée, W n'a eu d'autre choix que de demander de l'aide à des amis sur Twitter. Après plus de deux semaines de négociations, il a finalement reçu une réponse positive de LayerBank et BedRock, réussissant à récupérer ses actifs.
L'expérience de W n'est pas un cas isolé. Selon les retours d'autres parties concernées, l'année dernière, BedRock a également utilisé des moyens similaires pour couper le chemin de sortie des utilisateurs de unibtc, entraînant un "gel substantiel" de ces unibtc. Bien sûr, cet article n'a pas l'intention de spéculer sur les raisons sous-jacentes de cet événement, mais vise simplement à expliquer d'un point de vue technique comment éviter et éradiquer de telles actions malveillantes centralisées.
Tout d'abord, en revenant sur les événements précédents, nous pouvons voir que BedRock, en tant qu'émetteur d'unibtc et LP initial du pool de liquidités du marché secondaire, possède naturellement le droit d'accès au canal de sortie du marché secondaire d'unibtc. Si nous voulons limiter son pouvoir, cela doit davantage passer par la gouvernance que par des moyens techniques.
Cependant, le fait que le pont inter-chaînes Free et BedRock aient conspiré pour refuser les demandes des utilisateurs a révélé des défauts techniques évidents dans le processus "émission - circulation sur une seule chaîne - circulation sur plusieurs chaînes" d'unibtc : le pont inter-chaînes Free, en tant que partenaire de BedRock, est manifestement hautement centralisé.
Un véritable pont sans confiance devrait garantir que l'entité officielle du pont ne puisse pas empêcher les utilisateurs de sortir. Cependant, dans le cas de gel d'unibtc, que ce soit avec BedRock ou le pont inter-chaînes Free, des pouvoirs centralisés puissants sont en place, et aucun passage de sortie résistant à la censure n'est fourni.
Bien sûr, des cas similaires à unibtc ne sont pas rares, et il n'est pas rare que les grandes bourses coupent les voies de sortie des utilisateurs. Pour les ponts inter-chaînes ou d'autres types de projets, de tels cas d'utilisation des droits centralisés ne manquent pas non plus. En juin 2022, le Harmony Horizon Bridge a suspendu les canaux de retrait de 57 actifs en raison d'une attaque de hacker. Bien que cette action ait des "raisons valables", elle a tout de même suscité un certain malaise chez certaines personnes.
Lors de l'événement StableMagnet de 2021, l'équipe du projet a volé 24 millions de dollars en utilisant une vulnérabilité de programme préalablement réservée. Finalement, un grand nombre de forces de police de Hong Kong et du Royaume-Uni ont été mobilisées et, grâce à l'aide de la communauté, 91 % des fonds volés ont été récupérés. Ces divers cas illustrent bien que si une plateforme de garde d'actifs ne peut pas fournir un service sans confiance, cela entraînera inévitablement des conséquences néfastes.
Cependant, le Trustless n'est pas à portée de main. Des canaux de paiement et des DLC aux BitVM et ZK Rollup, les gens ont essayé diverses méthodes de mise en œuvre. Bien qu'il soit possible de garantir dans une large mesure l'autonomie des utilisateurs et de fournir des sorties fiables pour le retrait d'actifs, il existe néanmoins des défauts inévitables.
Par exemple, les canaux de paiement nécessitent que les parties surveillent les comportements malveillants potentiels de l'autre partie, les DLC doivent s'appuyer sur des oracles ; tandis que BitVM a un coût élevé et présente d'autres hypothèses de confiance dans la phase de mise en pratique ; la capsule de sauvetage des ZK Rollups doit passer par une longue période de fenêtre avant de pouvoir être déclenchée, et nécessite d'abord l'arrêt du Rollup, ce qui entraîne des coûts considérables.
D'après la situation actuelle de la mise en œuvre des différentes grandes solutions techniques, aucune solution de garde d'actifs et de retrait ne peut être considérée comme parfaite, le marché a encore besoin d'innovation. Dans ce qui suit, DeepSafe Research prendra comme exemple la solution de garde d'actifs lancée par DeepSafe pour expliquer une solution de vérification de messages sans confiance combinant TEE, ZK et MPC. Cette solution a équilibré des indicateurs tels que le coût, la sécurité et l'expérience utilisateur qui ne peuvent pas être tous atteints, et peut fournir des services sous-jacents fiables pour des plateformes de trading, des ponts inter-chaînes ou tout scénario de garde d'actifs.
CRVA : Réseau de vérification aléatoire cryptographique
Les solutions de gestion d'actifs les plus largement utilisées sur le marché adoptent généralement des méthodes telles que la multi-signature ou le MPC/TSS pour déterminer si les demandes de transfert d'actifs sont valides. L'avantage de cette solution réside dans sa simplicité de mise en œuvre, son faible coût et la rapidité de vérification des messages, mais ses inconvénients sont évidents : elles ne sont pas assez sûres et tendent souvent vers la centralisation. Dans l'affaire Multichain de 2023, les 21 nœuds participant au calcul MPC étaient tous contrôlés par une seule personne, ce qui constitue une attaque typique de type "sorcière". Cet événement prouve suffisamment que le simple nombre de nœuds en apparence n'offre pas une protection décentralisée élevée.
Pour remédier aux insuffisances des solutions de gestion d'actifs traditionnelles MPC/TSS, la solution CRVA de DeepSafe a apporté de nombreuses améliorations. Tout d'abord, les nœuds du réseau CRVA adoptent une forme d'admission par le biais de la mise en gage d'actifs, et le mainnet ne sera officiellement lancé qu'après avoir atteint environ 500 nœuds. Selon les estimations, les actifs mis en gage par ces nœuds resteront à long terme à plusieurs dizaines de millions de dollars ou plus.
Deuxièmement, pour améliorer l'efficacité du calcul MPC/TSS, CRVA sélectionne aléatoirement des nœuds par le biais d'un algorithme de tirage au sort, par exemple en tirant 10 nœuds toutes les demi-heures, qui agissent comme validateurs pour vérifier si la demande de l'utilisateur doit être approuvée, puis génèrent la signature de seuil correspondante pour permettre son passage. Afin d'éviter les collusions internes ou les attaques de hackers externes, l'algorithme de tirage au sort de CRVA utilise un VRF circulaire original, combiné avec ZK pour cacher l'identité des sélectionnés, rendant impossible pour l'extérieur d'observer directement les personnes tirées.
Bien sûr, aller aussi loin n'est pas suffisant. Bien que l'extérieur ne sache pas qui a été sélectionné, la personne sélectionnée elle-même le sait à ce moment-là, il existe donc toujours un chemin pour la collusion. Pour éliminer davantage la collusion, tous les nœuds de la CRVA doivent faire fonctionner le code source dans un environnement matériel TEE, ce qui équivaut à effectuer le travail principal dans une boîte noire. Ainsi, personne ne peut savoir s'il a été sélectionné, à moins qu'il ne parvienne à compromettre le matériel de confiance TEE, ce qui, selon les conditions techniques actuelles, est extrêmement difficile à réaliser.
Ce qui a été mentionné ci-dessus est l'idée de base du plan CRVA de DeepSafe. Dans le flux de travail réel, il y a un grand nombre de communications par diffusion et d'échanges d'informations entre les nœuds du réseau CRVA. Le processus spécifique est le suivant :
Tous les nœuds doivent d'abord miser des actifs sur la chaîne avant d'entrer dans le réseau CRVA, en laissant une clé publique comme information d'enregistrement. Cette clé publique est également appelée "clé publique permanente".
Chaque heure, le réseau CRVA sélectionne au hasard quelques nœuds. Mais avant cela, tous les candidats doivent générer localement une "clé publique temporaire" unique et générer un ZKP pour prouver que la "clé publique temporaire" est liée à la "clé publique permanente" enregistrée sur la chaîne ; en d'autres termes, chacun doit prouver son existence sur la liste des candidats par ZK, sans révéler qui il est ;
Le rôle de la "clé publique temporaire" réside dans la protection de la vie privée. Si l'on tire directement au sort à partir de l'ensemble des "clés publiques permanentes", lorsque les résultats sont publiés, tout le monde saura directement qui a été élu. Si chacun ne révèle qu'une "clé publique temporaire" unique, puis que l'on sélectionne quelques personnes à partir de l'ensemble des "clés publiques temporaires", vous saurez au maximum que vous avez gagné, mais vous ne saurez pas à qui correspondent les autres clés publiques temporaires gagnantes.
Afin de prévenir davantage les fuites d'identité, CRVA prévoit que vous ne sachiez même pas ce qu'est votre "clé publique temporaire". Le processus de génération de la clé publique temporaire est effectué dans l'environnement TEE du nœud, et vous, en exécutant le TEE, ne pouvez pas voir ce qui se passe à l'intérieur.
Ensuite, dans le TEE, le texte en clair de la clé publique temporaire est chiffré en "charabia" avant d'être envoyé à l'extérieur, seul des nœuds Relayer spécifiques peuvent le déchiffrer. Bien sûr, le processus de déchiffrement se déroule également dans l'environnement TEE du nœud Relayer, qui ne sait pas à quels candidats correspondent ces clés publiques temporaires.
Après que le Relayer ait restauré toutes les "clés publiques temporaires", il les regroupe et les soumet à la fonction VRF sur la chaîne, à partir de laquelle les gagnants sont tirés. Ces personnes vérifient les demandes de transaction envoyées par l'interface utilisateur, puis génèrent une signature de seuil en fonction des résultats de la vérification, et enfin soumettent à nouveau sur la chaîne. (Il est à noter que le Relayer ici est en réalité aussi une identité cachée et est sélectionné périodiquement.)
Il se peut que certaines personnes demandent, puisque chaque nœud ne sait pas s'il a été sélectionné, comment le travail peut-il se poursuivre ? En fait, comme mentionné précédemment, chaque personne génère une "clé publique temporaire" dans son environnement TEE local. Une fois que les résultats du tirage au sort sont disponibles, nous diffusons directement la liste. Chacun n'a qu'à entrer la liste dans le TEE pour vérifier s'il a été sélectionné.
Au cœur de la solution de DeepSafe se trouve le fait que presque toutes les activités importantes se déroulent au sein du matériel TEE, et qu’il est impossible d’observer ce qui se passe depuis l’extérieur du TEE. Chaque nœud ne sait pas qui est le validateur choisi, ce qui empêche la collusion et augmente considérablement le coût des attaques externes. Pour attaquer le comité CRVA basé sur DeepSafe, attaquez théoriquement l’ensemble du réseau CRVA, et avec la protection TEE pour chaque nœud, la difficulté de l’attaque a considérablement augmenté.
Réaliser une solution d'auto-garde des actifs en combinant CRVA.
Dans la section précédente, nous avons présenté les principes généraux de CRVA, en clarifiant comment CRVA réalise une décentralisation sans confiance. Nous allons maintenant utiliser un stablecoin basé sur l'algorithme Bitcoin appelé HelloBTU comme exemple, pour clarifier davantage l'application de CRVA dans les solutions de conservation d'actifs.
Comme tout le monde le sait, en raison de l'absence d'un environnement Turing-complet sur la blockchain Bitcoin, il n'est pas possible de mettre en œuvre directement des logiques de contrats intelligents complexes comme DeFi. Ainsi, le BTCFi principal consiste à faire passer le Bitcoin sur d'autres chaînes pour interagir ensuite avec des contrats intelligents. La partie contrat intelligent de HelloBTU est déployée sur Ethereum, où les utilisateurs peuvent déposer des BTC à l'adresse de réception spécifiée par HelloBTU. Ensuite, le pont officiel de HelloBTU permet de transférer les BTC sur la chaîne Ethereum, où ils peuvent interagir avec le contrat intelligent de stabilisation de HelloBTU.
Supposons qu'un utilisateur souhaite staker 10 BTC sur la plateforme HelloBTU. L'opération consiste d'abord à transférer 10 BTC vers une adresse Taproot sur la blockchain Bitcoin, le déverrouillage correspondant nécessitant une signature multiple 2/2, dont une est générée par l'utilisateur et l'autre par CRVA.
Les différentes situations impliquées ici sont :
Supposons que 10 BTC soient transférés à l'adresse Taproot mentionnée ci-dessus, l'utilisateur utilise ces 10 BTC pour frapper des stablecoins et souhaite maintenant racheter activement les BTC. À ce moment-là, l'utilisateur et le CRVA génèrent chacun une signature pour débloquer ces 10 BTC et les renvoyer à l'adresse de l'utilisateur. Si le CRVA ne coopère pas avec l'utilisateur pendant une longue période, une fois la période de verrouillage temporel expirée, l'utilisateur peut unilatéralement récupérer ces 10 BTC, cette fonctionnalité est appelée "rachat autonome par l'utilisateur".
Une autre situation est que le BTC utilisé comme garantie par l'utilisateur a été liquidé, et maintenant il doit collaborer avec le CRVA pour transférer ces BTC et les remettre au contrôle du canal unidirectionnel du CRVA. Mais l'utilisateur peut refuser de coopérer, dans ce cas, ces BTC seront temporairement bloqués et personne ne pourra les récupérer ; une fois la période de verrouillage temporel écoulée, cet argent pourra être transféré par le CRVA vers une adresse Taproot contrôlée par le CRVA sous ( canal unidirectionnel du CRVA ) ;
Il y a un détail ici, c'est que le verrouillage temporel pour l'entrée de BTC dans le canal unidirectionnel CRVA est relativement court, tandis que le verrouillage temporel pour le rachat autonome par l'utilisateur est plus long. En d'autres termes, si CRVA et l'utilisateur ne peuvent pas coopérer, ces BTC entreront finalement en priorité dans le canal unidirectionnel CRVA. Ainsi, les comportements malhonnêtes de l'utilisateur peuvent être efficacement limités.
En ce qui concerne les actes malveillants de CRVA, étant donné que CRVA est un système de réseau de nœuds automatisé, tant que le code de démarrage initial ne contient pas de logique malveillante, il n'y aura pas de cas où CRVA refuse activement de coopérer avec les utilisateurs, donc cela peut être fondamentalement ignoré;
Si CRVA subit une panne de courant, une inondation ou d'autres forces majeures entraînant l'arrêt massif des nœuds, selon le processus mentionné dans le plan ci-dessus, les utilisateurs ont toujours la possibilité de retirer leurs actifs en toute sécurité. L'hypothèse de confiance ici est que nous faisons suffisamment confiance à CRVA pour qu'il soit décentralisé et qu'il n'agisse pas malicieusement (les raisons ont déjà été suffisamment expliquées précédemment).
Si le BTC est transféré dans un canal unidirectionnel CRVA, cela signifie souvent que la position de couverture sur la chaîne correspondante a été liquidée, et à ce moment-là, la propriété réelle du BTC appartient au liquidateur. Le liquidateur peut soumettre une demande de retrait, qui sera examinée par le CRVA. Si elle est approuvée, le CRVA générera une signature pour lui et transférera le montant correspondant de BTC au liquidateur.
À ce moment-là, si le CRVA ne répond pas pendant une longue période, après l'expiration du verrouillage temporel, ces BTC seront transférés à une adresse contrôlée par le DAO. Cette opération est déclenchée par une signature multiple, et le traitement ultérieur est résolu par la gouvernance du DAO. Ce DAO est constitué de projets connus, d'entreprises de sécurité et d'institutions d'investissement, établi dans le but de freiner les actes malveillants d'une entité unique.
En résumé, nous avons présenté de manière générale le plan d'autogestion des actifs de DeepSafe pour Bitcoin, et pour les actifs ERC-20, le principe est similaire, donc nous n'en parlerons pas ici. Concernant l'affaire de gel de unibtc mentionnée précédemment, si le pont cross-chain unibtc utilise le plan d'autogestion CRVA, il serait difficile que l'émetteur des actifs puisse contrôler la situation de manière unilatérale.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
1 J'aime
Récompense
1
1
Partager
Commentaire
0/400
HaveSmallGoals
· 05-06 08:50
Veuillez garder à l'esprit que toute exploitation des failles du projet de fête comporte une probabilité de 90 % de perte totale. Cela s'appelle profiter de la vulnérabilité des autres. Si le problème de la faille est résolu complètement et que vous devenez fortuitement riche, tôt ou tard cet argent devra également être perdu.
Plus de 100 000 $ ont été bloqués, ce qui montre l'importance de la garde sans confiance à travers l'événement de gel d'unibtc.
Auteur original :仙壤GodRealmX
Le 23 avril 2025, un internaute nommé Brain a demandé de l'aide sur Twitter par l'intermédiaire d'un ami, affirmant que plus de 100 000 $ d'actifs unibtc étaient bloqués par les autorités de Bedrock et ne pouvaient pas être retirés lors d'une opération d'arbitrage sur une chaîne Layer2 de Bitcoin.
Selon la divulgation de la partie W, le 17 avril, il a découvert que le unibtc émis par Bedrock avait un prix anormal sur une certaine chaîne L2 de Bitcoin et se détachait de BTC. W pense que le détachement est temporaire et que cela va bientôt revenir à l'ancrage. Il y a une bonne opportunité d'arbitrage ici, il a donc transféré une partie de son BTC vers cette chaîne L2 de Bitcoin, l'a échangé contre du unibtc et attendra qu'il revienne à l'ancrage pour le vendre.
Seulement 24 heures après le découplage, unibtc avait déjà rétabli son ancrage, mais lorsque W a essayé de vendre les unibtc en sa possession, il a découvert que le pool de liquidité unibtc-BTC sur la chaîne avait été retiré par les officiels de Bedrock, et que ce jeton était le seul canal de sortie du marché secondaire unibtc sur cette chaîne. Ne pouvant pas se débarrasser de ses unibtc, W a essayé de transférer unibtc vers d'autres chaînes.
Lorsqu'il a trouvé le seul pont cross-chain sur la chaîne qui prend en charge unibtc (appelé Free), il a reçu un message indiquant : "La transaction nécessite une autorisation de signature de la part du projet." W a contacté le service client du pont Free, et l'interlocuteur a expliqué : "La clé multisignature du cross-chain unibtc est hébergée par Bedrock, sans leur permission, les utilisateurs ne peuvent pas transférer unibtc vers d'autres chaînes."
Il n'y a pas moyen, W ne peut que contacter les personnes concernées par Bedrock pour poser la question. La première réponse de leur part est : « Nous pouvons vous permettre de retirer le capital, mais il faut soumettre à l'examen si vous pouvez retirer les bénéfices générés par l'arbitrage. »
À ce stade, W réalise que le chemin de sortie de unibtc sur cette chaîne est complètement coupé, et les unibtc d'une valeur d'environ 200 000 U qu'il détient sont "temporairement gelés" - il n'a aucun moyen de les vendre sur cette chaîne, ni de les transférer sur une autre chaîne. À ce moment-là, il se sentait très impuissant, ne souhaitant qu'un retrait sans encombre de son capital.
Cependant, l'attitude des personnes concernées par BedRock est devenue ambiguë - elles ne précisent ni quand W pourra retirer son capital, ni ne fournissent aucun engagement écrit, prétextant des raisons telles que "examen des risques" et "vérification technique" pour retarder.
Après un certain retard, BedRock a affirmé que le dépeggement de unibtc provenait du fait que des personnes sur la plateforme LayerBank empruntaient massivement des actifs unibtc et procédaient à une vente à découvert. Ensuite, les personnes de BedRock ont suggéré à W de "tenir LayerBank responsable". Cependant, W n'a pas reçu de réponse de LayerBank pendant une longue période après les avoir contactés.
Dans une situation désespérée, W n'a eu d'autre choix que de demander de l'aide à des amis sur Twitter. Après plus de deux semaines de négociations, il a finalement reçu une réponse positive de LayerBank et BedRock, réussissant à récupérer ses actifs.
L'expérience de W n'est pas un cas isolé. Selon les retours d'autres parties concernées, l'année dernière, BedRock a également utilisé des moyens similaires pour couper le chemin de sortie des utilisateurs de unibtc, entraînant un "gel substantiel" de ces unibtc. Bien sûr, cet article n'a pas l'intention de spéculer sur les raisons sous-jacentes de cet événement, mais vise simplement à expliquer d'un point de vue technique comment éviter et éradiquer de telles actions malveillantes centralisées.
Tout d'abord, en revenant sur les événements précédents, nous pouvons voir que BedRock, en tant qu'émetteur d'unibtc et LP initial du pool de liquidités du marché secondaire, possède naturellement le droit d'accès au canal de sortie du marché secondaire d'unibtc. Si nous voulons limiter son pouvoir, cela doit davantage passer par la gouvernance que par des moyens techniques.
Cependant, le fait que le pont inter-chaînes Free et BedRock aient conspiré pour refuser les demandes des utilisateurs a révélé des défauts techniques évidents dans le processus "émission - circulation sur une seule chaîne - circulation sur plusieurs chaînes" d'unibtc : le pont inter-chaînes Free, en tant que partenaire de BedRock, est manifestement hautement centralisé.
Un véritable pont sans confiance devrait garantir que l'entité officielle du pont ne puisse pas empêcher les utilisateurs de sortir. Cependant, dans le cas de gel d'unibtc, que ce soit avec BedRock ou le pont inter-chaînes Free, des pouvoirs centralisés puissants sont en place, et aucun passage de sortie résistant à la censure n'est fourni.
Bien sûr, des cas similaires à unibtc ne sont pas rares, et il n'est pas rare que les grandes bourses coupent les voies de sortie des utilisateurs. Pour les ponts inter-chaînes ou d'autres types de projets, de tels cas d'utilisation des droits centralisés ne manquent pas non plus. En juin 2022, le Harmony Horizon Bridge a suspendu les canaux de retrait de 57 actifs en raison d'une attaque de hacker. Bien que cette action ait des "raisons valables", elle a tout de même suscité un certain malaise chez certaines personnes.
Lors de l'événement StableMagnet de 2021, l'équipe du projet a volé 24 millions de dollars en utilisant une vulnérabilité de programme préalablement réservée. Finalement, un grand nombre de forces de police de Hong Kong et du Royaume-Uni ont été mobilisées et, grâce à l'aide de la communauté, 91 % des fonds volés ont été récupérés. Ces divers cas illustrent bien que si une plateforme de garde d'actifs ne peut pas fournir un service sans confiance, cela entraînera inévitablement des conséquences néfastes.
Cependant, le Trustless n'est pas à portée de main. Des canaux de paiement et des DLC aux BitVM et ZK Rollup, les gens ont essayé diverses méthodes de mise en œuvre. Bien qu'il soit possible de garantir dans une large mesure l'autonomie des utilisateurs et de fournir des sorties fiables pour le retrait d'actifs, il existe néanmoins des défauts inévitables.
Par exemple, les canaux de paiement nécessitent que les parties surveillent les comportements malveillants potentiels de l'autre partie, les DLC doivent s'appuyer sur des oracles ; tandis que BitVM a un coût élevé et présente d'autres hypothèses de confiance dans la phase de mise en pratique ; la capsule de sauvetage des ZK Rollups doit passer par une longue période de fenêtre avant de pouvoir être déclenchée, et nécessite d'abord l'arrêt du Rollup, ce qui entraîne des coûts considérables.
D'après la situation actuelle de la mise en œuvre des différentes grandes solutions techniques, aucune solution de garde d'actifs et de retrait ne peut être considérée comme parfaite, le marché a encore besoin d'innovation. Dans ce qui suit, DeepSafe Research prendra comme exemple la solution de garde d'actifs lancée par DeepSafe pour expliquer une solution de vérification de messages sans confiance combinant TEE, ZK et MPC. Cette solution a équilibré des indicateurs tels que le coût, la sécurité et l'expérience utilisateur qui ne peuvent pas être tous atteints, et peut fournir des services sous-jacents fiables pour des plateformes de trading, des ponts inter-chaînes ou tout scénario de garde d'actifs.
CRVA : Réseau de vérification aléatoire cryptographique
Les solutions de gestion d'actifs les plus largement utilisées sur le marché adoptent généralement des méthodes telles que la multi-signature ou le MPC/TSS pour déterminer si les demandes de transfert d'actifs sont valides. L'avantage de cette solution réside dans sa simplicité de mise en œuvre, son faible coût et la rapidité de vérification des messages, mais ses inconvénients sont évidents : elles ne sont pas assez sûres et tendent souvent vers la centralisation. Dans l'affaire Multichain de 2023, les 21 nœuds participant au calcul MPC étaient tous contrôlés par une seule personne, ce qui constitue une attaque typique de type "sorcière". Cet événement prouve suffisamment que le simple nombre de nœuds en apparence n'offre pas une protection décentralisée élevée.
Pour remédier aux insuffisances des solutions de gestion d'actifs traditionnelles MPC/TSS, la solution CRVA de DeepSafe a apporté de nombreuses améliorations. Tout d'abord, les nœuds du réseau CRVA adoptent une forme d'admission par le biais de la mise en gage d'actifs, et le mainnet ne sera officiellement lancé qu'après avoir atteint environ 500 nœuds. Selon les estimations, les actifs mis en gage par ces nœuds resteront à long terme à plusieurs dizaines de millions de dollars ou plus.
Deuxièmement, pour améliorer l'efficacité du calcul MPC/TSS, CRVA sélectionne aléatoirement des nœuds par le biais d'un algorithme de tirage au sort, par exemple en tirant 10 nœuds toutes les demi-heures, qui agissent comme validateurs pour vérifier si la demande de l'utilisateur doit être approuvée, puis génèrent la signature de seuil correspondante pour permettre son passage. Afin d'éviter les collusions internes ou les attaques de hackers externes, l'algorithme de tirage au sort de CRVA utilise un VRF circulaire original, combiné avec ZK pour cacher l'identité des sélectionnés, rendant impossible pour l'extérieur d'observer directement les personnes tirées.
Bien sûr, aller aussi loin n'est pas suffisant. Bien que l'extérieur ne sache pas qui a été sélectionné, la personne sélectionnée elle-même le sait à ce moment-là, il existe donc toujours un chemin pour la collusion. Pour éliminer davantage la collusion, tous les nœuds de la CRVA doivent faire fonctionner le code source dans un environnement matériel TEE, ce qui équivaut à effectuer le travail principal dans une boîte noire. Ainsi, personne ne peut savoir s'il a été sélectionné, à moins qu'il ne parvienne à compromettre le matériel de confiance TEE, ce qui, selon les conditions techniques actuelles, est extrêmement difficile à réaliser.
Ce qui a été mentionné ci-dessus est l'idée de base du plan CRVA de DeepSafe. Dans le flux de travail réel, il y a un grand nombre de communications par diffusion et d'échanges d'informations entre les nœuds du réseau CRVA. Le processus spécifique est le suivant :
Tous les nœuds doivent d'abord miser des actifs sur la chaîne avant d'entrer dans le réseau CRVA, en laissant une clé publique comme information d'enregistrement. Cette clé publique est également appelée "clé publique permanente".
Chaque heure, le réseau CRVA sélectionne au hasard quelques nœuds. Mais avant cela, tous les candidats doivent générer localement une "clé publique temporaire" unique et générer un ZKP pour prouver que la "clé publique temporaire" est liée à la "clé publique permanente" enregistrée sur la chaîne ; en d'autres termes, chacun doit prouver son existence sur la liste des candidats par ZK, sans révéler qui il est ;
Le rôle de la "clé publique temporaire" réside dans la protection de la vie privée. Si l'on tire directement au sort à partir de l'ensemble des "clés publiques permanentes", lorsque les résultats sont publiés, tout le monde saura directement qui a été élu. Si chacun ne révèle qu'une "clé publique temporaire" unique, puis que l'on sélectionne quelques personnes à partir de l'ensemble des "clés publiques temporaires", vous saurez au maximum que vous avez gagné, mais vous ne saurez pas à qui correspondent les autres clés publiques temporaires gagnantes.
Afin de prévenir davantage les fuites d'identité, CRVA prévoit que vous ne sachiez même pas ce qu'est votre "clé publique temporaire". Le processus de génération de la clé publique temporaire est effectué dans l'environnement TEE du nœud, et vous, en exécutant le TEE, ne pouvez pas voir ce qui se passe à l'intérieur.
Ensuite, dans le TEE, le texte en clair de la clé publique temporaire est chiffré en "charabia" avant d'être envoyé à l'extérieur, seul des nœuds Relayer spécifiques peuvent le déchiffrer. Bien sûr, le processus de déchiffrement se déroule également dans l'environnement TEE du nœud Relayer, qui ne sait pas à quels candidats correspondent ces clés publiques temporaires.
Après que le Relayer ait restauré toutes les "clés publiques temporaires", il les regroupe et les soumet à la fonction VRF sur la chaîne, à partir de laquelle les gagnants sont tirés. Ces personnes vérifient les demandes de transaction envoyées par l'interface utilisateur, puis génèrent une signature de seuil en fonction des résultats de la vérification, et enfin soumettent à nouveau sur la chaîne. (Il est à noter que le Relayer ici est en réalité aussi une identité cachée et est sélectionné périodiquement.)
Il se peut que certaines personnes demandent, puisque chaque nœud ne sait pas s'il a été sélectionné, comment le travail peut-il se poursuivre ? En fait, comme mentionné précédemment, chaque personne génère une "clé publique temporaire" dans son environnement TEE local. Une fois que les résultats du tirage au sort sont disponibles, nous diffusons directement la liste. Chacun n'a qu'à entrer la liste dans le TEE pour vérifier s'il a été sélectionné.
Au cœur de la solution de DeepSafe se trouve le fait que presque toutes les activités importantes se déroulent au sein du matériel TEE, et qu’il est impossible d’observer ce qui se passe depuis l’extérieur du TEE. Chaque nœud ne sait pas qui est le validateur choisi, ce qui empêche la collusion et augmente considérablement le coût des attaques externes. Pour attaquer le comité CRVA basé sur DeepSafe, attaquez théoriquement l’ensemble du réseau CRVA, et avec la protection TEE pour chaque nœud, la difficulté de l’attaque a considérablement augmenté.
Réaliser une solution d'auto-garde des actifs en combinant CRVA.
Dans la section précédente, nous avons présenté les principes généraux de CRVA, en clarifiant comment CRVA réalise une décentralisation sans confiance. Nous allons maintenant utiliser un stablecoin basé sur l'algorithme Bitcoin appelé HelloBTU comme exemple, pour clarifier davantage l'application de CRVA dans les solutions de conservation d'actifs.
Comme tout le monde le sait, en raison de l'absence d'un environnement Turing-complet sur la blockchain Bitcoin, il n'est pas possible de mettre en œuvre directement des logiques de contrats intelligents complexes comme DeFi. Ainsi, le BTCFi principal consiste à faire passer le Bitcoin sur d'autres chaînes pour interagir ensuite avec des contrats intelligents. La partie contrat intelligent de HelloBTU est déployée sur Ethereum, où les utilisateurs peuvent déposer des BTC à l'adresse de réception spécifiée par HelloBTU. Ensuite, le pont officiel de HelloBTU permet de transférer les BTC sur la chaîne Ethereum, où ils peuvent interagir avec le contrat intelligent de stabilisation de HelloBTU.
Supposons qu'un utilisateur souhaite staker 10 BTC sur la plateforme HelloBTU. L'opération consiste d'abord à transférer 10 BTC vers une adresse Taproot sur la blockchain Bitcoin, le déverrouillage correspondant nécessitant une signature multiple 2/2, dont une est générée par l'utilisateur et l'autre par CRVA.
Les différentes situations impliquées ici sont :
Supposons que 10 BTC soient transférés à l'adresse Taproot mentionnée ci-dessus, l'utilisateur utilise ces 10 BTC pour frapper des stablecoins et souhaite maintenant racheter activement les BTC. À ce moment-là, l'utilisateur et le CRVA génèrent chacun une signature pour débloquer ces 10 BTC et les renvoyer à l'adresse de l'utilisateur. Si le CRVA ne coopère pas avec l'utilisateur pendant une longue période, une fois la période de verrouillage temporel expirée, l'utilisateur peut unilatéralement récupérer ces 10 BTC, cette fonctionnalité est appelée "rachat autonome par l'utilisateur".
Une autre situation est que le BTC utilisé comme garantie par l'utilisateur a été liquidé, et maintenant il doit collaborer avec le CRVA pour transférer ces BTC et les remettre au contrôle du canal unidirectionnel du CRVA. Mais l'utilisateur peut refuser de coopérer, dans ce cas, ces BTC seront temporairement bloqués et personne ne pourra les récupérer ; une fois la période de verrouillage temporel écoulée, cet argent pourra être transféré par le CRVA vers une adresse Taproot contrôlée par le CRVA sous ( canal unidirectionnel du CRVA ) ;
Il y a un détail ici, c'est que le verrouillage temporel pour l'entrée de BTC dans le canal unidirectionnel CRVA est relativement court, tandis que le verrouillage temporel pour le rachat autonome par l'utilisateur est plus long. En d'autres termes, si CRVA et l'utilisateur ne peuvent pas coopérer, ces BTC entreront finalement en priorité dans le canal unidirectionnel CRVA. Ainsi, les comportements malhonnêtes de l'utilisateur peuvent être efficacement limités.
En ce qui concerne les actes malveillants de CRVA, étant donné que CRVA est un système de réseau de nœuds automatisé, tant que le code de démarrage initial ne contient pas de logique malveillante, il n'y aura pas de cas où CRVA refuse activement de coopérer avec les utilisateurs, donc cela peut être fondamentalement ignoré;
Si CRVA subit une panne de courant, une inondation ou d'autres forces majeures entraînant l'arrêt massif des nœuds, selon le processus mentionné dans le plan ci-dessus, les utilisateurs ont toujours la possibilité de retirer leurs actifs en toute sécurité. L'hypothèse de confiance ici est que nous faisons suffisamment confiance à CRVA pour qu'il soit décentralisé et qu'il n'agisse pas malicieusement (les raisons ont déjà été suffisamment expliquées précédemment).
Si le BTC est transféré dans un canal unidirectionnel CRVA, cela signifie souvent que la position de couverture sur la chaîne correspondante a été liquidée, et à ce moment-là, la propriété réelle du BTC appartient au liquidateur. Le liquidateur peut soumettre une demande de retrait, qui sera examinée par le CRVA. Si elle est approuvée, le CRVA générera une signature pour lui et transférera le montant correspondant de BTC au liquidateur.
À ce moment-là, si le CRVA ne répond pas pendant une longue période, après l'expiration du verrouillage temporel, ces BTC seront transférés à une adresse contrôlée par le DAO. Cette opération est déclenchée par une signature multiple, et le traitement ultérieur est résolu par la gouvernance du DAO. Ce DAO est constitué de projets connus, d'entreprises de sécurité et d'institutions d'investissement, établi dans le but de freiner les actes malveillants d'une entité unique.
En résumé, nous avons présenté de manière générale le plan d'autogestion des actifs de DeepSafe pour Bitcoin, et pour les actifs ERC-20, le principe est similaire, donc nous n'en parlerons pas ici. Concernant l'affaire de gel de unibtc mentionnée précédemment, si le pont cross-chain unibtc utilise le plan d'autogestion CRVA, il serait difficile que l'émetteur des actifs puisse contrôler la situation de manière unilatérale.
Si le problème de la faille est résolu complètement et que vous devenez fortuitement riche, tôt ou tard cet argent devra également être perdu.