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 ￰0￱ 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 ￰1￱ modifica è già attiva sulle testnet Holesky e Sepolia e verrà implementata sulla mainnet al momento dell’attivazione di ￰2￱ un post pubblicato il 21 ottobre, Toni Wahrstätter ha spiegato chiaramente la motivazione: “A partire dal prossimo hard fork Fusaka, l’EIP-7825 introduce un limite massimo di gas per transazione pari a 2²⁴ (≈16,78 milioni di gas).” 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 ￰3￱ 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 ￰4￱ 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 ￰5￱ nuovo limite obbliga quindi le operazioni che superano i 16,78 milioni di gas a essere suddivise in più transazioni sequenziali e più ￰6￱ 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 ￰7￱ rischio riguarda principalmente contratti complessi, script di deploy e router ￰8￱ significa per Ethereum e per gli utenti Da una prospettiva di roadmap, questo limite rappresenta una base per l’esecuzione ￰9￱ 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 ￰10￱ 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 ￰11￱ tecnici dell’EIP-7825 La specifica è semplice e diretta: “Limitare ogni transazione a 16.777.216 (2²⁴) gas per migliorare la resilienza contro determinati vettori di attacco DoS e rendere più prevedibile l’elaborazione delle transazioni man mano che aumentano i limiti di blocco.” 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 ￰12￱ 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 ￰13￱ 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 ￰14￱ 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 ￰15￱ 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 ￰16￱ modifica le dinamiche del mercato delle fee, né tocca l’economia dei blob o i target di blocco di altri ￰17￱ riassume la Foundation: “Questo limite stabilisce una base più sicura e prevedibile per un throughput più elevato nei futuri aggiornamenti.” Un piccolo passo tecnico, ma un grande passo strategico verso la scalabilità del layer di esecuzione di Ethereum .