Основы распределённого реестра

Распределённый реестр — детерминированный асинхронный конечный автомат, состояние которого реплицируется на N компьютеров (узлов), и действует как единый конечный автомат. Одно и то же «Состояние + Ввод» всегда создаёт одно и то же следующее «Состояние + Вывод».

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

Узлы следует бесконечному циклу каждые 3–6 секунд.

Конечный автомат формирует новый реестр каждые 3–6 секунд, создавая непрерывную цепочку связанных между собой реестров. Распределённый реестр поддерживает содержимое последнего реестра и цепочки реестров в нескольких представлениях данных. Текущий реестр хранится в локальной базе данных SQL для обеспечения ACID-безопасности, данные которого сопряжены с каждым процессом программы Распределённого реестра. Консенсус касается только настоящего, обращение к базе данных и обновление выполняется в режиме реального времени. Для применения согласованного набора транзакций используются только текущие данные и хеш-значение предыдущего реестра.

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

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

Транзакция — SQL-команда изменения состояния реестра, которая может содержать одну или несколько инструкций.

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

Распределённый реестр работает с данными в 4 местах и хранит реестры в XDR и SQL — одновременно.

Обращение к базе данных в процессе консенсуса.

Хранение в памяти до достижения консенсуса.

Хранение реестра в канонической форме — плоские XDR-файлы и дублирование данных, хранящихся в таблицах SQL.

Хранение контрольных точек и журналов архивов. Один JSON-файл перезаписывается, чтобы указать на текущую контрольную точку.

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

Выполняется, когда у внешнего клиента появляется новая транзакция.

Выполняется непрерывно в оверлейной сети.

Выполняется, когда протокол принимает решение о согласованном Состоянии (состояние консенсуса) + Вводные данные. Цикл: каждые 3–6 секунд.

Выполняется каждые 64 записи реестра.

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

Хранилище состоит из фиксированного числа уровней. Уровни содержат сегменты каждого уровня, кратные размеру сегментов предыдущего уровня. В сегментах хранятся записи в зависимости от их возраста — недавно изменённые записи находятся в меньших сегментах нижнего уровня. Два сегмента могут быть эффективно объединены вместе (за один проход): элементы из более нового сегмента перезаписывают элементы из более старого сегмента, остальные объединяются в отсортированном порядке, и все элементы хешируются при добавлении.

Список сегментов хранит записи реестров на диске для хеширования и дедупликации данных. Модуль списка сегментов координирует хеширование и дедупликацию сегментов несколькими фоновыми потоками. Окончательная дельта, полученная после закрытия реестра, передаётся для добавления в локальное хранилище — L0. Полученный набор записей используется для вычисления хеша всего набора записей реестра.

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

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

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

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

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

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

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

На уровне Распределённого реестра используется алгоритм EdDSA в качестве механизма цифровой подписи и протокол ECDH для применения сеансовых экземпляров curve25519-ключей между узлами.

Учётная запись в Распределённом реестре состоит из секретного и публичного ключа. Для создания Учётной записи и подписи транзакций используется криптография с открытым ключом, с помощью которой создаются экземпляры Ed25519-ключей. Только подписанные транзакции могут быть включены в реестр.

В качестве ключей аутентификации между узлами используются Curve25519-ключи, которые рандомизируются при запуске и применяются только для «протокола согласования ключей» между узлами. Ключи curve25519 выступают, как временные ключи, которые используются для каждого сеанса и подписываются Ed25519-ключами во время «рукопожатия» Узлов.