TON DocsTON Docs
OnboardingNodesApplicationsAPIsSmart contractsTolkTolk languageTVMTON Virtual MachineFoundationsBlockchain foundations

Catchain 1.0 overview

This page describes the legacy Catchain 1.0 consensus protocol. For the modern consensus version, read the whitepaper: Catchain 2.0: Simplex Consensus in TON.

Catchain is a communication protocol between actors. It does not execute the consensus algorithm itself but prepares the data required for the decision-making of a higher-level component: Block Consensus Protocol (BCP). The main purpose of the protocol is to allow validators to send messages that explicitly depend on other messages, possibly produced by different actors. Dependencies are encoded in such a way that a node receiving a message can download the referenced messages and verify their validity.

Problem

No network can guarantee that

  • Messages will be delivered.
  • Messages will arrive in the order they were sent, even if there are 2 messages between 2 nodes.

Actors are assumed to intentionally try to break consensus. The system must avoid situations where such actors prevent honest actors from making progress.

Assumptions

Each node knows the ADNL address and the public key of every other node. Thus, every pair of nodes can ensure each other's authenticity and establish an encrypted channel. The ADNL protocol is used to set up a private overlay network, which allows a node to send encrypted messages to a specific address or broadcast messages.

Protocol capabilities

Logical capabilities

At the logical level, the protocol provides causality preservation when sending messages. In other words, it lets a validator declare which messages cause other messages and guarantees that processing message A, which depends on messages B and C, only happens after messages B and C are processed.

Formal capabilities

The protocol implements a CRDT over the set of messages known to each node and achieves eventual consistency. As a synchronization mechanism, it uses the idea similar to vector clock with modifications that preserve eventual consistency even when some nodes are Byzantine.

Catchain 1.0 works over the ADNL protocol to maintain message integrity, at-least-once delivery guarantees, and message authenticity.

Choosing neighbor nodes

Catchain selects five neighbors at random and periodically refreshes the list each random interval between 60 and 120 seconds in the current configuration. Note that the neighbor relation is not symmetric: if B is a neighbor of A, it does not imply that A is also a neighbor of B.

In the current implementation, Mersenne Twister is used to pick the random interval for refreshing the neighbor list. It is seeded with values from std::random_device, whose behavior is platform-dependent.

Message identification

The seqno of each node is the count of messages that node has sent in the current round. A node must increment this number after each send message. Nodes not following that rule are considered Byzantine. The Catchain protocol detects such nodes, as described in Handling Byzantine nodes.

Every Catchain message is uniquely identified by the pair (sender; sender's seqno, body hash).

A Catchain message can declare any other messages by any node as a dependency. These dependencies are stored in the message body. Every Catchain message must declare the previous message from the same node as a dependency. Otherwise, the message is considered malformed and ignored by honest nodes. If a Catchain message has seqno equal to 0, the previous message for it is genesis: the name for the initial state of the system.

The same set of participants can take part in multiple catchain rounds, so the message identifier is extended with the round identifier to distinguish messages across rounds. Multiple-round scenarios are omitted in this article.

Example message flow