From f98071b1547444826a6dbf3fe6feb0c86963779b Mon Sep 17 00:00:00 2001 From: nixorokish Date: Tue, 26 Aug 2025 20:00:09 -0600 Subject: [PATCH 1/9] add fusaka index page and info --- public/content/roadmap/fusaka/index.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 public/content/roadmap/fusaka/index.md diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md new file mode 100644 index 00000000000..e69de29bb2d From 3b742e6d2b2dd30c6ee0e950e0e63ae9c7768b2b Mon Sep 17 00:00:00 2001 From: nixorokish Date: Tue, 26 Aug 2025 20:01:08 -0600 Subject: [PATCH 2/9] add fusaka index page and info --- public/content/roadmap/fusaka/index.md | 144 +++++++++++++++++++++++++ 1 file changed, 144 insertions(+) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index e69de29bb2d..6982c65a706 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -0,0 +1,144 @@ +--- +title: Fulu-Osaka (Fusaka) +description: Learn about the Fusaka protocol upgrade +lang: en +--- + +# Fusaka {#fusaka} + +The Fusaka network upgrade follows [Pectra](/roadmap/pectra/) and brings more new features and improves the experience for every Ethereum user and developer. The name consists of execution layer upgrade Osaka and consensus layer version named after the Fulu star. Both parts of Ethereum receive an upgrade that push Ethereum scaling, security and user experience to the future. + +This upgrade is planned for Q4 2025. + + +The Fusaka upgrade is only a single step in Ethereum's long-term development goals. Learn more about [the protocol roadmap](/roadmap/) and [previous upgrades](/history/). + + +## Improvements in Fusaka {#new-improvements} + +### Data availability & L2 scaling {#da-scaling} + +#### PeerDAS {#7594} + +Specification: https://eips.ethereum.org/EIPS/eip-7594 + +Resources: https://youtu.be/bONWd1x2TjQ?t=328 (dapplion on PeerDAS) + +This is the *headliner* of the Fusaka fork, the main feature added in this upgrade. L2s currently post their data to Ethereum in blobs, the ephemeral data type created specifically for L2s. Pre-Fusaka, every full node has to store every **byte of those blobs to ensure that the data exists. As blob throughput rises, having to download all of this data would be untenably resource-intensive. + +With [Data Availability Sampling](https://notes.ethereum.org/@fradamt/das-fork-choice) , instead of having to download all of the blob data, each node will sample just a portion. Blobs are uniformly randomly distributed across nodes in the network with each full node holding only 1/8th of the data, therefore enabling theoretical scale up to 8x. To ensure availability of the data, Any portion of the data can be reconstructed from any existing 50% of the whole with methods that drive down the probability of wrong or missing data to a cryptographically negligible level (~one in 10²⁰ to one in 10²⁴). + +This keeps hardware and bandwidth requirements for nodes tenable while enabling blob scaling resulting in more scale with smaller fees for L2s. + +In-depth: https://eprint.iacr.org/2024/1362.pdf + +#### Blob parameter only forks + +Specification: https://eips.ethereum.org/EIPS/eip-7892 + +L2s scale Ethereum - as their networks grow, they need to post more data to Ethereum. This means that Ethereum will need to increase the number of blobs available to them as time goes on. Although PeerDAS enables scaling blob data, it needs to be done in gradually and safely. + +Because Ethereum is code running on thousands of independent nodes that requirement agreement on the rules, you can’t just make changes like blob increases the way you deploy a website update. Any rule change must be a coordinated upgrade where every validator software upgrades at the same predetermined block. + +These coordinated upgrades generally include a lot of changes, require a lot of testing, and that takes time. In order to adapt faster to changing L2 blob needs, BPO-only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule. + +BPO-only forks can be set by clients. Between major ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These BPO-only forks can be configured at any time. + +#### Blob base-fee bounded by execution costs + +Specification: https://eips.ethereum.org/EIPS/eip-7918 + +Storybook explainer: https://notes.ethereum.org/@anderselowsson/AIG + +L2s pay two bills when they post data: the blob fee and the execution gas needed to verify those blobs. If execution gas dominates, the blob fee auction can spiral down to 1 wei and stop being a price signal. + +EIP-7918 pins a proportional reserve price under every blob. When the reserve is higher than the nominal blob base fee, the fee adjustment algorithm treats the block as over target and stops pushing the fee down and allows it increase normally. As a result: + +- the blob fee market always reacts to congestion +- L2s pay at least a meaningful slice of the compute they force on nodes +- base-fee spikes on the EL can no longer strand the blob fee at 1 wei + +### Gas limits, fees & DoS hardening + +#### Set upper bounds for MODEXP + +Specification: https://eips.ethereum.org/EIPS/eip-7823 + +Until now, the MODEXP precompile accepted numbers of virtually any size. That made it hard to test, easy to abuse, and risky for client stability. EIP-7823 puts a clear limit in place: each input number can be at most 8192 bits (1024 bytes) long. Anything bigger is rejected, the transaction’s gas is burned, and no state changes occur. It very comfortably covers real-world needs while removing the extreme cases that complicated gas limit planning and security reviews. This change provides more security and DoS protection without affecting user or developer experience. + +#### Transaction Gas Limit Cap + +Specification: https://eips.ethereum.org/EIPS/eip-7825 + +EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) adds a cap of 16,777,216 (2^24) gas per transaction. It’s proactive DoS hardening by bounding the worst-case cost of any single transaction as we raise the block gas limit. It makes validation and propagation easier to model to allow us to tackle scaling via raising the gas limit. + +Why exactly 2^24 gas? It’s comfortably smaller than today’s gas limit, is large enough for real contract deployments & heavy precompiles, and a power of 2 makes it easy to implement across clients. This new maximum transaction size is a similar to pre-Pectra average block size, making it a reasonable limit for any operation on Ethereum. + +#### MODEXP Gas Cost Increase + +Specification: https://eips.ethereum.org/EIPS/eip-7883 + +MODEXP is a precompile built‑in function that calculates modular exponentiation, a type of large‑number math used in RSA signature verification and proof systems. It allows contracts to run these calculations directly without having to implement them themselves. + +Devs and client teams identified MODEXP as a major obstacle to increasing the block gas limit because the current gas pricing often underestimates how much computing power certain inputs require. This means one transaction using MODEXP could take up most of the time needed to process an entire block, slowing down the network. + +EIP‑7883 changes the pricing to match real computational costs by: + +- raising the minimum charge from 200 to 500 gas and removing the one‑third discount from EIP-2565 on the general cost calculation +- increasing the cost more sharply when the exponent input is very long. if the exponent (the “power” number you pass as the second argument) is longer than 32 bytes / 256 bits, the gas charge climbs much faster for each extra byte +- charging large base or modulus extra as well. The other two numbers (the base and the modulus) are assumed to be at least 32 bytes - if either one is bigger, the cost rises in proportion to its size + +By better matching costs to actual processing time, MODEXP can no longer cause a block to take too long to validate. This change is one of several aimed at making it safe to increase Ethereum’s block gas limit in the future. + +#### RLP Execution Block Size Limit + +Specification: https://eips.ethereum.org/EIPS/eip-7934 + +Ethereum adds a hard cap on the [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)-encoded execution block size: 10 MiB total, with a 2 MiB safety margin reserved for beacon-block framing. Practically, clients define `MAX_BLOCK_SIZE = 10,485,760` bytes and `SAFETY_MARGIN = 2,097,152` bytes, and reject any execution block whose RLP payload exceeds `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`. The goal is to bound worst-case propagation/validation time and align with CL gossip behavior (blocks over ~10 MiB aren’t propagated), reducing reorg/DoS risk without changing gas accounting. + +#### Set default gas limit to XX million + +Specification: https://eips.ethereum.org/EIPS/eip-7935 + +Prior to raising the gas limit from 30M to 36M in Feb 2025 (and subsequently to 45M), this value hadn’t changed since the Merge (Sep 2022). This EIP aims to make consistent scaling a priority. + +EIP-7935 coordinates EL client teams to raise the default gas-limit above today’s 45M for Fusaka. It’s an Informational EIP, but it explicitly asks clients to test higher limits on devnets, converge on a safe value, and ship that number in their Fusaka releases. + +Devnet planning targets ~60M stress (full blocks with synthetic load) and iterative bumps; research says worst-case block-size pathologies shouldn’t bind below ~150M. Rollout should be paired with the transaction gas-limit cap (EIP-7825) so no single transaction can dominate as limits rise. + +### Preconfirmation support + +#### Deterministic proposer lookahead + +Specification: https://eips.ethereum.org/EIPS/eip-7917 + +With EIP-7917, Beacon Chain will become aware of upcoming block proposers for next epoch. Having a deterministic view on which validators will be propose future blocks can enable [preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353) - a commitment with upcoming proposer that guarantees the user transaction will be included in their block without waiting for the actual block. + +This feature benefits client implementations and security of the network as it prevents edge cases where validators could manipulate the proposer schedule. The lookahead also allows for less complexity of the implementation. + +### Opcodes & precompiles (developer goodies) + +#### Count leading zeros (CLZ) opcode + +Specification: https://eips.ethereum.org/EIPS/eip-7939 + +EIP-7939 adds a small EVM instruction, CLZ (“count leading zeros”). Given a 256-bit value, it returns how many zero bits are at the front — and returns 256 if the value is entirely zero. This is a common feature in many instruction set architectures as it enables more efficient arithmetic operations. In practice this collapses today’s hand-rolled bit scans into one step, so finding the first set bit, scanning bytes, or parsing bitfields becomes simpler and cheaper. The opcode is low, fixed-cost and has been benchmarked to be on par with a basic add, which trims bytecode and saves gas for the same work. + + +## Does this upgrade affect all Ethereum nodes and validators? {#client-impact} + +Yes, the Fusaka upgrade requires updates to both [execution clients and consensus clients](/developers/docs/nodes-and-clients/). All main Ethereum clients will release versions supporting the hard fork marked as high priority. You can keep up with when these releases will be available in client Github repos, their [Discord channels](https://ethstaker.org/support), the [EthStaker Discord](https://dsc.gg/ethstaker), or by subscribing to the Ethereum blog for protocol updates. To maintain synchronization with the Ethereum network post-upgrade, node operators must ensure they are running a supported client version. Note that the information about client releases is time-sensitive, and users should refer to the latest updates for the most current details. + +## How can ETH be converted after the hard fork? {#scam-alert} + +- **No Action Required for Your ETH**: Following the Ethereum Fusaka upgrade, there is no need to convert or upgrade your ETH. Your account balances will remain the same, and the ETH you currently hold will remain accessible in its existing form after the hard fork. +- **Beware of Scams!**  **anyone instructing you to "upgrade" your ETH is trying to scam you.** There is nothing you need to do in relation to this upgrade. Your assets will stay completely unaffected. Remember, staying informed is the best defense against scams. + +[More on recognizing and avoiding scams](/security/) + +## Further reading {#further-reading} + +- [Ethereum roadmap](/roadmap/) +- [Forkcast: Fusaka](https://forkcast.org/upgrade/fusaka) +- [Fusaka Meta EIP](https://eips.ethereum.org/EIPS/eip-7607) +- [Bankless: What Fusaka & Pectra will bring Ethereum](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) From 1f9d8b7176ff6174922d1a1a1c2eb4bac4df13f8 Mon Sep 17 00:00:00 2001 From: nixorokish Date: Tue, 26 Aug 2025 20:15:34 -0600 Subject: [PATCH 3/9] add resource --- public/content/roadmap/fusaka/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index 6982c65a706..c96fedf1f25 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -142,3 +142,4 @@ Yes, the Fusaka upgrade requires updates to both [execution clients and consensu - [Forkcast: Fusaka](https://forkcast.org/upgrade/fusaka) - [Fusaka Meta EIP](https://eips.ethereum.org/EIPS/eip-7607) - [Bankless: What Fusaka & Pectra will bring Ethereum](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) +- [Bankless: Ethereum's Next Upgrades: Fusaka, Glamsterdam & Beyond with Preston Van Loon](https://x.com/BanklessHQ/status/1956017743289020633?t=502) From 458331a984a7f8d955ee8538e02debfeb66c94ca Mon Sep 17 00:00:00 2001 From: nixo Date: Thu, 28 Aug 2025 11:41:28 -0600 Subject: [PATCH 4/9] Update public/content/roadmap/fusaka/index.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Mário Havel <61149543+taxmeifyoucan@users.noreply.github.com> --- public/content/roadmap/fusaka/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index c96fedf1f25..85fafb949c3 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -6,7 +6,7 @@ lang: en # Fusaka {#fusaka} -The Fusaka network upgrade follows [Pectra](/roadmap/pectra/) and brings more new features and improves the experience for every Ethereum user and developer. The name consists of execution layer upgrade Osaka and consensus layer version named after the Fulu star. Both parts of Ethereum receive an upgrade that push Ethereum scaling, security and user experience to the future. +The Fusaka network upgrade follows [Pectra](/roadmap/pectra/) and brings more new features and improves the experience for every Ethereum user and developer. The name consists of the execution layer upgrade Osaka and the consensus layer version named after the Fulu star. Both parts of Ethereum receive an upgrade that pushes Ethereum scaling, security and user experience to the future. This upgrade is planned for Q4 2025. From b85ca365528a80649bddcb23c206f239e8437e1e Mon Sep 17 00:00:00 2001 From: nixo Date: Thu, 28 Aug 2025 11:43:56 -0600 Subject: [PATCH 5/9] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Mário Havel <61149543+taxmeifyoucan@users.noreply.github.com> --- public/content/roadmap/fusaka/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index 85fafb949c3..eb1bd38432c 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -38,11 +38,11 @@ Specification: https://eips.ethereum.org/EIPS/eip-7892 L2s scale Ethereum - as their networks grow, they need to post more data to Ethereum. This means that Ethereum will need to increase the number of blobs available to them as time goes on. Although PeerDAS enables scaling blob data, it needs to be done in gradually and safely. -Because Ethereum is code running on thousands of independent nodes that requirement agreement on the rules, you can’t just make changes like blob increases the way you deploy a website update. Any rule change must be a coordinated upgrade where every validator software upgrades at the same predetermined block. +Because Ethereum is code running on thousands of independent nodes that require agreement on same rules, we cannot simply introduces changes like increasing blob count the way you deploy a website update. Any rule change must be a coordinated upgrade where every node, client and validator software upgrades before the same predetermined block. These coordinated upgrades generally include a lot of changes, require a lot of testing, and that takes time. In order to adapt faster to changing L2 blob needs, BPO-only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule. -BPO-only forks can be set by clients. Between major ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These BPO-only forks can be configured at any time. +BPO-only forks can be set by clients, similarly to other configuration like gas limit. Between major Ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These BPO-only forks can be configured at any time. #### Blob base-fee bounded by execution costs @@ -112,7 +112,7 @@ Devnet planning targets ~60M stress (full blocks with synthetic load) and iterat Specification: https://eips.ethereum.org/EIPS/eip-7917 -With EIP-7917, Beacon Chain will become aware of upcoming block proposers for next epoch. Having a deterministic view on which validators will be propose future blocks can enable [preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353) - a commitment with upcoming proposer that guarantees the user transaction will be included in their block without waiting for the actual block. +With EIP-7917, Beacon Chain will become aware of upcoming block proposers for the next epoch. Having a deterministic view on which validators will be proposing future blocks can enable [preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353) - a commitment with the upcoming proposer that guarantees the user transaction will be included in their block without waiting for the actual block. This feature benefits client implementations and security of the network as it prevents edge cases where validators could manipulate the proposer schedule. The lookahead also allows for less complexity of the implementation. From 41172562c062c545745344b37f6e34ec55ff24a4 Mon Sep 17 00:00:00 2001 From: Corwin Smith Date: Thu, 28 Aug 2025 12:48:36 -0600 Subject: [PATCH 6/9] Add to releases data for fusaka --- src/data/roadmap/releases.tsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/roadmap/releases.tsx b/src/data/roadmap/releases.tsx index 70d57f6ffc5..06c695ae073 100644 --- a/src/data/roadmap/releases.tsx +++ b/src/data/roadmap/releases.tsx @@ -189,7 +189,7 @@ export const releasesData: Release[] = [ ), - href: "https://eips.ethereum.org/EIPS/eip-7607", + href: "/roadmap/fusaka", }, { image: GuidesHubHeroImage, From 60336050a1864f5e32fd3aedb61c86f1fd0c58dd Mon Sep 17 00:00:00 2001 From: Corwin Smith Date: Thu, 28 Aug 2025 13:06:47 -0600 Subject: [PATCH 7/9] header ids --- public/content/roadmap/fusaka/index.md | 34 +++++++++++++------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index eb1bd38432c..581debdfb21 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -14,11 +14,11 @@ This upgrade is planned for Q4 2025. The Fusaka upgrade is only a single step in Ethereum's long-term development goals. Learn more about [the protocol roadmap](/roadmap/) and [previous upgrades](/history/). -## Improvements in Fusaka {#new-improvements} +## Improvements in Fusaka {#improvements-in-fusaka} -### Data availability & L2 scaling {#da-scaling} +### Data availability & L2 scaling {#data-availability-and-l2-scaling} -#### PeerDAS {#7594} +#### PeerDAS {#peerdas} Specification: https://eips.ethereum.org/EIPS/eip-7594 @@ -32,7 +32,7 @@ This keeps hardware and bandwidth requirements for nodes tenable while enabling In-depth: https://eprint.iacr.org/2024/1362.pdf -#### Blob parameter only forks +#### Blob parameter only forks {#blob-parameter-only-forks} Specification: https://eips.ethereum.org/EIPS/eip-7892 @@ -44,7 +44,7 @@ These coordinated upgrades generally include a lot of changes, require a lot of BPO-only forks can be set by clients, similarly to other configuration like gas limit. Between major Ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These BPO-only forks can be configured at any time. -#### Blob base-fee bounded by execution costs +#### Blob base-fee bounded by execution costs {#blob-base-fee-bounded-by-execution-costs} Specification: https://eips.ethereum.org/EIPS/eip-7918 @@ -58,15 +58,15 @@ EIP-7918 pins a proportional reserve price under every blob. When the reserve is - L2s pay at least a meaningful slice of the compute they force on nodes - base-fee spikes on the EL can no longer strand the blob fee at 1 wei -### Gas limits, fees & DoS hardening +### Gas limits, fees & DoS hardening {#gas-limits-fees-and-dos-hardening} -#### Set upper bounds for MODEXP +#### Set upper bounds for MODEXP {#set-upper-bounds-for-modexp} Specification: https://eips.ethereum.org/EIPS/eip-7823 Until now, the MODEXP precompile accepted numbers of virtually any size. That made it hard to test, easy to abuse, and risky for client stability. EIP-7823 puts a clear limit in place: each input number can be at most 8192 bits (1024 bytes) long. Anything bigger is rejected, the transaction’s gas is burned, and no state changes occur. It very comfortably covers real-world needs while removing the extreme cases that complicated gas limit planning and security reviews. This change provides more security and DoS protection without affecting user or developer experience. -#### Transaction Gas Limit Cap +#### Transaction Gas Limit Cap {#transaction-gas-limit-cap} Specification: https://eips.ethereum.org/EIPS/eip-7825 @@ -74,7 +74,7 @@ EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) adds a cap of 16,777,216 (2^ Why exactly 2^24 gas? It’s comfortably smaller than today’s gas limit, is large enough for real contract deployments & heavy precompiles, and a power of 2 makes it easy to implement across clients. This new maximum transaction size is a similar to pre-Pectra average block size, making it a reasonable limit for any operation on Ethereum. -#### MODEXP Gas Cost Increase +#### MODEXP Gas Cost Increase {#modexp-gas-cost-increase} Specification: https://eips.ethereum.org/EIPS/eip-7883 @@ -90,13 +90,13 @@ EIP‑7883 changes the pricing to match real computational costs by: By better matching costs to actual processing time, MODEXP can no longer cause a block to take too long to validate. This change is one of several aimed at making it safe to increase Ethereum’s block gas limit in the future. -#### RLP Execution Block Size Limit +#### RLP Execution Block Size Limit {#rlp-execution-block-size-limit} Specification: https://eips.ethereum.org/EIPS/eip-7934 Ethereum adds a hard cap on the [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)-encoded execution block size: 10 MiB total, with a 2 MiB safety margin reserved for beacon-block framing. Practically, clients define `MAX_BLOCK_SIZE = 10,485,760` bytes and `SAFETY_MARGIN = 2,097,152` bytes, and reject any execution block whose RLP payload exceeds `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`. The goal is to bound worst-case propagation/validation time and align with CL gossip behavior (blocks over ~10 MiB aren’t propagated), reducing reorg/DoS risk without changing gas accounting. -#### Set default gas limit to XX million +#### Set default gas limit to XX million {#set-default-gas-limit-to-xx-million} Specification: https://eips.ethereum.org/EIPS/eip-7935 @@ -106,9 +106,9 @@ EIP-7935 coordinates EL client teams to raise the default gas-limit above today Devnet planning targets ~60M stress (full blocks with synthetic load) and iterative bumps; research says worst-case block-size pathologies shouldn’t bind below ~150M. Rollout should be paired with the transaction gas-limit cap (EIP-7825) so no single transaction can dominate as limits rise. -### Preconfirmation support +### Preconfirmation support {#preconfirmation-support} -#### Deterministic proposer lookahead +#### Deterministic proposer lookahead {#deterministic-proposer-lookahead} Specification: https://eips.ethereum.org/EIPS/eip-7917 @@ -116,20 +116,20 @@ With EIP-7917, Beacon Chain will become aware of upcoming block proposers for th This feature benefits client implementations and security of the network as it prevents edge cases where validators could manipulate the proposer schedule. The lookahead also allows for less complexity of the implementation. -### Opcodes & precompiles (developer goodies) +### Opcodes & precompiles (developer goodies) {#opcodes-and-precomliles} -#### Count leading zeros (CLZ) opcode +#### Count leading zeros (CLZ) opcode {#count-leading-zeros-opcode} Specification: https://eips.ethereum.org/EIPS/eip-7939 EIP-7939 adds a small EVM instruction, CLZ (“count leading zeros”). Given a 256-bit value, it returns how many zero bits are at the front — and returns 256 if the value is entirely zero. This is a common feature in many instruction set architectures as it enables more efficient arithmetic operations. In practice this collapses today’s hand-rolled bit scans into one step, so finding the first set bit, scanning bytes, or parsing bitfields becomes simpler and cheaper. The opcode is low, fixed-cost and has been benchmarked to be on par with a basic add, which trims bytecode and saves gas for the same work. -## Does this upgrade affect all Ethereum nodes and validators? {#client-impact} +## Does this upgrade affect all Ethereum nodes and validators? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} Yes, the Fusaka upgrade requires updates to both [execution clients and consensus clients](/developers/docs/nodes-and-clients/). All main Ethereum clients will release versions supporting the hard fork marked as high priority. You can keep up with when these releases will be available in client Github repos, their [Discord channels](https://ethstaker.org/support), the [EthStaker Discord](https://dsc.gg/ethstaker), or by subscribing to the Ethereum blog for protocol updates. To maintain synchronization with the Ethereum network post-upgrade, node operators must ensure they are running a supported client version. Note that the information about client releases is time-sensitive, and users should refer to the latest updates for the most current details. -## How can ETH be converted after the hard fork? {#scam-alert} +## How can ETH be converted after the hard fork? {#how-can-eth-be-converted-after-the-hardfork} - **No Action Required for Your ETH**: Following the Ethereum Fusaka upgrade, there is no need to convert or upgrade your ETH. Your account balances will remain the same, and the ETH you currently hold will remain accessible in its existing form after the hard fork. - **Beware of Scams!**  **anyone instructing you to "upgrade" your ETH is trying to scam you.** There is nothing you need to do in relation to this upgrade. Your assets will stay completely unaffected. Remember, staying informed is the best defense against scams. From 82d792b8907141e428d044dabfc4961e5fe13b36 Mon Sep 17 00:00:00 2001 From: Corwin Smith Date: Thu, 28 Aug 2025 14:32:50 -0600 Subject: [PATCH 8/9] fusaka highlight content --- src/data/roadmap/releases.tsx | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/data/roadmap/releases.tsx b/src/data/roadmap/releases.tsx index 06c695ae073..2ac32ea92f3 100644 --- a/src/data/roadmap/releases.tsx +++ b/src/data/roadmap/releases.tsx @@ -179,14 +179,19 @@ export const releasesData: Release[] = [ decentralization -

Potential Additional Features

+

Blob Parameter Only (BPO) Forks

    -
  • Support for secure enclaves on mobile devices to improve UX
    • -
  • Blob fee market improvements
    • +
  • Allows flexible blob count increases between major upgrades
  • - Further improvements to validator efficiency and network performance + Enables faster adaptation to L2 scaling needs without waiting for + coordinated hard forks
+

Gas Limit & DoS Hardening

+
    +
  • Transaction gas limit cap of 16.7M gas per transaction
    • +
  • Default gas limit increase to ~60M (from current 45M)
    • +
), href: "/roadmap/fusaka", From 218a9861307c5066d1c7b52fd0453a78e973cdca Mon Sep 17 00:00:00 2001 From: nixo Date: Thu, 28 Aug 2025 14:35:20 -0600 Subject: [PATCH 9/9] Apply suggestions from code review lgtm! tysm for reviewing! Co-authored-by: Corwin Smith --- public/content/roadmap/fusaka/index.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/public/content/roadmap/fusaka/index.md b/public/content/roadmap/fusaka/index.md index 581debdfb21..52d522a1f94 100644 --- a/public/content/roadmap/fusaka/index.md +++ b/public/content/roadmap/fusaka/index.md @@ -24,11 +24,11 @@ Specification: https://eips.ethereum.org/EIPS/eip-7594 Resources: https://youtu.be/bONWd1x2TjQ?t=328 (dapplion on PeerDAS) -This is the *headliner* of the Fusaka fork, the main feature added in this upgrade. L2s currently post their data to Ethereum in blobs, the ephemeral data type created specifically for L2s. Pre-Fusaka, every full node has to store every **byte of those blobs to ensure that the data exists. As blob throughput rises, having to download all of this data would be untenably resource-intensive. +This is the *headliner* of the Fusaka fork, the main feature added in this upgrade. Layer 2s currently post their data to Ethereum in blobs, the ephemeral data type created specifically for layer 2s. Pre-Fusaka, every full node has to store every blob to ensure that the data exists. As blob throughput rises, having to download all of this data becomes untenably resource-intensive. -With [Data Availability Sampling](https://notes.ethereum.org/@fradamt/das-fork-choice) , instead of having to download all of the blob data, each node will sample just a portion. Blobs are uniformly randomly distributed across nodes in the network with each full node holding only 1/8th of the data, therefore enabling theoretical scale up to 8x. To ensure availability of the data, Any portion of the data can be reconstructed from any existing 50% of the whole with methods that drive down the probability of wrong or missing data to a cryptographically negligible level (~one in 10²⁰ to one in 10²⁴). +With [data availability sampling](https://notes.ethereum.org/@fradamt/das-fork-choice) , instead of having to store all of the blob data, each node will be responsible for a subset of the blob data. Blobs are uniformly randomly distributed across nodes in the network with each full node holding only 1/8th of the data, therefore enabling theoretical scale up to 8x. To ensure availability of the data, any portion of the data can be reconstructed from any existing 50% of the whole with methods that drive down the probability of wrong or missing data to a cryptographically negligible level (~one in 10²⁰ to one in 10²⁴). -This keeps hardware and bandwidth requirements for nodes tenable while enabling blob scaling resulting in more scale with smaller fees for L2s. +This keeps hardware and bandwidth requirements for nodes tenable while enabling blob scaling resulting in more scale with smaller fees for layer 2s. In-depth: https://eprint.iacr.org/2024/1362.pdf @@ -36,13 +36,13 @@ In-depth: https://eprint.iacr.org/2024/1362.pdf Specification: https://eips.ethereum.org/EIPS/eip-7892 -L2s scale Ethereum - as their networks grow, they need to post more data to Ethereum. This means that Ethereum will need to increase the number of blobs available to them as time goes on. Although PeerDAS enables scaling blob data, it needs to be done in gradually and safely. +Layer 2s scale Ethereum - as their networks grow, they need to post more data to Ethereum. This means that Ethereum will need to increase the number of blobs available to them as time goes on. Although PeerDAS enables scaling blob data, it needs to be done gradually and safely. Because Ethereum is code running on thousands of independent nodes that require agreement on same rules, we cannot simply introduces changes like increasing blob count the way you deploy a website update. Any rule change must be a coordinated upgrade where every node, client and validator software upgrades before the same predetermined block. -These coordinated upgrades generally include a lot of changes, require a lot of testing, and that takes time. In order to adapt faster to changing L2 blob needs, BPO-only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule. +These coordinated upgrades generally include a lot of changes, require a lot of testing, and that takes time. In order to adapt faster to changing layer 2 blob needs, blob paramter only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule. -BPO-only forks can be set by clients, similarly to other configuration like gas limit. Between major Ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These BPO-only forks can be configured at any time. +Blob parameter only forks can be set by clients, similarly to other configuration like gas limit. Between major Ethereum upgrades, clients can agree to increase the `target` and `max` blobs to e.g. 9 and 12 and then node operators will update to take part in that tiny fork. These blob parameter only forks can be configured at any time. #### Blob base-fee bounded by execution costs {#blob-base-fee-bounded-by-execution-costs} @@ -50,12 +50,12 @@ Specification: https://eips.ethereum.org/EIPS/eip-7918 Storybook explainer: https://notes.ethereum.org/@anderselowsson/AIG -L2s pay two bills when they post data: the blob fee and the execution gas needed to verify those blobs. If execution gas dominates, the blob fee auction can spiral down to 1 wei and stop being a price signal. +Layer 2s pay two bills when they post data: the blob fee and the execution gas needed to verify those blobs. If execution gas dominates, the blob fee auction can spiral down to 1 wei and stop being a price signal. EIP-7918 pins a proportional reserve price under every blob. When the reserve is higher than the nominal blob base fee, the fee adjustment algorithm treats the block as over target and stops pushing the fee down and allows it increase normally. As a result: - the blob fee market always reacts to congestion -- L2s pay at least a meaningful slice of the compute they force on nodes +- layer 2s pay at least a meaningful slice of the compute they force on nodes - base-fee spikes on the EL can no longer strand the blob fee at 1 wei ### Gas limits, fees & DoS hardening {#gas-limits-fees-and-dos-hardening} @@ -94,13 +94,13 @@ By better matching costs to actual processing time, MODEXP can no longer cause a Specification: https://eips.ethereum.org/EIPS/eip-7934 -Ethereum adds a hard cap on the [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)-encoded execution block size: 10 MiB total, with a 2 MiB safety margin reserved for beacon-block framing. Practically, clients define `MAX_BLOCK_SIZE = 10,485,760` bytes and `SAFETY_MARGIN = 2,097,152` bytes, and reject any execution block whose RLP payload exceeds `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`. The goal is to bound worst-case propagation/validation time and align with CL gossip behavior (blocks over ~10 MiB aren’t propagated), reducing reorg/DoS risk without changing gas accounting. +Ethereum adds a hard cap on the [RLP](/developers/docs/data-structures-and-encoding/rlp/)-encoded execution block size: 10 MiB total, with a 2 MiB safety margin reserved for beacon-block framing. Practically, clients define `MAX_BLOCK_SIZE = 10,485,760` bytes and `SAFETY_MARGIN = 2,097,152` bytes, and reject any execution block whose RLP payload exceeds `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`. The goal is to bound worst-case propagation/validation time and align with CL gossip behavior (blocks over ~10 MiB aren’t propagated), reducing reorg/DoS risk without changing gas accounting. #### Set default gas limit to XX million {#set-default-gas-limit-to-xx-million} Specification: https://eips.ethereum.org/EIPS/eip-7935 -Prior to raising the gas limit from 30M to 36M in Feb 2025 (and subsequently to 45M), this value hadn’t changed since the Merge (Sep 2022). This EIP aims to make consistent scaling a priority. +Prior to raising the gas limit from 30M to 36M in February 2025 (and subsequently to 45M), this value hadn’t changed since the Merge (September 2022). This EIP aims to make consistent scaling a priority. EIP-7935 coordinates EL client teams to raise the default gas-limit above today’s 45M for Fusaka. It’s an Informational EIP, but it explicitly asks clients to test higher limits on devnets, converge on a safe value, and ship that number in their Fusaka releases.