5 posts tagged with "resources"

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.

How much machine does an Ethereum execution client need once it sits at the tip of mainnet? Our fleet runs every major execution client on its own host, all with 12 cores, five of six client sets with 16 GiB RAM, one consensus client per pairing on a separate machine. Same chain, same engine-API traffic, one telemetry pipeline. Averaged over the same 36 hours, the synced clients hold between 4.9 and 15.6 GiB of host memory, burn about half a CPU core, and write to disk at anywhere from 0.9 to 22 MB/s. The spread is the story: the client you pick decides whether your box idles or works.

We deployed all 6 Ethereum execution clients from scratch on bare metal and tracked exactly how long each one took to fully sync. The results range from impressive to alarming.

We measured CPU, memory, disk I/O, and network across all 36 CC×EC pairings on our non-supernode fleet — here's what the Fusaka hardfork actually did to hardware consumption.

Let's have a look at both versions of Prysm 7.1.1 and 7.1.2 and it's resource consumption