Lighthouse Update #43

Since our last update Ethereum had three hard forks. Blobs 0 → 21 per block. MaxEB 32 → 2048 ETH.

Beyond delivering the forks we have improved Lighthouse to make it cheaper to run while experiencing no mainnet incidents.

The chain got better

• Deneb (v5.0.0, mainnet Mar 2024) — blobs. Cheap dedicated data space for L2s.
• Electra (v7.0.0, mainnet May 2025) — MaxEB 2048 ETH. One validator replaces 64. Balances above 32 ETH now compound.
• Fusaka (v8.0.0, mainnet Dec 2025) — PeerDAS. A node samples blob data instead of storing all of it.
• BPO1 + BPO2 — unlocking scalability for L2: blob target/max 6/9 → 14/21 in five weeks.

Each fork shipped in a Lighthouse release on time. Each one also gave the node more to do: more data to fetch, more state to hold, more messages to validate. The rest of this post is what we did so that cost did not reach the operator.

The node got cheaper

Tree-states, a two-year rewrite of state storage, in three steps:

• v5.2.0 — in memory. ~64x more states cached at the same memory cost. --state-cache-size 3 → 128. Ships with formally verified epoch processing.
• v6.0.0 — on disk, as hierarchical state diffs. Full-history archive node: 418 GiB. Sequential slot query 250–700 ms.
• v7.1.0 — extended to hot state. 4x less disk I/O in normal operation. 10x less data written during non-finality. Disks stop filling up in a long non-finality event.

Bandwidth, the same idea three times: stop downloading data the node already has.

• v5.3.0 — gossipsub IDONTWANT. No more downloading duplicate gossip messages.
• v6.0.0 — engine_getBlobsV1. Take blobs from your own EL instead of the network. Michael Sproul pioneered the idea and wrote the spec (execution-apis#559); every major EL and CL now implements it.
• v8.2.0 — partial data columns (EIP-8136). The same trick for PeerDAS columns: reuse blob data already in the EL instead of gossiping the whole column. Shipped for Fulu, on by default on Hoodi and Sepolia.
• v8.0.0 — --semi-supernode. Serve blobs over the Beacon API while carrying half the data columns, not all of them.

We rebuilt what we can see inside a running node:

• v7.1.0 — logging moved to tracing.
• v8.0.0 — built-in OpenTelemetry export, via --telemetry-collector-url.
• v8.2.0 — jemalloc memory profiling.

The numbers above came out of those traces. A post on reading them yourself is next.

AI adoption

Our culture comes from security. We are a security company, and what has made Lighthouse successful is balancing that focus with pragmatic engineering. We apply the same balance to AI: use it where it genuinely helps, while thinking long term about the entropy it adds to a codebase we plan to maintain for years.

Lighthouse has adopted AI since late 2025, in a progressive rollout where we consider it necessary, without sacrificing the quality standards of our codebase. Some examples:

• First-pass review — an AI reviews each pull request before a person does.
• Optimisation — AI helps us analyse traces and find slow code paths.
• Security audits — AI does a first pass. A person does the audit. Our security team wrote about this in Collapsing the Security Review Cycle and AI as a Force Multiplier for Security Engineers.
• Pre-release testing — AI runs tests and watches metrics on devnets before a release.

Every pull request undergoes a manual review by at least one senior maintainer before it is considered for merging. Larger changes get more reviewers, based on scope.

Security

Over the last three years we have handled serious issues before they reached production, both network-wide and specific to Lighthouse.

Between February and March 2026 we patched five advisories in the networking stack Lighthouse depends on — rust-yamux, rust-libp2p and quinn-proto — across three mandatory releases in four weeks.

When Holesky failed to finalise during the Pectra rollout, we shipped a hotfix in v7.0.0-beta.1, helped the network recover, and wrote up what happened in The Pectra Holesky Incident.

Sigma Prime has audited other people's code for years, and we are committed to the security of the chain we help run:

• Differential fuzzing against other clients.
• Contributions to the consensus specification, and review of changes to it.
• Maintenance and fixes for the Rust p2p libraries used across the wider blockchain ecosystem.

Security reports generated with LLMs rose sharply this year, and enough of the findings are real that triage now absorbs a meaningful share of our development time. Worth it — bugs get fixed before they reach mainnet, and we have become much faster at triage. Balancing it against the rest of the roadmap is the harder problem.

The Future

Lighthouse is at the forefront of roadmap development, carrying multiple initiatives in parallel to advance the Ethereum roadmap at an accelerating pace.

• Gloas — payload envelopes and bids, PTC duties, proposer preferences, external builder API, light client types, partial data columns.
• FOCIL — inclusion list committee derivation, signature verification, and the fork choice changes behind them.
• Heze — first support for block production on the fork after Glamsterdam.
• Block and blob archive via ERA files — chain history distributed as files instead of re-synced from peers.
• Tree sync.
• Optional execution proofs.
• engine_getBlobsV4, engine_hasBlobs — the next steps in taking blob data from the EL rather than the network.

Retrospective

Three years is a long time in this industry. The market went up and down and priorities shifted, but most of the people who shipped Deneb are the same people shipping Gloas today. The median tenure on the team is over five years.

That continuity is why 13 people can work on consensus, networking, databases and security at once, and why the work compounds instead of restarting. Most of us are solo stakers and deeply Ethereum-aligned. We are here to see this roadmap through.

Updates are back on a schedule: one per release, monthly beyond that. Follow on @sigp_io or by RSS.

Thanks to our users, contributors and supporters.