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

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

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

Шардирование

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

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

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

Каждая итерация согласования заносится в блок данных, который связан в цепочку блоков ссылкой на прошлый блок.


Консенсус Resonance

Для обеспечения качественного превосходства по процессу согласования внутри шардов применяется собственная разработка алгоритма согласования — алгоритм консенсуса Resonance.

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

Resonance имеет ряд важных отличий:

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

Более подробное описание вы найдете в технической документации проекта — YellowPaper.


3 уровня платформы

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

На Уровне Менеджмента узлы решают следующие вопросы:

  • Добавление, перемещение и удаление узлов в публичных шардах;
  • Создание, ветвление и удаление публичных шардов;
  • Регистрация создания и изменение конфигурации приватных шардов.

Кроме того, в нашей платформе реализован механизм, защищающий систему от внутренних атак. Без такой системы, которую мы называем Уровнем Валидаторов (Validators Layer), в случае если атакующий сможет получить большинство в отдельном шарде, он сможет деструктивно воздействовать на всю платформу в целом. Однако, с Уровнем Валидаторов, платформа может быть успешно атакована только в случае получения атакующим контроля над более половины узлов всей платформы, а не отдельного шарда.

И наконец, базовый уровень платформы — Уровень Шардов (Shards Layer). Все рабочие транзакционные взаимодействия и смарт-контракты выполняются в этом слое. Для различных целей формируются публичные, приватные и выделенные шарды.

Преимущества платформы

Благодаря описанным ключевым особенностям технологии платформа обладает рядом важных характеристик:

Пропускная способность более 100 000 транзакций в секунду. В дальнейшем будет увеличена.

 

Высокая масштабируемость за счет шардинга.

 

Время обработки транзакции — менее 1 секунды, благодаря синхронному консенсусу.

 

Высокая устойчивость к цензуре внутри шарда, благодаря синхронному консенсусу.

 

Высокая защищенность транзакций между шардами, благодаря Уровню Валидаторов.

 

Формирование публичных, приватных и выделенных шардов в едином адресном пространстве, благодаря архитектуре платформы.

 

Гибкая экономика, возможность подстраивать экономику шардов под конкретные нужды.

 

Настраиваемый уровень приватности действий пользователей платформы.


Виртуальная машина Wasm

В отличии от ряда проектов команда проекта не стала использовать EVM (виртуальную машину блокчейна Ethereum), а создала свою нативную виртуальную машину Power_VM на Wasm.

“WebAssembly (сокращенно Wasm) — это бинарный формат инструкций для стековой виртуальной машины. WebAssembly спроектирован как портативная цель компиляции для высокоуровневых языков, таких как C/C++/Rust, которую можно развертывать в web для клиентских и серверных приложений.” Википедия

Wasm является результатом многолетних совместных работ группы W3C, которая объединяет компании Microsoft, Google, Apple и Mozilla.

Wasm разрабатывают в первую очередь для применения в Web, однако, в “дорожной карте” упоминается и о применении в IoT, и для создания многопоточных тяжелых приложений.

Wasm совместим с семейством компиляторов LLVM (Low Level Virtual Machine) и оптимизирован по объему данных. Если на устройстве есть вариант такого компилятора, как на большинстве современных смартфонов, на этом устройстве принципиально можно запустить Wasm.

На данный момент, написана альфа версия Power_VM, оболочка, которая связывает программы на Wasm с блокчейном The Power. Благодаря ей наши смарт-контракты можно компилировать в Wasm код, вносить в блокчейн и запускать внутри тестнета The Power. Нами уже опробованы смарт-контракты — аналоги стандарта ERC-20.


Смарт-контракты

Для наших смарт-контрактов из языков, совместимых с Wasm, мы выбрали Rust — по ряду причин:

  • встроенные тесты
  • простой рефакторинг
  • универсальность языка
  • ряд ограничений для разработчика — для предотвращения ошибок при написании программ. Проще говоря, на Rust гораздо сложнее написать программу с ошибками.

После написания дополнительной документации в дальнейшем программисты смогут писать смарт-контракты и на C и C++.

Создать контракт

Уважаемый коллега, если вы пишете на языках Rust, C или C++, и вам интересно попробовать свои силы в написании смарт-контрактов — пожалуйста, оставьте свои контакты, и мы свяжемся с вами.


Тестнет и API

В феврале 2018 года запущена сеть из 3-х шардов для партнеров, с инструментами для разработчиков: Кошелек, “Кран”, Эксплорер, API.

  • Кошелек в системе выполняет одну из важнейших для пользователя функций — управление ключами (приватными и публичными). Сейчас приватный ключ хранится в файле (в зашифрованном файле). В первой боевой версии кошелька на время сессии кошелек будет дополнительно просить пользователя ввести пароль к файлу, чтобы его расшифровать и использовать приватный ключ, а по окончании сессии - будет “забывать” ключ. Зная приватный ключ пользователь в любой момент может сделать/восстановить публичный. Публичный ключ - в первую очередь, это идентификатор пользователя в сети.
  • Благодаря “Крану” (Faucet) пользователь может бесплатно получить в тестовые токены.
  • Эксплорер отображает транзакции и блоки.
  • Благодаря API разработчики уже сейчас могут разрабатывать сервисы на основе нашего блокчейна.

Один из последних примеров: наши партнеры и веб-разработчики со стажем, компания Byte-force, написали DLL библиотеку под .NET. Также, в ближайшее время появится библиотека для Python и JavaScript.

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

В репозитории на гитхабе вы найдете подробную инструкцию по подключению к тестовой среде и документацию к API


ДП 2.0 (децентрализованные приложения)

Мы добавили новую функцию в смарт-контракт — интерфейсную. Это позволяет доставлять до клиентских устройств гарантированно валидный клиентский код, что позволяет исключить возможность подмены кода и интерфейса взаимодействия с человеком. Таким образом, мы создаем новый стандарт - интерфейс взаимодействия клиентской части (фронтенда) и серверной (бэкенда).

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

В настоящее время мы не можем полностью раскрыть алгоритм взаимодействия смарт-контракта и клиентской части приложения. Однако укажем, что смарт-контракт проверяет оригинальность клиентской части и ее адрес расположения. Теперь нет необходимости создавать связующее ПО (middleware) и бэкенд, просто написать приложение на Rust, C, или C++, оно будет выполняться Wasm и компилироваться в бинарный код, понятный браузеру.

После подписания пользователем транзакции она меняет состояние смарт-контракта в блокчейне, и фронтенд ДП 2.0 может сразу получить и отобразить это изменение без задействования дополнительных серверов. Поэтому такую систему можно назвать “бессерверной” — serverless.

Первое ДП 2.0 было создано в качестве демонстрации концепта — это приложение Survey, которые вы можете найти в Маркетплейсе.

Единое адресное пространство

Несмотря на то, что основой платформы является множество шардов, для клиента платформы работа с ней должна выглядеть так же, как и работа с “монолитной” блокчейн платформой. Для этого необходимо чтобы все шарды оперировали единым адресным пространством клиентов. Объявляя единое адресное пространство для клиентов во всех шардах мы также решаем проблему адресации между клиентами, подключенными к различным шардам. Такая задача превращается в задачу поиска клиентов в шардах и маршрутизации между шардами.

Поэтому клиенту отправившему транзакцию, нет необходимости беспокоиться и выяснять, в каком шарде находится получатель транзакции, когда шард получателя получит информацию о транзакции клиента, все это берут на себя внутренние процессы шардов.

В отличии от платформ, в которых адрес клиента — это криптографически обработанный публичный ключ, на платформе The Power для обеспечения единого адресного пространства клиентов применяется общий реестр аккаунтов. Такая схема позволяет получить большие возможности, при малом усложнении системы:

  • Легко читаемый человеком адрес, который можно без сложностей передавать другой стороне обычными способами;
  • Универсальность применения типа криптографии ключей. При добавлении новых способов асимметричной криптографии нет необходимости отказываться от старых адресов;
  • Более простые способы применения мульти-подписей или даже мульти-подписей с иерархией;
  • Меньший размер адреса, особенно в случаях мульти-подписей и криптографических ключей высокой разрядности.

Технический FAQ

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

Автоматический шардинг + управление шардами Менеджмент уровнем.

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

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

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

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

The PowerZilliqaQuarkchainPchainChainweb (Kadena)Polkadot
Тип состояния (стейта) системы
Тип состояния (стейта) системыСмешанныйПолныйШардовыйШардовыйШардовыйШардовый
Метод передачи транзакции между шардами
Метод передачи транзакции между шардамиПрямойЧерез главную цепочкуЧерез главную цепочкуЧерез главную цепочкуПрямой (?*)Через главную цепочку
Метод валидации межшардовых транзакций
Метод валидации межшардовых транзакцийДополнительная или отложенная проверкаПолное состояние главной цепочкиЧерез главную цепочкуЧерез главную цепочкуДополнительная верификация (?*)Дополнительная или отложенная проверка
Система управления шардами
Система управления шардамиРешение большинстваЧерез главную цепочкуГлавная цепочка (?*)Через главную цепочкуРешение большинстваЧерез главную цепочку
Особенности ноды
Особенности нодыРавноправные узлыПривилегированные узлы в “главной” цепочкеПривилегированные узлы в “главной” цепочкеРавноправные узлыПривилегированные узлы в “главной” цепочке
Тип аккаунта Платформы
Тип аккаунта ПлатформыЕдиныйЕдиныйМета-аккаунт

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

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

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

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

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

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

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

Чем отличается минтинг от майнинга.

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

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

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

Что такое токен Smart Key? Чем Smart Key отличается от других токенов?

Когда приходит блок из чужого шарда, валидатор знает, кто из узлов является валидатором (выше мы описывали, что входит в full state). Если больше 50% валидаторов подписали блок - тогда валидатор принимает решение подписать блок.

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

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

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

Для захвата системы управления платформы — Менеджмент Уровня, необходимо захватить более 50% всех нод во всех шардах. Это условие схоже с работающими в системах с PoW. Захват отдельного шарда также ни к чему не приведет - так как все транзакции шарда проверяются внешними валидаторами. А для того, чтобы уверенно захватить еще и большинство валидаторов, необходимо получить большинство всех нод. Что приводит нас к тем же показателям надежности.

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

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

А сам проект, его инновационные технологии как-то защищены?

Все составляющие платформы The Power написаны полностью “с нуля” разработчиками проекта, ключевые особенности проекта запатентованы, что защищает проект, его партнеров и заказчиков от потенциальных внешних влияний, уязвимостей, попыток контроля.