The Fusaka hard fork, scheduled for activation on December 3, 2025, is Ethereum’s next major network upgrade after Pectra, and it marks one more scaling step taken by the crypto giant. Fusaka hard fork Fusaka hard fork December 3, 2025 The Pectra EIPs focus on improving performance, security, and developer tools. PeerDAS (EIP-7594) makes data availability more efficient by letting nodes verify blobs without downloading everything. Several upgrades tighten execution safety, including limits on ModExp (EIP-7823), a cap on transaction gas limits (EIP-7825), and updated ModExp gas costs (EIP-7883). The fork also improves block production with deterministic proposer lookahead (EIP-7917) and keeps blob fees stable with bounds tied to execution costs (EIP-7918). Additional enhancements include limiting block size in RLP format (EIP-7934), adding a new CLZ opcode for faster bit operations (EIP-7939), and introducing a secp256r1 precompile (EIP-7951) 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 Just as Pectra combined “Prague” and “Electra,” Fusaka is a combined name of Fulu (execution layer) and Osaka (consensus layer). It represents Ethereum’s next leap toward a highly scalable, data-rich future where Layer 2 rollups can operate cheaper and faster. 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 Key Changes Introduced In Fusaka Hard Fork EIP-7594: PeerDAS - Peer Data Availability Sampling EIP-7594: PeerDAS - Peer Data Availability Sampling EIP-7594 Ethereum needed this proposal because the network wants to provide more data availability for users and especially for rollups, but with the current EIP-4844 design, every node still has to download too much blob data just to check that it was actually published. This creates a scaling problem because if all nodes must download everything, the network’s bandwidth and hardware requirements go up, and decentralization can suffer. To fix this, Ethereum needs a way for nodes to confirm that data is available without downloading all of it. Data Availability Sampling (DAS) solves this by letting nodes check only small random pieces of the data. But Ethereum also needs a DAS method that fits well with the existing gossip network and doesn’t add heavy computation to block producers. PeerDAS was created to meet these needs and safely increase blob throughput while keeping node requirements low. EIP-4844 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. To make sampling work, PeerDAS expands each blob from EIP-4844 using a basic type of erasure coding. Erasure coding is a technique that adds extra redundant data so that the original data can be recovered even if some pieces are missing—similar to how you can complete a puzzle even if a few pieces are lost. The blob becomes a “row” that contains the original data plus some extra coded data that allows it to be rebuilt later. This row is then split into many small pieces called cells, which are the smallest verified units tied to a KZG commitment. All rows are then reorganized into “columns,” where each column contains the cell at the same position from every row. Each column is assigned to a specific gossip subnet. Nodes are responsible for storing certain columns based on their node ID and for sampling a few columns from peers every slot. If a node collects at least 50% of all columns, it can fully rebuild the data. If it has less than 50%, it simply requests the missing columns from peers. This ensures that if the data was actually published, it can always be reconstructed. In short, if there are 64 columns in total, a node only needs about 32 of them to rebuild the full blob. It keeps some columns itself and downloads a few from peers. As long as half the columns exist in the network, the node can reconstruct everything—even if some columns are missing. EIP-4844 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: no transaction can contain more than 6 blobs. 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 PeerDAS adds something called cell KZG proofs. 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 the blob transaction sender to generate all the cell proofs ahead of time and include them in the transaction wrapper. the blob transaction sender Because of this, the transaction gossip (PooledTransactions) now uses a modified wrapper: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) Inside the new wrapper, cell_proofs is just a list that contains every proof for every cell of every blob (for example: [cell_proof_0, cell_proof_1, ...]). The other fields — tx_payload_body, blobs, and commitments — are exactly the same as they were in EIP-4844. The difference is that the old single “proofs” field is removed and replaced with this new cell_proofs list, and a new field called wrapper_version 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 wrapper_version is a single byte, and in this proposal it is always set to 1. The cell_proofs field contains all of the cell proofs for each blob, including the proofs for the extra extension cells created during erasure coding. Because of the erasure coding, each blob corresponds to CELLS_PER_EXT_BLOB cell proofs. Even though the list contains proofs for the extension cells, the blobs themselves are still sent in their normal (non-extended) form. A blob only includes its original half—the receiving node can compute the extension half on its own, so there’s no need to send unnecessary data. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB More formally, cell_proofs[i * CELLS_PER_EXT_BLOB + j] is the proof for the j-th cell of the i-th blob after running compute_cells(blobs[i]), which produces both the original and extension cells. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) When a node receives this wrapper, it must validate the transaction and check that everything lines up correctly. It must verify that the number of versioned hashes, blobs, and commitments all match. It must also confirm that cell_proofs contains exactly CELLS_PER_EXT_BLOB * number_of_blobs proofs. Every commitment must hash to its matching versioned hash (kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]). Finally, the node must check that each commitment actually matches the blob and its proofs. To do this, it computes the extension cells locally using compute_cells, and then verifies all the cell proofs—batch verification is allowed to make this faster. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells Example: Imagine a blob is split into 8 cells after erasure coding (CELLS_PER_EXT_BLOB = 8). The original blob contains 4 cells, and the receiving node will compute the missing 4 extension cells itself. But the sender must include all 8 proofs in cell_proofs. 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] (only original 4 cells) commitments = [commitment_0] cell_proofs = [proof_0, proof_1, …, proof_7] (proof for each of the 8 cells) blobs = [blob_0] (only original 4 cells) blobs = [blob_0] commitments = [commitment_0] commitments = [commitment_0] cell_proofs = [proof_0, proof_1, …, proof_7] (proof for each of the 8 cells) cell_proofs = [proof_0, proof_1, …, proof_7] When a node samples, it might request only cell 2 or cell 5, and it can verify them instantly using the matching proofs, without ever downloading the full blob. PeerDAS lets Ethereum increase data availability without making nodes work harder. Today, a node only needs to sample about 1/8 of the total blob data. In the future, this might even go down to 1/16 or 1/32, 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 more 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 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 uses column sampling instead of row sampling because it makes rebuilding the data much easier. If nodes sampled full rows (whole blobs), they would need to create extra “extension blobs” that don’t naturally exist, which would slow down block producers. By sampling columns, nodes can prepare the extra row data in advance, and the transaction senders—not the block producers—compute the necessary proofs. This keeps block creation fast and efficient. Example: Imagine a blob is a 4×4 grid of cells. Row sampling would mean taking all 4 cells from one row, but some extension rows aren’t ready yet, so the block producer would have to generate them on the spot. Column sampling means taking one cell from each row (a column). The extra cells needed for reconstruction can be prepared ahead of time, so nodes can verify the data without slowing down block production. column sampling Example: EIP-7594 works fully with EIP-4844, so it doesn’t break anything already on Ethereum. All tests and detailed rules are in the consensus and execution specs. EIP-7594 EIP-7594 EIP-4844 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 blog. blog EIP-7823: Set upper bounds for MODEXP EIP-7823: Set upper bounds for MODEXP EIP-7823 This proposal is needed because the current MODEXP precompile in Ethereum has caused many consensus bugs over the years. Most of these bugs happened because MODEXP allows extremely large and unrealistic input sizes, which creates endless, unusual cases that clients must handle. Since every node has to process whatever input a transaction provides, having no upper limit makes MODEXP harder to test, easier to break, and more likely to behave differently across different clients. Very large inputs also make the gas-cost formula hard to predict, because it is difficult to price something when its size can grow without limit. These problems also make it difficult to replace MODEXP with future EVM-level code through tools like EVMMAX, because without fixed limits, developers cannot create safe and optimized execution paths. To reduce these issues and make Ethereum more stable, this proposal adds strict maximum sizes to MODEXP inputs so that the precompile becomes safer, easier to test, and more predictable. EIP-7823 introduces a simple rule: all three length fields used by MODEXP—the size of the BASE, the EXPONENT, and the MODULUS—must be 8192 bits or less, which is 1024 bytes. MODEXP inputs follow the format <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>, as defined in EIP-198, so this EIP only restricts the length values. If any length exceeds 1024 bytes, the precompile immediately stops, returns an error, and burns all gas. For example, if someone tries to provide a BASE that is 2000 bytes long, the call will fail before any work happens. These limits still support all real use cases. RSA verification typically uses key sizes like 1024, 2048, or 4096 bits, all well within the new limit. Elliptic curve operations use even smaller sizes, often under 384 bits, so they are also unaffected. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 EIP-198 These new limits also help with future upgrades. If MODEXP is ever rewritten in EVM code using EVMMAX, developers could add optimized paths for common input sizes like 256 bits, 381 bits, or 2048 bits, and use a slower fallback for rarer cases. With fixed maximum sizes, developers can even add special handling for very common modulus values. None of this was realistic before, because the unlimited input sizes made the design space too large to manage safely. 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 513 bytes, far below the new 1024-byte limit. Most real calls used small lengths like 32 bytes, 128 bytes, or 256 bytes. There were a few invalid or broken calls, such as empty inputs, inputs filled with repeating bytes like 0x9e5faafc, and one extremely large but invalid input. These would behave the same under the new limits because they were already invalid. So, while the EIP is technically a breaking change, in practice it would not have changed the outcome of any past transaction. 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. EIP-7825: Transaction Gas Limit Cap EIP-7825: Transaction Gas Limit Cap EIP-7825 Ethereum needed this proposal because today a single transaction can use almost the entire block gas limit. This creates several problems: one transaction could consume most of the block’s resources and cause a DoS-style slowdown, large gas-heavy operations can increase Ethereum’s state too quickly, and block validation becomes slower and harder for nodes to keep up with. If one user submits a huge transaction that uses nearly all the gas (for example, a transaction that consumes 38 million gas in a 40 million–gas block), then other normal transactions cannot fit into the block, and every node must spend extra time verifying that block. This threatens network stability and decentralization because slower verification means weaker nodes fall behind. To solve this, Ethereum needs a safe upper limit on how much gas a single transaction can use, so block load becomes more predictable, DoS risk is reduced, and nodes have a more even workload. EIP-7825 introduces a hard rule that no transaction can use more than 16,777,216 gas (2²⁴). This becomes a protocol-level cap, meaning it applies everywhere: when a user sends a transaction, when the txpool checks it, and when validators include it in a block. If someone sends a transaction with a gasLimit higher than this number, the client must reject it immediately with an error such as MAX_GAS_LIMIT_EXCEEDED. This cap is completely independent of the block gas limit. For example, even if the block gas limit is 40 million, no single transaction is allowed to use above 16.7 million gas. The goal is to make sure that many transactions can fit inside each block instead of letting one transaction dominate the entire block. EIP-7825 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEEDED MAX_GAS_LIMIT_EXCEEDED 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. 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. The number 16,777,216 (2²⁴) was chosen because it is a clean power-of-two boundary, making it easier to implement, and it is still large enough to handle most real-world transactions such as smart contract deployments, complex DeFi interactions, or multi-step contract calls. This value is roughly half of the typical block size, meaning even the most complex transactions should still fit comfortably within this limit. 16,777,216 (2²⁴) This EIP also maintains compatibility with current gas mechanics. Most users will never notice the change because nearly all existing transactions already consume far less than 16 million gas. Validators and block builders can still create blocks that exceed 16.7 million total gas, as long as each individual transaction respects the new cap. The only transactions affected are extremely large ones that previously attempted to use more than the new limit. Those transactions must now be split into multiple smaller operations—similar to breaking a very large file upload into two smaller ones. This change is technically not backward-compatible for those rare extreme transactions, but the number of users affected is expected to be very small. In terms of security, the gas cap makes Ethereum more resilient to gas-based DoS attacks because attackers cannot force validators to handle extremely large transactions anymore. It also helps keep block verification times predictable so that nodes can stay in sync more easily. The main edge case is that a few very large contract deployments may not fit under the cap and might need to be redesigned or split into multiple deployment steps. 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. EIP-7825 EIP-7883: ModExp Gas Cost Increase EIP-7883: ModExp Gas Cost Increase EIP-7883 The reason Ethereum needs this proposal is that the ModExp precompile (used for modular exponentiation) has been underpriced compared to the actual resources it consumes. In some situations, ModExp operations require far more computation than what users are currently paying for. This mismatch creates a risk: if complex ModExp calls stay too cheap, they can become a bottleneck 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 minimum gas cost is raised from 200 to 500, and the general formula no longer divides by 3, meaning the total cost effectively becomes three times higher. 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 exponents larger than 32 bytes is doubled by increasing the multiplier from 8 to 16. To illustrate this: if the exponent length was 40 bytes, EIP-2565 would add 8 × (40 − 32) = 64 to the iteration count, while EIP-7883 now uses 16 × (40 − 32) = 128, making it twice as expensive. Third, the pricing now assumes a minimum base/modulus size of 32 bytes and sharply increases the computation cost when these values exceed 32 bytes. For example, if the modulus is 64 bytes, the new rule applies a doubled complexity (2 × words²) instead of the old simpler formula, reflecting the real cost of large-number arithmetic. Together, these changes ensure that small ModExp operations pay a fair minimum fee and large, heavy operations scale their cost properly with size. EIP-2565 minimum gas cost three times higher exponents larger than 32 bytes 8 × (40 − 32) = 64 EIP-7883 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 2 × words², 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² The motivation behind these pricing increases comes from benchmarks showing many situations where the ModExp precompile was significantly underpriced. The revised formula raises small operations by 150%, typical operations by around 200%, and very large or unbalanced operations by much larger factors—sometimes more than 80×—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 backward-incompatible, but gas repricing has happened many times before in Ethereum and is well-understood. 150% 200% 80× backward-incompatible Test results show how significant the increases can be. About 99.69% of historical ModExp calls will now cost either 500 gas (up from 200) or three times their earlier price. But certain heavy test cases see huge increases. For example, in one “exp-heavy” test, the cost jumps from 215 gas to 16,624 gas—about 76× more—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. Test 99.69% of historical ModExp calls 76× more In terms of security, this proposal does not create new attack vectors or make any operation cheaper. Instead, it focuses on preventing an important risk: underpriced ModExp operations could make it possible for attackers to fill blocks with extremely heavy computations for very low cost. The only possible downside is that some ModExp operations might now become overpriced, but this is considered a far better outcome than the current underpricing problem. No interface changes or new functionality are introduced, so existing arithmetic behavior and test vectors remain valid. 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% 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% Test Case EIP-2565 Pricing EIP-7883 Pricing Increase Test Case Test Case EIP-2565 Pricing EIP-2565 Pricing EIP-7883 Pricing EIP-7883 Pricing Increase Increase modexp_nagydani_1_square 200 500 150% modexp_nagydani_1_square modexp_nagydani_1_square 200 200 500 500 150% 150% modexp_nagydani_1_qube 200 500 150% modexp_nagydani_1_qube modexp_nagydani_1_qube 200 200 500 500 150% 150% modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_1_pow0x10001 modexp_nagydani_1_pow0x10001 341 341 2048 2048 501% 501% modexp_nagydani_2_square 200 512 156% modexp_nagydani_2_square modexp_nagydani_2_square 200 200 512 512 156% 156% modexp_nagydani_2_qube 200 512 156% modexp_nagydani_2_qube modexp_nagydani_2_qube 200 200 512 512 156% 156% modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_2_pow0x10001 modexp_nagydani_2_pow0x10001 1365 1365 8192 8192 501% 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_square modexp_nagydani_3_square 341 341 2048 2048 501% 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_qube modexp_nagydani_3_qube 341 341 2048 2048 501% 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_3_pow0x10001 modexp_nagydani_3_pow0x10001 5461 5461 32768 32768 500% 500% modexp_nagydani_4_square 1365 8192 501% modexp_nagydani_4_square modexp_nagydani_4_square 1365 1365 8192 8192 501% 501% modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_qube modexp_nagydani_4_qube 1365 1365 8192 8192 501% 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_4_pow0x10001 modexp_nagydani_4_pow0x10001 21845 21845 131072 131072 500% 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_square modexp_nagydani_5_square 5461 5461 32768 32768 500% 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_qube modexp_nagydani_5_qube 5461 5461 32768 32768 500% 500% modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_nagydani_5_pow0x10001 modexp_nagydani_5_pow0x10001 87381 87381 524288 524288 500% 500% modexp_marius_1_even 2057 45296 2102% modexp_marius_1_even modexp_marius_1_even 2057 2057 45296 45296 2102% 2102% modexp_guido_1_even 2298 51136 2125% modexp_guido_1_even modexp_guido_1_even 2298 2298 51136 51136 2125% 2125% modexp_guido_2_even 2300 51152 2124% modexp_guido_2_even modexp_guido_2_even 2300 2300 51152 51152 2124% 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_3_even modexp_guido_3_even 5400 5400 32400 32400 500% 500% modexp_guido_4_even 1026 94448 9105% modexp_guido_4_even modexp_guido_4_even 1026 1026 94448 94448 9105% 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_base_heavy modexp_marcin_1_base_heavy 200 200 1152 1152 476% 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_exp_heavy modexp_marcin_1_exp_heavy 215 215 16624 16624 7632% 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_1_balanced modexp_marcin_1_balanced 200 200 1200 1200 500% 500% modexp_marcin_2_base_heavy 867 5202 500% modexp_marcin_2_base_heavy modexp_marcin_2_base_heavy 867 867 5202 5202 500% 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_exp_heavy modexp_marcin_2_exp_heavy 852 852 16368 16368 1821% 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_2_balanced modexp_marcin_2_balanced 996 996 5978 5978 500% 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_base_heavy modexp_marcin_3_base_heavy 677 677 2032 2032 200% 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3_exp_heavy modexp_marcin_3_exp_heavy 765 765 4080 4080 433% 433% modexp_marcin_3_balanced 1360 4080 200% modexp_marcin_3_balanced modexp_marcin_3_balanced 1360 1360 4080 4080 200% 200% EIP-7917: Determine proposer lookahead EIP-7917: Determine proposer lookahead 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 N+1 is known during epoch N, the actual proposer list could still change due to effective balance (EB) updates happening inside epoch N. 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 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 proposer_lookahead 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 start of epoch 5, Ethereum pre-calculates all proposers for epoch 5, 6, and 7 and stores them in order inside proposer_lookahead. Now, even if balances change later in epoch 5, the proposer list for epoch 6 stays fixed and predictable. start 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. The authors considered alternatives, such as caching the effective balances at the start of an epoch, but that would require extra storage and would not expose the schedule to the EVM. They also checked compatibility with future features like Single Secret Leader Election (SSLE). The current design remains compatible because the lookahead could one day store encrypted proposer IDs, or possibly be disabled entirely if SSLE removes lookahead, without breaking anything. 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. This EIP does not change how the RANDAO delay works. The proposer lookahead for epoch N is still derived from the RANDAO of epoch N − MIN_SEED_LOOKAHEAD − 1. 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 EIP-7918: Blob base fee bounded by execution cost EIP-7918: Blob base fee bounded by execution cost EIP-7918 Ethereum needs this proposal because the current blob fee system (from EIP-4844) 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. 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. EIP-7918 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 BLOB_BASE_COST). In the EIP, this constant is set to 2¹³. The mechanism works through a small change inside the calc_excess_blob_gas() 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 × base_fee_per_gas ÷ GAS_PER_BLOB. BLOB_BASE_COST 2¹³ calc_excess_blob_gas() BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB To understand why this is needed, it helps to look at blob demand. A rollup cares about the total price it pays: execution cost plus blob cost. If execution gas fee is very high—for example, 20 gwei—then even if the blob fee drops from 2 gwei to 0.2 gwei, the total cost barely changes. This means reducing the blob base fee has almost no impact on demand. In economics, this is called “fee inelasticity.” 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 Another reason for adding this reserve price is that nodes have to do a lot of extra work to verify the KZG proofs for blob data. These proofs are what guarantee that the data inside a blob actually matches its commitment. Under EIP-4844, a node only had to verify one proof per blob, which was cheap. But with EIP-7594 (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 EIP-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 (BLOB_BASE_COST = 2¹³) 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 November 2024 and March 2025. During high-execution-fee periods (around 16 gwei average), the reserve threshold significantly increased the blob base fee compared to the old mechanism. During low-execution-fee periods (around 1.3 gwei average), 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 Figure 3 shows how the blob base fee changes using both the current fee market and the proposed reserve fee. The data comes from three weeks in November 2024, when the average execution base fee was around 16 gwei. Under EIP-7918, the blob base fee is always set to the higher value from these two curves, which is shown in the darker line. The threshold is applied directly to the original data, without adjusting for how it might affect the long-term fee levels. Figure 4 shows how the blob base fee changes over time using both the current fee market and the proposed reserve fee. The data is taken from three weeks in March 2025, when the average execution base fee was about 1.3 gwei. Under EIP-7918, the blob base fee is always set to whichever of the two values is higher, shown by the darker line. The threshold is applied directly to the original data, without adjusting for how it might influence the long-term fee levels. In terms of security, the change does not introduce any risks. The blob base fee will always settle at or above the cost of BLOB_BASE_COST 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 EIP-7934: RLP Execution Block Size Limit EIP-7934: RLP Execution Block Size Limit EIP-7934 Before EIP-7934, Ethereum did not 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: network instability and DoS attack risks. 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 10 MB, 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 protocol-level cap on the size of an RLP-encoded execution block. The maximum allowed block size (MAX_BLOCK_SIZE) is set to 10 MiB (10,485,760 bytes), but because beacon blocks also consume some space (SAFETY_MARGIN), Ethereum adds a 2 MiB (2,097,152 bytes). This means the actual maximum RLP-encoded execution block size allowed is MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN. If the encoded block is larger than this limit, the block is considered invalid 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 independently of gas limits -meaning even if a block is “under the gas limit,” 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 10 MiB cap 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 not backward-compatible 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 EIP-7939: Count leading zeros (CLZ) opcode EIP-7939: Count leading zeros (CLZ) opcode EIP-7939 Before this EIP, Ethereum had no built-in opcode 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 slow, expensive, and used a lot of bytecode, 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 solves this by introducing a new opcode called CLZ (0x1e). 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 256, because a 256-bit zero has 256 leading zero bits. This matches how CLZ works in many CPU architectures like ARM and x86, where this operation is native. Adding CLZ makes many algorithms significantly cheaper: operations like lnWad, powWad, LambertW, 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 The gas cost for CLZ is set to 5, similar to an ADD, 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 cheaper to prove than ADD, reducing ZK proving costs. The EIP also explains why they chose CLZ instead of CTZ (count trailing zeros): you can compute CTZ from CLZ using x & -x, but you cannot 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 new 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 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. EIP-7951: Precompile for secp256r1 Curve Support EIP-7951: Precompile for secp256r1 Curve Support EIP-7951 Before this EIP, Ethereum did not have a safe, native way to verify digital signatures created using the secp256r1 (P-256) curve. This curve is the standard used in modern devices like Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn security keys. 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 two serious security vulnerabilities related to point-at-infinity handling and incorrect signature comparison. These issues could cause incorrect verification or even risk consensus failures. EIP-7951 fixes those security problems and introduces a safe, native precompile so Ethereum can finally support signatures from modern hardware securely and efficiently. 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 precompiled contract at address 0x100 called P256VERIFY, which performs ECDSA signature verification using the secp256r1 curve. This makes signature verification fast and cheap compared to implementing the algorithm directly in Solidity. The precompile uses the official curve parameters defined by NIST, including the field modulus, curve equation, base point, and subgroup order, ensuring strong cryptographic security. Points and scalars are encoded in strict 32-byte big-endian format, and a 64-byte all-zero value is used to represent the point at infinity. The precompile expects exactly 160 bytes of input—the hash, signature (r, s), and public key coordinates (qx, qy)—and it returns 32 bytes of 1 for success or empty output for failure. precompiled contract 0x100 P256VERIFY 160 bytes of input 32 bytes of 1 empty output The EIP also defines strict input validation rules. 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 RIP-7212, 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 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 These parameters are standardized by NIST in SP 800-1861. The gas cost for the operation is set to 6900 gas, 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 RIP-7212 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) 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 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)) 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, EIP-7951 is needed to safely bring modern hardware-backed authentication to Ethereum, 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 Consensus Client indicates that the EIP requires updates to consensus-layer clients, while a check mark under Execution Client 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 ✅ 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 ✅ EIP Number EIP Name Consensus Client Execution Client EIP Number EIP Number EIP Name EIP Name Consensus Client Consensus Client Execution Client Execution Client EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7594 EIP-7594 PeerDAS - Peer Data Availability Sampling PeerDAS - Peer Data Availability Sampling ✅ ✅ ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7823 EIP-7823 Set upper bounds for MODEXP Set upper bounds for MODEXP ✅ ✅ EIP-7825 Transaction Gas Limit Cap ✅ EIP-7825 EIP-7825 Transaction Gas Limit Cap Transaction Gas Limit Cap ✅ ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7883 EIP-7883 ModExp Gas Cost Increase ModExp Gas Cost Increase ✅ ✅ EIP-7917 Deterministic proposer lookahead ✅ EIP-7917 EIP-7917 Deterministic proposer lookahead Deterministic proposer lookahead ✅ ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7918 EIP-7918 Blob base fee bounded by execution cost Blob base fee bounded by execution cost ✅ ✅ EIP-7934 RLP Execution Block Size Limit ✅ EIP-7934 EIP-7934 RLP Execution Block Size Limit RLP Execution Block Size Limit ✅ ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7939 EIP-7939 Count leading zeros (CLZ) opcode Count leading zeros (CLZ) opcode ✅ ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ EIP-7951 EIP-7951 Precompile for secp256r1 Curve Support Precompile for secp256r1 Curve Support ✅ ✅ 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 major change of this upgrade is PeerDAS, 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
