Author: Ethereum Intern

Compiled by: Tim, PANews

Fusaka is the latest technical upgrade to the Ethereum network, scheduled for 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 are smaller proposals that make up the upgrade content. Next, we will introduce each EIP in order from the most popular to the least popular (this is entirely my subjective ranking!).

1. EIP-7594

First up is PeerDAS, a significant transformation in Ethereum's data availability and a major performance enhancement.

I often hear some misunderstandings about data availability, so let's explore this first:

To achieve final settlement on Ethereum, Rollups publish all the data required for new states in the form of blobs: this data is temporarily stored by Ethereum nodes.

If the complete state is not accessible, users will be unable to enforce withdrawals because they cannot generate the necessary proofs. This means that malicious sorters could withhold user funds or obstruct them maliciously.

Therefore, data availability is a guarantee that Ethereum ensures the availability of blobs. For example, smart contracts like L1 and L2 bridging contracts can confirm the existence of blobs and verify their content.

Currently, through the Proto-Danksharding (EIP-4844) scheme, blobs are replicated across all network nodes. If we want to continue providing this service, the current scheme lacks scalability, as its target throughput is only 31 KB per second.

The newly introduced PeerDAS system employs data sharding technology. This means that the content of data blocks will be stored in a distributed manner across different nodes, with no single node needing to store all the data.

However, a simple sharding structure can lead to data availability risks. How do we solve this problem?

First, blobs now use erasure coding technology. They are divided into 8 cells: 4 are used to store the original blob data, and the other 4 store additional information for reconstructing the data (this technology is known as Reed-Solomon erasure coding).

As long as there are 4 cells, the entire blob can be reconstructed. Even if two pieces of original data are lost, as long as two other random blobs are obtained, all data can still be recovered!

After being encoded with erasure coding, blobs are evenly distributed and stored in groups of nodes called "subnets." Each subnet stores 1/8 of each blob and distributes it to any requesting node.

The initial goal of PeerDAS is to handle 10 blobs per block, but in the future, it will gradually increase to 14 and eventually reach the capacity to handle 48 blobs through hard fork upgrades that only adjust the number of blobs parameter. This is to avoid overloading the network, and the specific implementation plan will be detailed in subsequent sections.

Nodes execute DA layer requirements by randomly requesting data units and deterministic proofs from other nodes during each period. Nodes that refuse to cooperate may face harsh penalties from other nodes through joint decisions.

This means that nodes that continuously refuse to provide data will be blacklisted by other nodes and marked as unreliable, effectively expelling them from the network.

Additionally, nodes must check the availability of blobs in new blocks before accepting those blocks, meaning that new blocks lacking blobs will be directly rejected.

Validators also need to store and transmit more blobs than regular nodes; if their stake reaches the limit of 4096 ETH, they must handle all data. This requirement is enforced by the P2P network layer, and if this rule is not followed, the network will stop communicating with the validator.

2. EIP-7951

Alright, we've talked quite a bit about PeerDAS. Next, we will discuss a new feature: the secp256r1 curve precompiled contract, which is EIP-7951.

Similar to Bitcoin, the elliptic curve digital signature algorithm (ECDSA) used by Ethereum is called secp256k1. This curve is specifically designed for digital signatures, ensuring that it is impossible to derive the private key from the signature.

However, most secure elements (i.e., isolated tamper-resistant hardware chips that perform cryptographic operations) do not support the secp256k1 curve. These chips can perform cryptographic operations while keeping keys secure.

You can think of it as a hardware wallet built into your computer or phone.

The secp256r1 curve is a curve widely supported by secure elements, and setting it as a precompiled contract means that smart wallets can more easily implement security features such as device-native signing and multi-factor authentication.

3. EIP-7917

The next EIP is proposal 7917, which aims to fix what some call a design flaw in the beacon chain.

Block producers are selected through a RANDAO random seed, which is calculated two periods in advance. Therefore, you should be able to predict the next block producer.

Block producers are randomly selected from the entire set of validators, weighted by their stake. However, if any validator's stake changes by more than 1 ETH (such as through deposits or penalties), the entire block producer arrangement will be regenerated.

EIP-7917 means that the block producer selection is stored in the state and set two periods in advance, like RANDAO.

This also makes it easier for on-chain contracts to verify the network broadcasts of block producers, as smart contracts can now verify Merkle proofs through the beacon state root. This improvement has significant practical value for applications based on pre-confirmation protocols.

4. EIP-7939

Next is EIP-7939, which introduces the Count Leading Zeros (CLZ) opcode. This is probably the most favored EIP proposal by optimizers, as it can save 179 gas compared to the current best Yul implementation.

CLZ is used to count the number of leading zeros in the EVM word length (256 bits), and this instruction is widely applicable. There is no need to elaborate on this, but it is foreseeable that it will enable more efficient cryptographic and mathematical operations in the future.

5. EIP-7825

EIP-7825 (Transaction Gas Limit Proposal) sets the gas limit for a single transaction at 2^24 (approximately 16 million gas), which is slightly more than one-third of a single block's capacity.

Setting a gas fee cap for a single transaction is primarily a DDoS protection mechanism. This measure can prevent potential load imbalance issues among network nodes while reducing the worst-case validation overhead and alleviating state bloat.

6. EIP-7918

Next is the EIP-7918 proposal, which aims to improve the blob market by establishing a gas fee standard for blobs. Similar to the fixed consumption of 21000 gas for a single transaction, each blob will have a minimum consumption standard of 8192 gas.

As everyone knows, the DA layer and execution layer use a dual-track billing mechanism. Even if the price of data availability skyrockets (for example, due to NFT minting activities on Layer 2), the gas price on the mainnet can remain stable.

However, this raises some new economic issues:

When the cost of Rollups is primarily composed of mainnet gas fees, the price signal mechanism for blobs becomes ineffective, leading to repeated reductions in blob fees. This is precisely why we often observe significant fluctuations in blob fees, with prices plummeting to 1 wei and then quickly rebounding.

Therefore, slightly linking blob transaction fees to the standard gas market can prevent blob space fees from being severely undervalued. Additionally, this can ensure that costs reflect the actual computational resources consumed when nodes validate KZG proofs!

7. EIP-7883

The upcoming EIP-7883 proposal will increase the cost of modular exponentiation precompiled contracts, making their pricing more accurate in specific use cases. This adjustment aims to ensure that costs reflect their actual computational resource consumption, as this function was previously priced too high and is currently priced too low.

This fee adjustment will raise the minimum gas cost from 200 to 500, implement a double multiplier for exponents exceeding 32 bytes, and double the complexity cost when the base or modulus exceeds 32 bytes.

The importance of accurate pricing lies in preventing potential DDoS attacks. Gas costs should be proportional to the amount of resources consumed by nodes, thereby preventing attackers from incapacitating network nodes at minimal cost.

8. EIP-7823

EIP-7823 is another proposal affecting the modular exponentiation precompiled contract, which limits the length of each input parameter to 1024 bytes (8192 bits) because the modular exponentiation function has repeatedly been the source of consensus vulnerabilities.

Consensus vulnerabilities refer to situations where a large number of validators execute invalid state transitions. This scenario is extremely dangerous, especially in proof-of-stake mechanisms, as invalid chains could potentially be finalized, leading to catastrophic consequences.

Modular exponentiation is a complex precompiled function, and different execution layer clients may implement this function with extremely subtle differences. Although there are currently many test cases for modular exponentiation, the risk of vulnerabilities significantly increases when the input length exceeds the test coverage.

The 8192-bit length limit still accommodates all practical application scenarios, such as supporting RSA verification with keys up to 8192 bits (commonly used key sizes are 1024/2048/4096 bits) and elliptic curve cryptography applications that typically use keys no longer than 384 bits.

Based on an analysis of Ethereum's complete historical data, this modification does not affect any past transactions, as the maximum input length in successfully executed transactions has been below 513 bytes.

This limitation also allows for easier future integration with new schemes like EVMMAX to reconstruct the modular exponentiation precompiled function.

9. EIP-7934

The EIP-7934 proposal will introduce an 8 MiB size limit for execution layer blocks. Currently, Ethereum does not impose a limit on block size, but the P2P network cannot effectively propagate blocks larger than 10 MiB.

The 8 MiB capacity will be dedicated to actual transaction data, while reserving a 2 MiB buffer for consensus layer overhead.

This limitation will minimize the risk of the network suffering from oversized block attacks in the future, even though the worst-case block size is currently far below this limit.

Alright, we have 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 updates that only modify the target values, limits, and pricing mechanisms for blobs. Each BPO fork requires only configuration changes without code modifications.

EIP-7642 removes legacy data from the P2P protocol prior to the merge, deletes the Bloom field from P2P (saving about 530 GB of sync bandwidth), and adds a block update feature that allows nodes to know the range of blocks they can serve.

EIP-7910 introduces a new JSON-RPC method called eth_config to describe the configuration information for current and scheduled hard forks. This feature is intended for node operators and network monitoring tools to verify client readiness.

Finally, EIP-7935 sets the default block gas limit in the validator configuration to 60 million, an increase from the current standard of 45 million gas per block.

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