Overview​

We run 5 Nimbus multiarch-v26.3.1 beacon nodes on our NDC2 bare-metal fleet in Vienna, each paired with a different execution client:

A sixth node (Nimbus + Reth v1.11.3) is also deployed, but Reth has not yet completed its initial sync and is therefore excluded from this analysis.

All 5 nodes use Nimbus' built-in validator_monitor feature to passively observe the same set of 1,000 validator pubkeys on-chain. The validator monitor tracks attestation inclusion, vote correctness, block proposals, and timing data for these validators without requiring the signing keys to be locally attached.

The full analysis covers a 48-hour window ending April 13, 2026. Data sources: Prometheus (prometheus-cold) for metrics and Elasticsearch (Filebeat) for both EC container logs and Nimbus CC container logs.

Block building: the headline finding​

When one of the 1,000 monitored validators is selected as block proposer, Nimbus triggers engine_forkchoiceUpdatedV3 with payload attributes on its paired EC, asking it to build a block. The EC then constructs the execution payload iteratively, improving it over several seconds until Nimbus calls engine_getPayloadV4 to retrieve the result.

Over 48 hours, block building was triggered for approximately 13 unique blocks. The results differ dramatically between execution clients.

Build latency vs. payload output​

Nimbus logs the exact timestamps for Requesting engine payload and Received engine payload, giving us the end-to-end build latency and resulting gas_used for every payload. This CC-side perspective is consistent across all ECs and fills in data even when the EC's own logs lack detail.

The most counterintuitive finding: Erigon is the fastest responder (479ms avg) yet delivers 0 gas. Its transaction pool is apparently unable to supply transactions within the build window, so it returns an empty block quickly rather than spending time filling it. Besu takes 67ms longer on average but uses that time to pack 23.5 Mgas into the payload.

For high-gas blocks (slots with blob transactions), latency increases across all ECs: Besu peaks at 848ms for a 60M gas block, Ethrex at 728ms for the same block. This confirms that build latency scales with payload complexity.

Per-block distribution​

The averages above compress a wide range of behavior into single numbers. Plotting every individual block build reveals the full distribution:

Three distinct patterns emerge:

Standard blocks (500-650ms, 7-18 Mgas): The main cluster where most builds land. Besu, Ethrex, and Nethermind consistently occupy the upper band (14-18 Mgas), while Geth sits lower (7-15 Mgas). All four ECs overlap in latency, confirming that response time differences between them are marginal for regular blocks.

Blob-heavy blocks (700-850ms, 38-60 Mgas): A few outlier slots where blob transactions push gas usage to 38-60M. These blocks take noticeably longer to build across all ECs, with Besu and Ethrex reaching the gas limit (60M) while Geth tops out around 40-48M. The latency increase is proportional to payload complexity.

Erigon (480-520ms, 0 Mgas): Every single Erigon build sits flat on the x-axis at 0 gas, forming a tight horizontal cluster. Regardless of whether the same slot produced a 17M gas block on Besu or a 60M gas block on Ethrex, Erigon delivered an empty payload. This pattern is consistent across all 12 blocks with no exceptions.

The scatter also reveals a handful of cached payloads (sub-100ms) where all ECs returned near-instantly, likely from a previously prepared payload that Nimbus retrieved before the build window elapsed.

Cross-EC payload comparison​

By examining the Received engine payload log from all 5 Nimbus CC instances, we can compare the actual gas_used delivered by each EC for the same blocks:

Besu, Ethrex, and Nethermind are the strongest block builders, routinely filling blocks to 15-30% gas utilization. Ethrex is particularly consistent, delivering 14-18M gas for standard blocks. Geth produces lighter payloads. Erigon's payloads are effectively empty.

Besu: the most aggressive builder​

Besu produced 661 block improvement iterations across its built blocks. Its logs show the full iterative building process with reward tracking:

New proposal for payloadId 0x36f36d block 24869114
  gas used 17,624,773  transactions 366  reward 2.22 finney
  is better than the previous one by 103.24 szabo

For block #24,869,114, Besu's best build reached 366 transactions, 17.6M gas, and a 2.22 finney block reward. It logged every improvement step, including the marginal reward increase between iterations.

Geth: clean lifecycle, strong output​

Geth logged 214 payload updates and provides the clearest view of the block building lifecycle:

The build started with 6 transactions and grew to 349 transactions over ~10.5 seconds, with each update taking 25-67ms. Geth logs Starting work on payload, then multiple Updated payload entries (with txs, gas, fees, elapsed time), and finally Stopping work on payload reason=delivery when Nimbus retrieves the result.

Ethrex: strong builder, detailed execution breakdown​

Ethrex does not log block building progress in its own container logs at the default log level. However, Nimbus' CC logs reveal it is one of the strongest builders in the fleet, delivering 21.8 Mgas on average with one block hitting 100% gas utilization (60M gas). Each payload carries extra_data: ethrex 9.0.0.

What Ethrex does log is an excellent per-block execution breakdown when processing incoming blocks:

BLOCK EXECUTION THROUGHPUT (24869233): 0.366 Ggas/s
  TIME SPENT: 55 ms. Gas Used: 0.020 (33%), #Txs: 134
  block validation: 1% | exec(w/merkle): 91% | merkle-only: 2% | store: 7%

This level of transparency into where execution time is spent (91% in execution+merkle, 7% in storage, 1% in validation) is unique among the tested ECs and valuable for performance profiling.

Nethermind: strong builder, quiet logs​

Nethermind's own logs only show production requests (Production Request 24869114 PayloadId: 0x2321052e5846b8a2) without per-iteration detail at the default log level. However, Nimbus' CC logs reveal the full picture:

INF Received engine payload  slot=14103195 payload="(block_number: 24869114,
  gas_used: 17257515, gas_limit: 60000000, extra_data: Nethermind v1.36.2, ...)"

For block #24,869,114, Nethermind delivered 17.3M gas, competitive with Besu's 17.6M and Ethrex's 16.9M. Across all 13 payloads in 48h, Nethermind consistently produced blocks in the 9-17M gas range.

Erigon: severely impaired block building​

Erigon's own logs show it actively attempts to build blocks but consistently fails to include transactions:

76% of Erigon's 54 block build iterations produced completely empty blocks with 0 transactions and 0 gas. When it did include transactions, the count was dramatically lower than other clients: a maximum of 36 transactions versus 300+ for Besu and Geth.

Built block  height=24869114  txs=0  executionRequests=0
  gas used %=0.000  time=782.686ms

The Nimbus CC logs confirm this: across 12 blocks, every single payload from Erigon contained 0 or near-0 gas. This is not a latency issue. At 479ms average, Erigon is the fastest EC to return a payload. The problem is upstream: Erigon's block execution latency (423-567ms per imported block) delays transaction pool maintenance, so when Nimbus asks for a payload, Erigon has nothing to put in it.

Attestation pipeline: per-EC timing differences​

While all 5 nodes observe the same 1,000 validators and see identical on-chain results (99.996% attestation inclusion rate), how quickly each node observes attestation events varies by EC pairing. Three pipeline stages were measured:

Besu is the fastest for raw attestation observation. However, Geth leads in the third stage (attestation appearing inside aggregates), which is the most relevant for actual inclusion. Erigon is consistently the slowest in this final stage, adding 18ms of latency versus Geth. Ethrex performs well across all three stages.

Attestation volume: Erigon's observation gap​

All 5 nodes should see roughly the same number of attestations for the monitored validators. Over 48 hours, they do not:

Erigon misses ~45,000 attestations that the other 4 nodes see within the same 48-hour window. This is not a network issue; all nodes are on the same bare-metal fleet in Vienna. Erigon's slower block processing causes attestations to expire before the node can process them.

Vote accuracy: source, target, and head​

The 1,000 monitored validators' three Casper FFG vote types show dramatically different difficulty levels:

Head vote accuracy is the hardest duty, with ~210x more misses than source. It requires the node to see the latest block before the slot boundary, making it the most sensitive to processing speed.

Head vote: diurnal pattern​

Over 48 hours, head vote accuracy shows a clear cyclic pattern:

The rate fluctuates between 98.64% and 99.54%, likely driven by network congestion patterns. All 5 nodes report identical values at each time point, confirming this reflects on-chain truth, not individual node performance.

Block proposals via gossip​

Over the monitoring period, the nodes observed 27 block proposals from the 1,000 monitored validators via gossip. In the last 48 hours, 12 block proposals were detected via the validator_monitor_block_hit_total counter. All proposals arrived via the gossip network, confirming the validators are actively proposing on-chain.

Nimbus CC logs as an observability source​

One of the practical takeaways from this analysis: Nimbus' consensus client logs are a valuable observability layer for block building, regardless of how detailed the execution client's own logs are.

Nimbus logs three key events per block building cycle:

1. Requesting engine payload — timestamp, slot, beacon head, fee recipient
2. Received engine payload — full payload contents: gas_used, gas_limit, block_number, extra_data
3. Block proposal included — slot, validator ID

For Ethrex and Nethermind, whose default log levels don't expose per-iteration block building details, the Nimbus CC logs were the only way to determine that both clients are strong builders (17-22M gas avg). This CC-side perspective also revealed the build latency data that showed Erigon's problem is not response time but empty transaction pools.

EC log verbosity at default levels​

An interesting infrastructure finding: the default log levels produce vastly different volumes across execution clients.

Nethermind produces ~9x more log output than Besu at default log levels. All 6 ECs in our fleet (including Reth, which is syncing) are included here since this is a general infrastructure observation.

Summary​

Key takeaways​

1. Erigon's block building is severely impaired. 76% of built blocks were empty, and even when it did include transactions, the count was a fraction of what other clients achieved. Paradoxically, Erigon responds fastest (479ms) but with nothing in the payload. The root cause is its slow block execution (423-567ms) cascading into transaction pool readiness.

2. Besu, Ethrex, and Nethermind are all strong block builders. Besu leads on raw gas output (23.5M avg) and iteration count (661 per block). Ethrex is the most consistent (14-18M gas for standard blocks, 60M for full blocks). Nethermind is competitive at 21.2M avg despite minimal logging.

3. Nimbus' CC logs are a valuable observability source. The Received engine payload log provides payload gas_used, build latency, and block details for every EC, making it the most reliable cross-client comparison tool, especially for ECs like Ethrex and Nethermind whose own logs lack block building detail at default levels.

4. Erigon misses ~11% of attestation observations due to slower block processing. This volume gap is unique to Erigon; the other 4 ECs are within 1% of each other.

5. Head vote accuracy (~99.1%) shows a diurnal pattern visible across all nodes identically, driven by network congestion rather than client behavior.

6. Log volume varies 9x between the most and least verbose EC at default log levels. Nethermind's high verbosity (5,661/hr) is an infrastructure sizing consideration.

Methodology notes​

All Prometheus data sourced from the prometheus-cold datasource in the StereumLabs Grafana instance. Validator monitor metrics use the validator_monitor_* family with cc_client="nimbus" and validator="total" label selectors. 48-hour data uses increase(...[48h]) instant queries and histogram_quantile over rate(...[48h]) for delay distributions.

EC container logs are stored in Elasticsearch (Filebeat 9.3.0 → Elasticsearch 9.3.0) and queried via the container.image.name field to isolate each execution client's output. Block building logs were identified by client-specific patterns: Besu's New proposal for payloadId, Geth's Updated payload/Starting work on payload/Stopping work on payload, and Erigon's Built block/Building block.

Additionally, Nimbus CC container logs (statusim/nimbus-eth2:multiarch-v26.3.1) were analyzed for engine API interactions: Requesting engine payload (build request timestamps), Received engine payload (payload contents including gas_used), and Block proposal included (on-chain confirmation). This CC-side perspective provides build latency measurements and fills in payload details for ECs whose own logs lack that information at default log levels (notably Ethrex and Nethermind).

All nodes run on NDC2 bare-metal hardware (Vienna), eliminating cloud-induced variance.

For details on our label conventions and how to build your own dashboards against our data, see Build your own dashboards.

Overview​

We compared three Teku consensus client versions on our NDC2 bare-metal fleet in Vienna, each paired with all 6 execution clients (Besu, Erigon, Ethrex, Geth, Nethermind, Reth). Each version was measured over a 14-day window during its active deployment period using avg_over_time(...[14d:1h]) instant queries against our Prometheus-cold datasource.

The full report is available as a PDF download at the bottom of this post.

Fleet-level headline numbers​

The two architectural changes — LevelDB → RocksDB in 26.2.0 and the jemalloc memory allocator in 26.3.0 — drove the majority of the performance shifts:

CPU utilization​

Metric: rate(process_cpu_seconds_total{job="teku"}[5m]) — Teku JVM process CPU in CPU-seconds per second.

CPU dropped 38% from 25.12.0 to 26.2.0. RocksDB's block cache and bloom filters reduce per-lookup processing compared to LevelDB. Version 26.3.0 added another 11% reduction through jemalloc's more efficient allocation patterns reducing GC-driven CPU spikes. The Nethermind pairing consistently shows the lowest Teku CPU usage across all three versions.

Memory & JVM analysis​

Process RSS memory​

Metric: process_resident_memory_bytes{job="teku"} — total physical memory consumed by the Teku JVM process.

RSS peaked in 26.2.0 (+5.5% vs 25.12.0), consistent with RocksDB's larger in-memory structures (block cache, memtables, bloom filters). Version 26.3.0 clawed back roughly half through jemalloc's reduced memory fragmentation, leaving a net +2.8%.

JVM heap memory​

Metric: jvm_memory_used_bytes{area="heap"} — Java heap utilization.

Heap grew steadily, reflecting increased in-heap state caching from the RocksDB JNI bridge and the natural growth of Ethereum's state tree. All values remain well within Teku's default 8 GB max heap.

JVM native memory​

Native (off-heap) memory rose modestly with RocksDB and stabilized with jemalloc.

JVM garbage collection​

Metric: rate(jvm_gc_collection_seconds_sum[5m]) — fraction of time spent in GC per second. This is a critical Teku-specific metric because GC pauses directly impact block processing latency.

GC overhead was flat from 25.12.0 to 26.2.0. The introduction of jemalloc in 26.3.0 is the standout: fleet-wide GC time dropped 36%. jemalloc reduces heap fragmentation, meaning fewer large-object promotions to old gen and fewer full GC cycles. For a Java client like Teku, this matters directly — GC pauses are a primary contributor to block import latency.

Storage engine & disk I/O​

Host-level disk I/O​

Metrics: rate(node_disk_read_bytes_total[5m]) and rate(node_disk_written_bytes_total[5m]) — host-level metrics that include both Teku CC and its paired EC. Since EC versions didn't change across measurement windows, deltas are attributable to the Teku version change.

All values in KB/s.

Read throughput dropped 79% (1,518 → 310 KB/s) and write throughput fell 61% (3,258 → 1,270 KB/s). RocksDB's block cache and SST-based design is far more read-efficient than LevelDB. The Besu pairing saw the most dramatic read improvement (−85%).

RocksDB internal metrics (26.2.0+ only)​

These metrics are only available for versions using RocksDB. Version 25.12.0 ran LevelDB which does not expose equivalent counters.

Write amplification improved in 26.3.0: both raw write rate and compaction writes decreased ~11%. The slight read increase likely reflects the partial sidecar import feature doing more background reads.

Block import performance​

Metric: beacon_block_import_delay_latest — most recent block import delay in milliseconds. This captures end-to-end latency from receiving a block to completing its import into the beacon state.

Version 26.2.0 was slightly slower fleet-wide — likely early-stage RocksDB tuning and the concurrent DAS backfiller adding load. Version 26.3.0 brought a strong recovery, achieving the lowest fleet-wide latency at 297 ms. The Ethrex pairing improved most dramatically (−73%), while the Nethermind pairing shows persistently elevated import times that warrant EC-side investigation.

P2P networking & peer connectivity​

All peer metrics improved steadily. Discovery live nodes grew from ~161 to ~176, suggesting the Discv5 layer is maintaining more active ENR records. Gossip throughput peaked in 26.3.0 — consistent with faster block processing enabling quicker re-gossip.

Data availability sampling (DAS) & PeerDAS​

Metric: rate(beacon_data_column_sidecar_processing_requests_total[5m]) — DAS workload rate.

DAS processing rates show significant per-pairing variance. The zero values in 25.12.0 for Erigon/Ethrex reflect sync issues that resolved in later versions. Version 26.3.0 allows nodes with >50% custody requirements to begin importing blocks after downloading only 50% of sidecars — an architectural improvement that doesn't compromise data availability guarantees.

Open file descriptors — the trade-off​

File descriptors doubled — the most visible trade-off of RocksDB. Its LSM-tree architecture holds many SST files open simultaneously for efficient reads. Growth continued from 26.2.0 to 26.3.0 as databases accumulated more SST files through compaction.

Summary & recommendations​

Key takeaways​

1. Upgrade to 26.3.0 is mandatory. Beyond the SSZ serialization bug fix, 26.3.0 delivers the best performance profile across nearly every dimension.

2. Verify file descriptor limits. With 26.3.0 averaging 1,308 open FDs (and likely higher under peak load), ensure systems allow at least 65,536 file descriptors.

3. Monitor RocksDB compaction. Add storage_compact_write_bytes and storage_bytes_written to your dashboards. Abnormal compaction spikes can indicate database health issues.

4. Consider DAS backfiller tuning. If 26.x nodes show elevated CPU during backfill, --Xp2p-reworked-sidecar-custody-sync-batch-size=1 can throttle the backfiller.

5. Watch the Nethermind pairing. Block import delays are persistently higher with Nethermind across 26.x versions — this warrants investigation on the EL side.

Download the full report​

The complete analysis with additional detail on JVM thread pools, executor queue depths, and RocksDB internal counters is available as a styled PDF:

📄 Download full report (PDF)

Methodology notes​

All data sourced from the prometheus-cold datasource (Org 6) in the StereumLabs Grafana instance. Query pattern: avg by (ec_client) (avg_over_time(metric{cc_client="teku", cc_version="...", role="cc", job="teku"}[14d:1h])) evaluated as instant queries at the end of each 14-day window. Rate metrics use rate(...[5m]) inside the subquery. Host-level metrics filtered with device!~"lo|veth.*|docker.*|br.*" to exclude virtual interfaces. All nodes run on NDC2 bare-metal (Vienna), eliminating cloud noise.

For details on our label conventions and how to build your own dashboards against our data, see Build your own dashboards.

On April 2, 2026 we presented StereumLabs at EthCC[9] in Cannes. The talk covered what we've built, why AI on raw metrics alone produces useless output, and concrete Fusaka/PeerDAS runtime data from our bare-metal fleet.

This post is a written companion to that talk. If you prefer watching, the recording is embedded below. The slide deck is available as a PDF download.

Video​

The StereumLabs platform​

StereumLabs is our observability and analytics platform for Ethereum staking infrastructure. We run every relevant client combination on dedicated bare-metal hardware: 6 execution layer clients (Geth, Nethermind, Besu, Erigon, Reth, Ethrex), 6 consensus layer clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine), plus the standalone Erigon + Caplin pairing. That's 37 combinations, monitored 24/7 with 90-day rolling metrics.

All nodes run on isolated bare metal. No shared cloud instances, no noisy-neighbor effects. When we measure performance differences between clients, the data is reproducible and directly comparable.

The platform provides 20+ dashboards covering resource consumption (CPU, RAM, disk, network), client-specific metrics (attestation rates, block processing times, peer counts, GC behavior), and system logs. Client development teams already have free access to the dashboards. The project is supported by an Ethereum Foundation grant.

But dashboards have limits. And that's where AI comes in.

AI Chatbot: natural language meets live data​

We built an AI chatbot connected directly to our full monitoring dataset. Instead of navigating dashboards and writing queries, users ask questions in plain English:

• "Compare disk growth between Geth and Erigon over the last 30 days"
• "How did the Prysm update from v7.1.1 to v7.1.2 affect resource usage?"
• "Which consensus client uses the most bandwidth as a supernode?"

The result is a structured analysis with actual numbers, across all EL pairings, in seconds.

The Instruction Set​

Here's what most people get wrong about AI in infrastructure monitoring: the model alone doesn't produce useful results. If you point a language model at raw Prometheus metrics, it doesn't know which queries to run, what normal ranges look like, or how to interpret differences between client architectures.

That's why we've built a continuously evolving Instruction Set. It encodes which metrics matter for which client combination, what normal ranges look like per pairing, how to interpret architectural differences (Go vs. Java GC behavior, Rust memory models), and which queries to run in which order to build a meaningful analysis.

Without the Instruction Set, the AI produces generic answers. With it, it produces the kind of analysis that would take an experienced engineer hours to assemble manually. We expand it continuously as we encounter new patterns, new client versions, and new edge cases. It's built from years of running these clients professionally.

Proof: Prysm v7.1.1 to v7.1.2​

When the Prysm team shipped v7.1.2, we asked the chatbot one question and got a full resource impact analysis across all 6 EL pairings:

This analysis would normally take hours of manual work. The chatbot produced it from a single question. The full report is published on our blog: Prysm v7.1.1 & 7.1.2 resources.

AI Alerting: from "something is wrong" to "here's why"​

The chatbot is great for proactive analysis. But what about when things go wrong at 3am? That's where AI Alerting comes in.

Two-stage architecture​

Stage 1: Near-real-time threshold alerts. Monitors hard thresholds like attestation rate, disk usage, peer count, and missed blocks. Fires within seconds. No AI inference delay, no additional cost. If the AI layer is slow or unavailable, the basic alert still arrives.

Stage 2: AI root-cause analysis. When a threshold alert fires, a webhook triggers the AI. It pulls relevant metrics and logs, correlates the data against our neutral baseline from all 37 client combinations, and delivers a root-cause analysis with actionable next steps. Delivered in 5 to 15 seconds.

The result: operators don't just get "attestation rate dropped below 95%." They get: "Your attestation rate dropped because Geth's peer count fell to 3, likely due to a network partition. Your Prysm instance is healthy. Recommended action: check firewall rules and restart the EL client."

Built-in baseline: instant context​

What makes our alerting especially useful is the neutral baseline dataset from our own fleet. When an alert fires, the AI automatically compares against data from all 37 client combinations.

Every alert answers three questions: Is this happening across the Ethereum network right now? Is it specific to this client version? Or is it unique to your local environment?

That distinction between "the whole network is seeing elevated block processing times after a fork" and "your Geth instance is the only one with this problem" is the difference between waiting it out and taking immediate action.

Security monitoring​

The same two-stage architecture applies to security events:

• SSH login checks — authorized key? Expected source IP? Expected time window?
• Service restart analysis — when an execution client restarts, the AI verifies that fee recipient addresses haven't been changed. A compromised operator could redirect staking rewards without anyone noticing for days.
• Configuration drift detection — unauthorized processes, unexpected port openings, validator key access patterns.

Traditional monitoring tells you "Geth restarted." Our AI layer tells you "Geth restarted, fee recipient address changed from 0xABC to 0xDEF, this was not initiated through the operator's usual deployment pipeline, severity: critical."

For operators staking millions in ETH, the difference between detecting a compromised reward address in minutes versus days is the difference between a security incident and a financial disaster.

Fusaka + PeerDAS: what the hardfork did to hardware​

A significant portion of the talk covered our Fusaka hardfork measurements. We compared two 14-day windows (before and after the December 3, 2025 activation) across all 36 non-supernode client pairings.

The fleet-level headline numbers:

Notable client outliers: Nimbus CPU jumped +257% (most compute-intensive PeerDAS implementation), Lighthouse was the only consensus client to reduce CPU (-13%), and Besu saw the largest memory drop (-35%).

The worst pairing post-fork: Nimbus + Reth at 16.78% CPU.

The full analysis with per-client breakdowns, heatmaps, daily trends, and PromQL queries is available as a dedicated blog post: Fusaka hardfork: hardware impact on non-supernodes.

Deployment models​

One thing we hear constantly from professional operators: "I'm interested, but I can't send my metrics to your cloud." That's why StereumLabs supports multiple deployment options:

• SaaS — hosted by us in our ISO 27001 certified environment. Best for smaller operators and researchers.
• Alerting-as-a-Service (pull model) — you expose a Prometheus endpoint, we scrape it. Your data never enters our systems. It only meets our baseline data at the AI inference layer.
• On-premise — the entire StereumLabs stack deployed on your infrastructure. Your own API keys. Data never leaves your network.

The key message: your infrastructure data doesn't become someone else's competitive intelligence.

Current status​

Get in touch​

We're looking for node operators who want to try the AI chatbot, client development teams interested in automated cross-EL impact analysis, and staking protocols looking for monitoring and security standards across their operator ecosystem.

Reach out at contact@stereumlabs.com or visit stereumlabs.com.

Slides​

The full slide deck from the talk is available for download:

📄 Download slides (PDF)

What is Fusaka?​

Ethereum's Fusaka hardfork activated on December 3, 2025 at 21:49 UTC (slot 13,164,544). It was the second hard fork of 2025 after Pectra (May 2025) and arguably the most consequential upgrade since the Merge. The name combines "Fulu" (consensus layer, named after a star) and "Osaka" (execution layer, named after the host city of Devcon 2025).

The headline feature is PeerDAS (Peer Data Availability Sampling, EIP-7594) — a fundamental change in how Ethereum verifies blob data. Instead of every node downloading and verifying every blob, nodes now only need to sample small slices, verifying that the full data exists without actually possessing all of it. Vitalik Buterin called it "literally sharding" — Ethereum reaching consensus on blocks without requiring any single node to see more than a tiny fraction of the data.

Beyond PeerDAS, Fusaka shipped approximately 12 additional EIPs:

• EIP-7935 — raises the default block gas limit, targeting ~60 million gas
• EIP-7825 — introduces a per-transaction gas cap of 16.78 million to prevent single-transaction DoS attacks
• EIP-7892 — the Blob Parameter Only (BPO) mechanism, allowing blob capacity increases between hard forks
• EIP-7951 — secp256r1 precompile for device-native signing and passkeys
• EOF (EVM Object Format) — a cleaner, more efficient programming structure for smart contracts
• EIP-7918 — stabilizes blob fees
• EIP-7742 — new opcodes including CLZ (count leading zeros) for more efficient cryptographic operations

Two scheduled BPO forks followed:

• BPO-1 (~December 9–10): blob target/max raised from 6/9 to 10/15
• BPO-2 (~December 23 – January 7): blob target/max raised to 14/21

We wanted to know: what did all this actually do to the hardware running our nodes?

Methodology​

Fleet setup​

StereumLabs runs approximately 90 hosts split across GCP cloud instances and NDC2 bare-metal nodes in Vienna, Austria. Each non-supernode host runs one consensus client (CC) paired with one execution client (EC), covering all 36 possible combinations of:

• Consensus clients: Grandine, Lighthouse, Lodestar, Nimbus, Prysm, Teku
• Execution clients: Besu, Erigon, Ethrex, Geth, Nethermind, Reth

Data source​

All metrics come from our prometheus-cold datasource (UID aez9ck4wz05q8e, Org 6), which covers all available metrics without retention or delay restrictions. Node-level system metrics are collected via prometheus-node-exporter at a 15-second scrape interval.

Comparison windows​

We compared two 14-day windows:

Both windows use avg_over_time(...[14d:1h]) — a 14-day average at 1-hour subquery resolution, computed as an instant query at the boundary timestamp. This smooths out transient spikes while preserving meaningful shifts.

Filtering​

Supernodes are excluded via the label filter cc_client!~".*-super". Only instances with role=~"cc|ec" are included. Network metrics exclude loopback and virtual interfaces (device!~"lo|veth.*|docker.*|br.*").

Fleet-level results​

Here's what happened across the entire non-supernode fleet:

Let's dig into each metric.

Network bandwidth: the biggest win​

The most striking result is the 60% drop in network receive bandwidth — from 2.20 MiB/s to 0.87 MiB/s on average. This is PeerDAS in action: nodes now verify only sampled slices of blob data rather than downloading entire blobs.

Daily trend​

Looking at the daily time series, the decline actually began before the fork itself — around November 28–29 — suggesting some nodes started running fork-compatible client versions with PeerDAS-like optimizations ahead of the December 3 activation. On the fork day itself, the fleet-average RX was already down to 0.26 MiB/s.

The post-fork trend shows a brief recovery as nodes settled into the new protocol, stabilizing around 1.4 MiB/s by mid-December — still a 36% reduction from the pre-decline baseline of ~2.2 MiB/s.

Network transmit bandwidth also decreased, though more modestly — from 0.20 to 0.18 MiB/s (−13%).

CPU utilization: moderate increase, one clear outlier​

Fleet-average CPU rose from 4.66% to 6.08% — a 30% relative increase, but in absolute terms still very modest. This is the expected trade-off: PeerDAS introduces data availability sampling routines (compute) in exchange for reduced data transfer (bandwidth).

The fork-day spike​

The daily time series reveals two notable spikes:

• December 4: 14.82% — the day after fork activation. All clients simultaneously processed new consensus rules, PeerDAS bootstrapping, and EOF-related state transitions. This spike was transient and resolved within 24 hours.
• December 10: 10.09% — coincides with BPO-1 raising the blob target/max from 6/9 to 10/15. The higher blob capacity required additional sampling work.

After settling, the new baseline sits around 5.5–5.7% — roughly 1 percentage point above pre-fork levels.

Per-consensus-client breakdown​

Not all consensus clients handled Fusaka equally:

On the positive side, Lighthouse was the only consensus client to decrease CPU usage (−13%), suggesting either an efficient PeerDAS implementation or concurrent optimizations shipped in its fork-compatible release.

Lodestar remained essentially flat (+1%), and Prysm (+11%), Teku (+5%), and Grandine (+21%) showed moderate increases — all within comfortable bounds for typical node hardware.

Per-execution-client breakdown​

Execution clients saw a more uniform increase, consistent with the raised gas limit (EIP-7935) and new EVM opcodes (EOF):

Besu (+101%) and Geth (+64%) saw the largest relative increases. For Besu, the doubling (from a very low 2.58% baseline) likely reflects the new gas limit activating code paths that were previously idle. Geth's increase is consistent with heavier block processing under the raised 60M gas ceiling.

Nethermind bucked the trend entirely with a −26% decrease — a surprising result that may indicate a coincidental version update with CPU optimizations during the measurement window.

The full picture: CPU heatmap across all 36 pairings​

This heatmap shows the percentage change in CPU utilization for every CC×EC combination. Red means higher CPU after Fusaka, green means lower:

The Nimbus row is unmistakable — deep red across all EC pairings, with nimbus + ethrex showing an extreme +1060% (from 0.83% to 9.63%, though the low baseline suggests the pairing may have been partially offline pre-fork). The Nethermind column is notably green across most CC pairings, reinforcing that Nethermind itself saw a concurrent optimization.

Memory: a modest but welcome decrease​

Average memory usage dropped from 6.06 GiB to 5.59 GiB (−8%) across the fleet. This aligns perfectly with PeerDAS's design: nodes no longer hold entire blobs in memory, only the sampled slices they need for verification.

Daily trend​

The CPU + memory daily trend chart above also shows the memory trajectory (orange line). There's a sharp drop on December 4 (from 6.22 to 5.26 GiB) — the first full day after the fork — followed by a gradual recovery over the next two weeks as caches and new protocol state accumulated. By December 18, memory was back to 6.27 GiB, suggesting the initial drop was partly transient (e.g., cleared blob caches from the pre-fork protocol).

The 14-day average still shows a net decrease because the early post-fork days pull the average down significantly.

Per-consensus-client breakdown​

Nimbus (−20%) and Grandine (−17%) saw the largest memory reductions. Interestingly, Nimbus traded memory savings for CPU — a classic compute-vs-memory trade-off in its PeerDAS implementation.

Prysm was the only consensus client to increase memory (+6%), suggesting it keeps more sampling state in memory than peers. Given Prysm's CPU increase was moderate (+11%), this is a reasonable engineering choice.

Per-execution-client breakdown​

Besu saw a dramatic −35% memory drop — from 6.59 to 4.31 GiB. This is the largest single-client change in the dataset and likely reflects aggressive cache invalidation during the fork transition. Reth moved in the opposite direction (+13%), possibly due to its database engine accumulating more state under the new protocol.

Disk I/O: reads halved, writes slightly up​

Read rate​

Disk reads dropped 53% — from 2.58 to 1.21 MiB/s. This is directly attributable to PeerDAS: nodes no longer need to retrieve full blobs from disk for verification. The reduction was visible across nearly all pairings.

Some notable per-pairing changes:

• teku + ethrex went from 26.18 MiB/s (an extreme outlier pre-fork) to 2.86 MiB/s — a 89% drop
• lighthouse + reth dropped from 1.71 to 0.55 MiB/s (−68%)
• grandine + reth moved in the opposite direction — from 0.08 to 3.23 MiB/s — suggesting a change in Grandine's blob retrieval strategy for PeerDAS

Write rate​

Disk writes increased 11% — from 1.73 to 1.92 MiB/s. The increase is modest and likely comes from:

1. PeerDAS sampling metadata — nodes now store sampling proofs and column indices
2. EOF state changes — the EVM Object Format introduces new bytecode validation and storage patterns
3. Higher gas limit — more transactions per block means more state writes

This is a small overhead relative to the substantial read savings.

Full 36-pairing matrices​

For the detail-oriented, here are the complete CPU and memory matrices across all CC×EC combinations.

CPU utilization — before Fusaka (%)​

CPU utilization — after Fusaka (%)​

Memory usage — before Fusaka (GiB)​

Memory usage — after Fusaka (GiB)​

Things to watch​

Nimbus CPU trajectory​

The +257% CPU increase on Nimbus deserves monitoring over subsequent weeks and versions. If this is a temporary bootstrapping cost (PeerDAS column sync, initial sampling table construction), it should decline. If it persists, Nimbus operators on lower-spec hardware may need to re-evaluate their headroom.

BPO-2 effects (not captured here)​

BPO-2 was scheduled for late December 2025 to early January 2026, raising blob parameters from 10/15 to 14/21. Our post-fork window (Dec 4–18) captures BPO-1 but not BPO-2. A follow-up analysis with a wider window would reveal whether the second parameter increase added further CPU or bandwidth pressure.

Memory recovery trend​

The sharp initial memory drop post-fork appears to be partly transient — memory was trending back upward by December 18. We'll continue monitoring whether this recovery plateaus below the pre-fork baseline or converges back to original levels.

The nimbus + ethrex anomaly​

The nimbus + ethrex pairing showed anomalously low CPU pre-fork (0.83%), which may indicate the pairing was partially offline or in a degraded state during the pre-fork window. The post-fork value of 9.63% is more consistent with fleet norms, suggesting the pairing recovered during or after the fork transition.

Client version confounding​

Client versions were not pinned across the fork boundary — some pairings may have undergone version upgrades alongside Fusaka. This means we cannot cleanly attribute all changes to the fork itself. In particular, Nethermind's −26% CPU decrease may reflect a version update rather than a Fusaka effect.

Bottom line​

Fusaka delivered on its core promise for non-supernode operators: dramatically lower bandwidth requirements (−60% receive, −13% transmit) and modestly lower memory (−8%), at the cost of a moderate CPU increase (+30%) that remains well within typical hardware headroom. Disk reads dropped by half.

For operators managing hosting costs, the network savings alone are significant — especially on cloud providers where egress is metered. The CPU overhead is real but manageable: even the worst-case fleet average post-fork (6.08%) leaves substantial headroom on modern hardware.

The main action item is monitoring Nimbus deployments for elevated CPU, and tracking BPO-2 effects as blob capacity continues to expand.

Appendix: PromQL queries used​

For reproducibility, here are the exact queries run against prometheus-cold:

avg by (cc_client, ec_client) (
  avg_over_time(
    (1 - rate(node_cpu_seconds_total{mode="idle", role=~"cc|ec", cc_client!~".*-super"}[1h]))
    [14d:1h]
  )
)

avg by (cc_client, ec_client) (
  avg_over_time(
    (node_memory_MemTotal_bytes{role=~"cc|ec", cc_client!~".*-super"}
     - node_memory_MemAvailable_bytes{role=~"cc|ec", cc_client!~".*-super"})
    [14d:1h]
  )
) / 1024 / 1024 / 1024

avg by (cc_client, ec_client) (
  avg_over_time(
    rate(node_disk_read_bytes_total{role=~"cc|ec", cc_client!~".*-super"}[1h])
    [14d:1h]
  )
) / 1024 / 1024

avg by (cc_client, ec_client) (
  avg_over_time(
    rate(node_network_receive_bytes_total{role=~"cc|ec", cc_client!~".*-super",
         device!~"lo|veth.*|docker.*|br.*"}[1h])
    [14d:1h]
  )
) / 1024 / 1024

Datasource: prometheus-cold (UID: aez9ck4wz05q8e, Org 6)

Before snapshot: instant query at 2025-12-03T00:00:00Z

After snapshot: instant query at 2025-12-18T00:00:00Z

Daily time series: range query from 2025-11-19T00:00:00Z to 2025-12-18T00:00:00Z, step = 86400s

We at StereumLabs run Prysm continuously across all six supported execution-layer clients — Besu, Erigon, Ethrex, Geth, Nethermind, and Reth — on isolated bare-metal nodes. When v7.1.2 landed, we pulled 90-day averages from our Prometheus-cold datasource to see exactly what changed. Here's the short version.

What improved​

Memory is the clearest win. Process RSS dropped by 5.1% on average (3.36 → 3.19 GB), with the biggest gains when paired with Geth (−8.8%) and Besu (−7.8%). Heap in-use stayed flat, which points to the savings coming from outside the Go heap — likely reduced stack allocations or more efficient mmap regions.

Block processing time also improved significantly — down 25% on average (142 → 107 ms). The headline number is dominated by the Erigon pairing, which went from 403 ms to 90 ms (−78%). For the production-grade trio of Geth, Nethermind, and Reth, results were stable to slightly better.

Network connectivity was unaffected. Average libp2p peer count held at ~71 across both versions.

What to watch​

CPU utilization showed a mixed picture that varies by EL pairing — Reth dropped 21%, while Besu increased 28%. Because we measure system-wide CPU across the full node, EL-side changes and PeerDAS load from the Fusaka hard fork both contribute noise here. No clear regression in Prysm itself.

GC pause duration ticked up marginally (+5.5%, from 0.735 to 0.775 ms) — well within acceptable bounds and unlikely to affect attestation or block proposal timelines.

Bottom line​

v7.1.2 is a straightforward upgrade for production operators: lower memory footprint, faster block processing on the pairings that matter most, and no regressions in network behavior. If you're running Ethrex, treat its +138% block processing regression as an outlier specific to that experimental client, not a Prysm issue.

📄 Full report with per-client breakdowns and methodology: Download PDF