Nimbus developers work to reduce Ethereum’s Prysm dependency

The necessity of client diversity

Ethereum requires multiple independent software implementations to prevent a single bug from disrupting the network. A diverse ecosystem of clients protects the chain because a bug in one client leaves the other implementations standing. If a single client holds more than 66% of the validator market share, a critical error can paralyze finality or cause a chain fork. If a client with over 66% market share suffers a critical error, it can disrupt the chain or cause a fork, meaning those validators cannot return to the original chain without facing a 32 ETH slashing penalty. Developers aim to keep the market share of every client below 33% to ensure that no single implementation can prevent finality. MigaLabs data shows Lighthouse holds 52.55% of consensus nodes, while Prysm holds 18%.

The network uses different types of nodes that handle data and verify transactions differently. Full nodes download all blocks and transactions to ensure they follow consensus rules. They keep the full state of the blockchain but can discard older data through a process called pruning to save disk space. Archive nodes store a complete history of every state since the beginning of the blockchain and never delete data. This makes archive nodes useful for services that require historical data, though they use more resources. Light nodes download only block headers and request remaining information from full nodes when necessary.

Ethereum also manages validator funds through different credential formats. The 0x00 prefix uses legacy BLS-based signing keys for withdrawals. The 0x01 prefix uses execution-layer addresses and became dominant after the Shanghai/Capella upgrade. EIP-7002 allows execution-layer triggered withdrawals through a system contract at a deterministic address. This contract accepts and validates withdrawal requests from authorized parties and maintains an ordered queue of pending exit requests. It enforces access controls and implements rate limiting to prevent spam.

Nimbus developers and technical improvements

Nimbus developers work to decrease the network’s dependency on dominant consensus clients like Prysm. Jacek Sieka, the Head of Research Development at Status, proposed a historical block roots accumulator for the Capella upgrade. This accumulator improves block verification times for archive nodes that process large batches of blocks. This change increases the state growth of consensus layer nodes from 10KB/year to 20KB/year. Etan Kissling, a developer for Nimbus, proposed code changes to the Engine API to resolve field encoding differences between the execution layer block header and the consensus layer execution payload header. These differences create additional overhead and complexity for building wallets and light clients.

Ethereum architecture separates the execution layer and the consensus layer into distinct clients. Execution layer clients, formerly called Eth1 clients, handle transaction processing, EVM execution, state management, and P2P networks for block propagation. Consensus layer clients, formerly called Eth2 clients, manage the Proof of Stake protocol, block proposals, validator rewards, and consensus P2P networks. These two layers coordinate through the Engine API. Nimbus, written in Nim, is a lightweight and efficient consensus client. Its low resource consumption makes it an option for individual participants and institutional operators seeking to maximize server capacity.

Prysm concentration and the 2026 outage

A bug in Prysm version v7.0.0 recently caused a 25% drop in voting participation. The flaw caused nodes to generate unnecessary old states while processing outdated attestations. At epoch 411,448, the network reached only 74.7% voting participation. This figure sits 9% below the two-thirds supermajority needed to maintain regular operation. If voting participation falls below two-thirds of the total staked ETH, the Ethereum network loses finality. A loss of finality can cause layer-2 bridges to freeze, rollups to pause withdrawals, and exchanges to increase block confirmation requirements.

Before this incident, voting participation routinely exceeded 99%. MigaLabs data from the period before the incident shows Lighthouse at 48.5% and Prysm at 22.71%. In September 2021, Prysm ran on 68.1% of consensus nodes. This concentration of market share creates a significant risk for the network. In May 2023, the Ethereum mainnet lost finality twice within 24 hours due to bugs in Prysm and Teku. You should monitor your own client versions to avoid similar issues.

Roadmap and validator rewards

The Ethereum roadmap moves toward a rollup-centric architecture where the base layer provides security and data availability. Pectra introduced EIP-7702 in May 2025. Fusaka deployed PeerDAS (EIP-7594) in December 2025. The network targets Glamsterdam for 2026 and Hegota for 2027.

Validators earn rewards from two different protocol layers. Consensus layer rewards are protocol-issued and predictable, based on attestations and block proposals. Execution layer rewards come from user priority fees and MEV during block proposals. These rewards vary based on on-chain activity.

How will the network reach a stable distribution of clients before the next major upgrade?