Auteur : Liam 'Akiba' Wright, Cryptoslate
Compilé par : Saoirse, Foresight News
En quatre jours, trois réseaux 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 modifié une partie de l'historique officiel de la chaîne.
Cronos a indiqué qu'après l'attaque de vulnérabilité sur le protocole Tectonic, les nœuds de validation ont arrêté le réseau via le mécanisme de consensus, ramenant la chaîne à son é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 réécrit directement l'état de la chaîne. Toutes les transactions et modifications d'état générées après le point de restauration ne font plus partie de la chaîne principale officielle après redémarrage.
Ontology et ICON ont adopté un autre ensemble de mesures d'urgence. Ontology a suspendu la production de blocs avant de confirmer l'attaque malveillante ; dans sa mise à jour du 1er septembre, il a indiqué que cette activité malveillante n'a pas entraîné de perte d'actifs pour les utilisateurs. ICON a d'abord suspendu le contrat attaqué, puis arrêté l'ensemble du réseau ; la fondation a déclaré que, pendant la phase de migration, elle avait le contrôle du réseau, et que la majorité des ICX volés avaient déjà été transférés vers des comptes de dépôt d'échanges.
L'arrêt de la chaîne de blocs n'est qu'un mécanisme de contrôle de premier niveau. La question plus profonde est la suivante : qui a le pouvoir d'ordonner l'arrêt du réseau ? Peuvent-ils modifier l'état de la chaîne déjà confirmé ? Quelles pertes deviennent irrécupérables lorsque les fonds sont transférés entre chaînes ou déposés dans des entités de garde centralisées ?
Les informations d'autorisation pour les mesures d'urgence en cas d'événement déclenché par le réseau ont été restaurées. Risque connu : attaque par vulnérabilité CronosTectonic, entraînant l'arrêt du réseau et la restauration de l'état de la chaîne avant la vulnérabilité, avec validation par consensus des validateurs ; les annonces de redémarrage n'ont pas divulgué les données de décompte et les seuils de vote ; toutes les activités sur la chaîne après le point de contrôle sont annulées ; les fonds transférés vers Ethereum ne sont pas sous le contrôle de Cronos ; le bilan final des pertes du protocole Tectonic n'est pas encore terminé. Lors d'une inspection quotidienne, Ontology a détecté un risque potentiel, confirmé ultérieurement comme activité malveillante : production de blocs suspendue préventivement, sans rollback ; l'équipe de développement principale, l'équipe technique et les nœuds validateurs ont participé ; les seuils de déclenchement des mesures d'urgence n'ont pas été divulgués ; pendant la réparation et la mise à niveau du réseau, les transactions n'étaient pas exécutables ; aucune perte d'actifs utilisateurs n'a été constatée. Le contrat de migration ICON présente une vulnérabilité de rejeu : contrat suspendu, puis arrêt complet du réseau ; pendant la phase de migration, le réseau est sous le contrôle de la fondation, avec réduction du nombre de nœuds validateurs principaux ; les pertes sont assumées par la fondation ; la récupération des ICX déposés sur les échanges dépend du fournisseur de custody, des procédures juridiques et des autorités compétentes.
Comparaison des méthodes de réponse d'urgence pour les chaînes publiques Cronos, Ontology et ICON
Cronos : de l'arrêt à la réécriture de l'état de la chaîne
Cronos a qualifié cette réponse à l'événement comme une « action d'urgence de consensus des validateurs ». L'annonce de redémarrage du 31 août indique que le réseau a repris la production de blocs à 23:49:01 UTC le 30 août, à la hauteur de bloc 90 896 189, avec un retour à l'état de la chaîne antérieur à l'attaque de la vulnérabilité Tectonic.
L'opération d'arrêt de Cronos implique de prendre une décision sur la répartition des bénéfices au point de restauration. Après le point de contrôle, l'état chaîne lié à la vulnérabilité, ainsi que toutes les transactions non pertinentes de cette période, sont supprimés de la chaîne officielle. L'annonce de redémarrage ne comporte aucune liste de transactions, aucun statistique de nœuds de validation, aucun seuil de poids de vote ni liste des nœuds participants. Cronos s'engage à publier un rapport d'analyse post-incident, qui devra expliquer en détail le processus de traitement et la portée technique de l'impact.
La taille réelle des actifs protégés par cette intervention n’est pas encore établie. TRM Labs estime qu’après la manipulation du prix du jeton TONIC, environ 75 millions de dollars d’actifs ont été empruntés ; dont environ 6 millions de dollars ont été transférés vers Ethereum et environ 68,7 millions de dollars ont été annulés sur la chaîne Cronos. Les statistiques de Bitquery indiquent un volume total de sorties plus élevé, avec environ 8,3 millions de dollars d’actifs transférés vers Ethereum et un total de 10 961 blocs abandonnés.
Les deux systèmes de statistiques portent sur des objets différents, et les données finales de perte de Tectonic restent à être publiées. Toutefois, un point est déjà très clair : le rollback de Cronos ne peut restaurer que les états encore présents sur cette chaîne ; les actifs sur la chaîne Ethereum sont entièrement hors de son contrôle.
Le plan de traitement des actifs de Tectonic laisse encore des problèmes comptables pour les utilisateurs. Le protocole indique qu'il ouvrira 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 un chemin de sortie et de déslevier, mais il n'est pas encore confirmé si les fournisseurs de fonds pourront récupérer intégralement leurs avoirs. Le rapport postérieur à publier par Tectonic devra encore clarifier le mécanisme de la faille, le montant total des sorties de fonds, l'ampleur des créances douteuses, les actifs récupérés et les autres dettes résiduelles.
Les progrès de la restauration des différentes infrastructures ne sont pas synchronisés avec le redémarrage de la consensus de la chaîne. Cronos rappelle que les différents protocoles, les ponts cross-chain, les explorateurs de blocs et les services RPC nécessiteront plus de temps pour être restaurés. La page d'état d'Alchemy documente également séparément cette interruption et sa restauration ultérieure. Le réseau de la chaîne peut être déclaré officiellement redémarré, mais les services qui en dépendent ne sont pas nécessairement prêts.
Ontology : L'arrêt vise uniquement à gagner du temps pour traiter la situation et ne annule pas les transactions.
Les mesures prises par Ontology ont été mises en œuvre avant la confirmation d'activités malveillantes. Le réseau a indiqué que l'équipe de développement principale a détecté des vulnérabilités potentielles lors de ses inspections quotidiennes, a immédiatement suspendu la production de blocs, et a confié l'examen du système à l'équipe technique et aux nœuds de validation.
La mise à jour du 1er septembre indique qu'un examen a confirmé la présence d'une attaque malveillante ; le mainnet restera hors ligne pour permettre la correction des vulnérabilités et la mise à niveau du réseau ; les actifs des utilisateurs n'ont pas été compromis. Ontology vise à rétablir le fonctionnement normal dans les 24 heures, à condition que les analyses de sécurité, la correction des vulnérabilités, la mise à niveau et les tests soient tous terminés avec succès.
L'arrêt de Ontology conserve tous les états chainés confirmés, tout en arrêtant uniquement la confirmation et le règlement des nouvelles transactions. L'annonce ne spécifie pas de point de reprise ni ne publie l'ensemble des transactions à annuler.
Les informations sur les autorisations divulguées ne sont pas complètes. L'annonce mentionne que l'équipe de développement centrale, l'équipe technique et les nœuds de validation du réseau participent à la gestion, mais ne précise pas qui est la personne décisionnelle ayant autorité contraignante finale, ni ne fournit de seuil numérique pour la gestion d'urgence. Le document VBFT d'Ontology décrit le mécanisme de consensus habituel, incluant la génération de blocs confirmés par les nœuds et la gestion de la mise à jour du consensus des nœuds de contrat, mais ce document ne couvre que les scénarios de fonctionnement normal ; les règles d'urgence de suspension utilisées le 31 août n'ont pas été rendues publiques.
Même sans causer de perte dactifs, l'arrêt entraîne des coûts réels. Ontology a informé les utilisateurs que les transactions sur la chaîne ne pourraient pas être traitées et a recommandé d'éviter les opérations sensibles au temps ; ultérieurement, elle a indiqué que le redémarrage du réseau dépendait de la correction des vulnérabilités, de la mise à niveau et des tests. Les utilisateurs ne pouvaient pas ajuster leurs positions ni effectuer de transferts ou de règlements sur la chaîne, et tous les services externes connectés à cette chaîne devaient simplement attendre le signal du réseau.
Les critères de reprise des opérations sont orientés vers la sécurité, mais les détails spécifiques sont limités. Ontology indique qu'il s'efforce de rétablir les services dans les 24 heures une fois les correctifs, les mises à jour, les tests et les validations terminés, mais il n'a pas divulgué qui déterminera la réalisation des conditions ni quelles sont les seuils de déclenchement.
Cela génère une incertitude au niveau de la gouvernance : l'annonce mentionne les parties impliquées dans l'examen, mais le sujet ayant le pouvoir final de décision concernant la reprise des services n'est pas clairement identifié. Pour les utilisateurs, le risque actuel provient d'une interruption de service, et non d'une perte d'actifs certifiée ou d'un rollback sur la chaîne.
ICON : Pourquoi l'arrêt de la blockchain est déjà trop tard
L'événement ICON a entièrement démontré le processus complet d'alerte, de traitement et de libération des actifs du contrôle de la chaîne.
Selon le rapport d'analyse post-incident de la fondation, l'attaquant a replayé 1492 fois deux messages de retrait signés historiquement valides entre le 27 août à 02:01:02 et 02:21:12 UTC. Un défaut de précision a permis à 1490 de ces appels de réussir, entraînant le transfert de 119 866 000 ICX et de 531 600 bnUSD depuis le pool d'actifs de la fondation.
02:08, le système de surveillance a émis une alerte, et les techniciens ont commencé l'enquête par la suite ; les contrats affectés ont été suspendus à 03:53. Les principales bourses ont progressivement arrêté les dépôts et retraits d'ICX à 05:54, et l'arrêt global a été officiellement appliqué à 06:18:54. ICON a été redémarré vers 07:51 le 28 août, après une interruption d'environ 25 heures, tout en corrigeant la vulnérabilité sous-jacente.
Le rapport de rétrospective identifie la cause racine dans les processus de réponse aux incidents, et non dans un manque de capacité de détection. Les alertes ont été déclenchées en moins de 7 minutes, mais ce type d'alerte est souvent confondu avec des anomalies RPC non liées, et le système n'a pas notifié le personnel de garde. L'enquête technique n'a commencé qu'autour de 03:40, peu de temps avant que le contrat ne soit suspendu.
Au moment où la chaîne sera officiellement arrêtée, la majorité des ICX affectés auront déjà été intégrés dans les systèmes de custody des échanges. Les mesures de contrôle du côté de la chaîne ICON ne peuvent empêcher les échanges de transférer ou de convertir les actifs qu'ils détiennent. La fondation ne peut compter que sur la gelée des actifs par les échanges, les notifications de conservation, les avocats et les autorités compétentes pour traiter la situation.
La frontière de la garde détermine directement la répartition des pertes. ICON indique que tous les actifs affectés appartiennent à la fondation ; les dépôts, soldes et positions des utilisateurs ordinaires n'ont pas été touchés. Le rapport indique que 531 600 bnUSD et 1,366 million de 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 s'élève à environ 150,2 ETH, ainsi qu'à 31 204 USDC. La majorité des ICX concernés ont simplement été gelés ou suivis sur l'échange, sans être véritablement récupérés.
La structure de gouvernance d'ICON diffère également des deux autres cas. Le rapport de rétrospective indique que le réseau était sous le contrôle de la fondation pendant la migration des jetons ; le document d'orientation sur la migration mentionne que la consensus fonctionnait en mode maintenance, avec uniquement 7 nœuds principaux. Ainsi, cette interruption repose sur une architecture opérationnelle spéciale clairement contrôlée par la fondation.
Les droits d'urgence sont également des pouvoirs au niveau du bilan.
Chaque arrêt de blockchain déplace essentiellement le risque vers un autre endroit.
- Cronos modifie l'historique de la chaîne principale : peut protéger les actifs encore sous la juridiction de la chaîne, mais annule également les activités normales sur la chaîne hors vulnérabilité, et est impuissant face aux actifs sur Ethereum.
- Ontology transforme le risque en coût temporel et perte de disponibilité du service ; pendant l'enquête, les transactions ne peuvent pas être réglées, et aucune perte comptable sur les actifs n'est confirmée.
- ICON n'a achevé l'isolation du contrat et du réseau qu'après que les actifs aient été transférés hors de la portée de la gestion sur chaîne ; la perte est assumée par la fondation, et la récupération des ICX gelés dépend des échanges et des autorités judiciaires.
Un simple score décentralisé masquera ces résultats radicalement différents. Un critère d'évaluation plus pragmatique est : les règles de traitement d'urgence sont-elles publiques ? Quel est le seuil déclenchant le traitement ? S'agit-il uniquement d'arrêter les nouveaux blocs, ou de réécrire l'état de la chaîne déjà confirmé ? Lorsqu'une intervention a lieu, qui contrôle les actifs échappant à la juridiction de cette chaîne ? Qui s'engage à assumer les pertes restantes ?
Cronos et Tectonic attendent toujours la publication de leur rapport de récapitulation complet. Ontology doit divulguer les détails de l'attaque et les règles d'autorisation d'urgence, puis confirmer si les conditions pour la mise à niveau et le redémarrage ont été remplies. Ce qui mérite vraiment d'être comparé, c'est la limite de risque définie pour chaque réseau — quels historiques, délais et fonds sont exposés au risque.