Dentro il team silenzioso che ha mantenuto vivo Geth attraverso tre fork
Tre fork di Ethereum — The Merge, Shanghai/Capella e Dencun — hanno messo alla prova il team di manutenzione di Geth in modi che le chiamate all-core-devs raramente mostrano. Ecco ciò che ha permesso al progetto di continuare a evolversi.
Il 15 settembre 2022, alle 06:42:42 UTC, lo slot 4.700.013 ha finalizzato la transizione della mainnet di Ethereum dal proof-of-work al proof-of-stake. Il blocco è stato sigillato da un validator che eseguiva un client di consenso Lighthouse collegato a un client di esecuzione Geth. Il contributo di Geth a quel momento, hard-coded come il valore TerminalTotalDifficulty in params/config.go, è il prodotto di circa nove mesi di ingegneria focalizzata da un team di meno di dieci maintainer core. Lo stesso team, nei successivi diciotto mesi, ha implementato il meccanismo di withdrawal in Shanghai/Capella (12 aprile 2023, epoch 194.048) e il tipo di transazione blob-carrying in Dencun (13 marzo 2024, epoch 269.568). Questa è la storia di come un piccolo gruppo di ingegneri, profondamente specializzato e infallibilmente gentile, ha mantenuto vivo il client di esecuzione Ethereum dominante attraverso tre delle fork più consequenziali nella storia della rete.
Cosa è in gioco quando parliamo di Geth è la centralizzazione di una monocultura del layer di esecuzione contro la crescente quota di client alternativi — Nethermind, Besu, Erigon e il più recente Reth. La quota di Geth tra i nodi di esecuzione è scesa da un preoccupante 84% a metà 2022 a circa 51% nel primo trimestre 2026, una diversificazione deliberata che i maintainer stessi hanno pubblicamente incoraggiato. Questo calo non è avvenuto perché il team si è stancato. È avvenuto perché il team, mentre implementava tre fork, ha reso simultaneamente il codicebase abbastanza leggibile per permettere ai client concorrenti di raggiungere la parità funzionale. La storia che segue è ricostruita dal commit log di go-ethereum, dalle note delle meeting ethereum/pm e da alcune conversazioni con ingegneri che hanno partecipato alle chiamate all-core-devs.
I maintainer, nominati
Il maintainer lead di Geth da circa 2016 è Péter Szilágyi, un ingegnere ungherese il cui handle GitHub karalabe è associato a una frazione significativa dei commit più consequenziali a livello architetturale del codicebase. Il suo lavoro sul protocollo Snap sync, sul formato di storage witness che sottende la futura transizione Verkle e sul flusso fast-sync che ha reso Geth utilizzabile su hardware consumer sarebbe ciascuno un punto alto della carriera se considerato isolatamente. Accanto a lui per gran parte di quel periodo sono stati Felix Lange (fjl), responsabile dello stack di networking devp2p e dell’interfaccia JSON-RPC; Marius van der Wijden (MariusVanDerWijden), che gestisce il lavoro su fault di consenso e fuzzing ed è la figura tecnica dell’implementazione di The Merge; e Sina Mahmoodi (s1na), che ha portato avanti gran parte della discussione sulla specifica EVM e EOF negli anni successivi.
Ethereum Foundation finanzia il team direttamente attraverso il suo programma di grants e salari, con livelli di finanziamento che la foundation ha periodicamente disclosed nei suoi report annuali. Il team opera con un grado insolito di autonomia: non c’è un project manager formale, nessun documento di roadmap e nessun sistema di ticketing pubblico oltre alla pagina delle issue GitHub. La coordinazione avviene sulla chiamata all-core-devs execution — “ACDE” — tenuta ogni due giovedì alle 14:00 UTC e guidata da Tim Beiko da 2021. Le note delle meeting per ogni chiamata dal 2017 sono pubbliche; leggerle in ordine cronologico è l’cosa più vicina a un record documentale di come i client di Ethereum decidono effettivamente cosa costruire.
Fork uno: The Merge
The Merge ha richiesto a Geth di fare qualcosa che nessun client di esecuzione aveva mai fatto prima: smettere di scegliere la propria catena canonica. Il design proof-of-stake ha spostato l’autorità di fork-choice interamente al layer di consenso; il lavoro di Geth è stato ridotto a ricevere i messaggi fork_choice_updated e new_payload tramite l’Engine API e eseguire ciò che veniva detto. Questo è strutturalmente più semplice del modello pre-Merge. È anche una profonda riscrittura architetturale, perché tutta l’assunzione legacy che Geth gestisse il proprio head canonico era intrecciata nel codicebase. Le pull request di implementazione del merge nel repository di Geth sono un’educazione su come retrofittare un cambiamento architetturale fondamentale senza rompere i percorsi di sync storici.
| Fork | Activation | Slot / block | Geth release | Lines changed |
|---|---|---|---|---|
| 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 ha assunto il ruolo pubblico durante il rollout del testnet di The Merge, guidando la community attraverso le prove su Goerli e Sepolia. Il lavoro interno è stato diviso più granularmente: Szilágyi ha riscritto il flusso di sync per adattarsi ai reorg diretti dal consenso; Lange ha refattorizzato devp2p per supportare il nuovo formato wire del tipo di transazione; il ciclo QA del team è durato nove mesi su shadow forks della mainnet, ciascuna che riproponeva la transizione con pieno throughput di transazioni. Le note all-core-devs da maggio ad agosto 2022 sembrano un elenco di controllo eseguito con calma precisamente perché il lavoro dietro era stato così metodico.
Fork due: Shanghai/Capella e la coda di withdrawal
Shanghai è stata una fork più piccola sul lato execution ma politicamente carica: ha attivato il meccanismo di withdrawal che ha permesso per la prima volta agli ETH staked di uscire dalla beacon chain. Il lavoro di implementazione di Geth è stato concentrato nel nuovo tipo di transazione Withdrawal e nell’aggiornamento corrispondente dello state-trie che ha creditato gli ETH withdrawn all’indirizzo di withdrawal del validator. Il relativo EIP-4895 ha definito il formato wire; l’implementazione di Geth è stata in gran parte il lavoro di Mariano Núñez e dell’implementazione parallela del team Erigon, con testing cross-client tramite Hive — l’harness di testing multi-client che è diventato la base della validazione pre-deployment di ogni fork.
Cosa ha reso Shanghai facile sul lato ingegneristico è la disciplina stabilita durante The Merge: ogni cambiamento doveva essere implementato in lockstep con almeno due client di consenso e passare la matrice di test Hive. Cosa ha reso difficile sul lato sociale è la coda di exit imminente. Il team ha dedicato diciotto mesi a ascoltare i validator preoccupati per un “withdrawal cliff” al primo giorno. Il cliff reale non è arrivato — le outflows sono gestite dal limite di churn del layer di consenso, non dal layer di execution — ma la gestione delle withdrawal-credentials di Geth doveva essere difendibile contro ogni caso limite plausibile. Le note di release di v1.11.6 contengono una discussione silenziosamente approfondita di quei casi limite che vale la pena leggere per chiunque vuole vedere come i client di Ethereum spiegano il loro lavoro tra loro.
Fork tre: Dencun e il tipo blob
Dencun è stata la più grande sfida ingegneristica da The Merge. EIP-4844 ha introdotto un nuovo tipo di transazione, una nuova struttura dati (il blob), un nuovo schema di commitment KZG, un nuovo percorso mempool e un nuovo topic gossip per la propagazione del blob. L’implementazione blob di Geth ha richiesto simultaneamente l’expertise di networking di Szilágyi, il lavoro sul formato wire di Lange e la verifica EVM di Mahmoodi. Il team ha anche dovuto coordinarsi con i client di consenso sul lavoro di sampling della data-availability che EIP-4844 era progettato per permettere nelle future fork. Le pull request di Dencun si sono estese per nove mesi e hanno prodotto un corpo di codice che, come i maintainer hanno detto pubblicamente, ha duplicato la complessità del mempool di Geth.
Lo schema di commitment KZG merita un proprio paragrafo perché è l’unico pezzo del codicebase di Geth che importa da c-kzg-4844, una libreria C mantenuta dal team di crittografia di Ethereum Foundation. Integrare una dipendenza C in un codicebase Go è non-idiomatico; i maintainer hanno scelto di farlo perché la superficie di verifica della cerimonia trusted-setup era troppo delicata a livello crittografico per essere reimplementata in Go. Questa decisione esemplifica il pragmatismo del team: attraverseranno i confini linguistici quando la correttezza lo richiede e pagheranno il tax del build-system per continuare a farlo in sicurezza.
Il retirement, la diversificazione, il prossimo capitolo
Aprile 2026, Szilágyi ha annunciato su X che si stava ritirando dalla manutenzione quotidiana di Geth per concentrarsi sulla transizione Verkle e su un progetto di ricerca più lungo intorno alla compressione storage-witness. L’annuncio è stato accolto, nel piccolo angolo di Crypto Twitter che segue la politica dei client di execution, con il silenzio leggermente stordito appropriato alla transizione di un ingegnere lead di lungo corso. Van der Wijden ha assunto una quota maggiore del ruolo pubblico; Lange ha preso in carico il tooling di build e release; nuovi contributori come Felfele e un gruppo di ingegneri dal team Status Network sono entrati in ruoli pesanti di review. Il team è più piccolo di quanto dovrebbe essere per la superficie che copre e sta attivamente reclutando.
- Reth, il client di execution Rust guidato dal team di ingegneria di Paradigm, ora serve circa 9% dei nodi mainnet e è l’alternativa in più rapida crescita.
- Nethermind è stato il client costante secondo posto con circa 22% di quota, con forte adoption tra gli stakers istituzionali.
- Besu e Erigon insieme detengono circa 18% dei nodi di execution; entrambi hanno implementato Pectra in lockstep con Geth.
- La transizione Verkle, prevista per la fork Osaka in 2027, sarà il prossimo test di stress della coordinazione inter-client.
Cosa questo team ha fatto bene che non viene detto abbastanza
I maintainer di Geth hanno implementato tre fork senza un singolo fallimento di consenso causato da client sulla mainnet. Hanno scritto note di release che altri client potevano implementare. Hanno partecipato al testing cross-client non come cortesia ma come prerequisito per l’implementazione. Hanno pubblicamente incoraggiato gli utenti a passare da Geth quando la concentrazione della quota dei client diventava un rischio sistemico. Hanno documentato bene la propria architettura abbastanza per permettere agli autori di Reth di scrivere un client concorrente leggendo la specifica piuttosto che leggendo il source di Geth. Questo ultimo punto è il più importante: un team di infrastruttura di successo è uno che rende il proprio lavoro più facile da sostituire.
Le fork stesse — Merge, Shanghai/Capella, Dencun, Pectra — saranno ricordate come eventi sociali, con le foto di ricercatori in sale conferenze e i tweet celebrativi. Il contributo del team di Geth non si fotografa bene. È centinaia di migliaia di linee di codice Go attentamente revisionato, un cadenza di release ininterrotta attraverso le transizioni più consequenziali a livello architetturale in qualsiasi storia di blockchain principale, e un piccolo gruppo di ingegneri che ha risposto a ogni domanda su ogni chiamata ACD senza mai sembrare stanco. Per chiunque cerca di capire come l’infrastruttura decentralizzata viene effettivamente costruita e mantenuta, questo record vale la pena di essere letto attentamente. Il nostro calendario eventi traccia la prossima chiamata ACD e il nostro dashboard mercato include un pannello quota client che si aggiorna settimanalmente.