DOCSEARCHbyAlgolia
Submit Docs

Tendermint Specification

website·Indexed 36 days ago

https://docs.tendermint.com/

Technical specifications for Tendermint Core, covering the consensus framework, P2P networking, and the ABCI++ application interface. It includes detailed documentation on light client verification, fork detection, proposer selection, and the PBTS system model, as well as requirements for application state management and evidence handling.

Tokens
124K
Snippets
382
Records
794
Agent score
70%

What's inside Tendermint

  1. Overview of the Tendermint Consensus Reactor

    The Consensus Reactor manages the internal state machine of the Tendermint consensus service via the ConsensusState service. Upon startup, it initiates a Broadcast Routine and the ConsensusState service. For every peer added to the reactor, it manages a known peer state and maintains three specific routines: Gossip Data Routine, Gossip Votes Routine, and QueryMaj23Routine. The reactor is responsible for decoding peer messages and updating peer states or forwarding specific messages (ProposalMessage, BlockPartMessage, and VoteMessage) to the ConsensusState module.

  2. Overview of ABCI++ and its improvements over ABCI

    ABCI++ extends the original ABCI by allowing the application to intervene at three critical stages of consensus execution: proposal creation, proposal validation, and vote transmission/reception. This enables block proposers to perform application-dependent work (e.g., signature aggregation, state transition proofs) and allows validators to perform checks beyond simple block execution. Additionally, ABCI++ simplifies block delivery by coalescing BeginBlock, DeliverTx, and EndBlock into a single FinalizeBlock method.

  3. Overview of the Tendermint Light Client Attack Detector

    The Light Client Attack Detector is a 'second line of defense' for Tendermint light clients. While standard light client verification is safe as long as more than 2/3 of voting power is correct, the Attack Detector identifies scenarios where faulty full nodes (who may have been validators) generate conflicting blocks of the same height to fool a light client.

    How it works:

    1. The light client maintains an address book of known full nodes.
    2. It selects a primary node to provide a new light block and a verification trace (a sequence of light blocks).
    3. After verifying the block with the primary, the detector cross-checks this data with a small subset of secondary nodes.
    4. If an attack is detected (conflicting light blocks), the detector computes evidence data.
    5. This evidence is used by full nodes to isolate faulty nodes still within their unbonding period and report them via the ABCI to the application for punishment.

  4. Overview of Tendermint Core State Sync

    State sync allows new nodes to rapidly bootstrap and join the network by discovering, fetching, and restoring state machine snapshots. The state sync reactor manages two primary responsibilities: serving local state machine snapshots to new nodes and discovering/fetching snapshot chunks for empty local applications during bootstrapping.

  5. Overview of the Tendermint Consensus State Machine

    Tendermint uses a round-based protocol to determine the next block at a specific height (H). A single round consists of three primary steps: Propose, Prevote, and Precommit. The optimal sequence of transitions is: NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight. Multiple rounds may be required if the proposer is offline, the proposal is invalid, or +2/3 of votes are not received in time.

  6. Overview of Tendermint and IBC fork detection specifications

    The Tendermint and IBC fork detection specifications are currently a work in progress. The documentation is split across several key areas:

    • Light Node Fork Detection: Defined in detection.md, focusing on the 'proof of fork' data structure used to submit evidence to full nodes.
    • IBC Context Requirements: Defined in req-ibc-detection.md, which includes necessary updates to ICS 007 to support Tendermint fork detection.
    • Functional Sketches: Defined in draft-functions.md, outlining the required functions for fork detection, proof generation, and verification for Relayers and IBC on-chain components.
    • Conceptual Discussions: Defined in discussions.md, covering light client supervisor context and lightstore semantics.

  7. Overview of Tendermint Remote Signer

    The remote signer option allows Tendermint validators to store their validator keys on a separate machine from the main node. This minimizes the attack surface by ensuring that if the main server is compromised, the validator keys remain secure on a different machine. The system uses a client-server architecture where Tendermint requests public keys or signatures for proposals and votes from the remote signer. For security, it is recommended to use a Virtual Private Cloud (VPC) or a private connection.

  8. Overview of Tendermint Core

    Tendermint Core is a blockchain application platform that provides the infrastructure (equivalent to a web-server, database, and supporting libraries) for blockchain applications written in any programming language. Technically, it performs Byzantine Fault Tolerant (BFT) State Machine Replication (SMR) for arbitrary deterministic, finite state machines.

  9. Overview of the Blocksync Reactor

    The Blocksync Reactor enables peers that are far behind the current consensus state to catch up quickly by downloading multiple blocks in parallel, verifying their commits, and executing them against the ABCI application.

    Full nodes run the reactor as a service to provide blocks to others. New nodes run it in fast_sync mode, actively requesting blocks until they are caught up, at which point they disable fast_sync and switch to the Consensus Reactor.

  10. Overview of Tendermint Core

    Tendermint is software designed for the secure and consistent replication of an application across multiple machines. It provides Byzantine Fault Tolerance (BFT), meaning the system continues to function correctly even if up to 1/3 of the machines fail or act maliciously. Consistency is guaranteed such that every non-faulty machine sees the same transaction log and computes the same state.

  11. Overview of the ABCI++ Interface

    ABCI++ (Application BlockChain Interface) is the communication interface between Tendermint (the state-machine replication engine) and the Application (the state machine being replicated).

    Key architectural details:

    • Communication Flow: Tendermint always initiates the methods by sending Request messages and receiving Response messages from the Application.
    • Implementation: The Application is responsible for implementing the logic to handle all ABCI++ methods.
    • Language Agnostic: All messages and methods are defined using protocol buffers (located in proto/tendermint/abci/types.proto), allowing the Application to be written in any programming language.

  12. Overview of Tendermint Ivy formal specifications and proofs

    The Tendermint BFT consensus algorithm is formally specified and verified using the Ivy verification tool. The following files constitute the specification and proof suite:

    • tendermint.ivy: Specification of the Tendermint algorithm based on 'The latest gossip on BFT consensus'.
    • abstract_tendermint.ivy: A verification-friendly abstract specification of Tendermint.
    • classic_safety.ivy: Proof that if every two quorums share a well-behaved node, no two well-behaved nodes will disagree.
    • accountable_safety_1.ivy: Proof that if two well-behaved nodes disagree (assuming every quorum has at least one well-behaved node), there is evidence of at least f+1 misbehaving nodes.
    • accountable_safety_2.ivy: Proof that malicious nodes cannot construct evidence to frame well-behaved nodes.
    • network_shim.ivy: The network model and a shim object for interfacing with the specification.
    • domain_model.ivy: Specification of the underlying domain model (rounds, values, quorums, etc.).