Trois blockchains publiques à l'arrêt en quatre jours : qui détient le bouton pause ?

Auteur : Liam 'Akiba' Wright, cryptoslate

Compilation : Saoirse, Foresight News

En l'espace de quatre jours, trois réseaux blockchain ont successivement cessé de produire des blocs. Chaque interruption a mobilisé des pouvoirs d'urgence radicalement différents, et seul Cronos a réécrit une partie de l'historique officiel de sa chaîne.

Cronos a indiqué qu'après l'exploitation d'une vulnérabilité du protocole Tectonic, le réseau a été arrêté par un mécanisme de consensus des validateurs, restauré à l'état antérieur à l'attaque, et la production de blocs a repris à partir de la hauteur 90 896 189. Cette opération n'a pas seulement stoppé la production de blocs, elle a directement réécrit l'état de la chaîne. Les transactions et changements d'état survenus après le point de restauration ne font plus partie de la chaîne principale officielle redémarrée.

Ontology et ICON ont eu recours à un autre type de mesure d'urgence. Ontology a suspendu la production de blocs avant même d'avoir confirmé l'activité malveillante ; sa mise à jour du 1er septembre précise que cette activité malveillante n'a entraîné aucune perte 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, et qu'à ce moment-là, la majeure partie des ICX volés avait déjà été transférée vers des comptes de dépôt d'exchanges.

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

Comparaison des mesures d'urgence des trois blockchains publiques Cronos, Ontology et ICON

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

Cronos qualifie cette intervention d'« action d'urgence par 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 90 896 189, l'état de la chaîne ayant été ramené à la situation antérieure à l'exploitation de la vulnérabilité Tectonic.

L'arrêt de Cronos implique un choix quant aux intérêts à privilégier au point de restauration. Après le point de contrôle, les états on-chain liés à la vulnérabilité, ainsi que toutes les transactions sans rapport survenues pendant cette période, ont été effacés de la chaîne officielle. L'annonce de redémarrage ne fournit ni liste des transactions, ni statistiques des nœuds validateurs, ni seuil de pondération des votes, ni liste des nœuds participants. Cronos s'engage à publier un rapport post-mortem, qui devra expliquer en détail le processus de traitement et l'étendue de l'impact technique.

Même l'ampleur des actifs effectivement protégés par cette intervention reste incertaine. TRM Labs estime qu'après la manipulation du prix du jeton TONIC, environ 75 millions de dollars d'actifs ont été empruntés ; environ 6 millions de dollars ont été transférés vers Ethereum, et environ 68,7 millions de dollars ont fait l'objet d'un rollback au sein de la chaîne Cronos. Les statistiques de Bitquery indiquent un flux sortant total 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 méthodes de calcul ne mesurent pas les mêmes objets, et les données définitives de pertes officielles de Tectonic restent à publier. Mais un point est déjà très clair : le rollback de Cronos ne peut restaurer que l'état des actifs restés sur sa propre chaîne, et les actifs sur Ethereum échappent totalement à son contrôle.

Le plan de gestion des actifs de Tectonic laisse subsister des problèmes de comptes pour les utilisateurs. Le protocole indique qu'il donnera la priorité à l'ouverture des retraits et des remboursements 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 la possibilité pour les fournisseurs de capitaux d'être intégralement remboursés n'est pas encore confirmée. Le rapport post-mortem que Tectonic doit publier devra clarifier le principe de la vulnérabilité, le flux sortant total des fonds, l'ampleur des créances irrécouvrables, les actifs déjà récupérés et les dettes restantes.

La progression de la restauration des différentes infrastructures n'est pas synchronisée avec le redémarrage du consensus de la chaîne. Cronos rappelle que les protocoles, les ponts inter-chaînes, les explorateurs de blocs et les services RPC nécessitent plus de temps pour se rétablir. La page de statut d'Alchemy a également consigné séparément cet arrêt et la reprise qui a suivi. Un réseau blockchain peut annoncer officiellement son redémarrage, mais les services qui en dépendent ne sont pas nécessairement prêts.

Ontology : l'arrêt ne vise qu'à gagner du temps, sans annuler les transactions

L'action d'Ontology est intervenue avant la confirmation de l'activité malveillante. Le réseau indique que l'équipe de développement principale a détecté un risque de sécurité potentiel lors d'une inspection de routine, a immédiatement suspendu la production de blocs, et a confié à l'équipe technique et aux nœuds validateurs le soin de mener un audit système.

La mise à jour du 1er septembre précise que l'audit a confirmé la présence d'une activité d'attaque malveillante, que le réseau principal restera à l'arrêt pour procéder à la correction de la vulnérabilité et à la mise à niveau du réseau ; 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é, la correction de la vulnérabilité, la mise à niveau et les tests se déroulent tous avec succès.

L'arrêt d'Ontology conserve l'intégralité de l'état on-chain déjà confirmé, et ne fait que stopper la confirmation et le règlement des nouvelles transactions. L'annonce ne précise aucun point de restauration et ne publie pas l'ensemble des transactions à annuler.

Les informations divulguées sur les pouvoirs sont incomplètes. L'annonce mentionne la participation de l'équipe de développement principale, de l'équipe technique et des nœuds validateurs du réseau, mais n'indique pas qui détient le pouvoir de décision final contraignant, ni ne fournit de seuil chiffré pour le déclenchement de l'urgence. La documentation VBFT d'Ontology décrit le mécanisme de consensus ordinaire, y compris la génération de blocs de confirmation par les nœuds et la mise à jour de l'ensemble des nœuds de consensus par les contrats de gestion, mais cette documentation 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é rendues publiques.

Même sans perte d'actifs, l'arrêt entraîne des coûts réels. Ontology informe les utilisateurs que les transactions on-chain ne pourront pas être traitées et recommande de ne pas exécuter d'opérations sensibles au facteur temps ; il indique ensuite que le redémarrage du réseau dépend de la correction de la vulnérabilité, de la mise à niveau et des tests. Les utilisateurs ne peuvent pas ajuster leurs positions ni effectuer de transferts ou de règlements on-chain, et tous les services externes connectés à cette chaîne doivent attendre le signal du réseau.

Les critères de reprise du fonctionnement sont axés sur la sécurité, mais les détails sont limités. Ontology indique que dès que la correction, la mise à niveau, les tests et la validation seront tous terminés, il s'efforcera de rétablir le service sous 24 heures, mais qui détermine que les conditions sont remplies et quel est le seuil de déclenchement ne sont pas divulgués.

Il en résulte une incertitude au niveau de la gouvernance : l'annonce énumère les parties participant à l'audit, mais l'entité disposant du pouvoir final de redémarrage n'est pas clairement identifiée. Pour les utilisateurs, le risque actuel provient de l'interruption de service, et non d'une perte d'actifs avérée ou d'un rollback de la chaîne.

ICON : pourquoi l'arrêt de la blockchain est-il arrivé trop tard

L'incident d'ICON illustre de bout en bout le processus d'alerte, de traitement et de sortie des actifs du contrôle de la chaîne.

Selon le rapport post-mortem de la fondation, l'attaquant a rejoué 1 492 fois deux messages de retrait signés historiquement valides entre 02:01:02 et 02:21:12 UTC le 27 août. Un défaut de précision a permis à 1 490 de ces appels d'aboutir, transférant 119,866 millions d'ICX et 531 600 bnUSD depuis la réserve d'actifs de la fondation.

À 02:08, le système de surveillance a émis une alerte, mais l'enquête technique n'a été lancée que plus tard ; le contrat affecté a été suspendu à 03:53. Les principaux exchanges ont progressivement fermé les dépôts et retraits d'ICX à partir de 05:54, et l'arrêt complet du réseau est entré en vigueur à 06:18:54. ICON a achevé son redémarrage vers 07:51 le 28 août, soit un intervalle d'environ 25 heures, tout en corrigeant la vulnérabilité sous-jacente.

Le rapport post-mortem estime que la cause profonde du problème réside dans le processus de réponse aux incidents, et non dans une insuffisance de détection. L'alerte s'est déclenchée en moins de 7 minutes, mais ce type d'alerte est souvent confondu avec des anomalies RPC sans rapport, et le système n'a pas notifié le personnel d'astreinte. L'enquête technique n'a démarré que vers 03:40, et le contrat n'a été suspendu que peu après.

Au moment où la chaîne a été officiellement arrêtée, la majeure partie des ICX affectés avait déjà été intégrée au système de garde des exchanges. Les moyens de contrôle côté chaîne ICON ne peuvent pas empêcher les exchanges de transférer ou de convertir les actifs qu'ils détiennent. La fondation ne peut compter que sur le gel des actifs par les exchanges, les notifications de préservation, les avocats et les forces de l'ordre.

La frontière de la garde détermine directement l'attribution des pertes. ICON indique que tous les actifs affectés appartiennent à la fondation, et que les dépôts, soldes et positions des utilisateurs ordinaires n'ont pas été touchés. Le rapport montre que 531 600 bnUSD et 1,366 million de SODA ont été intégralement récupérés ; sur les 113 634 USDC empruntés, 82 430 ont été recouvrés. La perte nette confirmée s'élève à environ 150,2 ETH, plus 31 204 USDC. La grande majorité des ICX concernés n'a fait l'objet que d'un gel ou d'un suivi par les exchanges, sans véritable récupération.

L'architecture de contrôle d'ICON diffère également des deux autres cas. Le rapport post-mortem indique que pendant la migration des jetons, le réseau était contrôlé par la fondation ; le guide de migration mentionne que le consensus fonctionnait en mode maintenance, avec seulement 7 nœuds principaux. Cet arrêt s'appuie donc sur une architecture opérationnelle spéciale clairement contrôlée par la fondation.

Le pouvoir d'urgence est aussi, par nature, un pouvoir au niveau du bilan

Chaque arrêt de blockchain revient, en substance, à transférer le risque vers un autre endroit.

• Cronos modifie l'historique officiel de la chaîne : cela peut protéger les actifs encore sous la juridiction de la chaîne, mais annule par contrecoup les activités on-chain normales sans rapport avec la vulnérabilité, et reste impuissant face aux actifs sur Ethereum.
• Ontology convertit le risque en coût temporel et en perte de disponibilité de service : pendant l'enquête, les transactions ne peuvent pas être réglées, et aucune perte comptable d'actifs n'est confirmée.
• ICON n'a achevé l'isolation du contrat et du réseau qu'après que les actifs sont sortis du périmètre de garde de la chaîne ; les pertes confirmées sont assumées par la fondation, et la récupération des ICX gelés dépend des exchanges et des autorités judiciaires.

Un simple score de décentralisation masquerait ces issues radicalement différentes. Un critère d'évaluation plus pragmatique est le suivant : les règles de traitement d'urgence sont-elles publiques ? Quel est le seuil de déclenchement de l'intervention ? S'agit-il seulement d'arrêter les nouveaux blocs, ou de réécrire l'état de chaîne déjà confirmé ? Au moment de l'intervention, qui contrôle les actifs sortis de la juridiction de la chaîne ? Qui s'engage à assumer les pertes restantes ?

Cronos et Tectonic doivent encore publier leurs rapports post-mortem complets. Ontology doit divulguer les détails de l'attaque et les règles d'autorisation d'urgence, puis confirmer si les conditions de mise à niveau et de redémarrage ont été remplies. Ce qui mérite réellement d'être comparé, c'est la frontière de risque tracée par chaque réseau — quels historiques, quels temps et quels fonds sont placés sous le risque.

Lien vers l'article original