По данным ^[1] аналитических агентств, рынок блокчейн-технологий вырастет с 210 млн долларов в 2016 году до 2,3 млрд долларов к 2021. Среднегодовой рост составит 61,5%. При этом в формировании рынка участвуют ^[2] как крупные компании (например, IBM, вложившие ^[3] 200 млн долларов в IoT-проекты, связанные с блокчейном), так и небольшие ^[4] стартапы, адаптирующие блокчейны под разные нужды.

Bitfury Group выпускает ^[5] новую версию открытого фреймворка для разработки блокчейнов Exonum ^[6]. Exonum 0.2 содержит регулярные исправления, а также некоторые конструктивные доработки. С помощью Exonum компании и правительственные организации могут создавать функциональные блокчейны, которые будут безопасны, прозрачны и контролируемы.

/ Exonum 0.2 Release ^[7] / Exonum ^[7]

В Exonum реализован особый ^[8] алгоритм византийского консенсуса (мы писали об этом в одном из наших материалов ^[9]). Он не требует майнинга блоков и работает быстрее — блокчейн обрабатывает 3 тыс. транзакций в секунду.

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

Что нового и изменения

Релиз Exonum 0.2 содержит внутренние системные доработки, упрощающие работу с фреймворком, и фиксы, которые «закрывают» самые очевидные недостатки.

Добавлена поддержка RocksDB ^[10]

RocksDB представляет собой key — value базу данных с более широкими возможностями по сравнению с LevelDB, которая использовалась в Exonum изначально.

Мы перешли на RocksDB, потому что она имеет богатый коробочный функционал и хорошо поддерживается разработчиками. Отметим, что сейчас Exonum работает с обеими базами данных, но дальнейшая работа нацелена на внедрение нового функционала с окончательным переходом на RocksDB. Вот некоторые из планируемых дополнений:

1. Использование семейств столбцов (column families ^[11]). Они позволят логично разделить базу данных на части (по сути, таблицы), упорядочить ее вид, обеспечить надежное хранение и управление данными. Кроме того, изменения к такой базе могут применяться атомарно, то есть прописываться одновременно в несколько таблиц.

2. Использование встроенных в RocksDB транзакций ^[12] — удобное коробочное решение, которое отсутствовало в LevelDB (было реализовано вручную). Транзакции также позволяют атомарно применять изменения к базе данных и имеют интерфейс типа BEGIN/COMMIT/ROLLBACK. Это дает возможность управлять изменениями в случае выявления неполадок, а также править данные и одновременно проверять конфликты.

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

3. Резервное копирование данных (см. Backups ^[13] и Checkpoints ^[14]) — возможность создания снимка состояния базы данных. При необходимости такие снимки могут быть использованы как для чтения, так и для чтения и записи.

Резервное копирование может выполняться полностью, а может только для той части данных, которая была изменена после последнего бэкапа. Такая гибкая функциональность значительно облегчает запуск нового узла в системе или обновление данных прежнего узла после «падения».

4. Сбор статистики — административный функционал, который представляет собой получение динамических характеристик базы данных (объём, скорость работы и др.) в виде истории, и может использоваться для более эффективной настройки, управления и мониторинга системы. В частности, для выбора оптимальных настроек узлов.

Добавлена поддержка динамических таймаутов

До текущего релиза таймауты необходимо было фиксировать в конфигурации, и они оставались неизменными при любом состоянии системы. Это приводило к тому, что блоки транзакций принимались в блокчейн с постоянной частотой, и при нулевой загрузке системы происходило «замусоривание» блокчейна пустыми блоками.


Например, при установлении таймаута длительностью в одну секунду и нулевой загрузке системы размер одного блока для системы из четырех узлов-валидаторов в среднем составлял 472 байта. За сутки работы «вхолостую» система расходовала 41 мегабайт дискового пространства.

Жесткая фиксация таймаута приводила к тому, что при слишком низком его значении росла скорость принятия новых блоков. Это увеличивало количество затрачиваемых ресурсов на обработку транзакций для формирования блоков, а также криптографических доказательств при их проверке. Соответственно, при установлении слишком высокого значения таймаута в обработке входящих транзакций возникали задержки, а при большом трафике начинался «застой» необработанных транзакций в пуле.

В новой реализации были добавлены две новые опции для управления таймаутами:

• Динамическая (Dynamic) — выбор происходит между минимальным и максимальным значением таймаута в зависимости от загрузки системы.
• Скользящее среднее (Moving Average) — опция похожа на предыдущую, однако позволяет определять промежуточные значения таймаутов в соответствии с одноимённым правилом ^[15].

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

В отличие от Exonum, блокчейны на основе консенсуса Proof-of-Work (например, биткойн) имеют встроенный принцип регуляции интервалов между блоками. А именно: в биткойне сложность вычисления нового блока автоматически изменяется таким образом, чтобы скорость принятия блока всегда составляла 1 блок в 10 минут. Таким образом, чем выше скорость принятия блоков, тем выше сложность вычисления и наоборот. В результате интервал принятия нового блока практически не зависит от общей вычислительной мощности сети.

Внедрено поточное шифрование

Функционал связан с оптимизацией работы с памятью. Ранее для шифрования данных, которые хранятся в различных участках памяти, необходимо было предварительно скопировать эти данные в оперативную память (RAM), для чего в ней дополнительно выделялось место, соответствующее размеру шифруемых данных. С внедрением возможности шифрования раздробленных данных «на лету», дополнительного копирования в RAM удалось избежать, и, следовательно, увеличить быстродействие системы.

С полным перечнем изменений вы можете ознакомиться по ссылке ^[16]. Руководство по работе с платформой есть в базе знаний ^[17] Exonum. Там же вы найдете пример ^[18] создания сервисов с кодом и комментариями.

---

Минорные релизы Exonum ожидаются раз в месяц. Следующий апдейт назначен на середину октября 2017 года. Следить за новостями о разработке продукта вы можете, оформив подписку ^[19], или в нашем блоге ^[20]. Задать вопросы команде можно в Gitter ^[21] (наш GitHub ^[22]).

Автор: alinatestova

Источник ^[23]