Le retour en arrière sur la chaîne ne peut-il pas récupérer les actifs volés ?

Trois blockchains publiques ont été arrêtées d'urgence, mettant en lumière les limites réelles des pouvoirs d'urgence sur la chaîne.

Rédigé par : Liam 'Akiba' Wright

Traduit par : Saoirse, Foresight News

En l'espace de quatre jours, trois réseaux de blockchain ont cessé de produire des blocs. Chaque arrêt de réseau a utilisé des pouvoirs d'urgence totalement différents, dont seul Cronos a réécrit une partie de l'histoire officielle de la chaîne.

Cronos a déclaré qu'après qu'un exploit ait été découvert dans le protocole Tectonic, les nœuds de validation ont arrêté le réseau via un mécanisme de consensus, restaurant la chaîne à l'état antérieur à l'attaque et redémarrant la production de blocs à partir de la hauteur de bloc 90,896,189. Cette opération a non seulement arrêté la production de blocs, mais a également directement réécrit l'état de la chaîne. Les transactions et changements d'état générés après le point de restauration ne font plus partie de la chaîne principale officielle redémarrée.

Ontology et ICON ont adopté une autre méthode d'urgence. Ontology a suspendu la production de blocs avant de confirmer l'attaque malveillante, son annonce de mise à jour du 1er septembre indiquant que cette activité malveillante n'avait pas causé de pertes d'actifs pour les utilisateurs. ICON a d'abord suspendu le contrat attaqué, puis a arrêté l'ensemble du réseau ; la fondation a déclaré que le réseau était sous son contrôle pendant la phase de migration, à ce moment-là, la plupart des ICX volés avaient déjà été transférés vers des comptes de garde d'échange.

L'arrêt de la blockchain n'est qu'un premier niveau de contrôle. La question plus profonde est : qui a le pouvoir d'ordonner l'arrêt du réseau ? Peuvent-ils réécrire l'état de la chaîne déjà confirmé ? Quelles pertes seront irréparables lorsque les fonds circulent entre chaînes ou entrent dans des institutions de garde centralisées ?

Les informations sur les mesures d'urgence déclenchées par l'événement révèlent les risques de restauration connus : l'attaque par exploit de CronosTectonic a arrêté le réseau et restauré l'état de la chaîne avant l'exploit, selon le consensus des validateurs ; l'annonce de redémarrage n'a pas révélé les données de vote et toutes les activités sur la chaîne après le point de contrôle ont été annulées ; les fonds transférés vers Ethereum ne sont pas sous le contrôle de Cronos ; les statistiques finales des pertes du protocole Tectonic ne sont pas encore complètes ; Ontology a découvert des risques potentiels lors de ses inspections régulières, suspendant préventivement la production de blocs après confirmation d'activités malveillantes, sans effectuer de retour en arrière ; les seuils de déclenchement des mesures d'urgence et les mises à jour du réseau pendant lesquelles les transactions ne peuvent pas être exécutées n'ont pas été divulgués ; aucune perte d'actifs utilisateur n'a été constatée ; le contrat de migration d'ICON présente une vulnérabilité de répétition, suspendant d'abord le contrat, puis arrêtant l'ensemble du réseau ; pendant la phase de migration, le réseau est contrôlé par la fondation, le nombre de nœuds de validation principaux a été réduit et les pertes sont à la charge de la fondation ; la possibilité de récupérer les ICX stockés dans les échanges dépend des gardiens, des procédures judiciaires et des organismes d'application de la loi.

Comparaison des méthodes de gestion d'urgence des trois blockchains publiques : Cronos, Ontology, ICON

Cronos : De l'arrêt à la réécriture de l'état de la chaîne

Cronos a qualifié la gestion de cet événement d'« action d'urgence du consensus des validateurs ». L'annonce de redémarrage du 31 août indique qu'à 23:49:01 UTC le 30 août, le réseau a repris la production de blocs à partir de la hauteur de bloc 90,896,189, l'état de la chaîne revenant à l'état antérieur à l'attaque par exploit de Tectonic.

L'opération d'arrêt de Cronos signifie qu'une décision de répartition des intérêts a été prise concernant le point de restauration. Après le point de contrôle, l'état de la chaîne lié à l'exploit, ainsi que toutes les transactions non pertinentes pendant cette période, ont été effacés de la chaîne officielle. L'annonce de redémarrage n'a pas été accompagnée d'une liste de transactions, de statistiques sur les nœuds de validation, de seuils de poids de vote ou de listes de nœuds participants. Cronos a promis de publier un rapport de rétrospective, nécessitant une explication complète du processus de gestion et de l'impact technique.

Même l'échelle des actifs réellement protégés par cette intervention n'est pas encore déterminée. TRM Labs estime qu'après la manipulation du prix du jeton TONIC, environ 75 millions de dollars d'actifs ont été empruntés ; parmi eux, environ 6 millions de dollars ont été transférés vers Ethereum, et environ 68,7 millions de dollars ont été récupérés sur la chaîne Cronos. Les statistiques de Bitquery indiquent une échelle totale de sorties encore plus élevée, avec environ 8,3 millions de dollars d'actifs transférés vers Ethereum, un total de 10 961 blocs ayant été annulés.

Les deux méthodes de comptage statistiques concernent des objets différents, les données finales de pertes du protocole Tectonic restent à être publiées. Mais une chose est déjà très claire : le retour en arrière de Cronos ne peut que restaurer l'état qui reste dans cette chaîne, les actifs sur la chaîne Ethereum ne sont absolument pas sous son contrôle.

Le plan de gestion des actifs de Tectonic laisse encore des problèmes de comptes pour les utilisateurs. Le protocole a déclaré qu'il ouvrirait en priorité les fonctions de retrait et de remboursement de prêts, tout en suspendant les dépôts et les nouveaux emprunts. Ce plan offre aux utilisateurs une voie de sortie et de désendettement, mais il n'est pas encore confirmé si les fournisseurs de fonds peuvent récupérer la totalité de leur investissement. Le rapport de rétrospective que Tectonic doit publier doit également clarifier le principe de l'exploit, le total des sorties de fonds, l'échelle des créances douteuses, les actifs récupérés et les autres dettes restantes.

Le progrès de la restauration des différentes infrastructures n'est pas synchronisé avec le redémarrage du consensus de la chaîne. Cronos rappelle que divers protocoles, ponts inter-chaînes, explorateurs de blocs et services RPC nécessitent plus de temps pour se rétablir. La page d'état d'Alchemy a également enregistré séparément cet arrêt et la restauration ultérieure. Le réseau de la chaîne peut être déclaré officiellement redémarré, mais les divers services qui en dépendent ne sont pas nécessairement prêts.

Ontology : L'arrêt vise seulement à gagner du temps pour la gestion, sans annuler les transactions

L'action de gestion d'Ontology a eu lieu avant la confirmation de l'activité malveillante. Le réseau a déclaré que l'équipe de développement principale avait découvert des risques de sécurité potentiels lors d'une inspection régulière et a immédiatement suspendu la production de blocs, confiant l'examen du système à l'équipe technique et aux nœuds de validation.

L'annonce de mise à jour du 1er septembre a déclaré que l'examen avait confirmé l'existence d'une attaque malveillante, le réseau principal continuera d'être arrêté pour effectuer des réparations de vulnérabilité et des mises à jour ; cette attaque n'a pas porté atteinte aux actifs des utilisateurs. L'objectif d'Ontology est de rétablir un fonctionnement normal dans les 24 heures, à condition que les contrôles de sécurité, les réparations de vulnérabilité, les mises à jour et les tests se déroulent tous sans problème.

L'arrêt d'Ontology conserve tous les états de la chaîne déjà confirmés, ne suspendant que la confirmation et le règlement des nouvelles transactions. L'annonce ne précise pas de point de restauration et ne publie pas l'ensemble des transactions à annuler.

Les informations sur les pouvoirs divulguées ne sont pas complètes. L'annonce mentionne la participation de l'équipe de développement principale, de l'équipe technique et des nœuds de validation du réseau à la gestion, mais ne précise pas qui est le décideur final ayant un pouvoir contraignant, ni ne fournit de seuils numériques pour les mesures d'urgence. La documentation VBFT d'Ontology décrit le mécanisme de consensus normal, y compris la génération de nœuds pour confirmer les blocs et gérer les mises à jour des contrats, mais le document ne couvre que les scénarios de fonctionnement normal, les règles d'arrêt d'urgence utilisées le 31 août n'ont pas été publiées.

Même sans pertes d'actifs, l'arrêt entraîne toujours des coûts réels. Ontology informe les utilisateurs que les transactions sur la chaîne ne pourront pas être traitées, conseillant de ne pas effectuer d'opérations sensibles au temps ; par la suite, il a été déclaré que le redémarrage du réseau dépend de la réparation des vulnérabilités, des mises à jour et des tests. Les utilisateurs ne peuvent pas ajuster leurs positions ou effectuer des transferts sur la chaîne, tous les services externes connectés à cette chaîne doivent simplement attendre le signal du réseau.

Les critères de détermination du redémarrage sont orientés vers la sécurité, mais les détails spécifiques sont limités. Ontology a déclaré que tant que les réparations, mises à jour, tests et vérifications sont tous terminés, ils s'efforceront de rétablir le service dans les 24 heures, mais qui détermine si les conditions sont remplies et quel est le seuil déclencheur n'a pas été divulgué.

Cela entraîne une incertitude au niveau de la gouvernance : l'annonce précise les parties participant à l'examen, mais le sujet ayant le pouvoir final de décision pour le redémarrage n'est pas clairement défini. Pour les utilisateurs, le risque actuel provient de l'interruption du service, et non de pertes d'actifs déterminées ou d'un retour en arrière de la chaîne.

ICON : Pourquoi l'arrêt de la blockchain est-il déjà trop tard

L'événement d'ICON illustre parfaitement le processus d'alerte, de gestion et de retrait des actifs du contrôle de la chaîne.

Selon le rapport de rétrospective de la fondation, l'attaquant a replays 1492 fois deux messages de retrait signés valides entre 02:01:02 et 02:21:12 UTC. Un défaut de précision a conduit à ce que 1490 de ces appels réussissent, transférant 119,866 millions d'ICX et 531,600 bnUSD du pool d'actifs de la fondation.

À 02:08, le système de surveillance a déjà émis une alerte, et les techniciens ont ensuite commencé l'enquête ; le contrat affecté a été suspendu à 03:53. Les principaux échanges ont progressivement arrêté les dépôts et retraits d'ICX à 05:54, et l'arrêt complet du réseau est entré en vigueur à 06:18:54. ICON a terminé le redémarrage vers 07:51 le 28 août, après environ 25 heures, tout en corrigeant les vulnérabilités sous-jacentes.

Le rapport de rétrospective estime que la racine du problème réside dans le processus de réponse à l'événement, et non dans une capacité de détection insuffisante. L'alerte a été déclenchée en 7 minutes, mais ce type d'alerte est souvent confondu avec des anomalies RPC non pertinentes, et le système n'a pas informé le personnel de garde. L'enquête technique n'a été lancée qu'à environ 03:40, peu après le contrat a été suspendu.

Lorsque la chaîne a officiellement cessé de fonctionner, la plupart des ICX affectés avaient déjà été intégrés dans le système de garde des échanges. Les moyens de contrôle du côté de la chaîne ICON n'ont pas pu empêcher les échanges de transférer ou de convertir les actifs qu'ils détenaient. La fondation ne peut compter que sur le gel des actifs des échanges, les notifications de préservation, les avocats et les organismes d'application de la loi pour traiter la situation.

Les frontières de garde déterminent directement l'attribution des pertes. ICON a déclaré que tous les actifs affectés appartenaient à la fondation, les dépôts, soldes et positions des utilisateurs ordinaires n'ayant pas été touchés. Le rapport indique que 531,600 bnUSD et 1,366,000 SODA ont été entièrement récupérés ; parmi les 113,634 USDC prêtés, 82,430 ont été récupérés. La perte nette confirmée est d'environ 150.2 ETH, plus 31,204 USDC. La grande majorité des ICX concernés n'ont été que gelés ou suivis dans les échanges, sans avoir été réellement récupérés.

La structure de contrôle d'ICON diffère également des deux autres cas. Le rapport de rétrospective indique que pendant la migration des jetons, le réseau était sous le contrôle de la fondation ; le document de directives de migration mentionne que le consensus fonctionne en mode de maintenance, avec seulement 7 nœuds principaux. Ainsi, cet arrêt repose sur une architecture de fonctionnement spéciale clairement contrôlée par la fondation.

Les pouvoirs d'urgence sont en essence également une question de pouvoir au niveau du bilan

Chaque arrêt de blockchain est essentiellement un transfert de risque vers d'autres endroits.

• Cronos modifie l'histoire de la chaîne officielle : cela peut protéger les actifs qui restent sous la juridiction de la chaîne, mais annule également toutes les activités normales sur la chaîne en dehors de l'exploit, et n'a aucun pouvoir sur les actifs sur Ethereum.
• Ontology transforme le risque en coûts de temps et en pertes de disponibilité de service, les transactions ne pouvant pas être réglées pendant l'enquête, sans confirmation de pertes d'actifs.
• ICON a terminé l'isolement des contrats et du réseau après que les actifs aient déjà été transférés hors de la portée de garde de la chaîne ; les pertes confirmées sont à la charge de la fondation, et la récupération des ICX gelés dépend des échanges et des autorités judiciaires.

Une simple évaluation décentralisée peut masquer ces résultats fondamentalement différents. Un critère d'évaluation plus pragmatique est : les règles de gestion d'urgence sont-elles publiques ? Quel est le seuil déclencheur pour les mesures d'urgence ? S'agit-il simplement d'arrêter la production de nouveaux blocs, ou de réécrire l'état de la chaîne déjà confirmé ? Lorsque l'intervention se produit, qui contrôle les actifs qui sortent de la juridiction de cette chaîne ? Qui s'engage à assumer les pertes restantes ?

Cronos et Tectonic doivent encore publier un rapport de rétrospective complet. Ontology doit divulguer les détails de l'attaque et les règles d'autorisation d'urgence, et confirmer si les conditions de jugement pour les mises à jour et le redémarrage ont été atteintes. Ce qui mérite vraiment d'être comparé, ce sont les limites de risque définies par chaque réseau ------ quelles histoires, quels temps et quels fonds seront placés sous risque.