Ultima ricerca di Vitalik: come devono cambiare i protocolli LSDFi e la liquidità per aumentare la decentralizzazione e ridurre il sovraccarico del consenso?

Questo articolo si concentrerà principalmente sui rischi di centralizzazione degli operatori di nodo e sugli oneri di consenso non necessari attualmente presenti nei protocolli LSDFi e nei pool di liquidità.

Autore:Vitalik Buterin

Traduzione: bayemon.eth, ChainCatcher

Lo stato attuale dello sviluppo di Ethereum può essere descritto come caratterizzato da un ampio utilizzo dello staking a due livelli (two-tiered staking), dove per staking a due livelli si intende un modello di staking con due categorie di partecipanti.

• Node Operator: gestisce i nodi e mette in staking una certa quantità di capitale proprio come garanzia, facendo leva sulla propria reputazione
• Delegator: i delegatori mettono in staking una certa quantità di Ethereum, senza una soglia minima, e senza ulteriori restrizioni sulle modalità di partecipazione oltre alla garanzia

Questa nuova forma di staking a due livelli nasce dai pool di staking che forniscono token di staking liquidi (LST) tramite la partecipazione di massa. (Rocket Pool e Lido seguono entrambi questo modello).

Tuttavia, l’attuale modello di staking a due livelli presenta due difetti:

• Rischio di centralizzazione degli operatori di nodo: il meccanismo di selezione degli operatori di nodo nei pool di staking è ancora eccessivamente centralizzato
• Oneri di consenso non necessari: Ethereum L1 deve verificare circa 800.000 firme per ogni Epoch, il che rappresenta un carico enorme per ogni singolo slot. Inoltre, poiché i pool di staking liquidi richiedono più capitale, la rete non trae pieno beneficio da questo carico. Se la rete Ethereum potesse raggiungere una decentralizzazione e sicurezza ragionevoli senza richiedere la firma di ogni staker per ogni slot, la comunità potrebbe adottare soluzioni di questo tipo, riducendo efficacemente il numero di firme per slot.

Questo articolo descriverà le soluzioni ai due problemi sopra menzionati, ipotizzando innanzitutto che la maggior parte del capitale sia detenuta da coloro che non desiderano gestire direttamente i nodi di staking nella forma attuale, firmare per ogni slot, bloccare i depositi e ridistribuire i fondi agli slasher. In questo caso, quale ruolo possono ancora svolgere queste persone per contribuire in modo significativo alla decentralizzazione e alla sicurezza della rete?

Come funziona attualmente lo staking a due livelli?

I due pool di staking più popolari sono Lido e RocketPool. Per quanto riguarda Lido, le due parti coinvolte sono:

• Node Operator: selezionati tramite voto dal Lido DAO, il che significa che in realtà sono scelti dai detentori di LDO. Quando qualcuno deposita ETH nel sistema di smart contract di Lido, viene creato stETH, che l’operatore di nodo può mettere in staking nel pool (ma poiché il certificato di prelievo è vincolato all’indirizzo dello smart contract, l’operatore non può prelevare liberamente)
• Delegator: quando qualcuno deposita ETH nel sistema di smart contract di Lido, viene generato stETH, che l’operatore di nodo può mettere in staking (ma poiché il certificato di prelievo è vincolato all’indirizzo dello smart contract, l’operatore non può prelevare liberamente)

Per quanto riguarda Rocket Pool:

• Node Operator: chiunque può diventare operatore di nodo, basta depositare 8 ETH e una certa quantità di token RPL.
• Delegator: quando qualcuno deposita ETH nel sistema di smart contract di Rocket Pool, viene generato rETH, che l’operatore di nodo può mettere in staking (anche in questo caso, poiché il certificato di prelievo è vincolato all’indirizzo dello smart contract, l’operatore non può prelevare liberamente).

Il ruolo del delegator

In questi sistemi (o in nuovi sistemi abilitati da potenziali cambiamenti futuri del protocollo), una domanda chiave da porsi è: qual è il senso di avere delegatori dal punto di vista del protocollo?

Per comprendere a fondo questa domanda, consideriamo innanzitutto che, con la modifica del protocollo menzionata nel post (limitazione della penalità di slashing a 2 ETH), anche Rocket Pool ridurrebbe la quota di staking degli operatori di nodo a 2 ETH, e la quota di mercato di Rocket Pool salirebbe al 100% (per gli staker e i detentori di ETH, dato che rETH diventerebbe privo di rischio, quasi tutti i detentori di ETH diventerebbero detentori di rETH o operatori di nodo).

Supponiamo che il rendimento per i detentori di rETH sia del 3% (inclusi premi interni al protocollo e commissioni di priorità + MEV), mentre il rendimento per gli operatori di nodo sia del 4%. Supponiamo inoltre che la fornitura totale di ETH sia di 100 milioni.

I risultati sono i seguenti. Per evitare il calcolo dell’interesse composto, calcoleremo i rendimenti su base giornaliera:

Ora, supponiamo che Rocket Pool non esista, che il deposito minimo per ogni staker scenda a 2 ETH, che il limite massimo di liquidità sia di 6,25 milioni di ETH e che il rendimento per gli operatori di nodo scenda all’1%. Calcoliamo di nuovo:

Consideriamo ora il costo di un attacco in entrambe le situazioni. Nel primo caso, un attaccante non si registrerebbe come delegator, poiché i delegatori in sostanza non hanno alcun diritto di prelievo, quindi non avrebbe senso. Pertanto, userebbe tutto il suo ETH per diventare operatore di nodo. Per raggiungere 1/3 della quantità totale in staking, dovrebbe investire 2,08 milioni di ETH (che, va detto, è comunque una cifra considerevole). Nel secondo caso, l’attaccante dovrebbe solo investire capitale, e per raggiungere 1/3 del totale del pool di staking, avrebbe comunque bisogno di 2,08 milioni di ETH.

Dal punto di vista dell’economia dello staking e del costo di un attacco, il risultato finale è identico in entrambi i casi. La quota di ETH detenuta dagli operatori di nodo sul totale aumenta dello 0,00256% al giorno, mentre quella dei non operatori di nodo diminuisce dello 0,00017% al giorno. Il costo di un attacco è di 2,08 milioni di ETH. In questo modello, i delegatori sembrano essere una macchina di Rube Goldberg senza senso, e una comunità razionale sarebbe persino incline a eliminare l’intermediario, ridurre drasticamente le ricompense di staking e limitare il totale di ETH in staking a 6,25 milioni.

Ovviamente, questo articolo non sostiene di ridurre di 4 volte le ricompense di staking e fissare il limite massimo di staking a 6,25 milioni. Al contrario, la tesi è che un sistema di staking ben funzionante dovrebbe avere una caratteristica chiave: i delegatori dovrebbero avere responsabilità importanti all’interno del sistema. Inoltre, se i delegatori sono fortemente motivati dalla pressione della comunità e dall’altruismo ad agire correttamente, va bene; dopotutto, questa è la forza principale che oggi spinge verso soluzioni di staking decentralizzate e sicure.

Le responsabilità dei delegatori

Se i delegatori possono svolgere un ruolo significativo nel sistema di staking, quale potrebbe essere questo ruolo?

Ritengo che ci siano due tipi di risposte:

• Scelta del delegator: il delegator può scegliere a quali operatori di nodo delegare i propri interessi. Il “peso” di un operatore di nodo nel meccanismo di consenso è proporzionale al totale degli stake delegati. Attualmente, il meccanismo di scelta dei delegatori è ancora limitato, ovvero i detentori di rETH o stETH possono ritirare il proprio ETH e passare a un altro pool, ma la reale disponibilità di scelta può essere notevolmente migliorata.
• Partecipazione al consenso: i delegatori possono scegliere di svolgere un certo ruolo nel meccanismo di consenso, con responsabilità più leggere rispetto allo staking completo, senza lunghi periodi di uscita e rischi di slashing, ma comunque in grado di bilanciare il potere degli operatori di nodo.

Rafforzare il potere di scelta dei delegatori

Ci sono tre modi per rafforzare il potere di scelta dei delegatori:

• Migliorare gli strumenti di voto all’interno del pool
• Aumentare la competizione tra i pool
• Rendere permanente il potere di rappresentanza

Attualmente, il voto all’interno dei pool non è realmente pratico: in Rocket Pool, chiunque può diventare operatore di nodo, mentre in Lido il voto è deciso dai detentori di LDO, non dai detentori di ETH. Lido ha proposto una governance duale LDO + stETH, che può attivare un meccanismo di protezione per bloccare nuovi voti e impedire l’aggiunta o la rimozione di operatori di nodo, dando così una certa voce ai detentori di stETH. Tuttavia, questo potere è ancora limitato e potrebbe essere rafforzato.

La competizione tra pool esiste già oggi, ma è relativamente debole. La sfida principale è che i token di staking dei pool più piccoli hanno una liquidità inferiore, sono meno affidabili e meno supportati dalle applicazioni.

Possiamo migliorare i primi due problemi limitando la penalità di slashing a una quantità ridotta, ad esempio 2 o 4 ETH. Il resto degli ETH può essere depositato e prelevato in sicurezza, consentendo lo scambio bidirezionale anche per i pool di staking più piccoli. Possiamo migliorare il terzo problema creando un contratto di emissione totale per gestire gli LST (simile a ERC-4337 ed ERC-6900 per i wallet), garantendo che qualsiasi token di staking emesso tramite tale contratto sia sicuro.

Attualmente, non esiste ancora un potere di rappresentanza permanente a livello di protocollo, ma sembra possibile in futuro. Implicherebbe una logica simile a quella sopra descritta, ma implementata a livello di protocollo. Per i pro e i contro della permanenza, si veda questo articolo.

Queste idee rappresentano miglioramenti rispetto allo stato attuale, ma i vantaggi che possono offrire sono limitati. La governance tramite voto dei token presenta problemi e, in definitiva, qualsiasi forma di scelta non incentivata dei delegatori è solo una forma di voto tramite token; questa è sempre stata la mia principale insoddisfazione nei confronti della proof-of-stake delegata. Pertanto, è utile considerare anche modalità di partecipazione al consenso più solide.

Partecipazione al consenso

Anche senza considerare i problemi attuali dello staking liquido, esistono limiti anche per i metodi di staking indipendenti attuali. Supponiamo di utilizzare la single-slot finality: idealmente, ogni slot potrebbe gestire circa 100.000-1.000.000 di firme BLS. Anche utilizzando SNARK ricorsivi per aggregare le firme, per la tracciabilità delle firme è necessario assegnare a ciascuna firma un campo di bit del partecipante. Se Ethereum diventasse una rete di scala globale, nemmeno l’archiviazione completamente decentralizzata dei bit field sarebbe sufficiente: ogni slot da 16 MB potrebbe supportare solo circa 64 milioni di staker.

Da questo punto di vista, è utile suddividere lo staking in un livello ad alta complessità e riducibilità e in un livello a bassa complessità, dove il livello ad alta complessità è attivo in ogni slot ma coinvolge solo 10.000 partecipanti, mentre il livello a bassa complessità viene chiamato solo occasionalmente. Il livello a bassa complessità può essere completamente esente da slashing, oppure può essere assegnata casualmente ai partecipanti la possibilità di depositare e diventare soggetti a slashing in alcuni slot.

In pratica, ciò può essere ottenuto aumentando il limite massimo del saldo dei validatori e poi aumentando la soglia di saldo (ad esempio, 2048 ETH) per determinare quali validatori esistenti entrano nel livello ad alta o bassa complessità.

Ecco alcuni suggerimenti su come potrebbero funzionare questi ruoli di staking minori:

• Per ogni slot, vengono selezionati casualmente 10.000 piccoli staker, che possono firmare ciò che ritengono rappresenti correttamente lo slot. Si utilizza la regola di scelta del fork LMD GHOST con input dai piccoli staker. Se la scelta del fork guidata dai piccoli staker e quella guidata dagli operatori di nodo divergono, il client dell’utente non accetta alcun blocco come finale e mostra un errore. Questo costringe la comunità a intervenire per risolvere la situazione.
• I delegatori possono inviare una transazione per dichiarare alla rete che sono online e disponibili a servire come piccoli staker nell’ora successiva. I messaggi inviati dai nodi (blocchi o attestazioni) devono essere firmati sia dal nodo sia da un delegatore selezionato casualmente per confermare il nodo.
• I delegatori possono inviare una transazione per dichiarare alla rete che sono online e disponibili a servire come piccoli staker nell’ora successiva. Per ogni epoca, vengono selezionati casualmente 10 delegatori come inclusion list provider e altri 10.000 come elettori. Questi vengono selezionati prima del k-slot e hanno una finestra di k slot per pubblicare on-chain la conferma di essere online. Ogni inclusion list provider selezionato che conferma può pubblicare una inclusion list; per ogni inclusion list, o le transazioni incluse vengono effettivamente incluse, oppure viene incluso il voto di almeno un elettore selezionato che segnala l’indisponibilità della lista, altrimenti il blocco viene considerato non valido.

Questi piccoli nodi di staking hanno in comune il fatto che non devono partecipare attivamente a ogni slot, e possono svolgere tutto il lavoro anche solo come light client. Pertanto, la distribuzione dei nodi richiede solo la verifica del livello di consenso; gli operatori di nodo possono utilizzare applicazioni o plugin del browser, che sono per lo più passivi e richiedono poche risorse computazionali, hardware o competenze tecniche, senza nemmeno la necessità di tecnologie avanzate come ZK-EVM.

Questi “piccoli ruoli” hanno anche un obiettivo comune: prevenire la censura delle transazioni da parte della maggioranza (51%) degli operatori di nodo. Il primo e il secondo metodo possono anche prevenire la reversione finale da parte della maggioranza. Il terzo si concentra più direttamente sulla censura, ma è più suscettibile all’influenza della maggioranza degli operatori di nodo.

Queste idee sono scritte dal punto di vista dell’implementazione di soluzioni di staking a due livelli a livello di protocollo, ma possono anche essere implementate come funzionalità dei pool di staking. Ecco alcune idee concrete di implementazione:

1. Dal punto di vista del protocollo, ogni validatore può impostare due chiavi di staking: una chiave di staking permanente P e un indirizzo Ethereum associato, e generare una chiave di staking rapida Q. Le informazioni di firma per la scelta del fork vengono tracciate tramite P, mentre le informazioni di firma vengono tracciate tramite Q. Se i risultati memorizzati da PQ non coincidono, nessun blocco viene accettato come finale, e il pool di liquidità seleziona casualmente i rappresentanti.
2. Il protocollo può rimanere sostanzialmente invariato, ma la chiave pubblica del validatore per quel periodo sarà impostata come P+Q. Si noti che, per lo slashing, due messaggi soggetti a slashing possono avere chiavi Q diverse, ma avranno la stessa chiave P; il design dello slashing deve gestire questa situazione.
3. La chiave Q può essere utilizzata nel protocollo solo per firmare e verificare inclusion list nei blocchi. In questo caso, Q può essere uno smart contract invece di una singola chiave, consentendo al pool di staking di implementare una logica di voto più complessa, accettando inclusion list da provider selezionati casualmente o un numero sufficiente di voti che segnalano l’indisponibilità della lista.

Conclusione

Se implementate correttamente, alcune ottimizzazioni al design della proof-of-stake possono risolvere due problemi contemporaneamente:

• Offrire a chi oggi non ha risorse o capacità per la proof-of-stake indipendente l’opportunità di partecipare, mantenendo più potere nelle loro mani: (i) la possibilità di scegliere quali nodi supportare e (ii) la possibilità di partecipare attivamente al consenso in modo più leggero ma comunque significativo rispetto all’esecuzione completa di un nodo di staking. Non tutti i partecipanti sceglieranno una o entrambe le opzioni, ma chiunque lo faccia otterrà miglioramenti significativi rispetto alla situazione attuale.
• Ridurre il numero di firme che il livello di consenso di Ethereum deve gestire in ogni slot, anche con la finalità single-slot, portandolo a circa 10.000 firme per slot. Questo aiuterà anche la decentralizzazione, rendendo più facile per chiunque eseguire un nodo validatore.

Per queste soluzioni, è possibile trovare risposte a diversi livelli di astrazione: i permessi concessi agli utenti all’interno del protocollo di proof-of-stake, la scelta degli utenti tra diversi protocolli di proof-of-stake e la loro istituzione a livello di protocollo. Questa scelta dovrebbe essere valutata con attenzione e, in generale, è meglio optare per la soluzione minima praticabile, per ridurre al minimo la complessità del protocollo e le modifiche all’economia del protocollo, pur raggiungendo gli obiettivi desiderati.

Un ringraziamento speciale a Mike Neuder, Justin Drake e altri per i feedback e la revisione. Si veda anche: gli articoli precedenti di Mike Neuder, Dankrad Feist e arixon.eth su argomenti simili.