Разбор технических ньюансов перехода на EOS

У многих пользователей возникают вопросы по разнообразию направлений в связи с предложением команды Golos•Core. осуществить переход на кодовую базу EOS. Данный пост не является попыткой дать ответы на все вопросы, он выполняет функцию одной из вводных частей. Количество частей на данный момент предсказать достаточно сложно, так как количество вопросов может увеличиваться по мере освещения всех деталей переезда на новую платформу.

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

Исследование перехода на EOS

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

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

В целях исследования мы разделили текущую архитектуру Голос на следующие подсистемы и проанализировали пересечения с платформой EOS :

• Встроенная база данных в разделяемой памяти
• Сетевая подсистема
• Подсистема проверки транзакций с иерархической системой авторизации
• Подсистема бендвича
• Весомая надстройка над БД с рутинами и индексами консенсуса
• Набор операций и обработчиков операций
• Набор плагинов для дополнительной обработки информации, поступающей в блокчейн
• Прослойка API для выдачи информации из стейта блокчейна и из базы подписанных блоков

Существующие операции и их обработчики мы разделили на следующие подгруппы:

• Аккаунты (профиль, ключи, восстановление, authority)
• Посты и комментарии (создание, редактирование, удаление, бенефициарство)
• Голосование за посты
• Market (трансферы, конвертации с учетом ограничений, накладываемых на переводы между 3 видами активов: GBG, делегирование и т.д.)
• Делегаты (голосование, изменение параметров, майнинг)
• Пропозал транзакции
• Кастом операции для плагинов

В коде EOS мы выделили следующие подсистемы для анализа:

• БД в разделяемой памяти, аналогичная Голос
• Сетевая подсистема
• Подсистема проверки транзакций с иерархической системой авторизации
• Подсистема учета бендвича
• Производители блоков
• Виртуальная машина WebAssembler для смарт-контрактов
• Слой бизнес-логики, связывающий аккаунты, бендвич и смарт-контракты на виртуальной машине
• Библиотека смарт-контрактов

В ходе проведенного анализа мы пришли к выводу о том, какие системы могут быть унаследованы новым блокчейном Голоса (Голос на кодовой базе EOS), о чем написали в предыдущем посте.

Для целостного восприятия считаем необходимым проговорить их заново. При переходе на новую платформу Голос могут быть унаследованы следующие подсистемы от EOS:

• Встроенная база данных (пояснение ниже)
• Сетевая подсистема
• Адаптация системы аккаунтов под требования, необходимые для миграции пользователей Golos
• Подсистема проверки транзакций с иерархической системой авторизации и с необходимыми изменениями для платформы Голос
• Подсистема учета бендвича
• Производители блоков с рядом изменений, часть из которых была озвучена в посте Николая Штефана
• Подсистема market в смарт-контрактах
• Пропозал транзакции в смарт-контрактах

Концентрат текущей экономики Голос может быть реализован в виде смарт-контрактов:

• Профили пользователей
• Создание/редактирование/удаление постов/комментариев, голосование за посты.
• Правила конвертации токена в вестинг, эмиссия токена

В блокчейн Голоса на базе EOS через смарт-контракты могут быть добавлены:

• Институт модераторов приложений, определяющих законы эмиссии токенов приложений и ее распределения, правила подключения новых пользователей к общему бендвичу приложений
• Институт воркеров приложений, развивающих кодовую базу приложений

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

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

По нашим оценкам, команда Golos•Core из 7 С++ программистов может реализовать предложенный план переезда на кодовую базу EOS в течение 6 месяцев.

Техническое несовершенство Голоса

Этот пост также ориентирован на то, чтобы дать ответы на часть технических вопросов, которые прозвучали после публикации первого поста. Как и было заявлено ранее, задача перехода - создать для Голоса новое конкурентное преимущество.

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

Обременительное наследование
Во-первых, текущий код Голоса перегружен условными операторами, необходимыми для поддержания перехода экономики из одного состояния в другое. Все хардфорки, которые происходили в Голосе и были унаследованы от Стима, оставили свои следы в коде. Эти условные операторы усложняют добавление новой функциональности. Их можно переработать (отрефакторить, так это называется в мире IT), и это чисто техническое улучшение, но оно потребует большого количества ресурсов, а также не даст новые функциональные возможности.

Вариантов переработки кода с избавлением от перегруженности кода множество. У каждого есть свои плюсы и минусы.

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

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

Это уже существенно уменьшает объем кода, который будет необходимо перенести.

Неэффективная база данных
Во-вторых, демон Голоса в текущий момент выполняет массу задач: от синхронизации данных по сети до выдачи информации по запросам от клиентов блокчейна. Для каждого слоя используется свой набор технологий. Проблема, на которой нам хотелось бы заострить внимание - это подсистема хранения данных, позволяющая хранить стейт системы (по факту база данных внутри демона). Реализация построенная на boost::multi_index очень сильно упрощает бизнес-логику внутри приложения. Но база данных - это не только удобство в реализации бизнес-логики. Чтобы база данных эффективно выполняла свои функции, необходимо реализация массы других подсистем.

В данный момент эти подсистемы отсутствуют в демоне. При достаточном количестве оперативной памяти демон имеет прямой доступ к данным без каких-либо посредников.
Но не стоит забывать о деталях. Чтобы демон обладал возможностью выдавать информацию, а не только ее модифицировать, в коде существует один-единственный mutex, разрешающий множество запросов на чтение и полностью блокирующий доступ к данным, когда необходимо эти данные изменить. Это приводит к тому, что выполняющиеся запросы на чтение блокируют выполнение транзакций из вновь прибывшего по сети блока. При поступлении в блокчейн новых транзакций на изменение данных происходит полная блокировка запросов на чтение. У того множества баз данных, что существуют в мире IT, есть масса стратегий по блокировке как отдельных таблиц, так и точечной блокировке отдельных записей. В демоне Голоса реализована лишь одна стратегия - глобальной блокировки доступа ко всем данным.

Если посмотреть на историю коммитов то можно обнаружить, что команда Golos•Core перерабатывала систему блокировок, вводила новые механики, позволяющие хоть как-то улучшить существующую ситуацию. Результатом стала не только отзывчивость демона, но и целостность данных. Для сравнения, в коде Стима, да и ЕОС, до сих пор существуют баги, приводящие к повреждению данных при определенных условиях. Возможно, некоторые из вас помнят ошибку, когда при старте демона, наталкивались на заблокированное состояние. Или то, что чтобы решить эту проблему, требовалось удалять файл shared_memory.meta (которого сейчас кстати и нет совсем).

Работа демона напрямую связана с отзывчивостью системы в целом. Чтобы решить проблему отзывчивости, существующие клиенты Голоса экспортируют данные во внешние базы данных и используют их возможности для выдачи ответов на запросы. И это еще не все. Все уже привыкли к необходимости запускать реплей цепочки при выходе новой версии демона, хотя изменилась лишь пара полей в неконсенсусной составляющей данных.

Все это заставляет задуматься, чем обоснована необходимость хранить стейт системы в том формате, который используется сейчас?

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

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

Для реализации слоя API в демоне есть множество плагинов, каждый со своей бизнес-логикой, которая никак не участвует в консенсусе. Любой новый клиент для блокчейна вынужден подстраиваться под текущий API. Это нонсенс в современном мире IT. Как результат блокчейн уже давно является блокчейном одного приложения.

А команда Golos•Core проводит много времени за переработкой и фиксами багов в API и плагинах, что, по большому счету, делается для поддержания функциональности одного клиента. И для реализации какой-то новой функциональности клиент - Голос Ио - вынужден ждать выпуска нового софтфорка.

Возникает желание расширить возможности демона и добавить ему гибкости в обработке запросов, внедрив GraphQL или другой механизм для обработки входящих запросов и формирования ответов на них. Насколько это резонно? Это сделает блокчейн самой что ни на есть базой данных, хоть он все еще и будет немного далек от нее.

Можно продолжить список, но описанного уже достаточно, чтобы осознать, что Голос с технической точки зрения пытается быть распределенной базой данных, с очень толстым и при этом очень жестким слоем API. Избавление от API с его набором функций позволяет существенно уменьшить объем переносимого кода но новую платформу.

Совершенствуя несовершенство

Чем подкупает EOS? Если заглянуть туда, то можно обнаружить ту же самую систему хранения данных, что в Голосе и Стиме. Но при этом есть существенное отличие, которое называется EOS RAM. Стоимость хранения данных в EOS такова, что переезд Голоса в нее становится крайне дорогостоящей процедурой. Для того, чтобы интегрировать возможности доступа к данным из смарт-контрактов в коде EOS существует одна большая хеш-таблица, ключами в которой являются имя пользователя, имя смарт-контракта, имя таблицы, id ключа в таблице. А в качестве значения используется сериализованная строка таблицы смарт-контракта. Именно это позволяет вести учет потребляемой пользователем RAM.

Внешняя база данных
Соответственно, решение которое мы выдвигаем - экспорт данных во внешнюю БД для превращения нового блокчейна в контроллер поверх БД.

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

1. Создать интерфейс доступа из библиотеки boost::multi_index к внешнему источнику данных
2. Создать слой кеширования данных в оперативной памяти демона
3. Написать драйвер для доступа к MongoDB.

Блокчейн будет хранить свой стейт во внешней БД, а не во внутреннем формате данных. EOS RAM в нашем блокчейне перестанет существовать в своем классическом понимании, а превратиться в слой кеширования данных, бендвич доступа к которому будет осуществляться по тем же правилам, по которым сейчас в EOS происходит учет бендвича для сетевой подсиcтемы и подсистемы CPU.

Разделение архитектуры хранения данных на несколько слоев предоставляет возможность в будущем добавить драйвера для других типов баз данных, которые могут лучше подходить для разного типа нод. Например, использование в качестве БД RocksDB или LevelDB может позволить держать ноду без внешних зависимостей с меньшими требованиями на ресурсы системы. Такой тип хранилища может лучше подойти для seed или делегатских нод.

У данного подхода есть ряд преимуществ:

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

Технические сложности
Как уже упоминалось ранее, не все вопросы технического характера разобраны. Есть ряд возможных технических барьеров, которые необходимо исследовать.

Одна из возможных проблем - это увеличенное время доступа к данным, поскольку это внешнее хранилище. Этот пункт достаточно важен, поскольку нода блокчейна должна успевать обрабатывать блоки. И на это накладывается то, что время между блоками в классическом EOS составляет всего полсекунды. Ситуацию немного спасает то, что нода при хранении данных во внешней БД перестает обрабатывать запросы на выдачу информации, и ей необходимо осуществлять лишь несколько точечных запросов на изменение при обработке транзакции. Даже если этого будет недостаточно в форке EOS можно увеличить время на обработку каждого блока.

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

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

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

Ниже представлен имеющийся у нас план создания и тестирования возможности переноса данных во внешнюю БД.

• 1 этап реализации.
  • Реализация интерфейса на уровне boost::multi_index для доступа к внешнему хранилищу данных.
  • Реализация интерфейсов интеграции объектов сессий chainbase в транзакции внешних хранилищ данных
  • Реализация драйвера для хранения данных в MongoDB
• 1 этап тестирования
  • Снятие замеров времени необходимых для полного реплея цепочки с одинаковым набором плагинов на одинаковом оборудовании с внутренним и внешним хранилищем данных.
  • Написание нагрузочных тестов с разнородным набором транзакций в блоках.
  • Снятие замеров времени необходимых для выполнения разных типов транзакций.
• 2 этап реализации
  • Добавление механизмов верификации данных во внешнем хранилище данных.
• 2 этап тестирования
  • Повторное снятие замеров при включенном механизме верификации данных.
• 3 этап реализации
  • Добавление слоя кеширования данных в оперативной памяти из внешнего хранилища.
• 3 этап тестирования
  • Повторное снятие замеров с включенным режимом кеширования данных и с включенным/выключенным механизмом верификации данных.
• Выпуск в продакшн версии блокчейна Голос с хранением данных в MongoDB.

На реализацию описанного выше планируется отвести 2 месяца. После реализации первого этапа появится возможность разворачивать блокчейн Голос с внешним хранилищем данных, и энтузиасты из сообщества смогут подключатся к тестированию новой технологии.

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

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

• https://t.me/goloscoretc (решение технических вопросов, связанных с работой блокчейн, нод, api и др.)
• 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, @epexa, @muhazokotuha, @timurku, @zxcat, @mariadia, @annaeq, @anazarov79, @rostislav.vel, @kaynarov, @s-medvedev