|
Unlike traditional BFT algorithms that have multiple validators with equal and static voting power, what
Tendermint does is each validator has coins staked to them. These coins can be either the validator operator's own coins or coins that are "delegated" to them by other users (think of these as Proof of Stake "mining pools"). Their "voting power" in the BFT consensus is weighted by their coin stake. Validators can come and go as part of the protocol, so essentially the previous validator set signs on the next validator set. Also, more people can delegate stake to existing validators. When a validator leaves, there is an unbonding period before they are allowed to withdraw their coins (this is the to put a minimum time length on a long-range attack). Tendermint also solves the nothing-at-stake problem because if a validator doubles signs on two competing blocks, this is byzantine behavior that is recognized and punished by slashing their staked coins on both forks (staked coins act as both weight for BFT voting power and as security deposits). One assumption that Tendermint makes as opposed to Nakamoto Consensus systems is that at least 66% of validators have to be running in order for the system to make progress. In Nakamoto consensus, even if a lot of miners are down, the existing miners can still propose blocks. This is, however, a double edged sword, as what seems top be "down validators" might actually be a network partition. In Nakamoto consensus, even a temporary partition would lead to parallel forks, while in Tendermint, this would not happen, as the system will stall instead of forking. Nakamoto Consensus is availability favoring, while Tendermint is consistency favoring. Tendermint works very well for both Proof of Stake and Proof of Authority systems, which is makes it particularly useful for both public and private settings, and deals with byzantine faults in both, as opposed to just crash faults as in protocols like Paxos and RAFT. |