Consensus Overview

The E Money Network uses the Proof-of-stake (PoS) consensus mechanism. The blockchain uses validator nodes to validate transactions and secure the chain. All validators need to stake EMYC tokens and should also get voted in by the EMYC tokens. The chain can support over 10+ validator nodes.

Tendermint is an easy-to-understand and mostly asynchronous BFT consensus protocol. The protocol follows a simple state machine that looks like the diagram below:

Participants in the protocol are called validators because they take turns proposing blocks of transactions and voting on them. Blocks are committed to a chain with one block at each height. A block may fail to be committed in which case the protocol moves to the next round and a new validator gets to propose a block for that height.

Two stages of voting are required to successfully commit a block. These stages are pre-vote and pre-commit. A block is committed when more than 2/3 of validators pre-commit the same block in the same round. In context, validators are performing something similar to a polka dance.

When more than two-thirds of the validator’s pre-vote for the same block we call that a polka. Every pre-commit must be justified by a polka in the same round. Validators may fail to commit a block for a number of reasons; the current proposer may be offline or the network may be slow.

Tendermint allows them to establish when a validator should 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 two-thirds of the validator set. A simplifying element of Tendermint is that it uses the same mechanism to commit a block as it does to skip to the next round.

Assuming less than one-third of the validators are Byzantine, Tendermint guarantees that safety will never be violated. In other words, validators will never commit conflicting blocks at the same height.

To do this it introduces a few locking rules which modulate which paths can be followed in the flow diagram. Once a validator pre-commits a block it is locked on that block.

Then the validator:

• must pre-vote for the block it is locked on

• can only unlock and pre-commit for a new block if there is polka for that block in a later round