The name Fusaka comes from a 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 optimization, signature compatibility, transaction fee structure, etc., and is a systemic upgrade to achieve L1 scaling, reduce L2 costs, reduce node costs, and improve user experience. I. Fusaka's Two Core Goals: Improving Ethereum Performance and Enhancing User Experience Goal 1: Significantly Improve Ethereum's Underlying Performance and Scalability Core Keywords: Data Availability Scalability Reduction Node Burden More Flexible Blobs Improved Execution Capabilities A More Efficient and Secure Consensus Mechanism In short: Further enhance Ethereum performance. Objective Two: Improve User Experience and Drive Next-Generation Wallet and Account Abstraction Core Keywords: Block Preconfirmation P-256 (Device Native Signature) Support Mnemonic Word Wallet A More Modern Account System The essence is that Ethereum is moving closer to the experience of mainstream internet software. II. Five Key Changes in Fusaka 1. PeerDAS: Reducing the Data Storage Burden on Nodes PeerDAS is a core new feature of the Fusaka upgrade. Currently, Layer 2 nodes use blobs (a temporary data type) to publish data to Ethereum. Before the Fusaka upgrade, each full node had to store every blob to ensure data existence. As blob throughput increases, downloading all this data becomes extremely resource-intensive, making it difficult for nodes to handle. PeerDAS employs a data abailability sampling scheme, allowing each node to store only a portion of the data blocks, rather than the entire data block. To ensure data availability, any portion of the data can be reconstructed from 50% of the existing data, reducing the probability of errors or missing data to a cryptographically negligible level. The implementation principle of PeerDAS is to apply Reed-Solomon erasure coding to blob data. In traditional domains, DVDs use the same encoding technology—even with scratches, the player can still read the DVD; and QR codes, even when partially obscured, can still be fully recognized. Therefore, the PeerDAS solution ensures that the hardware and bandwidth requirements of the nodes are within an acceptable range, while also enabling blob expansion, thus supporting more and larger-scale Layer 2 deployments at a lower cost. 2. On-demand elastic increase in blob quantity: Adapting to ever-changing L2 data requirements. To coordinate consistent upgrades across all nodes, clients, and validator software, a gradual approach is necessary. To more quickly adapt to the ever-changing Layer 2 data block requirements, a mechanism of blob-parameter-only forks is introduced.

When blobs were first added to the network during the Dencun upgrade, there were 3 (max 6). This was later increased to 6 (max 9) during the Pectra upgrade. After Fusaka, the number can be increased at a sustainable rate without requiring further major network upgrades.
3. Support for History Expiration: Reducing Node Costs
To reduce the disk space required by node operators during Ethereum's continued growth, clients are required to begin supporting the function of partially expiring history records.
In fact, the client already has this function available in real time, but it's being explicitly added to the to-do list during this upgrade. 4. Pre-confirm Blocks: Faster Transaction Confirmation With EIP7917, the Beacon Chain will be able to sense the block proposers of the next epoch. Knowing in advance which validators will propose future blocks enables pre-confirmation. A commitment is 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 because it prevents extreme situations such as validators manipulating proposer scheduling. Furthermore, the lookout function reduces implementation complexity. 5. Native P-256 Signatures: Ethereum Directly Aligns with 5 Billion Mobile Devices A built-in, passkey-like secp256r1 (P-256) signature checker is introduced to a fixed address. This is the native signature algorithm used by systems such as Apple, Android, FIDO2, and WebAuthn. For users, this upgrade unlocks native device signatures and passkey functionality. Wallets can directly access Apple's Secure Enclosure, Android's Keystore, Hardware Security Module (HSM), and FIDO2/WebAuthn—no mnemonic phrase required, a smoother registration process, and a multi-factor authentication experience comparable to modern applications. This will bring a better user experience, a more convenient way to restore accounts, and an account abstraction pattern that matches the existing functionality of billions of devices. For developers, it accepts 160 bytes of input and returns 32 bytes of output, making it very easy to port existing libraries and L2 contracts. Its underlying implementation includes pointers to infinity and modulo comparison checks to eliminate tricky boundary cases without breaking valid callers. III. Long-Term Impact of the Fusaka Upgrade on the Ethereum Ecosystem 1. Impact on L2: Scaling Enters the Second Curve. By increasing the number of PeerDAS and Blobs on demand, and through a fairer data fee mechanism, the data availability bottleneck is resolved, and Fusaka accelerates the decline in L2 costs. 2. Impact on nodes: Operating costs continue to decrease. Reduced storage demand and shorter synchronization times lower operating costs. In the long run, this ensures the sustainable participation of nodes with weak hardware, thus guaranteeing the continued decentralization of the network. 3. Impact on DApps: More complex on-chain logic becomes possible. More efficient mathematical opcodes and more predictable block proposal schedules could drive high-performance AMMs, more complex derivative protocols, and fully on-chain applications. 4. Impact on ordinary users: Finally, blockchain can be used like Web2. P-256 signatures mean—no mnemonic phrases needed, mobile phones as wallets, easier login, simpler recovery, and natural integration of multi-factor authentication. This is a revolutionary change in user experience and one of the necessary conditions for driving 1 billion users to the blockchain. IV. Conclusion: Fusaka is a key step towards DankSharding and large-scale user adoption. Dencun ushered in the Blob (Proto-DankSharding) era, Pectra optimized execution, and EIP-4844 had an impact. Fusaka, however, allows Ethereum to take a crucial step towards "sustainable scaling + mobile-first" development. TLDR: This upgrade will incorporate 12 EIPs, including: EIP-7594: Employing PeerDAS to reduce the data storage burden on nodes. This is a key foundation for expanding Ethereum's data capacity. PeerDAS builds the infrastructure needed to implement Danksharding, and future upgrades are expected to increase data throughput from 375kb/s to several MB/s; it also directly achieves Layer 2 scaling, enabling nodes to efficiently process more data without overwhelming individual participants. EIP-7642: Introduces the history expiration feature to reduce the disk space required by nodes. This is equivalent to changing how receipts are handled, deleting old data from node synchronization, thus saving approximately 530GB of bandwidth during synchronization. EIP-7823: Sets a limit on MODEXP to prevent consensus vulnerabilities. This limits the length of each input to MODEXP's encrypted precompiled version to 1024 bytes. Previously, MODEXP had been a source of consensus vulnerabilities due to the unlimited input length. By setting practical limits covering all real-world application scenarios, the testing scope is reduced, paving the way for future replacement with more efficient EVM code. EIP-7825: Introducing a transaction gas cap to prevent a single transaction from consuming most of the block space. This introduces a gas cap of 167,777,216 per transaction, preventing any single transaction from consuming most of the block space. This ensures a fairer allocation of block space, thereby improving network stability and the ability to defend against DoS attacks, and achieving more predictable block verification times. EIP-7883: Increase Gas Cost of ModExp Cryptographic Precompilers to Prevent Potential Denial-of-Service Attacks Due to Underpricing To address the issue of underpricing operations, the gas cost of ModExp cryptographic precompilers has been increased. The minimum cost has been increased from 200 gas to 500 gas, and the cost doubles for large inputs exceeding 32 bytes. This improves network economic sustainability by ensuring reasonable pricing for cryptographic precompilers and preventing potential denial-of-service attacks due to underpricing. EIP-7892: Supports On-Demand Elastic Increase of Blob Quantity to Adapt to Changing Layer 2 Needs. This is achieved by creating a new lightweight process for adjusting blob storage parameters. Ethereum can now adjust blob capacity more frequently and in smaller increments to adapt to evolving Layer 2 needs without waiting for major upgrades. EIP-7917: Implementing Block Preconfirmation to Improve the Predictability of Transaction Orders Currently, validators cannot know who will propose blocks before the start of the next epoch, introducing uncertainty into MEV mitigation and preconfirmation protocols. This change pre-calculates and stores the proposer schedule for future epochs, making it predictable and accessible to applications. EIP-7918: Addressing the Block Fee Market Problem by Introducing a Base Blob Fee Linked to Execution Costs. This solution addresses the block fee market problem by introducing a reserve price linked to execution costs. This prevents the block fee market from failing at 1 wei when Layer 2 execution costs are significantly higher than block costs. This is crucial for L2, ensuring sustainable blob pricing reflects true costs and maintains effective price discovery as L2 usage scales. 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, which slows down network propagation and increases the risk of temporary forks. This limit ensures that block sizes remain within a reasonable range that the network can process and propagate efficiently. This improves network reliability, reduces the risk of temporary forks, and thus achieves more stable transaction confirmation times. EIP-7935: Increasing the Default Gas Limit to 60M to Expand L1 Execution Capability This proposal suggests increasing the gas limit from 36M to 60M to expand L1 execution capability. While 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 ensures that this work is prioritized and continued. By allowing more computation per data block, the overall network throughput is directly improved, which is the most direct way to expand L1 execution capability. EIP-7939: Adding the CLZ Opcode for More Efficient On-Chain Computation This update adds a new CLZ (Calculate Leading Zeros) opcode to the EVM for efficiently calculating the leading zeros of a 256-bit number. This significantly reduces the gas cost of mathematical operations requiring bit manipulation, improves computational efficiency, and enables more complex on-chain computations. This allows for cheaper and more efficient mathematical operations, benefiting DeFi protocols, gaming applications, and any contracts that require complex mathematical calculations. EIP-7951: Adds Support for Pre-compiled secp256r1 Curve, Enhancing 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 signing, but many devices and systems use secp256r1. This update enables Ethereum to verify signatures from iPhones, Android phones, hardware wallets, and other systems using this standard curve, making integration with existing infrastructure easier.