Tendermint Core

At its core, Tendermint is a replicated state machine engine. It ensures that every correct node in the network processes the same transactions in the same order, leading to identical application state.

• Deterministic Execution: The application logic must be deterministic; given the same transaction and state, it must produce the same result on every node. Non-determinism is a fault.
• Block Execution Flow: 1) Transactions are gossiped via the mempool. 2) The proposer bundles them into a block. 3) The block undergoes the BFT voting process. 4) Upon commitment, it is delivered to the application via DeliverTx and the state is updated.

Tendermint uses a weighted round-robin proposer selection algorithm and a two-phase voting protocol with validator sets to achieve consensus.

• Validator Set: A known set of validators, each with a voting power (often tied to a staked amount). The proposer for a given round is determined by the formula: proposerIndex = (round + height) % len(validators).
• Two-Phase Vote: Validators cast pre-votes and then pre-commits on a proposed block. A block is committed when more than two-thirds of the total voting power pre-commits for it in the same round. This structure prevents equivocation and ensures agreement.

Tendermint Core nodes form a peer-to-peer (P2P) network using a gossip protocol for efficient and robust communication of transactions and blocks.

• Gossip Protocols: The network uses epidemic gossip to propagate transactions (via the mempool) and block proposals/votes. This ensures rapid dissemination and resilience to node churn.
• Secure Connections: Peer connections can be secured with Transport Layer Security (TLS) or other authentication mechanisms. The P2P layer is responsible for peer discovery and address book management to maintain network connectivity.

Tendermint provides a verification algorithm for light clients that allows resource-constrained devices to securely verify blockchain state with minimal data, relying on cryptographic commitments from the validator set.

• Light Client Protocol: A light client does not download full blocks. Instead, it syncs block headers (which contain the Merkle root of the application state and the validator set commitments). It verifies headers using validator set signatures.
• Fraud Proofs: While not natively implemented in the core protocol, the design enables the construction of fraud or validity proofs, allowing light clients to challenge incorrect state transitions.

Safety and Liveness are the two fundamental guarantees of a consensus protocol, often in tension with each other.

• Safety: The guarantee that 'nothing bad happens.' In consensus, this means all correct nodes agree on the same value, and the system never decides on an incorrect value. It ensures consistency and prevents forks.
• Liveness: The guarantee that 'something good eventually happens.' This means the system will eventually make progress and produce a decision, despite delays or failures.

Tendermint prioritizes safety over liveness in asynchronous network conditions, meaning it will halt rather than risk agreeing on conflicting values.

Finality is the irreversible guarantee that a block and its transactions will never be reverted or changed once agreed upon.

• Instant vs. Probabilistic Finality: Tendermint provides instant, deterministic finality. Once a block is committed in a round (after the 2/3+ pre-commit votes), it is permanently settled. This contrasts with probabilistic finality (e.g., in Nakamoto Consensus/Proof of Work), where confidence increases with subsequent blocks but reversal is always theoretically possible.
• Implication for Applications: Instant finality is critical for financial settlements and inter-blockchain communication, as assets can be considered transferred immediately upon block commitment.