Добрый день, уважаемые завсегдатаи и гости портала!
Мне всегда интересно рассказывать что-то, что я накопал в платформе 1С или около нее, и куда более интересно освещать те темы, которые находятся на границе технологического фронта. Технология BlockChain и мессенджеры как раз где-то тут и обитают.
Причиной данной публикации стал проведенный нами хакатон, посвященный мобильной платформе 1С и технологии BlockChain, которую мы изучали на базе продуктов HyperLedger. Обо всем этом и пойдет речь.
HYPERLEDGER
Итак, что же это такое. Я изначально ошибочно полагал, что вот это и есть некий блокчейн от IBM. Но, как оказалось, HyperLedger - это консорциум, в который помимо IBM входят многие другие ведущие IT-компании. Кстати, среди премьер-участников этого консорциума есть и SAP, а еще Xiaomi, Deloit, Oracle, Сбербанк, PwC ну и Intel (не говоря уже о прочих, не менее известных компаниях). А вот сам блокчейн от HyperLedger - это HyperLedger Fabric, который, кстати, является не единственной реализацией этого самого блокчейна. О его архитектуре и архитектуре нашего решения, использующего Fabric, мы и поговорим далее.
FABRIC
По-сути - это и есть хранилище цепочек связанных блоков. Процесс общения клиентского приложения с блокчейном можно отразить этой вот картинкой:
Итак, немножко погрузимся в детали. Эту картинку я честно скопипастил вот отсюда.
Деталь номер раз: информация в блокчейне делится на участников, транзакции и активы. Т.е. есть отдельные объекты, описывающие все это. Получается некий регистр накопления: участники - это измерение, актив - это ресурс, а транзакция - это проводка. Все как в 1С (или в 1С все, как у нормальных людей :), но Вы можете помещать в блокчейн любые так называемые assets - пары "ключ-значение", которые впоследствии можете использовать в качестве контекста смарт-контракта.
Деталь номер два: как и в любом блокчейне, в Fabric есть ноды. Но они делятся на ноды с различным функционалом. Во-первых, это ноды "orderer", которые сортируют входящие пакеты от "пиров" и формируют очередной блок транзакций. Также они будут вызывать все "пиры", если клиент сам их не обошел и не подтвердил консенсус. "Пиры" - это ноды, которые "коммитят" транзакции, выполняют смарт-контракты и хранят копию книги (под книгой тут понимается как раз цепочка связанных блоков - тот самый blockchain, в нашем случае это Ledger - главная книга или гроссбух). Кстати, помимо самой книги, "пиры" хранят в себе этакий "срез" активов - аналог таблицы остатков регистра. И есть еще MPS-ноды - "Membership Providers Service", выполняющий функции контроля доступа.
Деталь номер три: есть такая штука, как FABRIC CLIENT (мы используем вариант генерации REST-сервиса с помощью инструмента COMPOSER), через который происходит общение с блокчейном. Фактически клиент авторизуется на REST-сервисе и вызывает функцию смарт-контракта, а уже REST-сервис дергает все пиры, в настройках которых указано, что они участвуют в формировании консенсуса. По-сути, на каждом "пире" отрабатывает контракт, и при отсутствии расхождений в результатах данные передаются в "ordered" в виде собранной REST-сервисом транзакции.
Деталь номер четыре: HyperLedger Fabric изначально разрабатывался, как решение для корпоративного сегмента, которое не предполагает публичного использования (в отличие от блокчейна ETH и BC), поэтому владельцы пиров, ордеров и прочих сервисов инфраструктуры HyperLedger'а должны договориться друг с другом и обменяться сертификатами, т.е. невозможно просто так установить у себя ноду и подключиться к сетевой инфраструктуре конкретного блокчейна. Также, т.к. настройки сети хранятся в genesis-блоке, то для расширения ее новыми нодами необходимо произвести достаточно непростые манипуляции: получить genesis-блок, изменить его, получить разницу и задеплоить транзакцию, изменяющую genesis-блок, в книгу, после чего сгенерировать сертификаты и передать их новой ноде. Т.е. без приглашения сюда прийти невозможно.
СМАРТ-КОНТРАКТ
Когда я только погрузился в тему блокчейна, я совершенно не воспринимал идею смарт-контрактов. "Зачем?" - думал я. Но с ходом времени все устаканилось. Может быть помогло участие в проекте seti@home, который посвящен поиску сигналов от братьев по разуму и суть которого сводилась к распределенным вычислениям, т.е. к обработке пакета сигналов с aresibo и других обсерваторий и передаче результатов расчета в центральный узел исследовательского проекта. Суть смарт-контракта в том же самом: получить из блокчейна информацию, обработать ее в соответствии с переданными вызывающей стороной параметрами и сформировать транзакцию, изменяющую тот или иной актив (ресурс нашего регистра).
Смарт-контракт для Fabric можно создать на различных языках. В прошлом году я изучал возможности Etherium - блокчейна от Виталика Бутерина, и Solidity - языка смарт-контрактов для Etherium. Там контракт был просто набором некоторого машинного языка EVM - Etherium Virtual Machine, который выполнялся на нодах и результат выполнения которого создавал ту самую транзакцию, меняющую те самые "активы" (ячейки памяти 256-битного адресного пространства 256-битной карты памяти EVM, т.е. по каждому адресу у нас слово длинной в 256 бит). В Fabric практически все то же самое - контракт может оперировать своими переменными, активами (в "эфире" актив - это баланс кошелька контракта и sender'а, а в Fabric активов может быть произвольное количество - они определяются в конфигурационном файле связанных нод). Но, в отличие от Etherium, контекст экземпляра объекта смарт-контракта должен быть извлечен из блокчейна в коде самого контракта, для чего в нем есть методы объекта "shim" PutState, который сохраняет состояние в цепочке транзакций, и GetState, восстанавливающий состояние из цепочки транзакций.
Т.е. смарт-контракт в Etherium меняет состояние памяти VM и описывает изменения данных объекта контракта, а в HyperLedger Fabric контракт должен сохранить свое состояние самостоятельно, и при вызове функции сначала должен это состояние прочитать.
Т.к. смарт-контракт - это объект, содержащий список данных и методов работы с ними, являющийся по-сути экземпляром класса, то при его выполнении на всех "пирах" должен восстановиться экземпляр класса в том состоянии, которое сформировалось при коммите последней транзакции, им порожденной, т.е. перед обработкой данных необходимо вызвать этот самый GetState. И дальше уже этот восстановленный контекст участвует в вычислениях вызванного метода этого объекта. Если были изменения данных объекта, то они должны быть записаны с помощью SetState, а после достижения консенсуса FABRIC CLIENT'ом при помощи orderer'а эти данные сохраняются в блокчейне.
Да, все не просто, но без погружения в такие детали донести до читателя всю глубину функционала технологии просто невозможно.
ИНФРАСТРУКТУРА
Я решил, что не буду углубляться во всякие там блокчейновские POW и POS, которые используются для криптовалют, ибо в FABRIC нет ни того, ни другого - просто исполняется код смарт-контракта и при одинаковом результате данные сохраняются (если были изменения) и результат, возвращаемый методом контракта, является правильным. Это позволяет ускорить работу с блокчейном и достичь сотни транзакций в секунду для вполне солидной сети "пиров", содержащей сотни узлов.
Мы инфраструктуру подняли на нескольких виртуальных серверах UBUNTU SERVER, используя DOCKER в качестве контейнера для ноды. Там мы развернули несколько "пиров", orderer, MPS и создали REST-сервис с помощью COMPOSER'а. В качестве языка смарт-контракта использовался NODE.js.
МОБИЛЬНАЯ ПЛАТФОРМА, ZERO
Для клиентского приложения мы использовали мобильную платформу 1С, на которой реализовали корпоративный мессенджер ZERO - о нем я писал ранее. В ходе последнего хакатона мы прикрутили к нашему мессенджеру голосовалку, результаты голосования которой мы и храним в HyperLedger Fabric.
ПОДРОБНОСТИ
Мессенджер Zero уже обладал функционалом, позволяющим проводить опросы в чатах и каналах. Поэтому основной задачей было разработать механизм, связывающий этот функционал с REST API блокчейн-платформы (FABRIC CLIENT). Разработка этого механизма велась на серверной стороне мессенджера, а клиентская часть осталась практически без изменений.
Инициация голосования происходит через расширенное сообщение, форма которого открывается по нажатию кнопки «+» слева в строке сообщения. В открывшемся диалоге нужно нажать на «Опрос»:
В результате будет открыта форма ввода сообщения, содержащего опрос:
В поле "Сообщение" вводится текст опроса/голосования, а для прикрепления списка ответов нужно нажать "Добавить". Количество вариантов ответов при этом ограничено лишь Вашей фантазией.
Также у опроса есть "время жизни", в течение которого голосование доступно.
После того, как содержание опроса, пункты ответа и дата, до которой опрос актуален, заполнены, остается нажать кнопку ">".
Отправитель, кстати, тоже может проголосовать:
При этом попытка проголосовать повторно будет пресечена:
Получатели сообщения с опросом видят следующее:
Ну и, понятное дело, тоже могут проголосовать и тоже не могут сделать это дважды:
Результаты голосования сохраняются в серверной базе мессенджера ZERO и в блокчейне HyperLedger Fabric. Для просмотра транзакций книги HyperLedger мы сделали отдельную страницу, разместив ее на HTTP-сервере.
В принципе ниже три скрина с нашей системы отслеживания транзакций HyperLedger Fabric. На первом список транзакций, на втором содержание одной из транзакций, а на третьем - сам пакет данных с ответом REST-сервера.
