Вступление

В общих чертах, блокчейн это неизменяемый транзакционный реестр (immutable transaction ledger), поддерживаемый распределенной сетью узлов (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) с открытым исходным кодом, которая обладает рядом возможностей, отличающих её от остальных блокчейн- и DLT-платформ.

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

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

Fabric - первая DLT-платформа, которая поддерживает смартконтракты, написанные на языках программирования общего назначения, таких как Java, Go и Node.js, вместо использования предметно-ориентированных языков программирования (domain-specific languages, 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) - они могут быть написаны на стандартных языках программирования, но не имеют прямого доступа к состоянию реестра;
• реестр можно настроить так, чтобы поддерживать разные виды СУБД.
• политики по подтверждению и валидации (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-execute (упорядочить-выполнить), в которой: транзакции валидируются и упорядочиваются, а затем распространяются по всем узлам; каждый узел выполняет транзакции в заданном порядке.

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

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

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

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

Новый подход

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

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

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

В Fabric определенная для каждого типа транзакций политика подтверждения указывает на то, какие узлы и в каком количестве должны поручиться за корректность выполнения определенного смартконтракта. Это означает, что невозможна конфиденциальность ни самих контрактов, ни транзакционных данных, которыми они оперируют. Каждая транзакция и код, который ее осуществляет, видны каждому узлу в сети. В этом случае, мы принесли конфиденциальность контрактов и данных на 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-служб, чтобы удовлетворить возможным требованиям приложений.

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

Производительность блокчейн-платформ может зависеть от множества факторов: размера транзакции, размера блока, размера сети, от ограничения оборудования, и т.д. Группа по работе над производительностью и масштабированием работает над benchmarking-инструментом 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