Supernode hardware census: the blob ceiling is 21, mainnet fills 6

When BPO2, the second Blob Parameter Only fork, raised Ethereum's blob ceiling to a target of 14 blobs per block and a maximum of 21, it roughly doubled the room a block has for rollup data. Fusaka had already changed how that data moves, because under PeerDAS each blob is erasure-coded and split into 128 data columns, and a node either samples a handful of them or, if it runs as a supernode, keeps all 128. We run 84 supernodes at full custody, which is the worst case for blob load, and eight months into the new ceiling the result is almost boring. Mainnet fills only about 6 blobs per block, the blob-specific cost on our fleet is small, and the hardware differences we can actually measure come down to the client you run rather than the blobs it carries.

That is a duller headline than "blobs are crushing node operators," but it is the one the data supports. The averages are calm, and the interesting question is where the calm comes from and where it ends.

Read this first

• This is a supernode fleet, the worst case. Every host custodies all 128 data columns, whereas a plain full node keeps as few as 4 of them, about 1 in 32, and a home staker only a little more. A typical node therefore sees far less than the figures here, which are an upper bound rather than a normal load.
• These are averages over a two-week window, not tails. The blob cost that actually hurts comes from the rare block near the 21 maximum, which lives in the tail, and while we discuss that tail we do not headline it.
• The blob load is demand-limited. Mainnet fills about 6 of the 14 target, rising through 2026 but still well short of it, so everything here would scale up if demand reached the ceiling. That is exactly what the network is watching for before it raises the ceiling again.
• Storage is data columns now, not blobs. After PeerDAS the on-disk unit is the erasure-coded column rather than the whole blob, and the old blob_disk_bytes gauge reads zero.
• One measurement gotcha, stated up front. A naive rate(counter[14d]) over the window came out wrong by a factor of five, thanks to counter resets, so every rate here uses avg_over_time(rate[5m])[14d:1h] instead. The methodology section has the detail.

The ceiling doubled, the demand is still catching up

Fusaka shipped PeerDAS in December 2025, and two Blob Parameter Only forks followed close behind, with BPO1 lifting the target to 10 and then BPO2 taking it to 14, with a maximum of 21, on 2026-01-07. The capacity is real, and demand is climbing toward it, but it has not arrived.

Blob demand has climbed all year, from three to four blobs per block in the first quarter to a record daily average of 6.7 on 2026-09-03, and the running average now sits near 6 with a median closer to 4 (data from Blobscan). Even at that pace, blocks reach the 14 target only rarely and the 21 maximum only in the tail. Because demand has not yet pressed the ceiling there is little urgency to raise it, and core developers are holding BPO3 for a second reason as well: a telemetry review of the first two forks, prompted by the higher miss rates seen on blocks that carry 16 or more blobs. For now the ceiling sits ahead of demand, and the gap is closing.

The fleet: 84 full-custody supernodes

These numbers come from our deployment across Vienna (NDC2) and GCP, which runs 84 supernode hosts, 42 for consensus clients and 42 for the paired execution clients, covering the full six by six matrix with several pairings duplicated on both sites. The hosts are modest 10-core boxes with 14 to 18 GiB of RAM and a roughly 1.2 TB NVMe root, about 725 GB of which is used, and the two sites are comparable rather than identical because the GCP machines carry a little less memory. Consensus and execution run on separate hosts, so each per-client figure reflects that client's own machine, while a home staker running both on one box would be stacking a consensus figure on top of an execution figure. The window runs from 2026-08-04 to 08-18, chosen to sit clear of an unrelated gateway test later in the month, and the methodology section has the rest.

Where the blob load lands: almost nowhere

At about 6 blobs per block, the blob-specific work stays small even at full custody.

• Data-column verification is cheap. The KZG proof checking that PeerDAS adds costs under half a core on every consensus client, and at most about half a core-second per second of wall time on grandine. Reconstruction is heavier, but it only fires when a node is missing columns while still holding more than half of them, so it rarely triggers on a well-connected supernode. Even grandine and lighthouse, the two heaviest clients overall, spend almost none of their CPU here.
• Bandwidth stays modest. A full-custody supernode receives about 1.2 MiB per second, or roughly 10 Mbps. Full custody means taking every column rather than sampling, so that runs higher than a home staker would see, but at 6 blobs the columns themselves are only a small slice of it, and most of the traffic is ordinary attestations and gossip that comes nowhere near saturating the link.
• Storage is columns, and retention-bounded. After PeerDAS each host keeps erasure-coded data columns rather than whole blobs, over a window of roughly 18 days. Only one client counts them directly, and prysm reports several million column entries per host, though we cannot pin down exactly what the gauge tallies per block. There is no byte-level gauge anywhere on the fleet, so we will not quote a blob-storage figure in gigabytes we cannot measure, but the shape is clear enough: the unit changed, and the volume tracks the low blob count rather than the 21 ceiling. Most of a supernode's 725 GB of used disk is execution-client state in any case, not columns, and the pruning census breaks that down.

None of that is where an operator's hardware budget goes.

What actually varies: the client

The spread in our numbers is real, but it comes from the client rather than the blobs.

Consensus CPU runs about three times apart across clients, with grandine and lighthouse near 24 and 23 percent and nimbus and lodestar down near 7 to 8, against a fleet average of 10.5. Because the data-column and KZG work stays under half a core on every one of them, that spread is not blob processing at all, but the clients' ordinary steady-state CPU. Our blob-performance census found the same shape in verification latency, and here it simply resurfaces as CPU. These are whole-client figures rather than a blob-versus-baseline split, so read the differences that follow as the client you run, not a per-axis blob cost.

The execution side shows the same pattern on the other axes, where again no single client is cheapest on every one.

Ethrex holds 15.3 GiB of memory, up to nearly four times the lightest client, Reth at 4 GiB, and enough to nearly fill a 17.6 GiB host, the same appetite our hardware footprint census measured earlier. Erigon reads 42 MiB per second from disk, eight times the execution-host average and in line with its history-heavy layout, while Reth and Erigon together lead the write rate near 12 MiB per second and, on the consensus side, lighthouse writes the most at around 16. Pick any one axis and a different client turns out to be the expensive one, so an operator sizing a supernode is really choosing which axis matters most on the hardware they have. The blob count is not the variable.

Where it would bite

The calm depends on demand, and two things would end it.

The first is the tail. Blocks carrying 16 or more blobs are rare, a few hundred out of hundreds of thousands of slots, but they cost more when they do land, and published mainnet analyses put the miss rate on them near 1.79 percent against a baseline of about 0.5. The clearest example came in January 2026, when a surge in blob traffic pushed teku's LevelDB past its throughput and stalled full-custody nodes for tens of seconds, until the switch to RocksDB in teku 26.2.0 resolved it. Two-week averages like ours smooth all of that away, whereas a percentile view would catch it, and that percentile view is the right lens for anyone chasing missed attestations, the on-time votes a node drops when a block arrives late.

The second is demand itself. The roadmap does keep raising the target, toward 48 blobs and later 72, but not yet, because the step to around 48 is a further BPO held for the same telemetry review, and the larger increases wait on Glamsterdam's enshrined proposer-builder separation, whose wider payload-propagation window is what makes higher blob counts safe to carry. Until that arrives the ceiling stays at 21. Since we measured at a single demand point, what follows is a projection from the mechanism rather than a measurement: as the blob count climbs, the bandwidth and column axes should climb with it, roughly in step, and the client that looks cheapest today at 6 blobs is not guaranteed to still be cheapest at 14.

What this is not

These are full-custody supernodes, so every number should be read as an upper bound. A node on a home connection custodies only a fraction of the columns, as little as 1 in 32, and carries a matching fraction of the bandwidth and storage, so the absolute figures are not a home staker's. The finding is, though, and it does transfer: what moves your hardware bill is the client you run, not the blobs it carries. Beyond that, these are averages rather than the tail that governs missed attestations, and the fleet runs no local validators, so nothing here is an attestation or reward measurement. It is also a snapshot at today's demand, when the whole point of the ceiling is to be ready for demand that has not yet arrived.

Methodology

The fleet is our NDC2 deployment in Vienna together with GCP hosts, 84 supernodes in all, 42 running a consensus client and 42 the paired execution client, covering all thirty-six pairings with several duplicated across the two sites. Each host has 10 cores, and the Vienna machines carry 17.6 GiB of RAM against the GCP ones' 13.6, on a roughly 1.2 TB NVMe root, so they are best read as comparable rather than identical. All figures are window averages over 2026-08-04 to 08-18, taken from the Prometheus-cold datasource and filtered to the supernode hosts.

• Rates use a subquery. Every per-second figure is avg_over_time(rate(metric[5m])[14d:1h]), the mean of the five-minute rate across the window. A single rate(metric[14d]) reported 55 percent fleet CPU where the true figure is 10.5, because counter resets over a 14-day range corrupt the extrapolation. Gauges use avg_over_time(metric[14d]).
• Per-client attribution. Consensus figures filter to the consensus hosts and group by consensus client, and the execution figures do the same on the execution side. Network is the sum of the physical interfaces per host, excluding the container bridges that mirror the same packets, and disk is the real block devices, excluding the optical drive.
• Blob and column metrics. The pre-PeerDAS blob_disk_bytes gauge reads zero on this fleet, since the post-PeerDAS unit is the data column, and because only some clients expose a column count and none a byte size, the storage axis is reported as a column count on the one client that carries it rather than a fleet gigabyte figure.
• Window hygiene. The window excludes a later, unrelated gateway experiment on the same hosts, which would have added CPU and network load. The supernode setup has been stable across the fleet since about June 2026. Earlier windows ran a non-supernode fleet and are a different measurement, covered in the Fusaka hardware post.
• Context figures for blob demand, tail miss rates, and the teku incident are external, from Blobscan, published mainnet analyses, and the teku release notes. We cite them as context, not as our own measurements.

Coming next

The obvious follow-up is the percentile view, the tail this census smooths over, plus a rerun if demand climbs toward the 14 target. The queries and fleet labels behind this post live in build your own dashboards, and the stack itself in the measurement stack we described here. If you run Ethereum infrastructure and want this lens on your own nodes, reach us at stereumlabs.com or contact@stereumlabs.com.