L'EIP-8141 di Ethereum sembra indicare una nuova direzione, poiché Vitalik Buterin, cofondatore di Ethereum, promuove la proposta come un modo per migliorare l'efficienza attraverso transazioni scalabili sulla rete.

Al centro della proposta vi è la separazione dei requisiti per l'approvazione di una transazione dai processi effettivi che la transazione esegue. Buterin ritiene che questo approccio possa consentire a Ethereum di elaborare le transazioni comuni in modo più efficace senza comprometterne la flessibilità. Lo ha descritto come una delle strategie per migliorare la scalabilità di Ethereum preservando il decentralizzazione. L'iniziativa prosegue un percorso di lavoro sul protocollo avviato da tempo: la strada degli upgrade di Ethereum ha attraversato tappe come la Merge al proof-of-stake del 2022 e i successivi hard fork "Dencun" e "Pectra", con la scalabilità e le transazioni più economiche che restano priorità costanti nella roadmap di sviluppo della rete.

In un post su X datato 5 settembre 2026, Buterin ha scritto:

One positive consequence of all the recent detailed thinking about transaction formats – not just 8141, also "future of state" discussions eg. UTXOs, PBT, keyed nonces, and also recursive STARK mempool – is that we have a much more explicit understanding of how transactions have…

— vitalik.eth (@VitalikButerin) September 5, 2026 (https://x.com/VitalikButerin/status/2096378061377900881)

L'EIP-8141 separa le dipendenze dalle azioni nelle transazioni

Buterin divide il processo di esecuzione delle transazioni in due componenti principali: dipendenze e azioni.

Le dipendenze sono i requisiti che devono essere soddisfatti perché una transazione sia considerata valida. Includono la firma delle transazioni, la prova tramite albero di Merkle, l'uso di ZK-SNARK o STARK e altri controlli.

Le azioni sono le operazioni eseguite dopo la verifica di tutti i prerequisiti. Includono l'invio di ETH, la chiamata di smart contract e la modifica di informazioni sulla blockchain.

Con il metodo EIP-8141, alcuni controlli delle dipendenze potrebbero essere eseguiti in parallelo, anziché obbligare ciascun client a elaborare ogni controllo in sequenza. Altri controlli delle dipendenze potrebbero essere svolti addirittura mentre la transazione si trova nel mempool, prima di essere inclusa in un blocco.

Le dipendenze di stato restano più complesse, poiché le transazioni precedenti possono alterare i saldi e altri dati della blockchain. Tuttavia, i mempool potrebbero gestire tali controlli in modo più efficace se le transazioni specificano quale stato richiedono.

Buterin ha stimato che oltre il 90% delle transazioni sulla rete Ethereum non necessita della piena flessibilità di esecuzione. Ha precisato che questa cifra è una sua stima personale e non una metrica misurata della rete.

Un design a Frame Transaction

L'EIP-8141 introduce un nuovo tipo di transazione denominato Frame Transaction. Il design del framework separa le chiamate ai contratti per autorizzazioni, pagamenti delle commissioni e operazioni dell'utente.

Il design consentirebbe al codice dell'account di autorizzare una transazione e pagare le commissioni, invece di affidarsi al tradizionale meccanismo di firma. Tra le funzionalità potenzialmente abilitate da questo framework vi sono la sponsorizzazione delle commissioni, i pagamenti delle commissioni in token, la rotazione delle chiavi e le transazioni in batch. Queste capacità richiamano obiettivi da tempo associati all'account abstraction, un tema di design che Ethereum ha già perseguito tramite sforzi separati come l'EIP-4337, che ha introdotto un mempool per le "UserOperations" senza modificare il protocollo di base; l'EIP-8141 opera invece direttamente a livello di formato delle transazioni.

La verifica sarebbe il primo passaggio, a determinare se la transazione è autenticata. Successivamente, altri frame potrebbero occuparsi del pagamento della commissione e dell'esecuzione delle azioni specificate.

Il formato proposto è relativamente semplice e prevede l'uso di chiamate ai contratti, flag, origin e informazioni sul nonce. Lo stesso formato potrebbe essere adottato anche da altre reti basate sul modello EVM.

Restano questioni aperte

L'EIP-8141 è ancora in fase di bozza come proposta Core, il che significa che qualsiasi aspetto della sua tecnologia potrebbe cambiare durante lo sviluppo. Le Ethereum Improvement Proposals in fase di bozza devono superare la revisione degli sviluppatori core di Ethereum ed essere programmate in un futuro upgrade della rete prima dell'attivazione, un processo che storicamente richiede da mesi ad anni e può portare alla revisione o all'abbandono completo delle proposte. L'architettura attuale copre l'ingresso nel mempool, l'esecuzione dei frame, le ricevute, le firme, il gas e la propagazione delle transazioni. Gli sviluppatori stanno lavorando sulle questioni relative ai denial-of-service, alla sostituzione delle transazioni, alla modifica dei wallet, alla costruzione dei blocchi e agli RPC.

Un'altra questione aperta riguarda il numero massimo di Frame Transaction ricevibili da un singolo mittente. Sono stati sollevati dubbi sulle possibili conseguenze di questo limite per gli utenti che devono eseguire più transazioni all'interno di un singolo blocco.

Queste questioni indicano che l'EIP-8141 deve ancora superare ostacoli tecnici prima di poter entrare a far parte del protocollo di Ethereum.

Dal punto di vista di Buterin, la proposta collega l'account abstraction ai futuri piani di scalabilità di Ethereum. L'EIP-8141 non sostituisce gli account di Ethereum, ma rende prevedibili i modelli di transazione. Se lo sviluppo proseguirà, la proposta potrebbe svolgere un ruolo determinante nella strategia futura di Ethereum per la scalabilità, l'account abstraction e una maggiore efficienza delle transazioni.