Gli sviluppatori di Ethereum hanno implementato una correzione per un difetto nella gestione dei depositi nell’imminente aggiornamento di Glamsterdam<\/strong>. Questo difetto avrebbe potuto consentire a un costruttore di blocchi di ricevere ETH<\/strong> destinato a un nuovo validatore, dopo una decisione iniziale di rifiutare la modifica proposta.<\/p>\n Secondo le specifiche di consenso di Ethereum, il manutentore Justin Traglia<\/strong> ha integrato la correzione il 26 ottobre<\/strong>, dopo che lo sviluppatore avsetsin<\/strong> ha identificato un problema nel modo in cui i depositi in attesa sarebbero stati elaborati durante il fork Gloas<\/strong>. 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.<\/p>\n \u00c8 importante sottolineare che la vulnerabilit\u00e0 riguardava regole in fase di sviluppo e non un furto confermato sulla mainnet di Ethereum.<\/em> Gli sviluppatori hanno incorporato la correzione nelle specifiche, anche se i singoli client di consenso devono ancora implementare e testare il comportamento rivisto.<\/p>\n Il problema \u00e8 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<\/strong> di Ethereum.<\/p>\n Il ricercatore avsetsin<\/strong> ha descritto il difetto il 12 ottobre<\/strong>, 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.<\/p>\n 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.<\/p>\n<\/blockquote>\n “L’operatore pu\u00f2 prelevare i fondi del protocollo,” ha avvertito avsetsin nel rapporto su GitHub. Poich\u00e9 il validatore previsto non sarebbe stato creato, il servizio di staking potrebbe avere difficolt\u00e0 a ottenere la prova necessaria per completare le sue normali procedure di deposito e recupero.<\/p>\n Il ricercatore ha esaminato l’esposizione potenziale riguardante Lido<\/strong>, Origin<\/strong> e Rocket Pool<\/strong> 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.<\/p>\n 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<\/strong>, 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.<\/p>\n Tuttavia, la decisione non \u00e8 rimasta in vigore, con gli sviluppatori che hanno riaperto la proposta il 23 ottobre<\/strong> dopo ulteriori esami. Successivamente, il revisore potuz<\/strong> ha approvato l’approccio, ma ha richiesto ulteriori test per combinazioni specifiche di depositi. Avsetsin ha aggiunto quei test il 23 ottobre<\/strong>, coprendo casi in cui i depositi dei costruttori e dei validatori condividono una chiave pubblica ma richiedono una gestione separata.<\/p>\n La modifica finale \u00e8 stata integrata nelle specifiche di consenso di Ethereum il 26 ottobre<\/strong>, 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.<\/p>\n L’aggiornamento delle specifiche \u00e8 arrivato mentre gli sviluppatori di Ethereum stavano esaminando un problema separato che influenzava l’attivazione programmata di Glamsterdam sulla testnet Hoodi<\/strong>. La Ethereum Foundation ha rinviato l’aggiornamento del 26 ottobre<\/strong> dopo che i ricercatori hanno identificato rischi di compatibilit\u00e0 riguardanti l’EIP-8037<\/strong>.<\/p>\n 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<\/strong> \u00e8 stato rinviato con essi.<\/p>\n Il ricercatore di Ethereum Toni Wahrst\u00e4tter<\/strong> 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.<\/p>\n Il problema di compatibilit\u00e0 dei contratti \u00e8 distinto dal difetto del deposito del costruttore affrontato nella correzione di GitHub. Entrambi riguardano Glamsterdam, ma il rinvio del 22 ottobre<\/strong> della Fondazione ha citato specificamente ulteriori indagini sull’interazione dell’EIP-8037 con i contratti esistenti.<\/p>\n Glamsterdam \u00e8 gi\u00e0 stato attivato sulla testnet Sepolia<\/strong> il 6 ottobre<\/strong>, dove gli sviluppatori hanno esaminato le modifiche alla costruzione dei blocchi e una maggiore capacit\u00e0 di elaborazione delle transazioni. La successiva prova di Hoodi rimane non programmata, senza una data confermata per l’attivazione sulla mainnet di Ethereum.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.<\/p>\n","protected":false},"author":3,"featured_media":19791,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[11061,13,2848,8862,1377,11191],"class_list":["post-19792","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ethereum","tag-eip-8037","tag-ethereum","tag-glamsterdam","tag-hoodi","tag-lido","tag-rocket-pool"],"yoast_description":"Gli sviluppatori di Ethereum hanno risolto un difetto critico nell'aggiornamento di Glamsterdam per prevenire la cattiva allocazione dei depositi per i validatori, garantendo cos\u00ec la sicurezza della rete.","_links":{"self":[{"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/posts\/19792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/comments?post=19792"}],"version-history":[{"count":0,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/posts\/19792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/media\/19791"}],"wp:attachment":[{"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/media?parent=19792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/categories?post=19792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/satoshibrother.com\/it\/wp-json\/wp\/v2\/tags?post=19792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Dettagli della Correzione<\/h2>\n
Origine del Problema<\/h2>\n
Scenario di Rischio<\/h2>\n
\n
Analisi dei Rischi<\/h2>\n
Implementazione della Correzione<\/h2>\n
Problemi di Compatibilit\u00e0 e Aggiornamenti Futuri<\/h2>\n