Sicurezza delle transazioni Ethereum, la Foundation studia nuovi controlli per impedire operazioni con risultati inattesi
Una transazione Ethereum può essere firmata correttamente, superare tutti i controlli previsti dal protocollo e provocare comunque una perdita economica che l’utente non aveva intenzione di autorizzare. Il problema riguarda la differenza tra il contenuto di un’operazione e i suoi effetti effettivi sulla blockchain. Una firma digitale certifica l’autorizzazione a eseguire determinate istruzioni, ma non garantisce necessariamente che il risultato corrisponda alle aspettative di chi le ha approvate.
Il 5 ottobre 2026, la Ethereum Foundation ha dedicato un approfondimento a questa criticità, presentando le native transaction assertions come una possibile soluzione tecnica. L’obiettivo è consentire alle transazioni di includere condizioni verificabili sul loro risultato finale, impedendo che modifiche indesiderate vengano confermate sulla blockchain.
La ricerca prende in esame la proposta EIP-7906, denominata Transaction Assertions via State Diff Opcode, che introduce nuovi strumenti per controllare le conseguenze delle operazioni eseguite dalla Ethereum Virtual Machine (EVM).
La proposta è ancora in fase di standardizzazione e non costituisce una funzionalità già disponibile sulla rete principale Ethereum. Il suo sviluppo rientra nelle attività della Trillion Dollar Security Initiative, il programma attraverso cui la Foundation affronta alcune delle principali vulnerabilità che ostacolano l’utilizzo della blockchain da parte di utenti, imprese e istituzioni finanziarie.
Quando una transazione valida produce un risultato sbagliato
Il funzionamento degli smart contract rende particolarmente delicata la sicurezza delle transazioni Ethereum. Quando un utente autorizza un’operazione, firma informazioni che identificano il destinatario, l’eventuale valore trasferito e le istruzioni da eseguire.
Il risultato dipende però anche dalle condizioni della blockchain nel momento in cui la transazione viene elaborata. Il contenuto di uno smart contract, i saldi disponibili, la liquidità di un mercato decentralizzato e le autorizzazioni già concesse possono influenzare gli effetti finali.
Tra la firma e l’inclusione in un blocco possono intervenire altre operazioni. Una transazione diretta a uno scambio decentralizzato, ad esempio, potrebbe essere eseguita quando il prezzo di un token è cambiato rispetto a quello osservato inizialmente.
Gli stessi meccanismi di aggiornamento dei contratti possono creare situazioni differenti da quelle previste. Se un’applicazione utilizza un proxy, il codice effettivamente eseguito potrebbe essere modificato prima che una transazione venga confermata.
Il problema emerge anche quando l’utente autorizza una richiesta diversa da quella che ritiene di aver approvato.
Nell’approfondimento del 5 ottobre, la Ethereum Foundation distingue due categorie di rischio. La prima riguarda il disallineamento tra l’intenzione dell’utente e le istruzioni effettivamente firmate. La seconda interessa le operazioni autorizzate correttamente che producono conseguenze economiche inattese.
La distinzione è rilevante perché richiede strumenti di protezione differenti. Mostrare con maggiore chiarezza il contenuto di una richiesta può aiutare a individuare istruzioni sospette, mentre impedire un risultato economicamente dannoso richiede controlli sulle condizioni effettive dell’esecuzione.
Dai casi Bybit e BadgerDAO alle perdite negli scambi decentralizzati
La Foundation richiama alcuni incidenti già conosciuti per spiegare quali problemi potrebbero essere affrontati con controlli più rigorosi.
Nel caso dell’attacco a Bybit, nel febbraio 2025, i firmatari coinvolti nelle operazioni del wallet hanno autorizzato una modifica che ha consentito agli aggressori di assumere il controllo dei fondi. Le informazioni presentate durante il processo di approvazione non corrispondevano alle effettive conseguenze delle istruzioni firmate.
Un problema legato alla compromissione dell’interfaccia si era verificato anche nell’attacco a BadgerDAO, quando alcuni utenti erano stati indotti a concedere autorizzazioni sui propri token a soggetti non legittimati.
La ricerca cita inoltre un’operazione effettuata attraverso Aave e CoW Protocol, nella quale un utente aveva tentato di scambiare circa 50,4 milioni di dollari in token aEthUSDT con aEthAAVE.
La liquidità disponibile non era sufficiente per sostenere uno scambio di quelle dimensioni a condizioni economicamente ragionevoli. Le verifiche del sistema avevano escluso alcune quotazioni più complesse a causa dei limiti di gas, lasciando disponibile un risultato estremamente sfavorevole.
L’interfaccia aveva segnalato un impatto sul prezzo del 99,9% e richiesto una conferma esplicita del rischio. L’operazione è stata comunque autorizzata, producendo un risultato valutato intorno a 36.000 dollari.
In quest’ultimo episodio non si trattava di una firma nascosta dietro istruzioni differenti da quelle mostrate. L’utente aveva confermato un’operazione accompagnata da avvertimenti particolarmente evidenti.
Il caso dimostra che la sicurezza delle transazioni Ethereum non può essere affidata esclusivamente alla visualizzazione di messaggi di conferma. Una protezione aggiuntiva potrebbe consistere nell’imporre un valore minimo da ricevere, stabilito indipendentemente dalla quotazione generata dall’applicazione.
Questi incidenti costituiscono esempi utilizzati per motivare la ricerca. Non rappresentano prove di sfruttamento di una vulnerabilità contenuta nell’EIP-7906, né dimostrano che la proposta avrebbe necessariamente impedito gli attacchi nelle condizioni tecniche in cui si sono verificati.
Come funzionerebbero le native transaction assertions
Il principio delle transaction assertions consiste nell’associare a un’operazione condizioni che devono risultare vere anche dopo l’esecuzione delle istruzioni autorizzate.
Un wallet potrebbe richiedere, ad esempio, che un trasferimento non superi una determinata quantità di token. Un’applicazione di scambio potrebbe imporre che la quantità ricevuta non scenda sotto una soglia prestabilita. Un conto gestito attraverso smart contract potrebbe impedire modifiche non autorizzate alle proprie regole di controllo.
Queste condizioni dovrebbero essere verificate direttamente durante l’elaborazione della transazione.
Se il risultato non rispettasse la regola prevista, le modifiche prodotte dalla parte esecutiva verrebbero annullate. L’operazione risulterebbe fallita, evitando che gli effetti vietati dall’assertion diventino definitivi.
Il controllo si sposterebbe quindi dalle sole istruzioni autorizzate alle conseguenze effettive della loro esecuzione.
La distinzione rispetto ai normali avvertimenti visualizzati dal wallet è sostanziale. Una simulazione può prevedere il risultato di una transazione, ma lavora sulle condizioni della blockchain disponibili nel momento in cui viene effettuata.
Le assertions, invece, sarebbero eseguite all’interno del processo che determina il risultato della transazione stessa.
Questo consentirebbe di individuare anche alcune differenze emerse tra la simulazione iniziale e l’esecuzione effettiva, purché siano coperte dalle condizioni di controllo impostate.
La protezione non sarebbe comunque automatica. Le regole dovrebbero essere formulate correttamente e incluse nell’operazione. Un controllo incompleto potrebbe lasciare spazio a conseguenze indesiderate, mentre una condizione troppo restrittiva potrebbe bloccare transazioni legittime.
EIP-7906, il controllo delle differenze di stato sulla blockchain
L’elemento tecnico centrale dell’EIP-7906 è la possibilità di rendere accessibili agli smart contract le differenze tra lo stato iniziale e quello risultante dall’esecuzione di una transazione.
Queste differenze vengono indicate con l’espressione state diff.
Lo stato di Ethereum comprende informazioni quali i saldi degli account, i dati conservati negli smart contract, il codice associato agli indirizzi e altri elementi necessari al funzionamento della rete.
Durante l’esecuzione, un’operazione può modificare numerosi valori. Uno smart contract potrebbe aggiornare più volte la medesima posizione di memoria permanente, trasferire token oppure intervenire sulle autorizzazioni di un account.
Il controllo delle differenze di stato permette di osservare quali valori siano effettivamente cambiati rispetto alla situazione precedente.
Se una posizione di memoria viene modificata cinque volte, ma alla fine contiene un unico valore diverso da quello iniziale, la differenza netta riguarda quel valore finale. Se invece ritorna esattamente al contenuto originario, non compare tra le modifiche nette.
Questa impostazione evita di confondere ogni passaggio intermedio dell’esecuzione con il risultato persistente sulla blockchain.
La versione della specifica tecnica EIP-7906 consultabile al 29 ottobre 2026 descrive due istruzioni principali della EVM: TXTRACE ed EVENTDATACOPY.
TXTRACE consente di esaminare le modifiche prodotte dalla transazione, comprendendo informazioni sui saldi, sulle posizioni di memoria, sul codice, sui nonce e sugli eventi emessi.
EVENTDATACOPY permette invece di trasferire nella memoria della EVM i dati associati agli eventi, affinché possano essere esaminati dalla logica di controllo.
Il documento tecnico aggiornato introduce inoltre una modalità di esecuzione denominata ASSERT, nella quale queste verifiche vengono effettuate in sola lettura al termine della sequenza operativa.
L’approfondimento della Foundation del 5 ottobre descriveva una precedente articolazione tecnica con un frame POST_TX e tre istruzioni, comprendenti anche TXDIFF per ottenere direttamente valori iniziali e finali di specifiche posizioni.
La differenza tra le due descrizioni riflette l’evoluzione del progetto durante il processo di definizione della specifica. Le caratteristiche proposte non devono quindi essere considerate definitive.
Il rapporto con EIP-8141 e le transazioni suddivise in frame
L’EIP-7906 dipende dalla proposta EIP-8141, dedicata alle cosiddette frame transactions.
Questo modello prevede transazioni strutturate in più fasi, ciascuna con una funzione specifica. La sequenza può comprendere operazioni di verifica delle autorizzazioni, approvazione del pagamento delle commissioni ed esecuzione delle istruzioni.
L’EIP-7906 propone di aggiungere una modalità dedicata al controllo del risultato.
La fase ASSERT opererebbe dopo l’esecuzione delle azioni e utilizzerebbe istruzioni che non consentono di modificare ulteriormente lo stato della blockchain. La sua funzione sarebbe verificare che gli effetti prodotti rispettino le condizioni stabilite.
Qualora una condizione non fosse soddisfatta, la parte esecutiva verrebbe annullata. La transazione resterebbe comunque valida come operazione elaborata dalla rete e le commissioni relative al lavoro computazionale svolto rimarrebbero a carico del soggetto che paga il gas.
Questo aspetto risponde anche a una necessità operativa: impedire che transazioni costruite appositamente per fallire costringano i validatori e i produttori di blocchi a eseguire calcoli senza alcun costo per chi le invia.
Esiste tuttavia una distinzione tecnica importante. La proposta non garantisce l’annullamento indistinto di qualsiasi modifica avvenuta durante l’intera procedura. Gli effetti della fase preliminare di validazione possono seguire regole differenti rispetto a quelli della parte esecutiva sottoposta all’assertion.
L’EIP-7906 non impone inoltre che tutte le transazioni includano un controllo.
Un wallet dovrebbe decidere quali condizioni applicare e assicurarsi che siano effettivamente presenti nelle operazioni inviate. Un protocollo che volesse imporre una determinata protezione dovrebbe verificare che la transazione utilizzi il meccanismo richiesto.
La sicurezza dipenderebbe quindi anche dall’integrazione realizzata dagli sviluppatori delle applicazioni.
Clear signing e simulazioni, quali difese sono già disponibili
Le native transaction assertions si aggiungerebbero a strumenti già utilizzati per migliorare la sicurezza delle transazioni Ethereum, senza sostituirli integralmente.
Una delle iniziative più rilevanti è il clear signing, che punta a presentare le operazioni da firmare attraverso descrizioni strutturate e comprensibili.
Il 12 maggio 2026 la Ethereum Foundation ha annunciato, insieme a sviluppatori di wallet e operatori della sicurezza, un’iniziativa basata sullo standard ERC-7730 e su un registro di descrittori verificabili.
L’obiettivo è permettere ai wallet di rappresentare in modo coerente le istruzioni contenute nelle transazioni, riducendo il rischio che gli utenti approvino richieste tecniche senza comprenderne il significato.
Il clear signing riguarda soprattutto la comprensione di ciò che viene autorizzato. Le transaction assertions avrebbero invece il compito di verificare che l’esecuzione rispetti determinati vincoli sul risultato.
I due approcci affrontano quindi momenti differenti dello stesso processo.
Anche le simulazioni svolgono una funzione utile. Diversi wallet e strumenti di sicurezza possono analizzare preventivamente gli effetti attesi di un’operazione, segnalando trasferimenti sospetti o modifiche alle autorizzazioni.
Il limite consiste nella natura previsionale del controllo. Una simulazione utilizza uno stato della blockchain che potrebbe cambiare prima della conferma. Inoltre, qualora il dispositivo o il processo di firma fossero compromessi, la transazione firmata potrebbe non coincidere con quella precedentemente analizzata.
Esistono già protezioni eseguibili direttamente dagli smart contract.
I contratti di scambio possono imporre una quantità minima di token da ricevere, facendo fallire l’operazione quando il risultato scende sotto quella soglia. I wallet basati su Safe possono utilizzare meccanismi di controllo successivi all’esecuzione per verificare alcune condizioni sull’account.
Questi strumenti offrono garanzie effettive, ma richiedono che le verifiche siano state previste e implementate per gli elementi interessati.
La proposta EIP-7906 punta ad ampliare le possibilità di controllo, rendendo osservabili modifiche che oggi uno smart contract non può necessariamente esaminare attraverso le normali interfacce disponibili.
Le nuove protezioni non eliminerebbero tutti i rischi
L’introduzione delle assertions potrebbe contribuire alla sicurezza delle transazioni Ethereum, ma la stessa documentazione tecnica individua limiti che devono essere affrontati prima di un’eventuale adozione.
Uno dei principali riguarda l’affidabilità delle condizioni utilizzate.
Se un’interfaccia compromessa potesse costruire sia la transazione sia l’assertion destinata a proteggerla, un aggressore potrebbe inserire una regola compatibile con il risultato dannoso.
Per ottenere una garanzia concreta, la condizione di sicurezza dovrebbe derivare da un’intenzione approvata indipendentemente dall’utente, da una politica permanente del wallet oppure da regole del protocollo che il componente compromesso non possa alterare.
Un secondo problema riguarda i valori utilizzati come riferimento.
Se una verifica dipendesse da un prezzo ottenuto attraverso uno smart contract modificabile dalla stessa transazione, il controllo potrebbe confrontare il risultato con un parametro manipolato.
La specifica raccomanda pertanto di utilizzare, quando appropriato, condizioni fissate al momento della firma oppure dati iniziali che non possano essere modificati dalla parte esecutiva della medesima operazione.
Resta comunque possibile che lo stato della blockchain venga alterato da transazioni precedenti, comprese quelle contenute nello stesso blocco.
Le assertions avrebbero inoltre un ambito limitato alla singola transazione sulla singola rete.
Non potrebbero impedire automaticamente conseguenze prodotte da autorizzazioni già concesse in precedenza, né controllare tutte le fasi successive di operazioni distribuite tra blockchain differenti.
Un deposito effettuato attraverso un bridge, ad esempio, può generare effetti su un’altra rete attraverso una transazione separata. Le verifiche eseguite sulla blockchain di origine non garantirebbero automaticamente il risultato finale dell’intero processo.
Anche il costo computazionale richiede attenzione. Esaminare grandi quantità di modifiche ed eventi potrebbe comportare un consumo significativo di gas, rendendo necessarie limitazioni e ottimizzazioni.
Le assertions dovrebbero dunque essere progettate in modo da offrire controlli sufficientemente rigorosi senza rendere eccessivamente costose o difficili da eseguire le operazioni ordinarie.
La proposta nel programma Trillion Dollar Security
La ricerca sulle native transaction assertions rientra nell’iniziativa Trillion Dollar Security, annunciata dalla Ethereum Foundation il 14 maggio 2025.
Il programma nasce dall’esigenza di affrontare i problemi di sicurezza che potrebbero ostacolare una maggiore presenza di patrimoni, applicazioni finanziarie e attività istituzionali sulla blockchain.
L’espressione Trillion Dollar Security indica un obiettivo di affidabilità dell’infrastruttura, non una quantità di capitali già protetti attraverso nuove funzionalità.
Il progetto comprende diversi ambiti, dalla gestione delle chiavi private alla sicurezza degli smart contract, fino alla robustezza del protocollo e alla capacità degli utenti di riconoscere operazioni pericolose.
Nel rapporto dedicato alle principali criticità dell’ecosistema Ethereum, la gestione delle transazioni da parte degli utenti rappresenta uno dei problemi individuati.
L’irreversibilità delle operazioni confermate rende particolarmente gravi gli errori di autorizzazione. Anche quando il protocollo funziona correttamente, una firma concessa a istruzioni dannose può provocare perdite che non possono essere annullate attraverso una semplice richiesta di rimborso.
Le transaction assertions cercano di intervenire prima che una modifica indesiderata diventi definitiva.
Il loro possibile impiego riguarda anche la gestione di deleghe operative e l’utilizzo di sistemi automatizzati.
Un account potrebbe autorizzare un agente software a eseguire determinate operazioni, imponendo contemporaneamente limiti ai risultati consentiti. Le verifiche potrebbero riguardare, per esempio, la quantità massima di asset trasferibili oppure la permanenza di alcune condizioni di sicurezza.
Queste applicazioni rimangono possibilità progettuali. Non equivalgono alla disponibilità di una protezione universale per agenti autonomi o sistemi di gestione patrimoniale.
EIP-7906, quale fase ha raggiunto la standardizzazione
Alla data del 29 ottobre 2026, l’EIP-7906 risulta ancora classificata come Draft, Standards Track: Core nel repertorio ufficiale delle Ethereum Improvement Proposals.
La proposta è stata creata il 21 febbraio 2025 e ha attraversato successive revisioni tecniche.
Il documento pubblicato dalla Ethereum Foundation il 5 ottobre riferiva che l’EIP aveva raggiunto la fase di valutazione per una possibile inclusione nell’aggiornamento Hegotá, senza che fosse stata ancora confermata la sua introduzione.
Nel documento del 7 settembre 2026 dedicato alle priorità del protocollo per Hegotá, la Foundation aveva attribuito alla proposta una priorità elevata, inserendola nella fascia A del proprio sistema di valutazione. Venivano inoltre richiamate le sperimentazioni con frame transactions su una rete di sviluppo pubblica e la necessità di ulteriori approfondimenti.
Questi avanzamenti non rappresentano un’approvazione definitiva, né dimostrano che la funzionalità sia già stata attivata sulla mainnet.
La dipendenza dall’EIP-8141 rende inoltre necessario coordinare lo sviluppo delle assertions con quello della nuova struttura delle transazioni.
La ricerca è distinta dal rinvio dell’attivazione di Glamsterdam sulla testnet Hoodi, comunicato il 22 ottobre 2026. Si tratta di attività con obiettivi e percorsi tecnici differenti, che non devono essere interpretate come manifestazioni dello stesso problema.
L’EIP-7906 non è nemmeno un aggiornamento correttivo destinato a risolvere una specifica vulnerabilità già sfruttata sulla rete principale.
Il suo obiettivo riguarda l’introduzione di una nuova possibilità di controllo nel protocollo, affinché wallet e applicazioni possano imporre condizioni verificabili sulle operazioni autorizzate.
Per la sicurezza delle transazioni Ethereum, l’eventuale disponibilità di questa funzione aprirebbe soprattutto una questione di implementazione: quali regole debbano essere applicate, chi possa definirle e come garantirne l’indipendenza rispetto alle applicazioni che costruiscono le transazioni.
L’efficacia dipenderebbe anche dalla capacità dei wallet di rendere comprensibili queste condizioni e dei protocolli di renderle obbligatorie dove necessario.
La Ethereum Foundation ha invitato sviluppatori di wallet e applicazioni a contribuire alla definizione dei casi d’uso e delle specifiche. La versione tecnica rimane soggetta a revisioni e l’eventuale attivazione sulla mainnet richiederà le successive decisioni previste dal processo di aggiornamento del protocollo.
