По данным аналитических агентств, рынок блокчейн-технологий вырастет с 210 млн долларов в 2016 году до 2,3 млрд долларов к 2021. Среднегодовой рост составит 61,5%. При этом в формировании рынка участвуют как крупные компании (например, IBM, вложившие 200 млн долларов в IoT-проекты, связанные с блокчейном), так и небольшие стартапы, адаптирующие блокчейны под разные нужды.
Bitfury Group выпускает новую версию открытого фреймворка для разработки блокчейнов Exonum. Exonum 0.2 содержит регулярные исправления, а также некоторые конструктивные доработки. С помощью Exonum компании и правительственные организации могут создавать функциональные блокчейны, которые будут безопасны, прозрачны и контролируемы.
В Exonum реализован особый алгоритм византийского консенсуса (мы писали об этом в одном из наших материалов). Он не требует майнинга блоков и работает быстрее — блокчейн обрабатывает 3 тыс. транзакций в секунду.
Дополнительно Exonum привязывается к биткойн-блокчейну. Сеть высылает в поддерживающий блокчейн хеши блоков, чтобы повысить безопасность. Для атаки на такую сеть потребуется преодолеть механизмы консенсуса для обоих блокчейнов — поддерживающего и закрытого.
Что нового и изменения
Релиз Exonum 0.2 содержит внутренние системные доработки, упрощающие работу с фреймворком, и фиксы, которые «закрывают» самые очевидные недостатки.
Добавлена поддержка RocksDB
RocksDB представляет собой key — value базу данных с более широкими возможностями по сравнению с LevelDB, которая использовалась в Exonum изначально.
Мы перешли на RocksDB, потому что она имеет богатый коробочный функционал и хорошо поддерживается разработчиками. Отметим, что сейчас Exonum работает с обеими базами данных, но дальнейшая работа нацелена на внедрение нового функционала с окончательным переходом на RocksDB. Вот некоторые из планируемых дополнений:
1. Использование семейств столбцов (column families). Они позволят логично разделить базу данных на части (по сути, таблицы), упорядочить ее вид, обеспечить надежное хранение и управление данными. Кроме того, изменения к такой базе могут применяться атомарно, то есть прописываться одновременно в несколько таблиц.
2. Использование встроенных в RocksDB транзакций — удобное коробочное решение, которое отсутствовало в LevelDB (было реализовано вручную). Транзакции также позволяют атомарно применять изменения к базе данных и имеют интерфейс типа BEGIN/COMMIT/ROLLBACK. Это дает возможность управлять изменениями в случае выявления неполадок, а также править данные и одновременно проверять конфликты.
Стоит отметить, что настройки базы позволяют в любой момент установить удобный вид параллелизма— пессимистический (строки в источнике данных блокируются, запрещая пользователям модифицировать данные, когда с ними работает другой пользователь) или оптимистический (блокировка не производится, однако приложение определяет, изменялась ли строка).
3. Резервное копирование данных (см. Backups и Checkpoints) — возможность создания снимка состояния базы данных. При необходимости такие снимки могут быть использованы как для чтения, так и для чтения и записи.
Резервное копирование может выполняться полностью, а может только для той части данных, которая была изменена после последнего бэкапа. Такая гибкая функциональность значительно облегчает запуск нового узла в системе или обновление данных прежнего узла после «падения».
4. Сбор статистики — административный функционал, который представляет собой получение динамических характеристик базы данных (объём, скорость работы и др.) в виде истории, и может использоваться для более эффективной настройки, управления и мониторинга системы. В частности, для выбора оптимальных настроек узлов.
Добавлена поддержка динамических таймаутов
До текущего релиза таймауты необходимо было фиксировать в конфигурации, и они оставались неизменными при любом состоянии системы. Это приводило к тому, что блоки транзакций принимались в блокчейн с постоянной частотой, и при нулевой загрузке системы происходило «замусоривание» блокчейна пустыми блоками.
Например, при установлении таймаута длительностью в одну секунду и нулевой загрузке системы размер одного блока для системы из четырех узлов-валидаторов в среднем составлял 472 байта. За сутки работы «вхолостую» система расходовала 41 мегабайт дискового пространства.
Жесткая фиксация таймаута приводила к тому, что при слишком низком его значении росла скорость принятия новых блоков. Это увеличивало количество затрачиваемых ресурсов на обработку транзакций для формирования блоков, а также криптографических доказательств при их проверке. Соответственно, при установлении слишком высокого значения таймаута в обработке входящих транзакций возникали задержки, а при большом трафике начинался «застой» необработанных транзакций в пуле.
В новой реализации были добавлены две новые опции для управления таймаутами:
- Динамическая (Dynamic) — выбор происходит между минимальным и максимальным значением таймаута в зависимости от загрузки системы.
- Скользящее среднее (Moving Average) — опция похожа на предыдущую, однако позволяет определять промежуточные значения таймаутов в соответствии с одноимённым правилом.
Теперь, опираясь на значение таймаута раунда, в котором был принят предыдущий блок, а также на количество транзакций в этом блоке, система подбирает оптимальное значение таймаута для следующего блока. Ожидается, что это сделает управление системой гибким и эффективным, поскольку позволит регулировать ее загрузку.
В отличие от Exonum, блокчейны на основе консенсуса Proof-of-Work (например, биткойн) имеют встроенный принцип регуляции интервалов между блоками. А именно: в биткойне сложность вычисления нового блока автоматически изменяется таким образом, чтобы скорость принятия блока всегда составляла 1 блок в 10 минут. Таким образом, чем выше скорость принятия блоков, тем выше сложность вычисления и наоборот. В результате интервал принятия нового блока практически не зависит от общей вычислительной мощности сети.
Внедрено поточное шифрование
Функционал связан с оптимизацией работы с памятью. Ранее для шифрования данных, которые хранятся в различных участках памяти, необходимо было предварительно скопировать эти данные в оперативную память (RAM), для чего в ней дополнительно выделялось место, соответствующее размеру шифруемых данных. С внедрением возможности шифрования раздробленных данных «на лету», дополнительного копирования в RAM удалось избежать, и, следовательно, увеличить быстродействие системы.
С полным перечнем изменений вы можете ознакомиться по ссылке. Руководство по работе с платформой есть в базе знаний Exonum. Там же вы найдете пример создания сервисов с кодом и комментариями.
Минорные релизы Exonum ожидаются раз в месяц. Следующий апдейт назначен на середину октября 2017 года. Следить за новостями о разработке продукта вы можете, оформив подписку, или в нашем блоге. Задать вопросы команде можно в Gitter (наш GitHub).
Автор: alinatestova
