Author: Ethereum Intern
Compiled by: Tim, PANews
Fusaka is the latest technical upgrade to the Ethereum network and will take place on December 3, 2025 at 21:49:11.
How will this upgrade affect Ethereum? What specific changes will occur on the mainnet? Let's find out!
Like other upgrades, Fusaka includes various EIPs (Ethereum Improvement Proposals), which together constitute the upgrade content. We will now introduce each EIP in order of popularity (this is entirely my subjective ranking!).
1. EIP7594
First is PeerDAS, which is a major change in Ethereum's data availability and a key performance improvement.
I often hear some misconceptions about data availability, so let's discuss them first:
To complete the final settlement on Ethereum, Rollup publishes all the data required for the new state in the form of blobs: these data are temporarily stored by Ethereum nodes.
If the complete state cannot be accessed, users will be unable to force a withdrawal because they cannot generate the necessary proof. This means that malicious sorting tools could potentially withhold user funds or maliciously obstruct them.
Therefore, data availability is a guarantee that Ethereum uses to ensure the availability of blobs. For example, smart contracts such as L1 and L2 bridge contracts can confirm the existence of blobs and verify their content.
Currently, using the Proto-Danksharding (EIP-4844) scheme, blobs are replicated across all network nodes. However, this current approach lacks scalability for sustained service provision, as its target throughput is only 31 KB per second.
The newly launched PeerDAS system uses data sharding technology. This means that data blocks are distributed and stored across different nodes, and no single node needs to store all the data.
However, simple sharding can introduce data availability risks. How can we address this issue?
First, blobs now use erasure coding. They are divided into 8 cells: 4 cells are used to store the original blob data, and the other 4 cells are used to store additional information for reconstructable data (this technique is called Reed-Solomon erasure coding).
With just four cells, the entire blob can be reconstructed. Even if two original data sets are lost, all data can still be recovered as long as two additional random blobs are obtained!
After erasure coding, the blob is evenly distributed and stored in a group of nodes called a "subnet". Each subnet stores 1/8 of each blob and distributes it to any requesting node.
PeerDAS initially aims to process 10 blobs per block, but will gradually increase this to 14 blobs and eventually 48 blobs through hard forks that only adjust the number of blobs parameter. This is to avoid overloading the network; the specific implementation will be detailed in later chapters.
Nodes execute DA layer requirements by randomly requesting data units and deterministic proofs from other nodes at each time interval. Nodes that refuse to cooperate may be subject to joint adjudication by other nodes and face severe penalties.
This means that nodes that consistently refuse to provide data will be blacklisted and marked as unreliable by other nodes, which is essentially equivalent to expelling them from the network.
In addition, nodes must check whether the blob of a new block is available before accepting the block, which means that new blocks that lack a blob will be rejected directly.
Validators are also required to store and transmit more blobs than regular nodes, and if their stake reaches the cap of 4096 ETH, they must process all the data. This requirement is enforced by the P2P network layer; if this rule is not followed, the network will stop communicating with the validator.
2. EIP-7951
Okay, we've talked quite a bit about PeerDAS. Next, we'll discuss a new feature: pre-compiled secp256r1 curves, also known as EIP-7951.
Similar to Bitcoin, Ethereum uses an elliptic curve digital signature algorithm (ECDSA) with a curve called secp256k1. This curve is specifically designed for digital signatures to ensure that it is impossible to deduce a private key from a signature.
However, most secure components (i.e., isolated, tamper-proof hardware chips that perform cryptographic operations) do not support the secp256k1 curve, which allows cryptographic operations to be performed while protecting the key.
You can think of it as a hardware wallet built into a computer or mobile phone.
The secp256r1 curve is a curve widely supported by secure elements. Setting it as a precompiled contract means that smart wallets can more easily implement security features such as native device signatures and multi-factor authentication.
3.EIP7917
The next EIP is Proposal 7917, which aims to fix what some have called a design flaw in the Beacon Chain.
The block producer is selected using a random seed from RANDAO, which is calculated two time intervals in advance. Therefore, you should be able to predict the block producer for the next time interval.
Block producers are randomly selected from the set of all validators, weighted according to their stake. However, if any validator's stake changes by more than 1 ETH (e.g., through deposits or penalties), the entire block producer arrangement will be regenerated.
EIP-7917 means that the block producer chooses to store the block in the state, and sets it two time intervals in advance, just like RANDAO.
This also makes it easier for on-chain contracts to verify the block producer's network broadcast, as smart contracts can now verify Merkle proofs via beacon state roots. This improvement has significant practical value for applications based on pre-acknowledgment protocols.
4. EIP7939
Next is EIP-7939, the Count Leading Zero (CLZ) opcode. This is probably the EIP scheme most favored by optimizoor because it saves 179 gas compared to the current best Yul implementation.
CLZ is used to calculate the number of leading zeros in a 256-bit EVM word, and this instruction has wide applications. This goes without saying, but it's foreseeable that it will enable more efficient cryptographic and mathematical operations in the future.
5. EIP7825
EIP-7825 (the proposal to cap the gas for a single transaction) sets the gas cap at 2^24 (approximately 16 million gas), which is slightly more than one-third of the capacity of a single block.
Setting a cap on gas fees for a single transaction is primarily a DDoS protection mechanism. This measure avoids potential load imbalances among network nodes, while also reducing worst-case verification overhead and mitigating state bloat.
6.EIP7918
Next is Proposal EIP-7918, which aims to improve the blob market by establishing a gas fee standard for blobs. Similar to the base fee of 21,000 gas per transaction, each blob will have a minimum gas consumption standard of 8,192.
As you know, the DA layer and the execution layer use a dual-track billing mechanism. Even if the price of data availability surges (for example, due to NFT casting activities on Layer 2), the gas price on the mainnet will remain stable.
However, this has raised some new economic problems:
When the cost of a rollup is primarily composed of mainnet gas fees, the price signaling mechanism for blobs fails, causing the system to repeatedly lower blob fees. This is precisely why we often observe dramatic fluctuations in blob fees, with prices plummeting to 1 wei before quickly rebounding.
Therefore, linking blob transaction fees slightly to the standard gas market can prevent blob space fees from being significantly undervalued. Furthermore, this ensures that the cost reflects the actual computational power consumed by nodes when verifying KZG proofs!
7.EIP7883
Our upcoming EIP-7883 proposal will increase the cost of precompiled contracts for modular exponentiation, allowing for more accurate pricing in specific use cases. This adjustment aims to ensure that the cost reflects the actual computational resource consumption of this feature, which has historically been overpriced and currently underpriced.
This fee adjustment will raise the minimum gas cost from 200 to 500, double the multiplier for exponents exceeding 32 bytes, and double the complexity cost when the base or modulus exceeds 32 bytes.
Accurate pricing is crucial for preventing potential DDoS attacks. Gas costs should be proportional to the amount of resources consumed by nodes, thus preventing attackers from paralyzing network nodes with minimal cost.
8.EIP7823
EIP-7823 is another proposal that affects precompiled contracts for modular exponentiation. It limits the length of each input parameter to 1024 bytes (8192 bits) because modular exponentiation functionality has been the source of consensus vulnerabilities on multiple occasions.
A consensus vulnerability occurs when a large number of validators execute invalid state transitions. This situation is extremely dangerous, especially in proof-of-stake mechanisms, because an invalid chain could eventually be determined, leading to catastrophic consequences.
Modular exponentiation is a complex pre-compiled function, so different execution layer clients may implement it with extremely subtle differences. Although there are currently a large number of test cases for modular exponentiation, the risk of vulnerabilities increases significantly when the input length exceeds the test coverage.
The 8192-bit length limit can still meet all practical application scenarios, such as supporting RSA verification with up to 8192-bit keys (currently 1024/2048/4096-bit keys are commonly used), and elliptic curve cryptography applications that typically use no more than 384 bits.
Based on the analysis of Ethereum's complete historical data, this modification has no impact on any past transactions, as the maximum input length in successfully executed transactions was less than 513 bytes.
This limitation also makes it easier to reconstruct the pre-compilation of modular exponentiation operations in conjunction with new solutions such as EVMMAX in the future.
9.EIP7934
EIP-7934 proposes an 8 MiB size cap for execution layer blocks. While Ethereum currently does not have a block size limit, P2P networks are practically unable to effectively propagate blocks larger than 10 MiB.
8 MiB of capacity will be dedicated to actual transaction data, while a 2 MiB buffer will be reserved for consensus layer overhead.
This limit minimizes the risk of future network attacks involving extremely large blocks, even though the worst-case block size is currently far below this limit.
Okay, we've covered all the core EIPs, and now there are a few minor proposals: EIP-7892, EIP-7642, EIP-7910, and EIP-7935.
EIP-7892 defines a new type of hard fork, designed for more frequent changes that only modify the target value, cap, and pricing mechanism of the blob. Each BPO fork requires only configuration changes and no code modifications.
EIP-7642 removed legacy data from the p2p protocol prior to the merge, deleted the Bloom field in p2p (saving approximately 530GB of synchronization bandwidth), and added block update functionality, enabling nodes to know the range of blocks they can serve.
EIP-7910 introduces a new JSON-RPC method called eth_config to describe configuration information for current and planned hard forks. This feature is intended to allow node operators and network monitoring tools to verify client readiness.
Finally, EIP-7935 sets the default block GAS limit in validator configuration to 60 million, an increase from the current standard of 45 million GAS per block.
