Dans la soirée du 22 septembre, un utilisateur a envoyé un transfert d'ATOM.
Après une nuit, la transaction restait toujours « en attente de confirmation ».
La clé privée n'a pas été perdue, et le portefeuille ne montrait aucune anomalie de signature. En vérifiant à nouveau le lendemain, plusieurs RPC publics indiquaient tous que Cosmos Hub s'était arrêté à la hauteur de bloc 33 086 740.
Aucun nouveau bloc n'étant produit, il n'y avait naturellement nulle part où cette transaction pouvait être empaquetée.
Ce n'est qu'environ un jour plus tard, après que Cosmos Hub a repris la production de blocs, que ce transfert d'ATOM, qui était resté en attente tout du long, a finalement réussi.
Pour les utilisateurs ordinaires, c'est peut-être la leçon la plus intuitive pour comprendre le consensus blockchain.
Nous avons l'habitude de dire qu'« aucune institution centrale ne peut arrêter une chaîne publique », mais la réalité est clairement bien plus complexe. Une blockchain suffisamment décentralisée n'a en effet généralement pas ce « bouton d'arrêt » dans une salle de serveurs, mais elle peut quand même s'arrêter.
Cette pause de Cosmos Hub a justement pleinement exposé cet ensemble de mécanismes, habituellement cachés à la couche sous-jacente, aux utilisateurs ordinaires.
1. Pourquoi Cosmos a-t-il soudainement « arrêté de produire des blocs » ?
Tout d'abord, il est nécessaire de clarifier une question facile à confondre : ce qui a été directement attaqué cette fois n'était pas Cosmos Hub.
L'incident s'est d'abord produit sur Neutron.
Le 22 septembre, une proposition de gouvernance de Neutron intitulée « AIATO: AI Agent Takeover » a été adoptée. L'attaquant a exploité une faille dans les permissions de gouvernance au niveau de la chaîne et a utilisé des instructions privilégiées fournies nativement par le framework wasmd pour changer les administrateurs de contrats d'applications telles qu'Astroport et Drop en adresses contrôlées par l'attaquant.
Ce n'est pas ce que nous entendons habituellement par « vulnérabilité de code » ou « faille de protocole ».
On peut simplement le comprendre ainsi : les applications elles-mêmes ont leurs propres « serrures de porte », mais la gouvernance au niveau de la chaîne de Neutron détient également une « clé maîtresse » à privilèges plus élevés, et lorsque l'attaquant contrôle le résultat de la gouvernance, cela équivaut à obtenir cette clé, lui permettant de réattribuer les administrateurs, de migrer les contrats et de transférer davantage les actifs qu'ils contiennent.
Ce qui a réellement entraîné Cosmos Hub, c'est le transfert de fonds inter-chaînes qui a suivi.
L'analyse post-mortem de Cosmos Labs montre qu'avant que Neutron cesse de fonctionner, l'attaquant avait déjà déplacé certains actifs vers plusieurs réseaux, parmi lesquels environ 1,7 million d'ATOM ont été transférés dans Cosmos Hub et ont commencé à être échangés via la liquidité inter-chaînes.
En d'autres termes, Cosmos Hub lui-même n'a pas été directement attaqué, et les fonds des utilisateurs ordinaires du Hub n'ont pas été directement volés à cause de la vulnérabilité de Neutron.
Mais les ATOM obtenus lors de l'attaque étaient déjà entrés dans le Hub, et afin d'empêcher le reste des ATOM de continuer à s'écouler, certains validateurs de Cosmos Hub ont commencé à arrêter l'exécution de leurs nœuds.
Vers 19 h 18 le 22 septembre (SGT), les validateurs qui s'étaient arrêtés représentaient déjà plus d'un tiers de la puissance de vote totale, de sorte que Cosmos Hub ne pouvait plus continuer à former de nouveaux blocs et s'est finalement arrêté à 33 086 740.
Cette étape est très critique.
Cela signifie que Cosmos Hub n'a pas de bouton « Pause » qu'une entreprise pourrait cliquer directement, et qu'il n'y a pas non plus eu d'abord de vote de gouvernance on-chain. Ce qui a réellement arrêté le réseau, c'est que suffisamment de validateurs ont cessé de participer à la formation du consensus.
Mais ce qui est encore plus remarquable, c'est en fait le processus de récupération qui a suivi.
Environ 4 heures après l'arrêt de la chaîne, les validateurs ont reçu un plan de récupération complet : exécuter une modification d'état unique à la hauteur d'arrêt de la chaîne, transférant les ATOM restants dans l'adresse de l'attaquant vers une adresse multisig gérée conjointement par les validateurs de la communauté.
Cosmos Labs a ensuite produit le correctif Gaia v28.3.0 basé sur le plan déjà convenu par les validateurs, l'a testé et l'a distribué aux validateurs.
Cette version de Gaia exécuterait un changement d'état unique à la hauteur de récupération spécifiée, transférant 1 227 121 ATOM de l'adresse de l'attaquant vers une adresse multisig 4-sur-6 composée de six parties : Nansen, Keplr, Enigma, Silknodes, Kiln et Polkachu.
Au petit matin du 23 septembre, les validateurs confirmés avoir installé la v28.3.0 dépassaient déjà 67 % de la puissance de vote totale, donc à 12h00 UTC ce jour-là, Cosmos Hub a coordonné un redémarrage. Environ 6 minutes plus tard, cette modification d'état unique a été exécutée à la hauteur de bloc 33 086 741, et le réseau a repris la production normale de blocs.
En dernière analyse, tout au long du processus, depuis l'arrêt de la production de blocs par Cosmos jusqu'à la reprise du fonctionnement, les validateurs ont d'abord fait perdre la Liveness au réseau, puis plus de deux tiers de la puissance de vote ont accepté un nouvel ensemble de règles de transition d'état, faisant finalement de cet ensemble de règles l'état canonique après la récupération.
À ce stade, une question apparemment simple se pose : puisqu'il s'agit d'une chaîne publique décentralisée, pourquoi plus d'un tiers de la puissance de validation peut-il l'arrêter, alors que la restauration du réseau nécessite que suffisamment de validateurs acceptent et exécutent conjointement le même logiciel ?
La réponse est en fait cachée dans le mot « consensus ».
2. Le soi-disant consensus n'a jamais été « ne s'arrête jamais »
L'une des choses les plus facilement mal comprises à propos de la blockchain est d'assimiler « décentralisation » à « ne tombe jamais en panne ».
En fait, ce que le mécanisme de consensus résout vraiment est comment, sans registre central, de nombreux nœuds peuvent parvenir à un accord sur l'ordre des transactions et l'état du registre.
Cependant, différentes chaînes publiques ne mettent pas cela en œuvre de la même manière.
Par exemple, le mécanisme le plus classique de Bitcoin est le PoW, preuve de travail — les mineurs rivalisent pour produire des blocs en utilisant la puissance de calcul. Lorsque deux branches valides apparaissent brièvement sur le réseau, les nœuds choisissent l'une d'elles pour continuer à construire en fonction du travail cumulé.
Ainsi, Bitcoin n'a pas de moment clair où « après 67 % de vote, ce bloc est définitivement Finalisé ». Il est plus proche d'une sorte de finalité probabiliste : plus il y a de blocs suivants, plus le coût en puissance de calcul requis pour réorganiser et supprimer les transactions antérieures est élevé.
C'est aussi pourquoi on disait autrefois qu'il vaut mieux attendre 6 confirmations de bloc pour une transaction Bitcoin. Après tout, même avec une puissance de calcul supérieure, on ne peut pas simplement contourner les règles de consensus que les nœuds exécutent.
Bien sûr, cela ne signifie pas que l'état de Bitcoin est « absolument impossible à modifier » en toutes circonstances. Théoriquement, si l'ensemble de l'écosystème accepte un nouveau client et de nouvelles règles de consensus, via un Hard Fork, il est également possible de rendre valides des changements d'état qui étaient invalides selon les anciennes règles.
Mais voilà le problème : qui a la capacité de faire en sorte qu'assez de mineurs, de Full Nodes, de plateformes d'échange, de portefeuilles et d'utilisateurs acceptent conjointement un tel nouvel ensemble de règles ?
Presque personne.
L'équipe de développement ne peut pas décider seule des règles de consensus pour l'ensemble du réseau Bitcoin, et il est également difficile pour les mineurs et les plateformes d'échange, car le seuil de consensus à franchir est très élevé. Lorsque Binance a été piraté pour 7 000 BTC, certains ont suggéré que CZ contacte les grands mineurs pour agir, mais finalement rien n'en est sorti.
Ethereum fournit un autre exemple très classique.
Après être passé au PoS, Ethereum utilise maintenant le consensus Gasper composé de Casper FFG et LMD-GHOST ensemble. Pour simplifier, une partie du mécanisme est responsable de déterminer « quelle chaîne suivre actuellement », tandis que l'autre partie est responsable de donner aux blocs une véritable Finalité.
Ce n'est que lorsque les validateurs représentant au moins deux tiers de l'ETH mis en jeu s'accordent sur le point de contrôle correspondant qu'un bloc peut progresser davantage vers la finalisation ; inversement, si plus d'un tiers de l'enjeu ne participe pas correctement au vote pendant longtemps, le réseau peut temporairement être incapable de former une Finalité. Cependant, Ethereum a également conçu une fuite d'inactivité, qui réduit progressivement le poids effectif des validateurs hors ligne lorsque la finalisation ne peut pas être atteinte pendant longtemps, donnant au réseau une chance de restaurer éventuellement la Finalité.
Pour véritablement changer ce résultat, il est également nécessaire de modifier les règles du protocole et les clients.
Tout comme lors de l'incident The DAO de 2016, la communauté Ethereum a finalement procédé à un Hard Fork, exécutant au bloc 1 920 000 une modification spéciale de l'état que la Fondation Ethereum de l'époque a directement qualifiée de changement d'état irrégulier, transférant les ETH concernés vers un contrat de récupération.
Cependant, certains mineurs et membres de la communauté qui ont refusé de mettre à niveau et ont continué à maintenir l'état d'origine ont finalement formé Ethereum Classic (ETC), conduisant au célèbre fork ETH et ETC, montrant que tout le monde n'acceptait pas cet ensemble de règles.
Cosmos Hub est encore différent. Il utilise CometBFT, qui est plus proche d'un consensus BFT typique.
On peut le comprendre comme un consensus BFT plus typique, ce qui signifie que pour qu'un bloc soit véritablement validé, il doit obtenir un Commit de plus des deux tiers de la puissance de vote.
Son avantage est que la Finalité est très claire. Une fois qu'un bloc a été validé après le vote d'une puissance de vérification suffisante, il n'est pas nécessaire de continuer à attendre de plus en plus de blocs comme avec le PoW, en échangeant la probabilité contre un sentiment de sécurité.
Mais son autre face est aussi très directe : si un tiers ou plus de la puissance de vote ne fournit plus les votes nécessaires pour former un Commit, alors peu importe les efforts des validateurs restants, ils ne peuvent pas réunir plus des deux tiers.
À ce stade, le choix le plus sûr pour le réseau est exactement la « pause dans la production de blocs » observée cette fois, donc du point de vue des systèmes distribués, cette brève halte de Cosmos Hub n'est en fait pas mystérieuse.
En un mot, après qu'un groupe de validateurs détenant une puissance de vote suffisante cesse de participer, le protocole de consensus, selon ses propres règles, préfère perdre la disponibilité plutôt que de continuer à confirmer de nouveaux blocs sans consensus suffisant.
Derrière cela correspondent en fait deux concepts des systèmes distribués souvent confondus par les utilisateurs ordinaires :
- Sécurité : différents nœuds ne doivent pas confirmer simultanément deux états finaux contradictoires ;
- Vivacité : le réseau peut-il encore continuer à avancer et traiter de nouvelles transactions ;
Pour les systèmes BFT, lorsqu'il y a un nombre insuffisant de nœuds participant au consensus, la pause est parfois précisément le prix à payer pour maintenir la Sécurité. Pour le dire franchement, ce registre décentralisé préfère s'arrêter d'abord plutôt que de laisser les personnes restantes tenir chacune leurs propres registres.
En regardant en arrière sous cet angle, on constatera que de nombreux incidents apparemment complètement différents dans l'histoire des blockchains publiques tournent en fait autour de la même chose :
Lorsque les nœuds distribués ne peuvent plus former un consensus sur le « bon état », que doit faire le réseau ?
III. De Bitcoin à Solana, où se situe la véritable frontière du risque des blockchains publiques ?
Ce n'est pas la première fois que Cosmos met cette question sur la table.
Dès 2013, Bitcoin a connu un incident de fork de chaîne très classique.
À l'époque, Bitcoin 0.8 a changé sa base de données sous-jacente de Berkeley DB à LevelDB. Par la suite, un bloc contenant un grand nombre d'entrées de transaction est apparu. Les nœuds de la nouvelle version pouvaient le traiter normalement, mais certains nœuds de l'ancienne version, en raison de la limite du nombre de verrous de Berkeley DB, ont jugé ce bloc invalide.
Ainsi est apparue une scène très embarrassante : tout le monde exécutait Bitcoin, mais les anciens et nouveaux clients ont commencé à donner des réponses différentes à « ce bloc est-il légal ou non ».
Le réseau s'est donc scindé en deux chaînes, et le côté de la nouvelle version 0.8 a même eu environ 60 % du taux de hachage, et ne pouvait pas compter sur la concurrence normale du taux de hachage pour converger rapidement de lui-même.
Finalement, les grands pools de minage se sont coordonnés pour revenir à l'ancienne version, ont regagné plus de taux de hachage du côté des anciennes règles, et ce n'est qu'alors que le réseau a de nouveau convergé. Bitcoin a ensuite spécifiquement examiné cet incident avec le BIP 50.
En 2016, l'incident The DAO d'Ethereum a poussé le problème un cran plus loin.
Comme mentionné ci-dessus à propos de l'incident de The DAO, la communauté Ethereum a finalement procédé à un Hard Fork, exécutant au bloc 1 920 000 une modification spéciale de l'état explicitement appelée changement d'état irrégulier par la Fondation Ethereum, transférant les ETH concernés vers un contrat de récupération.
Mais tout le monde n'était pas d'accord avec cette gestion. Certains mineurs et membres de la communauté qui refusaient d'accepter la modification de l'état ont continué à maintenir les règles originales, ce qui a conduit à l'existence durable d'Ethereum Classic (ETC).
Ce DAO Fork a également été un événement classique, équivalant à dire à tout le monde que lorsque des événements extrêmes se produisent, outre le consensus du code, il existe aussi un consensus social. Si des opinions suffisamment cohérentes ne peuvent pas être formées, une chaîne peut réellement se scinder en deux.
Solana en 2021 a démontré une autre voie de défaillance complètement différente.
En septembre de cette année-là, un grand nombre de transactions de bots ont inondé le réseau, provoquant l'épuisement de la mémoire des nœuds validateurs et le plantage de nombreux nœuds. Finalement, l'ensemble du réseau n'a pas pu former de consensus sur l'état actuel et a cessé de confirmer de nouveaux blocs pendant environ 17 heures, après quoi les validateurs se sont coordonnés conjointement pour restaurer le réseau.
En rassemblant ces incidents, on constatera qu'il ne s'agit pas de la même chose :
- Le problème de Bitcoin en 2013 était que différents clients commençaient à appliquer des règles de validité différentes ;
- Le problème de Solana en 2021 était qu'un grand nombre de nœuds validateurs ne pouvaient plus continuer à participer normalement au consensus, et le réseau a perdu la Liveness ;
- Ce à quoi Ethereum DAO était confronté se rapprochait davantage de la question de savoir si une communauté devait activement modifier l'état au moyen de nouvelles règles de protocole ;
- Et cette fois, Cosmos Hub présente une couche de particularité supplémentaire : le réseau a d'abord activement perdu la Liveness par la coordination des validateurs afin d'empêcher les actifs attaqués de continuer à se déplacer ; par la suite, une proportion suffisamment élevée de puissance de vote a conjointement accepté le nouveau logiciel et l'état de récupération, permettant au réseau de former à nouveau un consensus ;
Ainsi, plutôt que de simplement réduire ces événements à « donc les blockchains peuvent réellement s'arrêter » ou « la décentralisation est entièrement fausse », il vaut mieux admettre un fait plus réel :
Le mécanisme de consensus n'a jamais été une machine qui ne peut pas se briser. Ce qu'il fournit réellement est en fait un ensemble de règles décentralisées, telles que qui décide de la chaîne correcte lorsque des désaccords surviennent ; combien de participants sont nécessaires pour qu'un état obtienne la finalité ; si le réseau choisit de continuer à fonctionner ou de s'arrêter lorsque des défaillances se produisent ; et, dans des circonstances extrêmes, quel type d'action collective peut modifier les règles de fonctionnement à l'avenir.
Cela laisse également à cet incident Cosmos une question qui vaut plus la peine d'être méditée pour les utilisateurs ordinaires que « si la chaîne doit être arrêtée ».
Réflexions finales
Nous disons souvent : pas vos clés, pas vos pièces.
Cette affirmation reste bien sûr vraie, sauf qu'elle met l'accent sur le contrôle des actifs — tant que la clé privée est entre vos propres mains, les portefeuilles, les plateformes de trading ou d'autres tiers ne peuvent pas signer un transfert en votre nom.
La condition préalable est que la blockchain sur laquelle vous vous trouvez doit être capable de traiter cette signature à tout moment.
Le jour où Cosmos Hub a cessé de produire des blocs, les utilisateurs détenaient toujours leurs propres clés privées, et les actifs n'ont pas disparu dans les airs pour autant, sauf que même si vous signiez correctement une transaction, il n'y avait aucun nouveau bloc pour l'accepter.
Le processus de récupération illustre en outre que si suffisamment de participants au consensus acceptent un nouvel ensemble de règles d'état, l'état on-chain de comptes spécifiques peut également changer sans être signé par la clé privée de l'adresse d'origine.
Cela n'invalide pas « Pas vos clés, pas vos pièces », mais cela nous rappelle que la souveraineté de la clé privée et le pouvoir de consensus sous-jacent n'ont jamais été la même chose.
Et pour les portefeuilles, il en va de même.
Les portefeuilles peuvent garantir que les clés privées et les droits de signature sont entre les mains des utilisateurs, peuvent identifier les anomalies au niveau de la chaîne aussi rapidement que possible, afficher avec précision l'état des transactions, établir une redondance RPC et des nœuds, et reconfirmer le résultat final des transactions après le rétablissement du réseau.
Mais les portefeuilles ne peuvent pas restaurer le consensus pour une chaîne publique, ni garantir que le réseau sous-jacent ne sera jamais interrompu, et encore moins garantir que les règles et l'état sur la chaîne ne subiront jamais de changements au niveau du consensus.
Ainsi, ce qu'un système décentralisé mature doit véritablement rechercher n'a peut-être jamais été « rien ne peut jamais être changé » ; au contraire, il devrait clarifier autant que possible ces frontières imparfaites : Qui peut suspendre le consensus ? Quel poids est nécessaire ? Dans quelles circonstances une intervention d'urgence est-elle autorisée ?
Parce que la véritable décentralisation ne peut pas faire en sorte que le système ne rencontre jamais d'accidents ; l'essentiel est que même si un accident se produit réellement, nous puissions encore savoir qui, sur la base de quelles règles et avec quel niveau de consensus, a décidé comment ce registre devrait être enregistré ensuite.
