Nine clients, no single point of failure.

Ethereum is a specification, not a program

“Ethereum” sounds like one program running in a lot of places. It isn’t. Ethereum is a set of rules, a specification, and anyone can write software that follows them. Many teams have. A node today runs two pieces: an execution client, which processes transactions and runs the virtual machine, and a consensus client, which handles proof-of-stake agreement. Each has several independent implementations.

On the execution side: Geth, Nethermind, Besu, Erigon and Reth, among others, written in Go, C#, Java and Rust. On the consensus side: Prysm, Lighthouse, Teku, Nimbus, Lodestar and Grandine, again spread across different languages and teams. That is roughly nine independent codebases keeping the same chain, built by people who share neither a codebase, a language, nor in many cases an employer.

Why writing the same thing many times is a feature

Reimplementing the same protocol half a dozen times looks wasteful. For reliability it’s the entire point.

A bug in one client is, by definition, a bug in only that client. Nodes running the other implementations are unaffected, because they don’t share the flawed code. When a single client goes down, its operators have a problem, but the network keeps producing blocks on the other clients while they fix it. The failure is contained to a slice of nodes rather than the whole chain.

That is exactly what happened in the November 2020 chain split. A bug in one execution client caused nodes running it to diverge, and the infrastructure that depended on that client (Infura, and much of the wallet ecosystem) had a bad day while the canonical chain kept going. Independent implementations are what made it a contained infrastructure incident rather than a network halt.

The other side: diversity has to be real

There’s a catch. The protection only holds if the clients are actually spread out. If one execution or consensus client runs on the large majority of the network, a bug in that client stops being contained. It becomes a bug that can hit most of the network at once, a genuine risk to liveness and to finality.

So the Ethereum community treats client diversity as something to manage, not assume. Public trackers watch how validators are split across clients, and there’s sustained pressure on operators to run minority clients, keeping any single implementation below the threshold where its bugs could threaten the whole network. It’s a live engineering concern, and treating it as one is part of why the record holds.

The contrast

The value of all this is clearest by comparison. A network that leans on a single dominant client has a single point of failure by construction: one bug, in one codebase, can take down everything at once. That’s a large part of why some fast chains have halted repeatedly where Ethereum has not. The redundancy isn’t free. It’s slower to coordinate and it means duplicated effort. What you buy with it is a network that doesn’t stop when one of its programs does.

The takeaway

“Ethereum has never gone down” gets read as a claim that its software is perfect. It’s closer to the reverse. The software isn’t perfect: individual clients have had bugs, and will again. The chain stays up because no one client has to be perfect. That’s what client diversity buys, and it’s a quiet, unglamorous reason the counter on the front page has never reset.