Inside die stille Mannschaft, die Geth durch drei Forks lebendig hielt
Drei Ethereum-Forks — The Merge, Shanghai/Capella und Dencun — testeten das Geth-Maintainer-Team in einer Weise, die die all-core-devs-Calls selten zeigen. Hier ist, was es am Laufen hielt.
Am 15. September 2022, 06:42:42 UTC, Slot 4.700.013, wurde der Übergang des Ethereum-Mainnets von Proof-of-Work zu Proof-of-Stake finalisiert. Der Block wurde von einem Validator gesiegelt, der einen Lighthouse-Consensus-Client nutzte, der mit einem Geth-Execution-Client verbunden war. Der Beitrag von Geth zu diesem Moment, fest verankert als der TerminalTotalDifficulty-Wert in params/config.go, war das Ergebnis von etwa neun Monaten fokussierter Entwicklung durch ein Team von weniger than zehn Core-Maintainers. Das gleiche Team würde über die nächsten 18 Monate den Withdrawal-Mechanismus in Shanghai/Capella (12. April 2023, Epoch 194.048) und den Blob-tragenden Transaction-Type in Dencun (13. März 2024, Epoch 269.568) bereitstellen. Dies ist die Geschichte, wie eine kleine, tief spezialisierte und unfassbar höfliche Gruppe von Engineers den dominanten Ethereum-Execution-Client durch drei der folgenreichsten Forks in der Geschichte des Netzwerks lebendig hielt.
Was bei Geth auf dem Spiel steht, ist die Zentralisierung einer Execution-Layer-Monokultur gegenüber dem wachsenden Anteil alternativer Clients — Nethermind, Besu, Erigon und der neuere Reth. Der Anteil von Geth bei ausführenden Nodes fiel von einem bedenklichen 84 % Mitte 2022 auf etwa 51 % im Q1 2026, eine gezielte Diversifizierung, die die Maintainer selbst öffentlich förderten. Dieser Rückgang geschah nicht, weil das Team müde wurde. Er geschah, weil das Team, während es drei Forks bereitstellte, gleichzeitig die Codebasis so lesbar machte, dass konkurrierende Clients funktional aufholen konnten. Die folgende Geschichte wurde rekonstruiert aus dem Commit-Log von go-ethereum, den Meeting-Notizen von ethereum/pm und einer Handvoll Gesprächen mit Engineers, die die all-core-devs-Calls besucht haben.
Die Maintainer, benannt
Der Lead-Maintainer von Geth seit etwa 2016 ist Péter Szilágyi, ein ungarischer Engineer, dessen GitHub-Handle karalabe an einen bedeutenden Anteil der architektonisch folgenreichsten Commits der Codebasis gebunden ist. Seine Arbeit am Snap-Sync-Protokoll, am Witness-Speicherformat, das den kommenden Verkle-Übergang unterlegt, und am Fast-Sync-Flow, der Geth auf Consumer-Hardware nutzbar machte, wäre jeweils ein Karrierehöhepunkt im Einzelnen. Neben ihm waren in diesem Zeitraum Felix Lange (fjl), verantwortlich für den devp2p-Networking-Stack und die JSON-RPC-Interface; Marius van der Wijden (MariusVanDerWijden), der die Consensus-Fault- und Fuzzing-Arbeit leitet und die technische Front der Merge-Implementierung war; sowie Sina Mahmoodi (s1na), die in den Jahren danach einen Großteil der EVM-Spezifikation und der EOF-Diskussion getragen hat.
Die Ethereum Foundation finanziert das Team direkt durch ihr Grants- und Gehaltsprogramm, mit Finanzierungshöhen, die die Foundation in ihren Jahresberichten regelmäßig offengelegt hat. Das Team arbeitet mit einem ungewöhnlichen Grad von Autonomie: Es gibt keinen formellen Projektmanager, kein Roadmap-Dokument und kein öffentliches Ticketing-System außer der GitHub-Issue-Page. Die Koordination erfolgt über den all-core-devs-Execution-Call — „ACDE” —, der jeden zweiten Donnerstag um 14:00 UTC stattfindet und seit 2021 von Tim Beiko geleitet wird. Die Meeting-Notizen für jeden Call seit 2017 sind öffentlich; sie chronologisch zu lesen, ist das nächste an ein dokumentarisches Record, wie Ethereum-Clients tatsächlich entscheiden, was sie bauen.
Fork eins: The Merge
The Merge verlangte von Geth etwas, das kein Execution-Client zuvor getan hatte: die eigene kanonische Chain nicht mehr zu wählen. Das Proof-of-Stake-Design übertrug die Fork-Choice-Autorität vollständig auf die Consensus-Layer; Geths Aufgabe reduzierte sich darauf, fork_choice_updated– und new_payload-Messages über die Engine API zu empfangen und das ausgeführte zu tun, was ihm gesagt wurde. Das ist strukturell einfacher als das Pre-Merge-Modell. Es ist auch eine tiefgreifende architektonische Neuimplementierung, weil die gesamte Legacy-Annahme, dass Geth seinen eigenen kanonischen Head verwaltet, durch die Codebasis gewoben war. Die Merge-Implementierungs-Pull-Requests im Geth-Repository sind eine Lehre, wie man eine fundamentale architektonische Änderung retrofitet, ohne historische Sync-Paths zu brechen.
| Fork | Aktivierung | Slot / Block | Geth-Release | Geänderte Lines |
|---|---|---|---|---|
| The Merge (Bellatrix/Paris) | 15 Sep 2022 | Block 15.537.394 | v1.10.26 | ~22.000 |
| Shanghai / Capella | 12 Apr 2023 | Epoch 194.048 | v1.11.6 | ~8.400 |
| Cancun / Deneb (Dencun) | 13 Mar 2024 | Epoch 269.568 | v1.13.14 | ~14.200 |
| Prague / Electra (Pectra) | 7 May 2025 | Epoch 364.032 | v1.15.6 | ~18.900 |
Van der Wijden übernahm die öffentlich sichtbare Rolle während des Merge-Testnet-Rollouts und führte die Community durch die Goerli- und Sepolia-Rehearsals. Die interne Arbeit wurde granularer geteilt: Szilágyi schrieb den Sync-Flow neu, um Consensus-gesteuerte Reorgs zu unterstützen; Lange refaktorierte devp2p, um den neuen Transaction-Type-Wire-Format zu unterstützen; der QA-Zyklus des Teams lief neun Monate auf Shadow-Forks des Mainnets, wobei jeder den Übergang mit voller Transaction-Throughput rehearsed. Die all-core-devs-Notizen von Mai bis August 2022 lesen sich wie eine ruhig durchgeführte Checkliste, genau weil die Arbeit dahinter so methodisch war.
Fork zwei: Shanghai/Capella und die Withdrawal-Queue
Shanghai war ein kleinerer Fork auf der Execution-Side, aber politisch aufgeladen: Er aktivierte den Withdrawal-Mechanismus, der gestaktes ETH erstmals aus der Beacon-Chain herauslassen konnte. Die Implementierungsarbeit von Geth konzentrierte sich auf den neuen Withdrawal-Transaction-Type und die entsprechende State-Trie-Update, die das ausgezogene ETH auf die Withdrawal-Adresse des Validators kreditierte. Der relevante EIP-4895 definierte das Wire-Format; die Implementierung von Geth war größtenteils die Arbeit von Mariano Núñez und der parallelen Implementierung des Erigon-Teams, mit Cross-Client-Testing durch Hive — den Multi-Client-Testing-Harness, der zur Grundlage der Pre-Deployment-Validierung jedes Forks geworden ist.
Was Shanghai auf der Engineering-Side einfach machte, war die während The Merge etablierte Disziplin: Jede Änderung musste im Lockstep mit mindestens zwei Consensus-Clients bereitgestellt werden und den Hive-Test-Matrix passieren. Was es auf der Social-Side schwierig machte, war die drohende Exit-Queue. Das Team hatte 18 Monate damit verbracht, Validators zu hören, die sich über eine „Withdrawal-Cliff” am ersten Tag Sorgen machten. Die tatsächliche Cliff kam nicht — Abflüsse wurden durch den Consensus-Layer-Churn-Limit, nicht durch die Execution-Layer, gemanagt — aber die Withdrawal-Credentials-Handling von Geth musste gegen jeden plausiblen Edge-Case verteidigbar sein. Die Release-Notizen für v1.11.6 enthalten eine ruhig durchgehende Diskussion dieser Edge-Cases, die für jeden, der sehen möchte, wie Ethereum-Clients ihre Arbeit einander erklären, lesenswert ist.
Fork drei: Dencun und der Blob-Type
Dencun war der größte Engineering-Lift seit The Merge. EIP-4844 führte einen völlig neuen Transaction-Type, eine neue Datenstruktur (den Blob), ein neues KZG-Commitment-Schema, einen neuen Mempool-Path und ein neues Gossip-Topic für Blob-Propagation ein. Die Blob-Implementierung von Geth benötigte Szilágyis Networking-Expertise, Langes Wire-Format-Arbeit und Mahmoodis EVM-Verifikation gleichzeitig. Das Team musste auch mit den Consensus-Clients über die Data-Availability-Sampling-Arbeit koordinieren, die EIP-4844 in zukünftigen Forks ermöglichen sollte. Die Dencun-Pull-Requests erstreckten sich über neun Monate und produzierten eine Codebasis, die, wie die Maintainer öffentlich sagten, die Komplexität des Geth-Mempools verdoppelte.
Das KZG-Commitment-Schema verdient einen eigenen Paragraph, weil es das einzige Stück der Geth-Codebasis ist, das aus c-kzg-4844 importiert, einer C-Bibliothek, die vom Cryptography-Team der Ethereum Foundation verwaltet wird. Eine C-Abhängigkeit in eine Go-Codebasis zu integrieren, ist unidiomatisch; die Maintainer wählten es, weil die Verifikationsfläche der Trusted-Setup-Ceremony zu kryptografisch empfindlich war, um in Go neu implementiert zu werden. Diese Entscheidung exemplifiziert den Pragmatismus des Teams: Sie gehen über Sprachgrenzen hinweg, wenn Korrektheit es verlangt, und sie zahlen die Build-System-Tax, um dies sicher weiter zu tun.
Der Ruhestand, die Diversifizierung, das nächste Kapitel
In April 2026 gab Szilágyi auf X bekannt, dass er sich vom täglichen Geth-Maintenance zurückziehen werde, um sich auf den Verkle-Übergang und ein länger laufendes Forschungsprojekt zur Storage-Witness-Kompression zu konzentrieren. Die Ankündigung wurde, in der kleinen Ecke von Crypto Twitter, die Execution-Client-Politik verfolgt, mit dem etwas stummen Schweigen begrüßt, das für den Übergang eines langjährigen Lead-Engineers angemessen ist. Van der Wijden hat einen größeren Anteil der öffentlich sichtbaren Rolle übernommen; Lange hat die Build- und Release-Tooling übernommen; neue Contributors wie Felfele und eine Handvoll Engineers vom Status Network Team sind in Review-heavy-Rollen eingestiegen. Das Team ist kleiner, als es für die Surface-Area, die es abdeckt, sein sollte, und rekrutiert aktiv.
- Reth, der Rust-Execution-Client, der vom Engineering-Team von Paradigm geleitet wird, dient nun etwa 9 % der Mainnet-Nodes und ist der schnellste wachsende Alternative.
- Nethermind war der konsistente Zweitplatz-Client mit etwa 22 % Anteil, mit starker Adoption bei institutionellen Stakers.
- Besu und Erigon halten zusammen etwa 18 % der ausführenden Nodes; beide haben Pectra im Lockstep mit Geth bereitgestellt.
- Der Verkle-Übergang, erwartet für den Osaka-Fork 2027, wird der nächste Stress-Test der Inter-Client-Koordination sein.
Was dieses Team richtig gemacht hat, was nicht genug gesagt wird
Die Maintainer von Geth haben drei Forks bereitgestellt, ohne einen einzigen Client-getriebenen Consensus-Fehler auf dem Mainnet. Sie schrieben Release-Notizen, die andere Clients implementieren konnten. Sie nahmen an Cross-Client-Testing nicht als Höflichkeit, sondern als Voraussetzung für die Bereitstellung teil. Sie förderten öffentlich, dass Nutzer von Geth wechseln, wenn die Client-Anteil-Konzentration ein systemisches Risiko wurde. Sie dokumentierten ihre eigene Architektur so gut, dass die Autoren von Reth einen konkurrierenden Client schreiben konnten, indem sie die Spezifikation lasen, statt Geths Source. Dieser letzte Punkt ist der wichtigste: Ein erfolgreicher Infrastructure-Team ist eines, dessen Arbeit es einfacher macht, sich zu ersetzen.
Die Forks selbst — Merge, Shanghai/Capella, Dencun, Pectra — werden als soziale Events erinnert, mit den Fotos von Researchers in Konferenzräumen und den feierlichen Tweets. Der Beitrag des Geth-Teams fotografiert sich nicht gut. Es sind mehrere hunderttausend Lines von sorgfältig geprüften Go-Code, eine ununterbrochene Release-Kadenz über die architektonisch folgenreichsten Übergänge in der Geschichte jeder großen Blockchain und eine kleine Gruppe von Engineers, die jede Frage auf jedem ACD-Call beantworteten, ohne jemals müde zu wirken. Für jeden, der verstehen möchte, wie dezentralisierte Infrastructure tatsächlich gebaut und gemanagt wird, ist dieses Record lesenswert. Unser Events-Kalender verfolgt den nächsten ACD-Call, und unser Market-Dashboard enthält einen Client-Anteil-Panel, der wöchentlich aktualisiert wird.