goloscore

6 лет назад

CyberWay. Событийная модель. Часть 2

Уважаемые пользователи!

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

Мы описывали решения данной задачи в блокчейне Голос, а также приводили причины, побудившие к разработке и создание качественно нового решения в блокчейне CyberWay. Сегодня мы подробно рассмотрим возможности и перспективы решения, используемого в блокчейне CyberWay.

Событийная модель в блокчейне CyberWay

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

Поступающие в блокчейн CyberWay транзакции обрабатываются смарт-контрактами. Результат обработки всех операций, в том числе, неявно заданных, регистрируется как событие и отправляется в плагин обработчика событий (англ. event engine, далее — ЕЕ). На каждое полученное от смарт-контракта событие плагин ЕЕ формирует соответствующее этому событию сообщение. Существует четыре вида сообщений, формируемых плагином ЕЕ, внутри которых находится информация о действиях, выполненных явным или неявным образом.

Сохранение информации о всех событиях непосредственно в блокчейне является трудно реализуемой задачей из-за требуемых для этого значительных ресурсов. Поэтому для хранения информации о событиях используется сервисный компонент — брокер сообщений NATS. В качестве посредника в передаче сообщений от плагина ЕЕ в NATS используется утилита Notifier.

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

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

Структурная схема обработки транзакций и получения информации о событиях показана на рисуке.

Структурная схема обработки транзакций в блокчейне CyberWay

Условные обозначения, используемые на структурной схеме

Блокчейн CyberWay:
- События (events) — операции, выполняемые в смарт-контрактах;
- Обработчик событий (ЕЕ) — плагин, регистрирующий события, происходящие в смарт-контрактах;
- БД — внутреннее хранилище блокчейна (БД Состояния).
Утилита Notifier — прослойка, которая обеспечивает получение сообщений в формате ЕЕ и передачу их в брокер сообщений NATS.
Брокер NATS (от англ. NAT Streaming) — брокер сообщений.
Призма — сервисная библиотека.
Приложение (App) — приложение, разрабатываемое пользователем.

На схеме красным цветом выделены компоненты событийной модели.

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

Обработчик событий

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

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

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

Сообщения, формируемые обработчиком событий

На каждое событие, поступающее от смарт-контрактов, ЕЕ формирует одно из четырех сообщений:

AcceptTrx. Сообщение формируется на каждую принятую блокчейном транзакцию и содержит информацию о созданной транзакции;
ApplyTrx. Сообщение формируется после выполнения операции из транзакции и содержит информацию о действиях (actions) и событиях (events), произошедших при выполнении операции;
AcceptBlock. Событие формируется на каждый сформированный блок, содержащий транзакции. Сообщение информирует, что блок принят блок-продюсерами и отправлен в блок-лог. Находящиеся в блок-логе блоки могут быть возвращены обратно в блокчейн на обработку. Эти блоки могут «выпасть» из общей цепочки и создать свою историю. После того, как эта часть блоков снова появится в блок-логе, их история уже не будет валидной и будет изменена. На каждый возвращаемый в блокчейн блок также появляется событие AcceptBlock;
CommitBlock. Сообщение информирует, что блок принят большинством блок-продюсеров, составляющим не менее «2/3+1» от общего их количества. Блок отправлен в блок-лог и является невозвратным (англ. last irreversible block). Его история не может быть изменена. На каждый такой созданный блок появляется сообщение CommitBlock.

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

Поля структуры содержат действия, которые переданы в ЕЕ. Отправляемые события из поля events, должны быть описаны в ABI-файле определенного смарт-контракта. В описаниях events указывается набор аргументов.

Пример с типом сообщения AcceptTrx

{
    "msg_type": "AcceptTrx",
    "id": "ce41f90 … a8a62",  // идентификатор транзакции
    "accepted": true,         // транзакция принята в блокчейн
    "implicit": false,        // «true» — неявная (скрытая) транзакция
    "scheduled": false        // «true» — отложенная транзакция
}

Сообщение информирует, что блокчейн принял на обработку транзакцию с указанным идентификационным номером. Наличие «false» в полях «implicit» и «scheduled» указывает, что принятая транзакция является явно заданной и не относится к отложенным.

Пример с типом сообщения ApplyTrx

{
    "msg_type": "ApplyTrx",
    "id": "56c93f … 3c285",                   // идентификатор транзакции
    "block_num": 8,                           // номер блока в цепочке блоков
    "block_time": "2019-04-25T10:01:48.000",  // время создания блока
    "actions": [                              // произошедшие действия
        {
            "receiver": "cyber.token",
            "code": "cyber.token",
            "action": "transfer",             // действие: трансферная операция
            "data": "",
            "args": {                         // аргументы действия
                "from": "cyber",              // отправитель средств
                "to": "cyber.stake",          // получатель средств
                "quantity": {
                    "amount": 50000000000000, // перечисляемая сумма
                    "decs": 4,
                    "sym": "SYS"
                },
                "memo": ""
            },
            "events": [                      // произошедшие события
                {
                    "code": "cyber.token",   // код события 
                    "event": "balance",      // событие: изменение баланса аккаунта "cyber"
                    "data": "",
                    "args": {
                        "account": "cyber",  // имя аккаунта отправителя средств
                        "balance": {
                            "amount": 10000192666580,  // остаток на балансе отправителя
                            "decs": 4,
                            "sym": "SYS"
                        }
                    }
                },
                {
                    "code": "cyber.token",
                    "event": "balance",      // событие: изменение баланса аккаунта "cyber.stake"
                    "data": "",
                    "args": {
                        "account": "cyber.stake",     // аккаунт получателя
                        "balance": {
                            "amount": 50000000000000, // сумма на балансе получателя
                            "decs": 4,
                            "sym": "SYS"
                        }
                    }
                }
            ]
        }
    ]
}

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

Пример с типом сообщения AcceptBlock

{
    "msg_type": "AcceptBlock",
    "id": "00000005 … 78e7c",          // идентификатор блока
    "block_num": 5,                    // номер блока в цепочке блоков
    "block_time": "2019-04-30T16:01:12.000",
    "validated": true,
    "in_current_chain": true,
    "trxs": [                          // перечень транзакций, содержащихся в блоке
        {
            "id": "db85... 19af9e5",   // идентификатор транзакции
            "status": "executed",      // транзакция выполнена
            "cpu_usage_us": 12322,     // ресурс CPU, затраченный на выполнение транзакции
            "net_usage_words": 25      // ресурс NET, затраченный на выполнение транзакции
        },
        ....
        {
            "id": "cb6cf8b9a5da039dceb913d9713f3d56b6a9da403d2c44135fc55349c0176df9",
            "status": "executed",
            "cpu_usage_us": 54623,    
            "net_usage_words": 2664
        },
        {
            "id": "384afa3778456b8b61ba43622f79b33b4b53fab020e2849aa36255ec7c7cadcc",
            "status": "executed",
            "cpu_usage_us": 45484,
            "net_usage_words": 1099
        },
        {
            "id": "ce41f9032b12ce3e5dbb4bf40c2d3ccb34f0a167f21d65391182f997aa3a8a62",
            "status": "executed",
            "cpu_usage_us": 479120,
            "net_usage_words": 16
        }
    ],
}

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

Пример с типом сообщения CommitBlock

{
    "msg_type": "CommitBlock",
    "id": "000000034044... ac178e7c",      // идентификатор блока
    "block_num": 3,
    "block_time": "2019-04-30T16:01:12.000",
    "validated": true,
    "in_current_chain": true
}

Сообщение информирует, что сформированный блок принят блок-продюсерами и помещен в цепочку блоков под номером 3.

Утилита Notifier

Все аргументы в событиях представляются в бинарном виде. Для того, чтобы плагин ЕЕ мог десериализовать такие аргументы и придать событию структурированный вид, в смарт-контрактах содержится ABI-описание каждого передаваемого события.

Используя ABI-описание события, плагин ЕЕ преобразует бинарный вид получаемого события в форму структуры.

В зависимости от настроек, формируемые плагином ЕЕ сообщения о событиях записываются либо в файловый дескриптор, либо передаются в конвейер (англ. pipeline).

Для передачи сообщений о событиях в брокер сообщений NATS создана утилита Notifier. Notifier открывает линию pipeline, получает событие и отправляет его в NATS. Затем запускается узел (нода), которая передает в линию всю информацию о событии.

Брокер сообщений

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

Задача воспроизведения ранее произошедших событий не входит в рамки функций EE. Для поддержки данной функциональности в событийную модель подключен отдельный сервис — брокер сообщения NATS. Этот сервис имеет настройки и обеспечивает сохранение полученной информации о событиях на жесткий диск с возможностью доступа к этой информации.

Взаимодействие утилиты Notifier с брокером сообщений NATS реализуется с помощью настроек NATS. Пользователю предоставляется возможность при необходимости подключать другие виды брокеров сообщения. Подключение брокера сообщений легко реализуемо.

Библиотека Призма

Библиотека Призма является продуктом разработки команды ГолосИО. Библиотека предоставляет пользователю информацию о событиях, произошедших в блокчейне, в удобной для пользователя форме. Пользователь может также разработать собственное приложение App (на рис. 2 выделено зеленым цветом) для получения информации о событиях. Приложение App будет легко реализуемо и совместимо с остальными компонентами системы.

Подробная информация по реализации библиотеки Призма будет предоставлена позже.

Достоинства решения

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

Пример 1

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

перечисление с баланса пользователя определенной суммы на баланс смарт-контракта вестинг;
информирование пользователя смарт-контрактом вестинг об изменении его (пользователя) баланса.

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

Решение позволяет исключить обращения событийной модели в БД Состояния (например, за получением данных о балансах пользователей).

Пример 2

Выполнение операции по переводу части средств с баланса одного пользователя на баланс другого приводит к изменению данных сразу двух балансов. Смарт-контракт cyber.token дополняет действие transfer событиями event со значениями измененных балансов. В сформированном результирующем событии будет находиться вся актуальная информация о выполненной трансферной операции.

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

Полное описание Событийной модели вы можете найти на github.com.

Cерия статей, раскрывающих идею и принципы функционирования блокчейна CyberWay и приложения Голос:

Каналы коммуникации с 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: @andreypf, @korpusenko, @maslenitsa, @muhazokotuha, @zxcat, @annaeq, @anazarov79, @kaynarov, @s-medvedev, @eugin, @dedbaraded, @jimak.