Gli sviluppatori del protocollo hanno neutralizzato con successo una vulnerabilità nelle specifiche di consenso della rete prima del suo rilascio definitivo. Il team principale ha implementato una modifica tecnica che impedisce che i fondi dei nuovi validatori vengano allocati in modo errato ai costruttori di blocchi durante il previsto hard fork di Glamsterdam.
Questo adeguamento architetturale giunge dopo un intenso dibattito all'interno della comunità tecnica. Grazie a una pausa nel programma di test, i team di ricerca hanno identificato il rischio in tempo, proteggendo i fornitori di staking di liquidità prima che i fondi potessero essere compromessi.
La vulnerabilità rilevata nell'aggiornamento di Glamsterdam
Il nucleo della rete si sta preparando per una delle sue transizioni tecniche più profonde con l'arrivo di Glamsterdam. Questo aggiornamento introduce una divisione strutturale dei ruoli tra due attori fondamentali nell'ecosistema: i costruttori di blocchi (costruttori), responsabili del raggruppamento e dell'ordinamento delle transazioni, e i validatori, la cui funzione è quella di proporre e certificare questi blocchi per mantenere il consenso. Tuttavia, un'analisi della sicurezza ha rivelato che Gli sviluppatori di Ethereum hanno corretto un bug in Glamsterdam che avrebbe permesso di dirottare i depositi di staking verso i costruttori. durante l'elaborazione delle transazioni in sospeso.
Il problema risiedeva nel modo in cui le specifiche di consenso preliminari gestivano le chiavi pubbliche condivise. In uno scenario specifico analizzato durante i test tecnici dell'ottobre 2026, un operatore malintenzionato poteva inizialmente registrarsi come costruttore utilizzando una determinata chiave pubblica. Se un protocollo o un utente inviava successivamente un deposito per attivare un nodo validatore utilizzando la stessa chiave identificativa, le regole preliminari accreditavano l'intero saldo al costruttore. Ciò lasciava l'entità mittente senza i mezzi tecnici per generare le prove crittografiche necessarie per prelevare o recuperare il proprio capitale, consentendo all'operatore del nodo costruttore di ritirare i fondi trasferiti.
Il ruolo dei protocolli di staking e della ricerca tecnica
L'anomalia è stata portata alla luce dal ricercatore tecnico avsetsin, affiliato all'organizzazione tecnica di Lido. Lo specialista ha valutato il potenziale impatto su diverse soluzioni all'interno dell'ecosistema, tra cui Lido, Rocket Pool e Origin Protocol. Sebbene si trattasse di vulnerabilità riscontrate nel codice e non di exploit eseguiti sulla rete principale, la possibilità teorica di dirottamento dei depositi rappresentava una minaccia alla sicurezza che non poteva essere ignorata in un ambiente decentralizzato ad alto rischio.
Per comprendere l'importanza di questo meccanismo, è utile rivedere i fondamenti tecnici disponibili su piattaforme educative come Accademia Bit2MeQuesto articolo analizza il funzionamento del meccanismo di consenso Proof of Stake. In Ethereum, ogni validatore deve impegnare 32 ETH per partecipare alla validazione e i fornitori di staking aggregano i depositi di migliaia di singoli utenti. Se il livello di consenso identifica erroneamente la proprietà dei depositi in sospeso quando viene applicato un hard fork, gli smart contract su queste piattaforme non dispongono di meccanismi nativi per annullare l'allocazione a livello di base. Il tempestivo intervento dei revisori ha impedito che l'errore progredisse fino alle fasi di integrazione più avanzate nel software client.
Dal rifiuto iniziale all'integrazione finale nel codice
Il processo per risolvere questo difetto tecnico ha comportato alcune difficoltà tecniche tra i responsabili del repository delle specifiche e i team che sviluppavano i client della rete. La soluzione proposta è stata temporaneamente sospesa il 19 ottobre, dopo che Justin Traglia, uno dei principali contributori alle specifiche di consenso, ha segnalato una mancanza di supporto da parte dei team client per implementare la modifica in quel momento. Diversi sviluppatori ritenevano che i filtri già presenti negli smart contract mitigassero la possibilità di registrare chiavi duplicate.
Tuttavia, l'estensione del periodo di test ha consentito simulazioni più approfondite. Il 23 ottobre, ulteriori test sono stati incorporati nel repository, dimostrando la necessità di una regola deterministica nel livello di consenso. Infine, la modifica è stata approvata e formalmente unita il lunedì successivo. Con la nuova logica, tutti i depositi in coda sono classificati rigorosamente in base alle loro credenziali di prelievo (credenziali di prelievoCiò garantisce che, anche qualora un costruttore e un validatore utilizzino la stessa chiave pubblica, i fondi destinati alla validazione rimangano allocati esclusivamente all'indirizzo di prelievo configurato dal depositante legittimo.
Programma di implementazione per le reti di test e la rete principale
Risolvere questa discrepanza nelle specifiche teoriche non significa che l'aggiornamento sia immediatamente pronto per l'attivazione generale. I vari team responsabili del software di validazione, inclusi i client di esecuzione e di consenso, devono adattare il loro codice sorgente a queste nuove specifiche prima che Glamsterdam possa proseguire con la sua roadmap verso la mainnet.
In termini di implementazione pratica, Glamsterdam ha già completato una fase di test iniziale sulla rete Sepolia. Tuttavia, il suo lancio, previsto per il 26 ottobre sulla testnet di Hoodi, ha dovuto essere posticipato per consentire la revisione della sicurezza dei contratti preesistenti e l'integrazione di questa correzione relativa ai depositi. Fino a quando la comunità tecnica non convaliderà il comportamento delle nuove credenziali di prelievo su Hoodi e non stabilirà una data definitiva per tale rete, l'implementazione sulla mainnet non verrà programmata. EthereumQuesto rigore tecnico riflette l'impegno dell'ecosistema per la stabilità dei fondi istituzionali e al dettaglio che sono alla base dell'infrastruttura.
Impatto della sicurezza sull'infrastruttura crittografica ai sensi di MiCA
La robustezza tecnica dei protocolli sottostanti è un fattore determinante per gli enti regolamentati nell'Unione Europea. Ai sensi del Regolamento MiCA, i fornitori di servizi di criptovalute devono garantire una gestione del rischio completa, verificata e trasparente su tutte le piattaforme e reti su cui operano i loro clienti. I potenziali incidenti a livello del meccanismo di consenso delle blockchain principali richiedono un monitoraggio costante da parte degli operatori autorizzati.
Nei mercati europei e spagnoli, la custodia e il supporto degli asset legati allo staking richiedono rigorosi standard di due diligence. L'individuazione e la correzione delle vulnerabilità nelle fasi di pre-implementazione della mainnet tutelano l'integrità del mercato e rafforzano la fiducia nei modelli decentralizzati basati sulla validazione. Per i responsabili delle decisioni analizzare le notizie attuali sulle criptovalute Dal punto di vista tecnico, la reattività dimostrata dagli ingegneri di Ethereum sottolinea la maturità dei processi di governance del software aperto di fronte a guasti potenzialmente critici.
Domande frequenti
Quali sono state le cause esatte del problema con l'aggiornamento di Glamsterdam?
Il bug consentiva una situazione in cui, se un operatore si registrava come costruttore di blocchi con una chiave pubblica e poi effettuava un deposito come validatore utilizzando la stessa chiave, entrambi i fondi venivano assegnati al costruttore. Ciò impediva al validatore di recuperare il proprio deposito originale.
Questa vulnerabilità ha comportato una perdita effettiva di fondi?
Non sono state segnalate perdite finanziarie sulla rete. La vulnerabilità è stata scoperta in modo proattivo nel repository delle specifiche teoriche e negli ambienti di test, consentendo l'implementazione della correzione prima del suo rilascio sulla rete principale.
In che modo il nuovo codice risolve il problema dell'assegnazione dei depositi?
La soluzione approvata categorizza i depositi in sospeso utilizzando le credenziali di prelievo. In questo modo, i fondi destinati alla convalida rimangono separati da quelli utilizzati dagli sviluppatori, indipendentemente dalla chiave pubblica utilizzata durante la registrazione al protocollo.
Quando verrà attivato Glamsterdam sulla rete principale di Ethereum?
La data per la rete principale non è ancora stata fissata. Gli sviluppatori devono prima completare i test sulla rete Hoodi, che sono stati riprogrammati dopo diversi aggiornamenti di sicurezza, prima che i clienti del software coordinino l'aggiornamento finale.
L'individuazione e la risoluzione tempestiva di questo bug a Glamsterdam evidenziano l'importanza fondamentale di un'accurata verifica e di test nello sviluppo di reti decentralizzate. Grazie alla collaborazione attiva tra ricercatori esterni e i manutentori del protocollo, Ethereum rafforza le proprie difese contro potenziali vettori di conflitto nell'allocazione del capitale.
Man mano che la rete si evolve verso una separazione più sofisticata dei ruoli di validazione e costruzione dei blocchi, la stabilità operativa continuerà a essere il pilastro imprescindibile per garantire la sicurezza degli utenti e delle piattaforme che interagiscono quotidianamente con la tecnologia degli smart contract.
Gli investimenti in criptovalute non sono completamente regolamentati, potrebbero non essere adatti agli investitori al dettaglio a causa dell'elevata volatilità e sussiste il rischio di perdere tutti gli importi investiti.
Per la creazione di questo articolo sono stati utilizzati strumenti di intelligenza artificiale generativa.
