El , programat per a l'activació en , és la següent gran actualització de la xarxa d'Ethereum després de Pectra, i marca un pas més d'escala presa pel gegant criptogràfic. Fusaka hard fork December 3, 2025 Fusaka hard fork The Pectra EIPs focus on improving performance, security, and developer tools. PeerDAS ( En aquest sentit, es tracta d’una de les principals qüestions que es plantegen en l’àmbit de l’aplicació de les normes de seguretat i de seguretat, i que no s’apliquen a les normes de seguretat, sinó que s’apliquen a les normes de seguretat i seguretat de les normes de seguretat. ), un límit sobre els límits de transacció de gasos ( ), i actualitzat costos de gas ModExp ( A més a més a més, l’objectiu és millorar la producció de blocs amb el proposador determinista lookahead ( ) i manté les taxes de blob estables amb límits lligats als costos d'execució ( L’objectiu és millorar la qualitat de vida de les famílies en el marc de l’exercici físic ( ), adding a new CLZ opcode for faster bit operations ( ), and introducing a secp256r1 precompile ( ) for better compatibility with modern cryptography and hardware security keys. EIP-7594 EIP-7823 EIP-7825 EIP-7883 EIP-7917 EIP-7918 EIP-7934 EIP-7939 EIP-7951 Igual que Pectra va combinar “Prague” i “Electra”, Fusaka és un nom combinat de i Representa el següent salt d'Ethereum cap a un futur altament escalable i ric en dades on els rollups de la capa 2 poden operar més barat i més ràpid. Fulu (execution layer) Osaka (consensus layer) In this blog, we’ll break down the core features of the Fusaka hard fork, explain how PeerDAS works in practice, and walk through the real network requirements for home stakers, supernodes, and full nodes — backed by devnet data. Key Changes Introduced In Fusaka Hard Fork Principals canvis introduïts en Fusaka Hard Fork : PeerDAS - Peer Data Availability Sampling EIP-7594 Càtedra 7594 Ethereum needed this proposal because the network wants to provide more data availability for users and especially for rollups, but with the current El disseny, cada node encara ha de descarregar massa dades blob només per comprovar que realment es va publicar. Això crea un problema d'escala perquè si tots els nodes han de descarregar tot, els requisits de banda ampla i maquinari de la xarxa augmenten, i la descentralització pot patir. Per corregir això, Ethereum necessita una manera per als nodes de confirmar que les dades estan disponibles sense descarregar-ho tot. Data Availability Sampling (DAS) ho resol permetent que els nodes només comprovin petites peces aleatòries de les dades. Però Ethereum també necessita un mètode DAS que s'ajusti bé a la xarxa de rumors existent i no afegeix càlcul pesat als fabricants de blocs. PeerDAS va ser creat per satisfer aquestes necessitats EIP-4844 PeerDAS is a networking system that lets nodes download only small pieces of blob data to check that the full data was actually published. Instead of downloading everything, nodes use the normal gossip network to share data, discover which peers hold certain parts, and request just the small samples they need. The main idea is that by downloading only tiny, random parts of the blob, nodes can still be confident that the entire blob exists. For example, instead of downloading a full 256 KB blob, a node might download only about 1/8 of it—but because many nodes sample different parts, any missing data would quickly be noticed. Per fer el treball de mostreig, PeerDAS amplia cada blob de utilitzant un tipus bàsic de codificació d'esborrat. —Semblant a com es pot completar un trencaclosques fins i tot si es perden unes quantes peces. El blob es converteix en una “fila” que conté les dades originals més algunes dades codificades addicionals que li permeten reconstruir-se més tard. Aquesta fila es divideix en moltes peces petites anomenades cèl·lules, que són les unitats verificades més petites lligades a un compromís KZG. Totes les files es reorganitzen en “columnes”, on cada columna conté la cel·la en la mateixa posició de cada fila. Cada columna s'assigna a una subred de trucades específiques. Els nusos són responsables de l'emmagatzematge de certes columnes basades en el seu ID de node i de la reconstrucció d'al 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 A més, l’IPE introdueix una regla important: . This limit must be enforced during transaction validation, gossip, block creation, and block processing. This helps reduce extreme cases where a single transaction overloads the blob system. no transaction can contain more than 6 blobs Pujol afegeix una cosa anomenada . A cell KZG proof shows that a KZG commitment really matches one specific cell (one small piece) of a blob. This lets a node download only the cells it wants to sample, instead of the full blob, while still guaranteeing data integrity. This is essential for data availability sampling. cell KZG proofs But generating all these cell proofs is expensive. A block producer would need to compute them again and again for many blobs, which is too slow. Proof verification, however, is very cheap. So the EIP requires per generar totes les proves cel·lulars amb antelació i incloure-les en el transaccionari. the blob transaction sender A causa d'això, el truc de transacció (PooledTransactions) ara utilitza un embolcall modificat: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) A l’interior del nou recinte, is just a list that contains every proof for every cell of every blob (for example: Els altres camps - , , i — són exactament els mateixos que eren en EIP-4844.La diferència és que l'antic camp de "proves" és eliminat i reemplaçat per aquest nou list, and a new field called s'afegeix per mostrar quin format d'envàs s'utilitza. cell_proofs [cell_proof_0, cell_proof_1, ...] tx_payload_body blobs commitments cell_proofs wrapper_version El is a single byte, and in this proposal it is always set to El El camp conté totes les proves de cèl·lules per a cada blob, incloent-hi les proves per a les cèl·lules d'extensió addicionals creades durant la codificació de l'esborrat. Tot i que la llista conté proves per a les cèl·lules d'extensió, els blobs mateixos encara s'envien en la seva forma normal (no-extensa). un blob només inclou la meitat original - el node receptor pot calcular la meitat de l'extensió per si mateix, de manera que no hi ha necessitat d'enviar dades innecessàries. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB I més formalment, és la prova per a la j-ta cel·la de la i-ta blob després de córrer , que produeix les cèl·lules originals i d'extensió. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) Quan un node rep aquest embolcall, ha de validar la transacció i comprovar que tot està en línia correctament. Ha de verificar que el nombre d'hashes, blobs i compromisos de versió coincideixin. contains exactly Totes les proves han de ser hash a la seva versió corresponent hash ( Finalment, el node ha de comprovar que cada compromís coincideix realment amb el blob i les seves proves. , i després verifica totes les proves cel·lulars - es permet la verificació de lot per fer això més ràpid. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells Imagineu que un blob es divideix en després d'esborrar el codi ( El blob original conté , i el node receptor calcularà la falta l’enviament, però l’enviador ha d’incloure en . 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: (only original 4 cells) blobs = [blob_0] commitments = [commitment_0] (proof for each of the 8 cells) cell_proofs = [proof_0, proof_1, …, proof_7] Quan un node mostra, només pot sol·licitar la cel·la 2 o la cel·la 5, i pot verificar-les instantàniament utilitzant les proves corresponents, sense descarregar mai el blob complet. PeerDAS permet a Ethereum augmentar la disponibilitat de dades sense fer que els nodes treballin més durament. En el futur, això pot fins i tot baixar a , which would let Ethereum scale more. The system works well because every node has many peers. So if one peer does not give the required data, the node can simply ask another peer. This creates natural redundancy and improves security. Nodes can also choose to store data than required, which further strengthens the network—even without any protocol changes. 1/8 of the total blob data 1/16 or 1/32 more Els validadors tenen una mica més de responsabilitat que els nodes complets normals. Atès que els validadors ja estan executant un maquinari més fort, PeerDAS els dóna una càrrega de custòdia de dades que coincideix amb el nombre total de validadors. Això garanteix que un grup estable de nodes està sempre disponible per emmagatzemar i compartir més dades, la qual cosa fa que la xarxa sigui més fiable. En resum, si hi ha 900.000 validadors, cada validador podria ser assignat una petita part de les dades totals de blob per emmagatzemar i servir. Els peers utilitzen En comptes de mostreig de files, perquè fa que la reconstrucció de les dades sigui molt més fàcil. Si els nodes mostren files completes (blobs sencers), haurien de crear "blobs d'extensió" addicionals que no existeixen de forma natural, el que retardaria els productors de blocs. Imagineu-vos que un blob és una xarxa de cèl·lules de 4×4. Sampling de filferro vol dir prendre totes les 4 cèl·lules d'una fila, però algunes files d'extensió encara no estan preparades, de manera que el productor del bloc hauria de generar-les en el lloc. Sampling de columnes vol dir prendre una cèl·lula de cada fila (una columna). Les cèl·lules addicionals necessàries per a la reconstrucció es poden preparar amb antelació, de manera que els nodes poden verificar les dades sense retardar la producció del bloc. column sampling Example: Treballa plenament amb , so it doesn’t break anything already on Ethereum. All tests and detailed rules are in the consensus and execution specs. 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. La taula mostra que les probabilitats d'un atac reeixit cauen a un nivell negligible, per la qual cosa PeerDAS es considera segur contra atacs de retenció de dades. . El blog : Set upper bounds for MODEXP EIP-7823 EIP-7823 Aquesta proposta és necessària perquè l'actual precompilació de MODEXP a Ethereum ha causat molts errors de consens al llarg dels anys. La majoria d'aquests errors es van produir perquè MODEXP permet mides d'entrada extremadament grans i irrealistes, la qual cosa crea casos infinits i inusuals que els clients han de gestionar. Atès que cada node ha de processar qualsevol entrada que proporcioni una transacció, no tenir un límit superior fa que MODEXP sigui més difícil de provar, més fàcil de trencar i més probable de comportar-se de manera diferent entre els diferents clients. Les entrades molt grans també fan difícil preveure la fórmula del cost del gas, perquè és difícil preveure alguna cosa quan la seva mida pot créixer sense límit. Aquests problemes també fan difícil substituir MODEXP amb futures eines EIP-7823 introdueix una regla simple: tots els tres camps de longitud utilitzats per MODEXP -la mida de la BASE, l'EXPONENT i el MODULUS- han de ser: , que és de 1024 bytes. les entrades MODEXP segueixen el format Com es defineix en , de manera que aquest EIP només limita els valors de longitud. Si qualsevol longitud supera 1024 bytes, la precompilació s'atura immediatament, retorna un error i crema tot el gas. Per exemple, si algú intenta proporcionar un BASE que és de 2000 bytes de llarg, la trucada fallarà abans que es produeixi qualsevol treball. Aquests límits encara donen suport a tots els casos d'ús reals. La verificació RSA normalment utilitza mides clau com 1024, 2048, o 4096 bits, tot bé dins del nou límit. Les operacions de corba el·líptica utilitzen mides encara més petites, sovint per sota de 384 bits, de manera que també no es veuen afectades. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 Aquests nous límits també ajuden amb futures actualitzacions.Si MODEXP es reescriu mai en codi EVM utilitzant EVMMAX, els desenvolupadors podrien afegir camins optimitzats per a mides d'entrada comuns com 256 bits, 381 bits, o 2048 bits, i utilitzar un retrocés més lent per a casos més rars. Amb mides màximes fixes, els desenvolupadors poden fins i tot afegir maneig especial per a valors de mòduls molt comuns. To confirm that this change would not break past transactions, the authors analyzed all MODEXP usage from block 5,472,266 (April 20, 2018) to block 21,550,926 (January 4, 2025). The results show that no successful historical MODEXP call ever used inputs larger than , molt per sota del nou límit de 1024 bytes. La majoria de trucades reals van utilitzar petites longituds com 32 bytes, 128 bytes, o 256 bytes. , i una entrada extremadament gran però vàlida. Aquests es comportarien igual sota els nous límits perquè ja eren vàlids. Així, mentre que l'EIP és tècnicament un canvi de ruptura, en la pràctica no hauria canviat el resultat de cap transacció passada. 513 bytes 0x9e5faafc From a security point of view, reducing the allowed input sizes does not create new risks. Instead, it removes unnecessary extreme cases that previously caused bugs and inconsistencies across clients. By limiting MODEXP inputs to realistic sizes, this EIP makes the system more predictable, reduces strange corner cases, and lowers the chance of errors between different implementations. These constraints also help prepare the system for a smoother transition if future upgrades like EVMMAX introduce optimized execution paths. : Transaction Gas Limit Cap EIP-7825 Tàrrega 7825 Ethereum necessitava aquesta proposta perquè avui dia una sola transacció pot utilitzar gairebé tot el límit de gas de bloc. Això crea diversos problemes: una transacció podria consumir la majoria dels recursos del bloc i causar una desacceleració d'estil DoS, les grans operacions de gas pesat poden augmentar l'estat d'Ethereum massa ràpidament, i la validació de blocs es fa més lenta i més difícil per als nodes de mantenir-se al dia. Si un usuari presenta una transacció enorme que utilitza gairebé tot el gas (per exemple, una transacció que consumeix 38 milions de gas en un bloc de 40 milions de gas), llavors altres transaccions normals no poden encaixar en el bloc, i cada node ha de passar temps addicional verificant aquest bloc. Això EIP-7825 introduces a hard rule that no transaction can use more than Això es converteix en un cap a nivell de protocol, el que significa que s'aplica a tot arreu: quan un usuari envia una transacció, quan el txpool la comprova, i quan els validadors la inclouen en un bloc. Aquest límit és completament independent del límit de gas de bloc. Per exemple, fins i tot si el límit de gas de bloc és de 40 milions, no es permet que una sola transacció utilitzi més de 16,7 milions de gas. 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEED MAX_GAS_LIMIT_EXCEEDED Per entendre-ho millor, imagineu que un bloc té espai per a 40 milions de gasos. Sense aquest límit, algú podria enviar una única transacció que consumeixi 35-40 milions de gasos. Aquesta transacció monopolitzaria el bloc i no deixaria espai per a altres, similar a una persona que lloga un autobús sencer perquè ningú més pugui embarcar. The proposal also adds specific requirements to how clients validate transactions. The txpool must refuse a transaction if its gasLimit is above 16,777,216, meaning such a transaction never even enters the queue. During block validation, if a block contains a transaction that exceeds the cap, the block itself must be rejected. Internally, client implementations will cap the GAS_LIMIT parameter for all transactions at this value. El número va ser triat perquè és un límit de potència neta de dos, el que el fa més fàcil d'implementar, i encara és prou gran per gestionar la majoria de transaccions del món real, com ara implantacions de contractes intel·ligents, interaccions complexes DeFi, o trucades de contractes de múltiples passos. 16,777,216 (2²⁴) Aquest EIP també manté la compatibilitat amb la mecànica del gas actual. La majoria dels usuaris mai no notaran el canvi perquè gairebé totes les transaccions existents ja consumeixen molt menys de 16 milions de gas. Els validadors i els constructors de blocs encara poden crear blocs que superen els 16,7 milions de gas total, sempre que cada transacció respecti el nou cap. Les úniques transaccions afectades són les extremadament grans que abans havien intentat utilitzar més del nou límit. Aquestes transaccions han de ser ara dividides en múltiples operacions més petites -similar a trencar un arxiu molt gran carregat en dos més petits. Aquest canvi no és tècnicament compatible amb les transaccions extremes rares, però el nombre d'usuaris afectats s'espera que sigui molt petit. En termes de seguretat, el cap de gas fa que Ethereum sigui més resilient als atacs DoS basats en gas perquè els atacants no poden forçar els validadors a gestionar transaccions extremadament grans més. També ajuda a mantenir els temps de verificació de bloc predictibles perquè els nodes puguin romandre en sincronització més fàcilment. Overall, EIP-7825 is designed to strengthen the network against abuse, keep node requirements reasonable, improve fairness in block space usage, and ensure the chain remains fast and stable as gas limits continue to increase over time. : ModExp Gas Cost Increase EIP-7883 Càtedra 7883 The reason Ethereum needs this proposal is that the ModExp precompile (used for modular exponentiation) has been en comparació amb els recursos reals que consumeix. En algunes situacions, les operacions de ModExp requereixen molt més computació que el que els usuaris estan pagant actualment. and make it harder for the network to safely increase the block gas limit, since block producers may be forced to process extremely heavy operations for very little cost. To fix this, Ethereum needs to adjust the ModExp pricing formula so that the gas used properly reflects the real work done by the client. That is why EIP-7883 introduces new rules that increase the minimum cost, raise the general cost, and make operations with large inputs (especially exponents, base, or modulus over 32 bytes) more expensive, so the gas pricing matches the true computation required. underpriced bottleneck This proposal modifies the ModExp pricing algorithm originally defined in EIP-2565 by increasing the cost in several important ways. First, the s'eleva de 200 a 500, i la fórmula general ja no es divideix per 3, el que significa que el cost total efectivament esdevé . For example, if a ModExp call previously cost 1,200 gas, it will now cost around 3,600 gas under the new formula. Second, the cost of operations with es duplica augmentant el multiplicador de 8 a 16. per il·lustrar això: si la longitud de l'exponent era de 40 bytes, EIP-2565 afegiria en el compte d'iteració, mentre que EIP-7883 ara utilitza El preu és el doble que el preu, i el preu és el doble que el preu. Per exemple, si el mòdul és de 64 bytes, la nova regla aplica una complexitat doblada ( ) en comptes de l'antiga fórmula més simple, que reflecteix el cost real de l'aritmètica de grans nombres. Junts, aquests canvis asseguren que les petites operacions de ModExp paguin una tarifa mínima justa i les grans operacions pesades escalen el seu cost correctament amb la mida. 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² The proposal defines a new gas calculation function that updates the complexity and iteration count rules. The multiplication complexity now uses a default value of 16 for base/modulus lengths up to 32 bytes, and for larger inputs it switches to the heavier formula , on "paraules" és el nombre de trossos de 8 bytes. El recompte d'iteració també s'actualitza de manera que els exponents de 32 bytes o més petits utilitzen la seva longitud de bit per determinar la complexitat, però els exponents més grans de 32 bytes afegeixen una penalització molt més gran. Això assegura que els exponents molt grans, que són computacionalment cars en la pràctica, ara tenen un cost de gas molt més alt. 2 × words² La motivació darrere d'aquests increments de preus prové dels criteris de referència que mostren moltes situacions en què el precompilador de ModExp va ser significativament menyspreat. , typical operations by around , i operacions molt grans o desequilibrades per factors molt més grans -de vegades més que —depending on how big the exponent, base, or modulus is. The intent is not to change how ModExp works, but to ensure that even in its most resource-intensive edge cases it no longer threatens network stability or prevents future increases to the block gas limit. Because this EIP changes how much gas ModExp requires, it is , però la repricing de gas s'ha produït moltes vegades abans en Ethereum i és ben entès. 150% 200% 80× backward-incompatible Els resultats de les proves mostren com de significatius poden ser els increments. ara costarà 500 gasos (a partir de 200) o tres vegades el preu anterior. Però alguns casos de proves pesants veuen enormes augments. Per exemple, en una prova "exp-pesa", el cost salta de 215 gasos a 16.624 gasos, aproximadament En un altre cas que involucra una operació de base pesada, el cost va de 1.026 a 94.448 gas, que reflecteix com la multiplicació de grans nombres realment escala. 99.69% of historical ModExp calls 76× more En termes de seguretat, aquesta proposta no crea nous vectors d'atac ni fa que qualsevol operació sigui més barata. En canvi, se centra en prevenir un risc important: les operacions de ModExp de baix preu podrien fer que els atacants puguin omplir blocs amb càlculs extremadament pesats per un cost molt baix. L'únic inconvenient possible és que algunes operacions de ModExp ara podrien ser sobrepreu, però això es considera un resultat molt millor que el problema actual de subpreu. 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_màxic_1_square 200 500 El 150% modexp_nagydani_1_qube 200 500 El 150% modexp_coneixedora_1_pow0x10001 341 2048 El 501% modexp_nagydani_2_square 200 512 El 156% modexp_narrador_2_quebratge 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 El 501% modexp_màxic_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 El 500% modexp_màxic_4_square 1365 8192 El 501% modexp_nagydani_4_qube 1365 8192 El 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_màxic_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500% modexp_descàrrega_5_pow0x10001 87381 524288 El 500% modexp_marius_1_even 2057 45296 El 2102% modexp_guido_1_even 2298 51136 El 2125% modexp_guido_2_esquerra 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_càrrega 852 16368 1821% modexp_marcin_2_devolució 996 5978 El 500% modexp_marcin_3_base_grau 677 2032 200% modexp_marcin_3_exp_càrrega 765 4080 433% modexp_marcin_3_devolució 1360 4080 200% *source: https://eips.ethereum.org/EIPS/eip-7883#test-cases* : Determine proposer lookahead EIP-7917 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 . These EB changes can come from slashings, penalties, rewards above 1 ETH, validator consolidations, or new deposits—especially after EIP-7251 raised the maximum effective balance beyond 32 ETH. This uncertainty creates issues for systems that rely on knowing the next proposer in advance, such as based preconfirmation protocols, which need a stable and predictable schedule to operate smoothly. A validator could even try to “grind” or manipulate their effective balance to influence who becomes the proposer next epoch. Because of these problems, Ethereum needed a way to make the proposer schedule fully deterministic several epochs ahead so it cannot be changed by last-minute EB updates and can be easily accessed by the application layer. N+1 N N Per implementar-ho, l'EIP introdueix un propositor determinista mirant cap endavant pre-calculant i emmagatzemant l'horari del propositor per als propers períodes MIN_SEED_LOOKAHEAD + 1 a l'inici de cada època. that always covers two full epochs of proposers - 64 slots in total. For example, when epoch N begins, this list already includes the proposer for every slot in epoch N and epoch N+1. Then, when the network moves to epoch N+1, the list is shifted forward: the proposer entries for epoch N are removed, the entries for epoch N+1 move to the front, and new proposer entries for epoch N+2 are added at the end. This makes the schedule fixed, predictable, and easy for clients to read directly, instead of recomputing proposers every slot. proposer_lookahead To keep this updated, the list shifts forward at every epoch boundary: the data for the past epoch is removed, and a new set of proposer indices for the next future epoch is computed and appended. The process uses the same seed and effective balance rules as before, but now the schedule is calculated earlier, removing the possibility of EB changes affecting it after the seed is known. The very first block after the fork also fills this entire lookahead range so that all future epochs have properly initialized schedules. 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. Inici 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. Els autors van considerar alternatives, com ara l'emmagatzematge de les balances efectives a l'inici d'una època, però això requeriria un emmagatzematge addicional i no exposaria l'horari a l'EVM. També van comprovar la compatibilitat amb futures característiques com Single Secret Leader Election (SSLE). Abans d'aquesta proposta, els clients només calculaven el proponent per a la ranura actual. Amb EIP-7917, ara calculen la llista de proponents per a totes les ranures de la propera època alhora durant cada transició d'època. Això afegeix una petita quantitat de treball, però el càlcul dels índexs de proponents és molt lleuger i principalment implica la mostra de les llistes de validadors utilitzant la llavor. Aquest EIP no canvia la forma en què funciona el retard de RANDAO. 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 necessita aquesta proposta perquè l'actual sistema de tarifes de blob (de ) es trenca quan el gas d'execució es converteix en el principal cost per als rollups. Ara mateix, la majoria dels rollups paguen molt més pel gas d'execució (el cost d'incloure la seva transacció blob al bloc) del que paguen per la quota de blob real. Això crea un problema: fins i tot si Ethereum continua rebaixant la quota de base de blob una i altra vegada, el cost total del rollup no canvia realment, perquè la part cara és encara el gas d'execució. A causa d'això, la quota de base de blob continua caient fins que arriba al mínim absolut (1 wei), i el protocol ja no pot utilitzar la quota de blob per controlar la demanda. Llavors, quan l'ús de blob de sobte puja, la quota de EIP-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 The core idea of EIP-7918 is simple: the price of a blob should never be cheaper than the cost of a certain amount of execution gas (called ). 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 entendre per què això és necessari, ajuda a mirar la demanda de blob. Un rollup es preocupa pel preu total que paga: cost d'execució més cost de blob. Si la quota de gas d'execució és molt alta -per exemple, 20 gwei- llavors, fins i tot si la quota de blob cau de 2 gwei a 0,2 gwei, el cost total amb prou feines canvia. Això vol dir que reduir la quota de base de blob no té gairebé cap impacte en la demanda. .” It creates a situation where the demand curve is almost vertical: lowering price does not increase demand. When this happens, the blob base fee mechanism becomes blind—it keeps lowering the price even though demand does not react. That is why the blob base fee often slides down to 1 wei. Then, when real demand increases later, the protocol needs an hour or more of nearly full blocks to raise the fee back up to a reasonable level. EIP-7918 fixes this by establishing a reserve price tied to execution gas so that blob fees remain meaningful even when execution costs dominate. fee inelasticity Una altra raó per afegir aquest preu de reserva és que els nodes han de fer molta feina addicional per verificar les proves de KZG per a les dades de blob. Aquestes proves són la garantia que les dades dins d'un blob realment coincideixen amb el seu compromís. , 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 Càtedra 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 ( ) es considera segura i ben equilibrada. BLOB_BASE_COST = 2¹³ Hi ha un petit detall per entendre quan les tarifes de gas d'execució salten sobtadament. Atès que el preu de reserva de blob depèn de la tarifa base d'execució, un sobtat augment en els costos d'execució pot empènyer temporalment les tarifes de blob a un estat on les tarifes d'execució les guien. Per exemple, imagineu que el gas d'execució salta sobtadament de 20 gwei a 60 gwei en un bloc. Atès que el preu de reserva de blobs està vinculat a aquest nombre, les tarifes de blob no poden caure per sota del nou nivell més alt. Les tarifes de blob encara augmentaran normalment si s'utilitzen blobs, però el protocol no els permetrà disminuir fins que hagin augmentat suficientment per a The authors also performed empirical analysis by applying the reserve price rule to real blob activity from and . During high-execution-fee periods (around ), the reserve threshold significantly increased the blob base fee compared to the old mechanism. During low-execution-fee periods (around ), the blob fee remained almost unchanged except when the calculated blob base fee dropped below the reserve price. By comparing thousands of blocks, the authors show that the new mechanism creates more stable pricing while still responding naturally to demand. A histogram of four months of blob fees shows that the reserve price prevents blob fees from collapsing toward 1 wei, which reduces extreme volatility. November 2024 March 2025 16 gwei average 1.3 gwei average Pel que fa a la seguretat, el canvi no introdueix cap risc. La quota de base de blob sempre s'establirà en o per sobre del cost de units of execution gas. This is safe because the mechanism only raises the minimum fee, and setting a lower bound on pricing does not interfere with protocol correctness. It simply ensures healthy economics. BLOB_BASE_COST : RLP Execution Block Size Limit EIP-7934 EIP-7934 Before EIP-7934, Ethereum did 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 , meaning oversized execution blocks could fail to spread across the network, creating fragmentation or nodes disagreeing on the chain. Because of these risks, Ethereum needed a clear, protocol-level rule to prevent oversized blocks and keep the network stable and secure. not network instability DoS attack risks 10 MB EIP-7934 solves this by introducing a L'execució de l'execució d'un bloc amb codificació RLP. La mida màxima permesa del bloc ( ) is set to , but because beacon blocks also consume some space ( ), Ethereum afegeix a Això vol dir que la mida real màxima de bloc d'execució codificada per RLP permesa és Si el bloc codificat és més gran que aquest límit, el bloc es considera and nodes must reject it. With this rule in place, block producers must check the encoded size of every block they build, and validators must verify this limit during block validation. This size cap applies of gas limits -meaning even if a block is “ ” it can still be rejected if its encoded size is too large. This ensures that both gas usage and real byte-size constraints are respected. 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, Choosing 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 This change is amb blocs més grans que el nou límit, el que significa que els miners i validadors han d'actualitzar els seus clients per respectar la regla. No obstant això, ja que els blocs de mida excessiva ja eren problemàtics i no normals en el funcionament real, l'impacte és mínim. En termes de seguretat, aquest EIP reforça significativament Ethereum contra atacs DoS de mida de bloc dirigits assegurant que cap participant no pugui crear blocs que aclaparin la xarxa. En general, EIP-7934 afegeix un límit de seguretat important, millora l'estabilitat, alinea el comportament d'EL i CL i evita diverses classes d'atacs relacionats amb la creació i propagació de blocs de mida excessiva. not backward-compatible : Count leading zeros (CLZ) opcode EIP-7939 EIP-7939 Before this EIP, Ethereum had 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 , and , 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 soluciona aquest problema introduint una . This opcode takes a 256-bit value from the stack and returns the number of leading zero bits. If the input number is zero, the opcode returns , perquè un zero de 256 bits té 256 bits de zero. Això coincideix amb com CLZ funciona en moltes arquitectures de CPU com ARM i x86, on aquesta operació és 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 Igual que 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 , reducing ZK proving costs. The EIP also explains why they chose CLZ instead of : es pot calcular CTZ de CLZ utilitzant Però tu implementar de manera fiable CLZ utilitzant CTZ, de manera que CLZ és més fonamental. The gas cost for CLZ is set to 5 ADD cheaper to prove than ADD CTZ (count trailing zeros) x & -x cannot Aquesta norma és totalment retrocompatible, ja que introdueix una També cobreix clarament els casos d'avantguarda: per exemple, l'opcode retorna 256 quan l'entrada és zero, i diversos casos de prova mostren entrades com ara valors de tot zero, top-bit i completament nonzero. Atès que CLZ té un cost de gas predictible i baix, cap creixement de la memòria i cap canvi d'estat, és segur dels problemes de denegació de servei. new Overall, EIP-7939 makes Ethereum faster, cheaper, and more developer-friendly by adding a simple, efficient primitive that modern CPUs already support — cutting gas, reducing bytecode size, and lowering ZK proving costs for many common operations. : Precompile for secp256r1 Curve Support EIP-7951 Títol: EIP-7951 Before this EIP, Ethereum did have a safe, native way to verify digital signatures created using the Aquesta corba és l'estàndard utilitzat en dispositius moderns com . Because of this missing support, apps and wallets could not easily use device-level hardware security for signing. There was an earlier attempt (RIP-7212), but it had 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 at address called , que realitza la verificació de la signatura ECDSA utilitzant la corba secp256r1. Això fa que la verificació de la signatura sigui ràpida i barata en comparació amb la implementació de l'algorisme directament a Solidity. El precompila utilitza els paràmetres oficials de la corba definits per NIST, incloent el mòdul de camp, l'equació de la corba, el punt de base i l'ordre del subgrup, garantint una forta seguretat criptogràfica. Els punts i les escales estan codificats en un estricte format big-endian de 32 bytes, i un valor de 64 bytes de tot-zero s'utilitza per representar el punt a l'infinit. - el hash, la signatura (r, s) i les coordenades de clau pública (qx, qy) - i retorna Per a l’èxit o pel fracàs. 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 La corba secp256r1 es defineix completament pel següent conjunt de paràmetres: 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 Aquests paràmetres són estandarditzats pel NIST en SP 800-1861. The gas cost for the operation is set to , 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 La taula següent resumeix quins clients Ethereum necessiten implementar canvis per a cada Fusaka EIP. indica que l'EIP requereix actualitzacions als clients de la capa de consens, mentre que una marca de shows that the change affects execution-layer clients. Some EIPs require updates in both layers, while others are specific to just one. 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 ✅ Càtedra 7594 PeerDAS - Sampling de disponibilitat de dades ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ Tàrrega 7825 Cap límit de transacció de gas ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7917 Determinista proposador lookahead ✅ Càtedra 7918 Blob base fee bounded by execution cost ✅ Títol: EIP 7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompilació per secp256r1 ✅ In summary, these are the key EIPs included in the Fusaka hard fork. While several improvements touch both consensus and execution clients—ranging from gas adjustments and opcode updates to new precompiles—the , which introduces peer-to-peer data availability sampling, enabling more efficient and decentralized handling of blob data across the network. major change of this upgrade is PeerDAS
