What HotStuff Consensus Is, and Which of the Two in This Repository Actually Runs

The idea, in one paragraph

HotStuff is a leader-based agreement protocol for a set of participants that do not trust each other. Each round has one leader. The leader proposes, the others vote, and the votes combine into a certificate saying a quorum agreed.

Its contribution is what happens when a leader fails. In the older protocols this family grew out of, replacing a silent leader cost a burst of messages between every pair of participants. HotStuff makes the replacement cost the same as an ordinary round, which is why it became the default shape for this kind of chain.

What runs here, precisely

A block is committed when a certificate exists two rounds beyond it. Three linked rounds, which is the classic form of the rule.

Fork choice is the highest certificate a participant has seen, and a safety lock trails one round behind it, so a participant cannot vote for a conflicting proposal it has already committed against.

Rounds are driven by a deadline that starts at two seconds and doubles, capped at sixteen, which is the wait an outsider can measure indirectly.

The one bug worth publishing, because the fix names its own reason

A proposer broadcasts its proposal to its peers, and broadcast skips the sender. So the proposer never receives its own proposal back, and without special handling its own vote would never be counted.

The consequence is not cosmetic. A certificate would then require every other participant to vote, which leaves no margin for a single failure and makes a committee of fewer than four unable to certify anything at all.

The code records the proposer's own vote explicitly, so a certificate needs the ordinary quorum rather than unanimity among the others. The comment beside it states exactly that reasoning.

This is the same class of mistake as counting a room's votes while forgetting you are in the room, and it is worth publishing because the fix is where the reasoning lives.

There are two HotStuff implementations here, and the network runs the older one

A reader auditing this repository will find a second, complete implementation with its own module documentation, its own specification and its own tests.

The two differ in ways that matter:

the running one commits after three linked rounds; the second commits after two the running one waits two seconds, doubling to sixteen; the second starts at four hundred milliseconds, capped at three thousand two hundred milliseconds the second carries batch digests in a block body rather than transactions the second is a pure event-driven core with no timers or sockets of its own

The second implementation's own comment describes the first as the live one, which is a pleasing way to learn which is which, and not a substitute for checking.

So we checked, on the machine

The live process is the solidus-node binary, started in development-network mode against a four-validator data directory. That binary links the older consensus crate, which is readable in its dependency list.

CONTROL: the host holds exactly four validator directories, and the public endpoint returns exactly four distinct proposers. Two independent sides agree on the committee size.

And the binary is not stale for this question. It was built after the last change to the consensus source, so a source read of that crate describes what is running rather than what the next build would run. That is a per-crate fact and not a general one, and it was checked rather than assumed.

The committee, stated at full precision

Four validators, in development-network mode, operated by one team.

The protocol's target design is a committee of twenty-one drawn from a pool of up to a hundred. That is a specification and it is not deployed, and this page states both numbers in the same breath because separating them is how the two get blurred.

What Byzantine fault tolerance is buying here

The property HotStuff provides is agreement despite participants that lie, stall or equivocate.

On this network there is no adversary to tolerate. Four machines, one operator, one place. The protocol is running correctly against a threat model nobody is exercising.

That is not a criticism of the choice. Building the tolerant protocol before you have the adversary is the right order. It does mean a reader should not read "Byzantine fault tolerant" as a statement about this deployment's threat environment, because the environment currently has one participant in it.

And none of it is checkable from outside

No certificate is published, so an outsider cannot see a quorum, count the signers, or verify that any round concluded the way this page describes.

Everything above is a reading of source and of a running process, and the read surface offers no way to confirm it.