A Closer Look at Tendermint’s Core Components and Connectivity – Part 2

Tendermint is a blockchain platform that combines a Byzantine fault tolerant (BFT) consensus engine with a generic application interface.

Tendermint allows developers to create decentralized applications (DApps) that can run on any programming language and achieve fast and final transactions.

In this essay, I will explain the core components of Tendermint, such as the the node, mempool and p2p.I will also explain how a simple key-value store (KVStore) application running on Tendermint consensus.

This essay will demonstrate the features and benefits of Tendermint as a flexible and scalable blockchain solution.

The first core: In a Tendermint P2P network, different types of nodes play specific roles and require specific connectivity. Let’s delve into the details of each node:

Seeds

Seeds serve as the initial contact point for new nodes.

They provide a list of active peers and then disconnect. Seeds should operate as full nodes with the PEX (Peer Exchange) reactor in a “crawler” mode, continuously exploring and validating the availability of peers.

The response from seeds should include a subset of the best-known peers, ensuring peer quality based on peer-exchange documentation.

Full Node

A new node requires several pieces of information to connect to the network. This includes a list of seeds, which can be provided via configuration files, flags, or hardcoded into the software.

Additionally, the node needs a ChainID (also known as Network at the P2P layer) and information about the recent block height (H) and hash (HASH) for the blockchain.

The values of H and HASH must be received and verified externally through means like trusted social consensus.

This validation is crucial for security in Proof-of-Stake blockchains. Once the node has the necessary information, it queries the seeds for peers related to its chain, establishes connections with those peers, and initiates the Tendermint protocols with successful connections.

When the node catches up to the specified height (H), it verifies that the block hash matches HASH. If not, Tendermint exits, and the user must retry, checking for potential issues with connected peers or invalid social consensus.

Validator Node

A validator node interfaces with a validator signing key and requires the highest level of security.

These nodes should not accept incoming connections but instead maintain outgoing connections to a controlled set of “Sentry Nodes.”

Sentry Nodes act as proxy shields, providing the validator node access to the rest of the network.

Validators who trust each other can accept incoming connections and establish direct private connectivity via VPN.

Sentry Node

Sentry nodes act as guardians for validator nodes, facilitating their access to the network. They should have strong connections with other full nodes in the network.

While sentry nodes can be dynamic, they should maintain persistent connections with an evolving random subset of other sentry nodes.

Sentry nodes always expect direct incoming connections from the validator node and its backups. In the PEX, they do not report the validator node’s address and may exercise stricter criteria for peer quality.

The second core component of Tendermint is the mempool. The mempool is a pool of unconfirmed transactions that are waiting to be included in a block.

The mempool is managed by each validator node independently, and it performs several functions.

First, it validates the transactions according to the application logic and the Tendermint protocol. Second, it prioritizes the transactions based on their fees, sizes, and ages.

Third, it propagates the transactions to other nodes in the network.

Fourth, it removes the transactions that are already committed in a block or that are invalid or expired. The mempool size and rate limits are configurable and affect the performance and security of the network.

The third core: In a P2P network, such as Tendermint, peers are identified by maintaining long-term persistent identities through public keys.

Each peer has a unique ID derived from its public key. When connecting to a peer, the connection is established using the peer’s ID, IP address, and port.

Authenticated encryption is employed to verify that the peer possesses the corresponding private key, preventing man-in-the-middle attacks.

P2P connections in Tendermint use TCP, and upon successful connection, two handshakes occur: one for authenticated encryption and another for Tendermint versioning.

The encryption handshake utilizes X25519 keys and chacha20poly1305 for encryption. To ensure non-malleability, Tendermint integrates the Merlin keccak-based transcript hashing protocol.

The ABCI serves as the intermediary between Tendermint, the consensus engine, and your application, which operates as the actual state machine, akin to the Ethereum Virtual Machine for the Ethereum chain.

It comprises a collection of methods, each accompanied by corresponding Request and Response message types.

Transactions initiated by a decentralized application (DApp) are ultimately processed by your ABCI application subsequent to being validated by the Tendermint consensus mechanism.

The ABCI methods are distributed across four distinct ABCI connections:

• Consensus connection: This connection encompasses methods such as InitChain, BeginBlock, DeliverTx, EndBlock, and Commit. It operates under the direction of a consensus protocol and handles block execution.
• Mempool connection: Responsible for validating new transactions, the Mempool connection includes the CheckTx method. Transactions are verified here before they are disseminated or incorporated into a block.
• Info connection: Designed for initialization and user queries, the Info connection features methods like Info, SetOption, and Query.
• Snapshot connection: This connection facilitates the serving and restoration of state sync snapshots. It encompasses methods such as ListSnapshots, LoadSnapshotChunk, OfferSnapshot, and ApplySnapshotChunk.

There are two approaches for designing your ABCI (Application Blockchain Interface) application: the built-in app and the external app.

The built-in app entails running your ABCI application within the same process as Tendermint Core, which yields optimal performance.

However, it requires your ABCI application to be developed in Golang. Detailed instructions on building a built-in application can be found here: link to the guide.

On the other hand, the external application involves running your ABCI application separately from the Tendermint Core process.

In this setup, your ABCI application communicates with Tendermint Core via TCP, Unix domain socket, or gRPC.

This approach allows your ABCI application to be written in any programming language and provides enhanced security guarantees.

For guidance on building an external application in Java, you can consult this resource: link to the guide.

In conclusion, Tendermint is a blockchain platform that offers a BFT consensus engine and a generic application interface. Tendermint enables developers to create DApps that can run on any programming language and achieve fast and final transactions.

This essay explained the core components of Tendermint, such as the block structure, the mempool, and the RPC interface.

It also showed how to create a simple KVStore application using Tendermint and the ABCI.

This essay illustrated the features and benefits of Tendermint as a flexible and scalable blockchain solution. For further reading and learning, please refer to the links on references.

Reference: 

https://docs.tendermint.com/v0.34/app-dev/getting-started.html

https://medium.com/softblocks/explaining-how-tendermint-consensus-works-433066cbc465

https://youtu.be/AFiLxS7f1Lo?si=6wN0s5bISEJi2C8z

https://youtu.be/wko5DPM-9Gs?si=GW8gUwa-a5Txm1ow