Un bug in staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">Reth, 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 client di esecuzione di Ethereum sviluppato da Paradigm, poteva far calcolare a un nodo uno state root sbagliato, e le reti che lo usano hanno rilasciato correzioni tra il 4 e il 6 novembre 2026. Base, BSC-Reth di BNB Chain e la blockchain Tempo hanno pubblicato versioni corrette, mentre il direttore tecnico di Paradigm ha chiesto di aggiornare anche a chi gestisce op-reth di Optimism. Base dice di aver controllato il proprio state root attuale e che «gli utenti non sono stati colpiti». Nessuna fonte riferisce perdite di fondi, exploit o interruzioni del servizio.
I primi titoli parlavano di un bug di Ethereum. È una formula troppo larga. Il difetto stava in un solo client, nel percorso che la nota di rilascio di BNB Chain chiama calcolo dello state root «legacy». Non riguardava il protocollo Ethereum e non riguardava Geth, il client di esecuzione più diffuso. Nessuna fonte indica come coinvolta Arbitrum, che usa un proprio software, Nitro, basato su Geth, e Arbitrum non ha rilasciato dichiarazioni.
Gli effetti a catena sono stati precauzioni. LayerZero ha sospeso alcune rotte cross-chain e il risk manager Gauntlet ha limitato i depositi in alcuni vault, secondo quanto riportato dalla stampa. Alle 07:30 UTC del 7 novembre LayerZero non aveva pubblicato alcuna dichiarazione propria sulla sospensione né sulla data di ripartenza delle rotte.
Il bug di Reth: un nodo poteva sbagliare lo state root
Ogni blocco di Ethereum, e delle reti layer 2 costruite sopra, si impegna su uno state root: un unico hash che riassume il saldo di ogni account e lo storage di ogni contratto dopo l’esecuzione delle transazioni del blocco. Ogni nodo lo ricalcola. Un nodo che ottiene un numero diverso è in disaccordo con la catena: può smettere di seguirla oppure, se costruisce blocchi, produrne uno che gli altri nodi rifiutano. La nostra guida su che cosa fa un nodo blockchain spiega i controlli coinvolti.
La pagina di stato di Base afferma che il bug di Reth «could, in some cases, make a node compute an incorrect state root», cioè poteva, in alcuni casi, far calcolare a un nodo uno state root errato. La nota di BNB Chain colloca il problema nel percorso di calcolo legacy, «in specifiche condizioni del trie». CryptoSlate è andata oltre il 6 novembre, scrivendo che certe configurazioni dello storage degli smart contract potevano far scattare il difetto, che una transazione costruita ad hoc poteva attivarlo in condizioni particolari e che il software di costruzione dei blocchi usava il metodo vulnerabile su hardware di fascia bassa e nelle reti OP Stack. Nessun documento primario conferma il punto sulla transazione costruita ad hoc. Se qualcuno avrebbe potuto sfruttare il difetto di proposito non è noto.
La preoccupazione andava oltre un singolo nodo fuori sincrono. I sistemi di prova e alcuni bridge si basano sugli state root per stabilire che cosa sia accaduto su una catena, ed è per questo che l’avviso di Konstantopoulos citava i bridge DeFi e i «sistemi basati su prove di stato». Secondo CryptoSlate, ha detto anche che la maggior parte dei bridge si affida a receipt root o all’approvazione multisig e non al calcolo interessato. La pagina di stato di Base dice che il suo sistema di prova verifica ogni state root con un’implementazione indipendente. TokenPost ha definito il difetto «un problema di correttezza del client, non un attacco noto».
Una correzione che non diceva che cosa correggeva
La modifica al codice è arrivata per prima, e in silenzio. La pull request #28264 sul GitHub di Reth, intitolata «fix(trie): tighten iterator seek boundary», è stata aperta alle 20:13 UTC del 3 novembre e integrata alle 21:00 UTC. Tocca un solo file, con 79 righe aggiunte e 12 rimosse. La descrizione parla di come un iteratore decide dove cercare al confine di un ramo in cache e aggiunge un test di regressione. Non c’è alcuna etichetta e nemmeno una parola sulla sicurezza.
La pagina di stato di Base fa risalire la scoperta al 4 novembre, e Base dice di aver applicato quel giorno una mitigazione a tutti i suoi block builder. Il 5 novembre sono usciti tre rilasci nel giro di circa 70 minuti. Paradigm ha descritto Reth v2.10.0 come una «hardening release» con priorità di aggiornamento alta per ogni tipo di nodo, e ha elencato la correzione sotto Engine & Trie. Le note non usano mai le parole state root o sicurezza.
| Ora (UTC) | Chi | Che cosa |
|---|---|---|
| 3 nov, 21:00 | Paradigm (Reth) | Pull request #28264 integrata |
| 4 nov | Base | Bug individuato, mitigazione applicata ai suoi block builder |
| 5 nov, 15:10 | Optimism | Rilasciato op-reth v2.8.1 |
| 5 nov, 16:01 | Base | Nodo v1.5.3: «Prevents a state root mismatch» |
| 5 nov, 16:18 | Paradigm (Reth) | Reth v2.10.0, «hardening release» |
| 5 nov, 17:52 | Base | La pagina di stato chiede agli operatori di aggiornare |
| 5 nov, 22:17 | Georgios Konstantopoulos | Avviso pubblico su X |
| 6 nov, 02:53 | BNB Chain | BSC-Reth v0.1.4-hotfix |
| 6 nov, 18:13 | Tempo | v1.18.2, priorità alta per i validatori |
| 6 nov, 18:53 | Paradigm (Reth) | Rilascio di manutenzione v2.10.1, il bug non è citato |
Unchained ha contato circa 43 ore tra l’integrazione della correzione e l’avviso pubblico di Base. Al 7 novembre non c’era alcun security advisory GitHub sul repository di Reth, nessuna fonte citava un numero CVE e Paradigm non aveva pubblicato un post-mortem.
L’avviso di Konstantopoulos e una nota di rilascio che tace
L’allarme pubblico è arrivato a tarda sera del 5 novembre. Alle 22:17 UTC Georgios Konstantopoulos, direttore tecnico di Paradigm, ha pubblicato su X un avviso: una correzione era stata distribuita in tutto l’ecosistema Reth, così che i nodi basati su Reth, i bridge DeFi e i sistemi basati su prove di stato «sono tutti al sicuro». Ha chiesto a chiunque dipenda da Reth di passare a Reth v2.10.0, OP Reth v2.8.1 e Base v1.5.3.
CryptoSlate ha riferito che nello stesso thread descriveva un caso limite nel codice legacy dello state root di Reth, si scusava per i disagi, diceva che i sistemi di prelievo di Base e delle altre catene OP Stack non erano esposti e che Optimism aveva ricevuto una patch. Coindaro non ha potuto leggere il thread per intero, quindi questi punti poggiano sul racconto di CryptoSlate.
Un dettaglio non torna. Le note di op-reth v2.8.1 chiedono a tutti gli operatori di aggiornare, ma descrivono soltanto una correzione alla chiamata RPC eth_capabilities. Non dicono nulla sugli state root, benché il rilascio comprenda 153 commit rispetto alla v2.8.0. L’affermazione che contenga la correzione del trie si regge quindi sul post di Konstantopoulos e sulle cronache. Non abbiamo trovato nemmeno un avviso di stato di Optimism; la nostra pagina su OP Mainnet e la Superchain spiega chi mantiene quel software.
Base, BNB Chain e Tempo: chi ha corretto e che cosa ha detto
Base: niente risincronizzazione, e il rischio di blocco eliminato
Il rilascio v1.5.3 del nodo Base dichiara di «prevenire uno state root mismatch» e indica l’aggiornamento come raccomandato, senza scadenza e senza modifiche incompatibili. La pagina di stato di Base ha aperto una voce di manutenzione alle 16:19 UTC del 5 novembre e, alle 17:52 UTC, ha chiesto agli operatori di aggiornare i nodi il prima possibile. Precisa che non serve alcuna risincronizzazione e che il rilascio elimina il rischio che i validatori di Base si blocchino davanti a uno state root non valido.
«Abbiamo verificato che lo state root attuale è corretto e che gli utenti non sono stati colpiti», ha scritto Base. La voce indica una finestra che arriva alle 16:19 UTC del 7 novembre e non mostra alcun aggiornamento di chiusura. Un ritardo nell’inclusione delle transazioni del 2 novembre, separato, e l’aggiornamento Denim del 5 novembre non sono legati a questo bug.
BNB Chain: un hotfix per ogni operatore BSC-Reth
BNB Chain ha pubblicato BSC-Reth v0.1.4-hotfix alle 02:53 UTC del 6 novembre. Le note dicono che integra la correzione di Reth a monte e che non servono né migrazioni del database né hard fork. Chiedono di aggiornare a validatori, builder MEV, full node e sentry che usano reth-bsc. In un post su X citato da crypto.news, BNB Chain ha scritto che «opBNB non usa op-reth e l’impatto su BSC-Reth è limitato».
Tempo: il team che forse l’ha trovato
Tempo, la blockchain per i pagamenti in stablecoin incubata da Stripe, ha rilasciato la v1.18.2 alle 18:13 UTC del 6 novembre, con priorità alta per i validatori e una riga che dice che aggiorna Reth con una correzione per le ricerche dell’iteratore del trie. Tempo è una catena layer 1, non un layer 2; il nostro approfondimento sulla differenza tra layer 1 e layer 2 spiega perché la distinzione conta.
CryptoSlate riferisce che il team di Tempo ha trovato il bug tramite fuzzing, un metodo di test che lancia enormi quantità di input casuali contro un software per farlo fallire. Nessun’altra fonte che abbiamo letto lo dice, e la pagina di Base registra la scoperta al 4 novembre senza nominare chi l’abbia fatta.
LayerZero ha sospeso le rotte, e i bridge si sono innervositi
LayerZero, il protocollo di messaggistica che molti bridge di token usano, ha sospeso «alcune rotte cross-chain in via precauzionale», che «dovrebbero riprendere presto», secondo un post di Frax su X che Unchained ha citato il 5 novembre. Frax l’ha poi cancellato. TokenPost ha scritto il 7 novembre che LayerZero ha sospeso parti della propria infrastruttura off-chain per alcune reti EVM e che i messaggi sono stati ritardati, non persi. Nessuna dichiarazione di LayerZero indica un orario di inizio, un elenco di rotte o una ripartenza. CryptoSlate osserva che la sospensione non dimostra che i contratti di LayerZero fossero vulnerabili.
Gauntlet, il curatore del rischio, ha limitato i depositi nei suoi vault V1, ha sospeso le allocazioni e ha ridotto l’esposizione agli asset trasferiti tramite LayerZero, secondo The Defiant, il cui riassunto dice che a conoscenza di Gauntlet non era stato segnalato alcun exploit. Unchained, riprendendo quel resoconto, ha aggiunto che i prelievi sono rimasti aperti. Il post di Gauntlet su X è stato cancellato, quindi questi dettagli poggiano sulle due testate.
I bridge hanno motivo di essere nervosi. Ad aprile l’exploit da 292 milioni di dollari del bridge rsETH di Kelp DAO, che LayerZero ha attribuito al gruppo nordcoreano Lazarus, ha messo sotto sospetto l’infrastruttura cross-chain. Unchained ha tracciato il parallelo, e nessuna fonte collega i due eventi. La nostra pagina del progetto LayerZero racconta che cosa ha cambiato l’attacco a Kelp. Il piano di ApeChain di spostare i propri asset da LayerZero a Chainlink CCIP è stato annunciato il 4 novembre, prima degli avvisi su Reth, ha riportato crypto.news.
Il secondo bug sullo state root di Reth in 14 mesi
Reth c’era già passato. Il 2 settembre 2025 un diverso bug sullo state root aveva bloccato alcuni nodi della mainnet Ethereum con Reth 1.6.0 e 1.4.8, come ha riferito The Block il giorno dopo. Anche allora Konstantopoulos condivise i comandi di ripristino. The Block citava dati di Ethernodes che davano a Reth il 5,4% dei client del livello di esecuzione all’epoca, e diceva che solo una piccola quota di nodi sembrava colpita. Nessuna fonte fornisce una cifra attuale.
Una quota piccola è ciò che permette alla mainnet di Ethereum di assorbire il bug di un solo client: i nodi con Geth e con gli altri client continuano a calcolare la radice giusta e la catena va avanti. Un layer 2 i cui block builder usano tutti lo stesso client non ha un simile cuscinetto, ed è per questo che Base ha indicato la propria implementazione di prova indipendente quando ha detto che gli utenti non erano stati colpiti.
Anche il software di prova ha avuto i suoi spaventi quest’autunno. A ottobre Succinct ha corretto un bug di SP1 che lasciava passare prove non valide nel suo verificatore Rust, senza conseguenze sui controlli on-chain.
Che cosa non si sa ancora e che cosa tenere d’occhio
Paradigm non ha pubblicato né un post-mortem, né un advisory, né una descrizione tecnica dell’esatto innesco. Nessuno ha detto se il bug sia mai stato colpito su una rete attiva, quanti nodi usassero versioni interessate o se catene OP Stack come Unichain o Ink siano state colpite oppure soltanto aggiornate.
I prossimi segnali sono un post-mortem o un security advisory di Paradigm e una parola di LayerZero sul fatto che le sue rotte funzionino di nuovo. La finestra di manutenzione di Base si chiude oggi alle 16:19 UTC.
I nodi rimasti sul vecchio codice sono il rischio residuo. Blockaid ha avvertito, come riferito da Unchained, che potrebbero bloccarsi o restituire prove di stato errate. I progetti hanno chiesto agli operatori di passare a Reth v2.10.0 o successive, op-reth v2.8.1, Base v1.5.3, BSC-Reth v0.1.4-hotfix o Tempo v1.18.2.