Вступление

В общих чертах, блокчейн это неизменяемый транзакционный реестр (immutable transaction ledger), поддерживаемый распределенной сетью узлов (пиров, peers, nodes). Каждый из этих узлов поддерживает копию блокчейна, применяя транзакции, подтвержденные протоколом консенсуса и сгруппированные в блоки, включающие в себя хэш, связывающий каждый новый блок с предыдущим.

Первое и самое известное применение блокчейна - криптовалюта Bitcoin, по стопам которой последовали многие другие применения этой технологии. Криптовалюта Ethereum пошла по иному пути: она использовала многие наработки Bitcoin, но добавила смарт контракты для создания платформы распределенных приложений. Тип блокчейна в Bitcoin и Ethereum - public permissionless: это публичные, открытые всем сети, по которым участники анонимно взаимодействуют друг с другом.

По мере роста популярности Bitcoin, Ethereum и других, производных от них технологий, растет и интерес к применению технологии блокчейна, распределенного реестра и распределенных платформ для более инновационного промышленного использования. Однако для многих кейсов требуется применение характеристик, которыми permissionless-технологии на данный момент не обладают. Также во многих случаях личность участников имеет большое значение, как, например, в случае финансовых транзакций, где соблюдаются принципы Know-Your-Customer (KYC) и Anti-Money-Laundering (AML).

Для промышленного использования нужно учитывать следующие требования:

  • Личность участников должна быть известна
  • Сети должны поддерживать разные уровни доступа к данным, то есть быть permissioned-сетями
  • Высокая производительность транзакций
  • Короткая задержка подтверждения транзакций
  • Приватность и конфиденциальность транзакций и связанных с ними данных

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

Hyperledger Fabric

Hyperledger Fabric - это готовая для промышленного использования платформа с технологией распределенного реестра (distributed ledger technology - DLT), permissioned-сетями и открытым исходным кодом, спроектированная для промышленных ситуаций, которая обладает ключевыми возможностями, отличающими ее от остальных блокчейн- и DLT-платформ.

Одним из таких решающих отличий является то, что Hyperledger был основан под консорциумом Linux Foundation, который имеет долгую и успешную историю ведения open source проектов с помощью открытого управления, обеспечивающего рост устойчивых сообществ и процветающих экосистем. Hyperledger управляется комитетом, состоящим из независимых разработчиков, а Hyperledger Fabric - множеством независимых мейнтейнеров из различных организаций. Со времени первых коммитов оно выросло в сообщество, состоящее из более чем 35 организаций и около 200 разработчиков.

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

Fabric - первая DLT-платформа, которая поддерживает смартконтракты, написанные на языках программирования общего назначения, таких как Java, Go и Node.js, вместо использования DSL. Это означает, что большинство предприятий уже способны разрабатывать смартконтракты и им не потребуется дополнительное время на изучение нового языка или DSL.

Платформа Fabric использует permissioned-сети, то есть, в отличие от public permissionless-сетей, участники знают друг друга - они не анонимны. Это означает, что, хотя участники могут не полностью доверять друг другу (возможно они, например, конкуренты в одной и той же отрасли), сеть может работать по модели управления, основанной на том доверии, которое все же существует между участниками. Это доверие может быть создано юридическим соглашением или протоколом разногласий.

Одно из важных отличий платформы - поддержка сменных протоколов консенсуса, которые позволяют платформе эффективнее подстраиваться под конкретные юзкейсы и модели доверия. Например, будучи развернутым внутри единственного предприятия или управляемого доверенным органом, BFT консенсус может оказаться ненужным и вредить производительности и пропускной способности. В таких ситуациях, возможно, разумнее использовать crash fault-tolerant (CFT) консенсус-протокол, но в случае распределенного юзкейса с несколькими участниками более традиционный BFT консенсус-протокол может быть необходим.

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

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

Давайте более детально рассмотрим эти отличительные черты.

Модульность

При проектировании Hyperledger Fabric главной целью была модульная архитектура. Что бы ни требовалось - сменный консенсус, сменный протокол управления учетными записями (можно поставить, например, LDAP или OpenID Connect), протоколы управления ключами или криптографические библиотеки - платформа была спроектирована так, чтобы иметь возможность подстроиться ко всему разнообразию промышленных юзкейсов.

Fabric состоит из следующих модульных компонентов:

  • Сменный ordering service устанавливает консенсус в последовательности транзакций и затем передает сформированные блоки пирам.
  • Сменный membership service provider ставит в соответствие сущностям сети их криптографические учетные записи.
  • Опциональный peer-to-peer gossip service распространяет блоки, полученные от ordering service, среди пиров.
  • Смартконтракты (‘chaincode’) выполняются внутри контейнерного окружения для изоляции (например, Docker). Они могут быть написаны на стандартных языках программирования, но не имеют прямого доступа к состоянию реестра.
  • Реестр можно настроить так, чтобы поддерживать разные виды DBMS.
  • Сменные политики по подтверждению и валидации (endorsement and validation policies) могут быть настроены независимо для каждого приложения

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

Permissioned vs Permissionless

В permissionless-блокчейне участвовать может практически каждый, и каждый участник анонимен. В таком случае не может быть никакого доверия кроме того, который следует из неизменяемости состояния блокчейна. Чтобы восполнить это отсутствие доверия, permissionless-блокчейны вводят встроенную криптовалюту, которую можно майнить, или плату за транзакции, чтобы создать экономический BFT консенус на основе “Proof of Work” (PoW).

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

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

Смартконтракты

Смартконтракт, в Fabric - “chaincode”, действует как доверенное распределенное приложение, которое обретает свою безопасность и доверие к себе через блокчейн и стоящий за ним консенсус пиров. Он составляет бизнесс-логику блокчейн-приложения.

Существует три ключевых пункта, относящихся к смартконтрактам, особенно существующим на платформе:

  • множество смартконтрактов выполняются одновременно в сети,
  • они могут быть развернуты динамически (во многих случаях любым участником, и
  • их коду нельзя доверять, он может быть вредоносным

Большинство существующих платформ, поддерживающих смарт контракты, следуют архитектуре order-execure (упорядочить-выполнить), в которой консенсус-протокол: валидирует и упорядочивает, а потом распространяет их по всем узлам, каждый узел потом исполняет транзакции в заданном порядке.

Архитектура order-execute может быть обнаружена в практически всех существующих блокчейн-системах, от public permissionless-платформ как Ethereum с PoW консенсусом, до permissioned платформ как Tendermint, Chain, и Quorum.

смартконтракты выполняемые в блокчейне, который действует под архитектурой order-execute должны быть детерминированными, иначе к консенсусу можно никогда так и не прийти.

Чтобы справиться с этой проблемой, многие платформы требуют, чтобы смартконтракты были написаны на нестандартном языке или DSL (как в случае Solidity), чтобы не допустить недетерминированных операций. Такой подход мешает широкому распространению среди разработчиков, так как им требуется выучить новый язык. Также такой подход может привести к многочисленным ошибкам в коде.

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

Новый подход

Fabric представляет новую архитектуру для транзакций, которую мы называем execute-order-validate (выполнить-упорядочить-валидировать). Она решает проблемы гибкости, масштабируемости, производительности и конфиденциальности, присутствующие в архитектуре order-execute, разбивая транзакционный поток на три шага:

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

Такой дизайн радикально отличается от парадигмы order-execute в том, что Fabric выполняет транзакции до определения их конечного порядка.

В Fabric, определенная для каждого типа транзакций политика подтверждения указывает на то, какие узлы и в каком количестве должны поручиться за корректность выполнения определенного смартконтракта. Так, каждая транзакция должна быть выполнена (подтверждена) только на подмножестве узлов, чтобы удовлетворить политике подтверждения. Это позволяет использовать параллельное выполнение, увеличивая общую производительность системы. Эта фаза также убирает весь недетерминизм, так как противоречивые результаты будут отфильтрованы перед ordering’ом.

Приватность и конфиденциальность

Как мы уже обсудили, в public permissionless-блокчейнах сети, использующей PoW, транзакции выполняются на каждом узле. Это означает, что невозможна конфиденциальность ни самих контрактов, ни транзакционных данных, которыми они оперируют. Каждая транзакция и код, который ее осуществляет, видны каждому узлу в сети. В этом случае, мы принесли конфиденциальность контрактов и данных на BFT-консенсус, обеспечиваемый PoW.

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

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

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

Шифрование данных - это один из подходов к обеспечению конфиденциальности; однако в permissionless-сетях использующих PoW консенсус, зашифрованные данные размещены на каждом узле. Имея достаточно времени и вычислительных ресурсов, зашифрованные данные могут быть расшифрованы злоумышленником. Для многих промышленных юзкейсов риск такой расшифровки неприемлем.

Доказательства с нулевым разглашением (Zero knowledge proofs, ZKP) - еще одна область, которая сейчас изучается чтобы решить эту проблему. Минус этого подхода в том, что вычисление ZKP требует значительных временных и вычислительных ресурсов. Следовательно, в этом случае мы обмениваем производительность на конфиденциальность.

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

Hyperledger Fabric, будучи permissioned-платформой, предоставляет конфиденциальность через архитектуру каналов (channels) и механизм приватных данных (private data). В каналах, определенные участники Fabric-сети создают подсеть, где каждый участник видит только определенный набор транзакций. Так, только узлы, участвующие в канале, имеют доступ к смартконтрактам (chaincode) и передаваемым данным, сохраняя приватность и конфиденциальность обоих. Приватные данные предоставляют возможность создания коллекций между участниками канала, гарантируя примерно ту же защиту, что и каналы, но без необходимости в создании и поддержке отдельной подсети.

Сменный консенсус

Ordering транзакций передан модульному компоненту, чтобы консенсус был логически отделен от пиров, выполняющих транзакции и поддерживающих реестр. Ordering передан компоненту под названием ordering service (ordering-служба). Так как консенсус модульный, он может быть реализован с определенным знанием доверия в конкретной системе. Такая архитектура позволяет платформе использовать хорошо отработанные инструменты для CFT- или BFT-ordering’а.

В текущем состоянии Fabric предоставляет реализацию CFT ordering-службы, базирующуюся на библиотеке etcd протокола Raft. Для информации о доступных на данный момент ordering-службах, смотрите документацию по ordering’у.

Заметьте, что такие службы не являются взаимно-исключающими. Сеть Fabric может иметь несколько ordering-служб, чтобы удовлетворить возможным требованиям приложений.

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

Производительность блокчейн-платформ может зависеть от множества факторов: размера транзакции, размера блока, размера сети, от ограничения оборудования, и т.д. Группа по работе над производительностью и масштабированием работает над banchmarking-инструментом Hyperledger Caliper.

Существуют исследовательские публикации, изучающие и тестирующие производительность Hyperledger Fabric. Последняя такая статья: scaled Fabric to 20,000 transactions per second.

Заключение

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

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

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

Предшествующее получено из рецензированной публикации «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