Gli sviluppatori di Ethereum hanno presentato una proposta che darebbe al codice on-chain la capacità di verificare cosa una transazione abbia effettivamente modificato — e di annullare l'intera transazione se il risultato viola regole stabilite in anticipo dall'utente. Il concetto, noto come native transaction assertions, è stato evidenziato dalla Ethereum Foundation in un post sul blog pubblicato il 5 ottobre 2026.

La proposta punta a una delle debolezze più antiche e persistenti della sicurezza delle criptovalute: la firma alla cieca.

Il problema della firma alla cieca

La firma alla cieca è l'equivalente crittografico dell'accettare termini e condizioni senza leggerli. Un wallet presenta una richiesta, i dettagli sono illeggibili o poco chiari, e l'utente approva comunque. Nella maggior parte dei casi non succede nulla di grave, ma quando accade, le conseguenze tendono a essere costose. La debolezza affonda le radici nel modo in cui le transazioni Ethereum sono costruite: il payload firmato è dati formattati per macchina e non linguaggio naturale, quindi ciò che appare sullo schermo del wallet è l'interpretazione di quei dati da parte di un'interfaccia.

La Ethereum Foundation ha inquadrato il nuovo lavoro come una risposta diretta a questi rischi, segnalati nell'ambito della sua iniziativa Trillion Dollar Security. Tale programma comprende già misure come Clear Signing, focalizzate sul rendere leggibili le richieste di transazione prima che l'utente le approvi.

Le native transaction assertions operano in una fase diversa del processo. Clear Signing mira ad aiutare gli utenti a comprendere una transazione prima che venga eseguita. Le assertion verificano se il risultato corrisponde aspettative dopo l'esecuzione.

Dentro EIP-7906

Il nucleo tecnico della proposta è EIP-7906, che introduce tre nuovi opcode nella Ethereum Virtual Machine: TXTRACE, TXDIFF ed EVENTDATACOPY. Gli opcode sono le istruzioni di basso livello comprese dall'EVM, quindi aggiungerne di nuovi amplia ciò che il codice degli smart contract può vedere e fare.

In questo caso, le nuove istruzioni offrono al codice on-chain un modo per esaminare le effettive modifiche di stato prodotte da una transazione. Questo sposta la verifica da ciò che una transazione dichiara di voler fare a ciò che ha effettivamente fatto.

Come si integra con EIP-8141

EIP-7906 non sta da sola. Si basa sul framework definito in EIP-8141, noto come formato di transazione a frame. I formati di transazione sono infrastruttura fondamentale: ogni nodo, wallet e strumento di sviluppo deve poterli elaborare, quindi a questo livello l'impatto si estende all'intero stack.

Le frame transaction suddividono una singola transazione in segmenti distinti, o frame. EIP-7906 aggiunge un nuovo elemento a quella struttura: un frame POST_TX.

Il frame POST_TX opera come una static call durante l'esecuzione. Una static call è un'operazione di sola lettura, il che significa che può esaminare lo stato ma non modificarlo. Se le condizioni definite in quel frame non sono soddisfatte, gli effetti della transazione possono essere annullati.

Stato e tempistiche

Nulla di quanto descritto è ancora attivo. EIP-7906 rimane in stato di bozza. Secondo il processo di sviluppo di Ethereum, una bozza deve superare la revisione e ottenere l'accettazione dagli sviluppatori che coordinano un aggiornamento prima che le sue modifiche raggiungano la rete. L'obiettivo è includerla nell'aggiornamento Hegotá, la cui distribuzione è prevista per il 2027.

Dimostrazioni preliminari sono già state eseguite su una rete di sviluppo, a suggerire che i meccanismi funzionano al di fuori di un whitepaper. EIP-7906 dipende inoltre da EIP-8141, quindi il suo destino è legato anche all'inclusione del formato di transazione a frame.

Perché conta oltre il codice

Le assertion native sposterebbero parte dell'onere del rischio di firma al livello di base. Se il protocollo può far rispettare direttamente i controlli sui risultati, gli utenti dipendono meno dal fatto che un singolo wallet perfezioni la propria logica di visualizzazione.

Per istituzioni e imprese, l'attrattiva è evidente. Le organizzazioni che spostano somme ingenti tendono a volere garanzie, non buone intenzioni. Un meccanismo in grado di annullare automaticamente una transazione i cui risultati escono dai parametri definiti si inserisce perfettamente nel tipo di controlli del rischio che questi attori già utilizzano altrove.

Restanoi aperte. Gli sviluppatori dovranno anche capire come gli utenti ordinari definiscono le regole che le loro transazioni devono soddisfare, dato che una rete di sicurezza che richiede una configurazione da esperti potrebbe finire per proteggere soprattutto gli esperti. Il livello di usabilità costruito sopra EIP-7906 potrebbe contare quanto gli opcode stessi.

C'è anche un compromesso da valutare. Ogni nuovo opcode amplia la superficie che deve essere implementata e auditata attraverso i molteplici client Ethereum. I miglioramenti alla sicurezza che introducono nuovi casi limite devono giustificare tale costo.

Tra i marker da monitorare: se EIP-7906 esce dallo stato di bozza, se EIP-8141 ottiene un posto in Hegotá e se seguiranno ulteriori test su devnet dopo le prime dimostrazioni.