Il Programmata per l’attivazione , è il prossimo grande aggiornamento di rete di Ethereum dopo Pectra, e segna un altro passo di scalabilità fatto dal gigante della criptovaluta. Fusaka hard fork December 3, 2025 Fusaka hard fork Il Pectra EIP si concentra sul miglioramento delle prestazioni, della sicurezza e degli strumenti di sviluppo. PeerDAS ( ) makes data availability more efficient by letting nodes verify blobs without downloading everything. Several upgrades tighten execution safety, including limits on ModExp ( , un limite sui limiti di transazione del gas ( ), e aggiornato il costo del gas ModExp ( La forchetta migliora anche la produzione di blocchi con propositore deterministico lookahead ( (e mantenere i costi di esecuzione stabili con limiti legati ai costi di esecuzione) ). Additional enhancements include limiting block size in RLP format ( ), aggiungendo un nuovo opcode CLZ per operazioni bit più veloci ( , e introdurre una precompilazione secp256r1 ( Per una migliore compatibilità con le moderne chiavi di sicurezza di crittografia e hardware. EIP-7594 EIP-7823 EIP-7825 EIP-7883 EIP-7917 EIP-7918 EIP-7934 EIP-7939 EIP-7951 Proprio come Pectra ha combinato “Prague” e “Electra”, Fusaka è un nome combinato di e Esso rappresenta il prossimo salto di Ethereum verso un futuro altamente scalabile e ricco di dati, dove i rollup di Layer 2 possono funzionare più economicamente e più velocemente. Fulu (execution layer) Osaka (consensus layer) In questo blog, analizzeremo le caratteristiche fondamentali del fork rigido Fusaka, spiegheremo come funziona PeerDAS in pratica e percorreremo i reali requisiti di rete per gli stakeholder domestici, i supernodi e i nodi completi - supportati dai dati di devnet. Key Changes Introduced In Fusaka Hard Fork Key Changes Introduced In Fusaka Hard Fork : PeerDAS - Peer Data Availability Sampling EIP-7594 Cronaca 7594 Ethereum aveva bisogno di questa proposta perché la rete vuole fornire più disponibilità di dati per gli utenti e specialmente per i rollup, ma con l'attuale Questo crea un problema di scalabilità perché se tutti i nodi devono scaricare tutto, la larghezza di banda e i requisiti hardware della rete aumentano e la decentralizzazione può soffrire. Per risolvere questo, Ethereum ha bisogno di un modo per i nodi per confermare che i dati sono disponibili senza scaricare tutto. Data Availability Sampling (DAS) risolve questo permettendo ai nodi di controllare solo piccoli pezzi casuali dei dati. Ma Ethereum ha anche bisogno di un metodo DAS che si adatta bene alla rete di rumor esistente e non aggiunge calcolo pesante ai produttori di blocchi. PeerDAS è stato creato per soddisfare queste esigenze e aumentare in modo sicuro il blobput attraverso mantenendo i requisiti dei nodi bassi. EIP-4844 PeerDAS è un sistema di rete che consente ai nodi di scaricare solo piccoli pezzi di dati blob per verificare che i dati completi siano stati effettivamente pubblicati. Invece di scaricare tutto, i nodi usano la normale rete di gossip per condividere i dati, scoprire quali coetanei detengono determinate parti, e richiedere solo i piccoli campioni di cui hanno bisogno. L'idea principale è che scaricando solo piccole, parti casuali del blob, i nodi possono ancora essere sicuri che l'intero blob esiste. Ad esempio, invece di scaricare un blob completo di 256 KB, un nodo potrebbe scaricare solo circa 1/8 di esso - ma poiché molti nodi campionano parti diverse, eventuali dati mancanti sarebbero rapidamente notati. To make sampling work, PeerDAS expands each blob from utilizzando un tipo di codice di eliminazione di base. — simile a come si può completare un puzzle anche se un paio di pezzi sono persi. Il blob diventa una “fila” che contiene i dati originali più alcuni dati aggiuntivi codificati che lo permettono di essere ricostruito più tardi. Questa fila viene poi suddivisa in molti piccoli pezzi chiamati cellule, che sono le unità più piccole verificate legate a un impegno KZG. Tutte le righe vengono poi riorganizzate in “colonne”, dove ogni colonna contiene la cellula nella stessa posizione da ogni riga. Ogni colonna è assegnata a una specifica sotto-net. I nodi sono responsabili di memorizzare alcune colonne in base al loro ID del nodo e di campionare alcune colonne da ogni slot dei pari. Se un nodo raccoglie almeno il 50% di tutte le colonne, EIP-4844 Erasure coding is a technique that adds extra redundant data so that the original data can be recovered even if some pieces are missing Additionally, the EIP introduces an important rule: Questo limite deve essere applicato durante la convalida delle transazioni, il rumor, la creazione di blocchi e il trattamento dei blocchi. Questo aiuta a ridurre i casi estremi in cui una singola transazione sovraccarica il sistema blob. no transaction can contain more than 6 blobs Pepe aggiunge qualcosa che si chiama Una prova di cellula KZG mostra che un impegno KZG corrisponde davvero a una cella specifica (un piccolo pezzo) di un blob. Questo consente a un nodo di scaricare solo le celle che vuole campionare, invece del blob completo, garantendo tuttavia l'integrità dei dati. cell KZG proofs Ma generare tutte queste prove cellulari è costoso. Un produttore di blocchi avrebbe bisogno di calcolarli ancora e ancora per molti blocchi, che è troppo lento. per generare tutte le prove cellulari in anticipo e includerle nel pacchetto di transazione. the blob transaction sender A causa di questo, il gossip di transazione (PooledTransactions) ora utilizza un wrapper modificato: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) all’interno del nuovo capannone, è solo un elenco che contiene ogni prova per ogni cella di ogni blob (ad esempio: Gli altri campi - di , e - sono esattamente gli stessi che erano in EIP-4844.La differenza è che il vecchio campo singolo "prove" viene rimosso e sostituito con questo nuovo Un nuovo campo chiamato is added to show which wrapper format is being used. cell_proofs [cell_proof_0, cell_proof_1, ...] tx_payload_body blobs commitments cell_proofs wrapper_version The è un singolo byte, e in questa proposta è sempre impostato a . The campo contiene tutte le prove cellulari per ogni blob, comprese le prove per le celle di estensione aggiuntive create durante la codifica di cancellazione. A causa della codifica di cancellazione, ogni blob corrisponde a Anche se l'elenco contiene prove per le celle di estensione, i blobs stessi vengono ancora inviati nella loro forma normale (non estesa). un blob include solo la sua metà originale - il nodo ricevente può calcolare la metà dell'estensione da solo, quindi non c'è bisogno di inviare dati inutili. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB More formally, è la prova per la j-ta cella del i-ta blob dopo la corsa , che produce sia le cellule originali che quelle di estensione. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) Quando un nodo riceve questo wrapper, deve convalidare la transazione e verificare che tutto si allinea correttamente. deve verificare che il numero di hash, blobs e impegni di versione corrisponda a tutti. Contiene esattamente proofs. Every commitment must hash to its matching versioned hash ( Infine, il nodo deve verificare che ogni impegno corrisponda effettivamente al blob e alle sue prove. , e quindi verifica tutte le prove cellulari - la verifica di lotto è consentita per rendere questo più veloce. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells Immaginate che un blob sia diviso in dopo la cancellazione del codice ( ). The original blob contains , e il nodo ricevente calcolerà il numero mancante Ma l'emittente deve includere in . Example 8 cells CELLS_PER_EXT_BLOB = 8 4 cells 4 extension cells all 8 proofs cell_proofs So for 1 blob, the transaction wrapper contains: blobs = [blob_0] (solo 4 celle originali) commitments = [commitment_0] (proof for each of the 8 cells) cell_proofs = [proof_0, proof_1, …, proof_7] Quando un nodo prende campioni, potrebbe richiedere solo la cella 2 o la cella 5 e può verificarli istantaneamente utilizzando le prove corrispondenti, senza mai scaricare il blob completo. PeerDAS consente a Ethereum di aumentare la disponibilità dei dati senza rendere più difficile il lavoro dei nodi. In futuro, questo potrebbe anche scendere a , che permetterebbe a Ethereum di scalare di più. Il sistema funziona bene perché ogni nodo ha molti pari. Così se un pari non fornisce i dati richiesti, il nodo può semplicemente chiedere a un altro pari. Questo crea redondanza naturale e migliora la sicurezza. I nodi possono anche scegliere di memorizzare dati rispetto al necessario, il che rafforza ulteriormente la rete, anche senza alcun cambiamento di protocollo. 1/8 of the total blob data 1/16 or 1/32 more Validators have a bit more responsibility than normal full nodes. Since validators already run stronger hardware, PeerDAS gives them a data-custody load that matches the total number of validators. This ensures that a stable group of nodes is always available to store and share more data, which makes the network more reliable. In short, if there are 900,000 validators, each validator might be assigned a tiny portion of the total blob data to store and serve. Because validators have better machines, the network can trust them to keep this data available. PeerDas utilizza invece di campionamento di riga perché rende la ricostruzione dei dati molto più facile. Se i nodi campionano righe intere (blobs interi), avrebbero bisogno di creare ulteriori "blobs di estensione" che non esistono naturalmente, il che rallenterebbe i produttori di blocchi. Immaginate che un blob sia una griglia di cellule 4x4. campionamento a riga significa prendere tutte le cellule 4 da una riga, ma alcune righe di estensione non sono ancora pronte, quindi il produttore del blocco dovrà generarle sul posto. campionamento a colonna significa prendere una cellula da ogni riga (una colonna). Le cellule aggiuntive necessarie per la ricostruzione possono essere preparate in anticipo, in modo che i nodi possano verificare i dati senza rallentare la produzione del blocco. column sampling Example: Funziona pienamente con , quindi non rompe nulla già su Ethereum. Tutti i test e le regole dettagliate sono nelle specifiche di consenso e esecuzione. EIP-7594 EIP-4844 The main security risk in any DAS system is a “data withholding attack,” where a block producer pretends that data is available but actually hides some of it. PeerDAS prevents this by using random sampling: nodes check random parts of the data. The more nodes that are sampled, the harder it is for an attacker to cheat. The EIP even provides a formula to calculate how likely such an attack could succeed, based on the total number of nodes (n), total samples (m), and samples per node (k). On the Ethereum mainnet, with about 10,000 nodes, the chance of a successful attack is extremely small, so PeerDAS is considered safe. The table shows that the chances of a successful attack drop to a negligible level, which is why PeerDAS is considered secure against data-withholding attacks. For deeper analysis, you can refer to the linked . Il blog : Set upper bounds for MODEXP EIP-7823 Pd 7823 Questa proposta è necessaria perché l'attuale precompilazione MODEXP in Ethereum ha causato molti bug di consenso nel corso degli anni. La maggior parte di questi bug è avvenuta perché MODEXP consente dimensioni di input estremamente grandi e irrealistiche, che crea casi infiniti e insoliti che i clienti devono gestire. Poiché ogni nodo deve elaborare qualsiasi input una transazione fornisce, non avere un limite superiore rende MODEXP più difficile da testare, più facile da rompere e più probabile di comportarsi in modo diverso tra i diversi clienti. Le entrate molto grandi rendono anche difficile prevedere la formula del costo del gas, perché è difficile prevedere qualcosa quando la sua dimensione può crescere senza limiti. Questi problemi rendono anche difficile sostituire MODEXP con futuri strumenti di codice a livello EVM come EVMMAX EIP-7823 introduce una regola semplice: tutti e tre i campi di lunghezza utilizzati da MODEXP - le dimensioni della BASE, dell'EXPONENT e del MODULUS - devono essere , che è di 1024 byte. le entrate MODEXP seguono il formato , as defined in , quindi questo EIP limita solo i valori di lunghezza. Se qualsiasi lunghezza supera i 1024 byte, la precompilazione si ferma immediatamente, restituisce un errore e brucia tutto il gas. Ad esempio, se qualcuno cerca di fornire una BASE che è lunga 2000 byte, la chiamata fallirà prima che si verifichi un lavoro. Questi limiti supportano ancora tutti i casi di utilizzo reali. La verifica RSA utilizza di solito le dimensioni chiave come 1024, 2048 o 4096 bit, tutti ben all'interno del nuovo limite. Le operazioni di curva ellittica usano dimensioni ancora più piccole, spesso sotto i 384 bit, quindi sono anche non interessate. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 Questi nuovi limiti aiutano anche con gli aggiornamenti futuri. Se MODEXP viene mai ri-scritto in codice EVM utilizzando EVMMAX, gli sviluppatori potrebbero aggiungere percorsi ottimizzati per le dimensioni di input comuni come 256 bit, 381 bit, o 2048 bit, e utilizzare un fallback più lento per casi più rari. Con le dimensioni massime fisse, gli sviluppatori possono persino aggiungere una gestione speciale per i valori di modulo molto comuni. Per confermare che questo cambiamento non romperebbe le transazioni passate, gli autori hanno analizzato tutto l'uso di MODEXP dal blocco 5.472.266 (il 20 aprile 2018) al blocco 21.550.926 (il 4 gennaio 2025). , ben al di sotto del nuovo limite di 1024 byte. La maggior parte delle chiamate reali utilizzava lunghezze piccole come 32 byte, 128 byte o 256 byte. Queste si comporterebbero allo stesso modo sotto i nuovi limiti perché erano già invalide.Quindi, mentre l'EIP è tecnicamente un cambiamento rivoluzionario, in pratica non avrebbe cambiato il risultato di nessuna transazione passata. 513 bytes 0x9e5faafc Dal punto di vista della sicurezza, ridurre le dimensioni di input consentite non crea nuovi rischi. Invece, elimina casi estremi inutili che in precedenza hanno causato bug e inconsistenze tra i clienti. Limitando le entrate MODEXP a dimensioni realistiche, questo EIP rende il sistema più prevedibile, riduce i casi di angolo strano e riduce la probabilità di errori tra le diverse implementazioni. Queste restrizioni aiutano anche a preparare il sistema per una transizione più fluida se futuri aggiornamenti come EVMMAX introducono percorsi di esecuzione ottimizzati. : Transaction Gas Limit Cap EIP-7825 EIP-7825 Questo crea diversi problemi: una transazione potrebbe consumare la maggior parte delle risorse del blocco e causare un rallentamento nello stile DoS, le grandi operazioni a gas pesante possono aumentare lo stato di Ethereum troppo rapidamente, e la convalida del blocco diventa più lenta e più difficile per i nodi di tenere il passo. Se un utente presenta una transazione enorme che utilizza quasi tutto il gas (ad esempio, una transazione che consuma 38 milioni di gas in un blocco a 40 milioni di gas), allora altre transazioni normali non si adattano al blocco, e ogni nodo deve spendere più tempo a verificare quel blocco. Questo minaccia la stabilità della rete e la decentralizzazione perché la convalida più lenta significa che i nodi cadono più deboli. Per risolvere questo, Ethereum ha bisogno di un limite superiore EIP-7825 introduce una regola dura che nessuna transazione può utilizzare più di Questo diventa un capo a livello di protocollo, il che significa che si applica ovunque: quando un utente invia una transazione, quando il txpool la controlla, e quando i validatori la includono in un blocco. Questo limite è completamente indipendente dal limite del gas del blocco. ad esempio, anche se il limite del gas del blocco è di 40 milioni, nessuna singola transazione è consentita di utilizzare più di 16,7 milioni di gas. 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEED MAX_GAS_LIMIT_EXCEED To understand this better, imagine a block has space for 40 million gas. Without this cap, someone could send a single transaction that consumes 35–40 million gas. That transaction would monopolize the block and leave no room for others, similar to one person renting out an entire bus so no one else can board. With the new 16.7M limit, the block will naturally hold multiple transactions and avoid this kind of abuse. La proposta aggiunge anche requisiti specifici a come i clienti convalidano le transazioni. Il txpool deve rifiutare una transazione se il suo gasLimit è superiore a 16,777,216, il che significa che tale transazione non entra nemmeno in fila. Durante la convalida del blocco, se un blocco contiene una transazione che supera il limite, il blocco stesso deve essere rifiutato. Il numero è stato scelto perché è un limite di potenza pulita di due, rendendolo più facile da implementare, ed è ancora abbastanza grande da gestire la maggior parte delle transazioni del mondo reale, come le implementazioni di contratti intelligenti, le interazioni DeFi complesse o le chiamate contrattuali a più passi. 16,777,216 (2²⁴) Questo EIP mantiene anche la compatibilità con la meccanica attuale del gas. La maggior parte degli utenti non noterà mai il cambiamento perché quasi tutte le transazioni esistenti consumano già ben meno di 16 milioni di gas. I validatori e i creatori di blocchi possono ancora creare blocchi che superano i 16,7 milioni di gas totali, a condizione che ogni singola transazione rispetti il nuovo capo. Le uniche transazioni colpite sono quelle estremamente grandi che in precedenza hanno cercato di utilizzare più del nuovo limite. Queste transazioni devono ora essere suddivise in più operazioni più piccole – simili a rompere un file molto grande caricato in due più piccole. Questo cambiamento non è tecnicamente compatibile con quelle rare transazioni estreme, ma si prevede che il numero di utenti colpiti sia molto piccolo. In termini di sicurezza, la copertura del gas rende Ethereum più resiliente agli attacchi DoS basati sul gas perché gli aggressori non possono più costringere i validatori a gestire transazioni estremamente grandi. Aiuta anche a mantenere i tempi di verifica dei blocchi prevedibili in modo che i nodi possano rimanere in sincronizzazione più facilmente. Nel complesso, EIP-7825 è progettato per rafforzare la rete contro gli abusi, mantenere i requisiti dei nodi ragionevoli, migliorare l'equità nell'uso dello spazio di blocco e garantire che la catena rimanga veloce e stabile man mano che i limiti del gas continuano ad aumentare nel tempo. : ModExp Gas Cost Increase EIP-7883 EIP-7883 The reason Ethereum needs this proposal is that the ModExp precompile (used for modular exponentiation) has been In alcune situazioni, le operazioni di ModExp richiedono molto più calcolo di quello che gli utenti stanno attualmente pagando. Questo squilibrio crea un rischio: se le chiamate complesse di ModExp rimangono troppo economiche, possono diventare un problema. Per correggere questo, Ethereum ha bisogno di regolare la formula di prezzo ModExp in modo che il gas utilizzato rifletta correttamente il lavoro reale svolto dal cliente. Ecco perché EIP-7883 introduce nuove regole che aumentano il costo minimo, aumentano il costo generale e rendono più costose le operazioni con grandi input (soprattutto esponenti, base o modulo su 32 byte), in modo che il prezzo del gas corrisponda al vero calcolo richiesto. underpriced bottleneck Questa proposta modifica l'algoritmo di prezzo ModExp originariamente definito nell'EIP-2565 aumentando il costo in diversi modi importanti. è aumentata da 200 a 500, e la formula generale non divide più per 3, il che significa che il costo totale effettivamente divide Ad esempio, se una chiamata ModExp costava in precedenza 1.200 gas, ora costa circa 3.600 gas secondo la nuova formula. è raddoppiato aumentando il moltiplicatore da 8 a 16. Per illustrare questo: se la lunghezza dell'esponente fosse di 40 byte, EIP-2565 aggiungerebbe per il conteggio di iterazione, mentre EIP-7883 ora utilizza , making it twice as expensive. Third, the pricing now assumes a In questo caso, il costo di calcolo aumenta drasticamente quando questi valori superano i 32 byte. ad esempio, se il modulo è 64 byte, la nuova regola applica una complessità raddoppiata ( Insieme, questi cambiamenti garantiscono che le piccole operazioni ModExp paghino una tassa minima equa e le grandi operazioni pesanti scalino il loro costo correttamente con le dimensioni. minimum gas cost three times higher exponents larger than 32 bytes 8 × (40 − 32) = 64 16 × (40 − 32) = 128 minimum base/modulus size of 32 bytes 2 × words² La proposta definisce una nuova funzione di calcolo dei gas che aggiorna le regole di complessità e di conteggio di iterazione.La complessità di moltiplicazione ora utilizza un valore predefinito di 16 per le lunghezze di base/modulo fino a 32 byte, e per le entrate più grandi passa alla formula più pesante , where “words” is the number of 8-byte chunks. The iteration count is also updated so that exponents of 32 bytes or smaller use their bit length to determine complexity, but exponents larger than 32 bytes add a much larger penalty. This ensures that very large exponents, which are computationally expensive in practice, now have a much higher gas cost. Importantly, the minimum returned gas cost is enforced as 500 instead of the earlier 200, making even the simplest ModExp calls more realistically priced. 2 × words² La motivazione dietro questi aumenti di prezzo proviene da benchmarks che mostrano molte situazioni in cui il precompilatore ModExp è stato significativamente sottovalutato. , typical operations by around , e operazioni molto grandi o squilibrate da fattori molto più grandi - a volte più di L'intenzione non è di cambiare il modo in cui ModExp funziona, ma di garantire che anche nei suoi casi di margine più ricchi di risorse non minacci più la stabilità della rete o impedisca aumenti futuri al limite del gas blocco. , ma la ripetizione del gas è avvenuta molte volte in precedenza in Ethereum ed è ben compresa. 150% 200% 80× backward-incompatible I risultati dei test mostrano quanto siano significativi gli aumenti. Ad esempio, in un test “exp-heavy” il costo salterà da 215 a 16.624 gas. —because extremely large exponents are now correctly priced. In another case involving a base-heavy operation, the cost goes from 1,026 to 94,448 gas, which reflects how big-number multiplication actually scales. These examples show why the old pricing formula wasn’t realistic and how the new one better matches computational reality. 99.69% of historical ModExp calls 76× more In termini di sicurezza, questa proposta non crea nuovi vettori di attacco o rende qualsiasi operazione più economica. Invece, si concentra sulla prevenzione di un rischio importante: le operazioni di ModExp sottopreziate potrebbero consentire agli attaccanti di riempire i blocchi con calcoli estremamente pesanti per un costo molto basso. L'unico inconveniente possibile è che alcune operazioni di ModExp potrebbero ora diventare sovrapprezzate, ma questo è considerato un risultato molto migliore rispetto al problema attuale di sottoprezzo. Non vengono introdotte modifiche all'interfaccia o nuove funzionalità, quindi il comportamento aritmetico esistente e i vettori di test rimangono validi. Test Case EIP-2565 Pricing EIP-7883 Pricing Increase modexp_nagydani_1_square 200 500 150% modexp_nagydani_1_qube 200 500 150% modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_2_square 200 512 156% modexp_nagydani_2_qube 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_4_square 1365 8192 501% modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125% modexp_guido_2_even 2300 51152 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_4_even 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_2_base_heavy 867 5202 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3_balanced 1360 4080 200% modexp_scarpone_1_square 200 500 150% modexp_successivo_1_quotazione 200 500 150% modexp_scarpone_1_pow0x10001 341 2048 Il 501% modexp_scarpone_2_square 200 512 156% modexp_successivo_2_quotazione 200 512 Il 156% modexp_scarpone_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 Il 501% modexp_successivo_3_quotazione 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_scarpone_4_square 1365 8192 Il 501% modexp_successivo_4_quotazione 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 Il 500% modexp_successivo_5_quotazione 5461 32768 Il 500% modexp_scarpone_5_pow0x10001 87381 524288 Il 500% modexp_mario_1_equivalente 2057 45296 Il 2102% modexp_guido_1_anche 2298 51136 Il 2125% modexp_guido_2_even 2300 51152 Il 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_4_equivalente 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_2_base_heavy 867 5202 Il 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_differenziato 996 5978 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_exp_grasso 765 4080 433% modexp_marcin_3_equivalente 1360 4080 200% *source: https://eips.ethereum.org/EIPS/eip-7883#test-cases* : Determine proposer lookahead EIP-7917 Cronaca di EIP 7917 Ethereum needed this proposal because the network’s proposer schedule for the next epoch was not fully predictable. Even though the RANDAO seed for epoch is known during epoch , the actual proposer list could still change due to effective balance (EB) updates happening inside epoch Questi cambiamenti EB possono derivare da tagli, penalità, ricompense superiori a 1 ETH, consolidamenti di validatori o nuovi depositi, specialmente dopo che EIP-7251 ha sollevato il saldo effettivo massimo oltre 32 ETH. Questa incertezza crea problemi per i sistemi che si basano sulla conoscenza del prossimo proponente in anticipo, come i protocolli di pre-confirmazione basati, che hanno bisogno di un calendario stabile e prevedibile per funzionare senza problemi. Un validatore potrebbe persino cercare di "grindare" o manipolare il loro equilibrio effettivo per influenzare chi diventa il proponente nella prossima epoca. A causa di questi problemi, Ethereum ha bisogno di un modo per rendere il proponente pianificare completamente deterministico diverse epoche in avanti in modo che non possa essere cambiato dall'ultimo aggiorn N+1 N N To implement this, the EIP introduces a deterministic proposer lookahead by pre-computing and storing the proposer schedule for the next MIN_SEED_LOOKAHEAD + 1 epochs at the start of every epoch. In simple terms, the beacon state now contains a list called Per esempio, quando inizia l'epoca N, questo elenco include già il proponente per ogni slot nell'epoca N e nell'epoca N+1. Quindi, quando la rete si sposta all'epoca N+1, l'elenco viene spostato in avanti: le voci del proponente per l'epoca N vengono rimosse, le voci per l'epoca N+1 si spostano in avanti e nuove voci del proponente per l'epoca N+2 vengono aggiunte alla fine. proposer_lookahead Per mantenere questo aggiornato, l'elenco si sposta in avanti a ogni confine dell'epoca: i dati per l'epoca passata vengono rimossi e un nuovo set di indici propositori per la prossima epoca futura viene calcolato e allegato. Il processo utilizza le stesse regole di semi ed efficaci bilanci come prima, ma ora il programma è calcolato in anticipo, eliminando la possibilità di cambiamenti EB che lo influenzano dopo che il seme è conosciuto. Imagine each epoch has 8 slots instead of 32 (just for simplicity). Without this EIP, during epoch 5, you know the seed for epoch 6, but the actual proposer for slot 2 of epoch 6 could still change if a validator gets slashed or earns enough rewards to change their effective balance inside epoch 5. With EIP-7917, at the of epoch 5, Ethereum pre-calculates all proposers for epoch 5, 6, and 7 and stores them in order inside . Now, even if balances change later in epoch 5, the proposer list for epoch 6 stays fixed and predictable. inizio proposer_lookahead This EIP fixes a long-standing oversight in the beacon chain design. It guarantees that once the RANDAO from earlier epochs becomes available, the validator selection for future epochs cannot be altered. This also prevents “effective balance grinding,” where a validator tries to adjust their balance after seeing the RANDAO to influence the next epoch’s proposer list. With deterministic lookahead, that entire attack vector is eliminated, making the security analysis much simpler. It also gives consensus clients early visibility into who will propose upcoming blocks, which helps implementations and allows the proposer schedule to be easily verified by the application layer via a Merkle proof from the beacon root. Gli autori hanno anche controllato la compatibilità con funzionalità future come Single Secret Leader Election (SSLE).Il design attuale rimane compatibile perché il lookahead potrebbe un giorno memorizzare ID di propositore crittografati, o possibilmente essere disabilitato completamente se SSLE rimuove il lookahead, senza rompere nulla. Before this proposal, clients only calculated the proposer for the current slot. With EIP-7917, they now compute the proposer list for all slots in the next epoch at once during every epoch transition. This adds a small amount of work, but computing proposer indices is very light and mainly involves sampling validator lists using the seed. However, clients will need benchmarking to make sure this extra computation does not cause performance issues. Questo EIP non cambia il funzionamento del ritardo RANDAO. il proponente lookahead per epoch is still derived from the RANDAO of epoch . The only change is that effective balances are now aligned with the same delay, so validators cannot modify their EB after seeing the RANDAO result. This removes a potential manipulation strategy, even though no attack had been discovered yet. The deterministic lookahead therefore, strengthens security and prevents malicious alteration of proposer schedules. N N − MIN_SEED_LOOKAHEAD − 1 : Blob base fee bounded by execution cost EIP-7918 EIP-7918 Ethereum ha bisogno di questa proposta perché l'attuale sistema di tasse blob (da ) breaks down when execution gas becomes the main cost for rollups. Right now, most rollups pay much more for execution gas (the cost of including their blob transaction in the block) than they pay for the actual blob fee. This creates a problem: even if Ethereum keeps lowering the blob base fee again and again, the rollup’s total cost does not really change, because the expensive part is still the execution gas. Because of this, the blob base fee keeps falling until it reaches the absolute minimum (1 wei), and the protocol can no longer use the blob fee to control demand. Then, when blob usage suddenly goes up, the blob fee needs many blocks to climb back to a normal level. This makes prices unstable and unpredictable for users. Pd 4844 For example, imagine a rollup wants to post its data: it pays about 25,000,000 gwei in execution gas (25 gwei per gas for roughly 1,000,000 gas), while the blob fee is only around 200 gwei. This means the total cost is roughly 25,000,200 gwei, where almost the entire cost comes from execution gas, not the blob fee. If Ethereum keeps lowering the blob fee—say from 200 gwei to 50 gwei, then to 10 gwei, and eventually down to 1 wei—the total cost barely changes at all, staying almost exactly 25,000,000 gwei. Because users don’t feel any difference, they don’t change their behavior, so the protocol keeps pushing blob fees down until they hit the minimum possible value. Then, when blob demand suddenly increases again, the blob base fee has to climb all the way up from 1 wei, causing sharp, unpredictable fee spikes. fixes this by introducing a minimum “reserve price” for blob fees that depends on the execution base fee, preventing blob prices from falling unrealistically low and keeping blob pricing much more stable and predictable for rollups. EIP-7918 L'idea di base di EIP-7918 è semplice: il prezzo di un blob non dovrebbe mai essere più economico del costo di una certa quantità di gas di esecuzione (chiamato ). In the EIP, this constant is set to . The mechanism works through a small change inside the function. Usually, this function increases or decreases the blob base fee depending on whether blocks are using more or less blob gas than the target. With this proposal, if a blob becomes “too cheap” compared to execution gas, the function stops subtracting the target blob gas. This makes the excess blob gas grow faster, which prevents the blob base fee from falling further. As a result, the blob base fee now has a minimum value equal to . BLOB_BASE_COST 2¹³ calc_excess_blob_gas() BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB Per capire perché questo è necessario, aiuta a guardare la domanda di blob. Un rollup si preoccupa del prezzo totale che paga: costo di esecuzione più costo di blob. Se la tassa di esecuzione del gas è molto alta - ad esempio, 20 gwei - allora anche se la tassa di blob scende da 2 gwei a 0,2 gwei, il costo totale cambia a malapena. Questo significa che ridurre la tassa di base di blob non ha quasi alcun impatto sulla domanda. “Crea una situazione in cui la curva della domanda è quasi verticale: abbassare il prezzo non aumenta la domanda.Quando questo accade, il meccanismo della tassa di base del blob diventa cieco – continua a abbassare il prezzo anche se la domanda non reagisce. Ecco perché la tassa di base del blob spesso scende a 1 wei. Poi, quando la domanda reale aumenta più tardi, il protocollo ha bisogno di un’ora o più di blocchi quasi completi per aumentare la tassa a un livello ragionevole. EIP-7918 risolve questo stabilendo un prezzo di riserva legato al gas di esecuzione in modo che le tasse del blob rimangano significative anche quando i costi di esecuzione dominano. fee inelasticity Un altro motivo per aggiungere questo prezzo di riserva è che i nodi devono fare un sacco di lavoro extra per verificare le prove KZG per i dati blob. , a node only had to verify one proof per blob, which was cheap. But with (PeerDAS), blobs are broken into many small pieces called cells, and every cell has its own proof. This makes verification much heavier. For example, the execution layer now has to batch-verify 128 proofs for every single blob before a transaction can even enter the mempool—this is about fifteen times more expensive than the normal KZG proof verification that smart contracts pay for. On top of that, full nodes, supernodes, and validators must verify even more proofs depending on how many columns they store or sample. A typical full node must verify proofs for all blobs in the mempool, plus eight sampled columns every slot, plus four columns it permanently custodies. All of this uses real CPU time, and it isn’t free for node operators. If blob fees drop too low, users would get this expensive compute work from the network essentially for free. By linking the blob reserve price to execution gas fees, EIP-7918 makes sure blob users always pay at least a fair minimum amount for the load they put on nodes. EIP-4844 Cronaca 7594 In the long run, EIP-7918 also helps prepare Ethereum for the future. As technology improves, the cost of storing and sharing data naturally gets cheaper, and Ethereum is expected to allow more blob data over time. When blob capacity increases, blob fees (in ETH) should naturally go down. This proposal supports that because the reserve price is tied to execution gas prices, not a fixed number, so it can adjust as the network grows. As both blobspace and execution blockspace expand, their price relationship stays balanced. The only time the reserve price might become too high is in a very unlikely future where Ethereum increases blob capacity a lot but does not increase execution gas capacity. In that case, blob fees might end up higher than needed. But Ethereum is not planning to scale in that way—both blobspace and execution blockspace are expected to grow together. Because of this, the chosen value ( ) is considered safe and well-balanced. BLOB_BASE_COST = 2¹³ There is one small detail to understand when execution gas fees suddenly jump. Because the blob reserve price depends on the execution base fee, a sudden rise in execution costs can temporarily push blob fees into a state where execution fees are guiding them. For example, imagine execution gas suddenly jumps from 20 gwei to 60 gwei in one block. Since the reserve price for blobs is tied to that number, blob fees cannot drop below the new higher level. Blob fees will still increase normally if blobs are being used, but the protocol will not allow them to decrease until they have risen enough to match the higher execution cost. This means blob fees may climb more slowly than execution fees for a few blocks. This small delay is not harmful — it actually prevents sharp, sudden swings in blob prices and keeps the system smoother and more stable. The authors also performed empirical analysis by applying the reserve price rule to real blob activity from and Durante i periodi di esecuzione (circa ), the reserve threshold significantly increased the blob base fee compared to the old mechanism. During low-execution-fee periods (around ), la tassa di blob rimase quasi invariata, tranne quando la tassa di base di blob calcolata è caduta al di sotto del prezzo di riserva. Con il confronto di migliaia di blocchi, gli autori mostrano che il nuovo meccanismo crea un prezzo più stabile mentre risponde naturalmente alla domanda. Un istogramma di quattro mesi di tasse di blob mostra che il prezzo di riserva impedisce che le tasse di blob crollino verso 1 wei, che riduce l'estrema volatilità. November 2024 March 2025 16 gwei average 1.3 gwei average In termini di sicurezza, il cambiamento non comporta rischi.La tassa di base del blob sarà sempre pari o superiore al costo del Questo è sicuro perché il meccanismo aumenta solo la tariffa minima, e la fissazione di un limite più basso sul prezzo non interferisce con la correttezza del protocollo. BLOB_BASE_COST : RLP Execution Block Size Limit EIP-7934 EIP-7934 Prima di EIP-7934, Ethereum ha fatto have a strict upper limit on how large an RLP-encoded execution block could be. In theory, a block could become extremely large if it contained many transactions or very complex data. This created two major problems: and . If a block was too large, it would take longer for nodes to download and verify it, which slowed block propagation and increased the chance of temporary blockchain forks. Worse, an attacker could deliberately create a very large block to overload nodes, causing delays or even knocking them offline — a classic denial-of-service scenario. At the same time, Ethereum’s consensus layer (CL) gossip protocol already refused to propagate any block over , il che significa che i blocchi di esecuzione eccessivi potrebbero non diffondersi in tutta la rete, creando frammentazione o nodi in disaccordo sulla catena. A causa di questi rischi, Ethereum aveva bisogno di una regola chiara a livello di protocollo per prevenire i blocchi eccessivi e mantenere la rete stabile e sicura. not network instability DoS attack risks 10 MB EIP-7934 solves this by introducing a on the size of an RLP-encoded execution block. The maximum allowed block size ( ) è fissato a , but because beacon blocks also consume some space ( ), Ethereum adds a . This means the actual maximum RLP-encoded execution block size allowed is . If the encoded block is larger than this limit, the block is considered Con questa regola in vigore, i produttori di blocchi devono controllare la dimensione codificata di ogni blocco che costruiscono, e i validatori devono verificare questo limite durante la convalida del blocco. dei limiti di gas – il che significa anche se un blocco è “ Può ancora essere rifiutato se la sua dimensione codificata è troppo grande. Questo assicura che siano rispettati sia l'uso del gas che i vincoli di dimensione dei byte reali. protocol-level cap MAX_BLOCK_SIZE 10 MiB (10,485,760 bytes) SAFETY_MARGIN 2 MiB (2,097,152 bytes) MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN invalid independently under the gas limit, Scegliere a was intentional because it matches the existing constraint in the consensus layer gossip protocol. Anything larger than 10 MiB would not be broadcast across the network anyway, so this EIP brings the execution layer into alignment with the consensus layer’s limits. This creates consistency across all components and prevents situations where a valid execution block becomes “invisible” because the CL refuses to gossip it. 10 MiB cap Questo cambiamento è with blocks larger than the new limit, meaning miners and validators must update their clients to respect the rule. However, since oversized blocks were already problematic and not normal in real operation, the impact is minimal. In terms of security, this EIP significantly strengthens Ethereum against targeted block-size DoS attacks by ensuring no participant can create blocks that overwhelm the network. Overall, EIP-7934 adds an important safety boundary, improves stability, aligns EL and CL behavior, and prevents several classes of attacks related to oversized block creation and propagation. not backward-compatible : Count leading zeros (CLZ) opcode EIP-7939 EIP-7939 Prima di questa EIP, Ethereum aveva to count the number of leading zero bits in a 256-bit number. Developers had to implement CLZ manually in Solidity using many bit-shift operations and comparisons. This was a big problem because the custom implementations were , e , which increased gas usage. For zero-knowledge proving systems, the cost was even higher — right-shifts are extremely expensive to prove, so operations like CLZ slowed down ZK circuits significantly. Since CLZ is a very common low-level function used in math libraries, compression algorithms, bitmaps, signature schemes, and many cryptographic or data-processing tasks, Ethereum needed a faster and cheaper way to compute it. no built-in opcode slow, expensive used a lot of bytecode EIP-7939 risolve questo problema introducendo un Questo opcode prende un valore di 256 bit dalla pila e restituisce il numero di bit a zero. Se il numero di input è zero, l'opcode restituisce Questo corrisponde a come CLZ funziona in molte architetture CPU come ARM e x86, dove questa operazione è nativa. , , , various math functions, byte-string comparisons, bitmap scanning, calldata compression/decompression, and post-quantum signature schemes all benefit from faster leading-zero detection. new opcode called CLZ (0x1e) 256 lnWad powWad LambertW Simile ad un , and slightly raised from the old MUL price to avoid underpricing the opcode and causing DoS risks. Benchmarks show that CLZ uses roughly the same compute effort as ADD, and in the SP1 rv32im proving environment, CLZ is actually L'EIP spiega anche perché hanno scelto CLZ invece di : è possibile calcolare CTZ da CLZ utilizzando , but you reliably implement CLZ using CTZ, so CLZ is more fundamental. The gas cost for CLZ is set to 5 ADD cheaper to prove than ADD CTZ (count trailing zeros) x & -x cannot This EIP is fully backwards-compatible because it introduces a opcode and does not modify any existing behavior. It also covers edge cases clearly: for example, the opcode returns 256 when the input is zero, and several test cases show inputs like all-zero, top-bit-set, and fully-nonzero values. Since CLZ has predictable and low gas cost, no memory growth, and no state changes, it is safe from denial-of-service issues. new Nel complesso, EIP-7939 rende Ethereum più veloce, più economico e più amichevole per gli sviluppatori aggiungendo un primitivo semplice ed efficiente che le CPU moderne già supportano: tagliare il gas, ridurre le dimensioni del bytecode e ridurre i costi di prova ZK per molte operazioni comuni. : Precompile for secp256r1 Curve Support EIP-7951 EIP-7951 Before this EIP, Ethereum did have a safe, native way to verify digital signatures created using the Questa curva è lo standard utilizzato in dispositivi moderni come A causa di questa mancanza di supporto, le app e i portafogli non potevano facilmente utilizzare la sicurezza hardware a livello di dispositivo per la firma. related to point-at-infinity handling and incorrect signature comparison. These issues could cause incorrect verification or even risk consensus failures. not secp256r1 (P-256) curve Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn security keys two serious security vulnerabilities EIP-7951 fixes those security problems and introduces a safe, native precompile so Ethereum can finally support signatures from modern hardware securely and efficiently. EIP-7951 adds a new a indirizzo called , che esegue la verifica della firma ECDSA utilizzando la curva secp256r1. Questo rende la verifica della firma veloce e economica rispetto all'implementazione dell'algoritmo direttamente in Solidity. La precompilazione utilizza i parametri ufficiali della curva definiti da NIST, tra cui il modulo di campo, l'equazione della curva, il punto di base e l'ordine del sottogruppo, garantendo una forte sicurezza crittografica. I punti e gli scalari sono codificati in un formato di big-endiano rigido di 32 byte e un valore di tutto-zero di 64 byte viene utilizzato per rappresentare il punto all'infinito. —the hash, signature (r, s), and public key coordinates (qx, qy)—and it returns for success or per il fallimento. precompiled contract 0x100 P256VERIFY 160 bytes of input 32 bytes of 1 empty output The EIP also defines strict . It checks that r and s are within valid ranges, that the public key lies on the curve, and that it is not the point at infinity. If anything is invalid, the precompile returns failure without reverting and consumes the same gas as a successful call. The verification algorithm follows standard ECDSA: it computes s⁻¹ mod n, rebuilds the signing point R’, rejects if R’ is infinity, and finally checks whether the x-coordinate of R’ matches r (mod n). This corrects the mistake in RIP-7212, which compared r’ directly instead of reducing it mod n. input validation rules The secp256r1 curve is fully defined by the following set of parameters: Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff Curve equation: y^2 = x^3 + ax + b (mod p) Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b Base point G: Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296 Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5 Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 Cofactor = h = 0x1 Questi parametri sono standardizzati dal NIST in SP 800-1861. Il costo del gas per l'operazione è fissato a , which is higher than the RIP-7212 version, but matches actual performance benchmarks for secp256r1 verification. Importantly, the interface remains fully compatible with Layer 2 networks that already deployed RIP-7212—same address, same input/output format—so existing smart contracts will continue to work with no changes. The only difference is the corrected behavior and higher gas cost. 6900 gas Input: P256VERIFY call excepts 160 Bytes as input that is interpreted as byte concatenation of: 32 bytes ----> message hash (h) 32 bytes ----> signature component (r) 32 bytes ----> signature component (s) 32 bytes ----> public key x-coordinate (qx) 32 bytes ----> public key y-coordinate (qy) Output: will be 32 bytes on successfull verification and 0 bytes on failure Input Validation: The precompile MUST perform the following validation checks and return `` (failure) if any check fails: 1. Input length: Input MUST be exactly 160 bytes 2. Signature component bounds: Both r and s MUST satisfy 0 < r < n and 0 < s < n 3. Public key bounds: Both qx and qy MUST satisfy 0 ≤ qx < p and 0 ≤ qy < p 4. Point validity: The point (qx, qy) MUST satisfy the curve equation qy^2 ≡ qx^3 + a*qx + b (mod p) 5. Point not at infinity: The point (qx, qy) MUST NOT be the point at infinity (represented as (0, 0)) From a security standpoint, the EIP restores proper ECDSA behavior, eliminates malleability concerns at the precompile level (leaving optional checks to applications), and clarifies that constant-time execution is not required for the precompile. The secp256r1 curve provides 128-bit security and is widely trusted and analyzed, making it safe for Ethereum adoption. In short, , fix the security issues of the earlier proposal, and provide a reliable, standardized way to verify P-256 signatures across the entire ecosystem. EIP-7951 is needed to safely bring modern hardware-backed authentication to Ethereum The table below summarizes which Ethereum clients need to implement changes for each Fusaka EIP. A check mark under indica che l'EIP richiede aggiornamenti ai client di livello consenso, mentre un segno di controllo sotto Alcuni EIP richiedono aggiornamenti in entrambi i livelli, mentre altri sono specifici per uno solo. Consensus Client Execution Client EIP Number EIP Name Consensus Client Execution Client EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7825 Transaction Gas Limit Cap ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7917 Deterministic proposer lookahead ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ Cronaca 7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ Pd 7823 Impostare limiti superiori per MODEXP ✅ EIP-7825 di Transaction Gas Limit Cap ✅ Pd7883 ModExp aumenta i costi del gas ✅ Cronaca di EIP 7917 Determinista propositore lookahead ✅ EIP-7918 Blob base fee limitato al costo di esecuzione ✅ EIP-7934 RLP esecuzione limite dimensione blocco ✅ EIP-7939 Count leading zeros (CLZ) codice opzionale ✅ EIP-7951 Precompilazione per secp256r1 Curve Support ✅ In sintesi, questi sono i principali EIP inclusi nel hard fork di Fusaka. Mentre diversi miglioramenti riguardano sia i clienti di consenso che di esecuzione, che vanno dagli aggiustamenti di gas e dagli aggiornamenti di opcode alle nuove precompilazioni, il , che introduce il campionamento di disponibilità dei dati peer-to-peer, consentendo una gestione più efficiente e decentralizzata dei dati blob in tutta la rete. major change of this upgrade is PeerDAS
