In 3 days, Ethereum will welcome these significant changes

The original text is from Sahil Sojitra

Compiled by ｜Odaily Planet Daily Golem

The Fusaka hard fork, scheduled to activate on December 3, 2025, is another major network upgrade for Ethereum following Pectra, marking an important step forward for the crypto giant in terms of scalability.

The EIPs of the Pectra upgrade focused on enhancing performance, security, and developer tools. The EIPs of the Fusaka upgrade emphasize scalability, opcode updates, and execution security.

PeerDAS (EIP-7594) improves data availability by allowing nodes to verify blobs without downloading all the data. Multiple upgrades also enhance execution security, including limiting ModExp (EIP-7823), restricting transaction gas limits (EIP-7825), and updating ModExp gas costs (EIP-7883). The Fusaka upgrade also improves block generation through a deterministic proposer foresight mechanism (EIP-7917) and stabilizes blob fees by setting a "reserve price" linked to execution costs (EIP-7918).

Other enhancements include limiting the block size in RLP format (EIP-7934), adding a new CLZ opcode to speed up bit operations (EIP-7939), and introducing secp256r1 precompilation (EIP-7951) for better compatibility with modern cryptography and hardware security keys.

Fusaka is a combination of Fulu (execution layer) and Osaka (consensus layer). It represents another step for Ethereum towards a highly scalable and data-rich future, where Layer 2 Rollups can operate at lower costs and faster speeds.

This article will delve into the nine core EIP proposals of the Fusaka hard fork.

EIP-7594: PeerDAS ------ Node Data Availability Sampling

Ethereum needs this proposal because the network aims to provide higher data availability for users, especially Rollup users.

However, under the current EIP-4844 design, each node still needs to download a large amount of blob data to verify its publication. This creates scalability issues, as requiring all nodes to download all data increases the network's bandwidth and hardware requirements, affecting decentralization. To address this, Ethereum needs a method that allows nodes to confirm data availability without downloading all data.

Data availability sampling (DAS) solves this problem by allowing nodes to check only a small amount of random data.

But Ethereum also needs a DAS method compatible with the existing Gossip network that does not impose a heavy computational burden on block producers. The creation of PeerDAS is precisely to meet these needs, safely increasing blob throughput while keeping node requirements low.

PeerDAS is a network system that allows nodes to download only a small number of data fragments to verify whether the complete data has been published. Nodes do not need to download all data but instead use the regular gossip network to share data, discovering which nodes hold specific parts of the data and only requesting the necessary small samples. The core idea is that by downloading only a small random portion of the data fragment, nodes can still be confident of the existence of the entire data fragment. For example, a node might only download about 1/8 of the data instead of the complete 256 KB data fragment—however, since many nodes sample different parts, any missing data will be quickly discovered.

To achieve sampling, PeerDAS uses a basic erasure coding to expand each data fragment in EIP-4844. Erasure coding is a technique that adds extra redundant data, allowing the original data to be recovered even if some data fragments are missing—similar to how a puzzle can still be completed even if a few pieces are lost.

The blob becomes a "row" that contains the original data along with some additional encoded data for later reconstruction. This row is then split into many small pieces called "cells," which are the minimum verification units associated with KZG commitments. All "rows" are then reorganized into "columns," with each column containing cells from the same position in all rows. Each column is assigned to a specific gossip subnet.

Nodes are responsible for storing certain columns based on their node ID and sampling some columns from peer nodes at each time slot. If a node collects at least 50% of the columns, it can fully reconstruct the data. If fewer than 50% of the columns are collected, it must request the missing columns from peer nodes. This ensures that if the data has indeed been published, it can always be reconstructed. In short, if there are a total of 64 columns, a node only needs about 32 columns to reconstruct the complete blob. It retains some columns itself and downloads others from peer nodes. As long as half of the columns exist in the network, the node can reconstruct everything, even if some columns are missing.

Additionally, EIP-7594 introduces an important rule: no transaction can contain more than 6 blobs. This restriction must be enforced during transaction validation, gossip propagation, block creation, and block processing. This helps reduce extreme cases where a single transaction could overload the blob system.

PeerDAS adds a feature called "cell KZG proof." A cell KZG proof indicates that the KZG commitment indeed matches a specific cell (a small unit) in the blob. This allows nodes to download only the cell they want to sample. It is crucial for data availability sampling to obtain the complete blob while ensuring data integrity.

However, generating all these cell proofs is costly. Block producers need to repeatedly compute these proofs for many blobs, which slows down the process. However, the cost of proof verification is very low, so EIP-7594 requires blob transaction senders to pre-generate all cell proofs and include them in the transaction wrapper.

As a result, transaction gossip (PooledTransactions) now uses a modified wrapper:

rlp([txpayloadbody, wrapperversion, blobs, commitments, cellproofs])

In the new wrapper, cellproofs is simply a list containing all proofs for each cell of each blob (e.g., [cellproof0, cellproof1, …]). Other fields txpayloadbody, blobs, and commitments are exactly the same as in EIP-4844. The difference is that the original single "proofs" field has been removed and replaced with the new cellproofs list, while a new field named wrapper_version has been added to indicate the current wrapper format in use.

PeerDAS enables Ethereum to improve data availability without increasing node workload. Nowadays, a node only needs to sample about 1/8 of the total data. In the future, this ratio could even drop to 1/16 or 1/32, thereby enhancing Ethereum's scalability. The system works well because each node has numerous peer nodes, so if a peer node cannot provide the required data, the node can request it from other peer nodes. This naturally establishes a redundancy mechanism and enhances security, and nodes can also choose to store data beyond their actual needs, further strengthening the network's security.

Validator nodes bear more responsibility than regular full nodes. Since validator nodes themselves run more powerful hardware, PeerDAS allocates corresponding data hosting loads based on the total number of validator nodes. This ensures that there is always a stable group of nodes available to store and share more data, thereby enhancing the reliability of the network. In short, if there are 900,000 validator nodes, each validator node may be assigned a small portion of the total data for storage and service. Because validator nodes have more powerful machines, the network can trust them to ensure data availability.

PeerDAS uses column sampling instead of row sampling because this greatly simplifies data reconstruction. If nodes sample entire rows (the entire blob), they would need to create additional "extended blobs" that do not originally exist, which would slow down block producers.

With column sampling, nodes can prepare additional row data in advance, and the transaction sender (rather than the block producer) computes the necessary proofs. This can maintain the speed and efficiency of block creation. For example, suppose a blob is a 4×4 grid of cells. Row sampling means taking all 4 cells from one row, but some extended rows may not be ready, so the block producer must generate them on the spot; column sampling means taking one cell from each row (each column), and the required additional cells can be prepared in advance, allowing nodes to verify data without slowing down block generation.

EIP-7594 is fully compatible with EIP-4844, so it does not break any existing functionality on Ethereum. All tests and detailed rules are included in the consensus and execution specifications.

The main security risk of any DAS system is the "data withholding attack," where block producers pretend data is available while actually hiding some data. PeerDAS prevents this by using random sampling: nodes check random parts of the data. The more nodes that sample, the harder it is for an attacker to cheat. EIP-7594 even provides a formula to calculate the likelihood of such an attack's success based on the total number of nodes (n), the total number of samples (m), and the number of samples per node (k). With about 10,000 nodes on the Ethereum mainnet, the probability of a successful attack is extremely low, making PeerDAS considered secure.

EIP-7823: Set 1024 Byte Limit for MODEXP

The necessity of this proposal lies in the fact that Ethereum's current MODEXP precompilation mechanism has led to numerous consensus vulnerabilities over the years. Most of these vulnerabilities stem from MODEXP allowing an impractically large amount of input data, forcing clients to handle countless edge cases.

Since each node must handle all inputs provided by transactions, the lack of an upper limit makes MODEXP harder to test, more prone to errors, and more likely to behave differently across different clients. Excessive input data also makes the gas cost formula difficult to predict, as it is challenging to price when the data can grow indefinitely. These issues also complicate future efforts to replace MODEXP with EVM-level code using tools like EVMMAX, as developers cannot create secure and optimized execution paths without fixed limits.

To mitigate these issues and enhance Ethereum's stability, EIP-7823 introduces strict limits on the amount of input data for MODEXP, making the precompilation process safer, easier to test, and more predictable.

EIP-7823 introduces a simple rule: all three length fields (base, exponent, and modulus) used by MODEXP must be less than or equal to 8192 bits, or 1024 bytes. MODEXP inputs follow the format defined in EIP-198: \<len(BASE)> \<len(EXPONENT)> \<len(MODULUS)> \<BASE> \<EXPONENT> \<MODULUS>, so this EIP only restricts the length values. If any length exceeds 1024 bytes, the precompilation will immediately stop, return an error, and consume all gas.

For example, if someone attempts to provide a base that is 2000 bytes long, the call will fail before any work begins. These limits still accommodate all practical application scenarios. RSA verification typically uses key lengths of 1024, 2048, or 4096 bits, all of which fall within the new limit. Elliptic curve operations use smaller input sizes, usually less than 384 bits, so they are also unaffected.

These new limits also facilitate future upgrades. If MODEXP is rewritten as EVM code using EVMMAX in the future, developers can add optimized paths for common input sizes (e.g., 256 bits, 381 bits, or 2048 bits) and use slower fallback options for rare cases. By fixing the maximum input size, developers can even add special handling for very common moduli. Previously, the unrestricted input size created an overly large design space that was difficult to manage securely, making these implementations impossible.

To confirm that this change does 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 showed that historically, all successful MODEXP calls did not use inputs exceeding 513 bytes, far below the new 1024-byte limit. Most practical calls used smaller lengths, such as 32 bytes, 128 bytes, or 256 bytes.

There were some invalid or corrupted calls, such as empty inputs, inputs filled with repeated bytes, and one very large but invalid input. The behavior of these calls under the new limits would also be invalid, as they are inherently invalid. Therefore, while EIP-7823 is technically a significant change, it does not actually alter the outcomes of any past transactions.

From a security perspective, reducing the allowed input size does not introduce new risks. On the contrary, it eliminates unnecessary extreme cases that previously led to errors and inconsistencies between clients. By limiting MODEXP inputs to reasonable sizes, EIP-7823 makes the system more predictable, reduces odd edge cases, and lowers the probability of errors between different implementations. These limits also help prepare for future upgrades (such as EVMMAX) that introduce optimized execution paths, allowing for a smoother transition.

EIP-7825: Transaction Gas Limit of 16,777,216

Ethereum indeed needs this proposal because currently, a single transaction can almost consume the entire block's gas limit.

This creates several problems: a transaction may consume most of the block's resources, leading to slow delays similar to DoS attacks; operations that consume a large amount of gas can rapidly increase Ethereum's state updates; and block verification speeds slow down, making it difficult for nodes to keep up.

If a user submits a massive transaction that consumes nearly all gas (e.g., a transaction that consumes 38 million gas in a block with a gas limit of 40 million), then other ordinary transactions cannot fit into that block, and each node must spend extra time verifying that block. This threatens the network's stability and decentralization, as slower verification speeds mean that less powerful nodes will fall behind. To address this issue, Ethereum needs a secure gas limit that restricts the amount of gas a single transaction can use, making block loads more predictable, reducing the risk of DoS attacks, and balancing the load on nodes.

EIP-7825 introduces a hard rule: any transaction consuming gas must not exceed 16,777,216 (2²⁴). This becomes a protocol-level limit, meaning it applies to all stages: user sending transactions, transaction pool checking transactions, and validators packing transactions into blocks. If someone sends a transaction with a gas limit exceeding this value, the client must immediately reject the transaction and return an error like MAXGASLIMIT_EXCEEDED.

This limit is entirely independent of the block gas limit. For example, even if the block gas limit is 40 million, any single transaction's gas consumption must not exceed 16,777,216. The goal is to ensure that each block can accommodate multiple transactions rather than allowing a single transaction to monopolize the entire block.

To better understand this, suppose a block can accommodate 40 million gas. Without this limit, someone might send a transaction consuming between 35 million and 40 million gas. This transaction would monopolize the block, leaving no room for other transactions, just like a person renting an entire bus, preventing others from boarding. The new 16,777,216 gas limit will naturally allow multiple transactions in a block, thus avoiding such abuse.

The proposal also specifies how clients should validate transactions. If a transaction's gas exceeds 16,777,216, the transaction pool must reject it, meaning such transactions will not even enter the queue. During block validation, if a block contains transactions exceeding the limit, that block itself must be rejected.

The choice of 16,777,216 (2²⁴) is because it is a clear power of two boundary, making it easy to implement, and it is still large enough to handle most practical transactions. For example, smart contract deployments, complex DeFi interactions, or multi-step contract calls. This value is about half of the typical block size, meaning even the most complex transactions can easily be kept within this limit.

This EIP also maintains compatibility with the existing gas mechanism. Most users will not notice this change, as nearly all existing transactions consume far less than 16 million gas. Validators and block creators can still create blocks with total gas exceeding 16,777,216, as long as each transaction adheres to the new limit.

The only transactions affected are those that previously attempted to use oversized transactions exceeding the new limit. These transactions must now be split into multiple smaller operations, similar to splitting a very large file upload into two smaller files. Technically, this change is not backward compatible for these rare extreme transactions, but the number of affected users is expected to be very small.

In terms of security, the gas limit makes Ethereum more resilient against gas-based DoS attacks, as attackers can no longer force validators to process oversized transactions. It also helps maintain predictable block verification times, making it easier for nodes to stay in sync. The main extreme case is that a few very large contract deployments may not meet the limit requirements and will need to be redesigned or split into multiple deployment steps.

Overall, EIP-7825 aims to strengthen the network's defenses against abuse, keep node demands reasonable, improve fairness in block space usage, and ensure that as gas limits increase, the blockchain can still operate quickly and stably.

EIP-7883: Increase ModExp Gas Costs

Ethereum needs this proposal because the price of ModExp precompilation (for modular exponentiation) has been too low compared to the actual resources consumed.

In some cases, the computational effort required for ModExp operations far exceeds the fees currently paid by users. This mismatch poses risks: if complex ModExp calls are priced too low, they could become bottlenecks, making it difficult for the network to safely increase gas limits. Block producers might be forced to handle extremely heavy operations at very low costs.

To address this issue, Ethereum needs to adjust the pricing formula for ModExp so that gas consumption accurately reflects the actual workload completed by clients. Therefore, EIP-7883 introduces new rules that raise the minimum gas cost, increase the total gas cost, and make operations with larger input data (especially those with exponents, bases, or moduli exceeding 32 bytes) more expensive, aligning gas pricing with the actual computational effort required.

The proposal raises costs in several important ways, modifying the original ModExp pricing algorithm defined in EIP-2565.

First, the minimum gas consumption increases from 200 to 500, and the total gas consumption is no longer divided by 3, meaning the total gas consumption effectively triples. For example, if a previous ModExp call required 1200 gas, under the new formula, it will now require approximately 3600 gas.

Second, the cost of operations with exponents greater than 32 bytes doubles, as the multiplier increases from 8 to 16. For instance, if the exponent length is 40 bytes, EIP-2565 would increase the number of iterations by 8 × (40 − 32) = 64 times, while EIP-7883 now uses 16 × (40 − 32) = 128 times, effectively doubling the cost.

Third, pricing now assumes a minimum base/modulus size of 32 bytes, and when these values exceed 32 bytes, the computational cost increases dramatically. For example, if the modulus is 64 bytes, the new rules apply double complexity (2 × words²) instead of the previously simpler formula, reflecting the actual costs of large number operations. These changes collectively ensure that small ModExp operations pay reasonable minimum fees, while the costs of large, complex operations are appropriately adjusted based on their size.

The proposal defines a new gas calculation function, updating complexity and iteration rules. Multiplication complexity now uses a default value of 16 for base/modulus lengths not exceeding 32 bytes, while for larger inputs, it switches to a more complex formula of 2 × words², where "words" refers to the number of 8-byte blocks. The number of iterations has also been updated so that exponents of 32 bytes or smaller use their bit length to determine complexity, while exponents larger than 32 bytes incur a greater gas penalty.

This ensures that extremely large exponents with high actual computational costs now have higher gas costs. Importantly, the minimum gas cost returned is enforced at 500, rather than the previous 200, making even the simplest ModExp calls more reasonable.

The motivation for these price increases stems from benchmarking, which indicates that in many cases, the pricing of ModExp precompilation is significantly too low. The revised formula raises gas costs for small operations by 150%, typical operations by about 200%, and gas costs for large or unbalanced operations by even more, sometimes exceeding 80 times, depending on the size of the exponent, base, or modulus.

The goal of this move is not to change how ModExp works but to ensure that it no longer threatens network stability or hinders future increases in block gas limits, even in extreme cases of resource consumption. Since EIP-7883 changes the amount of gas required for ModExp, it is not backward compatible, but gas repricing has occurred multiple times in Ethereum and is well understood.

Testing results indicate that the increase in gas costs is very significant. About 99.69% of historical ModExp calls now either require 500 gas (up from 200 gas) or three times the previous price. However, the gas cost increase for certain high-load test cases is even greater. For example, in a "exponentiation-intensive" test, gas consumption surged from 215 to 16,624, an increase of about 76 times, as the pricing for extremely large exponents is now more reasonable.

In terms of security, this proposal does not introduce new attack vectors or reduce the cost of any operations. On the contrary, it focuses on preventing a significant risk: low-priced ModExp operations could allow attackers to fill blocks with extremely heavy computations at very low costs. The only potential downside is that the price of certain ModExp operations may become too high, but this is far preferable to the current issue of pricing being too low. The proposal does not introduce any interface changes or new features, so existing arithmetic behavior and test vectors remain valid.

EIP-7917: Accurately Predict the Next Proposer

Ethereum needs this proposal because the scheduling of the next proposer for the network's upcoming epoch cannot be fully predicted. Even when the RANDAO seed for epoch N is known, the actual proposer list for epoch N+1 may still change due to updates in effective balances (EB) during epoch N.

These EB changes may arise from penalties, rewards exceeding 1 ETH, validator merges, or new deposits, especially after EIP-7251 raised the maximum effective balance above 32 ETH. This uncertainty poses challenges for systems that rely on knowing the next proposer in advance (such as pre-confirmation-based protocols), which require stable and predictable schedules to operate smoothly. Validators may even attempt to "game" or manipulate their effective balances to influence the proposer for the next epoch.

Due to these issues, Ethereum needs a method to make the proposer schedule fully deterministic for the next several epochs, so it does not change due to last-minute EB updates and is easily accessible to the application layer.

To achieve this, EIP-7917 introduces a deterministic proposer foresight mechanism that precomputes and stores the proposer schedule for the next MINSEEDLOOKAHEAD + 1 epochs at the start of each epoch. In simple terms, the beacon state now contains a list called prosoperer_lookahead, which always covers the proposers for two full cycles (a total of 64 slots).

For example, when epoch N begins, this list already contains the proposer for each slot in both epoch N and epoch N+1. Then, when the network enters epoch N+1, the list moves forward: it removes the proposer entries for epoch N, moves the entries for epoch N+1 to the front of the list, and adds new proposer entries for epoch N+2 at the end of the list. This makes the scheduling fixed and predictable, allowing clients to read it directly without recalculating the proposer for each slot.

To keep it updated, the list moves forward at each epoch boundary: it removes data from the previous epoch and computes a new set of proposer indices for the next future epoch to add to the list. This process uses the same seed and effective balance rules as before, but now the scheduling calculations are done earlier, avoiding the impact of effective balance changes after the seed is determined. The first block after the fork will also fill the entire foresight range to ensure that all future epochs have correctly initialized schedules.

Assuming each epoch has 8 slots instead of 32 (for simplicity). Without this EIP, during the 5th epoch, although you know the seed for the 6th epoch, if a validator is penalized or receives enough rewards to change their effective balance during the 5th epoch, the actual proposer for slot 2 of the 6th epoch may still change. With EIP-7917, Ethereum will precompute all proposers for epochs 5, 6, and 7 at the start of epoch 5 and store them in order in prosopers_lookahead. Thus, even if balances change later in the 5th epoch, the proposer list for the 6th epoch remains fixed and predictable.

EIP-7917 fixes a long-standing flaw in the beacon chain design. It guarantees that once the RANDAO for the previous epoch is available, the validator selection for future epochs cannot change. This also prevents "effective balance gaming," where validators attempt to adjust their balances after seeing the RANDAO to influence the proposer list for the next epoch. The deterministic foresight mechanism eliminates this entire attack vector, greatly simplifying security analysis. It also allows consensus clients to know in advance who will propose the upcoming block, aiding implementation and allowing the application layer to easily verify the proposer schedule through Merkle proofs of the beacon root.

Before this proposal, clients only computed the proposer for the current slot. With EIP-7917, they now compute the proposer list for all slots in the next epoch in one go during each epoch transition. This adds a small amount of work, but calculating proposer indices is very lightweight, mainly involving sampling the validator list using the seed. However, clients need to benchmark to ensure this additional computation does not lead to performance issues.

EIP-7918: Blob Base Fee Linked to Execution Costs

Ethereum needs this proposal because the current blob fee system (originating from EIP-4844) fails when execution gas becomes the primary cost for Rollups.

Currently, the execution gas paid by most Rollups (the cost of including blob transactions in blocks) is far higher than the actual blob fees. This creates a problem: even if Ethereum continuously lowers the base blob fee, the total cost for Rollups does not actually change, as the most expensive part remains the execution gas. Therefore, the base blob fee will continue to decrease until it reaches an absolute minimum (1 wei), at which point the protocol can no longer use blob fees to control demand. Then, when blob usage suddenly increases, blob fees need many blocks to return to normal levels. This makes prices unstable and difficult for users to predict.

For example, suppose a Rollup wants to publish its data: it needs to pay about 25,000,000 gwei in execution gas (about 1,000,000 gas requires 25 gwei), while the blob fee is only about 200 gwei. This means the total cost is approximately 25,000,200 gwei, with almost all of the cost coming from execution gas rather than blob fees. If Ethereum continues to lower blob fees, for instance, from 200 gwei to 50 gwei, then to 10 gwei, and finally to 1 gwei, the total cost will hardly change, remaining around 25,000,000 gwei.

EIP-7918 addresses this issue by introducing a minimum "reserve price" based on execution base fees, preventing blob prices from falling too low and making Rollup blob pricing more stable and predictable.

The core idea of EIP-7918 is simple: the price of a blob should never be lower than a certain amount of execution gas cost (referred to as BLOBBASECOST). The value of calcexcessblobgas() is set to 2¹³, and this mechanism is achieved by making minor modifications to the calcexcessblobgas() function.

Typically, this function increases or decreases the base blob fee based on whether the blob gas used in the block is above or below the target value. According to this proposal, if the blob becomes "too low" relative to execution gas, the function will stop deducting the target blob gas. This allows excess blob gas to grow faster, preventing the base blob fee from declining further. Therefore, the base blob fee now has a minimum value equal to BLOBBASECOST × basefeepergas ÷ GASPER_BLOB.

To understand why this is necessary, we can look at the demand for blobs. Rollups are concerned with their total costs: execution costs plus blob costs. If execution gas fees are very high, for example, 20 gwei, then even if blob fees drop from 2 gwei to 0.2 gwei, the total cost remains almost unchanged. This means that lowering the base blob fee has little impact on demand. In economics, this is referred to as "price inelasticity." It creates a situation where the demand curve is almost vertical: lowering prices does not increase demand.

In this case, the base blob fee mechanism becomes blind—continuing to lower prices even when demand does not respond. This is why the base blob fee often drops to 1 gwei. Then, when actual demand increases later, the protocol requires nearly full blocks for an hour or longer to raise fees to reasonable levels. EIP-7918 resolves this issue by establishing a reserve price linked to execution gas, ensuring that blob fees remain meaningful even when execution costs dominate.

Another reason for adding this reserve price is that nodes need to do a lot of extra work to verify the KZG proofs of blob data. These proofs ensure that the data in the blob corresponds to its commitment. Under EIP-4844, nodes only needed to verify one proof for each blob, which was low-cost. However, under EIP-7918, the number of proofs that nodes need to verify increases significantly. This is entirely due to the fact that in EIP-7594 (PeerDAS), blobs are split into many small pieces called cells, each with its own proof, greatly increasing the verification workload.

In the long run, EIP-7918 also helps Ethereum prepare for the future. As technology advances, the costs of storing and sharing data will naturally decrease, and Ethereum is expected to allow for more blob data storage over time. As blob capacity increases, blob fees (in ETH) will naturally decline. This proposal supports this because the reserve price is linked to execution gas prices rather than a fixed value, allowing it to adjust according to the growth of the network.

As blob space and execution block space expand, their price relationship will remain balanced. Only in very rare cases, when Ethereum significantly increases blob capacity without increasing execution gas capacity, might the reserve price become too high. In such cases, blob fees may ultimately exceed what is actually needed. However, Ethereum does not plan to scale in this way—blob space and execution block space are expected to grow in sync. Therefore, the chosen value (BLOBBASECOST = 2¹³) is considered safe and balanced.

When execution gas fees suddenly spike, it is important to understand a small detail. Since the price of blobs is tied to execution base fees, a sudden rise in execution costs may temporarily push blob fees into a state dominated by execution costs. For example, suppose execution gas fees suddenly jump from 20 gwei to 60 gwei within a block. Since the price of blobs is linked to this value, blob fees cannot drop below the new higher level. If blobs are still being used, their fees will continue to grow normally, but the protocol will not allow them to decrease until they grow enough to match the higher execution costs. This means that for several blocks, the growth rate of blob fees may lag behind execution costs. This temporary delay is harmless—it actually helps prevent extreme fluctuations in blob prices and makes the system smoother.

The author also conducted an empirical analysis of actual block transaction activity from November 2024 to March 2025, applying the reserve price rules. During periods of high execution fees (averaging around 16 gwei), the reserve threshold significantly raised block base fees compared to the old mechanism. During periods of low execution fees (averaging around 1.3 gwei), block fees remained almost unchanged unless the calculated block base fee fell below the reserve price. By comparing thousands of blocks, the author demonstrates that the new mechanism creates more stable pricing while still responding naturally to demand. A histogram of block fees over four months shows that the reserve price prevents block fees from plummeting to 1 gwei, thus reducing extreme volatility.

In terms of security, this change does not introduce any risks. The base block fee will always be equal to or greater than the execution gas's BLOBBASECOST unit cost. This is secure because the mechanism only raises the minimum fee, and setting a price floor does not affect the correctness of the protocol. It simply ensures healthy economic operation.

EIP-7934: Limit on RLP Execution Block Size

Before EIP-7934, Ethereum did not have strict upper limits on the size of RLP-encoded execution blocks. Theoretically, if a block contains a large number of transactions or very complex data, its size could become very large. This creates two main problems: network instability and the risk of denial-of-service (DoS) attacks.

If a block is too large, the time required for nodes to download and verify it increases, slowing down block propagation and increasing the likelihood of temporary forks in the blockchain. Worse, attackers could deliberately create a very large block to overload nodes, causing delays or even taking them offline—this is a typical denial-of-service attack. Meanwhile, Ethereum's consensus layer (CL) gossip protocol has already refused to propagate any blocks larger than 10MB, meaning that overly large execution blocks may not propagate through the network, leading to fragmentation on the chain or discrepancies between nodes. Given these risks, Ethereum needs a clear protocol-level rule to prevent blocks from becoming too large and to maintain network stability and security.

EIP-7934 addresses this issue by introducing a protocol-level limit on the size of RLP-encoded execution blocks. The maximum allowed block size (MAXBLOCKSIZE) is set to 10 MiB (10,485,760 bytes), but since beacon blocks also occupy some space (SAFETY_MARGIN), Ethereum adds 2 MiB (2,097,152 bytes) to this.

This means the actual maximum allowed RLP-encoded execution block size is MAXRLPBLOCKSIZE = MAXBLOCKSIZE - SAFETYMARGIN. If the encoded block exceeds this limit, it will be considered invalid, and nodes must reject it. With this rule, block producers must check the encoded size of every block they build, and validators must verify this limit during block validation. This size limit is independent of gas limits, meaning that even if a block is "below the gas limit," it will still be rejected if its encoded size is too large. This ensures compliance with both gas usage and actual byte size limits.

The choice of a 10 MiB limit is intentional, as it aligns with existing limits in the consensus layer gossip protocol. Any data larger than 10 MiB will not be broadcast in the network, so this EIP keeps the execution layer consistent with the consensus layer's limits. This ensures consistency across all components and prevents valid execution blocks from becoming "invisible" due to CL refusing to propagate them.

This change is not backward compatible with blocks larger than the new limit, meaning miners and validators must update their clients to comply with this rule. However, since oversized blocks are problematic in themselves and are not common in actual operation, the impact is minimal.

In terms of security, EIP-7934 significantly enhances Ethereum's ability to resist DoS attacks targeting specific block sizes by ensuring that no participant can create blocks that would cripple the network. In summary, EIP-7934 adds an important security boundary, improves stability, unifies the behavior of execution logic (EL) and CL, and prevents various attacks related to the creation and propagation of oversized blocks.

EIP-7939: Compute Leading Zeros (CLZ) Opcode

Before this EIP, Ethereum did not have a built-in opcode to calculate the number of leading zeros in a 256-bit number. Developers had to manually implement the CLZ function using Solidity, which required a lot of bit-shifting operations and comparisons.

This is a significant issue because custom implementations are slow, costly, and consume a lot of bytecode, increasing gas consumption. For zero-knowledge proof systems, the costs are even higher, as the proof costs for right-shifting operations are extremely high, so operations like CLZ significantly slow down the execution of zero-knowledge proof circuits. Since CLZ is a very common low-level function widely used in mathematical libraries, compression algorithms, bitmaps, signature schemes, and many cryptographic or data processing tasks, Ethereum needs a faster and more economical computation method.

EIP-7939 addresses this issue by introducing a new opcode called CLZ (0x1e). This opcode reads a 256-bit value from the stack and returns the number of leading zeros. If the input number is zero, the opcode returns 256, as a 256-bit zero has 256 leading zeros.

This aligns with how CLZ works in many CPU architectures like ARM and x86, where the CLZ operation is natively supported. Adding CLZ can significantly reduce the overhead of many algorithms: operations such as lnWad, powWad, LambertW, various mathematical functions, byte string comparisons, bitmap scans, and calls to data compression/decompression and post-quantum signature schemes can all benefit from faster leading zero detection.

The gas cost for CLZ is set at 5, similar to ADD, and slightly higher than the previous MUL price to avoid the risk of pricing too low, which could lead to denial-of-service (DoS) attacks. Benchmarking indicates that the computational load of CLZ is roughly equivalent to ADD, and in the SP1 rv32im proof environment, the proof cost for CLZ is actually lower than that for ADD, thereby reducing the costs of zero-knowledge proofs.

EIP-7939 is fully backward compatible, as it introduces a new opcode without modifying any existing behavior.

Overall, EIP-7939 makes Ethereum run faster, cost less, and be more developer-friendly by adding a simple and efficient primitive that modern CPUs already support—reducing gas costs, decreasing bytecode size, and lowering the costs of zero-knowledge proofs for many common operations.

EIP-7951: Support for Modern Hardware Signatures

Before this EIP, Ethereum lacked a secure, native way to verify digital signatures created using the secp256r1 (P-256) curve.

This curve is the standard used by modern devices such as Apple Secure Enclave, Android Keystore, HSM, TEE, and FIDO2/WebAuthn security keys. The absence of such support made it difficult for applications and wallets to easily use device-level hardware security for signing. There was a previous attempt (RIP-7212), but it had two serious security vulnerabilities related to handling of the point at infinity and incorrect signature comparisons. These issues could lead to verification errors and potentially consensus failures. EIP-7951 fixes these security issues and introduces a secure, native precompilation that allows Ethereum to safely and efficiently support signatures from modern hardware.

EIP-7951 adds a new precompiled contract named P256VERIFY at address 0x100, which performs ECDSA signature verification using the secp256r1 curve. This makes signature verification faster and cheaper compared to directly implementing the algorithm in Solidity.

EIP-7951 also defines strict input validation rules. If any invalid conditions exist, the precompilation will return a failure without rolling back, consuming the same gas as a successful call. The verification algorithm follows standard ECDSA: it computes s⁻¹ mod n, reconstructs the signature point R', rejects it if R' is at infinity, and finally checks whether the x-coordinate of R' matches r (mod n). This corrects the error in RIP-7212, which directly compared r' instead of reducing it modulo n first.

The gas cost for this operation is set at 6900 gas, higher than the RIP-7212 version but consistent with the actual performance benchmarks for secp256r1 verification. Importantly, this interface is fully compatible with Layer 2 networks that have deployed RIP-7212 (same address, same input/output format), so existing smart contracts will continue to function normally without any changes. The only difference is the corrected behavior and the higher gas cost.

From a security perspective, EIP-7951 restores the correct behavior of ECDSA, eliminates the plasticity issues at the precompilation level (leaving optional checks to applications), and clarifies that the precompilation does not require constant-time execution. The secp256r1 curve provides 128-bit security and has been widely trusted and analyzed, making it safe for use in Ethereum.

In summary, EIP-7951 aims to securely bring modern hardware-supported authentication to Ethereum, fixing the security issues of earlier proposals and providing a reliable, standardized way to verify P-256 signatures across the ecosystem.

Summary

The table below summarizes which Ethereum clients need to make changes for different Fusaka EIPs. A checkmark under consensus clients indicates that the EIP requires updates to the consensus layer client, while a checkmark under execution clients indicates that the upgrade affects the execution layer client. Some EIPs require updates to both the consensus and execution layers, while others only require updates to one of the layers.

In summary, these are the key EIPs included in the Fusaka hard fork. While this upgrade involves multiple improvements to both consensus and execution clients, from gas adjustments and opcode updates to new precompilations, the core of this upgrade remains PeerDAS, which introduces peer-to-peer data availability sampling, enabling more efficient and decentralized handling of blob data across the network.