BFT Voting and Proof of History

Proof of work never gives a final yes. A block simply gets harder to undo as more blocks pile on top. The four co-ops' consortium chain wants something firmer: once a trade is recorded, it stays recorded. Byzantine fault tolerant (BFT) voting gives exactly that.

The rule

More than two-thirds voting yes makes a block final; under a third may misbehave.

A BFT protocol works with a known set of validators, each identified by a public key and sometimes weighted by stake. For each block:

1. One validator proposes a block.
2. Validators exchange signed votes, usually in two rounds.
3. When a block has votes from more than two-thirds of the validators, it is final. No later block can ever undo it.

Why two-thirds? Protocol papers write it with numbers: with n = 3f + 1 validators, up to f of them may be faulty, and a block needs 2f + 1 votes. With 4 validators, f is 1 and a block needs 3 votes. Any two groups of 2f + 1 validators must share at least f + 1 members, so at least one honest validator sits in both groups. An honest validator never votes for two conflicting blocks, so two conflicting blocks can never both become final.

The trade-offs: finality is fast, but classic BFT protocols send many messages per block, so their validator sets tend to stay small, from tens to a few hundred. And if more than a third of the validators are offline, the chain halts rather than forking. The Tendermint family (now CometBFT) and many permissioned chains use this approach, and Ethereum's proof of stake also finalizes blocks with a two-thirds vote of staked coins.

Proof of history (PoH) tackles a different problem: agreeing on time. Solana introduced it as a running chain of SHA-256 hashes, each one computed from the one before. Because every step needs the previous result, no number of computers working in parallel can speed it up, so the count of hashes works as a clock. Mixing an event's data into the sequence proves that the event already existed before every hash that follows it. PoH only orders events; Solana paired it with stake-weighted voting to actually agree on blocks.

The shortcut

For any validator count n: votes needed = the next whole number above two-thirds of n; faults tolerated = the largest whole number below one-third of n.

The trap is mixing up the two ideas in this lesson. BFT voting decides which block is final. Proof of history only timestamps and orders events; it is a clock, not a vote.

Drills

Answer fast — trust the rule.

Remember

• More than two-thirds voting yes makes a block final; under a third may misbehave.
• Shortcut: votes needed is the next whole number above two-thirds of n; faults tolerated is the largest whole number below one-third of n.
• Trap: BFT halts rather than forks when too many validators are down, and proof of history is a clock, not a vote.