From 7ac98d1ee0deb0ec2accd67ddfb2bcf0923e0a81 Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Tue, 28 Oct 2025 15:04:06 +0300 Subject: [PATCH 01/21] init --- foundations/consensus/bcp-deep-dive.mdx | 8 ++++++ foundations/consensus/bcp-overview.mdx | 14 +++++++++++ foundations/consensus/catchain-overview.mdx | 28 +++++++++++++++++++++ 3 files changed, 50 insertions(+) create mode 100644 foundations/consensus/bcp-deep-dive.mdx create mode 100644 foundations/consensus/bcp-overview.mdx create mode 100644 foundations/consensus/catchain-overview.mdx diff --git a/foundations/consensus/bcp-deep-dive.mdx b/foundations/consensus/bcp-deep-dive.mdx new file mode 100644 index 000000000..0f6c7fe73 --- /dev/null +++ b/foundations/consensus/bcp-deep-dive.mdx @@ -0,0 +1,8 @@ +--- +title: "BCP deep dive" +sidebarTitle: "BCP deep dive" +--- + +import { Stub } from '/snippets/stub.jsx'; + + diff --git a/foundations/consensus/bcp-overview.mdx b/foundations/consensus/bcp-overview.mdx new file mode 100644 index 000000000..27d6f513d --- /dev/null +++ b/foundations/consensus/bcp-overview.mdx @@ -0,0 +1,14 @@ +--- +title: "BCP overview" +sidebarTitle: "BCP overview" +--- + +import { Stub } from '/snippets/stub.jsx'; +import {Aside} from "/snippets/aside"; + + + + + diff --git a/foundations/consensus/catchain-overview.mdx b/foundations/consensus/catchain-overview.mdx new file mode 100644 index 000000000..89d095dfd --- /dev/null +++ b/foundations/consensus/catchain-overview.mdx @@ -0,0 +1,28 @@ +--- +title: "Catchain overview" +sidebarTitle: "Catchain overview" +--- + +import {Aside} from "/snippets/aside"; + +Catchain is a communication protocol between validators. It does not execute the consensus algorithm itself but prepares data required for the decision-making of a higher-level component: [BCP - Block Consensus Protocol](/foundations/consensus/bcp-overview) + +## Проблема + +В полностью асинхронной системе при отправке сообщений нет никаких гарантий, что сообщение дойдёт. А если дойдёт, то не известно, в каком порядке. Даже если А отправляет 2 сообщения для Б, нет никаких гарантий порядка, в котором эти сообщения дойдут, если конечно они вообще дойдут. Более того, считается, что некоторые из акторов сети могут совершать Византийские ошибки. Требуется не допускать ситуации, при которой византийские узлы мешают функциональности системы. + + +## Задачи протокола + +Catchain помогает частично решить эту проблему. Он описывает +- как выбирать узлы "соседи" +- Описывает формат сообщений, у которых есть зависимости (другие, отправленные ранее сообщения) +- Описывает, как получать зависимости +- Как выявлять и наказывать те узлы в сети, которые мешают правильной работе сети + + +Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно собой. Более того, эти зависимости задаются таким образом, что любой участник сети может проверить, действительно ли такое сообщение существовало и получить его. + +## Идентификация сообщений + +Таким образом, сообщение в catchain можно уникально идентифицировать по паре значений — (отправитель, номер сообщения) From 2788802e603d6de254968e8bd655769fb6b318d9 Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Tue, 28 Oct 2025 15:04:34 +0300 Subject: [PATCH 02/21] more --- foundations/consensus/catchain-overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/foundations/consensus/catchain-overview.mdx b/foundations/consensus/catchain-overview.mdx index 89d095dfd..f9648ded8 100644 --- a/foundations/consensus/catchain-overview.mdx +++ b/foundations/consensus/catchain-overview.mdx @@ -21,7 +21,7 @@ Catchain помогает частично решить эту проблему. - Как выявлять и наказывать те узлы в сети, которые мешают правильной работе сети -Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно собой. Более того, эти зависимости задаются таким образом, что любой участник сети может проверить, действительно ли такое сообщение существовало и получить его. +Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно, собой. Более того, эти зависимости задаются таким образом, что любой участник сети может проверить, действительно ли такое сообщение существовало и получить его. ## Идентификация сообщений From 8603d51c67e90deca76f3c04526b706a4732fa9a Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 13:11:28 +0300 Subject: [PATCH 03/21] finish draft version --- foundations/consensus/catchain-overview.mdx | 44 +++++++++++++++++++-- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/foundations/consensus/catchain-overview.mdx b/foundations/consensus/catchain-overview.mdx index f9648ded8..0bb723966 100644 --- a/foundations/consensus/catchain-overview.mdx +++ b/foundations/consensus/catchain-overview.mdx @@ -9,20 +9,56 @@ Catchain is a communication protocol between validators. It does not execute the ## Проблема -В полностью асинхронной системе при отправке сообщений нет никаких гарантий, что сообщение дойдёт. А если дойдёт, то не известно, в каком порядке. Даже если А отправляет 2 сообщения для Б, нет никаких гарантий порядка, в котором эти сообщения дойдут, если конечно они вообще дойдут. Более того, считается, что некоторые из акторов сети могут совершать Византийские ошибки. Требуется не допускать ситуации, при которой византийские узлы мешают функциональности системы. +В полностью ас любой участник сети может проверить, действительно ли такое сообщение существовало и получить его.инхронной системе при отправке сообщений нет никаких гарантий, что сообщение дойдёт. А если дойдёт, то не известно, в каком порядке. Даже если А отправляет 2 сообщения для Б, нет никаких гарантий порядка, в котором эти сообщения дойдут, если конечно они вообще дойдут. Более того, считается, что некоторые из акторов сети могут совершать Византийские ошибки. Требуется не допускать ситуации, при которой византийские узлы мешают функциональности системы. +## Вводные данны + +Будем считать, что все участники сети известны в том смысле, что каждому участнику сети известен ADNL адрес любого другого участника сети и его публичный ключ. Таким образом, участники могут безопасно обмениваться сообщениями, шифруя или подписывая их своими приватными ключами. И подпись любого участника может быть проверена любым другим участником. ## Задачи протокола Catchain помогает частично решить эту проблему. Он описывает - как выбирать узлы "соседи" -- Описывает формат сообщений, у которых есть зависимости (другие, отправленные ранее сообщения) +- Описывает формат сообщений, у которых есть зависимости (другие сообщения) - Описывает, как получать зависимости - Как выявлять и наказывать те узлы в сети, которые мешают правильной работе сети +Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно, собой. Более того, эти зависимости задаются таким образом, что узел, получивший сообщение, может скачать зависимости и проверить их валидность. + +## Как выбирать узлы соседи -Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно, собой. Более того, эти зависимости задаются таким образом, что любой участник сети может проверить, действительно ли такое сообщение существовало и получить его. +Catchain предполагает выбор пяти узлов - соседей, случайным образом, а так же их периодическое обновление (через случайный интервал от 60 до 120 секунд в текущей конфигурации). Важно понимать, что отношение "соседства" не является симметричным, то есть если B сосед A, это не значит что А сосед B и наоборот. ## Идентификация сообщений -Таким образом, сообщение в catchain можно уникально идентифицировать по паре значений — (отправитель, номер сообщения) +Таким образом, сообщение в catchain можно уникально идентифицировать по паре значений — (отправитель; номер сообщения отправителя) + + + +Таким образом получается, что каждый актор должен сам индексировать свои сообщения и повышать счётчик. В силу того, что узлы могут быть Византийскими, требуется проверять, что узлы верно ведут свой счётчик. + +### Проверка на разные блоки с одинаковым id + +Если некий актор выпускает два различных по содержанию сообщения с id = (A; i), где i - номер сообщения, то такая ситуация называется форком. В таком случае, любой актор, заметивший это может сконструировать доказательство того, что такие 2 сообщения существовали. Учитывая, что публичные ключи всех участников известны, можно сконструировать доказательство, состоящее из id блока и двух подписей к нему. Это доказательство плохого поведения транслируется всем соседям в сети, а затем их соседям и так далее. Любой из честных участников сети, получивший доказательство, начинает игнорировать любые сообщения от узла A, а так же все сообщения, которые зависят от сообщений узла А. + + + +### Проверка на последовательные id + +Считается, что любое сообщение (X; i), кроме, конечно, (X;0), зависит от (X;i-1). Если узел выпустить сообщение (X; i), а затем выпустить (X; i + j, j > 1), то честный узел, получивший данное сообщение, не сможет получить сообщение (X; i + j - 1), а значит не сможет обработать (X; i + j). Таким образом, пропуск id сообщений становится бессмысленным, т.к. сообщения, следующие за пропущенным, игнорируются всеми правильными узлами. + + +## Процесс получения зависимостей + +Каждые 0.1 - 0.2 секунды узел выбирает трёх случайных соседей и запускает с ними синхронизацию. Синхронизация может выполняться двумя способами + +- Отправка (в сжатом виде) информации об уже полученных сообщениях. Если у соседа есть блоки сообщения свежее, он их предоставляет. +- Таргетированная подкачка конкретных сообщений. Обычно применяется, если после общей синхронизации первым способом, остались какие-то пропущенные единичные зависимости. + +## Шифрование + +Стоит отметить, что все описанные выше действия происходят в так называемом [приватном оверлее ADNL](ссылка). Общий сессионный ключ не считается, вместо этого для каждой пары узлов считается собственный ключ, которым и шифруются тела сообщений. На практике это означает что стороннему наблюдателю в TON Blockchain нельзя читать сообщения валидаторов, которые они посылают друг-другу. From 8e46eb8cc9118dc7570439e98e218855823a42a5 Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 13:28:31 +0300 Subject: [PATCH 04/21] Translated to english, fixed structure, fixed added ADNL separate task --- docs.json | 14 +++++ foundations/consensus/catchain-overview.mdx | 60 +++++++++---------- .../{consensus.mdx => network/adnl.mdx} | 2 +- 3 files changed, 45 insertions(+), 31 deletions(-) rename foundations/{consensus.mdx => network/adnl.mdx} (76%) diff --git a/docs.json b/docs.json index a0873129a..c43b90e9f 100644 --- a/docs.json +++ b/docs.json @@ -500,6 +500,20 @@ "foundations/messages/internal" ] }, + { + "group": "Network", + "pages": [ + "foundations/network/andl" + ] + }, + { + "group": "Consensus", + "pages": [ + "foundations/consensus/catchain-overview", + "foundations/consensus/bcp-overview", + "foundations/consensus/bpc-deep-dive" + ] + }, "foundations/hypercube-routing", "foundations/statuses", "foundations/phases", diff --git a/foundations/consensus/catchain-overview.mdx b/foundations/consensus/catchain-overview.mdx index 0bb723966..e23258721 100644 --- a/foundations/consensus/catchain-overview.mdx +++ b/foundations/consensus/catchain-overview.mdx @@ -5,60 +5,60 @@ sidebarTitle: "Catchain overview" import {Aside} from "/snippets/aside"; -Catchain is a communication protocol between validators. It does not execute the consensus algorithm itself but prepares data required for the decision-making of a higher-level component: [BCP - Block Consensus Protocol](/foundations/consensus/bcp-overview) +Catchain is a communication protocol between validators. It does not execute the consensus algorithm itself but prepares the data required for the decision-making of a higher-level component: [BCP - Block Consensus Protocol](/foundations/consensus/bcp-overview). -## Проблема +## Problem -В полностью ас любой участник сети может проверить, действительно ли такое сообщение существовало и получить его.инхронной системе при отправке сообщений нет никаких гарантий, что сообщение дойдёт. А если дойдёт, то не известно, в каком порядке. Даже если А отправляет 2 сообщения для Б, нет никаких гарантий порядка, в котором эти сообщения дойдут, если конечно они вообще дойдут. Более того, считается, что некоторые из акторов сети могут совершать Византийские ошибки. Требуется не допускать ситуации, при которой византийские узлы мешают функциональности системы. +In a fully asynchronous network there are no guarantees that a message will ever be delivered, nor in which order it will arrive. Even if node A sends two messages to node B, there is no guarantee that they will be delivered in the same order, or that they will be delivered at all. Moreover, some actors in the network are assumed to behave in a Byzantine way. The system must avoid situations where Byzantine nodes prevent honest nodes from making progress. -## Вводные данны +## Assumptions -Будем считать, что все участники сети известны в том смысле, что каждому участнику сети известен ADNL адрес любого другого участника сети и его публичный ключ. Таким образом, участники могут безопасно обмениваться сообщениями, шифруя или подписывая их своими приватными ключами. И подпись любого участника может быть проверена любым другим участником. +All participants of the network are known. Each validator knows the ADNL address and the public key of every other validator. Messages can therefore be encrypted and signed with private keys, and every signature can be verified by every other participant. -## Задачи протокола +## Protocol goals -Catchain помогает частично решить эту проблему. Он описывает -- как выбирать узлы "соседи" -- Описывает формат сообщений, у которых есть зависимости (другие сообщения) -- Описывает, как получать зависимости -- Как выявлять и наказывать те узлы в сети, которые мешают правильной работе сети +Catchain helps to address the issues above by describing: -Основной задачей протокола является предоставление возможности отправки сообщений, которые явно зависят от других сообщений, отправленных, возможно, другим актором, возможно, собой. Более того, эти зависимости задаются таким образом, что узел, получивший сообщение, может скачать зависимости и проверить их валидность. +- how to choose "neighbor" nodes; +- the format of messages with explicit dependencies (other messages); +- how to fetch dependencies; +- how to detect and penalize nodes that try to disrupt the system. -## Как выбирать узлы соседи +The main purpose of the protocol is to allow validators to send messages that explicitly depend on other messages, possibly produced by different actors. Dependencies are encoded in such a way that a node receiving a message can download the referenced messages and verify their validity. -Catchain предполагает выбор пяти узлов - соседей, случайным образом, а так же их периодическое обновление (через случайный интервал от 60 до 120 секунд в текущей конфигурации). Важно понимать, что отношение "соседства" не является симметричным, то есть если B сосед A, это не значит что А сосед B и наоборот. +## Choosing neighbor nodes -## Идентификация сообщений +Catchain selects five neighbors at random and periodically refreshes the list (every random interval between 60 and 120 seconds in the current configuration). The neighbor relation is not symmetric: if B is a neighbor of A, it does not imply that A is also a neighbor of B. -Таким образом, сообщение в catchain можно уникально идентифицировать по паре значений — (отправитель; номер сообщения отправителя) +## Message identification + +Every catchain message is uniquely identified by the pair `(sender; sender's sequence number)`. -Таким образом получается, что каждый актор должен сам индексировать свои сообщения и повышать счётчик. В силу того, что узлы могут быть Византийскими, требуется проверять, что узлы верно ведут свой счётчик. +Each actor is responsible for indexing its own messages and increasing the sequence counter. Because nodes can be Byzantine, honest validators must verify that counters are monotonically increasing. -### Проверка на разные блоки с одинаковым id +### Detecting forks (duplicate message IDs) -Если некий актор выпускает два различных по содержанию сообщения с id = (A; i), где i - номер сообщения, то такая ситуация называется форком. В таком случае, любой актор, заметивший это может сконструировать доказательство того, что такие 2 сообщения существовали. Учитывая, что публичные ключи всех участников известны, можно сконструировать доказательство, состоящее из id блока и двух подписей к нему. Это доказательство плохого поведения транслируется всем соседям в сети, а затем их соседям и так далее. Любой из честных участников сети, получивший доказательство, начинает игнорировать любые сообщения от узла A, а так же все сообщения, которые зависят от сообщений узла А. +If an actor issues two messages with the same identifier `(A; i)` but different payloads, the situation is called a fork. Any validator who observes it can construct a proof consisting of the block identifier and two distinct signatures. Since all public keys are known, this proof can be broadcast to the neighbors, and then further across the network. Every honest participant who receives the proof starts ignoring all messages from node A, as well as all messages that depend on A's messages. -### Проверка на последовательные id - -Считается, что любое сообщение (X; i), кроме, конечно, (X;0), зависит от (X;i-1). Если узел выпустить сообщение (X; i), а затем выпустить (X; i + j, j > 1), то честный узел, получивший данное сообщение, не сможет получить сообщение (X; i + j - 1), а значит не сможет обработать (X; i + j). Таким образом, пропуск id сообщений становится бессмысленным, т.к. сообщения, следующие за пропущенным, игнорируются всеми правильными узлами. +### Detecting skipped sequence numbers +Every message `(X; i)` (except the genesis message `(X; 0)`) depends on `(X; i - 1)`. If a node produces `(X; i)` and later emits `(X; i + j)` with `j > 1`, an honest node will not be able to obtain `(X; i + j - 1)` and therefore will not process `(X; i + j)`. Skipping sequence numbers is thus pointless: all messages following the missing one are ignored by honest validators. -## Процесс получения зависимостей +## Dependency retrieval process -Каждые 0.1 - 0.2 секунды узел выбирает трёх случайных соседей и запускает с ними синхронизацию. Синхронизация может выполняться двумя способами +Every 0.1–0.2 seconds a node selects three random neighbors and starts a synchronization round. Synchronization can be performed in two ways: -- Отправка (в сжатом виде) информации об уже полученных сообщениях. Если у соседа есть блоки сообщения свежее, он их предоставляет. -- Таргетированная подкачка конкретных сообщений. Обычно применяется, если после общей синхронизации первым способом, остались какие-то пропущенные единичные зависимости. +- Exchange a compressed summary of already delivered messages. If the neighbor has more recent blocks, it provides them. +- Perform targeted downloads of specific messages. This is usually used if, after the bulk synchronization above, there are still individual missing dependencies. -## Шифрование +## Encryption -Стоит отметить, что все описанные выше действия происходят в так называемом [приватном оверлее ADNL](ссылка). Общий сессионный ключ не считается, вместо этого для каждой пары узлов считается собственный ключ, которым и шифруются тела сообщений. На практике это означает что стороннему наблюдателю в TON Blockchain нельзя читать сообщения валидаторов, которые они посылают друг-другу. +All the steps above happen inside a [private ADNL overlay](/foundations/network/adnl). There is no shared session key; instead each pair of nodes derives its own key that is used to encrypt message bodies. In practice this means that an external observer in the TON blockchain cannot read the messages that validators exchange with each other. diff --git a/foundations/consensus.mdx b/foundations/network/adnl.mdx similarity index 76% rename from foundations/consensus.mdx rename to foundations/network/adnl.mdx index 9bc733758..857bae85e 100644 --- a/foundations/consensus.mdx +++ b/foundations/network/adnl.mdx @@ -4,4 +4,4 @@ title: "Consensus" import { Stub } from '/snippets/stub.jsx'; - + From 540405f359db3451a67115ebd87215c14ce07d3a Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 13:50:56 +0300 Subject: [PATCH 05/21] fmt --- foundations/consensus/bcp-overview.mdx | 1 - foundations/network/adnl.mdx | 4 +++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/foundations/consensus/bcp-overview.mdx b/foundations/consensus/bcp-overview.mdx index 27d6f513d..a31ba9647 100644 --- a/foundations/consensus/bcp-overview.mdx +++ b/foundations/consensus/bcp-overview.mdx @@ -8,7 +8,6 @@ import {Aside} from "/snippets/aside"; - diff --git a/foundations/network/adnl.mdx b/foundations/network/adnl.mdx index 857bae85e..e57e37550 100644 --- a/foundations/network/adnl.mdx +++ b/foundations/network/adnl.mdx @@ -4,4 +4,6 @@ title: "Consensus" import { Stub } from '/snippets/stub.jsx'; - + From 542f0313365af214757b70cd7245da0a5e33d62b Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 13:52:58 +0300 Subject: [PATCH 06/21] fix --- foundations/consensus/bcp-overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/foundations/consensus/bcp-overview.mdx b/foundations/consensus/bcp-overview.mdx index a31ba9647..ba1358303 100644 --- a/foundations/consensus/bcp-overview.mdx +++ b/foundations/consensus/bcp-overview.mdx @@ -9,5 +9,5 @@ import {Aside} from "/snippets/aside"; From 0c38d495d0fc3330d815b9c7b395fbfde43c835c Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 14:12:48 +0300 Subject: [PATCH 07/21] link fix --- docs.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs.json b/docs.json index 5cb59ecf1..7ccf35cc4 100644 --- a/docs.json +++ b/docs.json @@ -521,7 +521,7 @@ "pages": [ "foundations/consensus/catchain-overview", "foundations/consensus/bcp-overview", - "foundations/consensus/bpc-deep-dive" + "foundations/consensus/bcp-deep-dive" ] }, "foundations/hypercube-routing", From 1356037e6199667e0524b75e472249e1cf8d230a Mon Sep 17 00:00:00 2001 From: b4cksl4sh Date: Thu, 30 Oct 2025 14:21:44 +0300 Subject: [PATCH 08/21] fix aside --- foundations/consensus/catchain-overview.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/foundations/consensus/catchain-overview.mdx b/foundations/consensus/catchain-overview.mdx index e23258721..37c6d70dc 100644 --- a/foundations/consensus/catchain-overview.mdx +++ b/foundations/consensus/catchain-overview.mdx @@ -3,7 +3,7 @@ title: "Catchain overview" sidebarTitle: "Catchain overview" --- -import {Aside} from "/snippets/aside"; +import {Aside} from "/snippets/aside.jsx"; Catchain is a communication protocol between validators. It does not execute the consensus algorithm itself but prepares the data required for the decision-making of a higher-level component: [BCP - Block Consensus Protocol](/foundations/consensus/bcp-overview). @@ -44,7 +44,7 @@ Each actor is responsible for indexing its own messages and increasing the seque If an actor issues two messages with the same identifier `(A; i)` but different payloads, the situation is called a fork. Any validator who observes it can construct a proof consisting of the block identifier and two distinct signatures. Since all public keys are known, this proof can be broadcast to the neighbors, and then further across the network. Every honest participant who receives the proof starts ignoring all messages from node A, as well as all messages that depend on A's messages. -