Технические аспекты блокчейн платформы The Power: сессия вопросов и ответов с CTO проекта, Игорем Белоусовым

Итак, сегодня мы поговорим с CTO проекта The Power, Игорем Белоусовым, о технической составляющей проекта - алгоритме консенсуса, шардинге, архитектуре платформы, отличиях от конкурентных решений.

Добрый день Игорь, за время существования проекта накопилось много вопросов, чуть позже мы перейдем к ним, но сначала опишите одним предложением суть продукт/технологии - для тех читателей, кто не знаком с проектом.

Здравствуйте. Если одним предложением:

Платформа The Power - трехуровневая программная система распределенного реестра (DLT) для высокоскоростной обработки взаимодействий в децентрализованной публичной среде.

В основе платформы лежат 3 ключевых технологии:

Линейное масштабирование методом шардирования
Алгоритм консенсуса Resonance
Многоуровневая архитектура

То есть линейное масштабирование достигается за счет шардирования?

Да, шардинг плюс управление шардами с помощью Менеджмент Уровня.

Что такое шардинг или шардирование?

Все имеющиеся в наличии узлы системы автоматизированно разделяются на параллельно выполняемые частично изолированные распределенные системы - шарды.

Шард представляет собой практически независимо работающую систему DLT, в которой постоянно повторяемо происходит согласование сохраненных данных и вычислений над ними среди всех узлов шарда.

Расскажите о вашем алгоритме консенсуса Resonance

Алгоритм Resonance относится к семейству классических BFT (Byzantine fault tolerance, Византийская отказоустойчивость) консенсусов, в которых все участники должны знать криптографические ключи друг друга.

В чем главное отличие консенсуса Resonance от других BFT протоколов?

Самое главное отличие алгоритма Resonance то, что в нет лидера, блок создается всеми узлами. В остальных консенсусах блок создается узлом-лидером и потом подтверждается остальными узлами. Таким образом, мы сокращаем количество шагов согласования и главное - мы полностью убираем возможность цензуры, захват контроля над управлением шардом возможен только если произошел сговор более половины узлов. Т.к. все узлы могут подавать свою информацию, мы собираемся использовать обязательные действия по созданию дополнительных источников энтропии, чтобы создавать рандомайзер, максимально приближенный к реальности. Мы вносим в каждый блок такие данные от каждого узла, которые нельзя предсказать, т.к. эти данные подписаны их приватными ключами, а взломать их проблематично. Т.е. на каждом блоке вносятся новые данные подписанные ключами.

Какие взаимодействия происходят в Менеджменте уровне, а какие на уровне шардов?

Менеджмент уровень: регистрация пользователя (аккаунта), регистрация шардов, регистрация приватных шардов, регистрация узлов, назначение проверочных узлов (валидаторов), наказание узлов. В Менеджмент уровне транзакции управления проверяются всеми узлами системы, поэтому, это относительно дорогое взаимодействие.
Уровень шардов: все классические транзакции, которые есть в обычных классических блокчейнах.

Чем ваш шардинг отличается от аналогичных решений?

Сейчас нет устоявшейся параметров, по которым сравнивают шардинги, у каждого проекта - свои особенности.
Однако, я предложил свою классификацию для распределенных систем с шардингом. Ниже представлена таблица сравнения известных платформ с шардингом.

Примечание: по некоторым проектам не вся информация опубликована

Если в системе есть центральная цепочка (main chain) - значит скорость валидации любой транзакции равна скорости валидации в центральной цепочке - 2-3 минуты в целом. Есть мнение, что когда есть центральная цепочка - это фактически разные блокчейны, объединенные в одной платформе, а не единая блокчейн сеть.
Состояние (state) - все параметры системы на данный момент (все аккаунты, количество средств на них, смарт-контракты и их состояние). Если полное состояние (full state), как например, в проекте Zilliqa - все узлы должны хранить всю информацию, что затратно. Но плюс в том, что проще делать валидацию. Шардовый тип (Sharding state) - каждый шард работает полностью отдельно, валидация занимает значительное время. А у нас - смешанный тип состояния (mixed state). Часть данных (состояние шардов, какие аккаунты к какому шарду относятся, состояние аккаунтов, приватных шардов, какие узлы являются валидаторами) хранится на всех узлах. А данные, которые обрабатываются - хранятся внутри шарда.
Межшардовые транзакции у большинства проектов идут через центральную цепочку, в нашей системе - напрямую.

За счет чего достигнуто время валидации транзакции менее 1 сек?

Уменьшено количество шагов согласования до 3-х. Максимальное количество узлов в шарде - не более 150. BFT протоколы максимально быстро работают на малом количестве узлов.

Каким образом реализуется децентрализация системы?

Техническая децентрализация достигается благодаря протоколу Resonance.
Экономическая (социально-экономическая) децентрализация - через PoS (proof-of-stake) алгоритм. Владельцу выгодно защищать от захвата свой узел. Ему не выгодно экономически компрометировать систему.

На сайте упоминается, что вы используете механизм минтинга вместо майнина. Чем отличается минтинг от майнинга?

Минтинг в отличие от майнинга не требует вычисления, узел получает вознаграждение за сам факт создания блока.

Сколько транзакций входит в один блок, каков его размер?

Размер блока - динамический, 1 блок в секунду. Поэтому количество транзакций в блоке будет зависеть от рабочей нагрузки на шард. Мы ожидаем в среднем 80 транзакций в секунду в одном шарде, размер одной транзакции - около 200 байтов.

Как часто меняются валидаторы?

Предполагается смена Валидаторов раз в 1 час (раз в 3600 блоков).

Валидатор проверяет блоки в чужих шардах. Тогда как валидатор знает, верифицировать блок или нет?

Каждый блок любого шарда проверяется также валиаторами - узлами из числа нод других шардов. Назначение какому узлу какой шард проверять, происходит постоянно на Менеджмент уровне.

Что будет происходить с данными, если злоумышленники уничтожат шард?

Данные о состоянии шарда хранятся в двух других шардах. Могут исчезнуть последние 2-3 блока, все что ранее - восстановятся.

Как ваша платформа защищена от атаки 51%?

Для захвата системы управления платформы - Менеджмент Уровня необходимо захватить более 50% всех нод во всех шардах. Это условие похоже на работающие в системах с PoW.

Захват отдельного шарда также ни к чему не приведет - так как все транзакции шарда проверяются внешними валидаторами. А для того, чтобы уверенно захватить еще и большинство валидаторов, необходимо получить большинство всех нод. Что приводит нас к тем же показателям надежности.

Есть ли защита от атаки Сивиллы (Sybil attack)?

Защита от атаки Сивиллы - механизм PoS (proof-of-stake). Чтобы узел был подключен к системе, его владелец должен отправить на определенный системный адрес 500 000 SK токенов.

Спасибо за подробные ответы, надеемся нашим читателям понравился материал. А также надеемся, что он сподвигнет вас задавать новые интересные и непростые вопросы!

Ждем ваши вопросы в нашем чате для разработчиков: https://t.me/thepower_dev