Running Ethereum validators post-Fusaka upgrade

PeerDAS and the new data requirements

PeerDAS implements a networking protocol that allows nodes to perform data availability sampling. This protocol uses gossip for distribution, discovery for finding peers of particular data custody, and peer requests for sampling. Each node is responsible for maintaining a deterministic set of column subnets and custodying their data as a function of their node ID. A node can reconstruct the entire data matrix if it acquires at least 50% of all columns. If a node has less than 50%, it can request the necessary columns from its peer nodes. This process helps scale the network without increasing node bandwidth and storage requirements. The upgrade uses 1D Reed-Solomon erasure coding to extend each 128 KB blob into a redundant structure. These extended blobs form the rows of a matrix, and each row is divided into cells. The smallest verifiable units are cells, and these are authenticated with KZG commitments. A node samples entire columns from its peers every slot. PeerDAS uses a randomized sampling scheme to prevent data withholding attacks. This scheme reduces the probability of a successful attack as the network size grows. The 68% bandwidth reduction associated with these changes changes the workload for consensus clients. The upgrade introduces a limit of 6 blobs per transaction. The BPO1 update on December 9, 2025, increased this to 10 target and 15 maximum blobs. The BPO2 update on January 7, 2026, increased this to 14 target and 21 maximum blobs.

Hardware and capital requirements for professional nodes

Teku and Lighthouse clients have higher resource demands after the Fusaka upgrade. The combination of running both execution and consensus layer clients, blob data handling, and growing state size makes 32 GB of RAM the minimum for stable operation, not the recommended spec. The 32 GB RAM configuration is insufficient for stable operation after Fusaka. Operators report memory pressure during peak network activity when using 32 GB. 64 GB of RAM is the practical floor for stability. High-performance storage is another requirement. The blockchain state exceeds 3 TB. Institutional operators use NVMe SSDs with high Drive Writes Per Day ratings. A 2 TB enterprise NVMe outperforms a 4 TB consumer drive in production validator environments. Consumers should avoid low quality SSD disks. The storage requirements for blobs also increased. BPO1 storage for blob data is 160 GiB. BPO2 storage for blob data is 224 GiB. Consensus clients also require 100 Mbps bandwidth. Validators should prioritize 8 to 12 cores to handle the load.

Validator capital requirements remain at 32 ETH minimum to activate. The Pectra upgrade in May 2025 raised the maximum effective balance to 2,048 ETH. This allows large holders to consolidate operations into fewer validators. Consolidating into a high-balance validator under the 0x02 credential type reduces operational overhead. However, consolidation concentrates slashing risk. A double-vote or surround vote event on a 2,048 ETH validator has a proportionally larger penalty than on a 32 ETH validator. Institutional operators use DVT to distribute keys across multiple machines. The Ethereum Foundation used DVT-lite in March 2026 for its 72,000 ETH deployment. DVT-lite uses open-source tools like Dirk and Vouch from Attestant to spread signers across geographic regions and client pairings. This approach reduces client-diversity risk.

The Raspberry Pi 5 and Nimbus staking kit

Nimbus runs on ARM64. The Raspberry Pi 5 includes a Broadcom BCM2712 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU with cryptography extensions, 512KB per-core L2 caches, and a 2MB shared L3 cache that provides a significant improvement over the 1.5 GHz processor used in the 2019 model. It provides up to 8GB of LPDDR4X-4267 SDRAM. The 8GB version costs $80 and the 4GB version costs $60. You must use a 5V/5A USB-C power supply. The setup requires an SSD connected to a USB 3.0 port. Nimbus requires overclocking the CPU from 1.5 GHz to 1.8 GHz. A 64GB microSD card is also needed. After installing the OS, users increase the swap size to 2048MB. Users then use the scp command to copy signing keys to the Pi. The Pi 5 has dual 4Kp60 HDMI display outputs and a VideoCore VII GPU. It is a small device with a standard 40-pin header. The installation involves adding the Status APT repository and using APT to install the beacon node and validator client. The Raspberry Pi 5 also has a single-lane PCIe port for fast peripherals. The Pi 5 uses LPDDR4X-4267 SDRAM, which is faster and more power-efficient than previous versions. The device has two four-lane 1.5Gbps MIPI transceivers for camera and display connections. Will the increase in blob capacity eventually make the Pi 5 insufficient?

Client diversity and network stability

Client diversity maintains network resilience. If more than 33% of validators run the same consensus client, a bug in that client causes mass slashing. The Prysm bug at Epoch 411448 demonstrated this risk. After the Fusaka upgrade, the Prysm client encountered an error while processing old validator attestations. Network synchronization participation fell to 75% and voting participation dropped to 74%. Lighthouse, Teku, and Nimbus clients continued to operate normally. This diversity prevented a full network halt. The share of validators using the Prysm client decreased from 22.71% to 18% after the incident. The Prysm development team and the broader community resolved the bug quickly. By epoch 411712, voting participation recovered to 99% and synchronization participation rose to 97%. Using different client combinations like Lighthouse and Nethermind or Teku and Besu protects against correlated slashing. The network remains stable because the distributed design allows different clients to handle blocks even when one client fails. This multi-client architecture is the reason Ethereum avoided a total halt when the Prysm bug occurred.