Что такое Hyperledger Fabric?
Гибкая среда блокчейна, лежащая в основе IBM Blockchain Platform, помогает новаторам кардинально менять бизнес во всем мире
Что такое Hyperledger Fabric?
Hyperledger Fabric — это проект Linux Foundation с открытым исходным кодом, который предлагает модульную среду блокчейна и является стандартом де-факто для корпоративных платформ блокчейна. Открытая модульная архитектура, которая создавалась как основа для разработки приложений корпоративного класса и отраслевых решений, использует готовые компоненты для решения широкого спектра задач.
Hyperledger Fabric, в разработке которого принимало участие более 120000 организаций и более 15000 проектировщиков, предлагает уникальный подход к достижению консенсуса, который обеспечивает производительность в требуемом масштабе без ущерба для конфиденциальности данных.
Принцип работы Hyperledger Fabric
Hyperledger Fabric — это открытая и надежная платформа распределенного реестра корпоративного класса. Она предлагает расширенные средства обеспечения конфиденциальности — доступом к общим данным обладают только разрешенные (известные) участники сети.
Смарт-контракты описывают бизнес-процессы, которые требуется автоматизировать с помощью самовыполняющихся соглашений между сторонами, представленных в виде строк кода. Код и соглашения смарт-контрактов размещаются в распределенной, децентрализованной сети блокчейна. Отслеживаемые и необратимые транзакции укрепляют доверие между организациями. В результате компании получают возможность быстрее принимать более обоснованные решения, экономя время, сокращая расходы и уменьшая риски.
Преимущества Hyperledger Fabric
Контролируемая сеть
Формирование децентрализованного доверия в сети с известными участниками, а не в открытой сети с анонимными участниками.
Конфиденциальные транзакции
Предоставление доступа только к тем данным, которыми вы хотите поделиться с конкретными участниками.
Подключаемая архитектура
Подключаемая архитектура позволяет с большей эффективностью адаптировать блокчейн к отраслевым потребностям по сравнению с решением, подходящим на все случаи жизни.
Простое начало работы
Для программирования смарт-контрактов можно использовать те же языки, на которых уже работают ваши разработчики — нет необходимости изучать специализированные языки и архитектуры.
Использование kubernetes для разработки блокчейн проектов на Hyperledger Fabric
Добрый день, дорогие хабровчане.
Я являюсь разработчиком научно-технического центра IBM в Москве. Мы ведем разработку продуктов IBM совместно с другими лабораториями по всему миру. Если позволяет время и есть желание, то у нас разрешено использовать часть рабочего времени на проекты, которые не являются основной занятостью. Такой подход расширяет кругозор и поддерживает творческий настрой. Для меня такой областью является разработка блокчейн-решений на Hyperledger Fabric. Тем более, что такие проекты стали востребованы на нашем рынке.
Надеюсь, что статья будет не о блокчейне, а о том, что мы используем для разработки таких решений, но тем не менее стоит все-таки начать с предметной области.
Статья не претендует на полноту и нацелена на создание рабочего облачного окружения для разработки блокчейн-проектов на Hyperledger Composer. В результате наших практических изысканий мы должны получить следующую инфраструктуру:
Немного о Hyperledger Fabric
Существует большое количество блокчейн-платформ, которые можно сравнивать до бесконечности. Скорее всего универсальной платформы не существует, есть выбранная для текущей задачи. Для себя из блокчейн-платформ я выбрал Hyperledger Fabric. С одной стороны потому, что платформа интересна мне с технической точки зрения, с другой — IBM активно участвует в консорциуме Hyperledger.
Hyperledger — это консорциум в рамках проекта Linux Foundation. Hyperledger Fabric (HLF) — реализация технологии блокчейн для построения различных решений. Она является блокчейн-платформой с контролируемым доступом (permissioned). Это означает, что добавление новых участников контролируется. Участники определяются на этапе проектирования сети и могут иметь различные роли. Наиболее понятными сценариями для таких сетей являются цепочки поставок, в которых участвует множество независимых компаний. Для примера можно изучить опыт Walmart, JD.com, IBM и Tsinghua University в организации цепочки поставок продуктов питания.
С технической точки зрения каждый участник имеет развернутый участок сети у себя в организации (или в облачной инфраструктуре), но не имеет доступа к участкам сети, развернутым в других компаниях.
Как видно из схемы — каждый участник имеет:
В приложении пользователи авторизуются с помощью своих ключей или связки логин и пароль и получают доступ к смарт-контракту.
Смарт-контракт – это запрограммированная бизнес-логика и правила взаимодействия с данными, которые размещены в распределенном реестре (ledger). Реестр содержит цепочку блоков транзакций, которые совершили участники сети. Каждый последующий блок хранит хэш предыдущего блока, за счет чего обеспечивается невозможность изменения части информации. Процесс согласования корректности блока и добавления его в распределенный реестр называется консенсусом. Различные блокчейн-платформы имеют различные механизмы консенсуса: proof of work (PoW), proof of stake (PoS), byzantine fault tolerance (BFT) и прочие.
Начиная с версии 1.0 HLF специфична наличием Ordering Service, который является распределенным между участниками кластером и отвечает за очередность транзакций в формирующемся блоке. По сконфигурированным параметрам он собирает транзакции в сети и формирует блок. В случае отказа Ordering Service транзакции в сети перестанут регистрироваться, но сами данные останутся неизменными.
Теперь, разобравшись с основными понятиями, мы можем переходить к практике.
Как развернуть свою собственную HLF сеть
Все компоненты HLF работают в Docker-контейнерах и могут быть развернуты как с помощью Docker Compose, так и с помощью Kubernetes. Кроме того, сами смарт-контракты тоже запускаются в Docker-контейнерах.
Для того, чтобы развернуть HLF можно использовать уже существующую kubernetes-сеть, minikube или воспользоваться одним из облачных Kubernetes as a Service.
В облачной инфраструктуре IBM можно развернуть свою kubernetes-сеть бесплатно.
Как развернуть kubernetes сеть в IBM Cloud.
Для того, чтобы начать пользоваться IBM Cloud необходимо:
После регистрации в IBM Cloud вы получите доступ в графический интерфейс управления вашей инфраструктурой. Вам будут доступны сотни сервисов и десятки подходов для размещения ваших приложений (Cloud Foundry, Kubernetes, OpenWhisk, виртуальные машины и выделенные сервера). Для использования виртуальных машин и выделенных серверов необходимо добавить кредитную карту, а вот небольшой кусочек kubernetes можно получить бесплатно (с купоном выше).
Для этого необходимо в левом верхнем углу нажать на кнопку меню и выбрать Containers.
Перед вами откроется панель управления кластерами kubernetes, Docker registry и helm-чартами.
Выбрав слева в меню пункт Cluster, вы увидите интерфейс создания кластера kubernetes и выбор региона, в котором кластер будет развернут. Вы можете создать бесплатный кластер в каждом регионе.
После нажатия кнопки Create cluster следует выбрать тип кластера Free и придумать ему название.
Создание кластера займет некоторое время, которое вы можете потратить на переход в консоль (заварить кофе вы не успеете). Установив IBM Cloud CLI (bx tool) вам необходимо сконфигурировать его для работы с вашим аккаунтом:
Теперь вы готовы к тому, чтобы начать использовать ваш kubernetes-кластер для любых целей. Кластер является бесплатным, и в его функционале есть некоторые ограничения, которые нам не помешают развернуть свою блокчейн-сеть:
Для тех, кто первый раз использует kubernetes, возможно, стоит поэкспериментировать с разворачиванием первых Deployment и сервисов. Те, кто уже готов окунутся в мир разработки блокчейн-проектов, могут переходить к следующим шагам.
Разворачиваем контейнеры HLF в kubernetes
Для тех, кто не так давно работает с Docker и Kubernetes напомню, что для разворачивания любого приложения в kubernetes нам необходимы 2 вещи:
Open Source сообщество разработчиков Hypeledger Fabric сделало за нас эту работу. Docker Images с HLF уже лежат на DockerHub и автоматически загрузятся в наш кластер. А вся yaml-конфигурация находится в github репозитории. На момент написания статьи репозиторий содержит конфигурацию для Hyperledger Fabric 1.0.3. Возвращаемся в консоль и выполняем следующие команды:
Что такое Hyperledger Composer
Composer является инструментом для разработчиков блокчейн-решений. С его помощью можно повысить скорость разработки блокчейн-решений с месяцев до недель. Существует онлайн-песочница Composer Playground, но вся бизнес-логика, спроектированная в ней, будет запускаться у вас в браузере (эмуляция блокчейн). В нашем случае Composer будет подключен к работающей сети Hyperledger Fabric, развернутой в kubernetes.
Для создания модели в Hyperledger Composer необходимо описать участников (participant), активов (asset) и транзакций (transaction). Данный подход позволяет перевести разработку блокчейн-проекта в термины вашей задачи, а не выбранной платформы или используемого инструмента. Код транзакций (бизнес-логика) пишется на JavaScript, и при запуске нового смарт-контракта не создается новый Docker-контейнер, а код транзакции передается на интерпретацию в существующий контейнер.
Еще одним достоинством Hyperledger Composer является автоматическое создание REST-интерфейсов на основе описанных активов и транзакций, что позволяет вам сразу начинать писать пользовательский интерфейс (и соответственно получить MVP ).
Запуск первого блокчейн проекта
После запуска Hyperledger Composer в IBM Cloud вы сможете зайти в его веб интерфейс по адресу
:31080. По умолчанию все необходимые контейнеры Docker проброшены на публичный доступ по технологии NodePort (мы же не забываем, что разворачиваем окружение для разработчика).
Composer подключен к github-проету, и вы можете развернуть один из существующих проектов или начать разрабатывать свой.
В результате мы получили бесплатное облачное окружение для разработки проектов на базе Hyperledger Fabric.
Как и в любом технически непростом проекте всегда есть много деталей и дополнительных вещей. Данная статья является ознакомительной и призвана помочь в самом начале изучения. Надеюсь, что время и силы позволят мне написать несколько статей с более детальной информацией как по kubernetes в IBM Cloud, так и про разработку для Hyperledger Fabric.
Распределенный реестр для колесных пар: опыт с Hyperledger Fabric
Привет, я работаю в команде проекта РРД КП (распределенный реестр данных для контроля жизненного цикла колесных пар). Здесь я хочу поделиться опытом нашей команды в разработке корпоративного блокчейна для данного проекта в условиях ограничений, накладываемых технологией. По большей части я буду говорить о Hyperledger Fabric, но описанный здесь подход может быть экстраполирован на любой permissioned блокчейн. Конечная цель наших изысканий — готовить корпоративные блокчейн-решения так, чтобы итоговым продуктом было приятно пользоваться и не слишком тяжело поддерживать.
Здесь не будет никаких открытий, неожиданных решений и здесь не будут освещаться никакие уникальные разработки (потому что их у меня нет). Я просто хочу поделиться своим скромным опытом, показать, что «так можно было» и, возможно, прочитать о чужом опыте принятия хороших и не очень решений в комментариях.
Проблема: блокчейны пока что не масштабируются
Задача, поставленная перед нашей командой в текущем проекте, выглядит в общем виде так: есть множество субъектов, достигающее нескольких тысяч, не желающее строить отношения на доверии; необходимо построить на DLT такое решение, которое будет работать на обычных ПК без специальных требований к производительности и обеспечивать пользовательский опыт не хуже любых централизованных систем учета. Технология, лежащая в основе решения, должна свести к минимуму возможность злонамеренных манипуляций с данными — именно поэтому здесь блокчейн.
Лозунги из whitepapers и СМИ обещают нам, что очередная разработка позволит совершать миллионы транзакций в секунду. Что же на самом деле?
Mainnet Ethereum сейчас работает со скоростью
30 tps. Уже только из-за этого его сложно воспринимать как сколько-нибудь пригодный для корпоративных нужд блокчейн. Среди permissioned-решений известны бенчмарки, показывающие 2000 tps (Quorum) или 3000 tps (Hyperledger Fabric, в публикации чуть меньше, но нужно учитывать, что бенчмарк проводился на старом consensus engine). Была попытка радикальной переработки Fabric, давшая не самые плохие результаты, 20000 tps, но пока это лишь академические изыскания, ждущие своей стабильной имплементации. Вряд ли корпорация, которая может себе позволить содержать отдел блокчейн-разработчиков, будет мириться с такими показателями. Но проблема не только в throughput, есть ещё latency.
Latency
Задержка от момента инициации транзакции до её окончательного утверждения системой зависит не только от скорости прохождения сообщения через все этапы валидаций и упорядочивания, но и от параметров формирования блока. Даже если наш блокчейн позволяет нам коммитить со скоростью 1000000 tps, но требует при этом 10 минут на формирование блока размером 488 Мб, станет ли нам легче?
Давайте посмотрим поближе на жизненный цикл транзакции в Hyperledger Fabric, чтобы понять, на что уходит время и как это соотносится с параметрами формирования блока.
взято отсюда: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane
(1) Клиент формирует транзакцию, отправляет на endorsing peers, последние симулируют транзакцию (применяют изменения, вносимые чейнкодом, на текущее состояние, но не коммитят в леджер) и получают RWSet — имена ключей, версии и значения, взятые из коллекции в CouchDB, (2) endorsers отправляют обратно клиенту подписанный RWSet, (3) клиент либо проверяет наличие подписей всех необходимых пиров (endorsers), а потом отправляет транзакцию на ordering service, либо отправляет без проверки (проверка все равно состоится позже), ordering service формирует блок и (4) отправляет обратно на все пиры, не только endorsers; пиры проверяют соответствие версий ключей в read set версиям в базе данных, наличие подписей всех endorsers и наконец коммитят блок.
Но это ещё не всё. За словами «ордерер формирует блок» скрывается не только упорядочивание транзакций, но и 3 последовательных сетевых запроса от лидера к фолловерам и обратно: лидер добавляет сообщение в лог, отправляет фолловерам, последние добавляют в свой лог, отправляют подтверждение успешной репликации лидеру, лидер коммитит сообщение, отправляет подтверждение коммита фолловерам, фолловеры коммитят. Чем меньше размер и время формирования блока, тем чаще придется ordering service устанавливать консенсус. В Hyperledger Fabric есть два параметра формирования блока: BatchTimeout — время формирования блока и BatchSize — размер блока (количество транзакций и размер самого блока в байтах). Как только один из параметров достигает лимита, выпускается новый блок. Чем больше нод ордереров, тем дольше это будет происходить. Следовательно, нужно увеличивать BatchTimeout и BatchSize. Но поскольку RWSet’ы версионируются, то чем больше мы сделаем блок, тем выше вероятность MVCC-конфликтов. К тому же, с увеличением BatchTimeout катастрофически деградирует UX. Мне кажется разумной и очевидной следующая схема для решения этих проблем.
Как избежать ожидания финализации блока и не потерять возможности отслеживания статуса транзакции
Чем больше время формирования и размер блока, тем выше пропускная способность блокчейна. Одно из другого прямо не следует, однако следует вспомнить, что установление консенсуса в RAFT требует трех сетевых запросов от лидера к фолловерам и обратно. Чем больше нод ордеров, тем дольше это будет происходить. Чем меньше размер и время формирования блока, тем больше таких интеракций. Как увеличивать время формирования и размер блока, не увеличивая время ожидания ответа системы для конечного пользователя?
Во-первых, нужно как-то решать MVCC-конфликты, вызванные большим размером блока, который может включать разные RWSet’ы с одной и той же версией. Очевидно, на стороне клиента (по отношению к блокчейн-сети, это вполне может быть бекенд, и я имею в виду именно его) нужен хендлер MVCC-конфликтов, который может быть как отдельным сервисом, так и обычным декоратором над инициирующем транзакцию вызовом с логикой retry.
Retry можно реализовать с экспоненциальной стратегией, но тогда latency будет деградировать так же экспоненциально. Так что следует использовать либо рандомизированный в определенных небольших пределах retry, либо постоянный. С оглядкой на возможные коллизии в первом варианте.
Следующий этап — сделать взаимодействие клиента с системой асинхронным, чтобы он не ждал 15, 30 или 10000000 секунд, которые мы установим в качестве BatchTimeout. Но при этом нужно сохранить возможность удостовериться в том, что изменения, инициированные транзакцией, записаны/не записаны в блокчейн.
Для хранения статуса транзакций можно использовать базу данных. Самый простой вариант — CouchDB из-за удобства использования: у базы есть UI из коробки, REST API, для неё легко можно настроить репликацию и шардирование. Можно создать просто отдельную коллекцию в том же инстансе CouchDB, который использует Fabric для хранения своего world state. Нам нужно хранить документы такого вида.
Этот документ записывается в базу до передачи транзакции на пиры, пользователю возвращается ID сущности (этот же ID используется в качестве ключа), если это операция создания чего-либо, а затем поля Status, TxID и Error обновляются по мере поступления релевантной информации от пиров.
В этой схеме пользователь не ждет, когда же наконец сформируется блок, наблюдая крутящееся колесико на экране 10 секунд, он получает моментальный отклик системы и продолжает работать.
Мы выбрали BoltDB для хранения статусов транзакций, потому что нам нужно экономить память и не хочется тратить время на сетевое взаимодействие с отдельно стоящим сервером базы данных, тем более когда это взаимодействие происходит по plain text протоколу. Кстати, используете вы CouchDB для реализации описанной выше схемы или просто для хранения world state, в любом случае имеет смысл оптимизировать способ хранения данных в CouchDB. По умолчанию в CouchDB размер b-tree узлов равен 1279 байт, что сильно меньше размера сектора на диске, а значит как чтение, так и перебалансировка дерева будет требовать больше физических обращений к диску. Оптимальный размер соответствует стандарту Advanced Format и составляет 4 килобайта. Для оптимизации нам нужно установить параметр btree_chunk_size равным 4096 в файле конфигурации CouchDB. Для BoltDB такое ручное вмешательство не требуется.
Backpressure: buffer strategy
Но сообщений может быть очень много. Больше, чем система способна обработать, разделяя ресурсы с десятком других сервисов кроме отраженных на схеме — и все это должно работать безотказно даже на машинах, на которых запуск Intellij Idea будет делом крайне утомительным.
Проблема разной пропускной способности сообщающихся систем, продьюсера и консьюмера, решается разными способами. Посмотрим, что мы могли бы сделать.
Dropping: мы можем заявить, что способны обрабатывать не более X транзакций за T секунд. Все запросы, превышающие этот лимит, сбрасываются. Это довольно просто, но про UX тогда можно забыть.
Controlling: у консьюмера должен быть некий интерфейс, через который он в зависимости от нагрузки сможет контролировать tps продьюсера. Неплохо, но это накладывает обязательства на разработчиков клиента, создающего нагрузку, реализовывать этот интерфейс. Для нас это неприемлемо, так как блокчейн в перспективе будет интегрирован в большое количество давно существующих систем.
Buffering: вместо того, чтобы ухищряться в сопротивлении входному потоку данных, мы можем буферизовать этот поток и обрабатывать его с необходимой скоростью. Очевидно, это лучшее решение, если мы хотим обеспечить хороший пользовательский опыт. Буфер мы реализовывали с помощью очереди в RabbitMQ.
В схему добавилось два новых действия: (1) после поступления запроса на API в очередь кладется сообщение с параметрами, необходимыми для вызова транзакции, и клиент получает сообщение о том, что транзакция принята системой, (2) бекенд с задаваемой в конфиге скоростью читает данные из очереди; инициирует транзакцию и обновляет данные в хранилище статусов.
Теперь можно увеличивать время формирования и вместимость блока настолько, насколько захочется, скрывая задержки от пользователя.
Другие инструменты
Здесь не было ничего сказано про чейнкод, потому что в нем, как правило, нечего оптимизировать. Чейнкод должен быть максимально простым и безопасным — это всё, что от него требуется. Писать чейнкод просто и безопасно нам сильно помогает фреймворк ССKit от S7 Techlab и статический анализатор revive^CC.
Кроме того, наша команда разрабатывает набор утилит для того, чтобы сделать работу с Fabric простой и приятной: блокчейн эксплорер, утилита для автоматического изменения конфигурации сети (добавление/удаление организаций, нод RAFT), утилита для отзыва сертификатов и удаления identity. Если хотите внести свой вклад — welcome.
Заключение
Этот подход позволяет легко заменить Hyperledger Fabric на Quorum, другие приватные Ethereum сети (PoA или даже PoW), существенно снизить реальную пропускную способность, но при этом сохранить нормальный UX (как для пользователей в браузере, так и со стороны интегрируемых систем). При замене Fabric на Ethereum в схеме нужно будет изменить только логику retry-сервиса/декоратора c обработки MVCC-конфликтов на атомарный инкремент nonce и повторную отправку. Буферизация и хранилище статусов позволили отвязать время отклика от времени формирования блока. Теперь можно добавлять тысячи нод ордеров и не бояться, что блоки формируются слишком часто и нагружают ordering service.
В общем-то, это всё, чем я хотел поделиться. Буду рад, если это кому-то поможет в работе.
Что такое Hyperledger Fabric платформа: преимущества и примеры
Содержание
Blockchain имеет огромный потенциал для изменения различных отраслей нашей жизни, и мы видим это уже прямо сейчас. С выбором революционной технологии вы берете на себя огромную ответственность за выбор структуры, на которой будете создавать свой блокчейн проект.
Введение: что такое 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, позволяют передавать данные только тем сторонам, которые должны их использовать.
Например, многие финансовые компании выражают обеспокоенность по поводу конкурентов, которые видят хотя бы количество обрабатываемых транзакций. Некоторые финансовые учреждения не считают криптографию «достаточной» мерой защиты своих данных. Каналы помогают обеспечить возможность разделения данных, где только те, кто должен знать данные, будут видеть количество транзакций и сами данные.
Смарт-контракты: Как и Ethereum, Fabric позволяет использовать смарт-контракты под названием «chaincode». Смарт-контракты разработаны на высшем уровне.
Например, возьмем случай с ипотечной компанией, использующей blockchain. Информация об ипотеке не может открыто публиковаться. Информация требует от сторон возможности идентифицировать себя в сети для проверки подлинности.
Постоянность сети
Децентрализованная среда представляет собой упорядоченную запись информации для приложения blockchain. Каждая транзакция приводит к набору ключа-значения, который привязан к регистру. Он может быть создан, обновлен или удален. Неизменяемый источник доверия для v1.0 добавляется в файловую систему узла, который также имеет встроенный модуль LevelDB.
LevelDB имеет по умолчанию базовую основу данных и поддерживает ключевые запросы, составные ключевые запросы и запросы диапазона ключей. Если вам нужны сложные, насыщенные запросы, CouchDB поможет вам и поддержит базовые возможности LevelDB, добавляя полные запросы, богатые данными запросы. При наличии дополнительной поддержки базы данных документов, такой как CouchDB, контент JSON становится полностью запрашиваемый, модель данных совместима с существующей моделью программирования ключей / значений. В результате всего этого изменение приложения не требуются при моделировании данных кодового кода как в JSON при использовании CouchDB.
Этот формат JSON помогает минимизировать работу, необходимую для создания простых отчетов и выполнения функций аудита. Например, в сценариях цепочки поставок вы можете использовать стиль документа JSON, чтобы отображать конкретные данные для товаров и транспортных объектов. Вы можете легко подготовить отчет о товарах для разных местоположений и транспортных объектов, которые были использованы при доставке в конечный пункт назначения товара.
Модульная архитектура, поддерживающая подключаемые компоненты
Hyperledger Fabric даёт возможность разработчикам создавать встраиваемые компоненты в свою архитектуру. Например, вы можете сжать какие то компоненты по мере необходимости и в один из самых быстрых способов.
Такая модульность обеспечивается благодаря своей прочной архитектуре, которая учитывает перспективы развития новой технологии blockchain. Это очень удобно, когда вы хотите получить доступ к системе, например, к пользовательской системе управления идентификационными данными, чтобы пользователи могли использовать платформу blockchain, построенную поверх Hyperledger Fabric.
Модульная архитектура: Fabric имеет модульную архитектуру и обеспечивает большую гибкость в зависимости от того, что вы хотите использовать.
Модульность архитектуры Hyperledger Fabric позволяет разработчикам сети использовать различные решения для компонентов, что является значительным преимуществом. Одной из наиболее востребованных областей модульности является идентификация узлов. В некоторых сетях с несколькими компаниями уже есть управление идентификацией и они хотят повторно использовать то что имеют, а не перестраивать. Другие компоненты архитектуры, которые могут быть легко подключены, включают в себя консенсус или шифрование.
Защита цифровых паролей и конфиденциальных данных
Поддержка 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 также ориентируется на корпоративных клиентов.
Существует Enterprise Ethereum, который был запущен в феврале 2017 года. В него входят более 30 компаний из списка Fortune 500, а также стартапы, ученые, поставщики технологий и эксперты Ethereum. В число участников входят BP, Cisco, Accenture, Intel и Toyota.
