Вступление¶
В общих чертах, блокчейн — это неизменяемый реестр транзакций, поддерживаемый распределенной сетью одноранговых узлов. Каждый из этих узлов поддерживает свою копию реестра, применяя транзакции, подтвержденные протоколом консенсуса и сгруппированные в блоки, включающие в себя значение хэш-суммы, связывающее каждый следующий блок с предыдущим.
Первым и самым известным применением блокчейна является криптовалюта Bitcoin, хотя у нее есть много последователей. В Ethereum, альтернативной криптовалюте, использован другой подход, объединяющий многие характеристики Bitcoin с умными контрактами, что позволило создать платформу распределенных приложений. Bitcoin и Ethereum относятся к классу блокчейнов, который являются публичными без контроля доступа. По сути это публичные сети, открытые для всех, и в которых участники взаимодействуют анонимно.
По мере роста популярности Bitcoin, Ethereum и других производных от них технологий рос и интерес к применению самой технологии блокчейн, распределенных реестров и платформ распределенных приложений для более инновационных корпоративных сценариев. Однако эти корпоративные сценарии требуют такие характеристики производительности, которые блокчейны без контроля доступа не в состоянии (на сегодняшний день) обеспечить. Кроме того, во многих случаях идентификация участников является жестким требованием, например, при проведении финансовых транзакций, где необходимо соблюдать правила осведомленности о клиентах (KYC) и противодействия отмыванию средств (AML).
Для корпоративного использования необходимо учитывать следующие требования:
- Участники должны быть идентифицированы/идентифицируемы
- Сети должны быть с контролем доступа
- Высокая скорость проведения транзакций
- Низкая задержка при подтверждении транзакций
- Конфиденциальность транзакций и данных бизнес-транзакций
В отличие от блокчейн-платформ, которые адаптируются для корпоративного использования, Hyperledger Fabric была с самого начала спроектирована для этого. В последующих разделах описывается, чем Hyperledger Fabric (Fabric) отличается от других блокчейн-платформ, и приводится обоснование некоторых архитектурных решений, принятых в ней.
Hyperledger Fabric¶
Hyperledger Fabric — это платформа с технологией распределенного реестра (DLT) корпоративного уровня с открытым исходным кодом и контролем доступа, предназначенная для использования в корпоративной среде и предоставляющая ряд ключевых возможностей, отличающих ее от других популярных блокчейн-платформ и платформ распределенных реестров.
Одним из ключевых отличий является то, что консорциум Hyperledger был основан в рамках Linux Foundation, имеющего долгую и успешную историю развития проектов с открытым исходным кодом и открытым управлением, в которых развиваются крепкие сообщества и процветающие экосистемы. Hyperledger управляется техническим комитетом, а Hyperledger Fabric — командой разработчиков из различных организаций. С момента появления первого кода сообщество разработчиков выросло до более чем 200 человек более чем из 35 организаций.
Fabric имеет модульную и настраиваемую архитектуру, обеспечивающую инновационность, универсальность и оптимизацию для широкого спектра промышленных сценариев в банковской и финансовой отраслях, страховании, здравоохранении, управлении персоналом, цепочках поставок и даже передачи цифровой музыки.
Fabric — это первая платформа распределенного реестра, поддерживающая умные контракты, написанные на языках программирования общего назначения, таких как Java, Go и Node.js, а не на специфичных для этой цели языках (DSL). Это означает, что большинство компаний уже обладают необходимым набором компетенций для разработки умных контрактов и им не требуется проводить дополнительное обучение новому языку программирования.
Fabric является платформой с контролем доступа, то есть, в отличие от публичных сетей без контроля доступа, здесь участники известны друг другу, а не анонимны и абсолютно лишены взаимного доверия. Это означает, что хотя участники и не могут полностью доверять друг другу (они могут быть, например, конкурентами в одной и той же отрасли), сеть может работать в рамках модели управления, построенной на доверии, существующем между участниками, например, юридического соглашения или структуры для разрешения споров.
Одним из важных отличий платформы является поддержка подключаемых протоколов консенсуса, что позволяет более эффективно настраивать платформу под конкретные сценарии и модели доверия. Например, при развертывании в рамках одного предприятия или под управлением доверенного органа полностью византийский консенсус может считаться ненужным и снижающим пропускную способность сети. В подобных ситуациях более чем достаточным может оказаться отказоустойчивый (CFT) консенсус, в то время как в многостороннем децентрализованном случае может потребоваться более традиционный византийский (BFT) протокол консенсуса.
Fabric может использовать протоколы консенсуса, которые не требуют внутренней криптовалюты для стимулирования дорогостоящего майнинга или исполнения умных контрактов. Отсутствие криптовалюты снижает некоторые значительные риски и векторы атак, а отсутствие операций криптографического майнинга означает, что платформа может быть развернута с примерно такими же операционными затратами, как и любая другая распределенная система.
Сочетание этих двух отличительных особенностей делает Fabric одной из лучших по производительности платформ, доступных сегодня, как с точки зрения скорости обработки транзакций, так и с точки зрения скорости их подтверждения, а также обеспечивает конфиденциальность транзакций и умных контрактов (то, что в Fabric называется чейнкодом), которые их реализуют.
Давайте более детально рассмотрим эти отличительные черты.
Модульность¶
Модульная архитектура Hyperledger Fabric была заложена при проектировании платформы. Будь то подключаемый консенсус, подключаемые протоколы управления идентификацией, такие как LDAP или OpenID Connect, протоколы управления ключами или криптографические библиотеки, платформа спроектирована таким образом, что ее можно сконфигурировать для удовлетворения различных требований корпоративных сценариев.
На высоком уровне Fabric состоит из следующих модульных компонентов:
- Подключаемый упорядочивающий сервис обеспечивает консенсус при установлении порядка транзакций и затем рассылает блоки одноранговым узлам.
- Подключаемый провайдер услуг членства отвечает за ассоциацию сущностей в сети с криптографическими идентификаторами.
- Необязательная служба gossip распространяет блоки, полученные из упорядочивающего сервиса, среди одноранговых узлов.
- Умные контракты («чейнкод») запускаются в отдельной контейнерной среде (например, Docker) для обеспечения их изоляции. Они могут быть написаны на обычных языках программирования и не имеют прямого доступа к состоянию реестра.
- Реестр может быть настроен для работы с разными СУБД.
- Подключаемое применение политик одобрения и валидации может быть независимо настроено для каждого приложения.
В индустрии существует справедливое мнение, что не существует «одного блокчейна, который бы управлял всеми». Hyperledger Fabric может быть сконфигурирована различными способами, чтобы удовлетворить разнообразные требования к решениям для различных отраслевых сценариев.
Нужен ли контроль доступа?¶
В блокчейнах без контроля доступа практически любой может стать участником, и каждый участник анонимен. В этом случае не может быть никакого доверия, кроме того, что состояние блокчейна до определенной глубины является неизменным. Для смягчения отсутствие доверия, блокчейн без контроля доступа обычно использует внутреннюю криптовалюту, которая «добывается» (в результате майнинга), или комиссию за проведение транзакций, чтобы обеспечить экономический стимул для компенсации больших затрат ресурсов при участии в византийском консенсусе, основанном на «доказательстве работы» (PoW).
С другой стороны, блокчейны с контролем доступа функционируют среди множества известных, идентифицированных и часто проверенных участников, действующих в рамках модели управления, которая обеспечивает определенную степень доверия. Блокчейн с контролем доступа предоставляет способ обеспечения безопасности взаимодействия группы сущностей, которые имеют общую цель, но не могут полностью доверять друг другу. Полагаясь на идентификаторы участников, блокчейн с контролем доступа может использовать более традиционные отказоустойчивые (CFT) или византийские (BFT) протоколы консенсуса, которые не требуют дорогостоящего майнинга.
Кроме того, при наличии контроля доступа риск того, что участник намеренно внедрит вредоносный код через умный контракт, снижается. Во-первых, участники известны друг другу, а во-вторых, все действия, будь то отправка прикладных транзакций, изменение конфигурации сети или развертывание умного контракта, записываются в блокчейн в соответствии с политикой одобрения, установленной в сети для соответствующего типа транзакций. Виновник, не обладающий анонимностью в сети, будет легко идентифицирован, а инцидент рассмотрен в соответствии с условиями модели управления.
Умные контракты¶
Умный контракт, или то, что Fabric называется «чейнкодом», работает как доверенное распределенное приложение, безопасность и доверие которого обеспечивается блокчейном и лежащим в его основе консенсусом между одноранговыми узлами. В нем содержится бизнес-логика блокчейн-приложений.
Есть три ключевых момента, которые относятся к умным контрактам, особенно когда они развернуты на платформе:
- несколько умных контрактов выполняются в сети параллельно,
- они могут быть развернуты динамически (во многих случаях любым участником), и
- код приложения должен рассматриваться как недоверенный и, возможно, вредоносный.
Большинство существующих блокчейн-платформ с поддержкой умных контрактов, используют парадигму order-execute (упорядочить-исполнить), в которой протокол консенсуса:
- проверяет и упорядочивает транзакции, а затем распространяет их между одноранговыми узлами,
- каждый одноранговый узел последовательно выполняет транзакции.
Парадигму «order-execute» можно увидеть практически во всех существующих блокчейн-системах, от публичных платформ без контроля доступа, таких как Ethereum (с консенсусом на основе PoW), до платформ с контролем доступа, таких как Tendermint, Chain и Quorum.
Умные контракты, выполняемые в блокчейне, в котором принята парадигма «order-execute», должны быть детерминированными, иначе консенсус может быть никогда не достигнут. Чтобы решить проблему недетерминизма, многие платформы требуют написание умных контрактов на нестандартном, или специфическом, языке (например, Solidity), чтобы исключить недетерминированные операции. Это препятствует широкому внедрению, поскольку от разработчиков умных контрактов требуется изучение нового языка и может привести к ошибкам при программировании.
Кроме того, поскольку все транзакции выполняются последовательно всеми узлами сети, производительность и масштабируемость ограничены. Тот факт, что код умного контракта выполняется на каждом узле системы, требует принятия сложных мер по защите всей системы от потенциально вредоносных контрактов для обеспечения отказоустойчивости всей системы.
Новый подход¶
Fabric представляет новую парадигму выполнения транзакций, которую мы называем execute-order-validate (выполнить-упорядочить-проверить). Она решает проблемы отказоустойчивости, гибкости, масштабируемости, производительности и конфиденциальности, с которыми сталкивается модель «order-execute», разделяя исполнение транзакции на три этапа:
- выполнение транзакций и их одобрение путем проверки их правильности,
- упорядочение транзакций через (подключаемый) протокол консенсуса и
- проверка транзакций на соответствие политике одобрения, установленной для конкретного приложения, перед их записью в реестр.
Такой подход радикально отличается от парадигмы «order-execute» тем, что Fabric выполняет транзакции до достижения конечного соглашения об их порядке.
В Fabric политика одобрения, определенная для каждого конкретного приложения, определяет, какие одноранговые узлы или сколько из них должны поручиться за правильное исполнение умного контракта. Таким образом, каждая транзакция должна быть выполнена (одобрена) только тем подмножеством одноранговых узлов, которое необходимо для удовлетворения политики одобрения транзакции. Это позволяет осуществлять параллельное выполнение, увеличивая общую производительность и масштаб системы. Этот первый шаг также устраняет любой недетерминизм, поскольку противоречивые результаты могут быть отфильтрованы до упорядочивания.
А поскольку мы устранили недетерминизм, Fabric является первой реализации технологии блокчейн, позволяющей использовать стандартные языки программирования.
Конфиденциальность¶
Как мы уже говорили, в публичной блокчейн-сети без контроля доступа, использующей в качестве модели консенсуса PoW, транзакции выполняются на каждом узле. Это означает, что не может быть конфиденциальности ни самих контрактов, ни данных транзакций, которые они обрабатывают. Каждая транзакция и код, который ее реализует, видны каждому узлу сети. В данном случае мы обменяли конфиденциальность контрактов и данных на византийский консенсус, обеспечиваемый PoW.
Отсутствие конфиденциальности может быть проблемой при реализации различных бизнес-сценариев. Например, в сети партнеров в цепочке поставок некоторым покупателям могут быть предоставлены привилегированные тарифы как средство укрепления отношений или стимулирования дополнительных продаж. Если каждый участник может видеть все контракты и транзакции, становится невозможным поддерживать такие деловые отношения в полностью прозрачной сети: все заходят получить привилегированные тарифы!
В качестве второго примера рассмотрим индустрию ценных бумаг, где трейдер, создающий позицию (или избавляющийся от нее) не захочет, чтобы об этом узнали его конкуренты, иначе они будут стремиться вступить в игру, ослабляя гамбит трейдера.
Для решения проблемы отсутствия конфиденциальности при реализации корпоративных бизнес-сценариев, в блокчейн-платформах используются различные подходы. Все они имеют свои компромиссы.
Один из подходов к обеспечению конфиденциальности — шифрование данных. Однако, в сети без контроля доступа, использующей PoW для консенсуса, зашифрованные данные находятся на каждом узле. При наличии достаточного количества времени и вычислительных ресурсов, шифрование может быть взломано. Для многих корпоративных сценариев, риск компрометации данных неприемлем.
Доказательство с нулевым разглашением (ZKP) — еще одна область исследований, связанных с решением этой проблемы. Компромисс здесь заключается в том, что в настоящее время вычисление ZKP требует значительного времени и вычислительных ресурсов. Следовательно, в данном случае мы имеем компромисс между производительностью и конфиденциальностью.
Для модели с контролем доступа, в которой используются альтернативные протоколы консенсуса, могут быть рассмотрены подходы, ограничивающие распространение конфиденциальных данных только авторизованными узлами.
Hyperledger Fabric, будучи платформой с контролем доступа, обеспечивает конфиденциальность через наличие каналов в сети и функции конфиденциальных данных. В каналах участники Fabric создают подсеть в которой каждый участник имеет доступ к определенному набору транзакций. Таким образом, только те узлы, которые присоединены к каналу, имеют доступ к умным контрактам (чейнкоду) и данным транзакций, сохраняя конфиденциальность и того, и другого. Конфиденциальные данные позволяют определять коллекции участников канала, обеспечивая во многом ту же защиту данных, что и каналы, но без дополнительного создания и поддержки отдельных каналов.
Подключаемый консенсус¶
Упорядочение транзакций передано отдельному компоненту, который логически отделен от одноранговых узлов, выполняющих транзакции и поддерживающих реестр. Этот компонент — служба упорядочения. Поскольку консенсус является модульным, его реализация может быть адаптирована к доверительным допущениям конкретного развертывания или решения. Такая модульность позволяет платформе полагаться на хорошо зарекомендовавшие себя инструменты для отказоустойчивого (CFT) или византийского (BFT) упорядочения.
В настоящее время Fabric предоставляет отказоустойчивую реализацию службы упорядочения, основанную на библиотеке etcd протокола Raft. Информацию о доступных в данный момент службах упорядочения вы можете найти в нашей документации.
Заметьте, что такие службы не являются взаимно-исключающими. В сети Fabric может быть несколько упорядочивающих служб, поддерживающих различные приложения или требования приложений.
Производительность и масштабирование¶
На производительность блокчейн-платформы может влиять множество факторов, таких как размер транзакции, размер блока, размер сети, а также ограничения аппаратного обеспечения и т.д. Рабочая группа по производительности и масштабированию Hyperledger Fabric в настоящее время работает над системой эталонного тестирования под названием Hyperledger Caliper.
Было опубликовано несколько научных работ, посвященных изучению и тестированию производительности Hyperledger Fabric. В последней из них в сети Fabric было получено 20.000 транзакции в секунду.
Заключение¶
Любая серьезная оценка блокчейн-платформ должна включать Hyperledger Fabric.
Вместе взятые отличительные особенности Hyperledger Fabric делают ее хорошо масштабируемой системой для построения блокчейн-сетей с контролем доступа, поддерживающих гибкие доверительные допущения, что позволяет платформе поддерживать широкий спектр отраслевых сценариев от правительственных и финансовых применений, цепочек поставок, здравоохранения до многих других.
Hyperledger Fabric — самый активный из проектов Hyperledger. Сообщество, созданное вокруг платформы, постоянно растет, а инновации, появляющиеся с каждым новым выпуском, значительно превосходят все другие платформы корпоративного блокчейна.
Благодарности¶
Написанное выше взято из рецензируемого исследования «Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains» — Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, Jason Yellick
© Copyright Hyperledger 2020.
This work is licensed under a Creative Commons Attribution 4.0 International License alt=»Creative Commons License» /> Revision d248a7a2 .
Hyperledger fabric что это
Hyperledger Fabric, an open source project from the Linux Foundation, is the modular blockchain framework and de facto standard for enterprise blockchain platforms. Intended as a foundation for developing enterprise-grade applications and industry solutions, the open, modular architecture uses plug-and-play components to accommodate a wide range of use cases.
With more than 120,000 contributing organizations and more than 15,000 engineer contributors working together, Hyperledger Fabric offers a unique approach to consensus that enables performance at scale while also preserving the data privacy enterprises demand.
Hyperledger Fabric is an open, proven, enterprise-grade, distributed ledger platform. It has advanced privacy controls so only the data you want shared gets shared among the “permissioned” (known) network participants.
Smart contracts document the business processes you want to automate with self-executing terms between the parties written into lines of code. The code and the agreements contained therein exist across the distributed, decentralized blockchain network. Transactions are trackable and irreversible, creating trust between organizations. This enables businesses to make more informed decisions quicker — saving time, reducing costs, and reducing risks.
Hyperledger Fabric для Чайников
Добрый день, дорогие читатели, меня зовут Николай Нефедов, я технический консультант компании 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
Полезны ссылки
Благодарности
Выражаю огромную благодарность за помощь в подготовке статьи моим коллегам:
Николаю Марину
Игорю Хапову
Дмитрию Горбачеву
Александру Земцову
Екатерине Курденковой
Екатерине Гусевой
What is Hyperledger Fabric?
Hyperledger Fabric is an open source, permissioned blockchain framework, started in 2015 by The Linux Foundation. It is a modular, general-purpose framework that offers unique identity management and access control features, which make it suitable for a variety of industry applications such as track-and-trace of supply chains, trade finance, loyalty and rewards, as well as clearing and settlement of financial assets.
What is Blockchain Technology?
Blockchain is a technology that makes it possible to build applications where multiple parties can record transactions directly, without the need for a trusted, central authority to ensure that the transactions are verified. Blockchain enables this with the help of a peer-to-peer network where each participant in the network has access to a shared ledger where the transactions are recorded. These transactions are by design, immutable and cryptographically verifiable. At a high-level, blockchain technology consists of three components: a distributed ledger, consensus algorithm, and smart contracts.
- A ledger is a transactional log that keeps a complete record of the entire history of data changes. Ledgers are immutable and append-only by design, and the committed transactions are independently verifiable by each member in a network. In a blockchain technology, each member of the network maintains a copy.
- Consensus algorithms help ensure that the members in the network have an agreed-upon method to allow transactions and data to be committed to the ledger and execution of smart contract code. If the consensus requirements aren’t met, then the transaction or operation is considered invalid.
- Smart contracts are code that is executed on the blockchain network. Often times, they define the rules of a business contract and are executed programatically when the preconditions for the contract are met.
Benefits of Hyperledger Fabric
Open Source
Hyperledger Fabric platform is an open source blockchain framework hosted by The Linux Foundation. It has an active and growing community of developers.
Permissioned
Fabric networks are permissioned, meaning all participating member’s identities are known and authenticated. This benefit is particularly useful in industries including healthcare, supply chain, banking, and insurance where data cannot be exposed to unknown entities. For example, an insurance company on a Hyperledger Fabric blockchain network can share customer’s claim data with permissioned parties to maintain customer privacy.
Governance and Access Control
Fabric networks consist of channels, which are a private “subnet” of communication between two or more specific network members, members on the network can transact in a private and confidential way. Each transaction on the blockchain network is executed on a channel, where each party must be authenticated and authorized to transact on that channel. This provides an additional layer of access control and is especially useful when members want to limit exposure of the data, for example when competitors are on the same network. Fabric also offers a Private Data Collection feature set, where access to given transactions on a channel can be limited to subset of participants.
Performance
Hyperledger Fabric is built to support enterprise-grade use cases, and can support quick transaction throughput from its consensus mechanism. Because Fabric is a permissioned blockchain framework, it does not need to solve for Byzantine Fault Tolerance which can cause slower performance when validating transactions on the network.
How does Hyperledger Fabric Work?
A Hyperledger Fabric network is comprised of unique organizations (or members) that interact with each other on the network. For example, an organization could be a bank in a network comprised of financial institutions or a shipping partner in a supply chain network. From a Fabric component perspective, each organization has a Fabric certificate authority and one or more peer nodes. A Fabric network also has an ordering service shared by all organizations in the network, and this component helps process transactions for the network. We will share more details about each of these concepts and components below:
An organization in a network is defined by a root certificate specific to that organization. Users and other components (like peer nodes – see below) in that organization are also identified by certificates, and these certificates are derived from this root certificate, ensuring other organizations in the network can relate a user to their organization. These certificates also specify the permissions for each entity on the network, like read-only versus full access on a channel.
A root certificate for an organization is stored in the Fabric certificate authority (CA). The Fabric CA also issues certificates for users in an organization and handles other related operations. An enterprise-grade Fabric CA utilizes a variety of components and can deployed in a variety of ways using a Hardware Security Module (HSM) for root certificate protection.
An organization also creates one or more peer nodes as components to carry out operations on behalf of that organization. Specifically, a peer node endorses transactions proposed on the network, stores and executes smart contract code (known as chaincode in Fabric), and stores a local copy of the ledger for access. Fabric clients typically interact with peer nodes to read the ledger, add new chaincode to the network, or propose a new transaction. A peer node typically runs on its own computer, like an Amazon EC2 instance.
Finally, a Fabric network also includes of an ordering service shared by all members of the network. The ordering service makes sure new transactions on the network are properly ordered in new blocks and have the proper endorsements. The ordering service then broadcasts a new block of transactions to peer nodes in each organization. Peer nodes update their local copy of the ledger with this new block.
Hyperledger Fabric Transaction Flow
1. The transaction flow begins when a client application sends a transaction proposal to peers in each organization for endorsement.
2. The peers verify the submitting client’s identity and authority to submit the transaction. Next, they simulate the outcome of the proposed transaction and if it matches what was expected, it sends an endorsement signature back to the client.
3. The client collects endorsements from peers, and once it receives the proper number of endorsements defined in the endorsement policy, it sends the transaction to the ordering service.
4. Lastly, the ordering service checks to see if the transaction has the proper number of endorsements to satisfy the endorsement policy. It then chronologically orders and packages the approved transactions into blocks, and sends these blocks to peer nodes in each organization. Peer nodes receive new blocks of transactions from the ordering service, and then do a final validation for transactions in that block. Once this is complete, the new block is added to the ledger and the state of the ledger is updated. The new transactions are now committed.
Hyperledger Fabric vs. Hyperledger Sawtooth
Hyperledger Sawtooth is another open source blockchain platform hosted by The Linux Foundation under the Hyperledger Project. Hyperledger Fabric and Hyperledger Sawtooth networks have differing governance capabilities and consensus algorithms.
CHARACTERISTICS
HYPERLEDGER SAWTOOTH
Permissions
Created specifically for permissioned networks.
Supports permissioned and permissionless networks.
Privacy and Network Governance
Transaction Flow
Unique Execute-Order-Commit endorsement model where transactions are initially executed on a set of peers while ordering service handles packaging and delivery.
Flexibility in defining set of required endorsers at the data level or contract level. This approach makes the framework more scalable and prevents nondeterminism in contract code.
Traditional Order-Execute-Commit flow. Sawtooth Validator handles transaction processing, ordering, and delivery.
Consensus Algorithms
Pluggable consensus algorithm allowing the orderer to be switched based on needs of the environment.
Amazon Managed Blockchain’s ordering service is built using Amazon QLDB technology and has an immutable change log that accurately maintains the complete history of all transactions in the blockchain network, ensuring durability of the data.
Uses a default “Proof-of-Elapsed Time (PoET)” algorithm, which is a Byzantine Fault consensus mechanism that relies on a specialized hardware component. Read more here.
Smart Contract Language
Go, Java, Python, Rust
Industry Use Cases for Hyperledger Fabric
Supply Chain
Supply chains are global, distributed webs of suppliers, manufacturers, and retailers. Hyperledger Fabric networks can improve supply chain processes by increasing transparency and traceability of transactions within the network. On a Fabric network, companies with access to the ledger can view the same immutable data, which enforces accountability and reduces the risk for counterfeiting. In addition, production updates are added to the ledger in real time, which makes tracking provenance faster and simpler during events like product recalls or food contamination outbreaks.
Trading and Asset Transfer
Trading requires many organizations such as importers, exporters, banks, shipping companies, and customs departments, to work with one another. Using Hyperledger Fabric, financial and trading consortiums can easily create a blockchain network where all parties can transact and process trade-related paperwork electronically, without the need for a central trusted authority. Unlike other processes that require trade-related paperwork to go back and forth between the stakeholders, taking 5-10 days to complete, transactions in a Hyperledger Fabric network built using Managed Blockchain can process instantly.
Insurance fraud costs the insurance industry billions of dollars a year, but with Hyperledger Fabric, insurance companies can reference transaction data stored on the ledger to identify duplicate or falsified claims. Blockchain can also make multi-party subrogation claims processing faster by using smart contracts to automate repayment from the at-fault party back to the insurance company. In addition, insurers can use Hyperledger Fabric to streamline Know Your Customer (KYC) processes by storing customer data on a distributed ledger and automating the verification of their identity documents with smart contracts.
Hyperledger Fabric on Amazon Managed Blockchain
Amazon Managed Blockchain is a fully managed service that allows you to set up and manage a scalable Hyperledger Fabric blockchain network with just a few clicks. Amazon Managed Blockchain eliminates the overhead required to create the network, and automatically scales to meet the demands of thousands of applications running millions of transactions. Once your network is up and running, Managed Blockchain makes it easy to manage and maintain your Hyperledger Fabric network. It manages your certificates and lets you easily invite new members to join the network.
Get started building a Hyperledger Fabric blockchain network in minutes with AWS on Amazon Managed Blockchain here.