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

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

Hyperledger Fabric должна стать отправной точкой в развитии корпоративных блокчейн решений, которые будут созданы на базе проверенного, открытого исходного кода.

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

Hyperledger Fabric отличается от других блокчейн-систем тем, что  является “закрытым и контролируемым”. В отличие от открытых систем, позволяющих неидентифицированным личностям участвовать в работе сети (например, механизм консенсуса PoW в Bitcoin), участники блокчейнов Hyperledger Fabric должны проходить регистрацию с получением сертификата. В дальнейшем уровень доступа к отдельным структурам блокчейна может быть настроен с помощью анализа идентификаторов. Например, отдельные группы участников могут создавать каналы, которые будут являться отдельным регистром транзакций, доступным только им.

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

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

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

Practical Byzantine fault tolerance (PBFT)

Основным механизмом обеспечения консенсуса в Hyperledger Fabric является  алгоритм Practical Byzantine fault tolerance (PBFT) - практический подход к византийской отказоустойчивости. PBFT - механизм на базе голосования. Этот алгоритм предложен в 1999 году группой исследователей из Массачусетского института. Преимущество алгоритма PBFT состоит в его устойчивости к двум основным классам ошибок функционирования распределенных систем: полный отказ компонента и византийская ошибка. В первом случае – это ошибки, связанные с недоступностью одного из компонентов распределенной системы, например, узел прекратил работу. Византийские же ошибки характеризуются тем, что узел продолжает работать, но при этом может делать это некорректно, выдавая неверную информацию. Второй класс ошибок является более сложным к распознаванию, но, как было сказано выше, алгоритм PBFT является по отношению к нему устойчивым. Также алгоритмы BFT отличаются тем, что результатом их работы всегда является конечное состояние системы, не возникает случаев неопределенности.

В распределенных системах задача византийских генералов  - это задача консенсуса в сети ненадежных вычислителей. Она звучит примерно так: задача взаимодействия нескольких удаленных узлов, которые получили послание из одного управляющего центра. Часть узлов могут быть скомпрометированы, но необходимо принять верное решение. Алгоритм PBFT работает в предположении, что (n-1)/3 узлов могут быть скомпрометированы.

На пальцах алгоритм PBFT можно описать так: каждый узел публикует ключ. Любое сообщение, проходящее через узел, подписывается им для проверки. Далее сообщение вновь пересылается другим узлам и проходит проверку. После того как будет достигнуто достаточное количество одинаковых ответов, транзакция считается действительной.  Однако, нужно учитывать, что чем больше узлов участвует в алгоритме, тем больше времени займет достижение консенсуса. Подробное описание алгоритма (оригинальный документ) на английском языке представлено по ссылке:
http://pmg.csail.mit.edu/papers/osdi99.pdf

A Kafka-based Ordering Service

Еще в документации проекта упоминается механизм обеспечения консенсуса на базе кластера Kafka Apache с сервисом Zookeeper, который тоже относится к механизмам открытого голосования. Kafka это гибрид распределенной базы данных и очереди сообщений. Zookeeper ensemble – это распределенный сервис конфигурирования и синхронизации.

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

В документации говорится, что использование такого механизма консенсуса подходит тем, кому необходима высокая производительность системы и при этом несущественна византийская отказоустойчивость. Система Kafka устойчива к полным отказам компонента (fault tolerance), но не устойчива к византийским ошибкам.

Подробное описание механизма и пути решения возможных сложностей представлены в официальном документе:
https://docs.google.com/document/d/1vNMaM7XhOlu9tB_10dKnlrhy5d7b1u8lSY8a-kVjCO4/edit

SOLO

Другой, самый простой механизм обеспечения консенсуса, – SOLO: один узел обслуживает всех клиентов. Консенсуса не требуется, поскольку существует “центральный орган управления”. Однако, это скорее тестовая спецификация.

Hyperledger Fabric является проектом Linux Foundation. Linux Foundation – некоммерческая организация, основанная в 2007 году путем слияния Open Source Development Labs и Free Standarts Group. Цель организации – продвижение и разработка ресурсов и сервисов открытого ПО. Linux Foundation состоит из крупных компаний, которые ежегодно выделяют средства на разработку проектов.

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

Открытый код проекта доступен в соответствии с лицензией Apache License 2.0, доступной по ссылке:
http://www.apache.org/licenses/LICENSE-2.0.

Любые добавления кода также должны сопровождаться сертификатом “Developer Certificate of Origin sign-off”:
http://developercertificate.org.

Вся документация проекта предоставляется в соответствии с международной лицензией “Creative Commons Attribution 4.0 International License”:

http://creativecommons.org/licenses/by/4.0/)

Если в соответствии с миссией проекта возникает необходимость использовать код с другой лицензией, совет управляющих может ради исключения провести голосование по этому вопросу: исключение может быть сделано только при достижении ⅔ голосов. Также все участники обязаны соблюдать антимонопольную политику Linux Foundation:
http://www.linuxfoundation.org/antitrust-policy.

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

Hyperledger Fabric состоит из двух основных компонентов: журнала состояния (world state) и журнала транзакций (transaction log). Журнал состояний описывает состояние сети в данный момент времени – это база данных сети. В журнале транзакций регистрируются все транзакции, в результате которых наступило текущее состояние сети – это история обновлений. Каждый участник имеет копию базы данных каждой сети Hyperledger Fabric, к которой он принадлежит. Интересной возможностью является выполнение специальных запросов, подобных SQL-запросам, к базе данных для эффективного аудита сети и разрешения спорных вопросов.

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

В Hyperledger Fabric участники блокчейна разделены на несколько категорий:

• Клиенты (client / committing peer). Этот тип узлов относится к конечным пользователям, которые могут совершать транзакции
• Узлы (peer). Этот тип узлов поддерживает работу сети и управляет выполнением транзакций и добавлением блоков в сеть. К ним также относится специальный тип узлов поручителей – индоссанты (endorser), которые проверяют, удовлетворяет ли транзакция всем необходимым требованиям.
• Сервисные узлы (orderers  from ordering service). Этот тип узлов формирует блоки транзакций и утверждает добавлений новых блоков в блокчейн, работает с  узлами-peers. Также ими обрабатываются все конфигурационные транзакции для настройки политики сети.

Подобное разделение сетевых ролей обеспечивает своеобразный параллелизм в работе блокчейна и делает процесс его работы более эффективным.

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

Транзакции в Hyperledger Fabric разделены на два типа:

• Выполняемые/развертываемые (deploy transactions). Такие транзакции создают новый чейн-код и принимают программу в качестве входного параметра. Когда развертываемая транзакция успешно выполняется, чейн-код “устанавливается” в блокчейн
• Вызываемые транзакции (invoke transactions). Такие транзакции выполняют операцию на базе чейн-кода, который уже установлен в блокчейн ранее при помощи развертываемой транзакции. Вызываемая транзакция относится к чейн-коду или одной из его функций. После ее успешного выполнения чейн-код выполняет изменение текущего состояния системы.

Hyperledger Fabric поддерживает сети, в которых конфиденциальность является ключевым требованием, что особенно актуально для сетей B2B (business to business). Это реализуется с помощью специальных частных каналов: ограниченные пути обмена сообщениями, которые могут использоваться определенными подгруппами участников. Каналы Hyperledger Fabric еще называют подсетями. Все данные о выполненных транзакциях и участниках канала недоступны остальным пользователям сети, не имеющим доступ к этому частному каналу. Каждый канал определяется следующими параметрами:

• участниками (организациями), которые к нему принадлежат;
• узлами (peer) для каждого участника канала;
• совместным распределенным регистром;
• чейн-кодами, развернутыми на данном канале;
• сервисными узлами (orderers).

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

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

31 июля 2017 года компания Fujitsu (один из участников консорциума Hyperledger) объявила о разработке технологии, которая повышает производительность сети Hyperledger Fabric v0.6.1 примерно в 2,7 раза. С использованием этой технологии производительность достигла 1350 транзакций в секунду (TPS 1350). Благодаря этому, с точки зрения производительности,  Hyperledger Fabric стал применим к онлайн транзакционным системам, которые требуют более 1000 транзакций в секунду. Сейчас Fujitsu  продолжает исследование и развитие технологии и адаптирует ее к последней версии Hyperledger Fabric. А разработчики Fabric дополнительно изучают усовершенствование механизмов консенсуса, которые также смогут повысить производительность.

В документации проекта делается упор на то, что архитектура Hyperledger Fabric подразумевает разделение участников блокчейна на три категории, о которых говорилось выше: clients, peers, orderers. Благодаря этому разделению, возникает эффект распараллеливания, когда узлы поручители (endorser peers) ортогональны к узлам oderers.

Порядок выполнения транзакции можно разделить на несколько этапов:

1. Приложение направляет заявку о выполнении транзакции узлу поручителю (endorser).
2. Узлы поручители определяют, сколько их подписей (и каких) необходимо для одобрения заявки, и после этого выполняют чейн-код, создавая набор для чтения и записи. Для выполнения каждой транзакции готовится набор для чтения и записи (read/write set). Набор для чтения содержит список уникальных значений, которые транзакция считывает во время выполнения. Набор записи содержит список уникальных ключей и их новых значений, которые транзакция должна записать.
3. После этого узлы поручители отправляют подписанную заявку обратно в приложение.
4. Приложение  отправляет транзакцию и подписи в сервисные узлы.
5. Сервисные узлы формируют блоки транзакций и доставляют их узлам-peers.
6. Для каждой полученной транзакции узлы-peers проверяют,  были ли выполнены условия одобрения и нет ли ошибок в наборах для чтения и записи (обнаружение конфликтующих транзакций). Если обе проверки пройдены, блок фиксируется в регистре, и обновления состояний для каждой транзакции отображаются в журнале состояния.

Поскольку по сети передаются только подписи и наборы для чтения и записи, а процесс выполнения транзакции расщепляется, оптимизируется масштабируемость и производительность.

С помощью алгоритма консенсуса PBFT (который является основным механизмом консенсуса) достигается отказоустойчивость = (n-1)/3 для системы, состоящей из n узлов. Система устойчива как к полным отказам компонента (узел не работает), так и к византийским ошибкам (узел работает некорректно). Так же системы на базе PBFT являются неизменными: после окончательного подтверждения транзакцию нельзя отменить.

Принципиальным отличием сетей Hyperledger Fabric от других блокчейнов является то, что они контролируемые (permissioned). Для того чтобы пользователь мог стать участником сети и, соответственно, имел право вносить изменения в блокчейн, его кандидатура должны быть “одобрена центральным органом”. Специальные механизмы (Certificate Authority, Membership Service Providers) осуществляют проверку “уровней доступа” пользователей посредством проверки сертификатов и идентификаторов. Таким образом, вероятность нарушения безопасности случайным лицом минимизируется. С другой стороны, владельцы сети должны понимать, что из-за этого обязанность контроля ложится в какой-то степени и на них. С технической точки зрения механизм консенсуса BFT является хорошо изученным и надежным (несмотря на это, разработчики заявляли о возрождении исследований протоколов BFT). Так что сопоставление этих двух аспектов должно иметь хороший результат.  

Для разработчиков блокчейнов создан специальный фреймворк Error handling framework, с помощью которого проще отслеживать и распознавать возникающие ошибки.

CA - это модульный компонент для управления сетевыми идентификаторами всех организаций-членов и их пользователей. С его помощью происходит регистрация участника сети и выпуск сертификатов. С помощью сертификатов пользователи смогут “подписывать” действия в блокчейне. Сертификаты разделяются на два типа:

• долгосрочные сертификаты (enrollment certificate - Ecert)
• одноразовые сертификаты, позволяющие провести одну сетевую транзакцию (transaction certificate Tcert)

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

HFC SDK позволяет разработчикам создавать приложения, взаимодействующие с блокчейном. С их помощью упрощается управление эксплуатацией каналов и чейн-кодов. Версия Hyperledger Fabric 1.0 поддерживает SDK на языках программирования Java и Node.js.
SDK предоставляет следующие функции:

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

В whitepaper Hyperledger говорится о том, что, несмотря на большое количество блокчейн-сетей и их уровень независимости, Hyperledger нуждается в адресной системе, которая будет позволять транзакциям одной сети взаимодействовать с транзакциями другой сети.

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

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

Стоит отметить, что  22 августа 2017 года Hyperledger объявила о запуске новой технологии Sawtooth Ethereum, которая обеспечивает интеграцию их другого проекта Hyperledger Burrow с виртуальной машиной Ethereum. Hyperledger Burrow давно позиционируется как механизм, с помощью которого будет обеспечено взаимодействие EVM с другими проектами Hyperledger, таким образом работы в сфере интеграции с другими крупными проектами действительно ведутся.

У Hyperledger существует своя википедия, в которой есть раздел, посвященный разработке разных сценариев использования проектов Hyperledger, в том числе Fabric:
https://wiki.hyperledger.org/groups/requirements/use-case-inventory#pre-wiki_document_history.
Раздел находится в активной работе и у каждого сценария свой статус уровня разработки.

Бизнес-кейсы разделены на категории, каждая из которых содержит сценарии использования в разной степени полноты описания.
Среди них представлены:

• Рынки капитала (кредитный дефолтный своп, корпоративное взаимодействие, синдицированный банковский кредит, депозитарий активов, обмен и т.д.).
• Финансовые сервисы (база финансовых справочных данных, микрокредитование, эскроу сервисы, межбанковские платежи, трансграничные денежные переводы и т.д.).
• Правительственные/правовые/нормативные (отслеживание идентификаторов граждан, системы голосования, владение собственностью, контроль трансграничных капиталов и т.д.).
• Здравоохранение/медицина (результаты клинических испытаний, выявление контрафактных лекарств, регистрация медицинского страхования и т.д.).
• IoT - Internet of things, интернет вещей.
• Публикации (отслеживание прав владения музыкой, книгами и т.п.).
• Логистика (отслеживание предметов роскоши, контроль цепочек поставок, контроль подделок и т.п.).

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

Отдельно нужно отметить Hyperledger Composer (https://composer-playground.mybluemix.net/login) - фреймворк для разработки приложений на базе блокчейнов Fabric. Composer призван упростить разработку и запуск блокчейн-приложений новичкам и тем, кто не сталкивался ранее с блокчейн-разработками и разработками на базе Fabric.

Первой  версией платформы была Hyperledger Fabric v0.6.0. Она была выпущена осенью 2016 года. После этого компания продолжала разработки, добавляя на каждом этапе новые механизмы, постепенно приближаясь к итоговой версии.
1 июля 2017 была запущена первая производственная версия - Hyperledger Fabric 1.0.

В ней, в отличие от предыдущих, уже реализован механизм консенсуса SBFT Simplified BFT – это механизм на базе PBFT.

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

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

2 ноября 2017 стала доступна превью-версия Hyperledger Fabric v1.1.0-preview:
https://www.hyperledger.org/blog/2017/11/02/hyperledger-fabric-v1-1-0-preview-is-now-available.
Среди нововведений возможность создания чейнкодов с помощью Node.js, упрощение возможности настройки конфигурации организации, расширение возможностей шифрования данных и смарт-контрактов, контроль доступа на основе атрибутов и другие. Компания обращает внимание, что еще не готова к полноценному релизу этой версии, но хотела бы услышать ранние отзывы сообщества о работе нового функционала.

Полноценный релиз это версии Hyperledger Fabric v1.1.0-alpha намечен на 31 января 2018 года.

У  Hyperledger существует общая whitepaper для всех проектов, в которой описаны ключевые моменты необходимые для успешного внедрения в бизнес-индустрию.
https://docs.google.com/document/d/1Z4M_qwILLRehPbVRUsJ3OF8Iir-gqS-ZYe7W-LE9gnE/pub

Платформа Hyperledger Fabric сопровождается очень подробной официальной документацией, касающейся всех особенностей платформы.
https://hyperledger-fabric.readthedocs.io/en/latest/

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

Github проекта также снабжен файлами readme с подробным описанием всех этапов и нюансов применения встроенных механизмов. В целом активность команды на github высокая и стабильная.

Road Map  в привычном виде у проекта не существует.

На официальном сайте даже появлялся пост на эту тему:
https://hyperledger.org/blog/2017/11/28/update-on-the-hyperledger-fabric-1-1-roadmap,
в котором объясняется, что команда хочет, чтобы их планы работ относительно следующей версии были прозрачны. Вся информация собрана на вики проекта:
https://wiki.hyperledger.org/projects/fabric.

Также за активностью работы можно следить на JIRA, где собрана статистика разработок проекта:

https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104 .

Hyperledger был основан в 2015 году Linux Foudation.

Состав руководства представлен на официальном сайте:
https://www.hyperledger.org/about/leadership

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

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

В состав консорциума Hyperledger входит более 130 ведущих компаний, и список участников постоянно пополняется новыми членами.

К премиальным участникам, члены которых входят в управляющий совет Hyperledger, относятся:

• Accenture
• Airbus
• American Express
• Change Healthcare
• Cisco
• CME Group
• Gruppe Deutsche Börse
• DAIMLER
• Digital Asset
• DTCC
• Fujitsu
• HITACHI
• IBM
• Intel
• J. P. Morgan
• NEC
• R3
• SAP
• WANDA GROUP

К основным участникам относятся еще 120 компаний-участников, среди которых Oracle, Nokia, Sberbank, Samsung, Paxos, Huawei, Deloitte и другие.

Премиальные и основные члены консорциума должны быть действующими членами Linux Foundation.

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

Еще одна категория членов консорциума - Associate Member category. К ней относятся некоммерческие организации, проекты с открытым исходным кодом и государственные структуры. Присоединение членов этой категории требует одобрения советом управляющих с установлением критериев присоединения.

Отдельно в документации именно Hyperledger Fabric приведен список специалистов по техническому обслуживанию с указанием их адресов электронной почты и никнеймов на Gerrit, GitHub, Rocketchat.
http://hyperledger-fabric.readthedocs.io/en/latest/MAINTAINERS.html

К конкурентам проекта можно отнести блокчейн-платформы со смарт-контрактами, такие как Ethereum, Corda, NEM и т.д.

Ethereum является публичным блокчейном со смарт-контрактами, на базе которого могут функционировать любые приложения без привязки к конкретной отрасли. Смарт-контракты в Ethereum должны быть написаны на специальном языке программирования Solidity, в то время как в Fabric и Corda можно писать смарт-контракты на распространенном Java.

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

На блокчейн-платформе NEM также могут создаваться смарт-контракты, однако, они отличаются тем, что выполняются вне блокчейна.  Также у NEM существует версия для приватных блокчейнов – Mijin. Еще один популярный проект – блокчейн-платформа со смарт-контрактами Cardano, но она пока находится в стадии разработки.

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

Цитируемость, соцсети

Известность проекта стремительно растет в связи с тем что в июле 2017 года была выпущена первая “производственная” версия Hyperledger Fabric и большое количество крупных компаний заявило о разработке блокчейн-решений на ее базе.

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

Активность в соцсетях, в подтверждение вышесказанному, довольно низкая:

• Twitter — 47’867 читателей,
• Facebook — 6’788 подписчиков,
• YouTube — 5’086 подписчиков.

Проекты на Hyperledger Fabric

На данный момент многие проекты заявили о намерении разрабатывать системы на базе Hyperledger Fabric. Среди этих проектов:

• Глобальная торговая платформа Batavia, создание которой было инициировано UBS (крупнейший финансовый холдинг Швейцарии) и IBM. На данный момент к инициативе присоединились четыре крупных банка: Bank of Montreal (BMO), CaixaBank, Commerzbank и Erste Group.
  Новая платформа должна быть построена таким образом, чтобы позволить организациям любого масштаба беспрепятственно использовать ее в любой точке мира для проведения транзакций по всем видам торговли. Batavia должна позволить организациям строить многопартийные трансграничные торговые сети и следить за всеми этапами торговых перевозок.
• Oracle тестирует новую платформу на базе Fabric. Платформа будет ориентирована на корпоративных клиентов. Основным функционалом будет выполнение транзакций, заключение контрактов и отслеживание поставок. Еще одним проектом Oracle на базе Fabric  станет сервис Blockchain Cloud Service — облачный сервис для корпоративных клиентов.
• Royal Bank of Canada руководит проектом по переводу системы платежей с банками США на блокчейн-технологию. Сейчас RBC уже успешно ввел технологию в существующие системы, она дублирует основной реестр банка, позволяя отслеживать платежи между США и Канадой в реальном времени.
  (http://finance.liga.net/cryptoeconomics/2017/9/28/news/54910.htm)
• Блокчейн-консорциум CLS group, в который входят Barclays, Bank of America, Bank of China (Hong Kong), Bank of Tokyo-Mitsubishi UFJ, Citibank, Goldman Sachs, JPMorgan Chase, Morgan Stanley и другие, анонсировал разработку системы безопасных и оперативных платежей и обмена валют. Такой мощный состав консорциума стал поводом для заявлений о том, что вполне возможно будет создана альтернатива SWIFT-переводам.
• Компания Change Healthcare (является членом консорциума Hyperledger), которая занимает лидирующие позиции в разработке программ в сфере здравоохранения США, заявила о создании сети Intelligent Healthcare Network для проведения и обработки транзакций по медицинским искам.
• Ведущая южнокорейская брокерская компания и поставщик услуг Coinplug запустила торговую платформу на базе блокчейн. До этого цифровые валюты не поддерживались ни на одной из платформ компании.
• Fujitsu и Японская ассоциация банкиров (JBA) тестируют блокчейн-платформу на базе Fabric с целью изучения возможностей внедрения технологии в сферу финансовых услуг.
• IBM основал блокчейн-консорциум, направленный на разработку сети управления цепями поставок на базе Fabric. В консорциум вошли такие компании как: Nestle, Unilever, Walmart, Dole и другие.
• В конце августа SWIFT объявила о завершении тестирования прототипа системы проведения онлайн транзакций по международным корреспондентским счетам на базе Fabric.
• Sony и Sony Global Education разработала систему хранения данных об образовании (дипломы, сертификаты и т. п.) на базе Fabric и IBM Blockchain.
• Крупный банк Тайланда Kasikornbank разрабатывает блокчейн-систему для гарантийных писем, которые являются обеспечением ценных бумаг со стороны банка

Постоянно добавляются новые проекты, т. к.  Hyperledger Fabric — основная блокчейн технология для корпораций.

Персоны в проекте

В составе команды есть персоны, известные в IT-индустрии, такие как Brian Behlendorf, который был основным разработчиком веб-сервера Apache; Arnaud Le Hors — разработчик IBM, который был редактором нескольких ключевых веб-спецификаций, включая HTML и DOM, и принимал участие в таких проектах с открытым исходным кодом, как Xerces, парсер Apache XML и X Window System; и др. технические специалисты IBM.

Hyperledger Fabric, несомненно, является передовиком в области приватных блокчейнов.

Известность проекта стремительно растет в связи с тем что в июле 2017 года была выпущена первая “производственная” версия Hyperledger Fabric и большое количество крупных компаний заявило о разработке блокчейн-решений на ее базе.

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

Hyperledger Fabric ориентирована на корпоративный сектор. Предполагается, что решения на базе Fabric будут внедряться “гигантами” отрасли и, соответственно, выведут использование блокчейн-технологий на новый уровень.

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

Одним из ярких событий в рунете стало проведение первой в РФ банковской платежной транзакции между Сбербанком и Альфа-банком с использованием блокчейна на базе Hyperledger Fabric:
https://abnews.ru/2017/11/29/sberbank-i-alfa-bank-blokchejn/.

К концу января планируется релиз новой версии Hyperledger Fabric v1.1.0-alpha, уже сейчас доступна превью-версия с обновленным функционалом.

Ссылки

Официальный сайт: https://www.hyperledger.org/projects/fabric

Документация проекта: http://hyperledger-fabric.readthedocs.io/en/latest/

Facebook: https://www.facebook.com/hyperledger/

Github: https://github.com/hyperledger/fabric

Slack: https://hyperledgerproject.slack.com

Gerrit: https://gerrit.hyperledger.org/r/#/q/status:open

Twitter: https://twitter.com/hyperledger

1. Добавлен раздел “Известность”, как дополнительный параметр оценки проекта. Вес раздела в системе рейтинга — 10 баллов.
2. Подраздел “Проекты на Hyperledger Fabric” перенесен из раздела “Функционал и программная платформа” в раздел “Известность”.
3. В связи с изменением, указанным в п. 2, оценка раздела “Функционал и программная платформа” изменилась с 12 из 12 на 10 из 10.

В связи с вышеуказанными изменениями общий рейтинг проекта изменился с 44 балла из 46 — 95,6% на 50 баллов из 54 — 92,59%.