Mineurs Etc Annulent La Migration Core Geth V1.13.0

On n’attendait pas qu’un simple numéro de version fasse reculer plusieurs nœuds de pools miniers en moins d’une journée. Pourtant, c’est exactement ce qui s’est produit autour d’Ethereum Classic : une bascule vers Core Geth v1.13.0, une alerte, puis un retour presque immédiat vers le client maintenu. L’affaire n’a pas fait disparaître des blocs ni des fonds. Elle a surtout révélé, en quelques heures, à quel point la confiance dans un dépôt GitHub, un compte de communication et un courriel de pool peut peser plus lourd qu’un processus de revue. Le réseau a tenu. La gouvernance logicielle, elle, a montré ses coutures.

Ce Que Révèle Le Recul Des Mineurs ETC

Le 14 septembre 2026, une version étiquetée stable sort du dépôt ethereumclassic/core-geth. Le lendemain, le compte @ETC_Network présente la mise à jour comme un correctif de sécurité et invite les opérateurs à migrer. Des messages similaires circulent sur des agrégateurs de marché. Des pools reçoivent des courriels envoyés depuis une adresse ethereumclassic.com. Quatre nœuds de 2Miners apparaissent alors sous CoreGeth v1.13.0 vers midi UTC le 15 septembre. Le soir même, ils sont revenus sur Argos v1.12.23.

Ce va-et-vient n’est pas un détail technique pour initiés. Sur une chaîne de preuve de travail déjà marquée par des réorganisations historiques, changer le client de consensus, réactiver un mécanisme de sélection de chaîne et remplacer les points d’entrée du réseau, ce n’est pas une mise à jour cosmétique. C’est un geste politique autant que logiciel. Classix, dans un rapport d’incident daté du 16 septembre, parle d’une version non revue par les mainteneurs historiques, poussée trop vite, puis présentée comme urgente.

Aucun bloc n’a été perdu, aucune réorganisation n’a été observée, aucun fonds n’a été touché. La gravité venait du changement de comportement, pas du bilan comptable.

Rapport d’incident Classix, 16 septembre 2026.

Une Version Sortie Trop Vite Pour Être Banale

Le rythme du dépôt intrigue autant que le contenu. Selon le rapport, 96 commits auraient été poussés en 56 heures directement sur la branche principale, sans pull requests ni revue externe. Le volume annoncé est massif : plus de treize mille lignes ajoutées, près de quatre mille lignes retirées. Une telle densité, sur un client de nœud, n’est pas le rythme habituel d’une rustine de sécurité. C’est le rythme d’une fourche qui veut exister tout de suite.

Le dépôt lui-même n’est pas né le jour de la version. Il aurait été forké depuis etclabscore/core-geth en décembre 2024. L’activité s’emballe le 12 septembre 2026 avec une première candidate, v1.13.0-rc1. Six autres candidates suivent. La version stable est étiquetée à 15 h 06 UTC le 14 septembre. Le matin suivant, l’injonction de migrer circule. Entre la première étiquette et le message public, le délai est court. Trop court, aux yeux de ceux qui maintiennent Argos depuis 2020.

Les chiffres de nœuds individuels restent modestes. Etcnodes.org montrait onze nœuds en v1.13.0 à 7 h 33 UTC le 15 septembre, puis dix le 16. Trois de ces nœuds correspondaient, selon le rapport, à des adresses de bootnodes désormais codées en dur dans le nouveau client. Autrement dit, une partie de la présence visible n’était pas forcément le signe d’une adoption spontanée par des mineurs indépendants. Elle pouvait aussi refléter l’infrastructure de découverte elle-même.

Deux Dépôts, Une Même Étiquette, Deux Légitimités

Ethereum Classic n’a pas de fondation unique qui désigne un client officiel. Le site du projet le rappelle : pas de développeur officiel, pas de mainteneur officiel, pas de site officiel unique, pas de client officiel. Dans un tel vide institutionnel, la légitimité se construit par l’usage et par le temps. etclabscore/core-geth s’appuie sur six années d’historique public, une maintenance continue et une adoption observée parmi les nœuds ETC. Le dépôt ethereumclassic/core-geth s’appuie sur un nom d’organisation, une communication large et une rhétorique de sécurité.

Classix recommande de rester sur Argos v1.12.23, version actuelle du dépôt maintenu depuis 2020, et d’éviter v1.13.0. Les opérateurs déjà passés de l’autre côté sont invités à revenir, à restaurer leur ancienne clé de nœud si elle a été rotée, et à vérifier la configuration de MESS. Ce n’est pas un débat d’ego entre dépôts. C’est un débat sur qui a le droit de dire « mettez à jour maintenant » quand personne n’est officiellement en charge.

Le mot rogue utilisé dans le rapport ne signifie pas automatiquement malveillance démontrée. Il signifie surtout absence de revue par les mainteneurs reconnus et promotion d’une version comme correctif alors que le dépôt historique n’avait pas publié cette mise à jour. Dans un écosystème où les opérateurs de pools scannent les alertes entre deux tours de validation, cette distinction se perd vite. Un courriel, un fil public, un badge « security update », et le basculement commence.

Les Arguments Sécurité Passés Au Crible

v1.13.0 affirmait que toute la série 1.12.x devait être abandonnée, au motif de failles non corrigées, dont une aurait été utilisée contre des bootnodes ETC en mars. Classix a examiné sept points cités. Cinq auraient déjà été traités dans les versions maintenues entre mars et août. Deux autres ne toucheraient pas le chemin pair à pair d’Ethereum Classic. Le récit de l’urgence, selon cette lecture, ne tenait pas.

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. Quant à CVE-2026-22868, liée à la vérification de preuves KZG, Classix estime qu’elle ne s’applique pas à ETC : ces preuves accompagnent les transactions blob nées de la mise à niveau Cancun d’Ethereum, que Classic n’a pas activée.

Un autre point listé concernait la profondeur des requêtes GraphQL. Là encore, le rapport le sort du chemin pair à pair et du consensus : il faut activer GraphQL manuellement. Diego López León, mainteneur de Core Geth cité dans le document, n’aurait pas trouvé, dans les écarts restants, de faille exploitable d’Argos que v1.13.0 serait venue corriger. Si cette lecture tient, la migration n’était pas une rustine tardive. C’était un changement de produit habillé en alerte.

Présenter comme critique ce qui est déjà corrigé, ou ce qui ne s’applique pas à la chaîne, transforme la sécurité en argument de bascule.

Lecture du rapport Classix.

MESS, Ou Comment Un Interrupteur Change La Chaîne

Au-delà des CVE, v1.13.0 touche au cœur du consensus perçu par le client. Une modification réactive le Modified Exponential Subjective Scoring, plus connu sous le nom de MESS, en retirant la configuration qui le désactivait au bloc 19 250 000. Ethereum Classic avait introduit ce mécanisme en 2020 pour se protéger contre les réorganisations, puis l’avait éteint via ECIP-1110 après le passage d’Ethereum à la preuve d’enjeu.

MESS n’est pas un simple score cosmétique. Il change la façon dont un nœud tranche entre des histoires concurrentes. Si seulement une famille de clients le réactive pendant que Besu, Nethermind et Getc l’ignorent, le réseau peut voir des nœuds départager autrement les mêmes forks. Sur une chaîne déjà traumatisée par des attaques de majorité en août 2020, dont des réorganisations de plusieurs milliers de blocs, ce n’est pas une option anodine.

On peut aimer MESS ou le juger dépassé. On ne peut pas le réintroduire par une bascule de client non coordonnée et prétendre qu’il s’agit d’un détail de configuration. Classix insiste sur ce point : des clients différents se comporteraient différemment si seuls les nœuds Core Geth suivaient la nouvelle règle. La diversité logicielle, souvent présentée comme un bouclier, devient alors une source de divergence si les règles implicites ne sont plus les mêmes.

Bootnodes, Clés DNS Et Identités Qui Tourneraient

Le client contesté ne se contente pas de rouvrir MESS. Il change l’infrastructure de découverte. Un commit remplace une clé de signature d’arbre DNS maintenue par des contributeurs etclabscore depuis 2020 et code en dur trois nouvelles adresses IP de bootnodes. Deux arbres plus anciens, blockd.info et etcdisco.net, sont ensuite retirés. Trois domaines de remplacement seraient hébergés via le même compte Cloudflare, avec l’aveu, dans le dépôt, qu’un incident sur ce compte unique pourrait couper les trois chemins.

Les opérateurs suivant le guide de migration n’étaient pas informés, selon Classix, de qui contrôlait la nouvelle clé de signature. Le même guide demandait de rotator les clés P2P des nœuds, en citant CVE-2026-26315. Or Aegis aurait déjà traité le fond du problème en mars. Rotater une clé change l’identité réseau du nœud. Le pair doit alors reconstruire ses connexions à travers la nouvelle découverte. Autrement dit, la rustine annoncée poussait les nœuds vers une topologie contrôlée autrement.

Pris un par un, chacun de ces gestes peut se défendre. Ensemble, ils redessinent qui parle à qui, comment on tranche une chaîne concurrente, et par quels points d’entrée on rejoint le réseau. C’est précisément ce cocktail qui a fait qualifier l’événement de haute sévérité malgré un faible impact observé. L’impact mesuré était nul sur les blocs et les fonds. L’impact potentiel, lui, tenait au changement de règles et de topologie.

Pourquoi Les Pools Ont Reculé Aussi Vite

Les pools miniers ne sont pas des laboratoires. Ils sont des usines à blocs. Un nœud qui se comporte autrement, même quelques heures, peut coûter de l’orphelignage, de la latence, de la méfiance des mineurs affiliés. Voir quatre nœuds 2Miners basculer puis revenir le jour même raconte une séquence classique : un message d’autorité perçue, une application rapide, puis un contre-récit technique suffisamment précis pour inverser la décision.

Les autres pools listés seraient restés sur des versions de la série 1.12. Cette inertie a probablement limité la portée. Si une part dominante du hashrate avait suivi v1.13.0 pendant plusieurs jours, le débat sur MESS n’aurait plus été théorique. Il serait devenu une question de quelle histoire de blocs le réseau considère canonique. Le recul rapide a donc autant de valeur que l’alerte initiale. Il montre qu’une partie de l’infrastructure lit encore les rapports d’incident, pas seulement les bannières de mise à jour.

Il reste des nœuds isolés sur la version contestée. Dix, puis peut-être moins selon les vérifications à venir. Classix présente son texte comme une notification initiale et un rapport intérimaire, promis à mise à jour si les nœuds restants sont identifiés, si les administrateurs de l’organisation GitHub répondent, ou si d’autres faits matériels apparaissent. L’histoire n’est donc pas close. Elle est seulement sortie de la phase où des pools industriels suivaient le mouvement.

Le Fantôme Des Attaques De 2020 N’A Pas Disparu

Ethereum Classic n’aborde pas ces sujets en terrain neutre. En août 2020, le réseau a subi trois attaques de majorité, avec des réorganisations impliquant des milliers de blocs. Ces épisodes ont durablement associé ETC à la fragilité d’une preuve de travail dont le hashrate peut être loué. MESS était précisément une réponse à cette mémoire. Le désactiver plus tard, après la fusion d’Ethereum, répondait à une autre lecture : le mécanisme n’était plus le bon compromis.

Réouvrir MESS en 2026, via un client non coordonné, réveille donc deux peurs à la fois. La première est technique : des nœuds qui ne tranchent plus de la même façon. La seconde est historique : tout ce qui évoque une guerre de chaînes rappelle les réorganisations d’alors. Même si rien de tel ne s’est produit ces derniers jours, le vocabulaire de la communauté est déjà chargé. D’où l’attention disproportionnée, en apparence, pour un incident sans perte financière.

Les réorganisations ne naissent pas seulement d’un attaquant externe. Elles naissent aussi d’un désaccord logiciel sur ce qui constitue la meilleure chaîne. Un client qui réactive un score subjectif pendant que d’autres s’en tiennent à la règle antérieure crée les conditions d’un désaccord honnête, pas forcément d’une attaque. C’est parfois plus dangereux, parce que chaque camp peut croire défendre la spécification.

Diversité Des Clients, Slogan Et Réalité

Classix invite les opérateurs à ne pas concentrer le hashrate sur Core Geth et à considérer Nethermind, Besu et Getc. Le conseil n’est pas nouveau. Ethereum le répète depuis des années, au point d’enchaîner des devnets privés quand une mise à niveau comme Glamsterdam révèle des bugs croisés entre exécution et consensus. Chez Classic, la diversité est plus fragile, simplement parce que l’écosystème est plus petit et que Core Geth reste un point de ralliement historique.

La diversité n’est utile que si les clients implémentent la même règle de consensus. Multiplier les binaires tout en laissant un seul d’entre eux réactiver MESS, ce n’est plus de la diversité. C’est de la fragmentation. Le rapport le dit sans détour. Il demande aussi aux administrateurs de l’organisation GitHub ethereumclassic de durcir les contrôles : propositions et revues avant la création de dépôts, protection des branches par défaut, identification claire des mainteneurs qui distribuent du logiciel. Il demande encore que ethereumclassic/core-geth soit retiré, archivé, ou au moins affublé d’un avertissement expliquant qu’il n’est pas un client officiel.

• Rester sur Argos v1.12.23 tant que le dépôt maintenu n’a pas tranché autrement.
• Vérifier MESS et restaurer l’ancienne clé P2P en cas de rotation récente.
• Répartir les nœuds entre plusieurs implémentations réellement compatibles.
• Traiter tout appel à migration « sécurité » comme une hypothèse à recouper.

Quand La Communication Devient Une Surface D’Attaque

Le plus troublant, dans cette séquence, n’est pas seulement le code. C’est le canal. Un compte largement suivi, des pages de marché qui reprennent le message, un courriel envoyé à des pools depuis un nom de domaine évocateur. Aucun de ces vecteurs n’est, à lui seul, une preuve de capture. Ensemble, ils montrent que la distribution d’un client de nœud passe encore par des réflexes de marque. Or Ethereum Classic a précisément choisi de ne pas avoir de marque officielle.

Ce paradoxe alimente la confusion. S’il n’y a pas d’autorité, qui a le droit d’écrire « mettez à jour tous les nœuds 1.12.x » ? Si quelqu’un le fait quand même, les opérateurs doivent-ils obéir au nom, au dépôt, à l’historique des correctifs, ou à leur propre lecture des diffs ? La réponse honnête est inconfortable : ils doivent lire. Peu d’équipes de pool ont le temps de relire 13 422 lignes ajoutées en un week-end. D’où le rôle des rapports d’incident, et d’où le danger quand le premier message public précède la revue.

On a trop souvent réduit la sécurité des chaînes à la cryptographie et au hashrate. Cette affaire rappelle une troisième couche : la chaîne d’approvisionnement logicielle. Qui pousse sur main. Qui étiquette stable. Qui possède le compte Cloudflare des arbres DNS. Qui envoie le courriel aux pools. Ces questions sont moins glamour qu’une CVE. Elles décident pourtant si un mineur bascule avant d’avoir compris MESS.

Ce Que L’Incident Ne Dit Pas, Et Qu’Il Faut Dire

Il ne dit pas qu’Ethereum Classic vient de subir une nouvelle attaque de majorité. Il ne dit pas que des fonds ont quitté des adresses. Il ne dit pas que la chaîne s’est cassée en deux histoires durables. Il dit qu’une fenêtre s’est ouverte, que quelques nœuds de production y sont entrés, puis en sont ressortis. Cette modestie des dégâts ne doit pas servir d’excuse. Les incidents à faible impact sont précisément ceux qu’on peut encore étudier à froid.

Il ne dit pas non plus qui, exactement, a piloté le dépôt forké, ni avec quelle intention dernière. Le rapport Classix documente un rythme, un contenu, une communication et un écart avec le dépôt maintenu. Il ne clôt pas le chapitre des motifs. Tant que les administrateurs de l’organisation GitHub n’ont pas répondu publiquement, toute lecture d’intention reste une hypothèse. On peut décrire des faits de publication. On ne peut pas, ici, prétendre connaître les arrières-pensées.

Enfin, l’incident ne dit pas que Argos est parfait. Un client maintenu depuis 2020 peut avoir des dettes techniques. Il dit que le bon réflexe, face à une alerte de sécurité, n’est pas de changer de fourche parce que le numéro de version est plus élevé. C’est de demander où est la revue, où est le correctif déjà publié, et ce que le diff change vraiment dans le consensus et la découverte.

Leçons Concrètes Pour Les Opérateurs De Nœuds

La première leçon est procédurale. Une version stable qui naît après six candidates en deux jours mérite plus de suspicion, pas moins. La deuxième est cartographique : avant d’appliquer un guide de migration, regarder si le guide demande de rotator une clé, de changer de bootnodes, de modifier un score de chaîne. Si oui, ce n’est plus une rustine. C’est un changement de voisinage réseau.

La troisième leçon concerne les pools. Les nœuds de production ne devraient pas tous suivre le même fil de mises à jour au même instant. Garder au moins un nœud témoin sur le client précédent, comparer les pairs, les hauteurs, les forks vus, puis seulement étendre. Cette discipline est ennuyeuse. Elle coûte moins cher qu’une après-midi à revenir en arrière sous la pression d’un rapport public.

La quatrième leçon est collective. Si Ethereum Classic refuse le statut d’officiel, alors les organisations GitHub qui portent le nom du projet doivent malgré tout se comporter comme des gardiens de dépôt, pas comme des vitrines. Protéger la branche par défaut, exiger des revues, identifier les mainteneurs, signaler clairement les fourches non reconnues : ce n’est pas trahir la décentralisation. C’est empêcher qu’un nom de projet devienne un sésame.

Sans client officiel, la seule autorité durable reste l’historique public des correctifs et l’adoption observée des nœuds.

Principe repris du dossier Classix.

Ce Que Les Marchés Ont À Voir Là-Dedans

Les cours d’ETC n’ont pas besoin d’un drame pour bouger, et cet article ne prétend pas lire un chandelier. Reste que les investisseurs confondent souvent « rien n’a été volé » et « rien n’est arrivé ». Un réseau dont les pools peuvent être poussés vers un client aux règles différentes en quelques heures porte un risque de gouvernance, même quand le grand livre reste intact. Ce risque se paie rarement le jour J. Il se paie le jour où deux histoires de blocs durent plus longtemps qu’un communiqué.

Les agrégateurs qui ont repris le message de migration illustrent un autre angle mort. Les pages de marché sont lues comme des tableaux de bord neutres. Elles relaient pourtant des injonctions opérationnelles. Un opérateur pressé peut y voir une confirmation. La neutralité affichée d’un site de cours n’est pas une revue de code. Traiter ces relais comme des sources techniques, c’est inverser la hiérarchie des preuves.

Pour les mineurs individuels, la leçon est plus simple encore. Si un pool change de client, demander lequel, quelle version, et si MESS est actif. Si la réponse est floue, la récompense du bloc ne suffit pas à justifier l’angle mort. La preuve de travail n’absout pas de lire la configuration du logiciel qui assemble les blocs.

Une Chaîne Sans Centre, Pas Une Chaîne Sans Soin

Ethereum Classic a construit une partie de son identité contre l’idée d’un centre qui décide. Ce réflexe a un prix : chaque dépôt peut se présenter comme la suite naturelle du projet. Chaque compte peut parler au nom du réseau. Chaque version peut se dire urgente. Le soin, dès lors, ne vient plus d’un bureau. Il vient de la lenteur volontaire des opérateurs, de la publicité des diffs, de la diversité réelle des clients, et de la capacité à reculer quand un rapport solide contredit une bannière.

Le 15 septembre, une partie de l’infrastructure minière a montré qu’elle savait encore reculer. C’est la nouvelle la plus utile de cette affaire. Pas le spectacle d’une fourche contestée. Pas la liste des CVE. Le recul. Dans un milieu qui célèbre souvent la vitesse, revenir à Argos v1.12.23 en quelques heures est un geste adulte. Il reste à transformer ce réflexe en habitude, et l’habitude en règle de dépôt.

Classix le dit : le document sera mis à jour si les nœuds restants sont vérifiés, si les mainteneurs de l’organisation répondent, si d’autres faits apparaissent. Tant que ces réponses manquent, la prudence la plus simple est aussi la plus claire. Ne pas courir après v1.13.0. Relire sa configuration MESS. Garder plusieurs clients compatibles. Et traiter tout appel à migrer « pour la sécurité » comme le début d’une enquête, jamais comme la fin d’une discussion.

Les mineurs ont inversé la migration. Le réseau n’a pas perdu de blocs. L’alerte, elle, demeure, parce qu’elle ne portait pas seulement sur une version. Elle portait sur la facilité avec laquelle une chaîne sans autorité officielle peut encore obéir, quelques heures durant, à une autorité apparente. C’est cette facilité qu’il faudra désormais surveiller, version après version, dépôt après dépôt.