Que se passe-t-il quand une mise à jour présentée comme urgente circule plus vite que les vérifications habituelles ? Sur Ethereum Classic, quelques nœuds de pools miniers ont basculé vers Core Geth v1.13.0, puis sont revenus en arrière. L’épisode n’a pas fait disparaître des blocs ni des fonds. Il a pourtant révélé une tension plus ancienne : qui a le droit de pousser un client, au nom de qui, et avec quelles conséquences sur le consensus.
Une alerte qui a fait reculer les mineurs
Le 16 septembre 2026, Classix a publié un rapport d’incident. Le constat est simple à formuler et plus délicat à digérer. Une version baptisée Core Geth v1.13.0 est sortie le 14 septembre depuis le dépôt ethereumclassic/core-geth. Le compte @ETC_Network l’a présentée le lendemain comme une mise à jour de sécurité. Des messages similaires ont circulé sur des agrégateurs de données de marché. Des pools ont même reçu des courriels depuis une adresse ethereumclassic.com. Une partie de l’infrastructure minière a suivi. Puis elle a fait demi-tour.
Classix insiste sur un point de gouvernance technique. Les mainteneurs historiques de Core Geth n’avaient pas revu ce code. Le dépôt maintenu depuis 2020, etclabscore/core-geth, n’avait pas publié cette version. Le conseil opérationnel a donc été clair : rester sur Argos v1.12.23, considérée comme la lignée suivie par une large part des nœuds. Ce n’est pas un détail de packaging. Sur une chaîne en preuve de travail, le client que font tourner les mineurs oriente la façon dont les blocs sont acceptés, dont les pairs sont trouvés, et parfois dont une réorganisation est tranchée.
Ce qu’il faut retenir d’emblée
Migration brève vers v1.13.0, retour à Argos, aucun bloc perdu selon Classix, mais un changement de comportement consensus et de découverte de nœuds jugé suffisamment grave pour classer l’événement en sévérité haute et impact faible.
Chronologie serrée d’une version accélérée
Le dépôt contesté n’est pas apparu le jour de la release. Il a été forké depuis etclabscore/core-geth en décembre 2024. L’activité a ensuite connu un pic brutal. Selon le rapport, 96 commits ont été poussés en 56 heures, directement sur la branche principale, sans pull requests ni revue externe. Le volume annoncé est massif : 13 422 lignes ajoutées, 3 977 lignes retirées. Ce rythme ne ressemble pas à une rustine isolée. Il ressemble à une réécriture compressée.
Le 12 septembre 2026, une première étiquette v1.13.0-rc1 apparaît. Six autres candidats suivent. Le 14 septembre à 15 h 06 UTC, v1.13.0 est marquée stable. Le matin suivant, le message de migration est public. Entre la première candidate et la consigne de basculer, l’intervalle est court. Trop court, aux yeux de Classix, pour qu’une communauté éclatée puisse comparer les diffs, tester les clients concurrents et mesurer l’effet sur le réseau.
Cette vitesse explique une partie de la confusion. Un opérateur de pool lit un mot « sécurité », voit un numéro de version plus élevé, et applique le réflexe d’urgence. Sur Ethereum Classic, ce réflexe n’est pas absurde. Le réseau a déjà connu des attaques majoritaires. Mais l’urgence ne dispense pas de vérifier la provenance du binaire, la revue du code et l’alignement avec les autres implémentations.
Ce que les nœuds miniers ont réellement fait
Les données citées par Classix donnent une image précise, presque clinique. Le 15 septembre à 12 h 09 UTC, quatre nœuds 2Miners tournaient encore sous CoreGeth v1.13.0. À 23 h 35 UTC, les quatre étaient revenus à Argos v1.12.23. Les autres pools listés restaient sur la série 1.12. Autrement dit, la bascule n’a pas emporté tout le hashrate visible. Elle a touché une poche identifiable, puis s’est inversée en moins de douze heures pour ces machines-là.
Du côté des nœuds individuels, le tableau est un peu différent. Etcnodes.org affichait 11 nœuds en v1.13.0 à 07 h 33 UTC le 15 septembre, puis 10 le 16. Trois de ces adresses correspondaient, selon le rapport, à des bootnodes dont les IP étaient désormais codées en dur dans le nouveau client. Ce détail n’est pas cosmétique. Quand un logiciel impose de nouveaux points d’entrée réseau, il redessine la carte des premiers contacts entre pairs.
Classix affirme qu’aucun bloc n’a été perdu, qu’aucune réorganisation n’a été observée, qu’aucun fonds n’a été touché et qu’aucun service n’a été interrompu. L’événement est pourtant classé en sévérité haute et impact faible. La formule peut sembler contradictoire. Elle décrit un logiciel qui change le comportement de consensus sans qu’une perte économique ait déjà été mesurée. Le risque précède le dégât. C’est précisément ce que les opérateurs de preuve de travail détestent : un écart de règles entre clients avant qu’un fork de fait ne le rende visible.
Le rapport présente l’épisode à la fois comme une notification initiale et comme un compte rendu provisoire, destiné à être mis à jour si les nœuds restants sont identifiés ou si les administrateurs de l’organisation répondent.
Pourquoi le mot « rogue » a été employé
Classix parle de version rogue parce que le canal de publication ne correspondait pas au dépôt suivi depuis six ans. Sur Ethereum Classic, cette distinction pèse lourd. Le projet lui-même, d’après la clause reprise dans le rapport, ne désigne pas de développeur officiel, de mainteneur officiel, de site officiel ni de client officiel. L’autorité, s’il en existe une, se construit par l’usage, l’historique public et la continuité de maintenance.
Dans ce cadre, etclabscore/core-geth tire sa légitimité d’une ligne de temps : maintenance depuis 2020, versions successives Aegis, Hermes puis Argos, adoption observée parmi les nœuds. Le dépôt ethereumclassic/core-geth peut porter un nom proche, un numéro plus élevé et un discours de sécurité. Il n’emporte pas automatiquement la même confiance opérationnelle. Le nom d’un dépôt n’est pas une signature cryptographique de gouvernance.
Les opérateurs ont donc dû départager deux signaux. D’un côté, une communication large, y compris par courriel. De l’autre, une alerte de ceux qui maintiennent la lignée déjà déployée. Le retour des nœuds 2Miners vers Argos montre que, dans l’infrastructure minière, le second signal a fini par l’emporter. Ce n’est pas une victoire rhétorique. C’est un choix de continuité.
Les arguments sécurité passés au crible
La note de v1.13.0 affirmait que tous les nœuds en 1.12.x devaient migrer. Elle soutenait que chaque version de cette série contenait des failles non corrigées, dont une vulnérabilité censée avoir servi contre des bootnodes Ethereum Classic en mars. Classix a repris sept points cités par la release et a contesté le récit point par point.
Cinq problèmes, selon le rapport, avaient déjà été traités dans les versions maintenues entre mars et août. Deux autres n’affectaient pas le chemin pair à pair d’Ethereum Classic. CVE-2026-22862 et CVE-2026-26315 auraient été corrigées dans Aegis v1.12.21. Hermes v1.12.22 aurait ensuite traité d’autres sujets cryptographiques. Argos v1.12.23 aurait intégré un décodage différé des messages pair à pair inspiré de go-ethereum pour CVE-2026-26313.
Reste CVE-2026-22868, liée à la vérification de preuves KZG. Classix estime qu’elle ne s’applique pas à Ethereum Classic, parce que ces preuves sont associées aux transactions blob introduites par la mise à niveau Cancun d’Ethereum, que ETC n’a pas activée. Une autre question, la profondeur des requêtes GraphQL, ne ferait pas partie du chemin pair à pair ni du consensus et exigerait que GraphQL soit activé manuellement. Autrement dit, une surface optionnelle n’est pas une urgence réseau généralisée.
Le mainteneur Diego López León aurait passé en revue les différences restantes et n’aurait pas trouvé, dans Argos, de faille exploitable que v1.13.0 viendrait corriger. Si ce diagnostic tient, le motif « il faut absolument quitter 1.12.x » s’effondre. Il reste alors les autres changements : le MESS, les bootnodes, la rotation des clés. C’est là que l’incident cesse d’être un débat de CVE et redevient un débat de règles de chaîne.
| Point avancé par v1.13.0 | Lecture de Classix |
|---|---|
| Toutes les 1.12.x seraient vulnérables | Plusieurs correctifs déjà livrés dans Aegis, Hermes et Argos |
| CVE liées au P2P et aux bootnodes | Une partie déjà traitée dès mars 2026 |
| CVE-2026-22868 (preuves KZG) | Non applicable sans activation Cancun côté ETC |
| GraphQL et profondeur de requête | Hors chemin consensus, option à activer volontairement |
Le retour du MESS, souvenir de 2020
Au-delà des bulletins de sécurité, v1.13.0 modifie la manière dont un nœud peut choisir une chaîne. Une modification réactive le Modified Exponential Subjective Scoring, plus connu sous le sigle MESS, en retirant la configuration qui l’avait désactivé au bloc 19 250 000. Ethereum Classic avait introduit ce mécanisme en 2020 pour se protéger des réorganisations, puis l’avait éteint via ECIP-1110 après le passage d’Ethereum à la preuve d’enjeu.
Le MESS n’est pas un simple drapeau cosmétique. Il change la façon dont un client pondère l’histoire concurrente. Si seulement les nœuds Core Geth le réactivent, tandis que Besu, Nethermind et Getc ne l’implémentent pas, le réseau n’applique plus les mêmes règles partout. Classix le dit sans détour : des clients de consensus différents peuvent alors se comporter différemment. Sur une chaîne déjà marquée par des réorganisations historiques, cette hétérogénéité n’est pas un luxe académique.
Ethereum Classic a subi trois attaques majoritaires en août 2020, avec des réorganisations impliquant des milliers de blocs. Ce souvenir n’est pas une anecdote de forum. Il explique pourquoi n’importe quel changement de scoring subjectif réveille les opérateurs. Une protection conçue pour un contexte donné peut devenir une source de divergence si elle n’est plus partagée par l’ensemble des implémentations.
Le rapport ne décrit pas une catastrophe déjà advenue. Il décrit un désalignement possible. Dans la pratique minière, ce désalignement se manifeste d’abord par des nœuds qui voient une tête de chaîne que d’autres rejettent, puis par des pools qui hésitent à pointer leur hashrate. Le fait qu’aucune réorganisation n’ait été enregistrée pendant l’épisode ne prouve pas que le réglage soit anodin. Il prouve seulement que la fenêtre d’adoption a été courte et partielle.
Nouveaux bootnodes et clés de découverte
Le client contesté ne se contente pas de toucher au scoring. Un commit remplace une clé de signature d’arbre DNS maintenue par des contributeurs etclabscore depuis 2020. Trois nouvelles adresses IP de bootnodes sont inscrites en dur. Deux arbres de découverte plus anciens, blockd.info et etcdisco.net, sont ensuite retirés. Trois domaines de remplacement passeraient par le même compte Cloudflare. Le dépôt reconnaîtrait lui-même qu’un incident sur ce compte unique pourrait couper les trois chemins.
Les opérateurs qui suivaient le guide de migration n’étaient pas informés, selon Classix, de qui contrôlait la nouvelle clé de signature. C’est un angle mort classique des bascules réseau. On parle beaucoup de CVE. On parle moins de qui signe l’infrastructure de découverte, où vivent les premiers pairs, et ce qu’il advient si ces points d’entrée disparaissent ou sont capturés.
Le guide demandait aussi de faire tourner les clés de nœud P2P, en citant CVE-2026-26315. Classix répond qu’Aegis avait déjà traité le fond du problème en mars. Tourner une clé change l’identité réseau d’un nœud. Le pair doit reconstruire ses connexions via l’infrastructure de découverte. Si cette infrastructure vient d’être remplacée, la rotation n’est plus un geste d’hygiène isolé. Elle devient un aiguillage vers les nouveaux bootnodes.
On comprend alors pourquoi trois nœuds encore visibles en v1.13.0 coïncidaient avec des IP de bootnodes. Une mise à jour n’installe pas seulement un binaire. Elle peut installer une topologie. Sur un réseau pair à pair, la topologie est une forme de pouvoir discret.
Ce que Classix demande aux opérateurs
La consigne opérationnelle est nette. Éviter ethereumclassic/core-geth v1.13.0. Rester sur etclabscore/core-geth Argos v1.12.23. Ceux qui ont déjà migré doivent revenir, restaurer l’ancienne clé de nœud si elle a été tournée, et vérifier la configuration MESS. Ces trois gestes forment une checklist de remise à l’état antérieur, plus qu’une montée de version.
Classix ajoute un conseil de fond : ne pas concentrer la puissance de calcul sur un seul client. Nethermind, Besu et Getc restent des alternatives. La diversité logicielle n’est pas un slogan de conférence. C’est une assurance contre un binaire unique qui changerait les règles pendant que le hashrate dort. Ethereum, de son côté, multiplie les tests croisés entre clients d’exécution et de consensus avant une activation. Les préparatifs autour de Glamsterdam l’ont encore illustré, avec un devnet privé supplémentaire après des bogues exposés avant une activation prévue sur Sepolia.
Ethereum Classic n’a pas la même densité d’équipes ni le même calendrier de forks coordonnés. D’où l’insistance sur des contrôles de dépôt plus stricts. Classix demande aux administrateurs de l’organisation GitHub ethereumclassic de durcir les accès, d’exiger propositions et revues avant la création de nouveaux dépôts, de protéger les branches par défaut et d’identifier les mainteneurs des dépôts qui distribuent du logiciel. Le dépôt contesté devrait être retiré, archivé, ou au minimum porter un avertissement expliquant qu’il n’est pas un client officiel.
Ce dernier mot, « officiel », reste glissant. Le projet refuse précisément cette étiquette. Classix le reconnaît et déplace le critère : l’historique public de six ans, la maintenance active, l’adoption observée. Ce n’est pas une couronne. C’est une piste d’audit. Pour un opérateur de pool, cette piste est souvent plus utile qu’un bandeau marketing.
Pourquoi l’épisode dépasse un simple rollback
Un rollback de nœuds miniers peut sembler banal. On installe, on voit un message d’alerte, on revient. Sur une blockchain, ce geste raconte autre chose. Il dit que la communication de sécurité est devenue un vecteur de propagation aussi efficace qu’un correctif réel. Il dit aussi que le nom d’un dépôt, le numéro de version et l’apparence d’une organisation suffisent parfois à faire bouger de la puissance de calcul avant que le code ait été lu.
La preuve de travail n’élimine pas ce risque. Elle le déplace. Le hashrate suit les pools. Les pools suivent des runbooks. Les runbooks suivent des annonces. Si l’annonce précède la revue, le réseau bascule d’abord, discute ensuite. Ici, la discussion a rattrapé la bascule assez vite pour éviter une perte mesurable. Ce n’est pas une garantie pour la prochaine fois.
Les réorganisations de 2020 restent le décor mental de beaucoup d’opérateurs ETC. Elles rappellent qu’une minorité de hashrate mal alignée, ou une majorité temporairement captée, peut réécrire une fenêtre d’histoire. Réactiver un mécanisme anti-réorganisation sur un seul client, pendant que les autres n’en font rien, crée un terrain où deux lectures de la même chaîne peuvent coexister. Même brève, cette coexistence mérite d’être documentée.
Il faut aussi parler d’attention. Un réseau qui ne désigne personne comme officiel attire à la fois des mainteneurs patients et des initiatives soudaines. L’absence de centre n’est pas l’absence de pouvoir. Le pouvoir se loge dans les bootnodes, les clés DNS, les listes d’e-mails, les comptes qui parlent au nom du ticker. L’incident de septembre 2026 met ces leviers sous la lumière, sans qu’il soit besoin d’inventer un complot. Il suffit de lire les diffs et les horodatages.
Gouvernance logicielle sans chef d’orchestre
Beaucoup de lecteurs comparent instinctivement Ethereum Classic à Ethereum. La comparaison éclaire et trompe à la fois. Ethereum a des processus de testnets, des équipes clientes multiples, des calendriers publics. ETC hérite d’une histoire de scission, d’une base minière plus mince, d’une communication plus dispersée. Dans ce paysage, un dépôt GitHub bien nommé peut peser autant qu’un ECIP longuement débattu.
Classix ne prétend pas clore le débat politique du projet. Le rapport se présente comme technique et provisoire. Il restera ouvert si des nœuds restants sont vérifiés, si des mainteneurs d’organisation répondent, si d’autres faits matériels apparaissent. Cette prudence de forme contraste avec la fermeté des recommandations : ne pas rester sur v1.13.0, restaurer Argos, surveiller le MESS, diversifier les clients.
Pour un administrateur de nœud, la leçon pratique tient en quelques habitudes. Vérifier le dépôt d’origine, pas seulement le nom du logiciel. Lire si une release a suivi des pull requests. Comparer les CVE citées avec le journal des versions déjà installées. Regarder si un changement touche le consensus ou seulement une API optionnelle. Examiner qui contrôle la découverte de pairs. Ces gestes prennent du temps. Ils coûtent moins cher qu’une divergence de chaîne.
Les pools qui sont revenus en arrière ont, de fait, appliqué cette discipline après coup. Quatre nœuds 2Miners ont servi de révélateur public. D’autres machines individuelles ont mis plus longtemps à disparaître des listes. Le réseau n’est pas un bloc unique. Il est une mosaïque de mises à jour plus ou moins rapides, plus ou moins documentées.
Diversité des clients, refrain utile
Chaque crise de client ravive le même refrain. Un seul logiciel dominant transforme un bogue ou une décision de conception en événement réseau. Ethereum Classic n’échappe pas à cette arithmétique. Si Core Geth concentre trop de nœuds miniers, un changement de scoring ou de bootnodes se propage plus loin qu’un correctif isolé dans un client minoritaire.
Besu, Nethermind et Getc ne sont pas des talismans. Ils ont leurs propres surfaces d’erreur. Mais ils brisent la corrélation. Un défaut de revue dans un dépôt ne devient pas automatiquement la règle de tous les mineurs. La diversité n’empêche pas un opérateur de se tromper. Elle empêche le même tromperie de devenir consensus par accident.
C’est aussi une question de culture d’exploitation. Un pool qui sait redéployer Argos en quelques heures, restaurer une clé et contrôler un drapeau MESS a un avantage sur un pool qui traite le client comme une boîte noire. L’incident de septembre n’a pas seulement testé un binaire. Il a testé les runbooks.
Ce que l’absence de dégât ne doit pas cacher
Il est tentant de classer l’affaire comme un non-événement parce qu’aucune perte n’a été comptabilisée. Ce serait lire uniquement la colonne impact et ignorer la colonne sévérité. Un logiciel peut modifier le consensus sans casser tout de suite les soldes. Les dégâts d’un réseau de preuve de travail se mesurent parfois plus tard, quand une réorganisation révèle qu’une partie des nœuds n’avait plus la même définition de la chaîne valide.
Classix a choisi de publier tôt. Le document sert d’avertissement autant que de récit. Tant que des nœuds v1.13.0 restent visibles, même en petit nombre, le dossier n’est pas seulement historique. Il reste opérationnel. Trois bootnodes alignés sur le nouveau client suffisent à poser une question simple : vers quels pairs un nœud neuf est-il guidé au premier démarrage ?
Les opérateurs qui n’ont jamais quitté la série 1.12 n’ont rien à « réparer », si ce n’est à confirmer leur configuration. Ceux qui ont suivi le guide de migration ont une liste plus longue. Revenir en arrière n’est pas seulement changer un numéro de version. C’est défaire une identité réseau éventuellement neuve et un scoring éventuellement réactivé.
Une mémoire utile pour les prochaines alertes
Les alertes de sécurité continueront d’arriver. Certaines seront justes. D’autres mélangeront des CVE déjà closes, des surfaces hors consensus et des changements d’infrastructure. La compétence d’un écosystème se juge à sa capacité à séparer ces couches. Ethereum Classic vient d’en avoir une illustration publique, avec horodatages, comptes de nœuds et liste de commits.
Le style humain d’un incident de ce type n’est pas le ton martial. C’est la fatigue des gens qui maintiennent un client depuis des années, la précipitation de ceux qui voient un numéro de version monter, la prudence des pools qui préfèrent un rollback à une explication incomplète. Entre ces trois postures, le réseau a choisi, pour l’instant, la continuité d’Argos.
Reste le travail de fond demandé aux administrateurs de dépôts : protéger les branches, nommer les mainteneurs, éviter qu’un fork puisse se présenter comme la voie unique. Sans ce cadrage, le prochain message « migrez maintenant » repartira avec la même longueur d’avance sur la revue. Les mineurs pourront encore reculer. Ils n’auront pas toujours le luxe d’un impact faible.
En attendant une éventuelle mise à jour du rapport, la photographie du 16 septembre 2026 est celle-ci : une release rapide, une promotion large, une adoption partielle, un retour des pools cités, des nœuds isolés encore visibles, aucun sinistre comptable déclaré, et une discussion rouverte sur le MESS, les bootnodes et la diversité des clients. Ce n’est pas la fin d’Ethereum Classic. C’est un rappel que, sur une chaîne sans chef unique, la prudence se code autant dans les processus Git que dans les ASIC.
Checklist pour un opérateur de nœud ETC
- Confirmer que le binaire vient d’etclabscore/core-geth Argos v1.12.23 si l’on suit cette lignée.
- Éviter v1.13.0 du dépôt contesté tant que le rapport n’est pas infirmé.
- Si une migration a eu lieu, restaurer l’ancienne clé P2P et vérifier le MESS.
- Comparer les CVE citées avec le journal réel des versions 1.12.21 à 1.12.23.
- Envisager un second client pour ne pas lier tout le hashrate à une seule implémentation.
On peut lire cet épisode comme une anecdote de dépôt. On peut aussi le lire comme un cas d’école. Une blockchain publique vit autant de ses règles écrites que de ses habitudes de mise à jour. Quand ces habitudes s’accélèrent, le réseau a besoin de gens qui savent dire non, puis documenter pourquoi. C’est exactement le rôle qu’a voulu jouer le rapport du 16 septembre. Qu’il soit amendé plus tard ne change pas l’essentiel : les mineurs ont reculé, et cette marche arrière vaut mieux qu’une confiance aveugle dans un numéro de version.
Les semaines suivantes diront si les nœuds restants disparaissent, si l’organisation GitHub répond, si le dépôt est archivé ou simplement laissé en l’état. D’ici là, la leçon la plus sobre tient en une phrase. Sur Ethereum Classic, la sécurité n’est pas seulement une liste de CVE. C’est aussi la certitude que le client que l’on lance applique les mêmes règles que le voisin, découvre les pairs par des chemins connus, et n’a pas été poussé en 56 heures sans regard extérieur. Cette certitude-là, aucun bandeau « security update » ne la remplace.
