Ethereum after Fusaka: abundant blobspace changes the scaling question
Lead illustration — PeerDAS replaces “every node downloads everything” with a distributed, verifiable data-availability system.
Research date: 5 October 2026 (UTC)
Executive summary
Ethereum’s most important scaling achievement of the past year is not a single headline transaction-per-second number. It is a change in the system’s constraint. Since the Fusaka upgrade activated on 3 December 2025, Peer Data Availability Sampling (PeerDAS) has allowed ordinary nodes to verify that rollup data exists without each node downloading every blob in full. Two subsequent Blob-Parameter-Only upgrades raised the operating target from six blobs per block before Fusaka to 14, with a maximum of 21. That is a 2.3-fold increase in target data capacity, delivered without a second general-purpose hard fork.
The early demand signal is substantial. Growthepie’s daily dataset reported that Ethereum L2s processed 29.31 million transactions in the latest completed day and 208.66 million over seven days as of 5 October, with Base accounting for 6.55 million daily transactions, or 22% of the tracked L2 total. L2BEAT, using a different methodology focused on data publication, reported roughly 12.33 GiB posted across public data-availability layers over the past day and about $35.05 billion secured by Ethereum data availability. These measurements are snapshots, not eternal facts, but together they show that blobspace supports a large and economically meaningful execution layer above Ethereum.
The investment and governance conclusion is more nuanced than “more blobs mean cheaper L2s.” Fusaka turned a hard per-node bandwidth ceiling into a managed control loop. Capacity can now rise incrementally through BPO forks, while developers watch utilization, propagation, client performance and fee-market behavior. The scarce resource therefore shifts from raw data bytes toward credible operational governance: deciding when to add capacity, ensuring the node set remains diverse, and preserving an informative price signal.
This report’s thesis is that post-Fusaka Ethereum should be judged on three linked outcomes: whether demand fills the new capacity with useful activity; whether fees remain low without becoming economically meaningless; and whether sampling keeps home-node participation viable as total throughput grows. PeerDAS creates room for success. It does not, by itself, guarantee any of those outcomes.
What changed: verification without universal replication
Dencun’s EIP-4844 introduced blobs in March 2024. Blobs are temporary data objects designed for rollups: a rollup executes transactions away from Ethereum mainnet, compresses the results, and publishes enough data to Ethereum for others to reconstruct and verify the rollup state. This was cheaper than competing with ordinary L1 execution for calldata, but it retained a scaling problem. Every full node still downloaded every blob. Raising the blob count therefore raised the bandwidth burden for every node.
Fusaka’s headline feature, EIP-7594 / PeerDAS, changes that architecture. Blob data is erasure-coded, extended with redundancy, and divided into 128 columns. A regular node subscribes to a randomized subset of column subnets; Ethereum’s explanation says the default node receives 8 of 128 extended-data columns, equivalent to one-eighth of the original data volume. KZG commitments let the node verify that sampled pieces correspond to the committed blob. If at least half of the extended data remains available, the original can be reconstructed. Validators incorporate availability into fork choice rather than treating it as an optional afterthought.
flowchart LR
U[Users transact on L2] --> S[Sequencer orders and compresses]
S --> B[Blob submitted to Ethereum]
B --> E[Erasure coding extends data]
E --> C[128 column subnets]
C --> N1[Ordinary nodes custody samples]
C --> N2[Other nodes custody different samples]
C --> SN[Supernodes custody all columns]
N1 --> V[Verify against KZG commitment]
N2 --> V
SN --> R[Reconstruct and repair gaps]
V --> F[Validators accept available block]
R --> FThis is a division of labor, not a relaxation of the availability requirement. The security claim is probabilistic at the level of an individual sample but reinforced across a large, randomly distributed node population. Ethereum’s PeerDAS overview describes an availability-failure probability on the order of one in 10²⁰ to one in 10²⁴ under its assumptions. The important caveat is “under its assumptions”: randomness, peer diversity, client correctness and sufficient honest storage all matter.
Capacity became a policy variable
PeerDAS’s theoretical ceiling was never intended to arrive in one jump. The Ethereum Foundation’s blob-scaling roadmap described a path from six blobs per block toward a theoretical 48, while emphasizing staged increases and network observation. Fusaka added BPO forks, which can change blob targets and maxima on a pre-scheduled basis without bundling unrelated execution and consensus changes into a major upgrade.
The first two BPO steps moved the target/max pair from 6/9 at Fusaka activation, to 10/15, and then to 14/21 in early January 2026. The Foundation’s January 2026 protocol checkpoint said both stress-tested steps activated successfully and that a third increase was not a priority until usage rose into the available capacity. This is a revealing governance choice. Engineering capability established an upper envelope; observed demand determines whether the network should approach it.
Editorial diagram — BPOs make scaling iterative: supply is raised, real demand and pricing respond, and node health informs the next step.
flowchart TD
A[Measure sustained blob demand] --> B{Near target often enough?}
B -- No --> C[Hold parameters and observe]
B -- Yes --> D[Review propagation and client health]
D --> E{Safety margins intact?}
E -- No --> F[Optimize networking or pause increase]
E -- Yes --> G[Schedule tested BPO step]
G --> H[Higher target and maximum]
H --> I[Fee market and rollups adapt]
I --> A
C --> A
F --> AThe control-loop framing is more accurate than treating 48 blobs as promised capacity. BPOs reduce coordination overhead, but they do not remove judgment. Higher limits expand throughput only if builders include the data, peers propagate it reliably, clients process it within slot timing, and rollups generate demand. A target is also not a guaranteed occupancy level: it is the point around which the blob base-fee mechanism adjusts.
Evidence of demand—and limits of the evidence
Activity above Ethereum is already much larger than activity visible on L1 alone. Growthepie’s live L2 transaction page reported 3,023 live transactions per second, 29.31 million transactions over the latest completed day, 208.66 million over seven days, and 983.90 million over 30 days on 5 October. Its daily universe covered 25 curated L2s, while its live feed included additional tracked networks. Those definitions matter: live TPS is based on the latest completed hour, whereas daily and longer totals use completed periods.
Transaction count is not identical to economic demand. A low-cost chain can create many simple or automated transactions; one settlement transfer may carry more economic value than thousands of game actions. Nor do all networks described as L2s inherit the same security properties. L2BEAT distinguishes rollups that post data to Ethereum from validiums and optimiums that use external data-availability arrangements. Its data-availability risk framework is useful precisely because “L2” is not a uniform security label.
The L2BEAT snapshot provides a second lens. Its DA summary showed approximately $35.05 billion of value secured by Ethereum DA versus about $844.75 million by alternative DA systems, and 12.33 GiB of past-day data across the public DA layers it could measure. The site also counted 41 scaling projects using Ethereum’s enshrined DA bridge. These values move with token prices, deposits and classification changes, so they should be treated as dated observations rather than precise structural constants.
Together, the sources support a restrained conclusion. Ethereum DA is both heavily used and associated with substantially more secured value than the alternative public DA systems in L2BEAT’s coverage. They do not prove that every extra blob creates proportional end-user utility, or that Ethereum will retain its share as competitors improve.
Economics: cheap data, but not free data
For rollups, blob fees are a wholesale input cost. More supply should reduce congestion at a given level of demand and can lower the settlement cost embedded in user fees. That supports higher-frequency applications—payments, social interactions, gaming and machine-to-machine activity—that are not viable when every action bears a large settlement overhead.
Yet permanently negligible blob fees would create two problems. First, price would stop signaling scarcity during congestion. Second, Ethereum would earn little from providing security and availability even as rollup businesses monetize execution. Fusaka’s EIP-7918 addresses a specific failure mode by bounding the blob base-fee reserve in relation to execution costs. Previously, when execution gas dominated the total cost of submitting a blob transaction, the blob fee could remain pinned near its minimum and fail to respond promptly. The change does not guarantee high revenue; it makes the auction more responsive and prevents an obviously uninformative floor.
This matters for valuation narratives. L2 scale can expand Ethereum’s strategic relevance while compressing fee revenue per byte. Security demand, ETH monetary dynamics and protocol revenue are related but not interchangeable. An analyst should therefore track at least four series rather than one: blob utilization relative to target, blob fees, total L2 activity, and the value secured by Ethereum-based rollups. Rising activity with low fees may be a product success but a weak short-term revenue signal. Rising fees with blocks persistently above target may indicate demand strength, but also a need for another capacity step.
Implications for institutions and builders
For institutional users, the clearest benefit is not a promise that fees will always fall. It is that Ethereum now has a more modular way to expand DA without forcing ordinary nodes to ingest every additional byte. That improves the credibility of capacity planning for rollups whose applications need predictable settlement. It also strengthens the distinction between execution venues and the settlement/availability layer beneath them.
For rollup operators, abundant blobspace intensifies competition. When data cost declines, differentiation moves toward distribution, application liquidity, sequencer performance, interoperability and governance. Margins created only by the spread between user fees and L1 data costs are vulnerable: capacity expansion can invite rivals to cut prices, while demand spikes can still raise wholesale costs.
For Ethereum governance, the operational burden increases. BPO forks are narrower than full network upgrades, but they turn telemetry into policy. Client diversity, geographic network conditions and home-node bandwidth deserve equal weight with aggregate blob utilization. An average can conceal tail failures: the network remains decentralized only if participants outside well-connected data centers can stay synchronized.
Risks and counterarguments
The strongest technical risk is that sampling works in production only as well as its networking assumptions and implementations. Correlated client bugs, adversarial peer selection, poor subnet distribution or reconstruction bottlenecks could weaken performance even when the cryptography is sound. The independent KZG-library audit is useful evidence of review, but no audit eliminates implementation or systems risk.
A second risk is hidden centralization above the DA layer. PeerDAS decentralizes data custody; it does not decentralize sequencers, proving systems, upgrade keys or governance. Users can receive cheap transactions while still depending on a small operator set for ordering and liveness. L2 maturity must therefore be evaluated separately from Ethereum DA capacity.
Third, abundant supply can delay price discovery. If blob targets remain well above demand, fees say little about users’ willingness to pay, and Ethereum may subsidize an ecosystem whose economic returns accrue elsewhere. The counterargument is that early infrastructure should price for adoption, not immediate rent extraction, and that greater rollup use deepens ETH’s role as collateral and settlement asset. Both propositions require evidence over time.
Finally, alternative DA layers can offer lower prices or specialized throughput. Ethereum’s advantage is its enshrined bridge and large secured-value base, not monopoly economics. Rollups may choose different points on the cost-security spectrum, and modular architectures make switching or hybrid designs conceivable.
What to watch next
The most informative dashboard is not a single TPS counter. Readers should watch whether average blob use approaches the 14-blob target for sustained periods; whether fee spikes are brief and orderly; whether another BPO is proposed with public network-health evidence; whether Ethereum’s share of secured DA value holds; and whether major rollups improve their sequencer and proof-system risk profiles. These indicators jointly test whether capacity, economics and decentralization are advancing together.
Conclusion
Fusaka solved a specific, consequential problem: Ethereum could not keep scaling rollup data if every node had to download every blob. PeerDAS replaced universal replication with verifiable sampling and reconstruction, while BPO forks made capacity a staged operational variable. The move from a six-blob target to 14 demonstrates that the mechanism has already produced real headroom, and current L2 activity shows there is a large market positioned to use it.
The next phase is less cinematic and more important. Ethereum must turn headroom into useful, secure demand without pricing DA irrationally or pushing nodes toward professional data centers. That is why post-Fusaka performance should be judged as a three-part system—usage, economics and node health—not as a contest for the largest theoretical throughput number. The architecture has changed the scaling question. The quality of the control loop will determine the answer.