Una modifica alle specifiche approvata il 26 ottobre chiude un difetto nell'elaborazione dei depositi di Ethereum che avrebbe potuto consentire ai node operator di dirottare i depositi degli staker ancora in coda verso saldi sotto il proprio controllo, una volta attivato l'aggiornamento Glamsterdam della rete. La correzione è approdata nel repository consensus-specs — le regole di riferimento che i team dei client di Ethereum implementano — due settimane dopo che il difetto era stato segnalato su GitHub. Solo i depositi ancora in attesa nella coda al momento dell'attivazione del fork avrebbero potuto essere dirottati, e poiché Glamsterdam non ha raggiunto la mainnet, nessun fondo è andato perduto.

Come un operatore avrebbe potuto impossessarsi del deposito di uno staker

I protocolli di staking in pooling dividono comunemente il lavoro di gestione di un validatore. Il protocollo fornisce l'ETH, mentre un node operator esterno detiene la chiave di firma del validatore. Ethereum tiene separate firma e prelievi, così l'operatore può gestire il validatore senza poter prelevare la stake del protocollo.

Glamsterdam abbina le modifiche del livello di esecuzione a un aggiornamento del livello di consenso chiamato Gloas e aggiunge i builder come nuova tipologia di partecipante nell'ambito della proposer-builder separation inclusa nel protocollo. I builder assemblano la parte dei blocchi contenente le transazioni e detengono i propri saldi. Al fork, Ethereum converte i depositi idonei ancora in attesa nella coda in account builder.

È proprio in quella conversione che risiedeva il difetto. Secondo la regola precedente, una volta che un deposito in sospeso registrava un builder per una chiave, ogni deposito successivo per quella chiave alimentava il builder, indipendentemente da dove puntassero le sue crediali di prelievo. Un operatore poteva mettere in coda un deposito builder per una chiave nuova da un indirizzo da lui controllato. Se il protocollo di staking finanziava poi un deposito validatore per la stessa chiave, ed entrambi erano ancora in sospeso al momento del fork, l'ETH del protocollo sarebbe stato accreditato sul saldo builder dell'operatore, che l'operatore poteva quindi prelevare. Inoltre non sarebbe stato creato alcun validatore. Alcuni protocolli rilasciano il resto della stake solo dopo aver verificato che un nuovo validatore porti le loro credenziali di prelievo, e tale prova non sarebbe mai arrivata.

In un commento successivo, l'autore della segnalazione ha elencato i design che il bug avrebbe potuto sconvolgere: la predeposit guarantee di Lido, OETH di Origin e Saturn di Rocket Pool, segnalando però che l'elenco era frutto di una rapida ricerca assistita dall'AI e poteva contenere errori. In ciascun caso l'esposizione sarebbe stata il primo deposito — 1 ETH negli esempi di Lido e Rocket Pool — con il resto della stake rimasto bloccato fino all'esecuzione delle procedure di recupero. L'autore ha descritto questi casi come risultanze condizionali sul codice, non exploit attivi.

Respinta il 19 ottobre, approvata una settimana dopo

La correzione è stata proposta il 12 ottobre. Dopo la discussione in due call degli sviluppatori core, è stata chiusa il 19 ottobre per mancanza di supporto dai client, e la call di testing aveva suggerito di realizzare un prototipo dopo l'aggiornamento del testnet Hoodi, piuttosto che stravolgere il calendario.

Tre giorni dopo, l'Ethereum Foundation ha rinviato l'attivazione di Glamsterdam su Hoodi per indagare su come EIP-8037 interagisce con gli smart contract esistenti, un problema non correlato ai depositi. Il tempo aggiuntivo ha riaperto il dibattito. Un commento del 23 ottobre all'ordine del giorno della successiva call di testing ha collegato la modifica dei depositi alla nuova tempistica; lo stesso giorno l'autore ha aggiunto test sull'ordine dei depositi, e la modifica è stata approvata il 26 ottobre.

Cosa prevede la nuova regola

Dopo il fork, i depositi builder e validatore seguono già percorsi separati ai sensi dell'EIP-8282. La correzione applica la stessa logica alla coda al momento del fork: sono le credenziali di prelievo, e non la chiave pubblica, a stabilire la destinazione di ciascun deposito in sospeso.

Il riutilizzo di una stessa chiave per un validatore e un builder resta consentito; lo scopo dichiarato in ciascun deposito ora determina quale account viene finanziato.

Cosa deve ancora avvenire prima del fork

L'approvazione delle specifiche è solo il primo passo; i team dei client devono ora implementare la stessa regola. Una modifica a Teku aperta il 27 ottobre era ancora in revisione, e l'equivalente per Lodestar restava aperto.

Una modifica tardiva deve inoltre atterrare in modo identico in ogni client. I test di riferimento più datati codificano il routing precedente, quindi un client che applica la nuova regola li fallisce. L'autore di Teku segnala di aver superato i test generati dalle specifiche aggiornate, che non sono ancora state incluse in una release ufficiale delle specifiche. Se i client arrivassero al fork applicando regole diverse alla stessa coda, calcolerebbero saldi differenti e dissentirebbero sullo stato della catena.

La Foundation non ha fissato una nuova data per Hoodi né per il lancio di Glamsterdam sulla mainnet. I protocolli di staking che si affidano alle prove di deposito dispongono inoltre di una propria linea di difesa: secondo l'autore della segnalazione, i controlli pre-deposito che respingono una chiave già associata a un deposito builder possono prevenire questo scenario. I segnali da monitorare d'ora in poi sono le due pull request ancora aperte dei client, una release delle specifiche che includa i test aggiornati e nuove date per Hoodi e la mainnet.