Архитектура Exonum

В этом документе описывается высокоуровневая архитектура Exonum. Он предназначен для разработчиков ядра Exonum. Чтобы узнать, как использовать Exonum, см. [документацию].

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

Организация кода

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

Хранилище

Модуль хранилища можно найти в ящике exonum-merkledb. Он предоставляет абстракцию над встроенным хранилищем ключ-значение с семействами столбцов: признак Database. Ключи и значения могут быть представлены в виде срезов байтов: &[u8].

Для преобразования необработанных байтов в собственные структуры данных Rust и наоборот используются признаки BinaryKey и BinaryValue.

Помимо необработанного хранилища предоставляются коллекции, такие как наборы, списки и карты; см. различные структуры *Index. Особый интерес представляют ProofMapIndex и ProofListIndex, которые предоставляют меркелизованные коллекции. Эти коллекции способны предоставлять компактные доказательства для поисковых запросов. Подробности реализации см. в соответствующих модулях (indexes::{proof_list_index, proof_map_index}).

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

Блокчейн

Основы управления блокчейном находятся в ящике exonum (также известном как ядро).

Модуль blockchain определяет схему данных, используемую ядром (подмодуль schema), и связанные вещи, такие как блоки (подмодуль block), конфигурации (config) и подключение к узлу (api_sender). Общие ресурсы узла упакованы в структуру Blockchain, которую можно дополнить поведением для создания BlockchainMut, способной обрабатывать транзакции и генерировать блоки.

Поведение узла заключено в модуле runtime ящика. Основные типы там:

— Признак Runtime, определяющий интерфейс между ядром и сервисами в определённой среде (например, Rust или JVM). — Dispatcher, передающий вызовы от ядра к включённым Runtimes.

Интерфейс между Dispatcher и BlockchainMut относительно невелик (по сути, две основные операции: создание и фиксация блоков), но он сопоставляется с более богатым жизненным циклом сервисов, определённым внутри Dispatcher. Особо следует отметить структуру миграции данных (migrations submodule), позволяющую выполнять MigrationScript в фоновом режиме и обеспечивать, чтобы результаты миграции были одинаковыми среди всех узлов сети.

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

Узел

Логика узла находится в ящике [exonum-node]. Она определяет алгоритм консенсуса, одноранговую сеть между узлами и предоставляет узлам HTTP-серверы. (Основа для HTTP API находится в отдельном ящике, [exonum-api]).