The initial name of the protocol during the first stage of research and development was Catch-chain (a trap blockchain) because essentially it is a separate blockchain for the prevention of malicious events impeding consensus achievement on the main TON blockchain. Later on, its name was shortened to Catchain.
The consensus algorithm of TON is described as tolerant towards system breaches connected with the so-called Byzantine fault. Byzantine Fault Tolerance is a popular buzzword nowadays and it’s important to clarify here what it means.
All distributed ledgers are built to manage a system, and the problem with Byzantine generals formulated by Leslie Lamport, a computer scientist, actually predates cryptocurrency. Imagine several separated Byzantine generals in the middle of the war.
They can send messages to each other but they are still not on the same page with how the war will go on and so they vote. A manipulative person with a decisive vote can send a vote for the attack to some generals and a vote for retreat — to others. Naturally, this only an example but one can imagine the very same problem occurring in the first-gen blockchains.
A truly Byzantine Fault-tolerant blockchain is the one where new blocks (and therefore new actions) are made only after total verified consensus. This consensus prevents the creation of new similar blockchains.
There is a type of blockchains where this is not the case with Bitcoin Cash as perhaps the most notable result. The new blockchains are usually built with Byzantine Fault tolerance to ensure the integrity of the community behind the system and the system itself.
Catchain pertains to the latter type of algorithms in which preliminary agreement occurs before a new block is created, and midway forks are impossible. The Catchain consensus model is based on the already existing algorithm practical Byzantine Fault Tolerance (Hyperledger Fabric, Zilliqa) having increased resistance to Sybil attacks in asynchronous networks and also has similarities with Tendermint (Cosmos) and dBFT algorithms (Neo, Algorand). However, there is a number of principal differences that allow us to call it a separate algorithm type.
For a particular task of creation of new blocks on one of the TON blockchains (masterchain or one of its active shardchains), a separate group consisting of several validators is created. The members of this group are used to create a private overlay network inside ADNL as well as for the launch of a corresponding sample of the Catchain protocol.
The process of consensus achievement consists of several rounds which occur inside one catchain. At one point in time, there can be several rounds because some stages of a single round can intersect with others.
Every single round ends either with a collective acceptance of a candidate block suggested by one of the members of the process or with the acceptance of a ‘zero candidate’, i.e. without accepting any of the suggested candidates.
The round is considered finished only after a potential candidate collects the signatures of over two-thirds of all validators, and this event can be added into a special CommitSign, after which the process will automatically start to participate in the next round (with a new identifier).
The events of one validation round occur in the following order:
As mentioned above, in blockchains with traditional protection mechanisms using Proof-of-Work and Proof-of-Stake and their hybrids, for a small period, several correct blockchains or forkchains can coexist simultaneously of which one is further selected.
The TON Blockchain system built on the base of small blockchains (multi-blockchains) practically leaves no chances for the occurrence of such events as it uses the blockchain as a means of broadcasting of such messages, i.e. uses the blockchain as a means of broadcasting inside a certain group of processes. However, there exists a very small probability of creation and simultaneous confirmation of several identical blocks.
For prevention of such scenarios, there was created the Catchain protocol that allows to detect forks at the earliest stage of their emergence by way of creation of two (or more) different versions of the same message and sending them to different groups of peers.
The block signatures on Catchain are created in such a way that the confirmation of forks (i.e. proof of their intended creation) becomes extremely simple as in reality a hash of a very small structure (containing a magical number, an ordinal number of the block and the hash of the rest of the message) is signed. As a result, to prove a fork, there are only needed two small structures and two signatures.
As soon as there is a fork found (it usually happens in recursive loading of dependencies of some messages), one group of nodes starts ignoring the messages of a neighbouring group and all of its subsequent messages, as they are not accepted and broadcast elsewhere. Yet, the messages created before the fork was found can be loaded if they are referenced in the messages (blocks) created by the processes that do not know about this fork before they refer to them.
Then another service message containing a corresponding proof of fork is created and broadcast to all the neighbouring nodes. From this moment on, all subsequent messages lose dependence from the messages of a known ‘bad’ node and in case of violation, these messages will be rejected by all the ‘honest’ peers in this group.
Every node stores its copy of the list of ‘bad’ members of the network (the ones that have created at least one fork). This list is constantly updated in case of detection of a new fork. Thus, if the sender is identified as ‘bad’, his or her message will be ignored and rejected.
It is well-known that the Catchain protocol was first developed in December 2018 and tested on 300 nodes distributed all over the world. During the test, the time in which consensus on block creation was achieved constituted 6 seconds.
Later on, in December 2019 there was issued a document that showed that the Catchain protocol was 100% ready. Therefore, a conclusion can be made that all the preliminary tests were successfully passed.
However, it was mentioned in the status section that the complete documentation was only 95% ready, while the final document was only released a year after in February 2020.
Thus, it is logical to conclude that the theoretical part is quite thoroughly worked out and presents a fully completed original consensus model ready for realization in the mainnet.
Create your free account to unlock your custom reading experience.