Intro to ABCI

​The Tendermint Core ​(the "consensus engine") communicates with the application via a socket protocol that satisfies the ABCI. To draw an analogy, let's use a well-known cryptocurrency, the Bitcoin. Bitcoin is a cryptocurrency blockchain where each node maintains a fully audited Unspent Transaction Output (UTXO) database. If one wanted to create a Bitcoin-like system on top of ABCI, Tendermint Core would be responsible for

• Sharing blocks and transactions between nodes

• Establishing a canonical/immutable order of transactions (the blockchain)

The application will be responsible for

• Maintaining the UTXO database

• Validating cryptographic signatures of transactions

• Preventing transactions from spending non-existent transactions

• Allowing clients to query the UTXO database.

Tendermint is able to decompose the blockchain design by offering a very simple API (i.e. the ABCI) between the application process and consensus process.

The ABCI consists of 3 primary message types that get delivered from the core to the application. The application replies with corresponding response messages.

The messages are specified in the ABCI specification​. The DeliverTx message is the workhorse of the application. Each transaction in the blockchain is delivered with this message. The application needs to validate each transaction received with the DeliverTx message against the current state, application protocol, and cryptographic credentials of the transaction.

A validated transaction then needs to update the application state by binding a value into a key values store or by updating the UTXO database. The CheckTx message is similar to DeliverTx, but it's only for validating transactions. Tendermint Core's mempool first checks the validity of a transaction with CheckTx, and only relays valid transactions to its peers.

For instance, an application may check an incrementing sequence number in the transaction and return an error upon CheckTx if the sequence number is old. Alternatively, they might use a capabilities-based system that requires capabilities to be renewed with every transaction. The Commit message is used to compute a cryptographic commitment to the current application state that is to be placed into the next block header and this has some useful properties.

Inconsistencies in updating that state will now appear as blockchain forks which catches a whole class of programming errors. This also simplifies the development of secure lightweight clients as Merkle-hash proofs can be verified by checking against the block hash and that the block hash is signed by a quorum. There can be multiple ABCI socket connections to an application.

Tendermint Core creates three ABCI connections to the application; one for the validation of transactions when broadcasting in the mempool, one for the consensus engine to run block proposals and one more for querying the application state.

Message handlers need to be designed very carefully so that these are usefully utilised in their associated blockchain. The proposed diagram below shows an architecture which is a good place to start. It illustrates the flow of messages via ABCI.