The name "Fusaka" comes from the combination of the execution layer upgrade "Osaka" and the consensus layer version "Fula Star." This upgrade is expected to be activated on December 3, 2025, at 21:49 UTC.
This upgrade includes 12 EIPs, covering data availability, gas/block capacity, security optimizations, signature compatibility, transaction fee structures, etc. It is a systematic upgrade aimed at achieving L1 scaling, reducing L2 costs, lowering node costs, and enhancing user experience.
I. Two Core Goals of Fusaka: Enhance Ethereum Performance, Improve User Experience
Goal 1: Significantly Enhance Ethereum's Underlying Performance and Scalability
Core Keywords:
Data availability expansion
Reduced node burden
More flexible blobs
Enhanced execution capabilities
More efficient and secure consensus mechanism
In short: Further enhance Ethereum's performance.
Goal 2: Improve User Experience, Promote Next-Generation Wallets and Account Abstraction
Core Keywords:
Block pre-confirmation
Support for P-256 (device-native signatures)
Wallets without mnemonic phrases
A more modern account system
Essentially: Ethereum is moving towards the experience of mainstream internet software.
II. Five Key Changes in Fusaka
1. PeerDAS: Alleviating Data Storage Burden on Nodes
PeerDAS is a core new feature of the Fusaka upgrade. Currently, Layer 2 nodes use blobs (a type of temporary data) to publish data to Ethereum. Before the Fusaka upgrade, each full node had to store every blob to ensure data availability. As the throughput of blobs increases, downloading all this data becomes extremely resource-intensive, making it difficult for nodes to cope.
PeerDAS adopts a data availability sampling solution, allowing each node to store only a portion of the data blocks instead of all. To ensure data availability, any part of the data can be reconstructed using 50% of the existing data, with the reconstruction method reducing the probability of errors or missing data to a cryptographically negligible level.
The implementation principle of PeerDAS: applying Reed-Solomon style erasure coding to blob data. In traditional fields, DVDs use the same coding technology— even if a DVD disc gets scratched, the player can still read it; similarly, QR codes can still be recognized even if part of them is obscured.
Thus, through the PeerDAS solution, both the hardware and bandwidth requirements for nodes can be kept within acceptable limits while achieving blob expansion, allowing for more and larger-scale Layer 2 operations at lower costs.
2. On-Demand Elastic Increase of Blob Quantity: Adapting to Changing L2 Data Needs
To coordinate a consistent upgrade across all nodes, clients, and validator software, a gradual approach is necessary. To adapt more quickly to the changing demands for Layer 2 data blocks, a mechanism that branches only through data block parameters (blob-parameter-only forks) has been introduced.
During the Dencun upgrade, the network initially added 3 blobs (max 6), which later increased to 6 (max 9) in the Pectra upgrade. After Fusaka, the number of blobs can be increased at a sustainable pace without requiring major network upgrades.
3. Support for Historical Record Expiration: Reducing Node Costs
To reduce the disk space required by node operators during Ethereum's continuous growth, clients are required to start supporting the feature of partial historical record expiration. In fact, clients have already been able to implement this feature in real-time; it is just being explicitly included in the to-do list with this upgrade.
4. Early Implementation of Block Pre-Confirmation: Faster Transaction Confirmation
With EIP7917, the beacon chain will be able to sense the block proposer for the next epoch. Knowing in advance which validators will propose future blocks allows for pre-confirmation. A commitment can be made with the upcoming block proposer to ensure that user transactions will be included in that block without waiting for the actual block to be generated.
This feature benefits client implementation and network security, as it prevents extreme situations such as validator manipulation of proposer scheduling. Additionally, the foresight feature reduces implementation complexity.
5. Native P-256 Signatures: Aligning Ethereum Directly with 5 Billion Mobile Devices
The introduction of a built-in, passkey-like secp256r1 (P-256) signature checker at fixed addresses is the native signature algorithm used by systems like Apple/Android/FIDO2/WebAuthn.
For users, this upgrade unlocks device-native signatures and passkey functionality. Wallets can directly access Apple’s secure enclave, Android’s keystore, hardware security modules (HSM), and FIDO2/WebAuthn—without mnemonic phrases, making the registration process smoother and the multi-factor authentication experience comparable to modern applications. This will lead to a better user experience, more convenient account recovery methods, and an account abstraction model that matches the existing capabilities of billions of devices.
For developers, it accepts 160-byte inputs and returns 32-byte outputs, making it very easy to port existing libraries and L2 contracts. Its underlying structure includes checks for infinity and modular comparisons to eliminate tricky edge cases while not compromising valid callers.
III. Long-Term Impact of the Fusaka Upgrade on the Ethereum Ecosystem
Impact on L2: Scaling enters the second curve. Through PeerDAS and on-demand increases in blob quantity, along with a fairer data fee mechanism, the data availability bottleneck is resolved, and Fusaka accelerates the downward trend in L2 costs.
Impact on Nodes: Operating costs continue to decline. Reduced storage requirements and shorter synchronization times lower operating costs. In the long run, this ensures the sustainable participation of weak hardware nodes, thereby maintaining the network's ongoing decentralization.
Impact on DApps: More complex on-chain logic becomes possible. More efficient opcode and more predictable block proposal timelines could drive high-performance AMMs, more complex derivatives protocols, and fully on-chain applications.
Impact on Ordinary Users: Finally, blockchain can be used like Web2. P-256 signatures mean—no mnemonic phrases, phones as wallets, easier logins, simpler recovery, and naturally integrated multi-factor verification. This is a revolutionary change in user experience and one of the necessary conditions for bringing a billion users on-chain.
IV. Summary: Fusaka is a Key Step Towards DankSharding and Large-Scale User Adoption
Dencun opened the era of blobs (Proto-DankSharding), Pectra optimized execution and the impact of EIP-4844, and Fusaka takes a crucial step towards "sustainable scaling + mobile-first" for Ethereum.
TLDR:
This upgrade will incorporate 12 EIPs, mainly including:
EIP-7594: Adopting PeerDAS to alleviate the data storage burden on nodes.
This is a key foundation for expanding Ethereum's data capacity. PeerDAS builds the infrastructure needed to achieve Danksharding, with future upgrades expected to increase data throughput from 375kb/s to several MB/s; it also directly enables Layer 2 scaling, allowing nodes to efficiently handle more data without overwhelming any single participant.
EIP-7642: Introducing historical record expiration functionality to reduce the disk space required by nodes.
This is akin to changing the way receipts are processed, removing old data from node synchronization, thus saving about 530GB of bandwidth during synchronization.
EIP-7823: Setting a limit on MODEXP input length to prevent consensus vulnerabilities.
This limits the input length of each MODEXP cryptographic precompile to 1024 bytes. Previously, the input length was unrestricted, making MODEXP a source of consensus vulnerabilities. By setting practical limits that cover all real-world application scenarios, it reduces the testing scope and paves the way for future replacements with more efficient EVM code.
EIP-7825: Introducing a gas limit for transactions to prevent a single transaction from consuming most of the block space.
This introduces a limit of 167,777,216 gas for a single transaction, preventing any single transaction from consuming most of the block space. This ensures a fairer distribution of block space, thereby improving network stability and defense against DoS attacks, and achieving more predictable block validation times.
EIP-7883: Increasing the gas cost of the ModExp cryptographic precompile to prevent potential denial-of-service attacks due to underpricing.
To address the issue of underpricing operations, the gas cost of the ModExp cryptographic precompile has been increased. The minimum cost has risen from 200 gas to 500 gas, and for large inputs over 32 bytes, the cost doubles. By ensuring reasonable pricing for cryptographic precompiles, it enhances the economic sustainability of the network and prevents potential denial-of-service attacks due to underpricing.
EIP-7892: Supporting on-demand elastic increases in blob quantity to adapt to the changing needs of Layer 2.
This creates a new lightweight process to adjust blob storage parameters. Ethereum can make smaller, more frequent adjustments to blob capacity without waiting for major upgrades, adapting to the changing needs of Layer 2.
EIP-7917: Implementing block pre-confirmation to improve the predictability of transaction order.
Currently, validators cannot know who will propose blocks before the next epoch begins, creating uncertainty for MEV mitigation and pre-confirmation protocols. This change pre-computes and stores the proposer schedule for future epochs, making it certain and accessible to applications.
EIP-7918: Introducing a base fee for blobs linked to execution costs to address the data block fee market issue.
This solution addresses the data block fee market issue by introducing a reserve price linked to execution costs. When Layer 2 execution costs are significantly higher than data block costs, this can prevent the data block fee market from failing at 1 wei.
This is crucial for L2, ensuring that sustainable blob pricing reflects real costs and maintains effective price discovery as L2 usage scales up.
EIP-7934: Limiting the maximum RLP execution block size to 10MB to prevent network instability and denial-of-service attacks.
Currently, block sizes can be very large, slowing down network propagation and increasing the risk of temporary forks. This limit ensures that block sizes remain within a reasonable range that the network can efficiently process and propagate. This improves network reliability and reduces the risk of temporary forks, leading to more stable transaction confirmation times.
EIP-7935: Raising the default gas limit to 60M to expand L1 execution capacity.
This proposal suggests raising the gas limit from 36M to 60M to expand L1 execution capacity. Although this change does not require a hard fork (the gas limit is a parameter chosen by validators), extensive testing is needed to ensure network stability under high computational loads. Therefore, including this EIP in a hard fork can ensure that this work is prioritized and ongoing.
By allowing more computations per data block, the overall network throughput is directly increased, which is the most straightforward method to expand L1 execution capacity.
EIP-7939: Adding the CLZ opcode to make on-chain computation more efficient
This update adds a new CLZ (Count Leading Zeros) opcode to the EVM, which efficiently counts the number of leading zeros in a 256-bit number. It can significantly reduce the gas cost of mathematical operations that require bit manipulation, improving computational efficiency and enabling more complex on-chain calculations. This move allows for cheaper and more efficient mathematical operations, benefiting DeFi protocols, gaming applications, and any contracts that require complex mathematical computations.
EIP-7951: Adding support for the secp256r1 curve precompile to enhance user experience
This update adds support for the widely used cryptographic curve secp256r1 (also known as P-256) to Ethereum. Currently, Ethereum only supports the secp256k1 curve for signatures, but many devices and systems use secp256r1. This update enables Ethereum to verify signatures from iPhones, Android phones, hardware wallets, and other systems that use this standard curve, making it easier to integrate with existing infrastructure.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
