Pourquoi une blockchain publique peut-elle s'arrêter ? Comprendre véritablement le consensus blockchain à partir de l'arrêt de Cosmos pendant 25 heures

Auteur : imToken

Le 22 septembre au soir, un utilisateur a effectué un transfert d'ATOM.

Une nuit plus tard, la transaction était toujours en "attente de confirmation".

La clé privée n'a pas été perdue, et le portefeuille n'a pas montré d'anomalie de signature. Le lendemain, après une nouvelle vérification, plusieurs RPC publics ont montré que Cosmos Hub était bloqué à la hauteur de bloc 33,086,740.

Aucun nouveau bloc n'a été produit, il n'y avait donc aucun endroit pour empaqueter cette transaction.

Ce n'est qu'environ un jour plus tard que Cosmos Hub a recommencé à produire des blocs, et ce transfert d'ATOM, qui était resté en attente, a finalement réussi.

Pour les utilisateurs ordinaires, cela pourrait ê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 blockchain publique", mais la réalité est manifestement beaucoup plus complexe. Une blockchain suffisamment décentralisée n'a effectivement pas de "bouton d'arrêt" dans une salle de serveurs, mais elle peut néanmoins s'arrêter.

Cette fois-ci, la pause de Cosmos Hub a justement exposé ce mécanisme, habituellement caché en arrière-plan, aux utilisateurs ordinaires.

I. Pourquoi Cosmos s'est-il soudainement "arrêté de produire des blocs" ?

Tout d'abord, il est nécessaire de clarifier une question qui peut prêter à confusion : ce n'est pas Cosmos Hub qui a été directement attaqué.

L'événement a d'abord eu lieu sur Neutron.

Le 22 septembre, une proposition de gouvernance de Neutron intitulée "AIATO : Prise de contrôle par un agent AI" a été approuvée. L'attaquant a exploité une faille dans les droits de gouvernance au niveau de la chaîne, utilisant des instructions privilégiées fournies par le cadre wasmd pour changer les administrateurs des contrats d'applications comme Astroport et Drop en une adresse contrôlée par l'attaquant.

Ce n'est pas ce que nous comprenons habituellement comme une "vulnérabilité de code" ou un "défaut de protocole".

On peut le comprendre simplement comme suit : l'application elle-même a sa propre "serrure", mais la gouvernance au niveau de la chaîne de Neutron détient une "clé maîtresse" avec des droits plus élevés, et lorsque l'attaquant contrôle le résultat de la gouvernance, il obtient cette clé, ce qui lui permet de redésigner des administrateurs, de migrer des contrats et de transférer davantage d'actifs.

Ce qui a réellement impliqué Cosmos Hub, c'est le transfert de fonds inter-chaînes qui a suivi.

Une rétrospective de Cosmos Labs montre qu'avant que Neutron ne cesse de fonctionner, l'attaquant avait transféré une partie des actifs vers plusieurs réseaux, dont environ 1,7 million d'ATOM ont été transférés vers 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 subi d'attaque directe, et les fonds des utilisateurs ordinaires de Hub n'ont pas été volés directement à cause de la vulnérabilité de Neutron.

Mais les ATOM obtenus par l'attaquant étaient déjà entrés dans le Hub, et pour empêcher le reste des ATOM de continuer à sortir, certains validateurs de Cosmos Hub ont commencé à arrêter le fonctionnement de leurs nœuds.

Vers 19h18 (SGT) le 22 septembre, les validateurs arrêtés représentaient plus d'un tiers du pouvoir de vote total, ce qui a empêché Cosmos Hub de continuer à former de nouveaux blocs, s'arrêtant finalement à 33,086,740.

Cette étape est très cruciale.

Elle signifie que Cosmos Hub n'a pas de "bouton Pause" que pourrait cliquer directement une entreprise, et il n'y a pas eu de vote de gouvernance en chaîne préalable. Ce qui a réellement arrêté le réseau, c'est qu'un nombre suffisant de validateurs a cessé de participer à la formation du consensus.

Mais ce qui mérite d'être noté, 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, transférant les ATOM restants de l'adresse de l'attaquant vers une adresse multi-signature gérée collectivement par des validateurs de la communauté.

Ensuite, Cosmos Labs a créé un patch 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écutera une modification 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 multi-signature 4-of-6 composée de Nansen, Keplr, Enigma, Silknodes, Kiln et Polkachu.

Dans la nuit du 23 septembre, le nombre de validateurs ayant confirmé l'installation de v28.3.0 a dépassé 67 % du pouvoir de vote total, et donc le 23 septembre à 12h00 UTC, 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 une production normale de blocs.

En fin de compte, le processus entier de l'arrêt de Cosmos à la reprise de son fonctionnement a été que les validateurs ont d'abord fait perdre au réseau sa vivacité, puis plus de deux tiers du pouvoir de vote ont accepté un nouvel ensemble de règles de transformation d'état, permettant à cet ensemble de règles de devenir l'état canonique après la récupération.

À ce stade, une question apparemment simple se pose : puisqu'il s'agit d'une blockchain publique décentralisée, pourquoi plus d'un tiers du pouvoir de validation peut-il l'arrêter, tandis que la récupération du réseau nécessite suffisamment de validateurs acceptant et exécutant le même logiciel ?

La réponse se cache en fait dans le mot "consensus".

II. Ce que l'on appelle le consensus n'est pas "jamais à l'arrêt"

Une des choses les plus facilement mal comprises à propos de la blockchain est de mettre "décentralisé" et "jamais hors service" sur un pied d'égalité.

En réalité, le mécanisme de consensus résout vraiment le problème de comment de nombreux nœuds peuvent parvenir à un accord sur l'ordre des transactions et l'état du livre comptable sans un comptable central.

Cependant, les différentes blockchains réalisent cela de différentes manières.

Comme Bitcoin, le plus classique est le PoW, c'est-à-dire la preuve de travail - les mineurs comptent sur la puissance de calcul pour rivaliser pour produire des blocs. Lorsque le réseau présente temporairement deux branches légitimes, les nœuds choisissent celle qui a le plus de travail accumulé pour continuer à construire.

Ainsi, Bitcoin n'a pas de moment clairement défini où "67 % des votes finalisent ce bloc pour toujours". Il est plus proche d'une finalité probabiliste, plus il y a de blocs suivants, plus il faut dépenser de puissance de calcul pour réorganiser les transactions précédentes.

C'est aussi pourquoi les gens disaient autrefois qu'une transaction Bitcoin devait attendre 6 confirmations de blocs, car même si la puissance de calcul est élevée, elle ne peut pas simplement contourner les règles de consensus que les nœuds appliquent.

Bien sûr, cela ne signifie pas que l'état de Bitcoin est "absolument immuable" dans toutes les circonstances. En théorie, si l'ensemble de l'écosystème accepte un nouveau client et de nouvelles règles de consensus, un Hard Fork peut également rendre des changements d'état invalides sous les anciennes règles valides.

Mais le problème réside ici : qui a la capacité de faire accepter à suffisamment de mineurs, de nœuds complets, de plateformes d'échange, de portefeuilles et d'utilisateurs un tel nouvel ensemble de règles ?

Pratiquement personne.

L'équipe de développement ne peut pas décider des règles de consensus pour l'ensemble du réseau Bitcoin, et les mineurs et les plateformes d'échange ont également du mal, car le seuil de consensus à franchir est très élevé. Lorsque Binance a été piraté pour 7000 BTC, quelqu'un a suggéré à CZ de contacter de grands mineurs pour agir, mais cela n'a finalement pas abouti.

Ethereum, quant à lui, fournit un autre exemple classique.

Après être passé au PoS, Ethereum utilise maintenant le consensus Gasper, composé de Casper FFG et LMD-GHOST. En termes simples, une partie du mécanisme est responsable de déterminer "quelle chaîne devrait être suivie actuellement", tandis qu'une autre partie est responsable de faire en sorte que le bloc obtienne une véritable finalité.

Lorsque les validateurs représentant au moins deux tiers de l'ETH staké parviennent à un accord sur le point de contrôle correspondant, le bloc peut aller vers la détermination finale ; en revanche, si plus d'un tiers du stake ne participe pas au vote correct pendant une longue période, le réseau peut temporairement ne pas parvenir à 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 finalité ne peut pas être atteinte pendant une longue période, permettant au réseau de retrouver finalement la finalité.

Pour vraiment changer ce résultat, il faut également changer les règles du protocole et le client.

Comme en 2016 avec l'incident The DAO, la communauté Ethereum a finalement procédé à un Hard Fork, exécutant un changement d'état spécial que la fondation Ethereum a alors directement qualifié de changement d'état irrégulier au bloc 1,920,000, transférant l'ETH concerné vers un contrat de récupération.

Cependant, une partie des mineurs et de la communauté qui a refusé la mise à niveau et a continué à maintenir l'état d'origine a finalement formé Ethereum Classic (ETC), entraînant la scission bien connue entre ETH et ETC, montrant que tout le monde n'acceptait pas cet ensemble de règles.

Cosmos Hub, en revanche, utilise CometBFT, qui est plus proche d'un consensus BFT typique.

On peut le comprendre comme un consensus BFT plus typique, c'est-à-dire qu'un bloc doit obtenir plus des deux tiers du pouvoir de vote pour être réellement soumis.

Son avantage est que la finalité est très claire : une fois qu'un bloc a été soumis par un vote suffisant, il n'est pas nécessaire d'attendre encore plus de blocs comme avec le PoW pour échanger la sécurité contre la probabilité.

Mais son autre face est très directe : si un tiers ou plus du pouvoir de vote ne fournit plus les votes nécessaires à la formation du Commit, même les validateurs restants ne peuvent pas atteindre les deux tiers.

À ce moment-là, le choix le plus sûr pour le réseau est, comme lors de cette "pause de production de blocs", donc d'un point de vue de système distribué, cette courte interruption de Cosmos Hub n'est en fait pas mystérieuse.

En résumé, un groupe de validateurs détenant suffisamment de pouvoir de vote qui cesse de participer entraîne que le protocole de consensus, selon ses propres règles, préfère perdre la disponibilité plutôt que de continuer à confirmer de nouveaux blocs en l'absence d'un consensus suffisant.

Cela correspond en fait à deux concepts souvent confondus par les utilisateurs ordinaires dans les systèmes distribués :

• Sécurité : ne pas permettre à différents nœuds de confirmer simultanément deux états finaux conflictuels ;
• Vivacité : le réseau peut-il continuer à fonctionner et traiter de nouvelles transactions ;

Pour un système BFT, lorsque le nombre de nœuds participant au consensus est insuffisant, la pause est parfois le coût à payer pour maintenir la sécurité. Pour le dire simplement, ce livre de comptes décentralisé préfère rester là plutôt que de permettre aux autres de tenir des comptes séparés.

En regardant en arrière sous cet angle, on constate que de nombreux incidents apparemment différents dans l'histoire des chaînes publiques tournent en réalité autour d'une même question : que doit faire le réseau lorsque les nœuds distribués ne parviennent pas à se mettre d'accord sur un "état correct" ?

III. Des Bitcoin à Solana, où se situent vraiment les limites des risques 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 incident classique de fork de chaîne.

À l'époque, Bitcoin 0.8 a changé sa base de données de Berkeley DB à LevelDB, puis un bloc contenant de nombreuses entrées de transaction est apparu. Les nouveaux nœuds pouvaient le traiter normalement, mais certains anciens nœuds, en raison de la limitation du nombre de verrous de Berkeley DB, ont jugé ce bloc invalide.

Une situation très embarrassante s'est alors produite : tout le monde exécutait Bitcoin, mais les clients anciens et nouveaux ont commencé à donner des réponses différentes sur "la légalité de ce bloc".

Le réseau s'est donc divisé en deux chaînes, et le côté de la nouvelle version 0.8 avait à un moment environ 60 % de la puissance de calcul, ne pouvant pas compter sur une compétition de puissance de calcul normale pour se rétablir rapidement.

Finalement, de grands pools de minage ont coordonné un retour à l'ancienne version, regagnant plus de puissance de calcul du côté des anciennes règles, permettant ainsi au réseau de se rétablir. Bitcoin a ensuite spécifiquement analysé cet incident avec le BIP 50.

En 2016, l'incident The DAO d'Ethereum a encore avancé la question.

Comme mentionné ci-dessus, la communauté Ethereum a finalement procédé à un Hard Fork, exécutant un changement d'état spécial qualifié d'"irregular state change" par la Fondation Ethereum au bloc 1,920,000, transférant les ETH concernés dans un contrat de récupération.

Mais tout le monde n'a pas accepté ce traitement. Une partie des mineurs et de la communauté qui a refusé d'accepter le changement d'état a continué à maintenir les anciennes règles, ce qui a conduit à l'existence prolongée d'Ethereum Classic (ETC).

Ce fork DAO est également un événement classique, équivalant à dire à tout le monde que lorsque des événements extrêmes se produisent, il existe un consensus social en plus du consensus du code. Si un accord suffisant ne peut être atteint, une chaîne peut vraiment se diviser en deux.

En 2021, Solana a montré un chemin de défaillance complètement différent.

En septembre de cette année-là, un grand nombre de transactions de robots ont afflué sur le réseau, provoquant l'épuisement de la mémoire des nœuds de validation, entraînant l'effondrement de nombreux nœuds. Finalement, tout le réseau n'a pas pu parvenir à un consensus sur l'état actuel, arrêtant la confirmation de nouveaux blocs pendant environ 17 heures, après quoi les validateurs ont coordonné pour restaurer le réseau.

En mettant ces incidents ensemble, on constate qu'ils ne sont pas tous identiques :

• Le problème de Bitcoin en 2013 était que différents clients commençaient à exécuter différentes règles de validité ;
• Le problème de Solana en 2021 était que de nombreux nœuds de validation ne pouvaient plus participer normalement au consensus, le réseau perdant sa vivacité ;
• L'incident DAO d'Ethereum était plus proche de la question de savoir si une communauté devrait modifier activement l'état par de nouvelles règles de protocole ;
• Et cette fois, Cosmos Hub a une autre spécificité, le réseau a d'abord perdu activement sa vivacité par la coordination des validateurs pour empêcher le mouvement des actifs attaqués ; ensuite, une proportion suffisamment élevée de droits de validation a accepté un nouveau logiciel et un état de récupération, permettant au réseau de retrouver un consensus ;

Ainsi, plutôt que de réduire ces événements à "la blockchain peut aussi s'arrêter" ou "la décentralisation est un mythe", il vaut mieux reconnaître un fait plus réel :

Le mécanisme de consensus n'est jamais une machine qui ne tombe jamais en panne. Ce qu'il fournit réellement, c'est un ensemble de règles décentralisées, par exemple, qui décide de la chaîne correcte en cas de désaccord ; combien de participants sont nécessaires pour qu'un état obtienne une finalité ; si le réseau choisit de continuer à fonctionner ou de s'arrêter en cas de défaillance ; et dans des cas extrêmes, quel type d'action collective peut changer les règles de fonctionnement à venir.

Cela laisse également à cet incident de Cosmos une question plus digne de réflexion pour les utilisateurs ordinaires que "devrait-on arrêter la chaîne".

Conclusion

Nous disons souvent, not your keys, not your coins.

Cette phrase reste bien sûr valable, mais elle souligne le droit de contrôle des actifs --- tant que la clé privée est entre vos mains, ni le portefeuille, ni la plateforme d'échange, ni aucun autre tiers ne peuvent signer correctement une transaction pour vous.

À condition que la blockchain sur laquelle vous vous trouvez ait la capacité de traiter cette signature à tout moment.

Le jour où Cosmos Hub a cessé de produire des blocs, les utilisateurs détenaient toujours leurs clés privées, et les actifs n'ont pas disparu sans raison, mais même si vous avez correctement signé une transaction, il n'y avait pas de nouveaux blocs pour l'accepter.

Le processus de récupération illustre encore plus que si suffisamment de participants au consensus acceptent un nouvel ensemble de règles d'état, l'état 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 ne rend pas "Not your keys, not your coins" obsolète, mais nous rappelle que l'autonomie de la clé privée et le droit de consensus sous-jacent ne sont jamais la même chose.

Et pour les portefeuilles, c'est la même chose.

Les portefeuilles peuvent garantir que les clés privées et le droit de signature sont entre les mains de l'utilisateur, peuvent rapidement identifier les anomalies au niveau de la chaîne, afficher avec précision l'état des transactions, établir des RPC et des redondances de nœuds, et après la récupération du réseau, confirmer à nouveau le résultat final de la transaction.

Mais un portefeuille ne peut pas restaurer le consensus d'une chaîne publique, ne peut pas garantir que le réseau sous-jacent ne sera jamais interrompu, et ne peut pas 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 vraiment rechercher n'est peut-être jamais "rien ne doit être modifié" ; au contraire, il devrait clarifier autant que possible ces limites imparfaites : qui peut suspendre le consensus ? Quel poids est nécessaire ? Dans quelles circonstances une intervention d'urgence est-elle autorisée ?

Car une véritable décentralisation ne peut pas empêcher le système de rencontrer des incidents. La clé est que même si un incident se produit vraiment, nous devons toujours savoir qui, selon quelles règles et avec quel consensus, a décidé comment ce livre doit être tenu à l'avenir.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.