Byzantine Fault Tolerance, and Why Four Validators in One Process Do Not Have Any

The idea, and the number that comes with it

A crash is a participant that stops. A Byzantine fault is a participant that keeps going and lies: sends one answer to you and a different one to somebody else, signs two conflicting things, or stalls selectively.

Tolerating that costs more than tolerating a crash. The classical bound is that a network of n participants can tolerate f of them being Byzantine only while n is at least 3f + 1, and agreement needs more than two thirds of them to concur.

What this code actually requires

The quorum is computed, not configured by hand. The formula in the source is two thirds of the committee, rounded down, plus one.

For four validators that is three. So this network tolerates exactly one faulty participant, which is what the bound allows at that size and is the smallest committee for which Byzantine tolerance means anything at all.

And then there is where those four validators live

We looked on the machine rather than reasoning from the chain.

one operating-system process four validator key directories inside one data directory one listening socket, bound to localhost

CONTROL: the socket table was read for the whole process rather than filtered to a port we guessed at, and it returned a single row. There is no peer-to-peer listener at all.

So the four validators are four identities inside one program on one computer. They do not talk to each other over a network, because there is no network for them to talk over.

Which means the tolerance is in the protocol and not in the deployment

The protocol tolerates one Byzantine participant out of four. That is real and it is correctly implemented.

The deployment provides nothing for it to work with. Anything that stops that one process stops all four validators at the same instant: a crash, an out-of-memory kill, a disk filling, a reboot, a bad deploy. That is four failures out of four, against a design that tolerates one.

Byzantine fault tolerance is a property of a protocol. Fault tolerance is a property of a deployment. They share a phrase and they are not the same claim, and this page exists because the phrase gets used as though they were.

The other two assumptions are unmet as well

The model assumes participants that can defect independently. One team operates all four.

The model assumes an adversary worth tolerating. There is none. The protocol is running correctly against a threat nobody is posing.

Neither of those is a scandal for a development network. Both of them are reasons the phrase should not be used as a security claim about this deployment.

What this arrangement does deliver, honestly

It is a development network and the software says so. The process is started in a development-network mode, by name. A single-process multi-validator network is a completely ordinary way to exercise a consensus implementation, and it is the right tool for the stage.

And it has been up continuously for weeks, measured as process uptime rather than as a percentage anyone would put on a marketing page.

That last reading also removes a candidate explanation for something else this estate has open. The chain produces blocks in bursts separated by long silences, and one obvious guess is that the node keeps restarting. It does not. The process has not restarted, so whatever produces the silences happens inside a running program.

What would actually change the claim

Separate machines. Separate operators. Separate failure domains.

Until then the honest sentence is that this network runs a Byzantine-fault-tolerant protocol, not that this network is Byzantine fault tolerant. The first is a fact about the code and the second is a fact about the world.

What you can check yourself, and what you cannot

solidus_getValidators, then solidus_getBlock across a dozen heights and collect proposer

You will find four distinct proposers. You will not find out how many machines they are on, how many processes, or how many people control them.

The number of distinct validators is not the number of failure domains, and no chain interface anywhere will tell you the difference. That is worth carrying to every other network you evaluate, not just this one.