Using Tendermint as a Finality Gadget

Archived Tendermint
1

Motivation

A hot topic in blockchain consensus study is to combine a probabilistic-finality consensus (PoW/BABE/LMD-GHOST) with a fast-finality consensus (GRANDPA/Casper). This allows to harvest the benefits of both chains - if the network is bad/partitioned, the system can still produce blocks using the probabilistic-finality consensus, and as the network resumes, the system could quickly finalize the blocks that are produced by the probabilistic-finality consensus.

However, after extensive study on existing protocols such as BABE/GRANDPA and LMD-GHOST/Casper, we found these protocols are pretty complicated and hard to use - their BFT properties are pretty hard to analyze and understand, and their implementations are highly coupled with their specific implementations.

The objective here is to use Tendermint as a finality gadget, make it as a module so that it can easily be reused to finalize another probabilistic-finality consensus/chain.

Setup

We assume a node in the network has two components:

  • A client of the TM chain, where the chain is used to finalize another probabilistic-finality chain; and
  • A client of the probabilistic-finality chain, or pChain in short. The chain has its own consensus, ledger model, and/or state-transfer function.

Both clients are can be run in a single process or different processed connected by RPCs.

Finality Gadget

For each block produced by the TM chain proposer, it will contain the last view of the pChain, either a hash or a header of the pChain tip observed by the TM chain validator. Upon receiving a TM chain block (proposing), a validator may have several different cases:
1, The tip does not existing in its pChain client; or
2, Its pChain client has synchronized the pChain tip and verified the correctness of the tip; or
3, The tip is invalid.

In case 1, the TM validator will ask the pChain client to synchronize the tip and verify the correctness before sending PREVOTE messages. If the tip is verified (case 2), then the TM validator will send PREVOTE/PRECOMMIT messages as normal TM consensus does. If the tip is invalid, the TM validator will not vote the TM block, and thus this round will timeout and a new proposer will be elected.

Note that the finality gadget doesn’t allow an invalid tip is included in the TM chain block, which is not supported by ABCI. And thus we need ABCIx to allow validating a TM block before voting.

For the pChain, it will apply a fork-choice rule we call TM-first fork-choice rule:

  • It will never re-organize the pChain before a block that is finalized by the TM chain
  • For the blocks/forks that are not finalized, it will use its local fork-choice rule, e.g., the longest chain for PoW or LMD GHOST, etc.

This ensures the following two properties:

  • A finalized block of pChain by the TM chain will be always finalized; and
  • The finalized block will enjoy the security brought by the TM chain.

Finalizing Multiple Chains

Note that the TM chain can include multiple tips of multiple independent pChains, and thus all pChains can enjoy benefits of the fast finality and shared security brought by the TM chain - a basic idea of sharding.

Comparison with GRANDPA

GRANDPA is a finality gadget proposed by Polkadot. Compared to TM, GRANDPA votes on chains instead of blocks:

  • All validators of the TM BFT only vote for a specific block of the pChain. And if a validator does not observe the block, it needs to synchronize with peers and verify it before PREVOTE, which creates the opportunity of making the round timeout;
  • GRANDPA allows a validator to vote a parent of a specific pChain block proposed by the leader, and thus agree on the best “intersection” (GHOST in GRANPA term) of the chains voted by all validators. This reduces the possible timeout to synchronize the pChain block, however, this creates further complexity and corner cases in BFT.
1 Like