Decentralized Systems · Proof of Stake

Key Question

How does Tendermint combine PBFT-style consensus with proof-of-stake for instant finality?

Deep Dive

Tendermint (2014, Jae Kwon) is the engine behind the Cosmos ecosystem. Unlike Ethereum’s probabilistic finality (a block is “probably” final after enough confirmations), Tendermint gives instant finality: once a block is committed, it’s final. No forks, no reorgs. The tradeoff: validators must be locked into a round until consensus is reached.

The consensus round is a three-phase protocol, directly adapted from PBFT:

Round Structure:

Validator Set (bonded by stake)
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│ Validator│  │ Validator│  │ Validator│  │ Validator│
│   A     │  │   B     │  │   C     │  │   D     │
│ (25%)   │  │ (25%)   │  │ (25%)   │  │ (25%)   │
└────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘
     │            │            │            │
     └────────────┴────────────┴────────────┘
                        │
              Proposer (rotates round-by-round)
                        │
                ┌───────┴───────┐
                │   PROPOSE     │ ← Proposer sends a block
                └───────┬───────┘
                        │
                ┌───────┴───────┐
                │  PRE-VOTE     │ ← Each validator broadcasts
                └───────┬───────┘   a prevote for the block
                        │
                ┌───────┴───────┐
                │ PRE-COMMIT    │ ← If 2/3+ prevotes received,
                └───────┬───────┘   broadcast precommit
                        │
                ┌───────┴───────┐
                │   COMMIT      │ ← Block finalized!
                └───────────────┘

For a block to commit at height H:

The proposer broadcasts a block.
Validators broadcast Prevote(H, block). If 2/3+ prevotes arrive, the block is “polka’d.”
Validators broadcast Precommit(H, block). If 2/3+ precommits arrive, the block is committed.
A new round begins at height H+1.

If a round fails (no block gets 2/3+ precommits), a new round starts with a new proposer and an exponentially increasing timeout (1s, 3s, 7s, …). This ensures liveness even under adversarial conditions.

Failed round with timeout escalation:

Round 1 (timeout=1s) → proposer A, no decision
       ↓
Round 2 (timeout=3s) → proposer B, no decision
       ↓
Round 3 (timeout=7s) → proposer C, block committed

Validator set changes happen at “end-block” through Cosmos governance. Bonded validators can be added or removed between blocks. The protocol uses a “stored” validator set for the current height and a “next” set for the next height — no need for complicated epoch transitions.

Comparison with Ethereum:

Property	Tendermint	Ethereum Beacon Chain
Finality	Instant (after 1 round)	Probabilistic (~12.8 min for finalization)
Forking	Never	Possible (resolved by GHOST)
Max validators	~100-300 (practical)	Unlimited (500K+)
Liveness assumption	1/3 must be online	1/3 must be online
Message complexity	O(n²) per round	O(n) per slot (via committees)

Tendermint sacrifices validator count for simplicity and instant finality. Cosmos chains typically run 100-150 validators, each with significant stake. This makes Tendermint suitable for application-specific blockchains that need fast, predictable finality.

Check Your Understanding

What fraction of validators must precommit for a block to be finalized in Tendermint?
What happens if a Tendermint round fails to reach consensus?
Why can’t Ethereum use Tendermint’s approach for its 500,000+ validator set?

The “So What?”

Tendermint proves that classical BFT consensus can work in permissionless settings by adding stake-based validator selection. It’s the go-to architecture for chains that need instant finality and can tolerate a smaller validator set — most Cosmos zones, Binance Chain, and several enterprise blockchains.

✏️ Exercises

Proof of Stake & Modern Consensus: Exercises

Exercise 1: Nothing-at-Stake and Slashing

Consider a proof-of-stake system with 10 validators, each with 10% of the total stake. At block height 100, a network partition occurs: 5 validators see fork A, and 5 see fork B. Under a naive (no slashing) PoS design, explain:

What each validator would do
What happens to the two forks over time
How adding a slashing condition that punishes double-signing changes the outcome

Exercise 2: Ethereum Committee Calculation

The Ethereum Beacon Chain uses a fixed committee size of 128 validators per slot. A validator is assigned to exactly one committee per epoch. Given:

Total active validators: 100,000
Slots per epoch: 32
Committee size: 128

Calculate:

How many validators are actively attesting in each slot?
How many committees exist per slot?
How often does each validator attest per epoch (on average)?
What fraction of total validators attests per slot?

Exercise 3: Comparing Committee Selection

Consider three protocols:

Ethereum: Committees selected via RANDAO (public randomness, all validators partitioned into fixed-size committees each epoch)
Tendermint: No committees — every validator votes on every block
Algorand: Committees selected via VRF (private randomness, each user independently computes their eligibility)

Answer:

Which protocol has the lowest communication overhead for selecting a committee? Why?
Which protocol is most vulnerable to adaptive corruption (attacker can corrupt validators mid-consensus)? Why?
For each protocol, estimate the fraction of total validators that participate in each block’s consensus. Is it all validators, a random subset, or a fixed subset?

👁️ View Solutions

Proof of Stake & Modern Consensus: Solutions

Exercise 1 Solution

Without slashing:

Each validator would sign blocks on whichever fork they see. The 5 on fork A sign A’s blocks; the 5 on fork B sign B’s blocks.
Both forks grow at the same rate (5 validators each). Neither fork outpaces the other. When the partition heals, all 10 validators see both forks. Since there’s no cost to signing both, each validator could sign on both forks, collecting rewards from whichever one ultimately wins. The forks never naturally resolve — the system is deadlocked.
Additionally, if validators can “hedge” by signing both, they have no incentive to pick one fork over the other.

With slashing (penalty for signing conflicting blocks at the same height):

During the partition, validators on fork A sign A’s blocks. Validators on fork B sign B’s blocks.
When the partition heals, each validator sees both forks. They MUST pick one. If they sign a block on both forks at the same height, they get caught (the two signatures prove equivocation) and lose their entire stake.
Since each validator will only sign one fork, the fork with more validators (or more accumulated stake-weight) will pull ahead. The smaller fork is abandoned, and consensus is restored.

Exercise 2 Solution

Given:

Total validators: 100,000
Slots per epoch: 32
Committee size: 128

Step 1 — Validators attesting per slot: Each slot has multiple committees of 128 validators. The total validators attesting per slot is: Total validators / Slots per epoch = 100,000 / 32 = 3,125 validators per slot

Step 2 — Committees per slot: Validators per slot / Committee size = 3,125 / 128 = 24.4

So there are approximately 24-25 committees per slot, each with 128 validators.

Since committees must be whole numbers: Ethereum assigns exactly 24 or 25 committees per slot depending on the epoch. Some validators may not be assigned every epoch (they “skip” a slot).

Step 3 — Attestation frequency per validator: Each validator attests exactly once per epoch (they’re assigned to one specific slot and one committee). Average: 1 attestation per epoch = 1 per 32 slots

Step 4 — Fraction attesting per slot: 3,125 / 100,000 = 3.125% of all validators attest each slot

Exercise 3 Solution

1. Lowest communication overhead for committee selection:

Algorand has the lowest overhead. Committee selection is done locally via VRF — each user computes a VRF with their secret key and the seed. No messages are exchanged to form the committee. The user simply knows they’re selected and includes their VRF proof in their first message.

Ethereum requires a distributed random beacon (RANDAO) which involves all validators contributing randomness over an entire epoch. Tendermint doesn’t select committees (everyone votes), so the overhead is zero for selection but maximal for voting.

2. Most vulnerable to adaptive corruption:

Tendermint is most vulnerable. Since the validator set is fixed for a long period, an attacker can observe who the validators are and corrupt them between rounds. In Algorand, each committee is freshly selected by VRF, so an attacker cannot predict who will be on the next committee until they reveal themselves. Ethereum is intermediate: committees rotate per epoch, giving a window for corruption.

3. Fraction of validators participating per block:

Protocol	Fraction participating	Type
Tendermint	100%	All validators, every block
Ethereum	~3.125% (see Ex 2)	Fixed-size committee per slot
Algorand	~0.1-1% (adjustable via threshold)	Random VRF-selected subset

Tendermint uses all validators for maximum security at the cost of O(n²) communication. Ethereum uses fixed-size committees to scale to 500K+ validators. Algorand uses VRF-based random subsets to get the best of both worlds: scalable but unpredictably selected.