AMA-сессия, преимущественно посвященная обсуждению Whitepaper Free TON, прошла 18 августа с участием Мити Горошевского, Павла Приголовко и других участников сообщества.
Вопросы, посыпавшиеся на технического директора TON Labs прекрасно отражают состояние платформы Free TON:
- когда произойдет переход основной сети (мэйннет) на Rust-ноду?
- как форсировать процесс внедрения Governance 2.0?
- что собой представляет новый протокол консенсуса, который должен заменить (или, скорее, дополнить) BFT?
Ответ по большинство из них дал Павел Приголовко, который ситуацию с развитием Free TON резюмировал так:
То, что сейчас разрабатывается, это настолько новая вещь, что использовать старый опыт в оценке сроков не получится.
Переезд на Rust ноду
По поводу переезда на Rust-ноду, Митя Горошевский отметил, что рассматривать можно два варианта.
Первый — переезжать сейчас, без внедрения нового протокола консенсуса. В этом случае необходимо будет провести аудит безопасности и подготовить протокол перехода. Оптимистичная оценка по срокам — три месяца, пессимистичная — конец года. Однако это не тот вариант, который нравится самому техническому директору, так как он считает пустым занятием переезжать на новую ноду ради самого факта переезда.
Второй вариант учитывает первоначальное внедрение нового консенсуса, на реализацию которого могут уйти месяцы. Сколько именно, никто предсказать сейчас не готов.
- Занятость Rust-нодой и новым консенсусом — не тормозит ли это все внедрение Governance 2.0?
Горизонт — это воображаемая линия. Важно, чтобы Gov 2.0 не превратился в этот горизонт. Участники АМА-сессии
Митя ответил, что внедрением децентрализованного управления блокчейном занимается совершенно другая команда, поэтому такой зависимости нет. Что же касается активизации перехода к новому управлению, то здесь многое зависит от активности и наличия заинтересованных сторон. Система смарт-контрактов SMV уже находится в высокой степени готовности и может быть запущена.
Новый алгоритм консенсуса
Этой теме была посвящена основная часть АМА-сессии. Митя подробно разъяснил нововведения в Whitepaper, о которых мы писали, и раскрыл технические подробности алгоритма.
Недостатки существующего протокола
По словам Мити, на текущий момент блокчейн делится на потоки. Их многие неправильно называют шардами, хотя правильнее называть их треды (threads), в которых распределено некоторое количество валидаторов. Они в соответствии с протоколом BFT достигают консенсуса, подписывают блок и отправляют заголовок блока (header) и сам блок мастерчейну.
Мастерчейн удостоверяется, что блок подписан, то есть блок проверяется только BFT-консенсусом соответствующего треда, после чего хэдер блока добавляется в блок мастерчейна, а сам блок отбрасывается. Пересылка блока треда в мастерчейн нужна только для одного — для подтверждения факта бродкаста.
Проблем у такого подхода много, самая очевидная — финализация. Чтобы убедиться что блок финализирован, нужно дождаться включение его заголовка в блок мастерчейна, на что уходит минимум 10 секунд, а обычно — 20-30.
Доказательство рассылки блока
Предлагается не ждать завершения консенсуса. BFT есть и пусть остается в треде. После того как коллатор выпускает блок, этот блок является кандидатом и сразу высылается в бродкаст. В этом случае не нужно ждать никакой финализации в рамках треда.
Важно доказать, что сам блок был разослан в бродкаст, не посылая сам блок в мастерчейн.
Пересылка блоков в мастерчейн ограничивает масштабируемость всей сети.
При помощи BLS-подписи из любой выборки валидаторов можно агрегировать подпись в 32-байтную структуру. Зная публичные ключи всех валидаторов, можно доказать, что публичный ключ в этой подписи есть. Все валидаторы, которые получают блок, готовят эту BLS-сигнатуру и отсылают ее некоторому количеству верификаторов (в Free TON их называют бродкаст-протекторами). Верификаторы собирают подписи, и когда будет собран 51% подписей, то можно будет считать, что передача в бродкаст состоялась.
Мы должны перейти от доказательства хранения к доказательству передачи. Митя Горошевский
Теперь вместо блока в мастерчейн отправляется эта 32-байтная структура. Получив ее, мастерчейн быстро проверяет, что в ней есть 51% публичных ключей сета валидаторов данного воркчейна, и для каждого воркчейна этого достаточно.
Проверка блока
Заключительный этап алгоритма консенсуса состоит в том, что определяется рандомный sub-сет валидаторов, которые проверяют данный блок. Если кто-то из них обнаруживает ошибку, то он пишет NAK, если ошибки нет, то AK. Мастерчейну необходимо получить один NAK, чтобы запустить процедуру перепроверки этого блока с участием большого количества валидаторов, потому что если окажется, что этот блок был подписан не большинством, а меньшинством (менее 51%), то можно однозначно слэшить всех валидаторов данного треда, которые создали и подписали блок.
До момента проверки верификаторами блока никто не знает, кто эти бродкаст-протекторы, но при этом они удостоверяют свою оценку AK или NAK, когда отправляют свой ответ.
NAK отправляется во все ноды мастерчейна и в другие ноды воркчейнов, то есть во все существующие ноды Free TON. Все это происходит в рамках одного блока, со скоростью валидации в самом треде — 0,5- 0,6 секунды.
Преимущества нового протокола
Вероятность успешной атаки на блокчейн в данном случае стремится к нулю, поскольку оказывается достаточно одного честного валидатора (из выбранных рандомно), чтобы осуществить пристальную проверку блока, который вызывает сомнения. К тому же при том количестве валидаторов, которое есть сейчас у Free TON, становится бессмысленно дорогой атаку 51%.
Помимо безопасности, преимуществом алгоритма является и скорость. В результате внедрения нового алгоритма консенсуса Free TON превращается в самую производительную и децентрализованную сеть среди существующих блокчейнов, каждая нода которой гарантирует безопасность всей платформы.