Архитектура Hyperledger Fabric¶

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

Активы — Возможность определения своих активов позволяет обмениваться практически всем, что имеет денежную стоимость в сети: от продуктов питания и антикварных автомобилей до валютных фьючерсов.
Чейнкоды — Чейнкод выполняется отдельно от ordering-транзакций, что понижает требуемый уровень доверия и проверки между разными типами узлов, а также оптимизирует производительность и масштабируемость.
Реестр — Неизменяемый распределенный реестр кодирует всю историю транзакций каждого канала и включает в себя возможность совершения SQL-подобного запросов, что обеспечивает простое и эффективное проведение аудитов, а также однозначное разрешение споров.
Конфиденциальность — Каналы и коллекции конфиденциальных данных позволяют осуществлять конфиденциальные и многосторонние сделки, что обычно требуется для сети из конкурирующих предприятий или для сети определенной регулируемой отрасли.
`Security & Membership Службы`_ — Permissioned membership позволяют создать доверенную блокчейн-сеть, в которой участники понимают, что все транзакции отслеживаются уполномоченными регулирующими органами и аудиторами.
Консенсус — Уникальный подход к консенсусу обеспечивает необходимые для предприятий гибкость и масштабируемость.

Активы¶

Активы могут варьироваться от материального имущества (недвижимость и оборудование) до нематериального имущества (контракты и интеллектуальная собственность). Hyperledger Fabric позволяет манипулировать активами с помощью чейнкод-транзакций.

Активы реализованы в Hyperledger Fabric как коллекция пар ключ-значение, с изменениями состояния, записанными в качестве транзакций в реестре канала (Канал). Активы могут быть представлены в двоичном и/или JSON формате.

Чейнкоды¶

Чейнкод — это программа, определяющая активы и инструкции по изменению активов; можно сказать, чейнкод определяет бизнес логику. Чейнкод обеспечивает соблюдение правил чтения и изменения пар ключ-значение или другой информации из базы данных. Чейнкод исполняется на основе текущего состояния базы данных реестра и инициализируются транзакционным proposal (предложением о проведении транзакции). Результатом работы чейнкода является набор записей (write set) пар ключ-значение, которые могут быть занесены в реестр всех пиров и представлены в сеть.

Реестр¶

Реестр — это последовательная, защищенная от подделки запись всех переходов состояния Fabric. Переходы состояния являются результатом вызова чейнкода («транзакций») участвующими сторонами. Результатом каждой транзакции является набор привязанных к реестру, принадлежащим активам пар ключ- значение, которые удаляются, создаются или обновляются.

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

Некоторые свойства реестра Fabric:

Поисковые запросы и обновления реестра с использованием запросов на основе ключа, range-запросов, и composite key запросов
Read-only запросы, использующие rich query language (ри использовании CouchDB в качестве базы данных)
Read-only запросы истории — Запросы истории реестра по ключу, позволяющие узнать происхождение данных
Транзакции состоят из версий ключей, считанных в чейнкоде (read set) и ключей, в которые велась запись (write set)
Транзакции собирают подписи каждого подтверждающего пира и передаются ordering-службе
Транзакции упорядочиваются в блоки и доставляются ordering-службой пирам канала
Пиры проверяют транзакции в соответствие с политикой подтверждения и обеспечивают соблюдение политики
Перед добавлением блока проводится проверка версий, чтобы убедиться, что состояние активов, использовавшихся в чейнкоде, не изменилось с момента исполнения чейнкода
После подтверждения транзакции она неизменяема
Реестр канала содержит конфигурационный блок, определяющий политики, ACL (списки контроля доступа) и другую информацию
Каналы содержат Membership Service Provider, позволяющие получать криптографические материалы от различных CA (certificate authorities)

Чтобы узнать больше о базах данных, структурах хранилища и «query-ability», ознакомьтесь с разделом Реестр.

Конфиденциальность¶

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

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

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

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

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

Ознакомьтесь с разделом Private Data для более подробных деталей о способах достижения конфиденциальности в вашей блокчейн-сети.

Службы Security & Membership¶

В основе Hyperledger Fabric лежит транзакционная сеть, в которой у всех участников есть известная identity. Public Key Infrastructure (Инфраструктура публичного ключа) раздает криптографические сертификаты, привязанные к организациям, сетевым компонентам, конечным пользователям или клиентским приложениям. В результате управление доступом к данным регулируется и изменяется и на широком, сетевом уровне, и на уровне каналов. Понятие «permissioned» Hyperledger Fabric в сочетании с возможностями каналов позволяет рассматривать сценарии, в которых конфиденциальность имеет первостепенное значение.

Для лучшего понимания криптографии, подписей, проверок и аутентификации, используемых в Hyperledger Fabric, ознакомьтесь с разделом Membership Service Providers (MSP).

Консенсус¶

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

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

В дополнение к многочисленным проверкам, на каждом этапе транзакционного потока происходят проверки identity. ACL (списки контроля допуска) реализованы на разных иерархических уровнях сети (от ordering-служб до каналов), и формирующаяся транзакция неоднократно подписывается и проверяется по мере прохождения через разные компоненты. В заключение, консенсус не ограничивается согласованным порядком набора транзакций, это всеобъемлющее подтверждение корректности, которое достигается в ходе проверок, проводимых в процессе становления транзакций, от proposal до включенных в блок и распределенных по всему каналу.

Ознакомьтесь с диаграммой Выполнение транзакции для визуального представления процесса консенсуса.