In der stillen Team, das 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 Transaktionstyp in Dencun (13. März 2024, Epoch 269.568) bereitstellen. Dies ist die Geschichte, wie eine kleine, tief spezialisierte und stets freundliche Gruppe von Engineers den dominanten Ethereum-Execution-Client durch drei der wichtigsten Forks in der Geschichte des Netzwerks lebendig hielt.
Was bei der Diskussion über 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 Maintainers 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 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 besuchten, rekonstruiert.
Die Maintainers, benannt
Der leitende Maintainer von Geth seit etwa 2016 ist Péter Szilágyi, ein ungarischer Engineer, dessen GitHub-Handle karalabe an einen bedeutenden Anteil der Codebasis mit den architektonisch wichtigsten Commits gekoppelt ist. Seine Arbeit am Snap-Sync-Protokoll, am Witness-Speicherformat, das die kommende Verkle-Transition 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-Netzwerkstack und die JSON-RPC-Schnittstelle; Marius van der Wijden (MariusVanDerWijden), der die Consensus-Fault- und Fuzzing-Arbeit leitet und die technische Front der Merge-Implementierung war; und 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 an 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, 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 verwaltete, durch die Codebasis gewoben war. Die Merge-Implementierungs-Pull-Requests im Geth-Repository sind eine Lehre, wie man eine fundamentale architektonische Änderung ohne Brechung historischer Sync-Paths retrofitieren kann.
| 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 nahm während des Merge-Testnet-Rollouts die öffentlich sichtbare Rolle ein und führte die Community durch die Goerli- und Sepolia-Rehearsals. Die interne Arbeit war granularer verteilt: Szilágyi schrieb den Sync-Flow neu, um Consensus-gesteuerte Reorgs zu unterstützen; Lange refaktorierte devp2p, um den neuen Transaktionstyp-Wire-Format zu unterstützen; der QA-Zyklus des Teams lief neun Monate auf Shadow-Forks des Mainnets, wobei jeder die Transition mit voller Transaktionsdurchsatz rehearsal. 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. Geths Implementierungsarbeit konzentrierte sich auf den neuen Withdrawal-Transaktionstyp und die entsprechende State-Trie-Aktualisierung, die das ausgezogene ETH auf die Withdrawal-Adresse des Validators kreditierte. Der relevante EIP-4895 definierte das Wire-Format; Geths Implementierung war größtenteils die Arbeit von Mariano Núñez und der parallelen Implementierung des Erigon-Teams, mit Cross-Client-Testing durch Hive — dem 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 die Hive-Testmatrix passieren. Was es auf der sozialen Seite 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 trat nicht ein — Abflüsse wurden durch den Consensus-Layer-Churn-Limit, nicht durch die Execution-Layer, gemanagt — aber Geths Behandlung der Withdrawal-Credentials 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-Typ
Dencun war der größte Engineering-Lift seit The Merge. EIP-4844 führte einen völlig neuen Transaktionstyp, eine neue Datenstruktur (den Blob), ein neues KZG-Commitment-Schema, einen neuen Mempool-Path und ein neues Gossip-Topic für Blob-Propagation ein. Geths Blob-Implementierung benötigte Szilágyis Netzwerkexpertise, 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 einen Codekörper, der, wie die Maintainers öffentlich sagten, die Komplexität von Geths Mempool verdoppelte.
Das KZG-Commitment-Schema verdient einen eigenen Absatz, weil es der einzige Teil von Geths Codebasis ist, der aus c-kzg-4844 importiert, einer C-Bibliothek, die vom Kryptographie-Team der Ethereum Foundation verwaltet wird. Eine C-Abhängigkeit in eine Go-Codebasis zu integrieren, ist unidiomatisch; die Maintainers wählten dies, 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 die Verkle-Transition und ein länger laufendes Forschungsprojekt zur Storage-Witness-Kompression zu konzentrieren. Die Ankündigung wurde in der kleinen Ecke von Crypto Twitter, die die Politics der Execution-Clients verfolgt, mit dem leicht stummen Schweigen begrüßt, das für die Transition eines langjährigen leitenden 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 Fläche, die es abdeckt, sein sollte, und rekrutiert aktiv.
- Reth, der Rust-Execution-Client, der von Paradigms Engineering-Team geleitet wird, dient nun etwa 9 % der Mainnet-Nodes und ist der schnellste wachsende Alternative.
- Nethermind war der konsistente zweitplatzierte 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.
- Die Verkle-Transition, erwartet für den Osaka-Fork 2027, wird der nächste Stresstest der Inter-Client-Koordination sein.
Was dieses Team richtig gemacht hat, was nicht oft genug gesagt wird
Geths Maintainers lieferten drei Forks 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 abwechselten, wenn die Client-Anteil-Konzentration ein systemisches Risiko wurde. Sie dokumentierten ihre eigene Architektur so gut, dass Reths Autoren einen konkurrierenden Client schreiben konnten, indem sie die Spezifikation lasen, nicht Geths Source. Dieser letzte Punkt ist der wichtigste: Ein erfolgreiches Infrastruktur-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 Fotos von Researchers in Konferenzräumen und feierlichen Tweets. Geth-Teams Beitrag fotografiert sich nicht gut. Es sind mehrere hunderttausend Lines sorgfältig geprüften Go-Code, eine ununterbrochene Release-Kadenz über die architektonisch wichtigsten Transitionen 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 erscheinen. Für jeden, der verstehen möchte, wie dezentralisierte Infrastruktur 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 ein Client-Anteil-Panel, das wöchentlich aktualisiert wird.