Spiegazione della governance di base di Ethereum

Una presentazione di Nixo Rokish della Fondazione Ethereum a ETHBoulder, che spiega la governance del protocollo di base di Ethereum, come vengono coordinati gli hard fork, le idee sbagliate comuni su chi controlla Ethereum e come partecipare al processo di governance.

Questa trascrizione è una copia accessibile della trascrizione originale del video (opens in a new tab) pubblicata da EthBoulder. È stata leggermente modificata per facilitarne la lettura.

Introduzione (0:12)

Grazie a tutti e sei i miei amici che si sono presentati. Va bene. Oggi vi parlo della governance di base di Ethereum. Mi chiamo Nixo. Guido il team di supporto al protocollo presso la Fondazione Ethereum (EF). Tra tutti i nostri mandati, uno è quello di rendere il processo di governance più chiaro e facile da navigare per tutti gli altri che partecipano a queste cose, perché Ethereum include molto di più dei soli sviluppatori principali (core developer).

Ecco quindi una panoramica dell'intervento. Parleremo di cos'è la governance di base. Parleremo delle idee sbagliate, di come funziona attualmente la governance di Ethereum. Accenneremo a come si confronta con altri sistemi di governance decentralizzata, al motivo per cui i costruttori (builder) dovrebbero interessarsene e ai percorsi pratici per la partecipazione.

Quindi, cos'è la governance del protocollo di base? Io gestisco un nodo. Questo significa che ho un pezzo di hardware, un computer a casa mia dove eseguo il software di Ethereum. Quando ho configurato questo software di Ethereum, ho dovuto scegliere i client che avrebbero eseguito quel software. Ethereum è piuttosto unico in quanto ha più client per la diversità dei client. Il punto è che se un client si blocca, se c'è un bug in un client, l'intera rete non si ferma. Ci sono altre blockchain che hanno altri client. Tuttavia, Ethereum è l'unica configurata in modo da proteggerci effettivamente dai bug. Quindi, se guardate a Solana, Solana ha un altro client, credo si chiami GTO, ma ha solo il 20-21% di adozione. Quindi, se il client di maggioranza si blocca, la catena si ferma. E abbiamo visto altre reti fermarsi. Ed è per questo che Ethereum è la blockchain più resiliente e sicura.

Quindi la domanda diventa: come si introducono modifiche in Ethereum quando ci si deve coordinare con così tanti client diversi? Innanzitutto faremo una distinzione tra un hard fork e un soft fork. Un soft fork non richiede il coordinamento di un hard fork. Ethereum funziona principalmente con gli hard fork. Quindi, cos'è un hard fork? Fondamentalmente, tutti i client creano una nuova versione di Ethereum e decidono in un momento preconfigurato di lanciare questa nuova versione di Ethereum. È sempre Ethereum, ma ha nuove funzionalità. Ha caratteristiche diverse. E tutti gli operatori di nodi come me, che gestiscono nodi a casa, o gli operatori professionali, devono adottare quella nuova versione di Ethereum. Devono aggiornare il proprio nodo o aggiornare i propri nodi per includere quel nuovo software.

Quindi come decidono quali funzionalità inserire in quegli hard fork? Devono concordare le priorità per allocare il loro tempo e le loro risorse, perché hanno tempo e risorse limitati da dedicare. Danno priorità a cose come falle di sicurezza o patch di sicurezza, cose come l'esperienza utente (UX): se c'è un'altra blockchain che compete con noi, dobbiamo diventare competitivi con quelle altre blockchain. Quindi una delle cose che considerano è che qualsiasi funzionalità introdotta deve essere compatibile con gli sviluppi futuri dei potenziali elementi della roadmap.

L'anno scorso è successa una cosa molto controversa. Forse ne avete sentito parlare. Si chiamava EOF. Ovvero EVM Object Format. Era un insieme di funzionalità che doveva essere inserito nell'hard fork Fusaka — Pectra, Fusaka, credo entrambi — ma è stato diviso. E uno dei tanti motivi per cui è stato escluso da quel fork è stato perché Vitalik ha pubblicato un post sulla possibilità che Ethereum adottasse RISC-V. Molte delle persone che lo hanno letto lo hanno guardato e hanno pensato: ok, se adottiamo RISC-V, le funzionalità che stiamo esaminando in EOF sono native in RISC-V. Quindi perché dovremmo aggiungere questa complessità al protocollo? Perché dovremmo dedicare tutte queste risorse degli sviluppatori di client a questa cosa? Sarebbe irrilevante se finissimo per passare a RISC-V.

Quindi quella è stata la goccia che ha fatto traboccare il vaso per EOF, che alla fine è stato escluso dal fork. Un'altra cosa che devono considerare è che deve essere scritto e rigorosamente testato in sei linguaggi diversi, perché questi client sono scritti in sei linguaggi diversi. Quindi è una matrice di test davvero grande su cui lavorare. E per questo motivo ogni minima scelta di progettazione è soggetta a dibattito, senza alcuna autorità per risolvere i disaccordi. Quindi la domanda che sorge spontanea è: chi decide? Che è il fulcro della governance.

Idee sbagliate (5:23)

Questo ci porta alle idee sbagliate e ne affronteremo alcune. Una è che Vitalik decida cosa entra nel protocollo di Ethereum. Un'estensione di questa è che l'EF controlli tutto. E una terza è che si tratti solo di accordi sottobanco: addetti ai lavori e veterani (OG) che prendono queste decisioni.

Quindi la prima: Vitalik decide. Ho appena selezionato un sottoinsieme di EIP stagnanti scritte da Vitalik. Questo significa che Vitalik si è seduto, ha scritto una proposta e ha detto: voglio che queste cose entrino in Ethereum, e nessuno è stato d'accordo; queste cose sono semplicemente rimaste lì. Non è riuscito a farle entrare nel protocollo. Quindi non tutto ciò che propone viene automaticamente incluso.

Un'estensione di questo è che la Fondazione Ethereum controlla tutto. Prenderò un esempio specifico di un momento che credo contraddica questa affermazione. Nel 2024 si è parlato molto del limite di gas. E il motivo è che nel 2022, durante The Merge, abbiamo alzato il limite di gas a 30 milioni. Questo è il calcolo massimo consentito in un blocco. E poi non lo abbiamo più toccato per un po' perché non era un vero e proprio collo di bottiglia per cui le persone dicevano: "Questo è il motivo per cui non passo a Ethereum" o "Questo sta limitando il mio attuale caso d'uso di Ethereum".

E alla fine del 2023, inizio 2024, c'era questa narrativa secondo cui Solana stava arrivando. Avrebbe fatto le scarpe a Ethereum. E così le persone pensavano a cosa potesse fare Ethereum per accelerare. E una delle cose era: pompiamo questa metrica del gas. E all'epoca l'EF e gli sviluppatori dei client dicevano: "Abbiamo altre cose di cui preoccuparci. Grazie lo stesso". Ma queste due persone, Eric Connor e Mariano Conti, sono arrivate e hanno detto: "No, stiamo alzando il limite di gas". Il limite di gas è un parametro controllato dai validatori. E così hanno potuto semplicemente iniziare a parlare con i validatori, gli operatori professionali, e dire: "Ehi, alzate il vostro limite di gas".

E a un certo punto c'è stata un'adozione tale che l'EF e i client hanno detto: "Oh, dobbiamo prestare attenzione a questo. Dobbiamo assicurarci che quello che stanno facendo sia sicuro e che il valore a cui finiranno per alzarlo sia una cosa sicura per la rete". Quindi, hanno dovuto riallocare le loro risorse. Nethermind ha ideato questo framework di test. L'EF ha fatto un sacco di lavoro a Berlin. Tutti gli sviluppatori dei client stavano facendo benchmark su questo. E quindi mi piace perché ha forzato la mano dell'EF nel decidere a cosa dare priorità.

E mi piace questo stupido tweet di cui ho fatto uno screenshot qui, perché è come se un organo di stampa a caso chiamasse Eric Connor e Mariano Conti sviluppatori principali (core dev). Non sono core dev. Eric Connor era uno staker e un membro della comunità. Mariano Conti era un ex sviluppatore di app per MakerDAO. Ma sono stati chiamati core dev solo perché lo sviluppo di Ethereum è davvero al di fuori del mondo di come funziona il software tradizionale, e quindi hanno visto un parametro fondamentale venire modificato e hanno pensato: "Oh, questi devono essere sviluppatori principali". Non lo erano. Quindi questo è solo un esempio di membri della comunità che intervengono e dicono che vogliono vedere questo cambiamento e lo fanno accadere.

Sono tutti accordi sottobanco, addetti ai lavori, veterani: capisco un po' di più perché questa sia un'idea sbagliata, perché in pratica partecipi a queste chiamate di governance, ci sono un centinaio di persone in queste chiamate di governance. Sembra che siano tutti molto a loro agio con quello che sta succedendo. Tu sei perso. Non hai idea di come vengano prese queste decisioni. Ti chiedi: "È già il mio turno di parlare?". E sembra che le persone ascoltino le stesse 10 persone per prendere queste decisioni.

Meritocrazia e statistiche di partecipazione (10:18)

Ma la verità è che lo sviluppo di Ethereum è più una meritocrazia di quanto abbia mai visto nella maggior parte dello sviluppo software. Tutte queste persone in questo screenshot — questo è uno dei tre in questa chiamata ACD casuale di cui ho deciso di fare uno screenshot — nessuna di queste persone è stata nominata per essere qui. Tutti sono semplicemente le persone che si sono presentate. Sono gli sviluppatori che hanno trascorso molto tempo con questo protocollo. Sono quelli che le persone hanno riconosciuto come sviluppatori di talento in questo spazio, che prendono costantemente buone decisioni, e nessuno in questo gruppo è nominato per essere qui.

Quindi sono entrato nell'EF solo poco più di un anno fa. Ho preso queste statistiche. Risalgono solo a marzo 2025. Quindi meno di un anno. La media dei partecipanti alle chiamate All Core Dev — ovvero le chiamate di governance — è 98. Quindi in media ci sono 98 persone in queste chiamate. Il numero massimo di partecipanti in una chiamata da allora è stato 153. Credo fosse il giorno in cui stavamo decidendo la data della Mainnet di Pectra. E il totale dei partecipanti unici è 567 solo nell'ultimo anno. Mi piace molto questa metrica perché dimostra che non sono le stesse 100 persone a partecipare a queste chiamate ogni volta. Questi sviluppatori di app, ricercatori, qualcuno sente parlare di una funzionalità in discussione, si presenta per esprimere la propria opposizione o il proprio sostegno e poi non partecipa a un'altra chiamata.

Come funziona il processo di governance (11:52)

Quindi questa è una diapositiva un po' noiosa, ma credo sia importante esaminarla: ecco come funziona attualmente la governance di Ethereum. Quando si discute di uno di questi fork, la prima cosa che succede è che le persone, durante questa finestra di tempo assegnata, possono presentare la loro proposta principale (headliner proposal). La proposta principale è la funzionalità di punta attorno alla quale vogliamo che le persone si riuniscano per questo fork. Può essere un membro della comunità, un ricercatore, un core dev: davvero chiunque presenti una di queste proposte principali. Poi la finestra si chiude e nelle chiamate di governance discutiamo su quale di queste abbia senso. Le persone espongono le loro ragioni, discutono e si raggiunge un consenso su quale dovremmo scegliere per l'imminente fork.

Successivamente scelgono le funzionalità minori. Quindi le cose più piccole che non hanno davvero bisogno di essere queste grandi funzionalità trainanti del fork. E per tutto questo tempo abbiamo delle devnet specifiche per le funzionalità. Una devnet è come una testnet: una rete di test privata per gli sviluppatori per testare queste funzionalità e assicurarsi che funzionino effettivamente su Ethereum. E poi a un certo punto c'è un blocco delle funzionalità (feature freeze). Quindi abbiamo discusso le funzionalità principali, abbiamo discusso le funzionalità minori, abbiamo eseguito queste devnet specifiche per le funzionalità che di solito sono le protagoniste del fork. E questo è un blocco delle funzionalità con un asterisco, perché a quel punto abbiamo deciso che non aggiungeremo altre funzionalità a questo fork. Eseguiremo tutte le funzionalità insieme, ci assicureremo che tutto vada bene, che nulla si rompa. Ma se qualcosa inizia a rallentare le cose, se il fork è in ritardo, se è troppo complesso, le cose possono ancora essere escluse a quel punto.

Quindi, dopo un certo numero di devnet — potrebbero essere due, potrebbero essere 10 — i client decidono tutti a un certo punto che la situazione è stabile. Ci fidiamo di quello che sta succedendo in questo momento. Siamo a buon punto. Iniziamo a pensare di portarlo sulla Mainnet di Ethereum. Rilasciano le versioni dei client e poi c'è un periodo di 30 giorni in cui il team di sicurezza dell'EF lancia un programma di bug bounty. Appaltano audit di sicurezza. E poi, alla fine di quel periodo di 30 giorni, lanciamo il fork sulle testnet. Queste sono testnet di cui potreste aver sentito parlare, come Holesky. È qui che gli sviluppatori di app possono testare le loro cose prima che il fork diventi operativo. E queste durano generalmente un minimo di 14 giorni ciascuna, solo per assicurarsi che tutto vada bene. Non ci aspettiamo grossi problemi perché è passato attraverso devnet specifiche per le funzionalità e devnet generalizzate in precedenza, ma storicamente ha rotto alcune di queste testnet. E quindi questa è una sorta di ultima chiamata per trovare e risolvere tutti questi bug.

E poi, una volta che la testnet permissionless è stabile, viene scelta la data per la Mainnet. Successivamente, c'è un margine di 30 giorni. Questo margine di 30 giorni esiste perché gli L2 e i protocolli lo hanno richiesto per prepararsi al fork. Quindi si tratta di un minimo di 30 giorni e poi avviene il fork.

Struttura delle chiamate e coordinamento (15:01)

Durante tutto questo tempo si svolgono alcune serie di chiamate principali. Sono tutte chiamate pubbliche trasmesse in diretta su YouTube. Le principali sono ACDE e ACDC. La E sta per livello di esecuzione (execution layer): si tratta di cose come transazioni, distribuzioni di smart contract, gestione della mempool. ACDC è il livello di consenso (consensus layer): quindi si tratta di cose relative ai validatori, come la gestione dei validatori, lo slashing. E queste si alternano il giovedì. Quindi c'è un'ACD ogni singolo giovedì e una di queste è ACDE e poi la successiva è ACDC, continuando in questo modo.

Le chiamate ACDE e ACDC si concentrano sul fork che stiamo realizzando attualmente e sui fork che stiamo pianificando per il futuro. Le chiamate ACDT sono più incentrate sui dettagli tecnici. Sono i client che parlano di bug che non riescono a superare o di dettagli di implementazione che devono essere risolti riguardo al fork su cui stanno lavorando attualmente. Quindi in questo momento il prossimo fork in programma è Glamsterdam. Pertanto, queste chiamate ACDT sono dominate da conversazioni su ePBS e liste di accesso a livello di blocco, che sono le cose che entreranno in Glamsterdam. E queste sono le chiamate altamente tecniche.

E poi ci sono le chiamate di approfondimento (breakout calls). Le chiamate di approfondimento sono membri della comunità, ricercatori, sviluppatori che dicono: "Ehi, ho una funzionalità che voglio inserire in Ethereum tra due fork". E così ospitano queste chiamate settimanali, mensili o bimestrali in cui discutono i dettagli di implementazione, modificano e iterano sulle specifiche e, in generale, affrontano tutte le domande che le persone hanno, tutte le incognite note per assicurarsi che sia nella posizione migliore possibile per essere inclusa nel fork tra due fork. E queste possono essere programmate ogni volta che il facilitatore lo decide.

Un processo in evoluzione (15:29)

Quindi una cosa che voglio far capire a tutti è che questo processo è tutt'altro che statico. Questo processo che vi ho appena descritto è attivo da meno di un anno. Ethereum è attivo da 10 anni. Ma cambia costantemente e il motivo per cui cambia costantemente è perché nessuno è al comando. E questo processo si evolve in un certo senso per capire il modo più efficiente di operare. E dico efficiente, ma la reputazione che ha la governance di Ethereum è di essere davvero stagnante, difficile da far passare le cose, confusa; e questo perché quando hai da 100 a 500 persone che prendono decisioni, sono onestamente impressionato che funzioni.

Quindi Tim ha pubblicato un post nell'aprile del 2025 intitolato "Reconfiguring All Core Devs" che ha finito per essere la proposta su come funzionano le cose in questo momento. E il motivo è che prima di allora avevamo una sorta di narrativa coesa su cosa dovessimo concentrarci in Ethereum. C'è stato The Merge, che è stata un'impresa enorme. Tutti erano molto entusiasti. La maggior parte delle persone era molto entusiasta. I miner no. E poi, in seguito a The Merge, ci sono stati i prelievi. Quindi, non volevamo che le persone avessero i loro ETH bloccati in un contratto e che si diffondesse questo FUD secondo cui non avrebbero mai potuto ritirare gli ETH da lì. Quindi, dovevamo rilasciarlo il più velocemente possibile. E poi c'è stato il Proto-Danksharding e poi è arrivato Pectra, e Pectra era una sorta di amalgama di diverse EIP non correlate e non aveva davvero una narrativa coesa. Ed è diventato così grande perché le persone stavano semplicemente infilando cose a causa della mancanza di coesione, tanto che ha dovuto essere diviso in due fork diversi perché i team di test dicevano: "L'ambito è decisamente troppo grande. Non possiamo testare tutto questo".

E così l'impulso di Tim per fare questo è stato: ok, dobbiamo pensare a un modo per mantenere questi fork il più mirati e coesi possibile. E la proposta principale (headliner) è stata in un certo senso la risposta a questo. Il punto era rilasciare in un modo che desse priorità al far sentire che tutti sapessero di cosa trattava il fork, in modo da non doverci infilare 25 EIP diverse.

Quindi l'altro screenshot in alto è Tim che propone definizioni per le fasi di inclusione di queste EIP. E il punto che voglio sottolineare con questo è che a volte si sente dire che questo processo è troppo burocratico. Ma quello che succede in realtà è che le persone entrano in questo processo di governance e chiedono: "Come faccio a far approvare un'EIP?" e le persone che sono lì da 10 anni rispondono: "In un certo senso, lo fai e basta". E le persone pensano: "Questo è orribile". E quindi quello che fanno queste cose è descrivere ciò che sta accadendo per rendere più facile agli esterni partecipare a questo processo, perché se arrivi qui e dici: "Ho un'EIP, non mi interessa la governance di Ethereum, voglio solo che questa EIP venga approvata", vuoi uno schema, vuoi una lista di controllo, vuoi un passo-passo molto chiaro su come far approvare questa EIP. Quindi, la maggior parte di queste cose riguarda più la descrizione di come funziona il processo che la creazione di regole burocratiche che le persone devono seguire per rendere difficile l'approvazione delle EIP.

La terza cosa sono i commit nel tempo su Forkcast. Forkcast è un prodotto del mio team, di Wolfram Mark, un ragazzo del mio team che lo ha creato a metà dell'anno scorso quando si è formato il mio team nella sua attuale iterazione. Ed è diventato una risorsa così canonica che le persone usano per interagire con un fork, per vedere cosa entra in un fork e come li influenza. Tutte queste cose hanno meno di due anni. Quindi il punto che sto sottolineando è che questo processo cambia molto. Non è affatto statico. Non è una burocrazia congelata in cui è difficile mettere piede.

Sistemi di governance comparabili (20:21)

Quindi, molto rapidamente, volevo accennare ai sistemi di governance decentralizzata più simili che riesco a vedere rispetto alla governance di Ethereum. E il punto che sto cercando di sottolineare qui è che questo è sostenibile: anche se è incredibile che da 100 a 500 persone possano prendere decisioni, è sostenibile nel mondo reale. Vediamo esempi di come questo funzioni.

L'IETF è l'Internet Engineering Task Force. È l'ente di standardizzazione gestito da volontari che ha creato TCP/IP, HTTP. È l'organizzazione maggiormente responsabile del fatto che oggi abbiamo un'internet libera. Il kernel Linux: è il nucleo del sistema operativo Linux. Quindi è un software open source che alimenta server internet, telefoni Android, supercomputer. La differenza in questo caso è che hanno una sorta di modello di dittatore benevolo con Linus Torvalds. Ma anche in questo caso hanno oltre 17.000 contributori, il che è sbalorditivo.

Cose a cui questo non è simile: altre blockchain che hanno votazioni di token onchain. Ethereum evita specificamente qualsiasi tipo di meccanismo di voto perché, a mio parere, questo porta a rischi di cattura e in un certo senso elimina l'incentivo a rendere le cose una meritocrazia in cui le persone si fidano semplicemente di chi scrive il codice migliore. E poi ci sono gli L2. Hanno multi-sig. Hanno consigli di sicurezza. Queste sono più simili a posizioni nominate che prendono queste decisioni. E questo ha i suoi compromessi. È più centralizzato. Tuttavia, si muove più velocemente.

Perché ai costruttori interessa (22:38)

Quindi perché ai costruttori (builder) interessa la governance? Perché i costruttori sono letteralmente coloro per cui Ethereum è stato creato. Ethereum non è stato creato per i core dev. Non è stato creato per i validatori. A volte queste persone si confondono al riguardo. I core dev e i validatori di Ethereum servono Ethereum, che a sua volta serve i costruttori e gli utenti.

E tutti hanno avuto quel momento con un'IA in cui si entra troppo nei dettagli e lei cerca di sistemare questa piccola cosa e non riesce a fare un passo indietro per guardare all'intero scopo del progetto. E i core dev possono essere così quando cercano di perfezionare il processo di sviluppo principale. Ed è molto cruciale in quel caso che i costruttori intervengano, perché lo sviluppo principale è così totalizzante che la maggior parte delle volte non stanno anche costruendo su Ethereum. Sono molto coinvolti nello sviluppo principale. Prende tutto il loro tempo. E quindi i costruttori di app devono davvero fare uno sforzo per intervenire e dire: "Ehi, abbiamo bisogno di questo. Questo è cruciale per Ethereum". Solo per assicurarsi che la prospettiva sia presente e che non vengano semplicemente incasellati a lavorare solo per gli sviluppatori principali.

Come partecipare (24:40)

Quindi come si partecipa o si fa inserire la propria funzionalità? Questo è un consiglio un po' generico, ma credo sia il migliore. Fatevi sentire sui vostri punti deboli (pain points). Andate su Twitter, scrivete post sui blog, identificate soluzioni per i vostri problemi. Speculate sulle cose che potrebbero aiutarvi. Se trovate altre persone che hanno gli stessi problemi, in genere potete trovare un'EIP esistente per affrontare quel problema o farvi aiutare da qualcuno a scrivere un'EIP che lo faccia.

Una cosa che mi piace del software open source è che in genere le aziende ben capitalizzate allocano il tempo e le risorse dei loro sviluppatori per mantenere gli strumenti open source che stanno utilizzando. E finisce per essere un gruppo di aziende diverse che collaborano al mantenimento di questa cosa, e può funzionare così anche in Ethereum. Quindi, se avete un problema che avete identificato, potete trovare uno sviluppatore di Base che ha un problema simile, e Base è un'organizzazione ben capitalizzata e quindi probabilmente sarebbero disposti ad allocare alcune risorse per rilasciare una funzionalità o guidare una funzionalità attraverso un hard fork di Ethereum.

Vi lascio solo alcune risorse. Forkcast.org: è lì che potete andare a vedere cosa entra in un fork, come influisce su determinati stakeholder. Quindi, se siete sviluppatori di app, c'è una sezione per gli sviluppatori di app. Se siete sviluppatori di portafogli, sviluppatori di client del livello di consenso, ci sono sezioni su come tutto questo vi riguarda. YouTube è dove vengono caricati tutti i video di quelle chiamate. Sono anche incorporati nella pagina forkcast.org/calls dove ci sono riassunti, attribuzioni dei relatori, in modo che sia più facile navigare in quelle chiamate. La directory delle EIP, il forum Ethereum Magicians dove potete andare a parlare con altre persone di potenziali soluzioni o EIP che volete scrivere. E molto presto il mio team avrà un sito di supporto al protocollo. Sembra fantastico. Non è ancora pronto per essere condiviso. C'è anche la mia email: nixo@ethereum.org (opens email client). Questo è tutto.