Fusaka è ora operativo e il dibattito si è spostato da ciò che avrebbe fatto a quanto bene ha retto. Attivato sette mesi dopo Pectra, ha segnato il secondo hard fork di Ethereum del 2025 e il suo turnaround più rapido tra i principali aggiornamenti da quando la rete è passata al proof-of-stake.
Il rilascio ha confermato un cambio di ritmo. Gli sviluppatori core hanno sostituito la vecchia cadenza annuale con fork più stretti e frequenti, e Fusaka ne è stata la prova pratica. Ecco cosa è stato effettivamente distribuito, come ha risposto la rete e cosa segnala per ETH in vista del 2026. 👇
Cos'è stato l'aggiornamento Fusaka di Ethereum?
L'Ethereum Fusaka upgrade è stato un hard fork coordinato che è andato live su mainnet il 3 dicembre 2025. Seguendo la tradizione, il nome unisce "Fulu", una stella nella costellazione di Cassiopea, a "Osaka", una ex città ospitante di Devcon, legando insieme i layer di consenso e di esecuzione in un'unica release.
Fusaka si è concentrato sulla scalabilità piuttosto che sulle funzionalità rivolte agli utenti, a differenza del Pectra upgrade che lo ha preceduto. La sua modifica principale, PeerDAS (EIP-7594), ha rielaborato il modo in cui i nodi confermano l'esistenza dei dati dei blob di Layer 2, consentendo loro di campionare frammenti anziché memorizzare ogni singolo byte. Ciò ha gettato le basi per il pieno Danksharding.
Il fork ha raggruppato circa dodici Ethereum Improvement Proposals, ereditate in gran parte da precedenti fasi di definizione dell'ambito, con un focus sul rafforzamento della Ethereum Virtual Machine e del layer dati. Insieme, hanno posizionato Ethereum per supportare rollup più veloci e applicazioni pesanti dal punto di vista dei dati senza spingere i requisiti dei nodi oltre l'hardware consumer.

Principali vantaggi offerti da Fusaka
Fusaka ha dato priorità alla salute della rete e a una scalabilità prevedibile rispetto alle funzionalità di spicco, riflettendo la prudenza che ne ha definito la portata finale. Le modifiche hanno ridefinito il modo in cui Ethereum gestisce carichi di dati più pesanti e il modo in cui i validator coordinano la produzione di blocchi in tutta la rete.
I principali vantaggi introdotti da Fusaka includono:
- Campionamento dei blob (PeerDAS): Riduce la pressione di larghezza di banda e di archiviazione sui nodi di consenso di circa l'85%, consentendo ai validator di verificare la disponibilità dei blob da campioni parziali anziché da download completi.
- Maggiore throughput dei blob: Ha aumentato il massimo di blob per blocco da 9 a circa 21 attraverso fork scaglionati, espandendo notevolmente la capacità di Layer 2 e riducendo i costi di pubblicazione dei rollup nel tempo.
- Limite di gas L1 maggiore: Ha innalzato il limite di gas predefinito per blocco a 60 milioni tramite EIP-7935, offrendo al layer di base circa il 20-30% di spazio in più per le transazioni e l'esecuzione di smart-contract complessi.
- Scalabilità flessibile dei blob (EIP-7892): Ha aggiunto i fork Blob Parameter Only, aggiornamenti leggeri che modificano le impostazioni dei blob senza richiedere un hard fork completo ogni volta che gli sviluppatori desiderano maggiore capacità.
- Proposer prevedibili (EIP-7917): Ha abilitato il lookahead deterministico dei proposer, in modo che i validator sappiano prima chi proporrà i prossimi blocchi, agevolando le pre-conferme e la stabilità del consenso.
- Firma nativa con passkey (EIP-7951): È stata aggiunta una precompilazione secp256r1, che abilita firme native del dispositivo tramite WebAuthn, FIDO2 e moduli di sicurezza hardware per un onboarding del wallet più fluido.

Spiegazione di Fusaka PeerDAS e della decisione su EOF
Due componenti hanno definito la portata di Fusaka: PeerDAS, che è entrato a far parte della release come funzionalità principale, e EOF, che gli sviluppatori hanno infine eliminato. Comprendere entrambi spiega perché l'aggiornamento finale sia apparso più snello rispetto a quanto suggerito dalle prime roadmap.
Cos'è PeerDAS in Fusaka?
PeerDAS (Peer Data Availability Sampling) consente ai nodi del livello di consenso di confermare transazioni di grandi blob controllando piccole porzioni casuali anziché scaricare ciascun blob per intero. I dati sono suddivisi in 128 colonne distribuite nella rete, in modo che ogni nodo memorizzi solo una frazione garantendo al contempo collettivamente la disponibilità.
Questo design ha reciso il legame tra la velocità di elaborazione dei blob e il costo dell'hardware dei validatori, consentendo a Ethereum di scalare la capacità dei dati senza richiedere macchine di livello enterprise. Gli sviluppatori hanno deprioritizzato qualsiasi funzionalità che rischiasse di ritardare PeerDAS, poiché era il prerequisito per soddisfare la futura domanda di rollup e data availability, come illustrato nella nostra guida all'EIP-4844.

Perché EOF è stato rimosso da Fusaka
EVM Object Format (EOF) mirava a ristrutturare gli smart contract tracciando confini netti tra codice, dati e metadati, sostituendo l'attuale bytecode non strutturato. Il piano ha raggruppato circa una dozzina di EIP coordinate nella prima profonda revisione dell'EVM dai suoi inizi.
Gli sviluppatori core hanno rimosso EOF da Fusaka dopo una call degli All Core Developers nell'aprile 2025, citando complessità irrisolte, rischi di tempistica e una mancanza di consenso generale. Il responsabile del protocollo Tim Beiko ha definito il taglio come una misura per proteggere PeerDAS, lasciando che i sostenitori di EOF portassero avanti la loro causa per un fork successivo piuttosto che imporlo.

Cronologia del rilascio di Ethereum Fusaka
Fusaka ha raggiunto la mainnet nei tempi previsti dopo aver superato tre testnet pubbliche durante l'ottobre 2025. Il rollout è poi proseguito attraverso due fork basati unicamente su parametri che hanno scalato la capacità dei blob in passaggi misurati anziché tutti in una volta, un approccio deliberatamente cauto data la novità della tecnica di campionamento.
Il rollout di Fusaka si è sviluppato attraverso queste tappe fondamentali:
- Holesky testnet: Attivata il 1° ottobre 2025, testa le modifiche di base tra cui l'aumento del gas-limit e le prestazioni dei validatori secondo le nuove regole.
- Sepolia testnet: Attivata il 14 ottobre 2025, focalizzata sul comportamento di PeerDAS e su limiti di gas simulati più elevati tra le implementazioni dei client.
- Hoodi testnet: Attivata il 28 ottobre 2025, l'ultima prova generale dei validatori senza permission prima che gli sviluppatori confermassero la prontezza della mainnet.
- Attivazione della mainnet: È entrata in funzione il 3 dicembre 2025 all'epoca 411392, finalizzandosi in modo pulito in circa quindici minuti su tutti i principali client.
- Fork BPO1: Attivato il 9 dicembre 2025, porta il target dei blob a 10 e il massimo a 15 per blocco.
- Fork BPO2: Attivato il 7 gennaio 2026, porta il target a 14 e il massimo a 21, completando la messa a punto dei parametri di Fusaka.

Lista EIP di Ethereum Fusaka
Il set finale di EIP di Fusaka ha fissato tre obiettivi: scalare la capacità dati di Layer 2, migliorare l'efficienza di esecuzione di Layer 1 e perfezionare l'esperienza per sviluppatori e validatori. Sulla base dell'annuncio della mainnet della Ethereum Foundation e del monitoraggio di Forkcast, queste sono state le proposte che hanno dato forma al rilascio.
Gli EIP di Fusaka più rilevanti per ruolo includono i seguenti:
- EIP-7594: Ha introdotto PeerDAS, il protocollo di campionamento che consente ai nodi di consenso di verificare la disponibilità dei blob senza scaricamenti completi, il pilastro dell'intero aggiornamento.
- EIP-7892: Ha abilitato i fork basati unicamente sui parametri dei blob (Blob Parameter Only), consentendo modifiche leggere ai target e ai massimi dei blob senza un hard fork coordinato completo.
- EIP-7935: Ha impostato il limite predefinito del gas dei blocchi a 60 milioni, standardizzando un valore tra i client che i validator avevano iniziato ad adottare persino prima dell'attivazione.
- EIP-7825: gas limitato per transazione a circa 16,7 milioni (2²⁴), una misura di protezione contro i DoS che getta anche le basi per la parallel execution.
- EIP-7918: ha limitato la commissione base dei blob in base al costo di esecuzione, impedendo ai prezzi dei blob di crollare a 1 wei e preservando un segnale di commissione significativo.
- EIP-7951: ha aggiunto una precompilazione secp256r1, consentendo di verificare a basso costo on-chain firme in stile passkey e supportate da hardware.
- EIP-7917: ha introdotto la previsione deterministica del proponente, consentendo a rollup e applicazioni di anticipare i prossimi proponenti di blocchi per un migliore ordinamento.
- EIP-7939: ha aggiunto l'opcode CLZ (count leading zeros), offrendo agli sviluppatori un'istruzione nativa ed economica per la matematica a livello di bit e gli helper crittografici.
Diverse proposte minori hanno completato il pacchetto, tra cui la coppia di ricalcolo dei prezzi ModExp (EIP-7823 e EIP-7883), il limite della dimensione del blocco RLP (EIP-7934) e miglioramenti del protocollo di rete (EIP-7642). Queste modifiche hanno principalmente ottimizzato la tokenomics del gas e l'efficienza di propagazione man mano che la capacità dei blocchi cresceva.

Come ha risposto la rete dopo il lancio
Il vero banco di prova di Fusaka è arrivato dopo l'attivazione, quando l'utilizzo in tempo reale dei blob e i dati sulle fee hanno sostituito le proiezioni. I primi segnali hanno ampiamente rispecchiato le aspettative degli sviluppatori, sebbene alcuni risultati abbiano sorpreso gli osservatori che monitoravano il prezzo del gas di ETH e i mercati dei blob nelle settimane successive.
I due fork BPO hanno triplicato la capacità massima dei blob nel giro di circa un mese, offrendo ai rollup molto più spazio per pubblicare i batch. Le fee di Layer 2 sulle principali reti sono rimaste ben al di sotto di un centesimo per le transazioni tipiche, e gli analisti hanno indicato ulteriori riduzioni man mano che la capacità continuava a scalare verso l'obiettivo a lungo termine di 128 blob.
Un risultato controintuitivo è balzato all'occhio. Il limite minimo delle fee per i blob introdotto da EIP-7918 ha causato un netto picco delle fee di base dei blob rispetto ai precedenti livelli prossimi allo zero, poiché la pubblicazione dei dati non era più di fatto gratuita. I costi di L2 sono rimasti comunque bassi, poiché il limite minimo delle fee ha principalmente ripristinato un segnale di prezzo funzionante anziché rendere lo spazio dei blob effettivamente costoso per i rollup.

Fusaka e ETH: andamento del prezzo dal lancio
Fusaka ha esordito con un breve rialzo, con ETH vicino a 3.200 $ nel giorno del lancio, in rialzo di circa il 4% mentre il fork si finalizzava tra l'ottimismo per i tagli dei tassi della Fed e i minimi pluriennali delle riserve sugli exchange. Tale forza si è mantenuta solo fino all'inizio di gennaio, quando ETH stazionava ancora sopra i 3.000 $ prima che le condizioni generali prendessero il sopravvento.
La discesa si è poi accentuata. ETH è sceso al di sotto di 1.800 $ entro febbraio 2026 a causa della convergenza tra timori di recessione, la vendita di ETH da parte del cofondatore Vitalik Buterin e i persistenti deflussi dagli spot-ETF. I rally primaverili verso 2.350 $ a marzo e 2.100 $ ad aprile sono stati sistematicamente venduti, e una mossa di risk-off a giugno ha spinto il prezzo vicino a 1.570 $.
Il quadro complessivo fa riflettere. ETH viene scambiato intorno a 1.774 $ all'inizio di luglio, in calo di circa il 45% dal lancio, e ha registrato le sue prime tre candele trimestrali rosse consecutive della storia. Fusaka ha superato importanti obiezioni tecniche, eppure il prezzo si è mosso nella direzione opposta nei sette mesi successivi.
Questa disconnessione riassume il dilemma sull'accumulo di valore che grava su ETH. Uno spazio di blocco più economico e abbondante non fa aumentare automaticamente la distruzione di commissioni sul layer-1 o il staking yield quando la domanda rimane debole, quindi Fusaka ha migliorato la qualità della rete più che il suo prezzo. Nulla di tutto ciò costituisce consulenza finanziaria, quindi effettua le tue ricerche prima di allocare fondi.

Cosa ha preparato Fusaka per il futuro
Fusaka non è mai stato un punto d'arrivo. Implementando PeerDAS e il meccanismo BPO, ha offerto agli sviluppatori principali un modo ripetibile per scalare la capacità di dati e una base per il lavoro di esecuzione più ambizioso che seguirà. La roadmap successiva a Fusaka sta già prendendo forma.
Il successore immediato è Glamsterdam, previsto per la seconda metà del 2026, che si concentra sulla scalabilità del Layer 1 stesso attraverso la separazione tra proposer e builder integrata e la parallel execution. Oltre al calendario degli hard fork, Vitalik Buterin ha pubblicato una roadmap "Lean Ethereum" che comprende la sicurezza quantistica, la privacy e la scalabilità a lungo termine fino al 2029.
Ulteriori fork BPO mirano a spingere il conteggio dei blob verso 48 per blocco entro la metà del 2026, proseguendo la scalabilità incrementale sbloccata da Fusaka. Ogni passaggio si somma al precedente, avvicinando costantemente Ethereum al throughput promesso da tempo dalla sua roadmap incentrata sui rollup.

Considerazioni finali
Fusaka ha mantenuto la sua promessa principale: ha scalato il layer di dati di Ethereum senza compromettere la decentralizzazione da cui dipendono gli operatori dei nodi. PeerDAS è stato implementato senza intoppi, la capacità dei blob è triplicata nel giro di poche settimane e la rete ha assorbito i cambiamenti con un'interruzione minima.
La domanda più difficile è cosa ne conseguirà. Fusaka ha fornito a Ethereum l'infrastruttura per accogliere la prossima ondata di utenti, ma l'infrastruttura da sola non garantisce che l'attività, le commissioni o il prezzo seguano lo stesso percorso. Con l'evolversi di Glamsterdam e della roadmap più ampia del 2026, la capacità della rete di convertire le capacità tecniche in valore duraturo rimane la storia da seguire.






