The original text is from Sahil Sojitra

Translated by ｜Odaily Planet Daily Golem

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

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

PeerDAS (EIP-7594) improves data availability by allowing nodes to verify blobs without needing to download all the data. Several 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, 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 whether it has been published. This creates scalability issues, as requiring all nodes to download all data increases the network's bandwidth and hardware demands, affecting decentralization. To address this, Ethereum needs a method that allows nodes to confirm data availability without downloading all the 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. PeerDAS was created to meet these needs and safely increase 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 the 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 in the existence of the entire data fragment. For example, a node might only download about 1/8 of the data instead of the full 256 KB data fragment—but since many nodes sample different parts, any missing data will be quickly discovered.

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

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 smallest verification units associated with KZG commitments. All "rows" are then reorganized into "columns," with each column containing cells from the same position across 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 in each time slot. If a node collects at least 50% of the columns, it can fully reconstruct the data. If the collected columns are less than 50%, 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 some 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 limit 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([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

In the new wrapper, cell_proofs is simply a list containing all proofs for each cell of each blob (e.g., [cell_proof_0, cell_proof_1, …]). The other fields tx_payload_body, 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 cell_proofs list, while a new field called wrapper_version has been added to indicate the current wrapper format in use.

PeerDAS enables Ethereum to improve data availability without increasing the workload on nodes. 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, enhancing Ethereum's scalability. The system works well because each node has many 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 a corresponding data hosting load 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 network's reliability. 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 it greatly simplifies data reconstruction. If nodes sample entire rows (the whole blob), they would need to create additional "expanded blobs" that do not originally exist, which would slow down block producers.

By using 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 expanded 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 disrupt 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 that 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 an attack's success is extremely low, making PeerDAS considered secure.

EIP-7823: Setting a 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 extremely large and impractical amount of input data, causing clients to handle countless exceptional situations.

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. Excessively large input data also makes the gas cost formula difficult to predict, as it is challenging to price when the data size 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 the stability of Ethereum, EIP-7823 introduces strict upper 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. The MODEXP input follows 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 use cases. 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 (such as 256 bits, 381 bits, or 2048 bits) and use slower fallback solutions for rare cases. By fixing the maximum input size, developers can even add special handling for very common moduli. Previously, due to the lack of input size restrictions, the design space was too vast to manage securely, making these enhancements unfeasible.

To confirm that this change does not disrupt past transactions, the author analyzed all MODEXP usage from block 5,472,266 (April 20, 2018) to block 21,550,926 (January 4, 2025). The results showed that all historically successful MODEXP calls did not use inputs exceeding 513 bytes, well 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 is also 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 a reasonable size range, EIP-7823 makes the system more predictable, reduces strange edge cases, and lowers the probability of errors between different implementations. These limits also help prepare for future upgrades (such as EVMMAX) that may introduce optimized execution paths, allowing for a smoother transition.

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

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

This creates several issues: a single transaction may consume most of the block's resources, leading to slow delays similar to DoS attacks; operations that consume a lot 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 nearly consumes all gas (for example, a transaction consuming 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: the gas consumed by any transaction must not exceed 16,777,216 (2²⁴). This becomes a limit at the protocol level, meaning it applies to all stages: user sending transactions, transaction pool checking transactions, and validators packing transactions into blocks. If someone sends a transaction that exceeds this gas limit, the client must immediately reject the transaction and return an error like MAXGASLIMIT_EXCEEDED.

This limit is completely independent of the block gas limit. For example, even if the block gas limit is 40 million, the gas consumption of any single transaction 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 occupy 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 one person renting an entire bus, preventing others from boarding. The new 16,777,216 gas limit will naturally allow the block to accommodate multiple transactions, 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 uploading a very large file by breaking it 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.

From a security standpoint, 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, maintain reasonable node demands, improve fairness in block space usage, and ensure that as gas limits increase, the blockchain can still operate quickly and stably.

EIP-7883: Increase in ModExp Gas Fees

The reason Ethereum needs this proposal is that the price of the ModExp precompilation (used for modular exponentiation) has been consistently low compared to the actual resources consumed.

In some cases, the computational effort required for the ModExp operation 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 increases costs through several important aspects, modifying the pricing algorithm for ModExp originally defined in EIP-2565.

First, the minimum gas consumption is raised 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 iteration count to 8 × (40 − 32) = 64 times, while EIP-7883 now uses 16 × (40 − 32) = 128 times, effectively doubling the cost.

Third, the 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 the complexity and iteration count rules. Multiplication complexity now uses a default value of 16 for base/modulus lengths not exceeding 32 bytes, while switching to a more complex formula of 2 × words² for larger inputs, where "words" refers to the number of 8-byte blocks. The iteration count 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, which have high actual computational costs, now carry 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 the ModExp precompilation is significantly low. The revised formula increases the gas fees for small operations by 150%, for typical operations by about 200%, and for large or unbalanced operations by even more, sometimes exceeding 80 times, depending on the size of the exponent, base, or modulus.

The aim 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 the most resource-intensive extreme cases. 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.

Test results indicate that the increase in gas fees is quite significant. Approximately 99.69% of historical ModExp calls now require either 500 gas (up from 200 gas) or three times the previous price. However, some high-load test cases see even larger increases in gas fees. For example, in an "exponentiation-intensive" test, gas consumption jumped from 215 to 16,624, an increase of about 76 times, as the pricing for extremely large exponents is now more reasonable.

From a security perspective, this proposal does not introduce new attack vectors nor does it lower the cost of any operations. On the contrary, it focuses on mitigating a significant risk: underpriced 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 be too high, but this is far better than the current issue of underpricing. The proposal does not introduce any interface changes or new features, so existing arithmetic behavior and test vectors remain valid.

EIP-7917: Accurately Predicting 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+1 is known during epoch N, the actual proposer list may still change due to updates in effective balances (EB) during epoch N.

These EB changes can 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 problems 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 "brush" 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 few epochs, so it does not change due to last-minute EB updates and is easily accessible by the application layer.

To achieve this, EIP-7917 introduces a deterministic proposer lookahead mechanism, which 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 proposers for each slot in epochs N and N+1. Then, as 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, predictable, and directly readable by clients without needing to recompute 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 a fork will also fill the entire lookahead 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 in the 6th epoch may still change. With EIP-7917, Ethereum will precompute all proposers for epochs 5, 6, and 7 at the start of the 5th epoch 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 design of the beacon chain. 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 brushing," where validators attempt to adjust their balances after seeing the RANDAO to influence the proposer list for the next epoch. The deterministic lookahead 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 calculated 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, primarily 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 Limited by Execution Costs

Ethereum needs this proposal because the current blob fee system (originating from EIP-4844) fails when execution gas becomes the primary cost of 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 as Ethereum continuously lowers the blob base fee, the total cost for rollups does not actually change, as the most expensive part remains the execution gas. Therefore, the blob base fee continues 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 several blocks to return to normal levels. This leads to price instability and makes it difficult for users to predict costs.

For example, suppose a rollup wants to publish its data: it needs to pay about 25,000,000 gwei in execution gas (approximately 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 would 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 being too low and making rollup blob pricing more stable and predictable.

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

Typically, this function increases or decreases the blob base 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 blob base fee from decreasing further. Therefore, the blob base 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 blob base fee has little impact on demand. In economics, this is referred to as "fee inelasticity." It creates a situation where the demand curve is nearly vertical: lowering the price does not increase demand.

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

Another reason for adding this reserve price is that nodes need to perform a lot of extra work to verify the KZG proofs of the 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, in EIP-7918, the number of proofs that nodes need to verify increases. 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, significantly 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 the storage of more blob data over time. As blob capacity increases, blob fees (in ETH) will naturally decrease. This proposal supports that because the reserve price is linked to execution gas prices rather than a fixed value, allowing it to adjust according to network growth.

As blob space and execution block space expand, their price relationship will remain balanced. The reserve price may only be too high in very rare cases where Ethereum significantly increases blob capacity without increasing execution gas capacity. 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, a small detail needs to be understood. Since the price of blobs depends on the execution base fee, a sudden rise in execution costs may temporarily put blob fees in 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 tied to that 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 increased the base fees of blocks compared to the old mechanism. During periods of low execution fees (averaging around 1.3 gwei), block fees remained almost unchanged unless the calculated base fees fell below the reserve price. By comparing thousands of blocks, the author demonstrated 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, thereby reducing extreme volatility.

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

EIP-7934: RLP Execution Block Size Limit

Before EIP-7934, Ethereum did not have a strict upper limit 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 created 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, an attacker 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 excessively large execution blocks may not propagate through the network, leading to fragmentation on-chain or divergence 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 upper 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 take up some space (SAFETY_MARGIN), Ethereum adds an additional 2 MiB (2,097,152 bytes) on top of that.

This means the actual maximum allowed RLP-encoded execution block size is MAXRLPBLOCKSIZE = MAXBLOCKSIZE - SAFETYMARGIN. If an 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 that both gas usage and actual byte size limits are adhered to.

The choice of a 10 MiB limit is intentional, as it aligns with the 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 situations where valid execution blocks become "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 withstand 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: Count Leading Zeros (CLZ) Opcode

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

This is a significant problem 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-shift operations are extremely high, making 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 way to compute it.

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 is consistent 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, as well as 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 underpricing leading to denial-of-service (DoS) attacks. Benchmarking shows 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 faster, cheaper, and 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: Signature Support for Modern Hardware

Before this EIP, Ethereum did not have 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. Due to the lack of this support, applications and wallets could not 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 even consensus failures. EIP-7951 fixes these security issues and introduces a secure, native precompiled contract that allows Ethereum to safely and efficiently support signatures from modern hardware.

EIP-7951 adds a new precompiled contract called 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 precompiled contract 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 if the x-coordinate of R' matches r (mod n). This corrects the error in RIP-7212, which directly compared r' without first reducing it modulo n.

The gas cost for this operation is set at 6900 gas, which is higher than the RIP-7212 version but aligns 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 precompiled level (leaving optional checks to applications), and explicitly states that the precompiled contract does not need to execute in constant time. The secp256r1 curve provides 128-bit security and has been widely trusted and analyzed, making it safe for use in Ethereum.

In short, EIP-7951 aims to securely introduce authentication supported by modern hardware into Ethereum, fix the security issues of earlier proposals, and provide a reliable, standardized way to verify P-256 signatures across the entire ecosystem.

Summary

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

In summary, the above outlines 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 precompiles, the core of this upgrade is still PeerDAS, which introduces peer-to-peer data availability sampling, enabling more efficient and decentralized handling of blob data across the entire network.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。