3 0 2
The Crypto.com Chain documenation is now moved to https://chain.crypto.com/docs.
You will be redirected in 10 seconds.
Redirect Now
Crypto.com Chain Crypto.com Chain

# Consensus

Crypto.com Chain prototype uses Tendermint Core as its consensus algorithm. It utilizes the ABCI (Application BlockChain Interface), which allows applications written in different languages to interact with the blockchain.

This interface allows a "plugging" custom applications with Tendermint. Specifically, if the application is written in Go, it can be linked directly with the chain; otherwise, a connection can be established via 3 TCP or Unix sockets. The details of this interface can be found here.

As Crypto.com Chain Core code is written in Rust, we utilize (and aim to continually improve) the rust-abci library.

For the overall architecture of Tendermint Core consensus engine with the ABCI, please refer to this infographic and this guide.

# Client: Interacting with the blockchain

To query a blockchain or submit a transaction, one can use the Tendermint RPC for that. Details of this RPC and its mechanism can be found in here.

Currently, it supports 3 methods:

  1. URI over HTTP
  2. JSON-RPC over HTTP
  3. JSON-RPC over WebSockets

The RPC HTTP server is executed on every full node. The RPC methods are equivalent, but WebSockets allow realtime subscription to different events.

:::tip NOTE Tendermint RPC is for internal use only, as it doesn’t support rate-limiting, authentication etc., so it shouldn’t be directly exposed to the internet. :::

At this moment, it’s also recommended to use tendermint lite as a local proxy for the Chain client libraries when connecting to remote full nodes.

The Chain client interaction with Tendermint is currently done via a custom client-rpc crate.

The main RPC methods are used broadcast_tx_(a)sync and abci_query.

broadcast_tx_(a)sync

This method takes “tx” parameter which is application-specific binary data (see transaction serialization for details on Chain binary format). The transaction binary payload is either hex-encoded (when called with the URI method) or base64-encoded (when called with JSON-RPC).

abci_query

Currently the main usage is that given a path “account”, one can query the current “staked state” of some address (which is provided as the “data” field).

# Application hash

The “application hash” is a compact representation of the overall ABCI application state. In Tendermint, ABCI applications are expected to be deterministic. Therefore, given the same input (block/consensus events + transaction data), one can expect that the applications will update its state in the same way. Eventually, we can compare the hash value of its application state with the others and verify the consistency.

In Crypto.com Chain, the application hash is a Blake3 hash of several components:

  • Root of a Merkle tree of a valid transaction in a given block;
  • Root of a sparse Merkle trie of staked states (see accounting details);
  • Binary serialized state of rewards pool (see serialization for details on Chain binary format and genesis for details on “state”);
  • Serialised network parameters.

# Conventions

As genesis information is taken from the Ethereum network, the same address format is used (i.e. hexadecimal encoding of 20-bytes from a keccak-256 hash of a secp256k1 public key).

For Tendermint data, its conventions must be followed:

  • Validator Key pair: base64-encoded Ed25519 key-pair;
  • Addresses: the first 20 bytes of SHA256 of the raw public key bytes.

For Crypto.com Chain, it has the following conventions:

  • Chain-ID: this is a string in Tendermint’s genesis.json. In Crypto.com Chain, it should end with two hex digits;
  • Network-ID: a single byte determined by the two last hex digits of Chain-ID. It is included in metadata of every transaction to specify the network;
  • Transactions, addresses etc.: Please refer to transaction binary serialization, accounting model, addresses / witness and format / types.

← Genesis →