Skip to content

Add Fusaka FAQ #16413

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 14, 2025
Merged

Add Fusaka FAQ #16413

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7afe329
add Fusaka FAQ
taxmeifyoucan Oct 1, 2025
dfd1d2c
chore: apply suggestions from code review
wackerow Oct 5, 2025
15193b3
Apply suggestions from code review
taxmeifyoucan Oct 8, 2025
518929f
Remove duplicates, add hw requirements
taxmeifyoucan Oct 8, 2025
a0d266a
chore: add custom header ids
wackerow Oct 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions public/content/roadmap/fusaka/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,6 +192,83 @@ Yes, the Fusaka upgrade requires updates to both [execution clients and consensu

[More on recognizing and avoiding scams](/security/)

### What's with the zebras? 🦓 {#whats-with-the-zebras}

A zebra is Fusaka's developer-chosen "mascot" because its stripes reflect PeerDAS’s column-based data-availability sampling, where nodes custody certain column subnets and sample a few other columns from peers each slot to check that blob data is available.

The Merge in 2022 [used a panda](https://x.com/hwwonx/status/1431970802040127498) as its mascot to signal the joining of the execution & consensus layers. Since then, mascots have been informally chosen for each fork and show up as ASCII art in the client logs at the time of upgrade. It’s just a fun way to celebrate.

### What improvements are included for L2 Scaling? {#what-improvements-are-included-for-l2-scaling}

[PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) is is the main feature of the fork. It implements Data Availability Sampling (DAS). Instead of every full node needing to download and store all blob data (which becomes unsustainable as L2s grow), PeerDAS allows each node to be responsible for only a subset of the blob data while maintaining its availability and verifiability. This enables blob throughput to scale significantly, leading to even smaller fees for Layer 2s.

[Learn more about PeerDAS](/roadmap/fusaka/peerdas)

Alongside PeerDAS, [a small change](https://eips.ethereum.org/EIPS/eip-7918) that improves the blob fee market is being introduced. It ensures that the blob fee market reacts efficiently to congestion and doesn't spiral down to 1 wei, guaranteeing L2s pay a meaningful fee for the compute and space that blobs impose on nodes.

### What are Blob Parameter Only forks? {#what-are-blob-parameter-only-forks}
Copy link
Member

@wackerow wackerow Oct 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar here... is this a "frequently asked question" that isn't already specifically discussed in the dedicated BPO section above?

Copy link
Member Author

@taxmeifyoucan taxmeifyoucan Oct 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for many of these duplicates is that I originally intended this as a standalone FAQ page. But as we started FAQ section in here, I just added all in one page but let me know if you think it would make sense having separate. Otherwise happy to trim down the content, sorry about the redundancy

Copy link
Member

@wackerow wackerow Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay yeah, makes sense ❤️

I guess my general take on "FAQs" is we should first attempt to provide quality thought-out content to users that would cover as much as possible (which I think we've done a good job of through the rest of this page so far). Then, if there are particularly common questions that people ask where a concise answer could be provided, an FAQ can be handy to fill in those gaps, or concisely and more directly answer this frequent questions. I'd be cautious though of effectively using the FAQ approach for larger amounts of content.

Curious your take on these thoughts

Copy link
Member Author

@taxmeifyoucan taxmeifyoucan Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the input again! I removed some duplicate content and added missing piece on hardware. Feel free to edit it further down


[BPOs](https://eips.ethereum.org/EIPS/eip-7892) provide a mechanism to continuously increase the blob count (both target and max) after PeerDAS is activated, without having to wait for a full coordinated upgrade. Each increase is hardcoded to be pre-configured in client releases supporting Fusaka.

This means users and validators don’t need to update their clients for each BPO and only make sure to follow major hardforks like Fusaka. This is same practice as before, no special actions are needed to It is still recommended to monitor your clients around upgrades and BPOs and keep them update even between major releases as fixes or optimizations might follow the hardfork.

PeerDAS is a significant change to p2p communication and blob mechanism that needs to be introduced gradually to ensure liveness and performance of the network. Fusaka ships with safe initial blob count but with BPOs, developers created a commitment to each new scale of blob count without any extra overhead on coordination and node users.

## What is the BPO schedule? {#what-is-the-bpo-schedule}

The exact schedule of BPO updates is going to be determined with Fusaka releases. Follow [Protocol announcements](https://blog.ethereum.org/category/protocol) and release notes of your clients.

Example of how it might look like:

- Before Fusaka: Target 6, Max 9
- At Fusaka activation: Target 6, Max 9
- BPO1, few weeks after Fusaka activation: Target 10, Max 15, increasing by two thirds
- BPO2, few weeks after BPO1: Target 14, Max 21

### Will this lower fees on Ethereum (Layer 1) {#will-this-lower-gas}
This upgrade does not lower gas fees on L1, at least not directly. The main focus is more blob space for rollup data, therefore lowering fees on Layer 2. This might have some side effects on L1 fee market but no significant change is expected.

### As a staker, what do I need to do for the upgrade? {#as-a-staker-what-do-i-need-to-do-for-the-upgrade}

As with every network upgrade, make sure to update your clients to latest versions marked with Fusaka support. Follow updates in the mailing list and Protocol Announcements on [blog.ethereum.org](https://blog.ethereum.org/category/protocol) to get informed about releases.
To validate your setup before Fusaka gets activated on mainnet, you can run a validator on testnets. Fusaka has been [activated sooner on testnets](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) giving you more space to make sure everything works and report bugs. Testnet forks are also announced in the mailing list and blog.

### Does "Deterministic Proposer Lookahead" (EIP-7917) affect validators? {#does-7917-affect-validators}

This change doesn’t change how your validator client functions. However, it will provide more insight into the future of your validator duties. Make sure to update your monitoring tooling to keep up with new features.

### How does Fusaka affect bandwidth requirements for nodes? {#how-does-fusaka-affect-bandwidth-requirements-for-nodes}

PeerDAS makes a significant change in how nodes transmit blob data. All data is divided into pieces called columns across 128 subnets with nodes subscribing to only some of them. Regular nodes will only subscribe to only 16 subnets, providing custody for 1/8 of the full data. This means that with the same amount of blob data, the node bandwidth of downloading them would be 8 times smaller. The actual bandwidth requirements will depend on amount of blobs allowed in the network. At the moment of Fusaka activation, the blob target is the same as before but with PeerDAS, node operators can see a decrease in their network usage. As BPOs configure higher number of blobs in the network, the necessary bandwidth will increase up to values before Fusaka activation.

### What EVM changes are implemented? {#what-evm-changes-are-implemented}

Fusaka solidifies EVM with new minor changes and features.

- For security while scaling, a maximum size of a single transaction will be [limited to 16.7 million](https://eips.ethereum.org/EIPS/eip-7825) units of gas.
- [New opcode CLZ](https://eips.ethereum.org/EIPS/eip-7939), Count Leading Zeros, is added to EVM and will enable smart contract languages to perform certain operations more efficiently.
- [The cost ModExp precompile will be increased](https://eips.ethereum.org/EIPS/eip-7883), contracts using it will charge more gas for execution.

### How does new 16M gas limit affects contract developers? {#how-does-new-16m-gas-limit-affects-contract-developers}

Fusaka introduces a limit to [maximum size of a single transaction to 16.7 million](https://eips.ethereum.org/EIPS/eip-7825) (2^24) gas units. This is roughly the size of an average block before which makes it big enough to accommodate even complex transactions that would consume an entire block. This limit creates protection for clients, preventing potential DoS attacks in the future with higher block gas limit. The goal of scaling is to enable more transactions get into the blockchain without a single one consuming all the block.

Regular user transactions are far from reaching this limit. Certain edge cases like big and complex Defi operations, large smart contract deployements or batch transactions targeting multiple contracts might be affected by this change. These transaction will have to be divided into smaller ones or optimized in another way. Use simulation before submitting transactions that potentially reach the limit.

RPC method `eth_call` is not limited and will allow simulation of bigger transactions than the actual blockchain limit. The actual limit for RPC methods can be configured by the client operator to ensure prevent abuse.

### What CLZ means for developers? {#what-clz-means-for-developers}

EVM compilers like Solidity will implement and utilize the new function for counting zeroes under the hood. New contracts might benefit from gas savings if they rely on this sort of operations. Follow releases and feature announcement of the smart contract language for documentation on potential savings.

### Are there any changes for my existing smart contracts? {#what-clz-means-for-developers}

Fusaka has no direct affect that would break any existing contracts or change their behavior. Changes introduced to execution layer are made with backwards compatibility, however, always keep an eye on edge cases and potential impact.

[With the increased cost of ModExp precompil](https://eips.ethereum.org/EIPS/eip-7883), contracts that depend on it will charge more gas for execution. If your contract relies heavily on this and becomes more expensive for users, reconsider how it’s utilized.

Consider the [new 16.7 million limit](https://eips.ethereum.org/EIPS/eip-7825) if transactions executing your contracts might be reaching similar size.

## Further reading {#further-reading}

- [Ethereum roadmap](/roadmap/)
Expand Down