Cronos a annulé un piratage de 75 millions de dollars. La solution soulève une question plus vaste

Le 30 août, Cronos a fait quelque chose que la plupart des blockchains affirment ne pas pouvoir faire.

Ses validateurs ont interrompu la production de blocs, écarté plus de 10 000 blocs de l'historique canonique et redémarré la chaîne à partir d'un instantané pris avant que Tectonic, un protocole de prêt de Cronos, ne perde environ 75 millions de dollars dans une attaque par manipulation de garanties.

La réponse a fonctionné au sens le plus étroit. Environ 69 millions de dollars d'actifs gelés ont été sauvés. Seuls environ 6 millions de dollars s'étaient échappés vers Ethereum avant l'arrêt. Les déposants de Tectonic ont évité ce qui aurait pu être une perte quasi totale.

Mais l'intervention a également effacé environ deux heures d'historique de transactions pour chaque utilisateur du réseau. Des transactions légitimes, des transferts, des interactions de contrats et des activités de pont sans lien avec l'exploit ont disparu de la chaîne canonique.

C'est là que réside l'inconfort. Cronos a contenu un piratage en prouvant que son historique pouvait être réécrit.

Comment Tectonic a perdu 75 millions de dollars

L'exploit de Tectonic a suivi un schéma DeFi familier : gonfler un actif de garantie peu échangé, emprunter des actifs liquides contre la valorisation gonflée, puis laisser le protocole détenir une garantie invendable à un prix proche de celui annoncé.

Tectonic permettait aux utilisateurs de déposer TONIC, son jeton de gouvernance, en garantie. TONIC avait un facteur de garantie de 20 %, ce qui signifie que les emprunteurs pouvaient retirer des actifs jusqu'à un cinquième de la valeur de garantie annoncée du jeton.

L'attaquant a dépensé environ 600 000 dollars pour acheter du TONIC sur des marchés peu liquides de Cronos, poussant le jeton environ 100 fois plus haut en 20 minutes environ. L'attaquant a ensuite fourni 364,6 billions de TONIC à Tectonic à la valorisation gonflée, créant une position de garantie annoncée d'environ 375 millions de dollars.

Contre cette position, l'attaquant a emprunté environ 75 millions de dollars d'actifs liquides au protocole.

Le calcul était brutal. Une manipulation de prix de 600 000 dollars a produit un retrait de 75 millions de dollars. Le rendement du capital déployé était d'environ 12 400 %. La garantie adossée aux prêts n'aurait pas pu être liquidée à un prix proche de sa valeur annoncée sans effondrer le marché.

Avant l'exploit, Tectonic détenait environ 121,7 millions de dollars de valeur totale bloquée et 82,7 millions de dollars de prêts actifs. Il représentait près de la moitié du capital DeFi de Cronos. En 48 heures, sa TVL était tombée à environ 3 millions de dollars, soit une baisse d'environ 97,5 %.

L'arrêt a gelé toute la chaîne

Les validateurs de Cronos ont détecté l'exploit rapidement et ont cessé de produire des blocs.

Cette décision a gelé plus que Tectonic. Chaque transfert, interaction de contrat intelligent et transaction de pont sur Cronos s'est arrêté. Les utilisateurs sans exposition à Tectonic ne pouvaient pas déplacer leurs fonds. Les applications construites sur Cronos ont perdu l'accès à l'activité normale de la chaîne. Les fournisseurs RPC et les ponts ont dû se mettre en pause ou se resynchroniser.

Le timing était critique. Au moment où les validateurs ont arrêté la chaîne, l'attaquant avait transféré environ 6 millions de dollars vers Ethereum. Les 69 millions de dollars restants se trouvaient à des adresses Cronos identifiées, gelés mais toujours techniquement sous le contrôle de l'attaquant sur la chaîne arrêtée.

Le PDG de Crypto.com, Kris Marszalek, a déclaré que l'exchange et l'application continuaient de fonctionner normalement et que les fonds des clients étaient en sécurité. Cette déclaration s'appliquait aux services centralisés de Crypto.com, pas aux fonds déposés dans Tectonic. La distinction est importante car Cronos, Crypto.com et Tectonic sont étroitement associés dans l'esprit du marché, mais ce ne sont pas le même système.

Cronos a choisi le retour en arrière

Au lieu de redémarrer depuis l'état arrêté et d'essayer de geler les adresses de l'attaquant, les validateurs ont restauré Cronos à un instantané antérieur à l'exploit. La chaîne a repris à partir du bloc 90 896 189 après que plus de 10 000 blocs ont été écartés.

Les transactions de l'attaque n'existaient plus sur la chaîne canonique. Pas plus que toutes les transactions légitimes survenues pendant la même fenêtre.

Cronos a décrit cette mesure comme une action d'urgence par consensus des validateurs pour protéger les utilisateurs. Un post-mortem complet n'avait pas encore été publié. La question sans réponse est de savoir comment le point de restauration a été choisi, combien de validateurs ont participé et quelle norme de gouvernance a été utilisée pour justifier la réécriture de l'historique public de la chaîne.

Les fournisseurs d'infrastructure ont dû s'adapter à la nouvelle version de la chaîne. Tatum, qui sert les développeurs sur Cronos, a rejoué les données de la chaîne à partir du bloc 90 896 188 pour resynchroniser ses systèmes. D'autres explorateurs, indexeurs, fournisseurs RPC et ponts ont dû faire un travail de réconciliation similaire.

Le retour en arrière n'a pas seulement inversé l'attaquant. Il a forcé chaque service connecté à Cronos à accepter une nouvelle version de la réalité.

L'oracle n'était pas la défaillance principale

Les exploits par manipulation de prix sont souvent imputés aux oracles. Marcin Kazmierczak, cofondateur de RedStone, a rejeté cette interprétation.

« L'oracle n'était pas en tort. Il a rapporté avec précision le prix du TONIC sur le pool qu'il lisait à ce moment-là », a-t-il déclaré.

Cette distinction est importante. Un oracle peut correctement rapporter un prix de marché manipulé. Le rôle du protocole de prêt est de décider si ce prix est sûr pour prêter.

La conception de Tectonic traitait le prix de marché coté du TONIC comme une valeur de garantie utilisable sans tenir compte adéquatement de la liquidité exécutable. Un jeton peut se négocier à un prix élevé sur un marché peu profond tout en étant impossible à liquider à grande échelle.

Kazmierczak a identifié le contrôle manquant comme un plafond d'emprunt lié à la liquidité exécutable. Un tel plafond limite l'emprunt en fonction de la quantité de garantie qui pourrait être vendue de manière réaliste sans effondrer son propre marché.

Une fenêtre de prix moyenne pondérée dans le temps plus longue n'aurait peut-être pas résolu le problème. Un mouvement de 100 fois en 20 minutes n'est pas une volatilité normale. C'est un signal que l'actif ne devrait pas soutenir une capacité d'emprunt significative.

Cette attaque était déjà connue

L'attaque de Tectonic n'était pas nouvelle.

Elle ressemblait étroitement à l'exploit de Mango Markets d'octobre 2022, dans lequel Avraham Eisenberg a gonflé le jeton MNGO peu échangé et a emprunté plus de 100 millions de dollars contre la valeur de garantie gonflée. Un jury de Manhattan a condamné Eisenberg pour fraude sur les matières premières, manipulation des matières premières et fraude électronique, bien qu'un juge fédéral ait ensuite annulé les condamnations pour des questions de compétence et de preuves.

L'incertitude juridique est importante car Eisenberg a soutenu qu'il avait utilisé le protocole comme prévu. Cette défense n'a pas mis fin au débat sur la question de savoir si l'exploitation de paramètres de garantie faibles est une manipulation de marché, une fraude ou simplement un abus de règles mal écrites.

Trois jours avant l'exploit de Tectonic, Moonwell sur Base a perdu 8,7 millions de dollars dans une attaque similaire impliquant le jeton illiquide MAMO. Moonwell a réagi en réduisant les plafonds d'emprunt à 1 wei sur ses marchés principaux de Base, fermant ainsi de fait les nouveaux prêts sur ces marchés.

Moola Market sur Celo a subi une attaque similaire en octobre 2022. Quatre ans plus tard, le même schéma fonctionne toujours parce que les protocoles continuent de lister des jetons de gouvernance peu liquides en garantie.

Les incitations sont claires. Les équipes de protocole gagnent de la TVL. Les détenteurs de jetons gagnent de l'utilité. Le risque reste caché jusqu'à ce que quelqu'un teste si la garantie peut réellement être liquidée. Pour les jetons de gouvernance à faible liquidité, ce n'est généralement pas le cas.

La comparaison avec le fork de la DAO a ses limites

Le fork de la DAO d'Ethereum en 2016 est la comparaison évidente. Après qu'un attaquant a drainé environ 60 millions de dollars de la DAO, la communauté Ethereum a voté pour un hard fork, annulant le vol sur la nouvelle chaîne tandis qu'Ethereum Classic préservait l'historique d'origine.

La différence réside dans le processus.

Le fork de la DAO a suivi des semaines de débat public. Les mineurs, les développeurs, les utilisateurs et les exchanges ont eu le temps de discuter, de se coordonner et de choisir leur camp. La scission a produit Ethereum Classic comme un rappel permanent que tout le monde n'a pas accepté la réécriture.

Cronos a agi en quelques heures. Il n'y a pas eu de débat public prolongé, pas de vote communautaire large et pas de chaîne alternative préservée pour les utilisateurs qui rejetaient le retour en arrière. Les validateurs se sont mis d'accord, ont restauré un état antérieur et ont continué.

Cette rapidité est préoccupante. Un retour en arrière qui exige des semaines de conflit public est un dernier recours. Un retour en arrière qu'un petit ensemble de validateurs peut exécuter rapidement est un outil administratif.

La structure des validateurs a rendu la réponse possible. Cronos est maintenu par un ensemble de validateurs relativement petit, dont beaucoup sont contrôlés par Crypto.com ou étroitement associés à lui. Coordonner un arrêt et un retour en arrière est plus facile dans cette structure que sur un réseau plus vaste et plus distribué comme Ethereum ou Bitcoin.

Le problème n'est pas que les validateurs ont agi pour sauver les utilisateurs. Le problème est qu'ils le pouvaient.

Qui a payé pour les blocs effacés

Le retour en arrière a protégé les déposants de Tectonic. Il a également annulé l'activité d'utilisateurs non liés.

Toute personne ayant effectué une transaction pendant la fenêtre d'environ deux heures a vu cette activité annulée. Les transactions DEX ont été défaites. Les transferts de portefeuille ont disparu. Les interactions de contrats intelligents ont été effacées. Cronos n'a pas publié de données montrant combien de transactions non liées à l'exploit ont été affectées.

L'asymétrie est difficile à ignorer. Les utilisateurs lésés par l'exploit de Tectonic ont été restaurés à leurs soldes d'avant l'attaque. Les utilisateurs dont les transactions légitimes sont tombées dans la fenêtre du retour en arrière ont perdu ces transactions sans cadre de compensation visible ni comptabilité publique.

Cela crée une incitation inconfortable. Si un protocole est drainé, les validateurs peuvent réécrire l'historique pour indemniser les déposants. Si la transaction légitime d'un utilisateur se trouve dans la même fenêtre, elle peut être effacée comme dommage collatéral.

Cronos doit encore expliquer comment les validateurs ont pesé ces préjudices les uns contre les autres.

Les développeurs ont désormais un nouveau risque à intégrer

Les développeurs qui construisent sur Cronos doivent maintenant tenir compte d'un risque qui était théorique avant le 30 août : l'état des applications peut être effacé rétroactivement par consensus des validateurs.

Pour un simple échange de jetons, cela peut être gênant. Pour les applications connectées à des systèmes externes, c'est beaucoup plus grave.

Un processeur de paiement qui accepte une transaction Cronos et expédie des marchandises ne peut pas annuler l'expédition si la transaction disparaît plus tard. Un protocole inter-chaînes qui frappe des actifs ailleurs après un dépôt Cronos peut se retrouver avec une frappe sur une chaîne et aucun dépôt sur Cronos. Un oracle ou un système d'automatisation qui déclenche des actions sur la base des confirmations Cronos peut ne pas être en mesure de défaire ces actions.

Les fournisseurs d'infrastructure héritent également de coûts opérationnels. Les indexeurs, les API de données et les explorateurs doivent pouvoir se resynchroniser autour d'un historique réécrit. Pour les équipes qui prennent en charge de nombreuses chaînes, un réseau à finalité faible est plus coûteux et plus risqué à intégrer.

Cela a aussi des implications pour les actifs tokenisés. Toute plateforme d'actifs du monde réel utilisant Cronos devrait se demander si le consensus des validateurs pourrait effacer des transferts de propriété après qu'ils ont déjà été reflétés dans des systèmes hors chaîne.

Les 6 millions de dollars montrent la limite

Les 6 millions de dollars transférés par l'attaquant ont survécu parce qu'ils avaient déjà atteint Ethereum.

C'est la frontière de tout retour en arrière. L'autorité d'une chaîne s'arrête à ses propres règles de consensus. Les validateurs d'Ethereum n'ont pas accepté le retour en arrière de Cronos et n'avaient aucune raison de l'honorer. Une fois que les fonds ont traversé les chaînes, Cronos ne pouvait plus les effacer.

Pour les applications inter-chaînes, cela crée une étrange condition de course. La valeur qui reste sur une chaîne capable de retour en arrière peut être réécrite. La valeur qui s'échappe vers une chaîne à finalité plus forte peut survivre.

L'attaquant de Tectonic l'a compris. Le premier mouvement a été de transférer les fonds hors de la chaîne. La fenêtre de deux heures entre l'exploit et l'arrêt est devenue une course entre la vitesse de transfert de l'attaquant et la vitesse de coordination des validateurs. Cronos a gagné la majeure partie de cette course, mais pas la totalité.

La finalité est un spectre

Le retour en arrière de Cronos a sauvé les utilisateurs d'une perte importante. Il a aussi rendu le modèle de confiance du réseau impossible à ignorer.

Certains utilisateurs peuvent préférer ce compromis. Ils peuvent vouloir que les validateurs interviennent lors d'exploits extrêmes, surtout lorsque l'alternative est l'effondrement d'un protocole de prêt. C'est une préférence défendable.

Mais ce n'est pas la même chose que l'immuabilité.

Une blockchain dont les validateurs peuvent arrêter et rembobiner l'historique offre un produit différent de celui où la finalité est crédible même sous stress. Elle peut encore être utile. Elle peut encore soutenir des applications. Elle peut même être plus sûre pour certains utilisateurs dans des urgences spécifiques.

Mais ce n'est pas une infrastructure neutre au sens le plus fort. C'est une infrastructure gouvernée par des personnes ayant le pouvoir de choisir quel historique survit.

C'est la vraie leçon de l'exploit de Tectonic. L'attaque de 75 millions de dollars a exposé des contrôles de garantie faibles. Le retour en arrière a exposé quelque chose de plus vaste : la finalité de Cronos dépend de la discrétion des validateurs. Pour quiconque construit, transfère ou détient des actifs sur le réseau, cela fait désormais partie du modèle de risque.