---
# System prepended metadata

title: Tendermint Consensus without mining

---

# Tendermint Consensus without mining
- Link:: https://tendermint.com/static/docs/tendermint.pdf
- Introduction
    - Consensus algorithm is a modified [[DLS Protocol]]
    - There is a difference in how a miner (or staker) can achieve power to disrupt consensus
        - Extrinsic: mining equipment or cheap electricity.
        - Intrinsic: the stake
    - Current (pre 2014) staking chains suffer from the nothing at stake problem
    - Delegated proof of stake is an attempt to solve the nothing at stake problem by having the delegates "expose/stake" their coins.
    - Security is simpler for intrinsic cryptocurrencies because the cost of double spend attack can be determined beforehand and this acts as a deterrence. The penalty is also very high.
- Terms
    - **Nodes** connect to each other through **gossip**
    - Nodes keep a recorded copy of the total history of the sequence of events
    - **Users** have an **account** identified by its **public address**
    - Nodes propagate **transactions** if the transactions follow the protocol rules
- Block Structure
    - ![](https://firebasestorage.googleapis.com/v0/b/firescript-577a2.appspot.com/o/imgs%2Fapp%2Fsebastians_mind_map%2FYRprgvdvwZ.png?alt=media&token=131f9bb6-ea3a-423c-a410-d8c8b59e3c7a)
    - Transactions are added to block
    - Validation and transaction hashes are merkle tree root hashes of the data in validation and transaction signatures
- Validators
    - Begin validating by posting a "bond transaction"
        - bond transaction
    - Once a validator is bonded, validators can participate in consensus by broadcasting **vote** transactions.
    - A fork occurs when "1/3 majority" cast votes for different blocks of the same height.
        - 1/3 majority
- Consensus
    - The [[FLP Impossibility]] is worked around through blocks and the assumption that an amount of work was put into the blocks.
        - The problem is the asynchronous nature of distributed computing.
    - A vote contains:
        - Heigh, round, type
        - Block hash
        - signature of vote
    - The round before the next block has the following steps, a round based-protocol is used to determine the next block:
        - Propose
            - The proposer sends a broadcast to its peers through gossip.  For a "lock-in-block" it will propose that block instead.
        - Prevote
            - Validators broadcast the "lock-in-block"
                - lock-in-block
        - Precommit
            - Each node makes a decision. If the node received 2/3rds of a precommits for a block, then the node goes into the Commit stage.
        - Commit
            - There are two parallel conditions.
            - 1. The node must receive the committed block. It then signs the committed block and broadcast a commit
            - 2. Waits for a majority of 2/3 of commits fotr the block. After wards it sets the CommitTime to the current time and transitions to the NewHeight.
