Dans l’ombre du petit groupe qui a maintenu Geth en vie à travers trois forks

Le 15 septembre 2022, à 06:42:42 UTC, le slot 4 700 013 a finalisé la transition du réseau principal d’Ethereum du proof-of-work vers le proof-of-stake. Le bloc a été sealed par un validateur exécutant un client de consensus Lighthouse connecté à un client d’exécution Geth. La contribution de Geth à cet instant, codée en dur comme la valeur TerminalTotalDifficulty dans params/config.go, est le produit d’environ neuf mois d’ingénierie concentrée par un groupe de moins de dix mainteneurs principaux. Ce même groupe a, sur les dix-huit mois suivants, déployé le mécanisme de retrait dans Shanghai/Capella (12 avril 2023, epoch 194 048) et le type de transaction transportant des blobs dans Dencun (13 mars 2024, epoch 269 568). Voici le récit de la manière dont un petit groupe d’ingénieurs, profondément spécialisé et invariablement poli, a maintenu le client d’exécution dominant d’Ethereum en vie à travers trois des forks les plus conséquents de l’histoire du réseau.

Quand nous parlons de Geth, ce qui est en jeu est la centralisation d’une monoculture du layer d’exécution face à la part croissante des clients alternatifs — Nethermind, Besu, Erigon et le plus récent Reth. La part de Geth dans les nodes d’exécution a chuté d’un inquiétant 84 % au milieu de 2022 à environ 51 % au premier trimestre 2026, une diversification délibérée que les mainteneurs eux-mêmes ont encouragée publiquement. Cette baisse ne s’est pas produite parce que le groupe s’est fatigué. Elle s’est produite parce que le groupe, tout en déployant trois forks, a simultanément rendu le codebase assez lisible pour que les clients concurrents atteignent la parité fonctionnelle. L’historique qui suit est reconstruit à partir du journal de commits de go-ethereum, des notes de réunion ethereum/pm et d’une poignée de conversations avec des ingénieurs ayant participé aux appels all-core-devs.

Les mainteneurs, nommés

Le mainteneur principal de Geth depuis environ 2016 est Péter Szilágyi, un ingénieur hongrois dont le handle GitHub karalabe est attaché à une fraction significative des commits les plus architecturalement conséquents du codebase. Son travail sur le protocole Snap sync, sur le format de stockage des witnesses qui sous-tend la future transition Verkle, et sur le flux fast-sync qui a rendu Geth utilisable sur du matériel consommateur serait chacun un point culminant de carrière s’il était isolé. Avec lui pendant la majeure partie de cette période ont travaillé Felix Lange (fjl), responsable de la stack de réseau devp2p et de l’interface JSON-RPC ; Marius van der Wijden (MariusVanDerWijden), qui supervise le travail sur les faults de consensus et le fuzzing et qui était la figure technique de l’implémentation de The Merge ; et Sina Mahmoodi (s1na), qui a porté une grande partie de la spécification EVM et des discussions EOF ces dernières années.

L’Ethereum Foundation finance directement le groupe via son programme de bourses et salaires, avec des niveaux de financement que la Foundation a périodiquement divulgués dans ses rapports annuels. Le groupe opère avec un degré d’autonomie inhabituel : il n’y a pas de chef de projet formel, pas de document de roadmap, et pas de système de ticketing public autre que la page des issues GitHub. La coordination se fait sur l’appel all-core-devs execution — « ACDE » — tenu tous les deux Thursdays à 14:00 UTC et dirigé par Tim Beiko depuis 2021. Les notes de réunion pour chaque appel depuis 2017 sont publiques ; les lire dans l’ordre chronologique est l’élément le plus proche d’un registre documentaire de la manière dont les clients d’Ethereum décident réellement de quoi construire.

Fork un : The Merge

The Merge a exigé de Geth quelque chose qu’aucun client d’exécution n’avait fait auparavant : ne plus choisir sa propre chaîne canonique. La conception proof-of-stake a déplacé l’autorité de choix de fork entièrement vers le layer de consensus ; le travail de Geth s’est réduit à recevoir les messages fork_choice_updated et new_payload via l’Engine API et à exécuter ce qu’on lui disait. C’est structurellement plus simple que le modèle pré-Merge. C’est aussi une réécriture architecturale profonde, car toute l’hypothèse legacy que Geth gérait sa propre tête canonique était tissée dans le codebase. Les pull requests d’implémentation de merge dans le dépôt Geth sont un enseignement sur la manière de rétrofit un changement architectural fondamental sans briser les chemins de sync historiques.

Van der Wijden a assumé le rôle public lors du déploiement du testnet de Merge, guidant la communauté à travers les répétitions Goerli et Sepolia. Le travail interne a été divisé plus granularément : Szilágyi a réécrit le flux de sync pour accommoder les reorgs dirigés par le consensus ; Lange a refactorisé devp2p pour supporter le nouveau format de wire pour le type de transaction ; le cycle QA du groupe a duré neuf mois sur des shadow forks du mainnet, chacun répétant la transition avec un débit de transaction complet. Les notes all-core-devs de mai à août 2022 se lisent comme une checklist calmement exécutée précisément parce que le travail derrière elles avait été si méthodique.

Fork deux : Shanghai/Capella et la file de retrait

Shanghai était un fork plus petit sur le côté execution mais politiquement chargé : il a activé le mécanisme de retrait permettant aux ETH stakés de quitter la chaîne beacon pour la première fois. Le travail d’implémentation de Geth était concentré dans le nouveau type de transaction Withdrawal et la mise à jour correspondante du state-trie qui créditait les ETH retirés à l’adresse de retrait du validateur. L’EIP-4895 pertinent définissait le format de wire ; l’implémentation de Geth était largement le travail de Mariano Núñez et de l’implémentation parallèle du groupe Erigon, avec des tests cross-client via Hive — le bac de test multi-clients qui est devenu la fondation de la validation pré-déploiement de chaque fork.

Ce qui a rendu Shanghai facile sur le côté ingénierie était la discipline établie lors de Merge : chaque changement devait être déployé en lockstep avec au moins deux clients de consensus et passer la matrice de test Hive. Ce qui a rendu cela difficile sur le côté social était la file de sortie imminente. Le groupe avait passé dix-huit mois à écouter les validateurs s’inquiéter d’un « retrait cliff » le premier jour. Le cliff réel ne s’est pas produit — les sorties étaient gérées par la limite de churn du layer de consensus, pas par le layer d’exécution — mais la gestion des withdrawal-credentials de Geth devait être défendable contre chaque cas limite plausible. Les notes de release de v1.11.6 contiennent une discussion discrètement approfondie de ces cas limites qui vaut la lecture pour toute personne souhaitant voir comment les clients d’Ethereum expliquent leur travail entre eux.

Fork trois : Dencun et le type blob

Dencun était le plus grand effort d’ingénierie depuis Merge. L’EIP-4844 a introduit un type de transaction entièrement nouveau, une nouvelle structure de données (le blob), un nouveau schéma de engagement KZG, un nouveau chemin mempool et un nouveau sujet gossip pour la propagation des blobs. L’implémentation blob de Geth a requis simultanément l’expertise réseau de Szilágyi, le travail de format de wire de Lange et la vérification EVM de Mahmoodi. Le groupe a également dû coordonner avec les clients de consensus sur le travail de sampling de data-availability que l’EIP-4844 était conçu pour permettre dans les futurs forks. Les pull requests Dencun ont étalé sur neuf mois et produit un corps de code qui, selon les mainteneurs publiquement, a doublé la complexité du mempool de Geth.

Le schéma de engagement KZG mérite son propre paragraphe car il est l’unique pièce du codebase de Geth qui importe depuis c-kzg-4844, une bibliothèque C maintenue par le groupe de cryptographie de l’Ethereum Foundation. Intégrer une dépendance C dans un codebase Go est non-idiomatique ; les mainteneurs ont choisi de le faire car la surface de vérification de la cérémonie de trusted-setup était trop délicate cryptographiquement pour être réimplémentée en Go. Cette décision illustre le pragmatisme du groupe : ils franchiront les frontières de langage quand l’exactitude le demande, et ils paieront le taxe du système de build pour continuer à le faire en sécurité.

Le départ, la diversification, le prochain chapitre

En avril 2026, Szilágyi a annoncé sur X qu’il se retirait de la maintenance quotidienne de Geth pour se concentrer sur la transition Verkle et sur un projet de recherche plus long autour de la compression des witnesses de stockage. L’annonce a été accueillie, dans le petit coin de Crypto Twitter qui suit la politique des clients d’exécution, par le silence légèrement étourdi approprié à la transition d’un ingénieur principal de longue date. Van der Wijden a assumé une part plus grande du rôle public ; Lange a pris en charge les outils de build et de release ; de nouveaux contributeurs comme Felfele et une poignée d’ingénieurs du groupe Status Network ont pris des rôles lourds en revue. Le groupe est plus petit qu’il devrait être pour la surface qu’il couvre et recrute activement.

• Reth, le client d’exécution Rust dirigé par le groupe d’ingénierie de Paradigm, sert maintenant environ 9 % des nodes mainnet et est l’alternative la plus en croissance.
• Nethermind a été le client constant en deuxième place avec environ 22 % de part, avec une forte adoption parmi les stakers institutionnels.
• Besu et Erigon ensemble tiennent environ 18 % des nodes d’exécution ; les deux ont déployé Pectra en lockstep avec Geth.
• La transition Verkle, prévue pour le fork Osaka en 2027, sera le prochain test de stress de la coordination inter-clients.

Ce que ce groupe a bien fait et qui n’est pas dit assez

Les mainteneurs de Geth ont déployé trois forks sans un seul incident de consensus piloté par un client sur mainnet. Ils ont écrit des notes de release que d’autres clients pouvaient implémenter contre. Ils ont participé aux tests cross-client non comme une courtoisie mais comme une condition préalable au déploiement. Ils ont encouragé publiquement les utilisateurs à quitter Geth lorsque la concentration de part de client devenait un risque systémique. Ils ont documenté leur propre architecture suffisamment bien pour que les auteurs de Reth puissent écrire un client concurrent en lisant la spécification plutôt qu’en lisant le source de Geth. Ce dernier point est le plus important : un groupe d’infrastructure réussi est celui dont le travail rend son remplacement plus facile.

Les forks eux-mêmes — Merge, Shanghai/Capella, Dencun, Pectra — seront remembered comme des événements sociaux, avec les photos de chercheurs dans des salles de conférence et les tweets célébratoires. La contribution du groupe Geth ne se photographie pas bien. C’est plusieurs centaines de milliers de lignes de code Go soigneusement revu, un rythme de release ininterrompu à travers les transitions les plus architecturalement conséquentes de l’histoire de toute blockchain majeure, et un petit groupe d’ingénieurs qui ont répondu à chaque question sur chaque appel ACD sans jamais paraître fatigués. Pour toute personne tentant de comprendre comment l’infrastructure décentralisée est réellement construite et maintenue, ce registre vaut une lecture attentive. Notre calendrier d’événements suit l’appel ACD prochain, et notre tableau de marché inclut un panneau de part de client qui se met à jour chaque semaine.