I core developer di Ethereum hanno deciso di non modificare una regola dell’aggiornamento Glamsterdam che, in condizioni molto circoscritte, potrebbe accreditare gli ETH destinati a un nuovo validatore di staking sul saldo di un builder (blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il costruttore di blocchi) controllato da un operatore di nodi. Il problema è stato segnalato il 12 ottobre nella issue n. 5735 del repository consensus-specs da uno sviluppatore che su GitHub usa il nome avsetsin. Il 19 ottobre Justin Traglia, che cura le specifiche, l’ha chiusa come «not planned» (non pianificata) per mancanza di sostegno da parte dei team dei client. Non risultano exploit né perdite. Il rischio di deposito staking in Glamsterdam riguarda soltanto i depositi ancora in coda quando il fork si attiva, e soltanto i protocolli che finanziano validatori gestiti da altri.
Dmitry (Dima) Gusakov, che su GitHub indica come ruolo quello di head of engineering di Lido, titolo che usa anche Crypto Briefing, il 14 ottobre aveva chiesto di discutere la questione nella call degli sviluppatori del livello di consenso (ACDC n. 189) del giorno dopo. Il tema è tornato nella call dedicata ai test (ACDT n. 101) del 19 ottobre. La specifica resta com’è, quindi ora spetta ai protocolli di staking proteggersi nei propri contratti. Glamsterdam arriva sulla testnet Hoodi il 26 ottobre. Per la mainnet non c’è ancora una data.
Il 19 ottobre gli sviluppatori hanno chiuso la correzione, tre giorni dopo averla vista con favore
Traglia ha chiuso la correzione collegata, la pull request n. 5736, alle 16:02 UTC del 19 ottobre, e l’issue tre minuti dopo. Nella nota di chiusura scrive che l’argomento è stato discusso in entrambe le call e che «non c’era abbastanza sostegno da parte dei client per fare questa modifica al momento». Le stesse parole compaiono sulla pull request.
È stato un cambio di rotta. Il 16 ottobre, nel thread dell’agenda della call del 19, Traglia si era detto «leggermente favorevole» alla modifica. Il suo piano la teneva fuori da Hoodi, faceva realizzare un prototipo ai client, la integrava dopo Hoodi, la provava su una devnet di breve durata e non ritardava la mainnet. Aggiungeva che la modifica avrebbe risparmiato a «ogni altro sistema DVT» la necessità di una correzione propria (DVT sta per distributed validator technology: la chiave di un validatore è suddivisa tra più macchine o più operatori).
Chi si sia opposto nelle call, e perché, non è pubblico. Al momento della verifica non erano stati pubblicati appunti scritti delle call del 15 e del 19 ottobre, e nessun team di client né alcun membro della Ethereum Foundation aveva rilasciato dichiarazioni sul rischio. L’unica altra traccia pubblica di uno sviluppatore dei client è una domanda di Michael Sproul, di Lighthouse, del 13 ottobre: voleva sapere se la correzione fosse compatibile con il fork di Sepolia, già avvenuto. Nico Flaig, di Lodestar, ha risposto che su Sepolia l’onboarding dei builder non è mai stato provato, perché il contratto di deposito di quella rete richiede un token speciale.
Builder, depositi ed ePBS: quello che serve sapere per capire il problema
Per fare staking su Ethereum si inviano ETH al contratto di deposito insieme a due dati essenziali: la chiave pubblica del validatore e le sue withdrawal credentials (credenziali di prelievo). Le credenziali indicano dove vanno gli ETH quando escono dallo staking. Quelle che iniziano con 0x01 puntano a un normale indirizzo Ethereum; quelle con 0x02 fanno lo stesso ma consentono di far maturare le ricompense sullo stesso saldo, fino a 2.048 ETH per validatore.
Un deposito non conta subito. Entra in una coda di depositi in attesa, che la catena elabora a ritmo limitato. Il 19 ottobre quella coda conteneva circa 1,2 milioni di ETH e richiedeva circa 21 giorni per svuotarsi, come abbiamo scritto nel nostro articolo sulla coda d’ingresso dello staking. Con una coda così lunga, i depositi inviati settimane prima di un fork possono essere ancora in attesa quando il fork arriva.
I builder sono l’altra metà della storia. Gloas, la parte di consenso di Glamsterdam, introduce la proposer-builder separation integrata nel protocollo (ePBS, EIP-7732, indicata come prevista per l’aggiornamento nella meta-EIP di Glamsterdam), che abbiamo spiegato quando Glamsterdam è andato online su Sepolia. Qui conta una sola conseguenza: i builder hanno un proprio saldo sulla beacon chain. Un builder si registra con un deposito attraverso lo stesso contratto di deposito, usando withdrawal credentials che iniziano con 0xB0.
Al momento del fork c’è quindi un lavoro di smistamento. Quando Gloas si attiva, la catena deve stabilire quali depositi in attesa sono per i validatori e quali creano o finanziano dei builder. È in questa regola di smistamento che si annida il problema.
Rischio deposito staking in Glamsterdam: come il deposito di un validatore finisce sul saldo di un builder
La regola si trova in una funzione di transizione del fork chiamata onboard_builders_from_pending_deposits e smista i depositi in attesa in base alla chiave pubblica. Una volta che un deposito in attesa ha registrato un builder per una certa chiave, ogni deposito successivo per quella stessa chiave va ad aumentare il saldo del builder, qualunque withdrawal credentials porti.
L’issue descrive un protocollo di staking che lavora con operatori di nodi esterni. Il protocollo finanzia il primo deposito dell’operatore per un validatore, poi attende la prova che il validatore esista con le withdrawal credentials del protocollo prima di inviare il resto. Supponiamo che l’operatore metta prima in coda un deposito valido da builder (0xB0, che punta al suo indirizzo) per una chiave nuova, e che anche il deposito da validatore del protocollo (credenziali 0x02) per quella chiave sia in attesa al momento del fork. Nelle parole dell’issue, «entrambi gli importi vanno al builder. L’operatore può prelevare i fondi del protocollo».
Non viene creato alcun validatore. Il protocollo non ottiene la prova che aspettava, può non essere in grado di dimostrare quanto accaduto e rischia di ritrovarsi con una contabilità incoerente o con fondi bloccati, secondo quanto scrive l’issue.
Contano due limiti. Il rischio riguarda soltanto i depositi in attesa a cavallo del fork: dopo Gloas, i depositi da builder e da validatore seguono percorsi separati. E il caso è diverso dal front-running subìto da Lido nel 2021 (vedi più sotto): qui le credenziali del protocollo sono registrate correttamente con il suo deposito, ed è lo smistamento una tantum al fork a ignorarle.
Chi potrebbe essere esposto, secondo un elenco che il suo stesso autore definisce non verificato
Lo scenario richiede un finanziatore diverso dal titolare della chiave, un operatore in grado di inviare un deposito da builder per la stessa chiave e un finanziamento a fasi, con un piccolo deposito prima del resto. Chi fa staking con fondi propri e controlla la propria chiave non rientra nel caso.
In un secondo commento all’issue, lo stesso autore cita tre protocolli che potrebbero essere interessati. Il commento si presenta come una «quick AI research», una ricerca rapida svolta con l’intelligenza artificiale che «può contenere errori». Definisce i risultati letture condizionali del codice, non exploit confermati in produzione, e precisa che non è dimostrato alcun blocco permanente dei fondi. Coindaro non ha verificato queste affermazioni e, al momento della verifica, nessuno dei tre protocolli le aveva confermate pubblicamente. La tabella qui sotto riporta ciò che dice il commento, niente di più.
| Protocollo e prodotto | Che cosa sostiene il commento assistito dall’IA che potrebbe accadere | Via di recupero che suggerisce |
|---|---|---|
| Lido, Predeposit Guarantee usata dagli stVault | Il vault perde il predeposito da 1 ETH; la garanzia da 1 ETH dell’operatore resta bloccata; 31 ETH restano in attesa | Riproporre il predeposito firmato dopo il fork, oppure scollegare il vault e cambiare depositante |
| Origin, strategia di staking nativo di OETH | Il deposito mancante blocca la verifica dei saldi, mentre il vault continua a contare gli ETH persi | Riproporre il deposito firmato |
| Rocket Pool, megapool di Saturn | Il validatore mancante impedisce lo scioglimento rapido; i restanti 31 ETH attendono un timeout | Prima si rimborsa il capitale degli utenti, l’eventuale ammanco diventa debito dell’operatore |
Lo stesso commento afferma che i contratti di verifica di tutti e tre vanno comunque aggiornati per Gloas e per l’EIP-7688, che cambia la struttura dei dati di consenso. Per un approfondimento sui due protocolli che hanno una pagina su Coindaro, vedi i nostri profili di Lido e di Rocket Pool e del suo aggiornamento Saturn.
La pipeline principale di stETH di Lido, cioè i moduli di operatori selezionati, non è citata nell’issue. Crypto Briefing indica il Deposit Security Module di Lido e il suo comitato di guardiani come difesa già esistente e lascia aperta la domanda se coprano i depositi da builder. È una domanda del giornale, non un riscontro, e Lido non aveva fatto dichiarazioni oltre ai commenti di Gusakov al momento della verifica. Nessuno ha indicato una cifra per gli ETH in gioco.
Lido aveva già incontrato una corsa ai depositi simile nel 2021
Il caso nuovo somiglia a uno vecchio. Il 5 ottobre 2021 una segnalazione arrivata tramite il bug bounty di Lido mostrò che un operatore di nodi poteva anticipare i depositi del protocollo (front-running). All’epoca il primo deposito per una chiave ne fissava per sempre le withdrawal credentials, quindi un operatore che depositava per primo con le proprie credenziali poteva impadronirsi di ciò che Lido inviava subito dopo. Lido sospese i depositi dal buffer e, il 14 ottobre 2021, pubblicò la LIP-5, con cui un comitato di guardiani approva i dati di deposito prima che gli ETH si muovano.
Tra le opzioni elencate allora c’era anche una modifica di lungo periodo al livello di consenso. La prima opzione di quell’elenco del 2021 era il predeposito: l’operatore versa 1 ETH con le credenziali del protocollo, il protocollo controlla, poi invia il resto. Cinque anni dopo, è di nuovo quel controllo sul predeposito a essere indicato ai protocolli come difesa.
I controlli sul predeposito sono ora la difesa, più una patch per un client
Il commento successivo dell’autore indica la risposta lato protocollo: «I controlli sul predeposito che rifiutano un precedente deposito da builder possono evitare questo scenario». In pratica, un protocollo dovrebbe cercare un eventuale deposito 0xB0 già presente sulla chiave prima di finanziare il resto.
Alcuni organi di stampa hanno scritto che la correzione respinta avrebbe «aggiunto controlli sul predeposito». La pull request n. 5736 non fa questo. Avrebbe modificato lo smistamento al fork, usando le withdrawal credentials invece della sola chiave:
- i depositi da validatore restano nella coda dei validatori anche se un builder usa la stessa chiave;
- un deposito valido da builder registra o aumenta un builder anche se un validatore usa la stessa chiave;
- un deposito da builder verso un builder già esistente ne aumenta il saldo qualunque sia la sua firma;
- un deposito da builder non valido, senza un builder dietro, resta in coda solo se esiste un validatore con quella chiave o è in coda un precedente deposito valido da validatore, altrimenti viene scartato.
Il lavoro sui client era cominciato prima della chiusura. Flaig ha aperto il 17 ottobre la pull request n. 10428 di Lodestar, che smista i depositi in attesa in base alle withdrawal credentials al momento del fork; al momento della verifica era ancora aperta. Ogni client deve calcolare lo stesso stato al fork, perciò una modifica di questo tipo funziona solo se tutti la adottano attraverso la specifica. Il 12 ottobre Flaig ha aperto anche una pull request sulla propria copia personale del codice core di Lido, per compensare i predepositi assorbiti dai builder. Non è una decisione di Lido.
Hoodi si aggiorna il 26 ottobre, la data della mainnet resta aperta
Il fork Glamsterdam sulla testnet Hoodi è fissato al 26 ottobre alle 17:42:48 UTC, all’epoch 132.352, secondo l’annuncio della Ethereum Foundation del 16 ottobre. Al fork il limite di gas sale a 200 milioni. Le regole di Hoodi sono congelate: sulla correzione, il 16 ottobre Traglia ha scritto che per questa testnet «quella nave è ormai salpata». L’onboarding dei builder al fork non è stato provato quando Sepolia si è aggiornata, il 6 ottobre, secondo Flaig, e Gusakov ha detto che Lido vuole il tempo di provarlo con builder reali su Hoodi.
Per la mainnet la Foundation ha scritto che la data di attivazione «non è ancora stata decisa». Nel thread dell’agenda della call del 15 ottobre, Barnabas Busa della Ethereum Foundation ha proposto due slot, nell’ipotesi che Hoodi vada bene: il 1° dicembre 2026 alle 20:38:47 UTC, oppure l’8 dicembre alle 16:29:11 UTC. Gusakov ha sostenuto la seconda nel pomeriggio: «Dobbiamo ancora fare molti test con builder reali su Hoodi. Quindi l’8 dicembre va benissimo per Lido». Se una delle due date sia stata concordata non è noto; restano entrambe proposte.
La prossima call sul livello di consenso, ACDC n. 190, è il 29 ottobre alle 14:00 UTC, tre giorni dopo Hoodi. Busa ha portato alla call del 15 ottobre anche una questione di depositi distinta: con l’EIP-8365, prevista per il successivo aggiornamento Hegotá, i nuovi depositi verso vecchie credenziali 0x00 verrebbero ignorati e gli ETH bruciati. È un problema diverso dallo smistamento dei builder.
Che cosa cambia per chi detiene stETH, rETH o usa servizi di staking
Per chi detiene token di staking liquido o usa un servizio di staking, finora non è successo nulla. Nessun fondo si è mosso, e il rischio descritto riguarda il modo in cui pochi protocolli finanziano nuovi validatori in una finestra attorno al fork. I protocolli interessati hanno tempo fino alla data della mainnet per aggiungere controlli o adeguare i contratti, e l’issue indica loro il metodo.
Per i lettori italiani vale una precisazione di contesto: i servizi di staking offerti da prestatori di servizi per le cripto-attività autorizzati ai sensi del regolamento MiCA, sotto la vigilanza di Consob e Banca d’Italia, si appoggiano a pipeline di questo genere. Non risulta alcuna iniziativa delle autorità su questo tema.
Lido, Origin e Rocket Pool non avevano detto pubblicamente se siano interessati al momento della verifica. I prossimi punti fermi sono il fork di Hoodi del 26 ottobre e la call del 29 ottobre, in cui potrebbe essere scelta una data per la mainnet.