{"id":30,"date":"2026-06-25T13:19:22","date_gmt":"2026-06-25T13:19:22","guid":{"rendered":"https:\/\/hoge.gg\/it\/inside-the-quiet-team-that-kept-geth-alive-through-three-forks\/"},"modified":"2026-06-25T13:19:22","modified_gmt":"2026-06-25T13:19:22","slug":"inside-the-quiet-team-that-kept-geth-alive-through-three-forks","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/inside-the-quiet-team-that-kept-geth-alive-through-three-forks\/","title":{"rendered":"Dentro il team silenzioso che ha mantenuto vivo Geth attraverso tre fork"},"content":{"rendered":"\r\n

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 \u00e8 stato sigillato da un validator che eseguiva un client di consenso Lighthouse collegato a un client di esecuzione Geth<\/a>. Il contributo di Geth a quel momento, hard-coded come il valore TerminalTotalDifficulty<\/code> in params\/config.go<\/code>, \u00e8 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 \u00e8 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\u00f9 consequenziali nella storia della rete.<\/p>\r\n\r\n\r\n\r\n

Cosa \u00e8 in gioco quando parliamo di Geth \u00e8 la centralizzazione di una monocultura del layer di esecuzione contro la crescente quota di client alternativi — Nethermind, Besu, Erigon e il pi\u00f9 recente Reth. La quota di Geth tra i nodi di esecuzione \u00e8 scesa da un preoccupante 84% a met\u00e0 2022 a circa 51% nel primo trimestre 2026, una diversificazione deliberata che i maintainer stessi hanno pubblicamente incoraggiato. Questo calo non \u00e8 avvenuto perch\u00e9 il team si \u00e8 stancato. \u00c8 avvenuto perch\u00e9 il team, mentre implementava tre fork, ha reso simultaneamente il codicebase abbastanza leggibile per permettere ai client concorrenti di raggiungere la parit\u00e0 funzionale. La storia che segue \u00e8 ricostruita dal commit log di go-ethereum<\/a>, dalle note delle meeting ethereum\/pm<\/a> e da alcune conversazioni con ingegneri che hanno partecipato alle chiamate all-core-devs.<\/p>\r\n\r\n\r\n\r\n

I maintainer, nominati<\/h2>\r\n\r\n\r\n\r\n

Il maintainer lead di Geth da circa 2016 \u00e8 Péter Szilágyi, un ingegnere ungherese il cui handle GitHub karalabe<\/code> \u00e8 associato a una frazione significativa dei commit pi\u00f9 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<\/code>), responsabile dello stack di networking devp2p e dell’interfaccia JSON-RPC; Marius van der Wijden (MariusVanDerWijden<\/code>), che gestisce il lavoro su fault di consenso e fuzzing ed \u00e8 la figura tecnica dell’implementazione di The Merge; e Sina Mahmoodi (s1na<\/code>), che ha portato avanti gran parte della discussione sulla specifica EVM e EOF negli anni successivi.<\/p>\r\n\r\n\r\n\r\n

Ethereum Foundation finanzia il team direttamente attraverso il suo programma di grants e salari<\/a>, 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’\u00e8 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\u00ec 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 \u00e8 l’cosa pi\u00f9 vicina a un record documentale di come i client di Ethereum decidono effettivamente cosa costruire.<\/p>\r\n\r\n\r\n\r\n

Fork uno: The Merge<\/h2>\r\n\r\n\r\n\r\n

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\u00e0 di fork-choice interamente al layer di consenso; il lavoro di Geth \u00e8 stato ridotto a ricevere i messaggi fork_choice_updated<\/code> e new_payload<\/code> tramite l’Engine API<\/a> e eseguire ci\u00f2 che veniva detto. Questo \u00e8 strutturalmente pi\u00f9 semplice del modello pre-Merge. \u00c8 anche una profonda riscrittura architetturale, perch\u00e9 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.<\/p>\r\n\r\n\r\n\r\n

Fork<\/th>Activation<\/th>Slot \/ block<\/th>Geth release<\/th>Lines changed<\/th><\/tr><\/thead>
The Merge (Bellatrix\/Paris)<\/td>15 Sep 2022<\/td>Block 15.537.394<\/td>v1.10.26<\/td>~22.000<\/td><\/tr>
Shanghai \/ Capella<\/td>12 Apr 2023<\/td>Epoch 194.048<\/td>v1.11.6<\/td>~8.400<\/td><\/tr>
Cancun \/ Deneb (Dencun)<\/td>13 Mar 2024<\/td>Epoch 269.568<\/td>v1.13.14<\/td>~14.200<\/td><\/tr>
Prague \/ Electra (Pectra)<\/td>7 May 2025<\/td>Epoch 364.032<\/td>v1.15.6<\/td>~18.900<\/td><\/tr><\/tbody><\/table>
Release di Geth legata a ogni fork di consenso. Fonte: github.com\/ethereum\/go-ethereum, ethereum.org.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

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 \u00e8 stato diviso pi\u00f9 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 \u00e8 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\u00e9 il lavoro dietro era stato cos\u00ec metodico.<\/p>\r\n\r\n\r\n\r\n

Fork due: Shanghai\/Capella e la coda di withdrawal<\/h2>\r\n\r\n\r\n\r\n

Shanghai \u00e8 stata una fork pi\u00f9 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 \u00e8 stato concentrato nel nuovo tipo di transazione Withdrawal<\/code> e nell’aggiornamento corrispondente dello state-trie che ha creditato gli ETH withdrawn all’indirizzo di withdrawal del validator. Il relativo EIP-4895<\/a> ha definito il formato wire; l’implementazione di Geth \u00e8 stata in gran parte il lavoro di Mariano Núñez e dell’implementazione parallela del team Erigon, con testing cross-client tramite Hive<\/a> — l’harness di testing multi-client che \u00e8 diventato la base della validazione pre-deployment di ogni fork.<\/p>\r\n\r\n\r\n\r\n

Cosa ha reso Shanghai facile sul lato ingegneristico \u00e8 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 \u00e8 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 \u00e8 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.<\/p>\r\n\r\n\r\n\r\n

Fork tre: Dencun e il tipo blob<\/h2>\r\n\r\n\r\n\r\n

Dencun \u00e8 stata la pi\u00f9 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\u00e0 del mempool di Geth.<\/p>\r\n\r\n\r\n\r\n

Lo schema di commitment KZG merita un proprio paragrafo perch\u00e9 \u00e8 l’unico pezzo del codicebase di Geth che importa da c-kzg-4844<\/a>, una libreria C mantenuta dal team di crittografia di Ethereum Foundation. Integrare una dipendenza C in un codicebase Go \u00e8 non-idiomatico; i maintainer hanno scelto di farlo perch\u00e9 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.<\/p>\r\n\r\n\r\n\r\n

Il retirement, la diversificazione, il prossimo capitolo<\/h2>\r\n\r\n\r\n\r\n

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\u00f9 lungo intorno alla compressione storage-witness. L’annuncio \u00e8 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 \u00e8 pi\u00f9 piccolo di quanto dovrebbe essere per la superficie che copre e sta attivamente reclutando.<\/p>\r\n\r\n\r\n\r\n