La Ethereum Foundation conferma: l’hard fork Fusaka introdurrà un limite massimo di gas per transazione (EIP-7825)

La Ethereum Foundation ha confermato che il prossimo hard fork Fusaka introdurrà un limite massimo a livello di protocollo sulla quantità di gas che una singola transazione può consumare, formalizzato come EIP-7825. Il tetto è fissato a 2²⁴ gas — ovvero 16.777.216 unità, segnando la prima volta che Ethereum applica un limite per transazione distinto dal limite di gas per blocco. La modifica è già attiva sulle testnet Holesky e Sepolia e verrà implementata sulla mainnet al momento dell’attivazione di Fusaka.

In un post pubblicato il 21 ottobre, Toni Wahrstätter ha spiegato chiaramente la motivazione:

La Foundation sottolinea che, pur limitando le singole transazioni, questo cambiamento non modifica il limite di gas per blocco. L’obiettivo è ridurre i vettori di attacco DoS (Denial-of-Service) in cui una singola chiamata troppo grande può monopolizzare un intero blocco, e migliorare la prevedibilità del “riempimento” dei blocchi mentre la rete si prepara all’esecuzione parallela.

Un nuovo equilibrio tra complessità delle transazioni e throughput di sistema

Con l’EIP-7825, Ethereum traccia una linea chiara tra complessità delle singole transazioni e capacità complessiva del sistema. In passato, alcune transazioni particolarmente grandi potevano consumare quasi tutto il gas di un blocco (circa 45 milioni), creando problemi di tempistiche e pianificazione per builder e validatori.

Il nuovo limite obbliga quindi le operazioni che superano i 16,78 milioni di gas a essere suddivise in più transazioni sequenziali e più leggere. La Foundation specifica che “per la maggior parte degli utenti non cambierà nulla”, poiché la grande maggioranza delle transazioni reali resta ben al di sotto di questa soglia. Il rischio riguarda principalmente contratti complessi, script di deploy e router specializzati.

Cosa significa per Ethereum e per gli utenti

Da una prospettiva di roadmap, questo limite rappresenta una base per l’esecuzione parallela. Il post collega la modifica a sviluppi futuri come EIP-7928, previsto nell’era “Glamsterdam”, dove transazioni prevedibili e limitate sono un prerequisito per una concorrenza efficace nel livello di esecuzione.

Garantendo che in ogni blocco possano sempre essere incluse più transazioni indipendenti — anche in condizioni estreme di mempool — il limite riduce i casi peggiori di congestione e semplifica la progettazione dei pianificatori per i builder che sperimentano percorsi di esecuzione parallela.

Dettagli tecnici dell’EIP-7825

La specifica è semplice e diretta:

Questa semplicità è proprio ciò che ha reso l’EIP popolare tra gli sviluppatori core: una regola piccola, chiara e compatibile con i futuri upgrade di scalabilità.

Le discussioni su come codificare e comunicare il limite sono andate avanti per mesi, anche su Ethereum Magicians e durante le call AllCoreDevs. Un punto centrale del dibattito è stato allineare i target di gas per blocco a multipli di 2²⁴, garantendo così che i builder possano sempre includere almeno n transazioni se la mempool ne contiene n idonee — una questione di prevedibilità più che di throughput puro.

Implementazione e impatti per sviluppatori

Tutti i principali client — Geth, Erigon, Reth, Nethermind e Besu — hanno già implementato il cambiamento nelle versioni compatibili con Fusaka, riducendo il rischio di divergenze tra client al momento dell’attivazione.

Le chiamate eth_call non saranno influenzate, ma le transazioni pre-firmate che superano il limite dovranno essere ri-firmate con un valore di gas inferiore. Per gli sviluppatori, il percorso di aggiornamento è semplice:

• testare su Holesky o Sepolia,
• ottimizzare le operazioni batch,
• aggiornare la logica di stima del gas e le alert per segnalare rapidamente eventuali superamenti del limite.

Contesto politico e filosofico

Storicamente, Ethereum ha preferito introdurre vincoli minimali e generali, lasciando la complessità ai livelli superiori. L’EIP-7825 segue questa filosofia: non impone come debbano essere scritti i contratti, ma assicura un limite superiore che protegge la vitalità della rete e prepara il terreno per un futuro multi-threaded.

Non modifica le dinamiche del mercato delle fee, né tocca l’economia dei blob o i target di blocco di altri EIP. Come riassume la Foundation:

Un piccolo passo tecnico, ma un grande passo strategico verso la scalabilità del layer di esecuzione di Ethereum.