ethereum · wackerow · Sep 27, 2025 · Sep 25, 2025 · Sep 26, 2025
@@ -37,7 +37,7 @@ This keeps hardware and bandwidth requirements for nodes tenable while enabling
 
 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.
+Because Ethereum is code running on thousands of independent nodes that require agreement on same rules, we cannot simply introduce 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 layer 2 blob needs, blob parameter only forks introduce a mechanism to increase blobs without having to wait on that upgrade schedule.
 
@@ -55,7 +55,7 @@ Graph source: [Ethereum Blobs - @hildobby, Dune Analytics](https://dune.com/hild
 
 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:
+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 to increase normally. As a result:
 
 - the blob fee market always reacts to congestion
 - layer 2s pay at least a meaningful slice of the compute they force on nodes
@@ -86,7 +86,7 @@ Until now, the MODEXP precompile accepted numbers of virtually any size. That ma
 
 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.
+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 similar to pre-Pectra average block size, making it a reasonable limit for any operation on Ethereum.
 
 **Resources**: [EIP-7825 technical specification](https://eips.ethereum.org/EIPS/eip-7825)
 
@@ -125,7 +125,7 @@ The goal is to bound worst-case propagation/validation time and align with conse
 
 **Resources**: [EIP-7934 technical specification](https://eips.ethereum.org/EIPS/eip-7934)
 
-#### Set default gas limit to XX million {#set-default-gas-limit-to-xx-million}
+#### Set default gas limit to 60 million {#set-default-gas-limit-to-60-million}
 
 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.
 
@@ -147,7 +147,7 @@ This feature benefits client implementations and security of the network as it p
 
 #### Count leading zeros (CLZ) opcode {#count-leading-zeros-opcode}
 
-This feature adds a small EVM instruction, **count leading zeroes (CLZ)**. Most everything in the EVM is represented as a 256-bit value—this new opcode returns how many zero bits are at the front. 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.
+This feature adds a small EVM instruction, **count leading zeros (CLZ)**. Most everything in the EVM is represented as a 256-bit value—this new opcode returns how many zero bits are at the front. 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.
 
 **Resources**: [EIP-7939 technical specification](https://eips.ethereum.org/EIPS/eip-7939)
 
@@ -177,7 +177,7 @@ This EIP is in a section apart from the "Core EIPs" because the fork doesn't act
 
 **Resources**: [EIP-7910 technical specification](https://eips.ethereum.org/EIPS/eip-7910)
 
-## FAQ {#FAQ}
+## FAQ {#faq}
 
 ### Does this upgrade affect all Ethereum nodes and validators? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators}
 
@@ -195,5 +195,6 @@ Yes, the Fusaka upgrade requires updates to both [execution clients and consensu
 - [Ethereum roadmap](/roadmap/)
 - [Forkcast: Fusaka](https://forkcast.org/upgrade/fusaka)
 - [Fusaka Meta EIP](https://eips.ethereum.org/EIPS/eip-7607)
+- [Fusaka testnet blog announcement](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)
 - [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)
@@ -80,6 +80,7 @@ PeerDAS is only a step [toward a greater scaling vision of FullDAS](https://ethr
 
 ## Further reading {#further-reading}
 
-- [PeerDAS Peer Data Availability sampling by Francesco D'Amato](https://www.youtube.com/watch?v=WOdpO1tH_Us)
+- [PeerDAS: Peer Data Availability sampling by Francesco D'Amato](https://www.youtube.com/watch?v=WOdpO1tH_Us)
 - [A Documentation of Ethereum’s PeerDAS](https://eprint.iacr.org/2024/1362.pdf)
 - [Proving the Security of PeerDAS without the AGM](https://eprint.iacr.org/2025/1683)
+- [Vitalik on PeerDAS, its impact, and testing Fusaka](https://x.com/VitalikButerin/status/1970983281090085200)