Консенсус в Тоне, обзорно

За время существования Тона в опенсорсе, консенсус, описанный Николаем в catchain.pdf, обсуждался меньше всего. В этом посте разберемся как валидаторы договариваются о принятии новых блоков, почему в Тоне не бывает форков (finality = latency) и как можно это потрогать.

Пдф описывает два протокола - собственно сам Кэтчейн и BCP (Block Consensus Protocol).

Несмотря на крутое название, Кэтчейн не является консенсусом в Тоне - описанный протокол вообще не связан с блокчейном и описывает как нужно обрабатывать зависимости между абстрактными сообщениями.

Вспомните npm или maven: каждое сообщение в Кэтчейне несёт с собой package.json, в котором лежат записи вида @node1/message-2 и @node2/message-3. Обработать входящее сообщение можно только после получения и обработки указанных зависимостей. Кэтчейн ничего не знает про стейки и валидацию блоков, он служит транспортом для BCP.

BCP - это PoS консенсус из семейства алгоритмов византийской отказоустойчивости (BFT). Это означает что сеть может продолжать успешную работу (выбирать одни и те же валидные блоки в одинаковом порядке) при наличии >= 2/3 “хороших” нод (взвешенный кворум по размеру стейков валидаторов).

Есть два семейства PoS алгоритмов:
1. C легкой генерацией блоков, разрешенными форками и их последующим разрешением
2. Со сложным согласованием выбора блока, при этом с отсутствием (почти) форков.

BCP относится ко вторым - чтобы нода посчитала блок принятым локально, она должна увидеть:

1. Пропоуз блока (Submit)
2. Кворум по валидации блока (Approve)
3. Кворум по голосованию за блок (Vote)
4. Кворум пре-коммитов на блок (PreCommit)
5. Кворум коммитов за блок (Commit)

Форков и ролл-бэков не бывает - блок финализируется до того как может появиться конкурентная ветка.

Для желающих разобраться во всем этом, мною была реализована визуальная интерактивная симуляция консенсуса Тона:
https://docs.ton.org/foundations/consensus/catchain-visualizer

Фидбэк приветствуется, ругать -> сюда, хвалить -> сюда