Exonum 0.3 — что мы улучшили в новой версии фреймворка для разработки блокчейнов

    Мы продолжаем развивать Exonum. В этот раз мы сосредоточили внимание на двух вещах: полностью перевели хранение данных на RocksDB, при этом прекратив поддержку LevelDB, и переписали сетевой код на Tokio. Зачем: эти решения позволили нам повысить эффективность хранения данных и увеличили производительность кода в сети.

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


    / Exonum

    Tokio — это обработчик цикла событий, который специально заточен под асинхронное программирование. Он базируется на асинхронном вводе/выводе (I/O), что обеспечивает непрерывную работу с событиями в потоке. Отдельные события обслуживаются в фоновом режиме до того момента, пока не будет получен конечный результат.

    Параметр, обеспечивающий асинхронное управление событиями, называется future. Это значение, которое будет подсчитано в будущем, однако на текущий момент не известно. Futures являются составными объектами и могут включать в себя цепочки событий, реализующих бизнес-логику процессов.

    Например, в контексте Exonum, это может быть представлено следующим образом:

    Подсоединиться к узлу «В» —> Обработать байты узла «В» и разбить их на сообщения —> Перенаправить каждое сообщение в канал узла

    Помимо futures в Tokio также присутствует базовый компонент для асинхронного I/O — stream. Это поток байтов, который преобразуется в другие элементы. В то время как future возвращает только один конечный результат, stream может возвращать несколько результатов, пока не будет полностью выполнен. Иными словами, stream оперирует серией событий, что делает его эффективным при работе со сложными схемами взаимодействий.

    Например, в Exonum TCP stream будет преобразован в сообщения Exonum. Этот stream направляется в код консенсуса по соответствующему каналу, и после их слияния код отбирает необходимые ему сообщения от сети и обрабатывает их.

    Еще одним существенным улучшением стала возможность узлов работать с тремя разными очередями вместо одной, которая существовала в сетевом коде на Mio. Глобально сеть управляет тремя основными типами событий при выполнении алгоритма консенсуса: входящими транзакциями, сообщениями и таймером.

    Раньше транзакции и сообщения перегружали одну очередь, и события таймера оставались за её пределами. Соответственно, новые раунды алгоритма консенсуса не начинались, и он попросту стопорился. Наличие дополнительных очередей резко повысило стабильность узлов.

    Аналогично для нового кода была организована работа в два потока: один для обслуживания внешних сетевых событий (ответы на сетевые сообщения), а второй — для самого консенсуса. При этом также существует отдельный поток для передачи транзакций, полученных через REST API. В результате это повысило производительность и стабильность работы сети: новые блоки принимаются с равномерным интервалом в 0,5 секунды, при этом, при необходимости скорость принятия блока может быть снижена.

    Удвоилась скорость подтягивания, то есть снизилось время, необходимое на получение отстающим узлом отсутствующих у него блоков. Например, в сети с 4 узлами скорость принятия блока при параллельном подтягивании ранее составляла 200–300 мс. Перевод только отстающего узла на новый код привел к тому, что интервал сократился до 100 мс. Ожидается, что если адаптировать всю сеть, показатели станут еще лучше. Статистика выше приведена для пустых блоков и может отличаться для сети «под нагрузкой».

    Мы также провели приблизительные расчеты влияния описанных изменений на производительность кода в сети с 4 валидаторами и одним дата-центром. Средняя скорость обработки при принятии блоков с тысячей транзакций составила:

    • 7318 транзакций в секунду для кода на Mio и LevelDB;
    • 20237 транзакций в секунду для кода на Tokio и LevelDB;
    • 31571 транзакций в секунду для кода на Tokio и RocksDB.

    Таким образом, с переходом на Tokio код в Exonum стал более производительным и структурированным, что упростило его поддержание.

    Еще одним улучшением стало внедрение нового индекса в хранилище — SparseListIndex. Он представляет собой упорядоченную структуру (перечень элементов), который может содержать пропуски. Это означает, что при удалении произвольной строки в списке, индекс сохранит работоспособность. Для сравнения в ListIndex все вхождения строго пронумерованы от 0 до n-1, где n — количество элементов списка, и удалять их можно только с конца списка.

    Также была добавлена базовая инфраструктура для сбора метрик и статистических данных в Exonum и сервисах. Опция полезна для оценки эффективности работы узла и будет окончательно реализована в будущих релизах.

    Наконец, мы бы хотели обратить внимание разработчиков сервисов на следующие позиции:

    • Поле events_pool_capacity в MemoryPoolConfig было заменено на новую конфигурацию EventsPoolCapacity;
    • NodeBuilder теперь использует ServiceFactory как объект, а не как тип;
    • Была изменена сигнатура функции gen_prefix в модуле schema;
    • Изменился конструктор индексов. В связи с использованием column families, доступных в RocksDB, стало возможным определение индексов при помощи строкового наименования, как это обычно реализовано в других базах данных (например, Transactions, Wallets и т. д.).

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


    / Exonum

    Еще больше о нововведениях — по ссылке. С вопросами к нашей команде и предложениями по развитию проекта вы можете обратиться в Gitter или GitHub.
    • +20
    • 3,7k
    • 5
    Bitfury Group 124,86
    Cофтверные и хардверные решения на Blockchain
    Поделиться публикацией
    Комментарии 5
    • +2
      Напомните плз, какой у вас консенсус и как пишутся смарт контракты
      • 0
        Мы планируем подготовить материал о консенсусе в ближайшее время.

        Документация по теме: 1 и 2.

        Если будут дополнительные вопросы, обращайтесь.
      • +2
        Как считаете, можно ли сервисы Exonum использовать как бизнес-логику разрабатываемой системы?

        Вот допустим, мы делаем проект типа хабра: есть пользователи, посты, комменты, рейтинги пользователей, лайки постов и комментов и проч. И (ВДРУГ) мы хотим сохранять инфу в блокчейн, чтобы… ммм… несколько организаций (участники-организаторы проекта) могли иметь инфу у себя и другие участники не могли бы её подделать в свою выгоду (ну допустим это завязано на деньги потом как-то будет, поэтому важна достоверность).

        Предполагается ли в концепции exonum, что всю логику можно делать как сервисы exonum, или всё же нужно делать ещё один слой бизнес-логики, который отправляет данные в exonum (и синхронно или асинхронно это тогда делать)?

        И как быть с ключами пользователей для шифрования транзакций, если делать веб-морду для этого (или придется делать только приложение?)? Транзакция: «Я, Вася, с таким-то открытым ключом, оставил этот коммент, вот я его подписал закрытым ключом». Закрытые ключи не хотелось бы в профиле на сайте хранить, его взлом будет означать потерю доверия всем транзакциям.
        • 0
          Вы можете реализовать всю бизнес-логику системы с помощью сервисов Exonum. Они более «гибкие», чем смарт-контракты. И могут быть реализованы в соответствии с потребностями системы и необходимой сложности бизнес-логики процесса. Более того, в дальнейшем сервисы можно дорабатывать и оптимизировать. Дополнительный слой бизнес-логики не требуется, все взаимодействия с блокчейном в Exonum осуществляются посредством API.

          Приватные ключи не хранятся на сайте в аккаунте пользователя. В этом отношении существует два наиболее оптимальных варианта:

          1. Приватный ключ может быть зашифрован и сохранен в блокчейн. Пользователь имеет возможность запросить ключ, однако расшифровать его он сможет только при помощи парольной фразы, которую сам и придумал. Вот подходящие (на наш взгляд) для этих целей библиотеки: 1 и 2.
          2. Пользователь придумывает длинную мнемоническую фразу, при помощи которой воссоздает свой закрытый ключ.
        • –1
          Блокчейн на расте — мой хипстометр зашкаливает :)

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое