Skip to main content

​
State machine

At its core, a blockchain is a replicated deterministic state machine: multiple nodes independently execute the same state machine over the same ordered inputs and, as a result, reach the same state. A state machine is a computer science abstraction in which a system can exist in many possible states, but only one at any given time. It is defined by:
  • a state S, which represents the current data of the system, and
  • transactions T, which describe how the state can change.
Given a state S and a transaction T, the state machine computes a new state S': 
+--------+                 +--------+
|        |                 |        |
|   S    +---------------->+   S'   |
|        |    apply(T)     |        |
+--------+                 +--------+
In practice, transactions are grouped into blocks to improve efficiency. A block B is an ordered list of transactions, and the resulting state is obtained by applying each transaction sequentially: 
+--------+                              +--------+
|        |                              |        |
|   S    +----------------------------> |   S'   |
|        |   For each T in B: apply(T)  |        |
+--------+                              +--------+
In a blockchain context, the state machine must be deterministic. This means that if a node starts from a given state and replays the same transactions in the same order, it will always arrive at the same final state. Determinism is essential: without it, nodes would diverge and consensus would be impossible. The Cosmos SDK gives developers full control over how the application state is defined, which transaction types are supported, and how state transitions are executed. Building state machines with the Cosmos SDK is covered in later sections. First, however, you’ll learn how this state machine is replicated across the network using CometBFT.

​
CometBFT: Networking and Consensus

Thanks to the Cosmos SDK, developers only need to define the application state machine. CometBFT then takes care of replicating that state machine across the network by handling networking and consensus. In this context:
  • Networking refers to how nodes discover each other, exchange messages, and propagate transaction and block data across a peer-to-peer network.
  • Consensus refers to how nodes agree on a single, ordered sequence of blocks to apply to the state machine, even in the presence of faulty or malicious nodes.
                ^  +-------------------------------+  ^
                |  |                               |  |   Built with Cosmos SDK
                |  |  State-machine = Application  |  |
                |  |                               |  v
                |  +-------------------------------+
                |  |                               |  ^
Blockchain node |  |           Consensus           |  |
                |  |                               |  |
                |  +-------------------------------+  |   CometBFT
                |  |                               |  |
                |  |           Networking          |  |
                |  |                               |  |
                v  +-------------------------------+  v
CometBFT is an application-agnostic engine responsible for these two layers. Through its networking layer, CometBFT propagates transaction and block data between nodes. Through its consensus layer, it deterministically orders transactions into blocks that can be safely applied by the application. Importantly, CometBFT does not interpret the meaning of transactions. It treats them as raw bytes and is only responsible for their dissemination and ordering. To agree on a single transaction order, CometBFT relies on a Byzantine Fault Tolerant (BFT) consensus algorithm. The CometBFT consensus algorithm operates over a set of special nodes called validators. Validators are responsible for proposing and voting on blocks. At any given block height, there exists a validator set V. One validator from V is selected as the proposer for the next block. A proposed block is considered committed if more than two-thirds of the voting power in V sign both a prevote and a precommit for that block, and if all transactions it contains are valid according to the application. The validator set itself is part of the application state and can be updated by rules defined in the state machine.

​
ABCI

CometBFT passes transactions to the application through an interface called the ABCI (Application Blockchain Interface), which the application must implement. ABCI defines the methods through which CometBFT sends ordered transaction bytes to the application for execution and receives the corresponding results, without needing to understand the application’s state or logic. 
              +---------------------+
              |                     |
              |     Application     |
              |                     |
              +--------+---+--------+
                       ^   |
                       |   | ABCI
                       |   v
              +--------+---+--------+
              |                     |
              |                     |
              |       CometBFT      |
              |                     |
              |                     |
              +---------------------+
Note that CometBFT only handles transaction bytes. It has no knowledge of what these bytes mean. Its responsibility is to propagate transactions across the network and deterministically order them into blocks. CometBFT then delivers the raw transaction bytes to the application via the ABCI and expects a response indicating whether execution was successful. Here are the most important ABCI methods:
  • CheckTx: When a transaction is received by CometBFT, it is passed to the application to perform basic validity checks. CheckTx is used to protect the mempool of full nodes against spam transactions. A special handler called the AnteHandler executes a series of validation steps, such as signature verification and fee checks.
    If the checks pass, the transaction is added to the mempool and relayed to peer nodes. No state changes occur during CheckTx since the transaction has not yet been included in a block.
  • DeliverTx: When a valid block is received by CometBFT, each transaction in the block is passed to the application via DeliverTx and executed in order. This is the stage at which state transitions occur. The AnteHandler is executed again, followed by the corresponding Msg service handlers for each message in the transaction.
  • BeginBlock / EndBlock: These methods are executed at the beginning and end of every block, regardless of whether the block contains transactions. They can be used to trigger automatic or time-based logic. Care must be taken to avoid computationally expensive or unbounded operations, as these would affect block processing time and could halt the chain.
For a complete description of all ABCI methods, see the CometBFT ABCI documentation. Any application built on CometBFT must implement the ABCI interface in order to communicate with the local CometBFT engine. In practice, application developers do not implement ABCI directly. The Cosmos SDK provides a standard implementation in the form of baseapp.