Correzione del Difetto nella Gestione dei Depositi di Ethereum
Gli sviluppatori di Ethereum hanno implementato una correzione per un difetto nella gestione dei depositi nell’imminente aggiornamento di Glamsterdam. Questo difetto avrebbe potuto consentire a un costruttore di blocchi di ricevere ETH destinato a un nuovo validatore, dopo una decisione iniziale di rifiutare la modifica proposta.
Dettagli della Correzione
Secondo le specifiche di consenso di Ethereum, il manutentore Justin Traglia ha integrato la correzione il 26 ottobre, dopo che lo sviluppatore avsetsin ha identificato un problema nel modo in cui i depositi in attesa sarebbero stati elaborati durante il fork Gloas. La modifica separa i depositi dei costruttori da quelli dei validatori in base alle loro credenziali di prelievo, impedendo che i fondi finiscano nel conto sbagliato quando entrambi utilizzano la stessa chiave pubblica.
È importante sottolineare che la vulnerabilità riguardava regole in fase di sviluppo e non un furto confermato sulla mainnet di Ethereum. Gli sviluppatori hanno incorporato la correzione nelle specifiche, anche se i singoli client di consenso devono ancora implementare e testare il comportamento rivisto.
Origine del Problema
Il problema è emerso da modifiche pianificate nell’ambito della separazione proposta-costruttore di Glamsterdam, che assegna la costruzione dei blocchi e la proposta dei blocchi a ruoli distinti. I costruttori assemblano i payload delle transazioni, mentre i validatori partecipano alla proposta e alla conferma dei blocchi attraverso il sistema di proof-of-stake di Ethereum.
Il ricercatore avsetsin ha descritto il difetto il 12 ottobre, identificando un problema nelle regole utilizzate per elaborare i depositi in attesa quando la rete si aggiorna. Se un costruttore si registrava utilizzando una chiave pubblica prima che un deposito di validatore arrivasse sotto la stessa chiave, la logica proposta avrebbe potuto accreditare entrambi i depositi al costruttore.
Scenario di Rischio
Avsetsin ha delineato uno scenario in cui un operatore di staking riceve fondi da un protocollo di staking liquido per stabilire un nuovo validatore. Registrandosi come costruttore per primo, l’operatore potrebbe causare l’ingresso del deposito del validatore del protocollo nel saldo del costruttore, dove l’indirizzo di prelievo potrebbe essere sotto il controllo dell’operatore.
“L’operatore può prelevare i fondi del protocollo,” ha avvertito avsetsin nel rapporto su GitHub. Poiché il validatore previsto non sarebbe stato creato, il servizio di staking potrebbe avere difficoltà a ottenere la prova necessaria per completare le sue normali procedure di deposito e recupero.
Analisi dei Rischi
Il ricercatore ha esaminato l’esposizione potenziale riguardante Lido, Origin e Rocket Pool attraverso una ricerca preliminare del codice. I risultati erano condizionati a come i singoli protocolli gestivano i depositi, e il rapporto non ha stabilito che i progetti avessero subito un exploit.
La correzione proposta ha inizialmente incontrato resistenza da parte degli sviluppatori di client di Ethereum, nonostante la descrizione del ricercatore del rischio di instradamento dei depositi. Il 19 ottobre, Traglia ha chiuso la richiesta di pull dopo discussioni tra gli sviluppatori principali. “Non c’era abbastanza supporto da parte dei client per apportare questa modifica in questo momento,” ha scritto Traglia.
Implementazione della Correzione
Tuttavia, la decisione non è rimasta in vigore, con gli sviluppatori che hanno riaperto la proposta il 23 ottobre dopo ulteriori esami. Successivamente, il revisore potuz ha approvato l’approccio, ma ha richiesto ulteriori test per combinazioni specifiche di depositi. Avsetsin ha aggiunto quei test il 23 ottobre, coprendo casi in cui i depositi dei costruttori e dei validatori condividono una chiave pubblica ma richiedono una gestione separata.
La modifica finale è stata integrata nelle specifiche di consenso di Ethereum il 26 ottobre, dopo ulteriori revisioni da parte dei client. Essa dirige i depositi validi dei validatori nella coda dei validatori, mentre consente ai legittimi depositi dei costruttori di registrarsi o aggiungere fondi a un costruttore esistente.
Problemi di Compatibilità e Aggiornamenti Futuri
L’aggiornamento delle specifiche è arrivato mentre gli sviluppatori di Ethereum stavano esaminando un problema separato che influenzava l’attivazione programmata di Glamsterdam sulla testnet Hoodi. La Ethereum Foundation ha rinviato l’aggiornamento del 26 ottobre dopo che i ricercatori hanno identificato rischi di compatibilità riguardanti l’EIP-8037.
Come riportato in precedenza da crypto.news sul rinvio, la decisione ha rimosso sia le modifiche all’esecuzione di Amsterdam che le modifiche al consenso di Gloas dall’attivazione programmata di Hoodi. L’aumento proposto a un limite di gas di 200 milioni è stato rinviato con essi.
Il ricercatore di Ethereum Toni Wahrstätter ha spiegato che l’EIP-8037 potrebbe interferire con i contratti intelligenti che si basano su assunzioni riguardanti il gas rimanente durante l’esecuzione. Ha identificato casi in cui la contabilizzazione del gas potrebbe causare il ripristino inaspettato di una transazione o consentire un percorso di esecuzione che gli sviluppatori avevano assunto fosse irraggiungibile.
Il problema di compatibilità dei contratti è distinto dal difetto del deposito del costruttore affrontato nella correzione di GitHub. Entrambi riguardano Glamsterdam, ma il rinvio del 22 ottobre della Fondazione ha citato specificamente ulteriori indagini sull’interazione dell’EIP-8037 con i contratti esistenti.
Glamsterdam è già stato attivato sulla testnet Sepolia il 6 ottobre, dove gli sviluppatori hanno esaminato le modifiche alla costruzione dei blocchi e una maggiore capacità di elaborazione delle transazioni. La successiva prova di Hoodi rimane non programmata, senza una data confermata per l’attivazione sulla mainnet di Ethereum.
La correzione del deposito unita contiene test di regressione che coprono come i depositi vengono classificati durante la transizione Gloas. I team dei client devono incorporare la modifica delle specifiche nel loro software e completare ulteriori test prima che le regole aggiornate possano operare durante un futuro aggiornamento della rete.
