E Money Network
  • Introduction to E Money Network
  • Add E Money Network to Metamask
  • Wallet Integration
  • E-Money Tokens
  • E Money Network Mainnet and Testnet Explorer​
  • E Money Network Faucet
  • E Money Network Whitelist
  • Launching Your Dapp on E Money Network
    • Developing and Deploying Contracts​
    • Contract Verification​
    • Contract Security Checks
  • Validating on E Money Network
    • Validator nodes
    • How to run a validator node on E Money Network
    • Running Validator Node
    • EMYC Token’s Utility & Purpose
    • Install Validator node​
  • Tendermint & EVMOS
    • ABCI Overview
      • Intro to ABCI
      • Motivation
    • Gas & Fees
      • How are Gas and Fees Handled on E Money Network?​
      • Gas calculation and Transaction execution on E Money Network
    • Keyring
    • Signing
    • Transactions
    • A Note on Determinism
    • Consensus Overview
  • E Money Card FAQs
    • Is a Know Your Customer (KYC) process required to obtain an E Money Card?
    • What details are required for the KYC process?
    • Do I need to create an E Money Wallet to order an E Money Card?
    • What happens if I lose my seed phrase?
    • What happens if I forget my password?
    • How do I order an E Money Card, and are there any costs?
    • Can I have the card shipped to a different address than the one I provided during KYC?
    • My card has been delivered, what’s next?
    • What should I consider before using the E Money Card for payments?
    • Where can I use the E Money Card?
    • Can I add the E Money Card to online payment services like Google Pay and Apple Pay?
    • Which countries’ citizens are eligible to apply for an E Money Card?
    • Are there any fees I should be aware of as a user?
    • How do taxes apply when using the E Money Card?
  • E Money Card Fees
  • Branding and Logos
Powered by GitBook
On this page
  1. Tendermint & EVMOS
  2. ABCI Overview

Intro to ABCI

PreviousABCI OverviewNextMotivation

Last updated 3 months ago

​The ​(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​. 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.

Tendermint Core
ABCI specification