Hyperledger fabric что это

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

Полезны ссылки

Благодарности

Выражаю огромную благодарность за помощь в подготовке статьи моим коллегам:
Николаю Марину
Игорю Хапову
Дмитрию Горбачеву
Александру Земцову
Екатерине Курденковой
Екатерине Гусевой

Hyperledger Fabric
Blockchain

Вступление¶

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

Первым и самым известным применением блокчейна является криптовалюта 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

This work is licensed under a Creative Commons Attribution 4.0 International License Revision 5945a07f .

Hyperledger Fabric

Hyperledger Fabric — это программный фреймворк для разработки приложений и специализированных бизнес-решений на основе блокчейна.

Решение имеет модульную архитектуру, позволяющую использовать по принципу plug-and-play различные компоненты, и применяет технологию контейнеров для выполнения «умных» контрактов, реализующих логику приложений системы.

2017: Выпуск

Участники проекта Hyperledger в октябре 2017 года объявили о выходе Fabric версии 1.0 — программного фреймворка для создания на основе распределенного реестра бизнес-сетей, поддерживающих «умные» контракты. На разработку Hyperledger Fabric 1.0 ушло около 16 месяцев. Свой вклад в создание продукта внесли 159 разработчиков из 28 организаций.

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

По словам исполнительного директора Hyperledger Брайана Белендорфа (Brian Behlendorf), Fabric ведет единую запись всех транзакций, что актуально для индустрии финансовых услуг. Появилась возможность перейти на модель мгновенных взаиморасчетов, основанную на едином совместно используемом распределенном реестре.

В то же время, «умные» контракты Hyperledger Fabric могут применяться и для автоматизации управления электронными медицинскими картами: участники системы здравоохранения смогут получать согласие пациента каждый раз, когда им нужно поделиться конфиденциальными сведениями о нем.

Система Hyperledger Fabric 1.0 готова к развертыванию и эксплуатации в рабочем режиме. [1]

Смотрите также

Блокчейн (Blockchain) (основная статья)
Проекты на базе блокчейн-технологии
Консорциум R3 — R3 управляет консорциумом из более чем 60 крупнейших в мире финансовых институтов для разработки прорывных коммерческих приложений для индустрии финансовых услуг, которые используют соответствующие элементы распределенных и общих реестровых технологий.
Блокчейн в России
Биткоин (Bitcoin) Криптовалюта
Hyperledger (Open Ledger Project)
МастерчейнЦБ РФ
Блокчейн–фонд
Digital Trade Chain (DTC)

Примечания

Что такое Hyperledger Fabric платформа: преимущества и примеры

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

Технология Blockchain радикально трансформирует современные концепции различных отраслей нашей жизни. Одним из самых популярных вариантов при разработке блокчейн проекта является Hyperledger Fabric. Мы представляем вам одну из лучших структур для разработки блокчейн технологий — Hyperledger Fabric, механизм с открытым исходным кодом для бизнес-цепочек.

Введение: что такое Hyperledger Fabric

Hyperledger Fabric — относительно новая бизнес блок-схема. Hyperledger Fabric имеет несколько отличительных характеристик по сравнению с другими современными моделями блокчейна; являются ли эти характеристики преимуществами или недостатками, часто зависит от контекста.

Hyperledger Fabric — это лучший фреймворк для разработки приложений и специализированных бизнес-решений на основе блокчейна.

Необходимо отметить, чтобы соответствовать современным требованиям бизнеса организация IBM присоединилась к другим компаниям для совместной разработки открытой исходной, готовой к производству, бизнес-блок-схемы, называемой Hyperledger Fabric, одного из восьми проектов Hyperledger, организованных The Linux Foundation.

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

В Hyperledger Fabric v1.0 участвовало 159 инженеров из 27 организаций.

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

В рамках работы в консорциуме IBM и создала блокчейн-фреймворк Hyperledger Fabric (изначально проект назывался OBC — Open Blockchain). Первая версия HLF, под номером 0.6.0, появилась осенью 2016 года. 1 июля 2017 вышла первая производственная версия — Hyperledger Fabric 1.0.

Необходимо отметить, что Everledger, мировой цифровой реестр бриллиантов, использует блок-цепочку Hyperledger Fabric для отслеживания конфликтных алмазов через цепочку поставок для защиты поставщиков, покупателей и перевозчиков от краж и подделок.

А сейчас перейдем к преимуществам Hyperledger Fabric.

Идентификационное членство

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

Hyperleger Fabric создавался корпорацией для корпораций, поэтому в него «пускают по билетам». Участник сети должен получить сертификат и быть идентифицирован. Разным участникам могут быть предоставлены разные права, ограничения и привилегии.

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

Производительность, масштабируемость и уровень доверия

Hyperledger Fabric построен на модульной архитектуре, которая делит обработку транзакций на три этапа: распределенную логическую обработку и соглашение («цепочный код»), упорядочение транзакций, а также на проверку и подтверждение транзакций. Такое разделение дает несколько преимуществ: для типов узлов требуется меньшее количество уровней доверия и верификации, а децентрализация сети и производительность оптимизированы.

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

Чтобы проиллюстрировать это, рассмотрим поток транзакций в версии 1.0 Hyperledger Fabric, показанный на рисунке ниже.

Начиная слева от рисунка:

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

Поскольку в сети с новой архитектурой v1.0 отправляются только сигнатуры и набор для чтения / записи, оптимизируются масштабируемость и производительность. Кроме того, поскольку только подтверждения и узлы действительно видят транзакцию, требуется меньшее количество уровней доверия в разных частях системы Blockchain, что обеспечивает большую безопасность.

Например, на фондовом рынке с ценными бумагами, обеспеченными активами или купленными и продаваемыми облигациями, объем сделок увеличился из-за растущего числа участников. Для увеличения количества транзакций в блокчейн системе требуется улучшенная масштабируемость и производительность, что и v1.0 от Hyperledger Fabric частично объясняется расщеплением выполнения цепочки.

Разделение выполнения цепочки также обеспечивает динамический рост в сети. В версии 1.0 Hyperledger Fabric узлы могут добавляться динамически и программно, а не статически, как в v0.6. Например, предположим, что компания, которая управляет валютными курсами, имеет новый банк для добавления в сеть. С Hyperledger Fabric v1.0 они могут сделать это программно, что увеличивает эффективность структуры.

Доступ к информации

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

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

Децентрализованная книга Fabric и смарт-контрактная платформа позволяют использовать частные каналы. Если у вас большая сеть цепочки и вы хотите делиться данными только с определенными сторонами, вы можете создать частный канал только с этими участниками. Более того, не каждая транзакция может быть видна каждому пользователю сети. Hyperledger Fabric позволяет осуществлять частные транзакции — что-то, что невозможно зделать в Ethereum, что способствует прозрачности. Для определенных высоко регулируемых отраслей, таких как здравоохранение, это, безусловно, очень большая выгода.

Смарт-контракты: Как и Ethereum, Fabric позволяет использовать смарт-контракты под названием «chaincode». Смарт-контракты разработаны на высшем уровне.

Не каждый блокчейн должен быть анонимным и открытым. Всё зависит от назначения его использования. Hyperledger Fabric позволяет всем участникам сети иметь известные идентификаторы. Децентрализованные блок-цепи — это именно то, что надо финансовым компаниям, а тем более отрасли здравоохранения.

Например, возьмем случай с ипотечной компанией, использующей blockchain. Информация об ипотеке не может открыто публиковаться. Информация требует от сторон возможности идентифицировать себя в сети для проверки подлинности.

Постоянность сети

Децентрализованная среда представляет собой упорядоченную запись информации для приложения blockchain. Каждая транзакция приводит к набору ключа-значения, который привязан к регистру. Он может быть создан, обновлен или удален. Неизменяемый источник доверия для v1.0 добавляется в файловую систему узла, который также имеет встроенный модуль LevelDB.

LevelDB имеет по умолчанию базовую основу данных и поддерживает ключевые запросы, составные ключевые запросы и запросы диапазона ключей. Если вам нужны сложные, насыщенные запросы, CouchDB поможет вам и поддержит базовые возможности LevelDB, добавляя полные запросы, богатые данными запросы. При наличии дополнительной поддержки базы данных документов, такой как CouchDB, контент JSON становится полностью запрашиваемый, модель данных совместима с существующей моделью программирования ключей / значений. В результате всего этого изменение приложения не требуются при моделировании данных кодового кода как в JSON при использовании CouchDB.

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

Модульная архитектура, поддерживающая подключаемые компоненты

Hyperledger Fabric даёт возможность разработчикам создавать встраиваемые компоненты в свою архитектуру. Например, вы можете сжать какие то компоненты по мере необходимости и в один из самых быстрых способов.

Такая модульность обеспечивается благодаря своей прочной архитектуре, которая учитывает перспективы развития новой технологии blockchain. Это очень удобно, когда вы хотите получить доступ к системе, например, к пользовательской системе управления идентификационными данными, чтобы пользователи могли использовать платформу blockchain, построенную поверх Hyperledger Fabric.

Модульная архитектура: Fabric имеет модульную архитектуру и обеспечивает большую гибкость в зависимости от того, что вы хотите использовать.

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

Прозрачный процесс: транзакции могут быть непрозрачными, но процесс разработки наоборот. «На этом этапе основные команды Hyperledger были чрезвычайно готовы сбалансировать потребности, чтобы получить возможности с открытым и прозрачным процессом развития», — заметил основатель Skuchain Заки Маниан.

Защита цифровых паролей и конфиденциальных данных

Поддержка HSM (Hardware Security Module) жизненно важна для защиты и управления цифровыми ключами для надежной аутентификации. Hyperledger Fabric предоставляет модифицированный и немодифицированный PKCS11 для генерации ключей, который поддерживает такую функцию, как управление идентификацией, которая нуждается в большей защите. Для сценариев управления идентификацией HSM повышает защиту ключей от взлома и конфиденциальных данных.

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

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

С каналами в Hyperledger Fabric вы можете предоставлять данные, которые необходимы только в разделённом виде, или хранить данные, чувствительные к разделам данных.

Поддержка сообщества

Сообщество, которое формирует и вносит изменения в Hyperledger Fabric, сегодня очень энергично.

При поддержке таких огромных компаний, как IBM и Toyota, использующих Hyperledger Fabric в своем производстве, сообщество Hyperledger Fabric и его поддержка продолжают расти быстрыми темпами.

Поддержка больших предприятий: благодаря таким технологическим гигантам, как IBM, Intel и Cisco, Fabric имеет сильную поддержку со стороны корпоративных компаний. Это может обеспечить высокую степень стабильности, внушая уверенность тем, кто все еще может не знать о будущем блокчейна. С другой стороны, знакомые с блокчейном люди обратят внимание на относительно новую и эффективную инфраструктуру.

Hyperledger Fabric все ещё новая инфраструктура

Hyperledger Fabric является самым зрелым технологическим проектом Hyperledger, но сам Hyperledger далеко не является таким. Фактически, Fabric 1.0 был выпущен только в июле 2017 года.

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

Создатели Hyperledger Fabric признают, что многое еще предстоит сделать. Вот, что сказал Крис Ферриса по этому поводу: «Конечно, это не конец. Есть еще много работы. Нам необходимо больше сотрудничества и новых инноваций на всех проектах Hyperledger». Феррис является председателем Технического руководства комитета Hyperledger и техническим директором Open Technology в IBM.

Ethereum против Hyperledger Fabric

Чтобы лучше понять Hyperledger Fabric, можно сравнить его с Ethereum.

Ethereum, сосредоточившись на децентрализованных приложениях (dApps), интеллектуальных контрактах и публичной блок-цепочке, больше ориентирован на рынок бизнес-потребителей (B2C).

Между тем, предприятиям, которые хотят разрабатывать приложения blockchain с надежной поддержкой конфиденциальности и децентрализации, ориентируются на Hyperledger Fabric. Он лучше всего подходит для разработки готовых к подключению приложений с блок цепочкой с использованием смарт-контрактов и поддержкой конфиденциальности и разрешений. Модульная архитектура Fabric обеспечивает гибкость и в значительной степени ориентирована на предприятия, которые хотят оптимизировать свой процесс работы, используя технологию blockchain.

Как заявляет издание, «большинство корпоративных приложений будут ориентированы на Fabric, тогда как Ethereum будет оставаться основой для dApps, которые являются более B2C».

Hyperledger, со своими технологическими спонсорами, ориентирован исключительно на приложения на основе транзакций. Несмотря на это Ethereum также ориентируется на корпоративных клиентов.

Возьмем, к примеру, JP Morgan Quorum, созданный и открытый JPMorgan. Quorum — это разрешенная реализация Ethereum; это то, что называется форком общественного блокчейна Ethereum. Подобно Fiber, у него нет собственной криптовалюты.

Существует Enterprise Ethereum, который был запущен в феврале 2017 года. В него входят более 30 компаний из списка Fortune 500, а также стартапы, ученые, поставщики технологий и эксперты Ethereum. В число участников входят BP, Cisco, Accenture, Intel и Toyota.

Оцените (232 оценки — 4.4 из 5)