Vitalik: Quali sono i possibili miglioramenti per il PoS di Ethereum e quali sono le vie per implementarli?

Questo articolo si concentrerà sulla questione della "Merge" di Ethereum: quali aspetti del design tecnico della proof-of-stake possono ancora essere migliorati e quali sono le strade per realizzare questi miglioramenti?

Autore:Vitalik Buterin

Traduzione: Deng Tong, Jinse Finance

Un ringraziamento speciale a Justin Drake, Hsiao-wei Wang, @antonttc e Francesco per i loro feedback e la revisione.

In origine, la "Merge" si riferiva all'evento più importante nella storia del protocollo Ethereum dal suo lancio: la tanto attesa e difficile transizione dal proof-of-work al proof-of-stake. Oggi, Ethereum è un sistema proof-of-stake stabile da quasi due anni, e questa proof-of-stake si è dimostrata eccellente in termini di stabilità, prestazioni e mitigazione dei rischi di centralizzazione. Tuttavia, ci sono ancora aree importanti in cui la proof-of-stake può essere migliorata.

La mia roadmap del 2023 la suddivide in diverse parti: miglioramenti delle caratteristiche tecniche, come stabilità, prestazioni e accessibilità per i validatori più piccoli, e cambiamenti economici per affrontare i rischi di centralizzazione. La prima ha assunto il titolo di "Merge", mentre la seconda è diventata parte della "Scourge".

Questo articolo si concentrerà sulla parte "Merge": quali aspetti del design tecnico della proof-of-stake possono ancora essere migliorati e quali sono le strade per realizzare questi miglioramenti?

Questa non è una lista esaustiva di tutti i possibili miglioramenti alla proof-of-stake; piuttosto, è una raccolta di idee attivamente considerate.

Finalità a slot singolo e democratizzazione dello staking

Quale problema stiamo cercando di risolvere?

Oggi, sono necessari 2-3 epoch (circa 15 minuti) per finalizzare un blocco e sono necessari 32 ETH per diventare uno staker. Inizialmente, questa era una scelta di compromesso per bilanciare tre obiettivi:

• Massimizzare il numero di validatori che possono partecipare allo staking (il che implica direttamente minimizzare l’ETH minimo richiesto per lo staking)
• Minimizzare il tempo di finalizzazione
• Minimizzare l’overhead per l’esecuzione dei nodi

Questi tre obiettivi sono in conflitto tra loro: per ottenere la finalità economica (cioè, che un attaccante debba distruggere una grande quantità di ETH per annullare un blocco finalizzato), ogni validatore deve firmare due messaggi ogni volta che si raggiunge la finalità. Quindi, se hai molti validatori, o ci vuole molto tempo per elaborare tutte le firme, oppure hai bisogno di nodi molto potenti per gestire tutte le firme contemporaneamente.

Nota che tutto ciò dipende da un obiettivo chiave di Ethereum: garantire che anche un attacco riuscito abbia un costo elevato per l’attaccante. Questo è il significato del termine "finalità economica". Se non avessimo questo obiettivo, potremmo finalizzare ogni slot selezionando casualmente un comitato (come fa Algorand). Ma il problema di questo approccio è che, se un attaccante controlla il 51% dei validatori, può attaccare a basso costo (annullando blocchi finalizzati, censurando o ritardando la finalità): solo una parte dei nodi nel comitato può essere rilevata e punita, sia tramite slashing che soft fork di minoranza. Ciò significa che l’attaccante può ripetere l’attacco più volte. Quindi, se vogliamo la finalità economica, il semplice approccio basato sul comitato non funziona e, a prima vista, sembra che abbiamo davvero bisogno della partecipazione di tutti i validatori.

Idealmente, vorremmo mantenere la finalità economica, migliorando allo stesso tempo la situazione su due fronti:

• Finalizzare i blocchi in un solo slot (idealmente mantenendo o riducendo l’attuale durata di 12 secondi), invece di 15 minuti
• Consentire ai validatori di fare staking con 1 ETH (abbassando il minimo da 32 ETH a 1 ETH)

Il primo obiettivo è motivato da due ragioni, entrambe riconducibili al desiderio di "allineare le proprietà di Ethereum con quelle delle L1 più performanti (ma più centralizzate)".

Primo, garantisce che tutti gli utenti di Ethereum possano beneficiare di un livello di sicurezza più elevato fornito dal meccanismo di finalità. Oggi, la maggior parte degli utenti non gode di questa sicurezza perché non vogliono aspettare 15 minuti; con la finalità a slot singolo, gli utenti vedrebbero la finalità quasi immediatamente dopo la conferma della transazione. Secondo, se utenti e applicazioni non devono preoccuparsi di possibili rollback della chain (tranne in rari casi di inactivity leak), si semplificano i protocolli e le infrastrutture circostanti.

Il secondo obiettivo nasce dal desiderio di supportare gli staker individuali. Sondaggi ripetuti hanno mostrato che il principale ostacolo per molti a fare staking individuale è il limite minimo di 32 ETH. Abbassare il limite a 1 ETH risolverebbe questo problema, rendendo altri fattori i principali limiti per lo staking individuale.

Esiste una sfida: sia la finalità più rapida che l’obiettivo di uno staking più democratico sono in conflitto con la minimizzazione dell’overhead. In effetti, questo è il motivo per cui non abbiamo adottato la finalità a slot singolo fin dall’inizio. Tuttavia, ricerche recenti hanno proposto alcuni modi per affrontare questo problema.

Cos’è e come funziona?

La finalità a slot singolo implica l’uso di un algoritmo di consenso che finalizza i blocchi in un solo slot. Questo obiettivo non è difficile di per sé: molti algoritmi (come il consenso Tendermint) lo realizzano già con ottime proprietà. Una caratteristica ideale unica di Ethereum, non supportata da Tendermint, è l’inactivity leak, che permette alla chain di continuare e recuperare anche se più di 1/3 dei validatori sono offline. Fortunatamente, questo desiderio è già stato soddisfatto: esistono proposte per modificare il consenso in stile Tendermint per adattarsi all’inactivity leak.

Principali proposte di finalità a slot singolo

La parte più difficile è capire come far funzionare la finalità a slot singolo con un numero molto elevato di validatori senza causare un overhead eccessivo per gli operatori di nodi. A tal fine, esistono alcune soluzioni principali:

Opzione 1: Forza bruta — lavorare su protocolli di aggregazione delle firme migliori, possibilmente usando ZK-SNARKs, che permettano di gestire le firme di milioni di validatori per slot.

Horn, uno dei design proposti per un protocollo di aggregazione migliore.

Opzione 2: Comitato Orbit — un nuovo meccanismo che consente a un comitato di medie dimensioni, selezionato casualmente, di finalizzare la chain, mantenendo però le proprietà di costo d’attacco che desideriamo.

Un modo per pensare a Orbit SSF è che apre uno spazio di compromesso che va da x=0 (comitato stile Algorand, senza finalità economica) a x=1 (stato attuale di Ethereum), con punti intermedi in cui Ethereum mantiene sufficiente finalità economica per una sicurezza elevata, ma ottiene anche i vantaggi di efficienza di un campione casuale di validatori di dimensioni medie per ogni slot.

Orbit sfrutta l’eterogeneità preesistente nelle dimensioni dei depositi dei validatori per ottenere la massima finalità economica possibile, pur continuando a dare un ruolo ai validatori più piccoli. Inoltre, Orbit utilizza una rotazione lenta dei comitati per garantire una forte sovrapposizione tra i quorum adiacenti, assicurando che la finalità economica si applichi anche ai confini della rotazione dei comitati.

Opzione 3: Staking a due livelli — un meccanismo in cui gli staker sono divisi in due categorie, una con requisiti di deposito più elevati e una con requisiti più bassi. Solo il livello con deposito più alto partecipa direttamente alla finalità economica. Esistono varie proposte su quali diritti e responsabilità abbia il livello con deposito più basso (vedi ad esempio il post su Rainbow staking). Idee comuni includono:

• Il diritto di delegare la propria quota a uno staker di livello superiore
• Staker di livello inferiore selezionati casualmente che devono attestare ogni blocco
• Il diritto di generare la inclusion list

Quali sono i collegamenti con la ricerca esistente?

• Strade per la finalità a slot singolo (2022):
• Proposte specifiche per il protocollo di finalità a slot singolo di Ethereum (2023):
• Orbit SSF:
• Ulteriori analisi dei meccanismi in stile Orbit:
• Horn, protocollo di aggregazione delle firme (2022):
• Aggregazione delle firme per il consenso su larga scala (2023):
• Protocollo di aggregazione delle firme proposto da Khovratovich et al.:
• Aggregazione delle firme basata su STARK (2022):
• Rainbow staking:

Cosa resta da fare? Quali sono i compromessi?

Ci sono quattro strade principali praticabili (possiamo anche adottare approcci ibridi):

• Mantenere lo status quo
• Orbit SSF
• SSF forza bruta
• SSF con staking a due livelli

(1) Significa non fare nulla, mantenere lo staking com’è, ma questo peggiora l’esperienza di sicurezza di Ethereum e le proprietà di centralizzazione dello staking.

(2) Evita la "high tech" e risolve il problema ripensando in modo intelligente le assunzioni del protocollo: allentiamo il requisito della "finalità economica" in modo che il costo dell’attacco sia ancora elevato, ma accettiamo che possa essere 10 volte inferiore rispetto a oggi (ad esempio, costo dell’attacco di 2.5 billions di dollari invece di 25 billions). Si ritiene generalmente che la finalità economica di Ethereum oggi sia molto superiore a quanto necessario e che i principali rischi di sicurezza siano altrove, quindi questo può essere un sacrificio accettabile.

Il lavoro principale consiste nel verificare che il meccanismo Orbit sia sicuro e abbia le proprietà desiderate, quindi formalizzarlo e implementarlo completamente. Inoltre, EIP-7251 (aumento del saldo massimo effettivo) consente la fusione volontaria dei saldi dei validatori, riducendo immediatamente l’overhead di validazione della chain e fungendo da fase iniziale efficace per il lancio di Orbit.

(3) Evita il ripensamento intelligente e risolve il problema con la tecnologia avanzata. Per farlo, è necessario raccogliere un gran numero di firme (oltre 1 milione) in un tempo molto breve (5-10 secondi).

(4) Evita sia il ripensamento intelligente che la tecnologia avanzata, ma crea comunque un sistema di staking a due livelli, che comporta rischi di centralizzazione. Il rischio dipende in gran parte dai diritti specifici concessi al livello di staking inferiore. Ad esempio:

• Se gli staker di livello inferiore devono delegare il diritto di attestazione a quelli di livello superiore, la delega può centralizzarsi e si finisce con due livelli di staking altamente centralizzati.
• Se è richiesto un campionamento casuale del livello inferiore per approvare ogni blocco, un attaccante può spendere pochissimo ETH per bloccare la finalità.
• Se gli staker di livello inferiore possono solo creare la inclusion list, il livello di attestazione può comunque essere centralizzato, e un attacco del 51% al livello di attestazione può censurare la inclusion list stessa.

Si possono combinare più strategie, ad esempio:

• (1 + 2): aggiungere Orbit senza implementare la finalità a slot singolo.
• (1 + 3): usare la forza bruta per ridurre la dimensione minima del deposito senza implementare la finalità a slot singolo. L’aggregazione richiesta è 64 volte inferiore rispetto al caso (3) puro, quindi il problema è più gestibile.
• (2 + 3): implementare Orbit SSF con parametri conservativi (ad esempio, comitato di 128k validatori invece di 8k o 32k) e usare la forza bruta per renderlo super-efficiente.
• (1 + 4): aggiungere Rainbow staking senza implementare la finalità a slot singolo.

Come interagisce con le altre parti della roadmap?

Oltre ad altri vantaggi, la finalità a slot singolo riduce il rischio di alcuni tipi di attacchi MEV multi-blocco. Inoltre, in un mondo con finalità a slot singolo, il design della separazione proponente-attestatore e altre pipeline di produzione dei blocchi a livello di protocollo devono essere progettate in modo diverso.

Il punto debole delle strategie di forza bruta è che rendono più difficile ridurre la durata dello slot.

Single Secret Leader Election

Quale problema vogliamo risolvere?

Oggi, quale validatore proporrà il prossimo blocco è noto in anticipo. Questo crea una vulnerabilità di sicurezza: un attaccante può monitorare la rete, identificare quali validatori corrispondono a quali indirizzi IP e lanciare un attacco DoS contro il validatore poco prima che debba proporre il blocco.

Cos’è? Come funziona?

Il modo migliore per risolvere il problema DoS è nascondere quale validatore genererà il prossimo blocco, almeno fino a quando il blocco non viene effettivamente generato. Nota che, se rimuoviamo il requisito di "unicità", questo è facile: una soluzione è permettere a chiunque di creare il prossimo blocco, ma richiedere che il randao rivelato sia inferiore a 2^256 / N. In media, solo un validatore soddisferà questo requisito, ma a volte ce ne saranno due o più, a volte nessuno. Combinare il requisito di "segretezza" con quello di "unicità" è sempre stato difficile.

Il protocollo Single Secret Leader Election risolve questo problema utilizzando alcune tecniche crittografiche per creare un "ID validatore cieco" per ogni validatore, quindi permette a molti proponenti di rimescolare e ri-ciecare il pool di ID (simile al funzionamento delle mixnet). In ogni slot, viene selezionato casualmente un ID cieco. Solo il proprietario di quell’ID cieco può generare una prova valida per proporre il blocco, ma nessuno sa a quale validatore corrisponde quell’ID cieco.

Protocollo Whisk SSLE

Quali sono i collegamenti con la ricerca esistente?

• Paper di Dan Boneh (2020):
• Whisk (proposta specifica per Ethereum, 2022):
• Tag Single Secret Leader Election su ethresear.ch:
• SSLE semplificato con ring signature:

Cosa resta da fare? Quali sono i compromessi?

In pratica, resta da trovare e implementare un protocollo sufficientemente semplice da poter essere facilmente implementato sulla mainnet. Diamo molta importanza al fatto che Ethereum sia un protocollo relativamente semplice e non vogliamo aumentare ulteriormente la complessità. Le implementazioni SSLE che abbiamo visto aggiungono centinaia di righe di codice di specifica e introducono nuove assunzioni crittografiche complesse. Trovare un’implementazione SSLE resistente ai quanti e sufficientemente efficiente è ancora una questione aperta.

Potrebbe anche darsi che solo quando, per altri motivi (ad esempio, stato degli alberi, ZK-EVM), introdurremo meccanismi di zero-knowledge proof generici su L1 di Ethereum, la "complessità marginale aggiuntiva" di SSLE diventerà sufficientemente bassa.

Un’altra opzione è ignorare completamente SSLE e affrontare il problema DoS con misure di mitigazione esterne al protocollo (ad esempio, a livello p2p).

Come interagisce con le altre parti della roadmap?

Se aggiungiamo un meccanismo di separazione proponente-attestatore (APS), come execution tickets, allora i blocchi di esecuzione (cioè i blocchi che contengono le transazioni Ethereum) non avranno bisogno di SSLE, perché possiamo fare affidamento su costruttori di blocchi specializzati. Tuttavia, per i blocchi di consenso (cioè quelli che contengono messaggi di protocollo come attestazioni, inclusion list parziali, ecc.), continueremo a beneficiare di SSLE.

Conferma delle transazioni più rapida

Quale problema stiamo cercando di risolvere?

Ridurre ulteriormente il tempo di conferma delle transazioni di Ethereum, da 12 secondi a 4 secondi, sarebbe prezioso. Questo migliorerebbe notevolmente l’esperienza utente sia su L1 che su soluzioni rollup, rendendo anche i protocolli defi più efficienti. Inoltre, faciliterebbe la decentralizzazione delle L2, permettendo a molte applicazioni L2 di lavorare su rollup, riducendo la necessità per le L2 di costruire i propri ordinatori decentralizzati basati su comitati.

Cos’è? Come funziona?

Qui ci sono essenzialmente due tecniche:

• Ridurre la durata dello slot, ad esempio a 8 o 4 secondi. Questo non implica necessariamente la finalità in 4 secondi: la finalità richiede essenzialmente tre round di comunicazione, quindi ogni round può essere un blocco separato, ottenendo almeno una conferma preliminare dopo 4 secondi.
• Consentire ai proponenti di pubblicare pre-conferme durante lo slot. In casi estremi, il proponente può includere in tempo reale le transazioni che vede nel suo blocco e pubblicare immediatamente un messaggio di pre-conferma per ciascuna ("la mia prima transazione è 0×1234...", "la mia seconda è 0×5678..."). Se un proponente pubblica due conferme in conflitto, si può gestire (i) tagliando il proponente, oppure (ii) facendo votare i validatori su quale sia arrivata prima.

Quali sono i collegamenti con la ricerca esistente?

• Basato su pre-conferme:
• Protocol Enforced Proposer Commitments (PEPC):
• Cicli interlacciati su chain parallele (idea del 2018 per bassa latenza):

Cosa resta da fare e quali sono i compromessi?

Non è ancora chiaro quanto sia praticabile ridurre la durata dello slot. Anche oggi, in molte parti del mondo, gli staker fanno fatica a ottenere le attestazioni abbastanza velocemente. Provare a ridurre lo slot a 4 secondi rischia di concentrare il set dei validatori e, a causa della latenza, rendere poco pratico essere validatore al di fuori di poche regioni privilegiate.

Il punto debole del metodo delle pre-conferme è che può migliorare molto il tempo di inclusione medio, ma non quello peggiore: se il proponente attuale funziona bene, la tua transazione riceverà una pre-conferma in 0,5 secondi invece di essere inclusa (in media) in 6 secondi, ma se il proponente attuale è offline o lento, dovrai comunque aspettare 12 secondi per il prossimo slot e un nuovo proponente.

Inoltre, resta aperta la questione di come incentivare le pre-conferme. I proponenti hanno interesse a massimizzare la loro optionalità il più a lungo possibile. Se i validatori firmano la tempestività delle pre-conferme, i mittenti delle transazioni possono pagare una parte della fee in cambio di una pre-conferma immediata, ma questo aggiunge oneri ai validatori e può rendere più difficile per loro rimanere neutrali come "tubi muti".

D’altra parte, se non proviamo a fare questo e manteniamo il tempo di finalità a 12 secondi (o più), l’ecosistema darà più valore ai meccanismi di pre-conferma sviluppati dalle L2, e le interazioni cross-L2 richiederanno più tempo.

Come interagisce con le altre parti della roadmap?

Le pre-conferme basate sui proponenti dipendono in realtà da un meccanismo di separazione proponente-attestatore (APS), come execution tickets. Altrimenti, la pressione per fornire pre-conferme in tempo reale potrebbe essere eccessiva per i validatori ordinari.

Altri ambiti di ricerca

Recupero da attacchi del 51%

Si presume generalmente che, in caso di attacco del 51% (inclusi attacchi non dimostrabili crittograficamente, come la censura), la comunità si unisca per implementare un soft fork di minoranza, assicurando che i buoni vincano e i cattivi subiscano inactivity leak o slashing. Tuttavia, questa forte dipendenza dal livello sociale può essere considerata malsana. Possiamo cercare di ridurre la dipendenza dal livello sociale, rendendo il processo di recupero il più automatizzato possibile.

La completa automazione non è possibile, perché altrimenti avremmo un algoritmo di consenso tollerante a >50%, e conosciamo già i limiti matematici (molto stringenti) di tali algoritmi. Ma possiamo ottenere una parziale automazione: ad esempio, se un client rileva che una transazione è stata censurata per troppo tempo, può rifiutare automaticamente di accettare una chain come finalizzata, o persino come head per la fork choice. Un obiettivo chiave è assicurarsi che i cattivi in un attacco non possano almeno ottenere una vittoria rapida.

Aumento della soglia di quorum

Oggi, un blocco viene finalizzato se il 67% degli staker lo supporta. Alcuni ritengono che questa soglia sia troppo bassa. In tutta la storia di Ethereum, c’è stato solo un (brevissimo) fallimento della finalità. Se questa percentuale fosse aumentata all’80%, il numero di periodi di non-finalità aumenterebbe solo leggermente, ma Ethereum guadagnerebbe in sicurezza: in particolare, molti casi controversi porterebbero solo a una sospensione temporanea della finalità. Questo sembra più sano che permettere una vittoria immediata alla "parte sbagliata", sia essa un attaccante o un client con bug.

Questo risponde anche alla domanda "che senso ha lo staking individuale". Oggi, la maggior parte degli staker partecipa tramite pool e sembra improbabile che gli staker individuali raggiungano il 51% dell’ETH in staking. Tuttavia, se ci impegniamo, raggiungere una minoranza di blocco per gli staker individuali, specialmente se la maggioranza è all’80% (quindi la minoranza di blocco è solo il 21%), sembra realizzabile. Finché gli staker individuali non partecipano a un attacco del 51% (sia per finalità reversal che per censura), tale attacco non otterrà una "vittoria pulita" e gli staker individuali aiuteranno attivamente a organizzare il soft fork di minoranza.

Resistenza ai quanti

Metaculus attualmente ritiene che, sebbene con grande incertezza, i computer quantistici probabilmente inizieranno a rompere la crittografia negli anni 2030:

Esperti di quantum computing, come Scott Aaronson, hanno recentemente iniziato a prendere più seriamente la possibilità che i computer quantistici funzionino davvero nel medio termine. Questo ha implicazioni per l’intera roadmap di Ethereum: significa che ogni parte del protocollo Ethereum che oggi si basa sulle curve ellittiche avrà bisogno di un’alternativa basata su hash o altre tecniche resistenti ai quanti. In particolare, non possiamo presumere di poter sempre fare affidamento sulle eccellenti proprietà di aggregazione delle firme BLS per gestire le firme di grandi set di validatori. Questo giustifica un approccio conservativo alle assunzioni sulle prestazioni nel design della proof-of-stake e motiva lo sviluppo più attivo di alternative resistenti ai quanti.