From cbdf1b4015b3621254e97045f1537b783d39ed61 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Thu, 9 Oct 2025 03:37:25 +0100 Subject: [PATCH 01/16] add crossllink reference to catchain --- ton/catchain.mdx | 59 ++++++++++++++++++++++-------------------------- 1 file changed, 27 insertions(+), 32 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 1e9708b9..8f8c0ed7 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -11,19 +11,21 @@ _February 19, 2020_ The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [\[3\]](#ref-3). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. -The Catchain Consensus protocol builds upon the overlay network construction protocol and the overlay network broadcast protocol of TON Network ([\[3\]](#ref-3)). The Catchain Consensus protocol itself can be decomposed into two separate protocols, one more low-level and general-purpose (the Catchain protocol[¹](#footnote-1)), and the other the high-level Block Consensus Protocol (BCP), which makes use of the Catchain protocol. Higher levels in the TON protocol stack are occupied by the block generation and validation levels; however, all of them are executed essentially locally on one (logical) machine, with the problem of achieving consensus on the newly-generated block delegated to the Catchain protocol level. +## 1 Overview + +The Catchain Consensus protocol builds upon the overlay network construction protocol and the overlay network broadcast protocol of TON Network ([3](#ref-3)). The Catchain Consensus protocol itself can be decomposed into two separate protocols, one more low-level and general-purpose (the Catchain protocol[¹](#footnote-1)), and the other the high-level Block Consensus Protocol (BCP), which makes use of the Catchain protocol. Higher levels in the TON protocol stack are occupied by the block generation and validation levels; however, all of them are executed essentially locally on one (logical) machine, with the problem of achieving consensus on the newly-generated block delegated to the Catchain protocol level. Here is an approximate diagram of the protocol stack employed by TON for block generation and distribution, showing the correct place of the Catchain Consensus protocol (or rather its two component protocols): -- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [\[3\]](#ref-3) for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. +- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [3](#ref-3) for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. - **(TON) Block consensus protocol**: Achieves (byzantine fault tolerant) consensus on the block to be accepted as the next one in the current validator group for the masterchain or a shardchain. This level makes use of (the abstract interface of) the block generation and validation software, and builds upon the lower-level Catchain protocol. This protocol is explained in more detail in Section [3](#3-block-consensus-protocol). - **Catchain protocol**: Provides secure persistent broadcasts in an overlay network (e.g., the task group of validators for a specific shardchain or the masterchain dedicated to generation, validation, and propagation of new blocks in this shardchain or masterchain), and detects attempts of "cheating" (protocol violation) on the part of some participants. This protocol is explained in more detail in Section [2](#2-catchain-protocol). -- **(TON Network) overlay broadcast protocol**: A simple best-effort broadcast protocol for overlay networks in the TON Network as described in [\[3\]](#ref-3). Simply broadcasts received broadcast messages to all neighbors in the same overlay network that did not receive a copy of these messages before, with minimal effort dedicated to keeping copies of undelivered broadcast messages for a short period of time. +- **(TON Network) overlay broadcast protocol**: A simple best-effort broadcast protocol for overlay networks in the TON Network as described in [3](#ref-3). Simply broadcasts received broadcast messages to all neighbors in the same overlay network that did not receive a copy of these messages before, with minimal effort dedicated to keeping copies of undelivered broadcast messages for a short period of time. -- **(TON Network) overlay protocol**: Creates overlay networks (cf. [\[3\]](#ref-3)) inside the ADNL protocol network, manages neighbor lists for these overlay networks. Each participant of an overlay network tracks several neighbors in the same overlay network and keeps dedicated ADNL connections (called "channels") to them, so that incoming messages can be efficiently broadcast to all neighbors with minimal overhead. +- **(TON Network) overlay protocol**: Creates overlay networks (cf. [3](#ref-3)) inside the ADNL protocol network, manages neighbor lists for these overlay networks. Each participant of an overlay network tracks several neighbors in the same overlay network and keeps dedicated ADNL connections (called "channels") to them, so that incoming messages can be efficiently broadcast to all neighbors with minimal overhead. - **Abstract Datagram Network Layer (ADNL) protocol**: The basic protocol of the TON Network, that delivers packets (datagrams) between network nodes identified only by 256-bit abstract (ADNL) addresses, which effectively are cryptographic keys (or their hashes). @@ -31,7 +33,7 @@ This text aims to describe only the second and the third protocol in this suite, We would like to point out here that the author of this text, while providing the general guidelines of how this protocol should be designed (on the lines of "let's create a BFT-hardened group broadcast message system, and run a suitably adapted simple two-phase or three-phase commit protocol on top of this system") and participating in several discussions during the development and implementation of the protocol, is definitely not the only designer of this protocol and especially of its current implementation. This is the work of several people. -A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [\[5\]](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [\[3\]](#ref-3) and [\[4\]](#ref-4)) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [\[2\]](#ref-2)), even though it is based on slightly different principles. +A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [3](#ref-3) and [4](#ref-4)) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. ## 2 Catchain Protocol @@ -45,7 +47,7 @@ The main prerequisite for running (an instance of) the Catchain protocol is the For the specific task of creating new blocks for one of the blockchains (i.e., the masterchain or one of the active shardchains) of the TON Blockchain, a special task group consisting of several validators is created. The list of members of this task group is used both to create a private overlay network inside ADNL (this means that the only nodes that can join this overlay network are those explicitly listed during its creation) and to run the corresponding instance of the Catchain protocol. -The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([\[4\]](#ref-4) would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) +The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([4](#ref-4) would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) #### 2.2.1. Catchains are created in advance @@ -65,7 +67,7 @@ Note that the (ordered) list of nodes participating in a catchain is fixed in th ### 2.4. Messages in a catchain. Catchain as a process group -One perspective is that a catchain is a (distributed) process group consisting of $N$ known and fixed (communicating) processes (or nodes in the preceding terminology), and these processes generate broadcast messages, that are eventually broadcast to all members of the process group. The set of all processes is denoted by $I$; we usually assume that $I = \{1 \ldots N\}$. The broadcasts generated by each process are numbered starting from one, so the $n$-th broadcast of process $i$ will receive sequence number or height $n$; each broadcast should be uniquely determined by the identity or the index $i$ of the originating process and its height $n$, so we can think of the pair $(i, n)$ as the natural identifier of a broadcast message inside a process group.[⁴](#footnote-4) The broadcasts generated by the same process $i$ are expected to be delivered to every other process in exactly the same order they have been created, i.e., in increasing order of their height. In this respect a catchain is very similar to a process group in the sense of [\[1\]](#ref-1) or [\[7\]](#ref-7). The principal difference is that a catchain is a "hardened" version of a process group tolerant to possible Byzantine (arbitrarily malicious) behavior of some participants. +One perspective is that a catchain is a (distributed) process group consisting of $N$ known and fixed (communicating) processes (or nodes in the preceding terminology), and these processes generate broadcast messages, that are eventually broadcast to all members of the process group. The set of all processes is denoted by $I$; we usually assume that $I = \{1 \ldots N\}$. The broadcasts generated by each process are numbered starting from one, so the $n$-th broadcast of process $i$ will receive sequence number or height $n$; each broadcast should be uniquely determined by the identity or the index $i$ of the originating process and its height $n$, so we can think of the pair $(i, n)$ as the natural identifier of a broadcast message inside a process group.[⁴](#footnote-4) The broadcasts generated by the same process $i$ are expected to be delivered to every other process in exactly the same order they have been created, i.e., in increasing order of their height. In this respect a catchain is very similar to a process group in the sense of [1](#ref-1) or [7](#ref-7). The principal difference is that a catchain is a "hardened" version of a process group tolerant to possible Byzantine (arbitrarily malicious) behavior of some participants. #### 2.4.1. Dependence relation on messages @@ -99,7 +101,7 @@ Recall that we have assumed that any message depends on all preceding messages o m_{i,s} \in D \Leftrightarrow s \leq \text{Vt}(D)_i ``` -We say that the vector $\text{Vt}(D) = (\text{Vt}(D)_i)$ with $i \in I$ and $\text{Vt}(D) \in \mathbb{N}^I_0$ with non-negative components $\text{Vt}(D)_i$ is the vector time or vector timestamp corresponding to cone $D$ (cf. [\[1\]](#ref-1) or [\[7\]](#ref-7) for a more detailed discussion of vector time). +We say that the vector $\text{Vt}(D) = (\text{Vt}(D)_i)$ with $i \in I$ and $\text{Vt}(D) \in \mathbb{N}^I_0$ with non-negative components $\text{Vt}(D)_i$ is the vector time or vector timestamp corresponding to cone $D$ (cf. [1](#ref-1) or [7](#ref-7) for a more detailed discussion of vector time). #### 2.4.6. Partial order on vector timestamps @@ -165,7 +167,7 @@ Note that all messages created by the same sender $i$ in a catchain turn out to In this way each process $i$ generates a simple blockchain consisting of its messages, with each "block" of this blockchain corresponding to one message and referring to the previous block by its hash, and sometimes includes references to blocks (i.e., messages) of other processes by mentioning the hashes of these blocks in its blocks. -Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [\[3\]](#ref-3), but with $N$ participants instead of 2. +Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3](#ref-3), 5], but with $N$ participants instead of 2. ### 2.6. Message propagation in a catchain @@ -441,7 +443,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [\[3\]](#ref-3)). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3](#ref-3), 5]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -597,33 +599,26 @@ Now we claim that (each round of) the BCP protocol as described above terminates ## References - - -\[1] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications, Springer, 2005. - - - -\[2] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). - - - -\[3] N. Durov, Telegram Open Network, 2017. - - - -\[4] N. Durov, Telegram Open Network Blockchain, 2018. + +[1] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications, Springer, 2005. - + +[2] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). -\[5] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. + +[3] N. Durov, [Telegram Open Network, 2017](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). - + +[4] N. Durov, [Telegram Open Network Blockchain, 2018](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf). -\[6] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. + +[5] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. - + +[6] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. -\[7] M. van Steen, A. Tanenbaum, Distributed Systems, 3rd ed., 2017. + +[7] M. van Steen, A. Tanenbaum, Distributed Systems, 3rd ed., 2017. ## Footnotes @@ -635,7 +630,7 @@ Now we claim that (each round of) the BCP protocol as described above terminates **4** In the Byzantine environment of a catchain this is not necessarily true in all situations. [Back ↑](#2-4-messages-in-a-catchain-catchain-as-a-process-group) - **5** We assume that all broadcast messages in the process group are "causal broadcasts" or "cbcast" in the terminology of [\[1\]](#ref-1), because we only need cbcasts for the implementation of Catchain protocol and Catchain consensus. [Back ↑](#2-4-8-using-vector-timestamps-to-correctly-deliver-broadcast-messages) + **5** We assume that all broadcast messages in the process group are "causal broadcasts" or "cbcast" in the terminology of [1](#ref-1), because we only need cbcasts for the implementation of Catchain protocol and Catchain consensus. [Back ↑](#2-4-8-using-vector-timestamps-to-correctly-deliver-broadcast-messages) **6** This also means that each process implicitly determines the Unixtime of the start of the next round, and computes all delays, e.g., the block candidate submission delays, starting from this time. [Back ↑](#3-4-5-protocol-overview) From c91227fad9aae156c03f878dd8cd853e88e30a50 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 11:28:48 +0100 Subject: [PATCH 02/16] update crosslinks for catchain --- ton/catchain.mdx | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 8f8c0ed7..46ae910d 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -9,23 +9,23 @@ _February 19, 2020_ ## Abstract -The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [\[3\]](#ref-3). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. +The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. ## 1 Overview -The Catchain Consensus protocol builds upon the overlay network construction protocol and the overlay network broadcast protocol of TON Network ([3](#ref-3)). The Catchain Consensus protocol itself can be decomposed into two separate protocols, one more low-level and general-purpose (the Catchain protocol[¹](#footnote-1)), and the other the high-level Block Consensus Protocol (BCP), which makes use of the Catchain protocol. Higher levels in the TON protocol stack are occupied by the block generation and validation levels; however, all of them are executed essentially locally on one (logical) machine, with the problem of achieving consensus on the newly-generated block delegated to the Catchain protocol level. +The Catchain Consensus protocol builds upon the overlay network construction protocol and the overlay network broadcast protocol of TON Network ([3, 3.3](/ton/ton#3-3-overlay-networks-and-multicasting-messages)). The Catchain Consensus protocol itself can be decomposed into two separate protocols, one more low-level and general-purpose (the Catchain protocol[¹](#footnote-1)), and the other the high-level Block Consensus Protocol (BCP), which makes use of the Catchain protocol. Higher levels in the TON protocol stack are occupied by the block generation and validation levels; however, all of them are executed essentially locally on one (logical) machine, with the problem of achieving consensus on the newly-generated block delegated to the Catchain protocol level. Here is an approximate diagram of the protocol stack employed by TON for block generation and distribution, showing the correct place of the Catchain Consensus protocol (or rather its two component protocols): -- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [3](#ref-3) for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. +- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [[3, 2.6](/ton/ton#2-6-creating-and-validating-new-blocks)] for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. - **(TON) Block consensus protocol**: Achieves (byzantine fault tolerant) consensus on the block to be accepted as the next one in the current validator group for the masterchain or a shardchain. This level makes use of (the abstract interface of) the block generation and validation software, and builds upon the lower-level Catchain protocol. This protocol is explained in more detail in Section [3](#3-block-consensus-protocol). - **Catchain protocol**: Provides secure persistent broadcasts in an overlay network (e.g., the task group of validators for a specific shardchain or the masterchain dedicated to generation, validation, and propagation of new blocks in this shardchain or masterchain), and detects attempts of "cheating" (protocol violation) on the part of some participants. This protocol is explained in more detail in Section [2](#2-catchain-protocol). -- **(TON Network) overlay broadcast protocol**: A simple best-effort broadcast protocol for overlay networks in the TON Network as described in [3](#ref-3). Simply broadcasts received broadcast messages to all neighbors in the same overlay network that did not receive a copy of these messages before, with minimal effort dedicated to keeping copies of undelivered broadcast messages for a short period of time. +- **(TON Network) overlay broadcast protocol**: A simple best-effort broadcast protocol for overlay networks in the TON Network as described in ([3, 3.3](/ton/ton#3-3-overlay-networks-and-multicasting-messages)). Simply broadcasts received broadcast messages to all neighbors in the same overlay network that did not receive a copy of these messages before, with minimal effort dedicated to keeping copies of undelivered broadcast messages for a short period of time. -- **(TON Network) overlay protocol**: Creates overlay networks (cf. [3](#ref-3)) inside the ADNL protocol network, manages neighbor lists for these overlay networks. Each participant of an overlay network tracks several neighbors in the same overlay network and keeps dedicated ADNL connections (called "channels") to them, so that incoming messages can be efficiently broadcast to all neighbors with minimal overhead. +- **(TON Network) overlay protocol**: Creates overlay networks ([3, 3.3](/ton/ton#3-3-overlay-networks-and-multicasting-messages)) inside the ADNL protocol network, manages neighbor lists for these overlay networks. Each participant of an overlay network tracks several neighbors in the same overlay network and keeps dedicated ADNL connections (called "channels") to them, so that incoming messages can be efficiently broadcast to all neighbors with minimal overhead. - **Abstract Datagram Network Layer (ADNL) protocol**: The basic protocol of the TON Network, that delivers packets (datagrams) between network nodes identified only by 256-bit abstract (ADNL) addresses, which effectively are cryptographic keys (or their hashes). @@ -33,7 +33,7 @@ This text aims to describe only the second and the third protocol in this suite, We would like to point out here that the author of this text, while providing the general guidelines of how this protocol should be designed (on the lines of "let's create a BFT-hardened group broadcast message system, and run a suitably adapted simple two-phase or three-phase commit protocol on top of this system") and participating in several discussions during the development and implementation of the protocol, is definitely not the only designer of this protocol and especially of its current implementation. This is the work of several people. -A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [3](#ref-3) and [4](#ref-4)) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. +A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [[3, 2.1.21](#2-1-21-configurable-parameters)] and [[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. ## 2 Catchain Protocol @@ -47,7 +47,7 @@ The main prerequisite for running (an instance of) the Catchain protocol is the For the specific task of creating new blocks for one of the blockchains (i.e., the masterchain or one of the active shardchains) of the TON Blockchain, a special task group consisting of several validators is created. The list of members of this task group is used both to create a private overlay network inside ADNL (this means that the only nodes that can join this overlay network are those explicitly listed during its creation) and to run the corresponding instance of the Catchain protocol. -The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([4](#ref-4) would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) +The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([[4](/ton/tblkch#1-2-principal-components-of-a-block-and-the-blockchain-state)] would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) #### 2.2.1. Catchains are created in advance @@ -167,7 +167,7 @@ Note that all messages created by the same sender $i$ in a catchain turn out to In this way each process $i$ generates a simple blockchain consisting of its messages, with each "block" of this blockchain corresponding to one message and referring to the previous block by its hash, and sometimes includes references to blocks (i.e., messages) of other processes by mentioning the hashes of these blocks in its blocks. -Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3](#ref-3), 5], but with $N$ participants instead of 2. +Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3, 5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. ### 2.6. Message propagation in a catchain @@ -443,7 +443,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3](#ref-3), 5]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 5](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -635,3 +635,5 @@ Now we claim that (each round of) the BCP protocol as described above terminates **6** This also means that each process implicitly determines the Unixtime of the start of the next round, and computes all delays, e.g., the block candidate submission delays, starting from this time. [Back ↑](#3-4-5-protocol-overview) **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) + + **8** The original PDF referred to an early version of the Telegram Open Network. We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [Telegram Open Network (TON) Blockchain Specification](/ton/tblkch). [Back ↑](#footnote-8) \ No newline at end of file From 4b3360fe542d5e88d9e8c20e065af3f41bd2b62a Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 11:54:34 +0100 Subject: [PATCH 03/16] fix all trailing links --- ton/catchain.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 46ae910d..f9093baf 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -33,7 +33,7 @@ This text aims to describe only the second and the third protocol in this suite, We would like to point out here that the author of this text, while providing the general guidelines of how this protocol should be designed (on the lines of "let's create a BFT-hardened group broadcast message system, and run a suitably adapted simple two-phase or three-phase commit protocol on top of this system") and participating in several discussions during the development and implementation of the protocol, is definitely not the only designer of this protocol and especially of its current implementation. This is the work of several people. -A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [[3, 2.1.21](#2-1-21-configurable-parameters)] and [[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. +A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [[3, 2.1.21](/ton/ton#2-1-21-configurable-parameters)] and [[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. ## 2 Catchain Protocol @@ -47,7 +47,7 @@ The main prerequisite for running (an instance of) the Catchain protocol is the For the specific task of creating new blocks for one of the blockchains (i.e., the masterchain or one of the active shardchains) of the TON Blockchain, a special task group consisting of several validators is created. The list of members of this task group is used both to create a private overlay network inside ADNL (this means that the only nodes that can join this overlay network are those explicitly listed during its creation) and to run the corresponding instance of the Catchain protocol. -The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([[4](/ton/tblkch#1-2-principal-components-of-a-block-and-the-blockchain-state)] would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) +The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([[4, 1.2](/ton/tblkch#1-2-principal-components-of-a-block-and-the-blockchain-state)] would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) #### 2.2.1. Catchains are created in advance @@ -167,7 +167,7 @@ Note that all messages created by the same sender $i$ in a catchain turn out to In this way each process $i$ generates a simple blockchain consisting of its messages, with each "block" of this blockchain corresponding to one message and referring to the previous block by its hash, and sometimes includes references to blocks (i.e., messages) of other processes by mentioning the hashes of these blocks in its blocks. -Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3, 5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. +Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3, 5.1.5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. ### 2.6. Message propagation in a catchain @@ -443,7 +443,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 5](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -636,4 +636,4 @@ Now we claim that (each round of) the BCP protocol as described above terminates **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - **8** The original PDF referred to an early version of the Telegram Open Network. We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [Telegram Open Network (TON) Blockchain Specification](/ton/tblkch). [Back ↑](#footnote-8) \ No newline at end of file + **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) \ No newline at end of file From c47571c43560cae3eccb69f00b1ea543b1de23cf Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 11:54:47 +0100 Subject: [PATCH 04/16] add spaces --- ton/catchain.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index f9093baf..a43cd020 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -636,4 +636,4 @@ Now we claim that (each round of) the BCP protocol as described above terminates **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) \ No newline at end of file + **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) \ No newline at end of file From 52fb86a6b2208bf0bb2904abb15e33aa28fe538d Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 11:56:07 +0100 Subject: [PATCH 05/16] Update catchain.mdx --- ton/catchain.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index a43cd020..c9794a99 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -636,4 +636,4 @@ Now we claim that (each round of) the BCP protocol as described above terminates **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) \ No newline at end of file + **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) From 528620860ad3e04b5450b40fbfce8e073038566a Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 12:12:42 +0100 Subject: [PATCH 06/16] Update catchain.mdx --- ton/catchain.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index c9794a99..0ed1d130 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -443,7 +443,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](/ton/ton#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates From b953f25d837a39cf0edb49d9f15825c77493b985 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 12:14:15 +0100 Subject: [PATCH 07/16] fix formatting issues --- ton/catchain.mdx | 49 +++++++++++++++++++++++++++--------------------- 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index a43cd020..6465261f 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -9,7 +9,7 @@ _February 19, 2020_ ## Abstract -The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. +The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain \[[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. ## 1 Overview @@ -17,7 +17,7 @@ The Catchain Consensus protocol builds upon the overlay network construction pro Here is an approximate diagram of the protocol stack employed by TON for block generation and distribution, showing the correct place of the Catchain Consensus protocol (or rather its two component protocols): -- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [[3, 2.6](/ton/ton#2-6-creating-and-validating-new-blocks)] for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. +- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. \[[3, 2.6](/ton/ton#2-6-creating-and-validating-new-blocks)] for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. - **(TON) Block consensus protocol**: Achieves (byzantine fault tolerant) consensus on the block to be accepted as the next one in the current validator group for the masterchain or a shardchain. This level makes use of (the abstract interface of) the block generation and validation software, and builds upon the lower-level Catchain protocol. This protocol is explained in more detail in Section [3](#3-block-consensus-protocol). @@ -33,7 +33,7 @@ This text aims to describe only the second and the third protocol in this suite, We would like to point out here that the author of this text, while providing the general guidelines of how this protocol should be designed (on the lines of "let's create a BFT-hardened group broadcast message system, and run a suitably adapted simple two-phase or three-phase commit protocol on top of this system") and participating in several discussions during the development and implementation of the protocol, is definitely not the only designer of this protocol and especially of its current implementation. This is the work of several people. -A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [[3, 2.1.21](/ton/ton#2-1-21-configurable-parameters)] and [[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. +A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. \[[3, 2.1.21](/ton/ton#2-1-21-configurable-parameters)] and \[[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. ## 2 Catchain Protocol @@ -47,7 +47,7 @@ The main prerequisite for running (an instance of) the Catchain protocol is the For the specific task of creating new blocks for one of the blockchains (i.e., the masterchain or one of the active shardchains) of the TON Blockchain, a special task group consisting of several validators is created. The list of members of this task group is used both to create a private overlay network inside ADNL (this means that the only nodes that can join this overlay network are those explicitly listed during its creation) and to run the corresponding instance of the Catchain protocol. -The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text ([[4, 1.2](/ton/tblkch#1-2-principal-components-of-a-block-and-the-blockchain-state)] would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) +The construction of this list of members is the responsibility of the higher levels of the overall protocol stack (the block creation and validation software) and therefore is not the topic of this text (\[[4, 1.2](/ton/tblkch#1-2-principal-components-of-a-block-and-the-blockchain-state)] would be a more appropriate reference). It is sufficient to know at this point that this list is a deterministic function of the current (most recent) masterchain state (and especially of the current value of the configuration parameters, such as the active list of all validators elected for creating new blocks along with their respective weights). Since the list is computed deterministically, all validators compute the same lists and in particular each validator knows in which task groups (i.e., instances of the Catchain protocol) it participates without any further need for network communication or negotiation.[³](#footnote-3) #### 2.2.1. Catchains are created in advance @@ -167,7 +167,7 @@ Note that all messages created by the same sender $i$ in a catchain turn out to In this way each process $i$ generates a simple blockchain consisting of its messages, with each "block" of this blockchain corresponding to one message and referring to the previous block by its hash, and sometimes includes references to blocks (i.e., messages) of other processes by mentioning the hashes of these blocks in its blocks. -Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3, 5.1.5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. +Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in \[[3, 5.1.5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. ### 2.6. Message propagation in a catchain @@ -443,7 +443,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. \[[3, 3.3.15](#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -599,26 +599,33 @@ Now we claim that (each round of) the BCP protocol as described above terminates ## References - -[1] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications, Springer, 2005. + - -[2] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). +\[1] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications, Springer, 2005. - -[3] N. Durov, [Telegram Open Network, 2017](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). + - -[4] N. Durov, [Telegram Open Network Blockchain, 2018](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf). +\[2] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). - -[5] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. + - -[6] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. +\[3] N. Durov, [Telegram Open Network, 2017](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). - -[7] M. van Steen, A. Tanenbaum, Distributed Systems, 3rd ed., 2017. + + +\[4] N. Durov, [Telegram Open Network Blockchain, 2018](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf). + + + +\[5] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. + + + +\[6] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. + + + +\[7] M. van Steen, A. Tanenbaum, Distributed Systems, 3rd ed., 2017. ## Footnotes @@ -636,4 +643,4 @@ Now we claim that (each round of) the BCP protocol as described above terminates **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) \ No newline at end of file + **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **\[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton#introduction), and links **\[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) From 2403e1a07145589d8410ca1cceb9579dab43eb01 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 14:24:09 +0100 Subject: [PATCH 08/16] self fix ci issues --- ton/catchain.mdx | 32 +++++++++----------------------- 1 file changed, 9 insertions(+), 23 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index ee566bc2..57402036 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -444,7 +444,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](/ton/ton#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. \[[3, 3.3.15](/ton/ton#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -600,33 +600,19 @@ Now we claim that (each round of) the BCP protocol as described above terminates ## References - + \[1] K. Birman, _Reliable Distributed Systems: Technologies, Web Services and Applications_, Springer, 2005. -\[1] K. Birman, Reliable Distributed Systems: Technologies, Web Services and Applications, Springer, 2005. + \[2] M. Castro, B. Liskov, et al., _Practical byzantine fault tolerance_, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). - + \[3] N. Durov, [_Telegram Open Network_](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf), 2017. -\[2] M. Castro, B. Liskov, et al., Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). + \[4] N. Durov, [_Telegram Open Network Blockchain_](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf), 2018. - + \[5] L. Lamport, R. Shostak, M. Pease, _The byzantine generals problem_, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. -\[3] N. Durov, [Telegram Open Network, 2017](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). + \[6] A. Miller, Yu Xia, et al., _The honey badger of BFT protocols_, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. - - -\[4] N. Durov, [Telegram Open Network Blockchain, 2018](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf). - - - -\[5] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. - - - -\[6] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. - - - -\[7] M. van Steen, A. Tanenbaum, Distributed Systems, 3rd ed., 2017. + \[7] M. van Steen, A. Tanenbaum, _Distributed Systems_, 3rd ed., 2017. ## Footnotes @@ -644,4 +630,4 @@ Now we claim that (each round of) the BCP protocol as described above terminates **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links **[3.x.x]** to the more up-to-date document - [The Open Network](/ton/ton), and links **[4.x.x]** to the [TON Blockchain](/ton/tblkch). [Back ↑](#abstract) + **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links \[3.x.x] to the updated document, [The Open Network](/ton/ton), and links \[4.x.x] to the [TON Blockchain](/ton/tblkch).[Back ↑](#abstract) From 27060f076965984b7830c55130cf86f49b0aa895 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 14:41:55 +0100 Subject: [PATCH 09/16] vale fixes --- .vale/config/vocabularies/Custom/accept.txt | 1 + ton/catchain.mdx | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/.vale/config/vocabularies/Custom/accept.txt b/.vale/config/vocabularies/Custom/accept.txt index fb55bfe1..13a85d1e 100644 --- a/.vale/config/vocabularies/Custom/accept.txt +++ b/.vale/config/vocabularies/Custom/accept.txt @@ -917,3 +917,4 @@ Yung Zellic ZK-proof Figma +C_i \ No newline at end of file diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 57402036..c5303b39 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -362,8 +362,12 @@ The purpose of this field in messages is to provide a sanity check for the compu ### 3.3. State recovery after restart or crashes +{/* vale off */} + A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain. +{/* vale on */} + #### 3.3.1. Database of all delivered messages To this end, a special database is created for each active catchain. This database contains all known and delivered messages, indexed by their identifiers (hashes). A simple key-value database suffices for this purpose. The hash of the most recent outbound message $m = m_{i,s}$ generated by the current process $i$ is also stored in this database. After restart, all messages up to $m$ are recursively delivered in proper order (in the same way as if all these messages had been just received from the network in an arbitrary order) and processed by the higher-level protocol, until $m$ finally is delivered, thus recovering the current state. From 33ddea63e3fc1586a1d628257369741a0bbc2b20 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 15:01:12 +0100 Subject: [PATCH 10/16] FIX VALE ISSUES --- .vale/config/vocabularies/Custom/accept.txt | 4 ++-- ton/catchain.mdx | 6 +----- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/.vale/config/vocabularies/Custom/accept.txt b/.vale/config/vocabularies/Custom/accept.txt index 13a85d1e..52ce6fb6 100644 --- a/.vale/config/vocabularies/Custom/accept.txt +++ b/.vale/config/vocabularies/Custom/accept.txt @@ -332,6 +332,7 @@ Burnosov callables buildx bundler +C_i cNFT cNFTs callables @@ -916,5 +917,4 @@ Yolo Yung Zellic ZK-proof -Figma -C_i \ No newline at end of file +Figma \ No newline at end of file diff --git a/ton/catchain.mdx b/ton/catchain.mdx index c5303b39..2a71f307 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -362,11 +362,7 @@ The purpose of this field in messages is to provide a sanity check for the compu ### 3.3. State recovery after restart or crashes -{/* vale off */} - -A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain. - -{/* vale on */} +A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program, might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain. #### 3.3.1. Database of all delivered messages From 2d49e42ba6a263e08894caf36e06f3b0e3fbff4a Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 15:06:24 +0100 Subject: [PATCH 11/16] vale fixes --- ton/catchain.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 2a71f307..590044ef 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -462,11 +462,11 @@ Each round of BCP proceeds as follows: • During each slow attempt (i.e., any attempt except the first $Y$) every process votes either for a candidate that was `PreCommitted` before (by the same process), or for a candidate that was suggested by `VoteFor`. -• If a block candidate has received votes from more than 2/3 of all processes during the current attempt, and the current process observes these votes (which are collected in the catchain state), a `PreCommit` event is created, indicating that the process will vote only for this candidate in future. +• If a block candidate has received votes from, more than 2/3 of all processes during the current attempt, and the current process observes these votes (which are collected in the catchain state), a `PreCommit` event is created, indicating that the process will vote only for this candidate in future. -• If a block candidate collects `PreCommits` from more than 2/3 of all processes inside an attempt, then it is assumed to be accepted (by the group), and each process that observes these `PreCommits` creates a `CommitSign` event with a valid block signature. These block signatures are registered in the catchain, and are ultimately collected to create a "block proof" (containing signatures of more than 2/3 of the validators for this block). This block proof is the external output of the consensus protocol (along with the block itself, but without its collated data); it is ultimately propagated in the overlay network of all full nodes that have subscribed to new blocks of this shard (or of the masterchain). +• If a block candidate collects `PreCommits` from, more than 2/3 of all processes inside an attempt, then it is assumed to be accepted (by the group), and each process that observes these `PreCommits` creates a `CommitSign` event with a valid block signature. These block signatures are registered in the catchain, and are ultimately collected to create a "block proof" (containing signatures of more than 2/3 of the validators for this block). This block proof is the external output of the consensus protocol (along with the block itself, but without its collated data); it is ultimately propagated in the overlay network of all full nodes that have subscribed to new blocks of this shard (or of the masterchain). -• Once a block candidate collects `CommitSign` signatures from more than 2/3 of all validators, the round is considered finished (at least from the perspective of a process that observes all these signatures). After that, only a `CommitSign` can be added to that round by this process, and the process automatically starts participating in the next round (and ignores all events related to other rounds). +• Once a block candidate collects `CommitSign` signatures from, more than 2/3 of all validators, the round is considered finished (at least from the perspective of a process that observes all these signatures). After that, only a `CommitSign` can be added to that round by this process, and the process automatically starts participating in the next round (and ignores all events related to other rounds). Note that the above protocol may lead to a validator signing (in a `CommitSign` event) a block candidate that was `Rejected` by the same validator before (this is a kind of "submitting to the will of majority"). From 2dbed6a58be62fa6e22fbe1c967f6aed6b07c91e Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 15:14:22 +0100 Subject: [PATCH 12/16] vale fixes --- ton/catchain.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 590044ef..57402036 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -362,7 +362,7 @@ The purpose of this field in messages is to provide a sanity check for the compu ### 3.3. State recovery after restart or crashes -A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program, might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain. +A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain. #### 3.3.1. Database of all delivered messages @@ -462,11 +462,11 @@ Each round of BCP proceeds as follows: • During each slow attempt (i.e., any attempt except the first $Y$) every process votes either for a candidate that was `PreCommitted` before (by the same process), or for a candidate that was suggested by `VoteFor`. -• If a block candidate has received votes from, more than 2/3 of all processes during the current attempt, and the current process observes these votes (which are collected in the catchain state), a `PreCommit` event is created, indicating that the process will vote only for this candidate in future. +• If a block candidate has received votes from more than 2/3 of all processes during the current attempt, and the current process observes these votes (which are collected in the catchain state), a `PreCommit` event is created, indicating that the process will vote only for this candidate in future. -• If a block candidate collects `PreCommits` from, more than 2/3 of all processes inside an attempt, then it is assumed to be accepted (by the group), and each process that observes these `PreCommits` creates a `CommitSign` event with a valid block signature. These block signatures are registered in the catchain, and are ultimately collected to create a "block proof" (containing signatures of more than 2/3 of the validators for this block). This block proof is the external output of the consensus protocol (along with the block itself, but without its collated data); it is ultimately propagated in the overlay network of all full nodes that have subscribed to new blocks of this shard (or of the masterchain). +• If a block candidate collects `PreCommits` from more than 2/3 of all processes inside an attempt, then it is assumed to be accepted (by the group), and each process that observes these `PreCommits` creates a `CommitSign` event with a valid block signature. These block signatures are registered in the catchain, and are ultimately collected to create a "block proof" (containing signatures of more than 2/3 of the validators for this block). This block proof is the external output of the consensus protocol (along with the block itself, but without its collated data); it is ultimately propagated in the overlay network of all full nodes that have subscribed to new blocks of this shard (or of the masterchain). -• Once a block candidate collects `CommitSign` signatures from, more than 2/3 of all validators, the round is considered finished (at least from the perspective of a process that observes all these signatures). After that, only a `CommitSign` can be added to that round by this process, and the process automatically starts participating in the next round (and ignores all events related to other rounds). +• Once a block candidate collects `CommitSign` signatures from more than 2/3 of all validators, the round is considered finished (at least from the perspective of a process that observes all these signatures). After that, only a `CommitSign` can be added to that round by this process, and the process automatically starts participating in the next round (and ignores all events related to other rounds). Note that the above protocol may lead to a validator signing (in a `CommitSign` event) a block candidate that was `Rejected` by the same validator before (this is a kind of "submitting to the will of majority"). From 3c300000ec7ffb8e601b253740a1646460900243 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 16:30:09 +0100 Subject: [PATCH 13/16] add aside callout block --- ton/catchain.mdx | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 57402036..8347812e 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -10,7 +10,12 @@ description: "Whitepaper by Dr. Nikolai Durov" ## Abstract -The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain \[[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. +The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. + + ## 1 Overview @@ -18,7 +23,7 @@ The Catchain Consensus protocol builds upon the overlay network construction pro Here is an approximate diagram of the protocol stack employed by TON for block generation and distribution, showing the correct place of the Catchain Consensus protocol (or rather its two component protocols): -- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. \[[3, 2.6](/ton/ton#2-6-creating-and-validating-new-blocks)] for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. +- **Top-level**: Block generation and block validation software, logically running on a stand-alone logical machine, with all the inputs provided and outputs handled by the lower-level protocols. The job of this software is to either generate a new valid block for a blockchain (a shardchain or the masterchain of the TON Blockchain; cf. [[3, 2.6](/ton/ton#2-6-creating-and-validating-new-blocks)] for a discussion of shardchains and the masterchain), or to check the validity of a block generated by somebody else. - **(TON) Block consensus protocol**: Achieves (byzantine fault tolerant) consensus on the block to be accepted as the next one in the current validator group for the masterchain or a shardchain. This level makes use of (the abstract interface of) the block generation and validation software, and builds upon the lower-level Catchain protocol. This protocol is explained in more detail in Section [3](#3-block-consensus-protocol). @@ -34,7 +39,7 @@ This text aims to describe only the second and the third protocol in this suite, We would like to point out here that the author of this text, while providing the general guidelines of how this protocol should be designed (on the lines of "let's create a BFT-hardened group broadcast message system, and run a suitably adapted simple two-phase or three-phase commit protocol on top of this system") and participating in several discussions during the development and implementation of the protocol, is definitely not the only designer of this protocol and especially of its current implementation. This is the work of several people. -A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. \[[3, 2.1.21](/ton/ton#2-1-21-configurable-parameters)] and \[[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. +A few words on the efficiency of the combined Catchain Consensus protocol. Firstly, it is a true Byzantine Fault Tolerant (BFT) protocol, in the sense that it eventually achieves consensus on a valid next block of the blockchain even if some participants (validators) exhibit arbitrarily malicious behavior, provided these malicious participants are less than one third of the total number of the validators. It is well-known that achieving BFT consensus is impossible if at least one third of participants are malicious (cf. [5](#ref-5)), so the Catchain Consensus protocol is as good as theoretically possible in this respect. Secondly, when the Catchain Consensus was first implemented (in December 2018) and tested on up to 300 nodes distributed all over the world, it achieved consensus on a new block in 6 seconds for 300 nodes and in 4–5 seconds for 100 nodes (and in 3 seconds for 10 nodes), even if some of these nodes fail to participate or exhibit incorrect behavior.[²](#footnote-2) Since the TON Blockchain task groups are not expected to consist of more than a hundred validators (even if a total of a thousand or ten thousand validators are running, only a hundred of them with the largest stakes will generate new masterchain blocks, and the others will participate only in the creation of new shardchain blocks, each shardchain block generated and validated by 10–30 validators; of course, all numbers given here are configuration parameters (cf. [[3, 2.1.21](/ton/ton#2-1-21-configurable-parameters)] and [[4, 1.6](/ton/tblkch#1-6-configurable-parameters-and-smart-contracts)]) and can be adjusted later by a consensus vote of validators if necessary), this means that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. This promise has been further tested and found out to be fulfilled with the launch of the Test Network of the TON Blockchain a couple of months later (in March 2019). Therefore, we see that the Catchain Consensus protocol is a new member of the ever-growing family of practical BFT protocols (cf. [2](#ref-2)), even though it is based on slightly different principles. ## 2 Catchain Protocol @@ -168,7 +173,7 @@ Note that all messages created by the same sender $i$ in a catchain turn out to In this way each process $i$ generates a simple blockchain consisting of its messages, with each "block" of this blockchain corresponding to one message and referring to the previous block by its hash, and sometimes includes references to blocks (i.e., messages) of other processes by mentioning the hashes of these blocks in its blocks. -Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in \[[3, 5.1.5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. +Each block is signed by its creator. The resulting structure is very similar to that of an "asynchronous payment channel" considered in [[3, 5.1.5](/ton/ton#5-1-5-asynchronous-payment-channel-as-a-virtual-blockchain-with-two-workchains)], but with $N$ participants instead of 2. ### 2.6. Message propagation in a catchain @@ -444,7 +449,7 @@ The first block producer may suggest a block candidate immediately after the rou #### 3.4.8. Suggesting a block candidate -A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. \[[3, 3.3.15](/ton/ton#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. +A block candidate for the TON Blockchain consists of two large "files" — the block and the collated data, along with a small header containing the description of the block being generated (most importantly, the complete block identifier for the block candidate, containing the workchain and the shard identifier, the block sequence number, its file hash and its root hash) and the sha256 hashes of the two large files. Only a part of this small header (including the hashes of the two files and other important data) is used as `candidate` in BCP events such as `Submit` or `CommitSign` to refer to a specific block candidate. The bulk of the data (most importantly, the two large files) is propagated in the overlay network associated with the catchain by the streaming broadcast protocol implemented over ADNL for this purpose (cf. [[3, 3.3.15](/ton/ton#3-3-15-streaming-broadcast-protocol)]). This bulk data propagation mechanism is unimportant for the validity of the consensus protocol (the only important point is that the hashes of the large files are part of BCP events and hence of the catchain messages, where they are signed by the sender, and these hashes are checked after the large files are received by any participating nodes; therefore, nobody can replace or corrupt these files). A `Submit(round, candidate)` BCP event is created in the catchain by the block producer in parallel with the propagation of the block candidate, indicating the submission of this specific block candidate by this block producer. #### 3.4.9. Processing block candidates @@ -600,19 +605,19 @@ Now we claim that (each round of) the BCP protocol as described above terminates ## References - \[1] K. Birman, _Reliable Distributed Systems: Technologies, Web Services and Applications_, Springer, 2005. + [1] K. Birman, _Reliable Distributed Systems: Technologies, Web Services and Applications_, Springer, 2005. - \[2] M. Castro, B. Liskov, et al., _Practical byzantine fault tolerance_, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). + [2] M. Castro, B. Liskov, et al., _Practical byzantine fault tolerance_, Proceedings of the Third Symposium on Operating Systems Design and Implementation (1999), p. 173–186, available at [http://pmg.csail.mit.edu/papers/osdi99.pdf](http://pmg.csail.mit.edu/papers/osdi99.pdf). - \[3] N. Durov, [_Telegram Open Network_](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf), 2017. + [3] N. Durov, [_Telegram Open Network_](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf), 2017. - \[4] N. Durov, [_Telegram Open Network Blockchain_](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf), 2018. + [4] N. Durov, [_Telegram Open Network Blockchain_](https://www.docdroid.net/qY4sQEv/telegram-open-network-blockchain-september-5-2018-pdf), 2018. - \[5] L. Lamport, R. Shostak, M. Pease, _The byzantine generals problem_, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. + [5] L. Lamport, R. Shostak, M. Pease, _The byzantine generals problem_, ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382–401. - \[6] A. Miller, Yu Xia, et al., _The honey badger of BFT protocols_, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. + [6] A. Miller, Yu Xia, et al., _The honey badger of BFT protocols_, Cryptology e-print archive 2016/99, [https://eprint.iacr.org/2016/199.pdf](https://eprint.iacr.org/2016/199.pdf), 2016. - \[7] M. van Steen, A. Tanenbaum, _Distributed Systems_, 3rd ed., 2017. + [7] M. van Steen, A. Tanenbaum, _Distributed Systems_, 3rd ed., 2017. ## Footnotes @@ -629,5 +634,3 @@ Now we claim that (each round of) the BCP protocol as described above terminates **6** This also means that each process implicitly determines the Unixtime of the start of the next round, and computes all delays, e.g., the block candidate submission delays, starting from this time. [Back ↑](#3-4-5-protocol-overview) **7** In fact, `Rejects` appear only in this restriction, and do not affect anything else. Therefore, any process can abstain from sending `Rejects` without violating the protocol, and `Reject` events could have been removed from the protocol altogether. Instead, the current implementation of the protocol still generates `Rejects`, but does not check anything on their receipt and does not remember them in the catchain state. Only a message is output into the error log, and the offending candidate is stored into a special directory for future study, because `Rejects` usually indicate either the presence of a byzantine adversary, or a bug in the collator (block generation) or validator (block verification) software either on the node that suggested the block or on the node that created the `Reject` event. [Back ↑](#3-5-3-useful-invariants) - - **8** The original PDF referred to an early version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf). We have redirected links \[3.x.x] to the updated document, [The Open Network](/ton/ton), and links \[4.x.x] to the [TON Blockchain](/ton/tblkch).[Back ↑](#abstract) From f70eb02c821b873ef2e4dade059e6cf6182d2652 Mon Sep 17 00:00:00 2001 From: Favour Kelvin Date: Fri, 10 Oct 2025 16:31:57 +0100 Subject: [PATCH 14/16] ci check fixes --- ton/catchain.mdx | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/ton/catchain.mdx b/ton/catchain.mdx index 8347812e..11e155d1 100644 --- a/ton/catchain.mdx +++ b/ton/catchain.mdx @@ -10,11 +10,14 @@ description: "Whitepaper by Dr. Nikolai Durov" ## Abstract -The aim of this text is to provide an outline of the Catchain Consensus Protocol, a Byzantine Fault Tolerant (BFT) protocol specifically crafted for block generation and validation in the TON Blockchain [[3, 2.1.12](/ton/ton#2-1-12-block-generation-intervals)][⁸](#footnote-8). This protocol can potentially be used for purposes other than block generation in a proof-of-stake (PoS) blockchain; however, the current implementation uses some optimizations valid only for this specific problem. - -