Dans la soirée du 22 septembre, un utilisateur a envoyé un virement ATOM.
Une nuit s'est écoulée et la transaction était toujours « en attente de confirmation ».
La clé privée n’a pas été perdue et il n’y a eu aucune exception de signature dans le portefeuille. En vérifiant à nouveau le lendemain, plusieurs RPC publics ont montré que le Cosmos Hub s'était arrêté à la hauteur de bloc 33 086 740.
Si aucun nouveau bloc n’est généré, il n’y aura naturellement aucun endroit pour empaqueter cette transaction.
Ce n’est que lorsque Cosmos Hub a repris la production en bloc environ un jour plus tard que le transfert ATOM qui attendait a finalement réussi.
Pour les utilisateurs ordinaires, cela peut être la leçon la plus intuitive pour comprendre le consensus de la blockchain.
On a l'habitude de dire qu'"aucune organisation centrale ne peut fermer une chaîne publique", mais la réalité est évidemment bien plus compliquée. Une blockchain suffisamment décentralisée n'a généralement pas de « bouton d'arrêt » dans la salle des serveurs, mais elle peut quand même s'arrêter.
La suspension de Cosmos Hub cette fois a complètement exposé ce mécanisme qui est généralement caché en bas aux utilisateurs ordinaires.
1. Pourquoi Cosmos a-t-il soudainement « arrêté de produire des blocs » ?
Tout d’abord, nous devons clarifier une question qui prête facilement à confusion. Ce n’est pas le Cosmos Hub qui a été directement attaqué cette fois.
L'incident s'est produit pour la première fois à Neutron.
Le 22 septembre, une proposition de gouvernance Neutron intitulée « AIATO : AI Agent Takeover » a été adoptée. L'attaquant a profité des failles des autorisations de gouvernance au niveau de la chaîne et a utilisé les instructions privilégiées fournies nativement par le framework wasmd pour remplacer les administrateurs de contrat d'applications telles que Astroport et Drop par des adresses contrôlées par l'attaquant.
Il ne s’agit pas du genre de « vulnérabilité du code » ou de « faille de protocole » que nous comprenons habituellement.
On peut simplement comprendre que l'application elle-même possède son propre « verrou de porte », mais la gouvernance au niveau de la chaîne de Neutron détient également un « passe-partout » doté d'une autorité supérieure. Lorsque l'attaquant contrôle les résultats de la gouvernance, cela équivaut à obtenir cette clé et peut redésigner l'administrateur, migrer le contrat et transférer davantage les actifs.
Ce qui a vraiment impliqué Cosmos Hub, c'est le transfert de fonds inter-chaînes qui a suivi.
L'examen de Cosmos Labs montre qu'avant l'arrêt de Neutron, l'attaquant avait transféré certains actifs vers plusieurs réseaux. Environ 1,7 million d'ATOM ont été transférés vers Cosmos Hub et ont commencé à être échangés via des liquidités inter-chaînes.
En d’autres termes, le 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 en raison de la vulnérabilité Neutron.
Cependant, l'ATOM obtenu lors de l'attaque est déjà entré dans le Hub. Afin d'empêcher l'ATOM restant de s'écouler, certains validateurs Cosmos Hub ont commencé à arrêter le fonctionnement du nœud.
Vers 19 h 18 le 22 septembre (SGT), les validateurs arrêtés représentaient plus d'un tiers du pouvoir de vote total, et Cosmos Hub n'a donc pas pu continuer à former de nouveaux blocs, s'arrêtant finalement à 33 086 740.
Cette étape est très critique.
Cela signifie qu'il n'y a pas de bouton « Pause » sur lequel une entreprise peut cliquer directement sur le Cosmos Hub, et qu'elle ne passe pas non plus par un vote de gouvernance en chaîne au préalable. Ce qui arrête réellement le réseau, c’est lorsqu’un nombre suffisant de validateurs ne participent plus à la formation d’un consensus.
Mais ce qui est plus remarquable, c’est le processus de récupération qui s’ensuit.
Environ 4 heures après la suspension de la chaîne, le vérificateur a reçu un plan de récupération complet : effectuer une modification unique du statut pour la hauteur de suspension de la chaîne et transférer l'ATOM restant dans l'adresse de l'attaquant vers une adresse multi-signature gérée conjointement par les validateurs de la communauté.
Cosmos Labs a ensuite produit le correctif Gaia v28.3.0 basé sur la solution atteinte par les vérificateurs, l'a testé et l'a distribué aux vérificateurs.
Cette version de Gaia effectuera un changement d'état unique à la hauteur de récupération spécifiée, transférant 1 227 121 ATOM dans l'adresse de l'attaquant vers une adresse multi-signature 4 sur 6 composée de Nansen, Keplr, Enigma, Silknodes, Kiln et Polkachu.
Au petit matin du 23 septembre, le nombre de validateurs ayant confirmé avoir installé la v28.3.0 dépassait 67 % du total des droits de vote. Par conséquent, à 12h00 UTC ce jour-là, le Cosmos Hub a coordonné un redémarrage. Environ 6 minutes plus tard, cette modification unique de l'état a été exécutée à la hauteur de bloc 33 086 741, et le réseau est revenu à une production normale de blocs.
En fin de compte, tout au long du processus, depuis le moment où Cosmos a arrêté de produire des blocs jusqu'à sa reprise de ses activités, ce sont les validateurs qui ont d'abord fait perdre au réseau sa vivacité, puis plus des deux tiers des droits 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 restauré.
À 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 des droits de vérification peuvent-ils l’arrêter, et pour restaurer le réseau, suffisamment de validateurs doivent accepter et exécuter le même ensemble de logiciels ?
La réponse réside en fait dans le mot « consensus ».
2. Le soi-disant consensus ne « s’arrête jamais ».
L’une des choses les plus mal comprises à propos de la blockchain est que la « décentralisation » est assimilée à « ne jamais s’arrêter ».
En fait, le problème que le mécanisme de consensus résout réellement est de savoir combien de nœuds peuvent parvenir à un accord sur la séquence des transactions et le statut du grand livre en l’absence d’un comptable central.
Cependant, différentes chaînes publiques mettent en œuvre cela de différentes manières.
L'exemple le plus classique de Bitcoin est le PoW, qui est une preuve de travail : les mineurs se font concurrence pour produire des blocs basés sur la puissance de calcul. Lorsque deux branches légales apparaissent dans le réseau dans un court laps de temps, le nœud choisit l'une d'elles pour continuer à se construire en fonction de la charge de travail accumulée.
Par conséquent, Bitcoin n’a pas de moment clair « ce bloc sera finalisé pour toujours après un vote de 67 % ». On se rapproche davantage d’une finalité probabiliste. Plus il y a de blocs ultérieurs, plus le coût en puissance de calcul sera de plus en plus élevé pour réorganiser les transactions précédentes.
C’est pourquoi tout le monde disait qu’il est préférable pour une transaction Bitcoin d’attendre 6 blocs pour être confirmée. Après tout, quelle que soit la puissance de calcul, elle ne peut pas simplement contourner les règles de consensus exécutées par les nœuds.
Bien entendu, cela ne signifie pas que l’état du Bitcoin soit « absolument inaltérable » en aucune circonstance. Théoriquement, si l'ensemble de l'écosystème accepte un nouvel ensemble de clients et de nouvelles règles consensuelles, via Hard Fork, les changements de statut qui étaient invalides selon les règles précédentes peuvent également être rendus valides.
Mais voici la question : qui a la capacité d’amener suffisamment de mineurs, de nœuds complets, de plateformes de trading, de portefeuilles et d’utilisateurs à accepter un tel nouvel ensemble de règles ?
À peine.
L’équipe de développement ne peut pas décider des règles de consensus pour l’ensemble du réseau Bitcoin. C’est également difficile pour les mineurs et les plateformes de trading car le seuil de consensus à franchir est très élevé. Lorsque 7 000 BTC ont été volés à Binance, certaines personnes ont suggéré que CZ contacte de grands mineurs pour opérer, mais rien ne s'est finalement produit.
Ethereum fournit un autre exemple classique.
Après être passé au PoS, Ethereum utilise désormais le consensus Gasper composé de Casper FFG et LMD-GHOST. Pour comprendre simplement, une partie du mécanisme est chargée de déterminer « quelle chaîne doit être suivie actuellement », tandis que l'autre partie est chargée de faire en sorte que le bloc atteigne sa finalité au sens propre du terme.
Lorsque les validateurs représentant au moins les deux tiers des ETH mis en jeu parviennent à un accord sur le point de contrôle correspondant, le bloc peut avancer vers la finalisation ; à l'inverse, si plus d'un tiers des enjeux ne participent pas à un vote correct pendant une longue période, le réseau peut être temporairement incapable de devenir définitif. Cependant, Ethereum a également conçu une fuite d'inactivité pour réduire progressivement le poids effectif des validateurs hors ligne lorsque la finalisation ne peut pas être finalisée pendant une longue période, donnant ainsi au réseau une chance de restaurer enfin la finalité.
Pour vraiment changer ce résultat, vous devez également modifier les règles du protocole et le client.
Tout comme l'incident DAO en 2016, la communauté Ethereum a finalement mis en œuvre une modification d'état spéciale appelée changement d'état irrégulier par la Fondation Ethereum au bloc 1 920 000 via Hard Fork, et a transféré l'ETH correspondant au contrat de récupération.
Cependant, certains mineurs et communautés qui ont refusé de se mettre à niveau et ont continué à maintenir l'état d'origine ont finalement formé Ethereum Classic (ETC), conduisant au fork bien connu d'ETH et d'ETC, indiquant que tout le monde n'accepte pas cet ensemble de règles.
Cosmos Hub est encore différent. Il utilise CometBFT, qui est plus proche d'un consensus BFT typique.
Cela peut être compris comme un consensus BFT plus typique, c'est-à-dire que pour qu'un bloc soit véritablement soumis, il doit obtenir un engagement de plus des deux tiers des droits de vote.
Son avantage est que la Finalité est très claire. Une fois qu'un bloc est soumis par vote avec des droits de vérification suffisants, il n'est pas nécessaire de continuer à attendre de plus en plus de blocs comme PoW, échangeant la probabilité contre un sentiment de sécurité.
Mais l’autre aspect est également très simple : si un tiers ou plus des droits de vote ne fournissent plus les voix requises pour former un commit, les validateurs restants ne pourront pas obtenir plus des deux tiers, quel que soit leur travail.
Le choix le plus sûr pour le réseau à l'heure actuelle est de « suspendre la production de blocs » cette fois-ci, donc du point de vue d'un système distribué, cette brève suspension de Cosmos Hub n'est en fait pas mystérieuse.
En un mot, après qu'un groupe de validateurs disposant d'un pouvoir de vote suffisant cesse de participer, le protocole de consensus, selon ses propres règles, préférerait perdre sa disponibilité plutôt que de continuer à confirmer de nouveaux blocs sans consensus suffisant.
Derrière cela correspondent en réalité deux concepts dans les systèmes distribués qui sont souvent confondus par les utilisateurs lambda :
Sécurité : différents nœuds ne peuvent pas confirmer deux états finaux contradictoires en même temps ;
Vivacité : le réseau peut-il continuer à avancer et à traiter de nouvelles transactions ?
Pour le système BFT, lorsqu'il n'y a pas suffisamment de nœuds participant au consensus, la suspension est parfois le prix à payer pour maintenir la sécurité. Pour parler franchement, ce grand livre décentralisé préfère s’arrêter là plutôt que de laisser les personnes restantes tenir leurs propres comptes.
En regardant en arrière sous cet angle, vous constaterez que de nombreux accidents apparemment complètement différents dans l’histoire des chaînes publiques tournent en réalité autour de la même chose :
Que fait le réseau lorsque les nœuds distribués ne parviennent plus à s'entendre sur le « bon état » ?
3. De Bitcoin à Solana, où se situe la véritable limite de risque des chaînes publiques ?
Ce n’est pas la première fois que Cosmos soulève cette question.
Dès 2013, Bitcoin a connu un accident de fourche de chaîne très classique.
À cette époque, Bitcoin 0.8 a fait passer la base de données sous-jacente de Berkeley DB à LevelDB, puis un bloc contenant un grand nombre d'entrées de transaction est apparu. La nouvelle version du nœud pouvait le traiter normalement, mais certains nœuds de l'ancienne version ont jugé le bloc comme invalide en raison de la limite du nombre de verrous Berkeley DB.
Une scène très embarrassante est alors apparue. Tout le monde utilisait Bitcoin, mais les anciens et les nouveaux clients ont commencé à avoir des réponses différentes quant à « si ce blocage est légal ».
En conséquence, le réseau s'est divisé en deux chaînes, et la nouvelle version 0.8 disposait autrefois d'environ 60 % de la puissance de calcul et ne pouvait pas compter sur la concurrence normale en matière de puissance de calcul pour converger rapidement par elle-même.
Au final, de grands pools miniers se sont coordonnés pour revenir à l'ancienne version, récupérant ainsi plus de puissance de calcul du côté des anciennes règles, et le réseau a de nouveau convergé. Bitcoin a ensuite examiné spécifiquement l'accident avec le BIP 50.
En 2016, l’incident du DAO sur Ethereum a poussé le problème encore plus loin.
Comme mentionné ci-dessus dans l'incident DAO, la communauté Ethereum a finalement mis en œuvre une modification d'état spéciale appelée explicitement un changement d'état irrégulier par la Fondation Ethereum via Hard Fork au bloc 1 920 000, transférant l'ETH concerné au contrat de récupération.
Mais tout le monde n’était pas d’accord avec cette décision. Certains mineurs et communautés qui ont refusé d’accepter la modification du statut ont continué à maintenir les règles d’origine, et l’Ethereum Classic (ETC) de longue date a ensuite vu le jour.
Ce DAO Fork est aussi un événement classique, ce qui équivaut à dire à tout le monde que lorsque des événements extrêmes se produisent, il existe également un consensus social en plus du consensus de code. Si une opinion suffisamment cohérente ne peut être formée, une chaîne peut réellement être divisée en deux.
La Solana 2021 montre une voie d’échec complètement différente.
En septembre de la même année, un grand nombre de transactions de robots ont afflué sur le réseau, provoquant l'épuisement de la mémoire du nœud de vérification et le crash d'un grand nombre de nœuds. En fin de compte, l’ensemble du réseau n’a pas pu parvenir à un consensus sur l’état actuel et a cessé de confirmer de nouveaux blocages pendant environ 17 heures. Ensuite, les validateurs ont travaillé ensemble pour restaurer le réseau.
En mettant ces accidents ensemble, vous constaterez qu’il ne s’agit pas de la même chose :
Le problème avec Bitcoin en 2013 est que différents clients commencent à mettre en œuvre des règles de validité différentes ;
Le problème de Solana en 2021 est qu'un grand nombre de nœuds de vérification ne peuvent pas continuer à participer normalement au consensus et que le réseau perd de sa vivacité ;
Ce à quoi Ethereum DAO est confronté est plus proche de la question de savoir si une communauté devrait activement modifier le statut via de nouvelles règles de protocole ;
Cette fois, Cosmos Hub a une autre couche de particularité. Le réseau perd d'abord activement sa vivacité grâce à la coordination des validateurs pour empêcher les actifs d'attaque de continuer à se déplacer ; ensuite, une proportion suffisamment élevée de droits de vérification accepte conjointement de nouveaux logiciels et restaure l'état, rendant ainsi le réseau à nouveau cohérent ;
Par conséquent, au lieu de simplement attribuer ces incidents au « les blockchains peuvent s’arrêter » et au « la décentralisation est fausse », il est préférable d’admettre un fait plus réel :
Le mécanisme de consensus n’est jamais une machine indestructible. Ce qu'il fournit en réalité, c'est un ensemble de règles décentralisées, par exemple : qui décidera de la bonne chaîne en cas de désaccord ; combien de participants peuvent faire un état final ; lorsqu'une panne survient, le réseau choisit de continuer à fonctionner ou de s'arrêter ; et dans les cas extrêmes, quel type d'action collective peut changer les prochaines règles de fonctionnement.
Cela fait également que cet incident de Cosmos soulève une question qui mérite plus d'être prise en considération par les utilisateurs ordinaires que « la chaîne devrait-elle être arrêtée ?
écris à la fin
On dit souvent : pas vos clés, pas vos pièces.
Bien sûr, cette phrase est toujours vraie, mais elle met l'accent sur le contrôle des actifs : tant que la clé privée est entre vos mains, les portefeuilles, les plateformes de trading ou d'autres tiers ne peuvent normalement pas signer un transfert à votre place.
Le principe est que la blockchain sur laquelle vous vous trouvez doit pouvoir traiter cette signature à tout moment.
Le jour où Cosmos Hub cesse de produire des blocs, les utilisateurs détiennent toujours leurs clés privées et les actifs ne disparaissent pas de nulle part. Cependant, même si vous signez correctement une transaction, il n’y a pas de nouveau bloc pour l’accepter.
Le processus de récupération explique en outre que si suffisamment de participants consensuels acceptent un nouvel ensemble de règles de statut, le statut en chaîne d'un compte spécifique peut également changer sans la signature de 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 l’autonomie des clés privées et les droits consensuels sous-jacents ne sont jamais la même chose.
Il en va de même pour les portefeuilles.
Le portefeuille peut garantir que la clé privée et les droits de signature sont entre les mains de l'utilisateur, identifier les anomalies au niveau de la chaîne le plus rapidement possible, afficher avec précision l'état de la transaction, établir la redondance du RPC et des nœuds et reconfirmer le résultat final de la transaction après la restauration du réseau.
Cependant, le portefeuille ne peut pas restaurer le consensus pour une chaîne publique, ni garantir que le réseau sous-jacent ne sera jamais interrompu, ni garantir que les règles et le statut de la chaîne ne changeront jamais au niveau du consensus.
Par conséquent, ce qu’un système décentralisé mature doit réellement poursuivre n’est peut-être jamais « rien ne peut être changé » ; au contraire, ces limites imparfaites doivent être rendues aussi claires que possible : qui peut suspendre le consensus ? Quel poids faut-il ? Dans quelles circonstances une intervention d’urgence est-elle autorisée ?
Grâce à une véritable décentralisation, il est impossible que le système ne rencontre jamais d'accidents. L’essentiel est que même si un accident se produit, nous pouvons toujours savoir qui, selon quelles règles et avec quel niveau de consensus, détermine comment ce récit doit ensuite être enregistré.