Технические детали транзита. Архитектура

Добрый день!

Восьмого августа 2018 г. во время общения в режиме Discord от команды Golos•Core было озвучено предложение по осуществлению транзита блокчейна Golos на кодовую базу форка блокчейна EOS. Настоящая статья содержит описание технической реализации этого транзита.

На рисунке 1 схематично показано взаимодействие узла (далее — нода) блокчейна Golos с другими нодами и клиентами этого блокчейна.

Рисунок 1 - Схема взаимодействия ноды блокчейна Golos

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

1. Взаимодействие нод осуществляется по специальному протоколу, представляющим собой двусторонний обмен подписанными блоками, а также отложенными транзакциями, еще не включенных в подписанные блоки.
2. Взаимодействие клиентов с нодой Golos осуществляется с помощью посылок двух типов сообщений, в том числе:
   • Отправление подписанных транзакций с целью изменить состояние блокчейна. Такое взаимодействие является односторонним, так как клиент получает ответ либо в виде подтверждения об успешном принятии транзакции, либо в виде сообщения об ошибке в передаче данных.
   • Обработка запросов пользователей по жестко заданному алгоритму с использованием API-плагинов, содержащих большой по объему код прослойки. Возможности клиентов ограничены тем набором функций, что предоставляются нодой Golos.

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

1. evaluators - множество обработчиков операций из подписанных транзакций, которые необходимо выполнить в текущем состоянии блокчейна. Например, после публикации пользователем нового поста будут выполняться следующие действия:
   • Подписанная транзакция, содержащая операцию comment_operation, будет передана от клиента к ноде. На первом этапе будет выполнена проверка соответствия публичных частей ключей из сигнатур транзакции, тем операциям, что включены в транзакцию.
   • Операция будет передана подсистеме database, где будет выбран нужный обработчик из подсистемы evaluators. Далее обработчик в тестовом режиме выполнит операцию.
   • В случае отсутствия ошибок на этапах проверки транзакции, подписанная транзакция будет включена в список отложенных транзакций, а также затем в следующий подписанный блок. Для этого она будет передана всем остальным нодам блокчейна.
2. blocklog - файл, содержащий всю цепочку подписанных блоков. Сохранение блока в файл blocklog происходит после принятия этого блока как неоткатываемого. В файле blocklog.index хранятся позиции подписанных блоков для быстрого доступа к ним в следующих случаях:
   • блок запрашивается другой нодой для процедуры синхронизации;
   • блок запрашивается клиентом цепочки через методы плагина databaseapi
3. chainbase - используется для текущего состояния системы, в состав которой входит множеством таблиц и индексов, которые сохраняются в файле разделяемой памяти sharedmemory.bin. Данные внутри файла хранятся в бинарном формате и представляют собой снимок оперативной памяти. Во время перехода с одной версии ноды на другую, а также во время некорректного завершения процесса формат данных не будет соответствовать формату, который понимает нода. В этом случае требуется выполнить процедуру “replay” - повторно выполнить все операций, которые были совершены за все время жизни цепочки.

Транзит блокчейна Golos на кодовую базу форка блокчейна EOS предусматривает миграцию следующих компонентов:

1. Данных состояния системы chainbase - файл sharedmemory.bin
2. Части функциональности из подсистемы evaluators - обработчиков тех операций, которые необходимы для публикации постов, голосования за посты, а также для выплаты за опубликованные посты.

Решение по остальным частям системы:

1. Большая часть функциональности будет унаследована от блокчейна EOS, в том числе:
   • Сетевая подсистема;
   • Алгоритм согласования данных Byzantine Fault Tolerance (BFT);
   • Машина смарт-контрактов WebAssembler;
   • Операции, связанные с трансфером активов, а также другие операции, ранее реализованные в виде смарт-контрактов в блокчейне EOS.
2. Большую по объему часть кода API подсистему предусматривается упростить и реализовать в виде внешней БД, предоставляющей широкие возможности для доступа к данным.

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

Рисунок 2 - Схема транзита блокчейна Golos в форк блокчейна EOS

С целью упрощения процедуры транзита блокчейна Golos в форк блокчейна EOS предлагается использовать базу данных (БД) состояния системы (State) в качестве генезиса новой системы. Это позволит избежать транзит всех подписанных блоков, реализация пересылки которых потребует больших трудозатрат.
В БД состояния системы будет хранится вся актуальная информацию о сообществе Golos, в том числе:

1. Все пользователи системы;
2. Все балансы текущих пользователей;.
3. Все посты и голосования за посты пользователей;.
4. Иная информация, которая на момент транзита появится в системе.

Схема на рисунке 2 показывает, что транзит будет осуществляться через общую для обоих блокчейнов БД состояния системы. Алгоритм процедуры транзита будет состоять из следующей последовательности действий:

1. Действия на ноде блокчейна Golos:
   • Прием транзакций из сети Golos;
   • Сохранение подписанных блоков в blocklog блокчейна Golos;
   • Сохранение изменений БД состояния системы в общую БД состояния системы блокчейна State;
   • Контроль идентичности БД состояния системы в момент перехода блокчейна Golos в блокчейн на базе форка блокчейна EOS. Контроль будет выполняться специальной подсистемой hash методом подсчета хеш-суммы БД состояния системы.
2. Действия на ноде форка блокчейна EOS:
   • Прием транзакций из сети форка EOS;
   • Блокировка всех операций с БД состояния системы до момента транзита (исключение составляет единственная ожидаемая нодой операция - подтверждение перехода);
   • Отправление в новый блокчейн операции подтверждения перехода производителями блоков форка блокчейна EOS в момент готовности процедуры транзита;
   • Ожидание наступления момента транзита - момента, когда количество производителей блоков, готовых осуществить переход будет равным X.
3. Действия на нодах форка EOS: подтверждение и фиксация в блокчейне хеш-суммы генезиса новой системы.
4. Действия на ноде блокчейна Golos:
   • сохранение в БД состояния системы информации блокирующей работу;
   • прекращение приема новых блоков из сети после получения информации о необходимости останова.
5. Действие ноды блокчейна форка EOS: снятие блокировки на выполнение операций с БД состояния системы.
6. Начало жизненного цикла нового блокчейна.

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

Критерии выбора алгоритма подсчета хеш-суммы БД состояния системы:

1. Поскольку одномоментно посчитать хеш-сумму по всему объему данных сообщества Golos не представляется возможным, то необходимо просчитывать хеш-сумму по мере обновления данных через подписанные блоки блокчейна Golos.
2. Хеш-сумма должна быть такова, чтобы ее можно было проверить по результирующему набору данных, без полной информации о всех изменениях, произошедших в БД состояния системы.

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

Рисунок 3 - Схема подсчета результирующей хеш-суммы

Алгоритм подсчета хеш-суммы содержит следующую последовательность действий:

1. Дробление исходных данных на несколько групп по определенному количеству записей.
2. Подсчет хеш-суммы для каждой из групп - hash уровня 1.
3. Разбиение множества хеш сумм первого уровня на группы по определенному количеству записей.
4. Подсчет хеш-суммы для каждой из групп - hash уровня 2.
5. Подсчет хеш-суммы выполнять до тех пор, пока результирующая сумма не будет сведена к одной хеш-сумме последнего уровня.

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

1. Повторно пересчитать хеш-сумму первого уровня для той группы, данные в которой были изменены.
2. Используя готовые хеш-суммы последующих уровней, получить результирующую хеш-сумму по всем данным.

Для осуществления транзита необходимо обеспечить существование общей БД состояния системы. Для реализации данного шага планируется осуществить экспорт данных состояния системы во внешнюю БД. У этого шага есть ряд преимуществ.

1. Данные из БД можно извлекать, используя возможности современных СУБД. Благодаря этой возможности отпадает необходимость реализовывать API слой внутри ноды блокчейна (рисунок 1 показывает, что это достаточно большой слой логики в коде ноды).
2. Структуру данных в БД можно расширять через добавление новых атрибутов.
3. Делать безболезненные снапшоты БД состояния системы, используя инструментарий СУБД.

Как было озвучено на встрече в режиме Discord данные планируется разбить на две категории:

1. Категория данных, необходимых для фиксирования консенсуса в системе, в том числе:
   • Существование аккаунтов в системе;
   • Текущий баланс пользователя в системе;
   • Текущие ограничения пользователя в системе;
   • Уникальность поста;
   • Другая информация.
2. Категория больших по объему данных, полное содержимое которых не влияет на консенсус, в том числе:
   • Тело постов и комментариев;
   • Профиль пользователя;
   • Другая информация.

Исходя из категоризации данных на встрече в режиме Discord было озвучено предложение о создании дополнительного хранилища данных (Storage), целостность которого не блокирует работу блокчейна, в котором можно сохранять большие по объему данные. При этом в основной БД состояния системы сохраняются хеш-суммы данных для хранилища.
В блокчейне появляются дополнительные возможности по оптимизации работы с хранилищем, в том числе:

1. Передача данных сериями в хранилище по last irreversible блокам. Это позволяет сократить время на процедурах откатов изменений при форках.
2. Блокчейну нет необходимости блокировать обработку подписанных блоков из за отсутствия данных в хранилище, так как у самой ноды нет необходимости запрашивать данные из хранилища.
3. Блокчейн обеспечивает транспортировку данных от одной ноды блокчейна к другой.

В действительности, простым хранилищем у блокчейна может быть “труба”, в которую блокчейн передает сериями сформированные объекты. Задача клиента - присоединится к “трубе” и обработать данные, передаваемые по этой “трубе”. Другими типами хранилища могут являться как БД, так и файловая система. Такое хранилище может быть шардировано (например, устанавливается нода и настраивается хранилище на шард определенного среза данных. Блокчейн гарантирует транспортировку и в хранилище будут загружаться уже согласованные нодами данные).

В хранилище такого типа данные разделяются на два типа:

1. Горячие данные, представляющие собой консенсус системы и которые необходимы для работы ноды блокчейна;
2. Холодные данные, представляющие собой дополнительные данные, которые блокчейн доставляет нодам, но которые могут не выделяться на ноде в отдельное хранилище.

На рисунке 4 приведена схема хранения горячих данных в варианте с внешней БД.

Рисунок 4 - Схема хранения горячих данных во внешней БД

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

На рисунке 5 приведена схема хранения горячих данных в варианте с RocksDB.
Данная схема предусматривает оптимизацию доступа к данным за счет использования узкоспециализированных решений для хранения консенсуса - RocksDB.

Рисунок 5 - Схема хранения горячих данных в RocksDB

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

Эффективность каждого из вариантов может быть определена непосредственно во время реализации прототипа.

В ходе реализации прототипа системы команда Golos•Core планирует выполнить:

1. Реализовать хранение стейта блокчейна Golos в БД.
2. Реализовать хранилище для больших по объему данных (постов и комментариев).
3. Подобрать параметры генерации и хранения подписанных блоков в форке блокчейна EOS.
4. Получить информацию о минимальных требованиях к ноде нового поколения.

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

1. Подсчет хеш-суммы БД состояния системы.
2. Алгоритм транзита цепочки.

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

Автор статьи - @andreypf,
team leader команды разработки Golos•Core

Каналы коммуникации с Golos•Core

• https://t.me/goloscoretc (решение технических вопросов, связанных с работой блокчейн, нод, api и др.)
• https://t.me/joinchat/BLwf_A118xQ57nsM1Q4MPA (канал для вноса предложений от комьюнити, обсуждение перехода на кодовую базу EOS)
• https://t.me/golos_tools (решение вопросов по различным интерфейсам и дополнительным инструментам, создаваемым Golos•Core)
• https://t.me/goloscore_analytics (решение вопросов по работе экономики блокчейн, статистическим экономическим данным, аналитике данных)
• https://t.me/goloscoretech (новостной канал, с актуальной информацией от Golos•Core)
• Мы будем очень рады, если вы поддержите делегата @goloscore. Заходите на страничку https://golos.io/~witnesses и проголосуйте за делегата Golos•Core

Спасибо за внимание и хорошего дня!

С уважением,

Команда Golos•Core @korpusenko, @andreypf, @maslenitsa, @muhazokotuha, @zxcat, @mariadia, @annaeq, @anazarov79, @kaynarov, @s-medvedev