Broad Overview

There are varying ways to implement Proof-of-Stake algorithms, but the two major tenets in Proof-of-Stake design are chain-based PoS and Byzantine Fault Tolerant-based PoS. Tendermint is a BFT-based PoS design, Casper the Friendly Ghost is a chain-based PoS design, and Casper the Friendly Finality Gadget is a hybrid of the two.

The CAP Theorem in computer science returns the impossibility of providing more than 2 out of 3 guarantees in distributed data systems: availability, consistency, and partition tolerance. Chain-based PoS algorithms tend to choose availability over consistency, where having availability means that all transactions will be processed, but at the expense of a consistent state replicating across the network. BFT-based PoS algorithms, on the other hand, strictly choose consistency over availability.

Byzantine Fault Tolerant-based Proof-of-Stake

Byzantine Fault Tolerant (BFT) consensus algorithms stem from a rich body of research spanning more than 30 years. Tendermint (2014) is the first adaptation of Proof-of-Stake consensus derived from the Practical Byzantine Fault Tolerant (PBFT) algorithm introduced by Castro and Liskov in 1999. BFT-based PoS protocols pseudo-randomly assign a validator the right to propose new blocks during a multi-round voting process. However, committing and finalizing blocks depends on a supermajority — a >⅔ quorum — of all validators signing off on the proposed block. This may take several rounds, or polkas, before blocks become finalized. BFT systems can only tolerate up to a ⅓ of failures, where failures can include arbitrary or malicious behaviour.

Tendermint Core

Tendermint consists of two chief technical components: a blockchain consensus engine and a generic application interface. The consensus engine, called Tendermint Core, ensures that the same transactions are recorded on every machine in the same order. The application interface, called the Application Blockchain Interface (ABCI), enables the transactions to be processed in any programming language.

At the core, Tendermint works as a round-based voting mechanism which makes the consensus protocol. A round is broken up into a three-step process through which validators propose blocks, signal commitment intent and then sign to commit new blocks. This mechanism yields a secure state replication machine for atomic broadcast with an added layer of accountability — safety faults are perfectly attributable in Tendermint.

Tendermint consensus algorithm begins with a set of validators. Validators maintain a full copy of the blockchain and are identified by their public keys. They take turns proposing blocks at each new block height. There is at most one proposer per voting round. Each proposal is signed by a validator’s corresponding private key so that the validator responsible for it can be identified if some failure were to occur. The rest of the validators then vote on each proposal, signing their votes with their private keys. This constitutes a single round. But it may take several rounds before a new block is committed due to network asynchrony.

A voting round depicting a circuit of partially synchronous proposals, followed by asynchronous voting. After the proposal step, validators only make progress after hearing from ⅔ or more of the other validators. The dotted arrow extends the consensus into atomic broadcast by moving to the next height.

Validators may fail to commit a block for a number of arbitrary reasons; i.e., the current proposer may be offline, or a network may be experiencing latency. Tendermint allows a validator to be skipped. Validators wait a small amount of time to receive a complete proposal block from the proposer before voting to move to the next round. This reliance on a timeout is what makes Tendermint a weakly synchronous protocol, rather than an asynchronous one. However, the rest of the protocol is asynchronous, and validators only make progress after hearing from more than ⅔ of the validator set. As such, Tendermint requires 100% uptime from a supermajority of its validators because if ⅓ or more are offline or partitioned, the network may halt.

Assuming less than ⅓ of the validators are Byzantine, Tendermint guarantees that safety will never be violated — that is, validators will never commit conflicting blocks at the same height. Therefore, a Tendermint-based blockchain never forks.

The design decision behind Tendermint so far really prioritizes safety and finality over liveness. There’s a fairly high likelihood that in the real world, the system will actually halt, and the participants will have to organize outside of the protocol in some sort of software update to restart the system.

Tendermint formed the basis for Casper research when very few people in the cryptocurrency community understood what the insight was and why it was valuable. The insight was: If the chain itself is highly fault-tolerant, then you can rely on the chain to make good decisions about who can produce blocks. If the chain itself is less reliable, then you end up with this chicken and the egg problem, which is what doomed every other consensus algorithm that came before.

This design decision is perceived as inferior to availability-prioritizing protocols like Ethereum and Bitcoin. The trade-off in Bitcoin is: If its network goes split brain, Bitcoin loses all of its safety guarantees in various attack scenarios. It’s the overall theme of finality, which is the idea that if your confidence interval is less than 100%, that the chain you’re following is the correct chain, and you’re using that chain to select who is going to produce the next block, then once you’ve diverted to an unsafe chain, there’s no clear path back to the correct chain.

Properties at a Glance

Provable liveness in partially synchronous network.

Safety threshold: ⅓ of validators.

Public/private chain compatible.

Instant finality: 1–3 seconds depending on number of validators.

Consistency-prioritizing.

Consensus safety.

Chain-based Proof-of-Stake

Chain-based Proof-of-Stake simulates Proof-of-Work consensus, in that the protocol assigns the right to commit a single new block to a pseudorandomly-selected validator, where the new block is hash-linked to a parent block of the previously longest chain. Chain-based PoS relies largely on synchronous networks, generally prioritizing availability over consistency. Casper(s) is an adaptation of the core ideas of Tendermint to a setting that prefers liveness over safety.

Casper the Friendly Finality Gadget

While Casper the Friendly Ghost is an explicit PoS construct, Casper the Friendly Finality Gadget (CFFG) is a PoS overlay on top of the existing Ethereum PoW proposal mechanism — a hybrid PoW/PoS implementation led by Vitalik Buterin.

Neither Bitcoin nor Ethereum’s PoW consensus protocols make ‘final’ decisions, and blocks can potentially be reorganized to some past block height. A block is said to be ‘final’ when there is no chance of it being revised. Since Proof-of-Work provides no such revision guarantees, it is not actually considered to be consensus safe. Instead, blocks get probabilistically more finalized as we move deeper into the chain. In order to add the desired properties of finality and 51% attack resistance to the Ethereum blockchain, implementing CFFG logic would ideally provide this effect.

Casper the Friendly Finality Gadget will be rolled out in multiple steps to conservatively transition Ethereum’s PoW security model to a wholly PoS one over time. The first iteration of Casper will be implemented as the hybrid PoW/PoS protocol discussed here. The final iteration of Casper will likely take the lessons from both CFFG and CTFG toward a complete PoS protocol.

CFFG is a hybrid between chain-based PoS and Byzantine Fault Tolerant-based PoS, as it borrows from both schools of thought. Its modular overlay design makes upgrading the existing PoW chain easier, as it is a more conservative approach to upgrading the system to an entirely different consensus model.

Casper’s application logic lives inside a smart contract. To become a validator in Casper, one must hold ether (ETH) and deposit some ETH to be leveraged as stake into the Casper smart contract. The block proposal mechanism in the first iteration of Casper remains the same: It still uses Nakamoto PoW consensus where miners create the blocks. In order to finalize blocks, however, Casper’s PoS overlay takes control and has its validators vote on blocks trailing the PoW miners.

A key component of Casper’s PoS consensus are checkpoints. Casper assesses finality at 50 block increments called checkpoints and each 50 block segment is called an epoch. This process happens via validators sending a Vote message during each epoch.

It takes two epochs, i.e., two rounds of voting, in order to finalize a checkpoint one epoch ago. For example, when > ⅔ of the validators, aka. “supermajority”, vote on a checkpoint, c, that checkpoint is said to be “justified”. Now in the next epoch, when a supermajority vote on that checkpoint, c’, two things happen: c’ becomes justified and c is finalized. The epoch of c is referred to as the last finalized epoch (LFE).

In review, a block1 is said to finalize, f, after two conditions are met:

A supermajority (>⅔) of validators vote on block1 in epoch1, thereby justifying block1. A supermajority (>⅔) of validators vote on block2 in epoch2, the direct child block to block1, thereby finalizing block1 during epoch2.

In an ideal execution, a block is finalized in the following steps:

⅔ Vote block1 → Justify block1 → ⅔ Vote block2 → Finalize block1

Where block2 is direct child of block1

Here’s an illustration of Casper’s finality gadget logic. Each block represents a checkpoint. Lines represent 50 blocks (epoch) between each checkpoint. A block becomes the last finalized epoch (LFE) when its child block is justified.

Validators are paid once a checkpoint is finalized. However, if there are two finalized checkpoints on two distinct forks at the same block height, thus violating safety, then slashing conditions come into play and at least ⅓ of the total security deposits staked will be slashed. Evidence for fault attribution when safety violations occur can be broadcasted as a transaction to the PoW miners. PoW miners then mine the block with the evidence transaction, and the validator(s) who submitted the evidence is rewarded a finder’s fee. When this happens, the guilty validator(s) who signed the conflicting blocks is slashed on both chains.

Now what happens if a miner were to execute a brute force PoW attack? Casper’s now finalized blockchain prevents PoW attackers, even with 51% or more of the hashpower, from rewriting history beyond the latest checkpoint. Thus, the Casper protocol provides safety. Unlike Casper the Friendly Ghost, because Casper the Friendly Finality Gadget is just an overlay on top of a separate proposal mechanism, Casper cannot guarantee liveness, as liveness depends on the proposal mechanism.

Validators are incentivized to converge on a canonical chain because they are penalized more over time as validators continue to vote on two divergent chains. With the formalization of ‘slasher 2.0’, validators are not just punished for double-voting but are penalized for voting on the incorrect fork. This does present a ‘discouragement’ predicament where validators end up opting out of voting from fear of getting slashed if there were a fork and they were unsure which one to choose.

Properties at a Glance

Finality: ~20 minutes to finality. Finalized blocks once every 50 blocks (an epoch) makes the blockchain future-proof against brute force PoW mining attacks.

Consensus safety.

Provable liveness.

Availability-prioritizing.

Casper the Friendly Ghost

Casper the Friendly Ghost (CTFG) is Vlad Zamfir’s correct-by-construction (CBC) consensus protocol tailored toward combatting an oligopolistic real world environment. CTFG is a PoS adaptation of the Greedy Heaviest-Observed Subtree, or GHOST protocol in PoW, for its fork choice rule. The guiding design principle behind Casper the Friendly Ghost is based on cryptoeconomics using formal methods aimed to achieve estimate safety. CTFG is a pure Proof-of-Stake concept, unlike Casper the Friendly Finality Gadget’s hybrid protocol detailed in the earlier section.

“Casper was born as simply ‘the friendly ghost’, an adaptation of GHOST to Proof-of-Stake, complete with incentives that would make a cartel ‘friendly’ to non-cartel validators.”

— Vlad Zamfir, The History of Casper — Chapter 5

Similar to Proof-of-Work, Casper the Friendly Ghost (CTFG) trades off consistency for availability. In particular, blocks are not finalized; rather, they grow “safer” the deeper down the chain they get. Casper the Friendly Ghost is similar to CFFG in that the head of the chain is always progressing faster than the blocks are getting finalized.

The key differentiator in Casper’s PoS proposal mechanism from Tendermint’s is that instead of pseudo-randomly elected leaders, validators in the former can propose blocks based on the blocks that they’ve seen.

The unique functionality Casper offers is parameterizable safety thresholds. Similar to taking 6 confirmations in Bitcoin to determine economic finality, “estimate safety” in CTFG provides that one validator can have a different safety threshold than another validator. Casper’s design goal is to allow validators to pick their fault tolerance thresholds while the network maintains the low overhead of Proof-of-Work.

A core advantage that Casper has over Tendermint is in the number of validators that the network can accommodate at any given time. Since block creation in Tendermint requires finality at time of creation, block times should be short. And in order to achieve short block times, there needs to be a limit to the number of validators Tendermint PoS can accommodate. Since neither CTFG or CFFG require safety at time of block creation, the Ethereum network would be able to accommodate much more than, say, 100 validators.

Properties at a Glance