A Blockchain Platform for the Enterprise
Добрый день, дорогие читатели, меня зовут Николай Нефедов, я технический специалист компании IBM, в этой статье я хотел бы познакомить вас с блокчейн платформой – Hyperledger Fabric. Платформа предназначена для построения бизнес приложений уровня предприятия (Enterprise class). Уровень статьи – для неподготовленных читателей, имеющих базовые знания IT технологий.
Hyperledger Fabric это open-source проект, одна из ветвей открытого проекта Hyperledger, консорциума Linux Foundation. Hyperledger Fabric был изначально стартован Digital Assets и IBM. Основной особенностью платформы Hyperledger Fabric является направленность на корпоративное применение. Поэтому платформа разрабатывалась с учетом обеспечения высокой скорости проведения транзакций и их низкой стоимости, а также идентификации всех участников. Данные преимущества достигаются за счет разделения службы проверки транзакций и формирования новых блоков распределенного реестра, а также применения центра сертификации и авторизации участников.
Моя cтатья это часть цикла статей о Hyperledger Fabric в рамках которой мы описываем проект системы по учету студентов, поступающих в ВУЗ.
Общая архитектура Hyperledger Fabric
Hyperledger Fabric — это распределенная блокчейн сеть, состоящая из различных функциональных компонентов, которые устанавливаются на узлы сети. Компоненты Hyperledger Fabric представляют из себя Docker контейнеры, которые можно свободно скачать из DockerHub. Hyperledger Fabric также можно запустить в Kubernetes среде.
Для написания смарт-контрактов (chaincode в контексте Hyperledger Fabric) мы использовали Golang (хотя Hyperledger Fabric позволяет использовать и другие языки). Для разработки пользовательского приложения в нашем случае использовался Node.js с соответствующим Hyperledger Fabric SDK.
На узлах выполняется бизнес логика (смарт-контракт) – chaincode, хранится состояние распределенного реестра (ledger data) и исполняются другие системные службы платформы. Узел – это только логическая единица, разные узлы могут существовать на одном физическом сервере. Гораздо важнее – это как узлы сгруппированы (Trusted domain) и с какими функциями блокчейн сети они ассоциированы.
Общая архитектура выглядит следующим образом:
Picture 1. Общая Архитектура Hyperledger Fabric
Пользовательское приложение (Submitting Client) — приложение, с помощью которого пользователи работают с блокчейн сетью. Для работы необходимо пройти авторизацию и обладать соответствующими правами на разного рода действия в сети.
Peers (Узлы) бывают нескольких ролей:
- Endorsing Peer — узел, который симулирует исполнение транзакции (исполняет код смарт-контракта). После выполнения проверки и исполнения смарт-контракта узел возвращает результаты выполнения клиентскому приложению вместе со своей подписью.
- Ordering Service — распределенный сервис на нескольких узлах, служит для формирования новых блоков распределенного реестра и создания очередности исполнения транзакций. Ordering Service не добавляет новые блоки в реестр (Для повышения производительности эта функция перенесена на Committing Peers).
- Committing Peer — узел, который содержит распределенный реестр и добавляет новые блоки к реестру (которые сформировал Ordering Service). Все Committing Peer содержат локальную копию распределенного реестра. Committing Peer перед локальным добвлением нового блока проверяет все транзакции внутри блока на валидность.
Endorsement Policy – это политика проверки транзакции на валидность. Данные политики определяют необходимый набор узлов, на которых должен быть выполнен смарт-контракт для того, чтобы транзакция была признана валидной.
Распределенный Реестр — Lerger — состоит из двух частей: WolrldState (также называется — State DataBase) и BlockChain.
BlockChain — это цепочка блоков, которая хранит записи о всех изменениях, произошедших с объектами распределенного реестра.
WolrldState — это компонент распределенного реестра, который хранит текущие (крайние) значения всех объектов распределенного реестра.
WorldState представляет собой базу данных, в базовом варианте — LevelDB или более сложная – CouchDB, которая содержит пары ключ — значение, например: Имя – Иван, Фамилия — Иванов, дата регистрации в системе – 12.12.21, дата рождения — 17.12.1961, и т.д. WorldState и распределенный реестр должны быть консистентны у всех участников данного канала.
Поскольку Hyperledger Fabric это сеть, в которой все участники известны и аутентифицированы, здесь используется выделенный центр сертификации — CA (Certification Authority). CA работает на основе X.509 стандарта и инфраструктуры публичных ключей – PKI.
Membership Service – это служба, через которую участники осуществляют проверку принадлежности объекта к той или иной организации или каналу.
Транзакция – в большинстве случаев, это запись новых данных в распределенный реестр.
Также транзакции бывают на создание каналов или смарт-контрактов. Транзакция инициируется пользовательским приложением и заканчивается записью в распределенный реестр.
Канал (Channel) – это закрытая подсеть, состоящая из двух или более участников блокчейн сети, предназначенная для проведения конфиденциальных транзакций внутри ограниченного, но известного, круга участников. Канал определяется участниками, своим распределённым реестром, смарт-контрактами, Ordering Service, WorldState. Каждый участник канала должен быть авторизован на доступ к каналу и иметь право выполнять разного рода транзакции. Авторизация выполняется с помощью Membership Service.
Типовой сценарий исполнения транзакции
Далее я хотел бы рассказать о типовом сценарии выполнения транзакции на примере нашего проекта.
В рамках нашего внутреннего проекта мы создали Hyperledger Fabric сеть, которая предназначена для регистрации и учета студентов, поступающих в ВУЗы. Наша сеть состоит из двух организаций, принадлежащим ВУЗу A и ВУЗу B. Каждая организация содержит клиентское приложение, а также свои Committing и Endorsing Peer. Также мы используем общие сервисы Ordering Service, Memebership Service и Certification Authority.
1) Инициация Транзакции
Пользовательское приложение, используя Hyperledger Fabric SDK, инициирует запрос на транзакцию и отправляет запрос на узлы со смарт-контрактами. Запрос может быть на изменение или чтение из распределенного реестра (Ledger). Если рассматривать пример нашей тестовой конфигурации системы для учета студентов ВУЗов, то клиентское приложение посылает запрос на транзакцию на узлы вузов A и B, которые включены в Endorsement policy вызываемого смарт-контракта. Узел A — это узел, который находится в ВУЗе, который регистрирует поступающего студента, а узел B — это узел, который находится в другом ВУЗе. Для того чтобы транзакция была сохранена в распределенный реестр, необходимо, чтобы все узлы, которые согласно бизнес логике должны одобрить транзакцию, успешно выполнили смарт-контракты с одинаковым результатом. Пользовательское приложение узла A, используя инструменты Hyperledger Fabric SDK, получает Endorsement policy (политика одобрения) и узнает, на какие узлы нужно отправить запрос на транзакцию. Это запрос на вызов (invoke) определенного смарт-контракта (chaincode function), чтобы прочитать или записать определённые данные в распределенный реестр. Технически, клиентское SDK использует соответствующую функцию, API которой передается некий объект с параметрами транзакции, а также добавляет клиентскую подпись и отправляет эти данные по протоколу protocol buffer over gRPC на соответствующие узлы (endorsing peers).
Picture 2. Инициация Транзакции
2) Выполнение смарт-контракта
Узлы (Endorsing Peers), получив запрос на проведение транзакции, проверяют клиентскую подпись и если все в порядке, то берут объект с данными запроса и запускают симуляцию исполнения смарт-контракта (chaincode function) с этими данными. Смарт-контракт — это бизнес логика транзакции, определённый набор условий и инструкций (в нашем случае это проверка студента, новый это студент, или он уже зарегистрирован, проверка возраста и т.д.). Для исполнения смарт-контракта также понадобятся данные из WorldState. В результате симуляции смарт-контракта на Endorsing peer получается два набора данных – Read Set и Write Set. Read Set и Write Set — это исходные и новые значения WorldState. (новые – в смысле полученные при симуляции смарт-контракта).
Picture 3. Выполнение смарт-контракта
3) Возврат данных клиентскому приложению
После проведения симуляции смарт-контракта Endorsing Peers возвращают клиентскому приложению исходные данные и результат симуляции, а также RW Set, подписанные своим сертификатом. На данном этапе никаких изменений в распределенном реестре не происходит. Клиентское приложение проверяет подпись Endorsing Peer, а также сравнивает исходные данные транзакции, которые были отправлены, и данные, которые вернулись (то есть проверяет не исказились ли исходные данные над которыми проводилась симуляция транзакции). Если транзакция была только на чтение данных из реестра, то клиентское приложение соответственно получает необходимый Read Set и на этом обычно транзакция успешно завершается без изменения распределенного реестра. В случае транзакции, которая должна изменить данные в реестре, клиентское приложение дополнительно проводит проверку выполнения Endorsing policy. Возможна ситуация, когда клиентское приложение не проверяет результат выполнения Endorsement Policy, но платформа Hyperledger Fabric в данном случае предусматривает проверку политик на узлах (Comitting Peers) на стадии добавления транзакции в реестр.
Picture 4. Возврат данных клиентскому приложению
4) Отправка RW sets на Ordering Peers
Клиентское приложение отправляет транзакцию вместе с сопутствующими данными на Ordering service. Сюда включаются RW Set, подписи Endorsing peers, а также идентификатор канала (Channel ID).
Ordering service – исходя из названия, основная функция этого сервиса — построение поступающих транзакций в правильном порядке. А также формирование нового блока распределенного реестра и гарантированную доставку новых сформированных блоков всем Commiting узлам, таким образом обеспечивая консистентность данных на всех узлах содержащих распределенный реестр (Commiting peers). При этом сам Ordering service никак не меняет реестр. Ordering Service это жизненно важный компонент системы, поэтому он представляет из себя кластер из нескольких узлов. Ordering Service не проверяет транзакцию на валидность, он просто принимает транзакцию с определенным идентификатором канала, выстраивает поступающие транзакции в определенном порядке и формирует из них новые блоки распределенного реестра. Один Ordering Service может обслуживать несколько каналов одновременно. В состав Ordering Service входит Kafka кластер, который и поддерживает правильную (неизменную) очередь транзакций (см. Пункт 7).
Picture 5. Отправка RW sets на Ordering Peers
5) Отправка сформированных блоков на Committing Peer
Сформированные в Ordering Service блоки передаются (broadcast) всем узлам сети. Каждый узел, получив новый блок, проверяет его на соответствие Endorsing Policy, проверяет, что все Endorsing Peers получили одинаковый результат (Write Set) в результате симуляции смарт-контракта, а также проверяет, не изменились ли исходные значения (то есть — Read Set — данные прочитанные смарт-контрактом из WorldState) с момента инициации транзакции. Если все условия выполнены – транзакция помечается валидной, в противном случае, транзакция получает статус не валидной.
Picture 6. Отправка сформированных блоков на Committing Peer
6) Добавления блока в реестр
Каждый узел добавляет транзакцию в свою локальную копию распределенного реестра, при этом, если транзакция валидна, то Write Set применяется к WorldState (текущему состоянию), соответственно, записываются новые значения объектов, которые затрагивались транзакцией. В случае если транзакция получила маркер – не валидной (например, произошло две транзакции с одними и теми же объектами в рамках одного блока, то одна из транзакций получится не валидной, поскольку исходные величины уже изменены другой транзакцией). Эта транзакция также добавляется в распределенный реестр с маркером не валидной, но Write Set этой транзакции не применяется к текущему состоянию WorldState и, соответственно, не изменяет объекты, учавствующие в транзакции. После этого пользовательскому приложению отправляется нотификация, что транзакция на веки вечные добавлена в распределенный реестр, а также статус транзакции, то есть валидна она или нет…
Picture 7. Добавления блока в реестр
ORDERING SERVICE
Ordering Service состоит из Kafka кластера с соответсвующими ZooKeeper нодами и Ordering Service Nodes (OSN), которые стоят между клиентами Ordering service и Kafka Кластером. Kafka кластер — это распределенная, отказоустойчивая платформа управления потоками (сообщениями). Каждый канал (топик) в Kafka — это неизменяемая последовательность записей, которая поддерживает только добавление новой записи (удаление существующей невозможно). Иллюстрация структуры топика приведена ниже. Именно это свойство Kafka и используется для построения блокчейн платформы.
взято с сайта kafka.apache.org
- Picture 8. Ordering Service Topic Structure*
Полезны ссылки
Благодарности
Выражаю огромную благодарность за помощь в подготовке статьи моим коллегам:
Николаю Марину
Игорю Хапову
Дмитрию Горбачеву
Александру Земцову
Екатерине Гусевой
Источник: habr.com