Incident de gel d’unibtc : Plus de 100 000 $ bloqués et l’importance de la garde sans confiance

Source originale : DeepSafe Research
Le 23 avril 2025, un internaute, nommé W, a sollicité de l’aide sur Twitter, via un ami, en rapportant que lors d’opérations d’arbitrage sur une chaîne Bitcoin Layer 2, plus de 100 000 dollars d’actifs unibtc étaient bloqués par des responsables de Bedrock, rendant tout retrait impossible.
Le 17 avril, W avait remarqué, dans une divulgation de la partie W, que le prix de l’unibtc émis par Bedrock sur une chaîne L2 Bitcoin était anormal et s’était décorrélé du BTC. Pensant que ce décorrélage était temporaire et que le prix allait rapidement revenir à la normale, W avait transféré une partie de son BTC sur la couche 2 Bitcoin, échangeant contre de l’unibtc, en prévision de le revendre une fois que le prix serait revenu à l’ancre.
Cependant, dans les 24 heures suivant le décorrélage, lorsque W a tenté de vendre son unibtc, il a découvert que la piscine de liquidité unibtc-BTC sur la chaîne avait été supprimée par les responsables de Bedrock. Cette piscine était le seul canal de sortie du marché secondaire pour l’unibtc. Ne pouvant pas vendre son unibtc, W a essayé de le transférer vers d’autres chaînes. En trouvant un pont inter-chaînes, appelé Free, qui supportait l’unibtc, il a reçu un message indiquant que « la transaction nécessite une autorisation de signature de la part du projet ».
W a contacté le service clientèle du pont inter-chaînes Free, qui a expliqué que la clé de signature multiple de l’unibtc inter-chaînes était gérée par Bedrock, et sans leur autorisation, les utilisateurs ne pouvaient pas transférer d’unibtc vers d’autres chaînes. W n’a eu d’autre choix que de chercher un employé de Bedrock pour s’informer sur le problème.
L’employé a répondu que Bedrock pourrait autoriser le retrait de la mise de W, mais a précisé que la possibilité de retirer les bénéfices générés par l’arbitrage restait à examiner. À ce moment-là, W a réalisé que son seul chemin de sortie de l’unibtc sur cette chaîne était complètement bloqué et qu’il possédait unibtc d’une valeur d’environ 200 000 dollars, maintenant « temporairement gelés ». Il n’avais aucun moyen de le vendre sur cette chaîne ou de le transférer vers d’autres chaînes.
W se sentait très impuissant et voulait simplement retirer son capital sans complication. Cependant, l’attitude du personnel de Bedrock est devenue ambiguë, ne fournissant pas de délais clairs pour le retrait de son capital ni d’engagement écrit. Ils ont retardé le processus avec des justifications telles que « examen des risques » et « enquête technique ».
Après un certain temps, Bedrock a affirmé que le décorrélage de l’unibtc avait été causé par un utilisateur sur la plateforme LayerBank, qui avait emprunté une grande quantité d’actifs unibtc et a entraîné une chute du marché. Bedrock a alors suggéré à W de « tenir LayerBank responsable ».
Lorsque W a tenté de joindre LayerBank, il a attendu longtemps sans réponse. Dans le désespoir, il a décidé de demander de l’aide à ses amis sur Twitter. Après plus de deux semaines de négociations, il a finalement reçu une réponse positive des responsables de LayerBank et de Bedrock et a pu récupérer ses actifs.
L’expérience de W n’est pas un cas isolé. D’après les témoignages d’autres utilisateurs, Bedrock a également utilisé des méthodes similaires l’année précédente pour couper les chemins de sortie des utilisateurs d’unibtc, entraînant le gel substantiel de ces actifs. Cet article n’a pas pour but de spéculer sur les raisons sous-jacentes de cet incident, mais vise uniquement à expliquer, d’un point de vue technique, comment éviter et éliminer des comportements centralisés nuisibles similaires.
En analysant les événements, on observe que Bedrock, en tant qu’émetteur d’unibtc et LP initial de la piscine de liquidité du marché secondaire, détient naturellement le pouvoir de retirer l’unibtc du marché secondaire. Si ce pouvoir devait être limité, cela devrait être réalisé davantage par la gouvernance que par des moyens techniques. Cependant, la collusion entre Free Cross-Chain Bridge et Bedrock pour empêcher les utilisateurs de retirer leurs actifs met en lumière des défauts techniques évidents dans le système unibtc au sein de la chaîne « émission – circulation sur une seule chaîne – circulation sur plusieurs chaînes ». Le Free Cross-Chain Bridge, en tant que partenaire de Bedrock, est manifestement très centralisé. Un véritable pont sans confiance devrait garantir que les autorités responsables du pont ne peuvent pas empêcher les utilisateurs de sortir. Dans l’incident de gel de l’unibtc, tant Bedrock que le pont inter-chaînes Free disposent d’autorités centralisées substantielles et ne fournissent pas de canaux de sortie résistants à la censure.
Malheureusement, de tels cas ne sont pas rares. En effet, le blocage de l’accès des utilisateurs est courant dans la plupart des échanges et plusieurs projets, y compris des ponts inter-chaînes, se retrouvent confrontés au même problème d’autorité centralisée. En juin 2022, un pont dénommé Harmony Horizon a suspendu les canaux de retrait pour 57 actifs en raison d’une cyberattaque. Bien que cette mesure ait eu des « raisons légitimes », elle a néanmoins suscité des craintes parmi les utilisateurs. Dans l’incident de StableMagnet en 2021, un propriétaire de projet a fraudé 24 millions de dollars à cause d’une vulnérabilité dans un programme. Finalement, Hong Kong et le Royaume-Uni ont mobilisé leurs forces de police et récupéré 91 % des fonds volés grâce à l’aide de la communauté.
Tous ces incidents illustrent très clairement que si une plateforme de garde d’actifs n’est pas en mesure d’offrir des services sans confiance, cela peut conduire à de graves conséquences. Cependant, les solutions sans confiance ne sont pas faciles à mettre en œuvre. Des méthodes allant des canaux de paiement aux BitVM et ZK Rollup ont été explorées. Bien qu’elles puissent garantir l’autonomie des utilisateurs et offrir des sorties fiables pour leurs actifs, des défauts subsistent. Par exemple, les canaux de paiement requièrent une observation du comportement malveillant potentiel de l’autre partie, et le DLC dépend d’oracles externes. L’utilisation de BitVM peut être coûteuse, et d’autres hypothèses de confiance demeurent. Les failles des ZK Rollup ne peuvent être exploitées qu’après une longue période d’attente, en plus des immenses coûts impliqués. À l’heure actuelle, aucune solution parfaite de garde d’actifs et de sortie n’existe sur le marché, et l’innovation demeure nécessaire.
Dans la suite de cet article, DeepSafe Research présentera la solution de garde d’actifs qu’ils ont récemment lancée, expliquant un système de vérification de message sans confiance qui combine TEE, ZK et MPC. Cette solution vise à équilibrer des indicateurs souvent contradictoires comme le coût, la sécurité et l’expérience utilisateur, tout en fournissant des services sous-jacents fiables pour les plateformes de trading, les ponts inter-chaînes, ou tout autre scénario de garde d’actifs.
CRVA : Réseau de Vérification Aléatoire Cryptographique
Actuellement, la majorité des solutions de gestion d’actifs sur le marché reposent principalement sur la signature multiple ou la méthode MPC/TSS pour déterminer la validité des demandes de transfert d’actifs. Ces solutions présentent des avantages tels qu’une mise en œuvre simple, un coût faible et une vérification rapide des messages. Cependant, leurs inconvénients sont évidents : elles ne sont pas suffisamment sécurisées et tendent à être centralisées. Par exemple, l’incident de Multichain en 2023 a révélé que les 21 nœuds participant au calcul MPC étaient contrôlés par une seule entité, représentant ainsi une attaque typique de centralisation.
Cela démontre que quelques dizaines de nœuds, même en apparence décentralisés, ne suffisent pas à assurer un haut degré de décentralisation. En raison de ces lacunes des solutions traditionnelles de gestion d’actifs MPC/TSS, la solution CRVA de DeepSafe propose plusieurs améliorations.
Premièrement, les nœuds du réseau CRVA adoptent un accès par mise en gage d’actifs, et le réseau principal ne sera officiellement lancé qu’une fois environ 500 nœuds atteints. Les actifs engagés par ces nœuds devraient atteindre des dizaines de millions de dollars ou plus sur une longue période. Deuxièmement, afin d’améliorer l’efficacité des calculs MPC/TSS, CRVA sélectionne aléatoirement les nœuds via un algorithme de loterie, par exemple 10 nœuds toutes les demi-heures, qui seront utilisés comme validateurs pour vérifier les demandes des utilisateurs, puis générer la signature de seuil correspondante pour la signature de la demande.
Pour prévenir la collusion interne ou les attaques extérieures, l’algorithme de loterie de CRVA utilise un VRF en anneau combiné avec ZK pour cacher l’identité de la personne sélectionnée, de sorte que l’identité du validateur choisi ne puisse pas être observée directement. Bien sûr, cela n’est pas suffisant à lui seul. Bien que l’extérieur ne sache pas qui a été sélectionné, le participant sélectionné, quant à lui, en est conscient, ce qui signifie qu’il existe toujours un potentiel de collusion. Pour minimiser ce risque, tous les nœuds de CRVA doivent exécuter le code principal dans un environnement matériel TEE, ce qui équivaut à effectuer leurs opérations dans une boîte noire. Ainsi, personne ne peut déterminer s’ils ont été sélectionnés à moins qu’ils ne parviennent à accéder au matériel de confiance TEE, ce qui est extrêmement difficile à réaliser avec les conditions techniques actuelles.
La logique de la solution CRVA de DeepSafe est ainsi établie. En pratique, le réseau CRVA nécessite une importante communication par diffusion et un échange d’informations entre ses nœuds. Le processus spécifique est le suivant :
1. Avant de rejoindre le réseau CRVA, chaque nœud doit d’abord engager des actifs sur la chaîne et fournir une clé publique en tant qu’information d’enregistrement, connue sous le nom de « clé publique permanente ».
2. Chaque heure, le réseau CRVA sélectionne aléatoirement plusieurs nœuds. Avant cela, chaque candidat est tenu de générer localement une « clé publique temporaire » unique et de produire un ZKP pour prouver que cette « clé publique temporaire » est associée à la « clé publique permanente » enregistrée. En d’autres termes, chaque participant doit prouver son existence dans la liste des candidats sans révéler son identité.
3. Le rôle des « clés publiques temporaires » est de protéger l’identité des participants. Si la sélection était faite à partir des « clés publiques permanentes », cela serait évident pour tous lorsqu’un résultat est annoncé. Toutefois, en n’exposant qu’une « clé publique temporaire » unique, nous ne saurons que l’on a gagné à la loterie, sans savoir quelles autres clés ont également été sélectionnées.
4. Pour garantir une confidentialité supplémentaire, CRVA envisage de rendre invisible votre « clé publique temporaire ». Le processus de génération de cette clé publique temporaire se fait dans l’environnement TEE du nœud, protégeant ainsi le secret de son contenu.
5. Ensuite, la clé publique temporaire est cryptée en un « code embrouillé » dans le TEE avant d’être envoyée à l’extérieur. Un nœud Relayer spécifique est alors en mesure de la restaurer, mais non pas en sachant à quels candidats ces clés temporaires correspondent.
6. Une fois que le Relayer a restauré toutes les « clés publiques temporaires », celles-ci sont rassemblées et soumises à la fonction VRF sur la chaîne, à partir de laquelle les gagnants sont sélectionnés. Ces personnes valideront la demande de transaction envoyée par le front-end utilisateur, puis généreront une signature de seuil basée sur le résultat de la validation, avant de soumettre cette signature à la chaîne. (Il est à noter que le Relayer est également masqué et sélectionné régulièrement.)
Certaines personnes pourraient s’interroger sur la manière dont le travail peut être effectué, étant donné que chaque nœud ne sait pas s’il a été sélectionné. En réalité, comme déjà précisé, chaque participant génère une « clé publique temporaire » dans l’environnement TEE local. Une fois que les résultats de la sélection sont connus, une liste est diffusée. Chacun n’a plus qu’à vérifier sa présence dans cette liste.
Le cœur de DeepSafe repose sur le fait que presque toutes les activités majeures sont réalisées dans l’environnement matériel TEE, et que les échanges ne peuvent pas être observés de l’extérieur. Aucun nœud ne connaît l’identité des validateurs sélectionnés, ce qui limite les risques de collusion et augmente considérablement le coût d’éventuelles attaques externes. Pour s’attaquer au comité CRVA basé sur DeepSafe, il faudrait théoriquement infiltrer l’ensemble du réseau, avec la difficulté supplémentaire que chacun de ses nœuds est également protégé par un TEE, ce qui complique grandement toute tentative d’attaque.
Intégration de la solution de garde des actifs CRVA
Nous avons exposé les principes fondamentaux de CRVA et comment cette solution pourrait réaliser décentralisation et absence de confiance. Nous allons maintenant utiliser HelloBTU, un stablecoin algorithmique sur Bitcoin, pour illustrer davantage l’application de CRVA dans les solutions de garde d’actifs.
Comme nous le savons tous, la chaîne Bitcoin ne dispose pas d’un environnement Turing-complet, rendant impossible la mise en œuvre première de logiques complexes de contrats intelligents, comme dans le cas de DeFi. Ainsi, BTCFi consiste principalement à relier Bitcoin à d’autres chaînes afin d’interagir avec des contrats intelligents. La partie contrat intelligent de HelloBTU est déployée sur Ethereum. Les utilisateurs peuvent déposer des BTC à une adresse de paiement spécifiée par HelloBTU, et le pont officiel de ce dernier transfèrera le BTC à la chaîne Ethereum pour interagir avec le contrat intelligent du stablecoin HelloBTU.
Supposons qu’un utilisateur souhaite engager 10 BTC sur la plateforme HelloBTU. La procédure consiste à d’abord transférer ces 10 BTC vers une adresse Taproot sur la chaîne Bitcoin. Le déverrouillage nécessite une signature 2/2, l’une étant générée par l’utilisateur et l’autre par CRVA.
Plusieurs scénarios peuvent se présenter : si l’utilisateur crée des stablecoins avec ces 10 BTC et désire les récupérer, il doit alors générer une signature de déverrouillage avec CRVA pour récupérer ses 10 BTC. Si CRVA ne coopère pas pendant un certain temps, après expiration de la période de verrouillage, l’utilisateur peut récupérer unilatéralement ses 10 BTC. Si, en revanche, les BTC utilisés comme garantie par l’utilisateur sont liquidés, il doit alors coopérer avec CRVA pour transférer ces BTC au canal unidirectionnel de CRVA. En cas de refus, ces actifs resteront temporairement bloqués jusqu’à l’expiration de la période de verrouillage, après quoi ils seront transférés vers une adresse contrôlée par CRVA. Notons que le délai d’entrée dans le canal unidirectionnel est généralement plus court que celui permettant aux utilisateurs de les récupérer eux-mêmes. Ainsi, si CRVA et l’utilisateur ne sont pas en mesure de coopérer, ces BTC seront d’abord transférés dans le canal unidirectionnel de CRVA, limitant ainsi les comportements malveillants des utilisateurs.
Concernant les comportements sournois de CRVA, étant donné que ce dernier est un système de réseau de nœuds opérationnels automatiques, et à condition que le code de démarrage initial ne véhicule pas de logique malveillante, il est peu probable que CRVA refuse de coopérer avec les utilisateurs. En cas de défaillance due à des raisons majeures telles que des pannes d’électricité ou des catastrophes naturelles, les utilisateurs peuvent toujours récupérer leurs actifs en toute sécurité grâce aux mécanismes prévus dans le processus mentionné précédemment.
Le postulat est de faire confiance à CRVA pour être suffisamment décentralisé pour ne pas agir de manière malveillante (comme expliqué ci-dessus). Si une fois les BTC transférés vers le canal unidirectionnel de CRVA, cela signifie généralement que la position stable correspondante a été liquidée, et que les droits de propriété des BTC appartiennent à l’utilisateur liquidé. Ce dernier peut alors initier une demande de retrait qui sera examinée par CRVA. Si elle est validée, CRVA générera une signature à cet effet et transférera le montant correspondant de BTC au liquidateur. Si CRVA ne répond pas dans un certain délai, après le verrouillage, ces BTC seront transférés à l’adresse contrôlée par le DAO pour un traitement ultérieur à travers une signature multiple, le tout étant soumis à la gouvernance du DAO. Ce dernier est composé de projets bien connus, de sociétés de sécurité et d’institutions d’investissement, et a pour mission de contrer les actes malveillants d’une seule entité.
En résumé, nous avons exposé la solution de garde des actifs Bitcoin de DeepSafe. Pour les actifs ERC-20, le principe appliqué est similaire et ne sera pas détaillé ici. En ce qui concerne l’incident de gel d’unibtc mentionné plus tôt, si le pont inter-chaînes d’unibtc avait adopté la solution de garde de soi de CRVA, l’émetteur d’actifs aurait eu beaucoup plus de difficultés à obtenir un contrôle unilatéral sur la situation.