hyperledger что это такое
Hyperledger: что это такое и какое значение имеет для блокчейна
Hyperledger не является блокчейном, но был создан Linux foundation в декабре 2015 года для продвижения технологии блокчейна. Проект представляет собой совместную работу по созданию открытой распределенной системы бухгалтерского учета (леджера), которая может быть использована для открытой разработки и внедрения блокчейн приложений и систем. Основной упор делается на создание и запуск платформ, которые поддерживают глобальные бизнес-транзакции. Проект также фокусируется на повышении надежности и производительности блокчейна.
Проекты в Hyperledger проходят различные этапы разработки: от идеи и ее проработки до активной работы и даже стагнации. Чтобы проект мог перейти от идеи на стадию инкубации, он должен иметь полностью действующую базу кода и активное сообщество разработчиков.
То есть, это не просто сайт, не проект на ICO, не блокчейн и не токены! Это что-то типа инструментов для разработки, принципов и примеров. Он не поддерживает какую-либо валюту.
Проекты Hyperledger
В настоящее время существует несколько проектов под куполом Hyperledger:
Ранние участники инициативы включали в себя поставщики ПО для блокчейне (Blockchain, ConsenSys, Digital Asset, R3, Onchain), известные технологические платформы (Cisco, Fujitsu, Hitachi, IBM, Intel, NEC, NTT DATA, Red Hat, VMware), финансовые компании (ABN AMRO, ANZ Bank, BNY Mellon, CLS Group, CME Group, DTCC, Deutsche Börse Group, JP Morgan, State Street, SWIFT, Wells Fargo), также компании SAP, Accenture, Calastone, Wipro, Credits, Guardtime, IntellectEU, Nxt Foundation, Symbiont.
Hyperledger Fabric
Fabric — это блокчейн-фреймворк, который изначально был предложен IBM и DAH (Digital Asset Holdings). Он предназначен для создания основы для разработки решений на блокчейне и основан на модульной архитектуре, где в случае необходимости могут быть подсоединены различные компоненты, например, алгоритм консенсуса. Умные контракты в Fabric называются chaincode. Сеть Hyperledger Fabric включает в себя «одноранговые узлы», которые выполняют блокчейн-код, данные регистров доступа, поддерживают транзакции и интерфейс приложений.
Fabric предназначена для проектов, в которых требуется технология распределенных регистров (DLT). Поддерживает chaincode в Go (Golang), Java и JavaScript (через Hyperledger Composer, или с версии 1.1) и, следовательно, потенциально более гибкий, чем язык смарт-контрактов.
Hyperledger Sawtooth
Sawtooth представляет собой модульную платформу, предложенную Intel в апреле 2016 года, с некоторыми ключевыми нововведениями. Основное внимание уделяется гибкому использованию в различных областях бизнеса с внедрением семейств транзакций и иного консенсуса.
Транзакции отделены от консенсусного уровня, используют для этого новую концепцию, называемую семействами транзакций. Вместо транзакций, которые индивидуально связаны с леджером, используются семейства транзакций, что обеспечивает большую гибкость и неограниченный дизайн бизнес-логики. Сделки следуют паттернам и структурам, определенным в семействах транзакций.
Intel также представили новый алгоритм консенсуса PoET, доказательство прошедшего времени. Протокол случайным образом выбирает победителя, правда денежного вознаграждения, как при майнинге, нет.
Распределенные регистры предоставляют цифровую запись (например, владение активами), которая поддерживается без центрального органа или реализации.
Iroha
Проект Iroha был предложен Soramitsu, Hitachi, NTT Data и Colu в сентябре 2016 года. Iroha стремится создать библиотеку повторно используемых компонентов. Базируется на Hyperledger Fabric, больше фокусируется на мобильных устройствах. Основная цель Iroha — дополнить другие проекты Hyperledger, предоставив повторно используемые компоненты, написанные на C ++. Этот проект также предложил новый алгоритм консенсуса под названием Sumeragi, который основан на византийской задаче. Iroha доступен по адресу https://github.com/hyperledger/iroha.
Различные библиотеки были предложены для Iroha. Вот некоторые из них:
Blockchain Explorer
Этот проект создает блокчейн-проводник для Hyperledger, который может использоваться для просмотра и запроса транзакций, блоков и связанных с ними данных цепочки. Он также дает информацию сети и возможность взаимодействия с кодом. Вообще, позволяет смотреть всю информацию на блокчейне.
Первоначально Hyperledger Explorer был предоставлен IBM, Intel и DTCC.
Под куполом есть и другие действующие проекты, которые также носят прикладной и более конкретный характер.
Hyperledger как протокол
Hyperledger нацелен на создание новой платформы. Постепенно Blockchain Hyperledger превращается в протокол для деловых транзакций. Hyperledger опубликовали эталонную архитектуру, таким образом заявив о попытке стандартизировать отрасль.
Эталонная архитектура может служить ориентиром для создания блокчейн-платформ. Она состоит из двух основных компонентов: служб Hyperledger и API Hyperledger, SDK и CLI.
Старый пример, компания активно развивается
Основное требование Hyperledger — это модульная структура. Разные службы должны подключаться и воспроизводиться, и пользователи должны иметь возможность легко удалить и добавить модуль в соответствии со спецификой своего бизнеса.
Также конфиденциальность транзакций и смарт-контрактов имеют первостепенное значение. Hyperledger предоставляет широкий спектр криптографических протоколов и алгоритмов, которые можно выбрать и внедрить без ущерба для производительности.
Также требуется гибкая модель PKI (инфраструктуры открытых ключей), которая может использоваться для управления функциями контроля доступа. Ожидается, что сила и тип криптографических механизмов будут варьироваться в зависимости от потребностей пользователей.
Возможность аудита — еще одно требование. Ожидается, что сохраняется неизменяемый контрольный журнал всех идентификационных данных, связанных операций и любыми изменениями.
Должен быть общий набор стандартов, которым могут следовать все блокчейны, чтобы обеспечить связь между разными проектами. Предполагается, что Hyperledger будет переносимым не только на уровне инфраструктуры, но и на уровне кода, библиотек и API.
Использование 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.
Сравнение корпоративных блокчейнов: Corda vs Hyperledger Fabric
👉🏻 Мы разрабатываем блокчейн-технологии для стартапов и бизнеса
Блокчейн в настоящее время является наиболее быстро развивающейся технологией. На рынке существует ряд структур блокчейна, включая Ethereum, Fabric, Corda, Indy и Quorum, и многие другие, похоже, выходят почти ежедневно. В этой статье мы глубоко погрузимся и проанализируем две популярные платформы для корпоративных решений на основе блокчейна: Corda и Hyperledger Fabric.
Corda-это блокчейн-платформа с открытым исходным кодом, которая упрощает управление юридическими контрактами и другой общей информацией между взаимно доверяющими сторонами. Corda изначально была разработана для применения в финансовых учреждениях. Существует также его коммерческое издание – Corda Enterprise. Corda Enterprise расширяет выпуск Corda и поддерживает дополнительные функции, включая поддержку коммерческих баз данных (Oracle, MSSql), HSM, повышение производительности (выполнение параллельного потока), настройку узлов высокой доступности и инструменты для развертывания сети Corda.
Что такое Hyperledger Fabric?
Hyperledger Fabric-это блокчейн-платформа с открытым исходным кодом, которая позволяет разрабатывать продукты, решения и приложения на основе блокчейна.
Corda против Fabric: сравнение
Обе платформы являются частными блокчейнами, которые обеспечивают строгий контроль доступа к данным – важная функция для большинства корпоративных приложений. В целом, они могут обрабатывать намного больше транзакций в секунду, чем публичные блокчейны.
Аутентификация/авторизация для обеих платформ основана на модели инфраструктуры открытых ключей (PKI) и сертификатах X. 509. Инфраструктура PKI — это технология аутентификации пользователей с помощью цифровой идентификации, основанная на криптографии с открытым ключом. Цифровая идентификация пользователя создается доверенной стороной, называемой центром сертификации (CA). Центр сертификации использует свой ключ для создания сертификата X. 509 – документа, который сопоставляет открытый ключ пользователя с его личностью.
Fabric. Каждая организация в сети имеет свой собственный центр сертификации и может полностью контролировать выдачу и аннулирование удостоверений личности. Кроме того, они могут добавлять пользовательские атрибуты в сертификаты X. 509, чтобы получить более подробные политики авторизации на уровне смарт-контракта. Структура использует концепцию поставщика услуг членства (MSP). MSP проверяет, имеет ли определенный сертификат удостоверения разрешение на работу в сети, и связывает удостоверение пользователя с ролью, такой как администратор, клиент или одноранговый узел (подтверждающий транзакцию). Пользователю не нужно размещать узел для запроса или изменения данных; требуются только действительные сертификаты и ключи. Клиенты приложений могут владеть своими закрытыми ключами и подписывать транзакцию из мобильного приложения, браузера или настольного компьютера, не раскрывая свой ключ третьей стороне.
Corda. Сертификат узла получается через службу идентификации сети. Прежде чем какой-либо узел или организация присоединится к сети, необходимо отправить запрос на присоединение. Служба идентификации несет ответственность за проведение проверки «Знай своего клиента» (KYC). Организация может присоединиться к сети только после того, как запрос будет одобрен службой идентификации. Служба идентификации действует как корневой центр сертификации для сети. Изначально Corda была разработана для финансовых учреждений (например, для взаимодействия между банками), поэтому идея заключалась в том, что у каждого участника должен быть развернутый узел. Однако это не всегда жизнеспособно. В сценариях B2C пользователю может потребоваться отдельная учетная запись для каждого клиента, и сложно иметь отдельный работающий узел для каждого из них. Пакет SDK для учетных записей был добавлен, чтобы позволить иметь много пользователей на одном узле и сделать структуру более обобщенной. Этот подход имеет определенные ограничения, так как закрытые ключи пользователей хранятся на узле. Это делает фреймворк неприменимым в ситуациях, когда пользователь должен полностью контролировать свои учетные данные.
Fabric более гибка, чем Corda, в отношении управления идентификацией. Это позволяет пользователям владеть своими идентификационными ключами без необходимости размещения узла блокчейна. Владение ключами может быть полезно в некоторых случаях, когда пользователю необходимо иметь полный контроль над своими данными, такими как цифровая идентификация или электронные медицинские записи. В отличие от этого, ключи Corda всегда хранятся на узле блокчейна.
В структуре удостоверение пользователя привязано к сертификату. Это позволяет создавать детализированные правила доступа в цепном коде с помощью атрибутов сертификата. Каждому сертификату может быть назначена роль или любые пользовательские атрибуты. В учетных записях Corda правила доступа должны быть реализованы на уровне приложений. Учетные записи – это просто открытые ключи, поэтому у вас нет возможности настраивать правила доступа в смарт-контракте.
Отказоустойчивость к сбоям (CFT) – этот протокол повышает отказоустойчивость системы в случае, если некоторые участники недоступны. Обычно это группа сторон, которые могут действовать, если с некоторыми из сторон не удалось связаться. Обычно реализация CFT основана на протоколе RAFT.
Византийская отказоустойчивость (BFT) – этот протокол работает в ненадежных средах, где в системе присутствуют злоумышленники. Для этого требуется группа сторон, не пользующаяся взаимным доверием, чтобы договориться об управлении. BFT работает медленнее, чем протокол CFT.
Fabric. Существует уникальный поток для достижения консенсуса, основанный на архитектуре транзакций Fabric: Выполнение-Заказ-Проверка. Этапы выполнения и проверки выполняются одноранговым компонентом; у каждой организации в сети есть свой собственный одноранговый узел. Компонент «Заказчик» выполняет этап заказа. На этапе выполнения одноранговый партнер организации выполняет смарт-контракты, определяет изменения, устанавливает и подтверждает правильность изменений. Пакеты фазы заказа упорядочивают транзакции в блок и доставляют их на узлы организации для проверки. На этапе проверки проверяется, что все необходимые участники одобрили транзакцию и что набор изменений еще не был изменен предыдущими транзакциями, чтобы предотвратить двойные расходы. Единственное место, где могут быть применены протоколы CFT или BFT, — это фаза заказа. В случае, если злоумышленник получит контроль над компонентом orderer, он может пропустить обработку определенных транзакций, выборочно доставлять блоки организациям или даже отправлять разные блоки в разные организации, чтобы нарушить глобальное состояние. Протокол BFT может устранить эти уязвимости. Даже без BFT на месте все равно невозможно выполнить атаку с двойными расходами. На данный момент только протокол CFT готов к производству. BFT остается в стадии разработки.
Corda. Нет глобального состояния, и данные передаются между контрагентами. Каждая сторона, совершающая сделку, получает историю состояния и проверяет ее достоверность. Еще одним компонентом является нотариус, который проверяет, не потребляла ли уже другая транзакция определенное состояние, чтобы обнаружить двойные расходы. Стоит подчеркнуть, что нотариус – это единственный компонент, используемый для проверки двойных расходов. Нотариус может быть действительным и недействительным. Проверяющий нотариус проверяет как правильность истории транзакций, так и двойные расходы. Нотариус, не подтверждающий подлинность, проверяет только двойные расходы. Проверяющий нотариус ставит под угрозу безопасность, получая доступ к данным. Неподтверждающий нотариус не имеет доступа к данным, но уязвим для атаки типа «отказ в доступе» — злоумышленник может притвориться, что изменил состояние другого узла, что приведет к ошибке проверки с двойными затратами. В настоящее время не существует готовой к производству реализации ни для CFT, ни для BFT, хотя Corda Enterprise имеет режим настройки высокой доступности для решения проблем отказоустойчивости, как это делает CFT.
Обе платформы не имеют готовой к производству реализации протокола BFT. Отсутствие реализации BFT в Corda создает гораздо более высокие риски для безопасности, чем в Fabric, из-за возможности того, что злоумышленник получит контроль над компонентом нотариуса и выполнит атаку с двойным расходованием.
Конфиденциальность является важнейшим аспектом корпоративных приложений. Важно знать, кто и когда внес изменения, и быть уверенным, что только авторизованные пользователи и организации могут видеть эти данные.
Структура. Существует две концепции разделения данных: каналы и частные коллекции данных (pDCs). Каналы – это частная сеть, доступная только приглашенным участникам, поэтому никто другой не может получить доступ к данным внутри. Узел может быть присоединен ко многим каналам одновременно. PDC позволяют обмениваться информацией только определенным участникам или организациям в рамках одного канала; доступ к данным может предоставляться статически во время установки смарт-контракта или динамически во время выполнения. Частные коллекции данных никогда не раскрывают исходные данные компоненту заказа для создания блоков. Данные реплицируются непосредственно между участвующими одноранговыми узлами. Все остальные могут видеть только хэш данных. Это обеспечивает доказательство существования данных, но они никогда не смогут узнать, что это за данные. В Fabric возможно создавать анонимные удостоверения. Это обеспечивает несвязываемость и выборочное раскрытие атрибутов путем создания доказательств с нулевым знанием (ZKPs). К сожалению, данная функция больше не находится в активном развитии. На данный момент на стороне клиента поддерживается только Java SDK, и только Go SDK поддерживается для chaincode. Отзыв удостоверений не поддерживается, и вы не можете раскрывать пользовательские атрибуты, только роль и имя подразделения организации. Это сильно ограничивает ситуации, в которых эта функция может быть использована. Например, анонимные удостоверения не могут использоваться для подписи транзакций в браузере. Сбор личных данных в сочетании с их идентификаций скрывает как личность, так и сведения об активах.
Corda. Эта структура стоит особняком от большинства блокчейн-решений, поскольку у нее нет глобального состояния. Данные передаются и проверяются от узла к узлу по мере необходимости. Данные могут быть видны компоненту нотариуса, если он является проверяющим нотариусом. Будущим владельцам активов необходимо проверить полную историю транзакций с момента выпуска актива, чтобы они могли видеть все данные истории транзакций. Существуют методы обеспечения конфиденциальности личных данных, такие как переоформление состояния (для удаления истории передачи активов), разрыв транзакции (для сокрытия некоторых частей транзакции) и анонимные удостоверения. Тем не менее, по-прежнему важно тщательно рассмотреть вопрос о том, кто может иметь доступ к данным. Анонимные удостоверения личности (или, в Corda, конфиденциальные удостоверения личности) позволяют пользователям явно предоставлять идентификационные данные только контрагентам по сделке, скрывая идентификационные данные при проверке истории. Ключи для анонимных удостоверений создаются для каждой транзакции, поэтому их невозможно отследить. SDK для учетных записей Corda также основан на анонимных удостоверениях. Сведения о счетах должны быть явно разделены между контрагентами. Конфиденциальные данные Corda сохраняют конфиденциальность личности пользователя, но не сведений об активе (например, сумма денег или адрес недвижимости). В настоящее время ведется расследование доказательств отсутствия знаний (ZKPS) и/или доверенных сред выполнения (TE), которые позволяют проверять транзакции без раскрытия содержимого, хотя до готовности к производству еще далеко.
Транзакции Corda по умолчанию являются закрытыми. Конфиденциальные учетные данные позволяют скрывать личность от будущих владельцев активов. Структура позволяет пользователям явно настраивать конфиденциальность через каналы или частные коллекции данных. Это усложняет управление сетью, особенно когда в ней много участников, но обеспечивает четкий контроль над тем, кто может получить доступ к данным. Какой подход лучше, зависит от конкретного случая использования.
Управление – это система правил и практик, которые контролируют сеть и ее участников. Обычно есть сетевой администратор с правом добавлять новых участников. Это позволяет масштабировать по горизонтали, так как каждый заказчик может быть добавлен в другой канал. Каждый канал управляется политиками, которые определяют, могут ли все организации, большинство организаций или только отдельные организации утверждать изменения (например, добавлять новых участников в канал). Каждая организация несет ответственность за подготовку своих администраторов. Администраторы каналов отвечают за управление потоком установки смарт-контрактов. Прежде чем смарт-контракт может быть установлен или обновлен, он должен быть одобрен необходимым количеством администраторов организации.
Fabric. Сетевая структура управляется несколькими организациями. Существуют организации-заказчики и консорциум прикладных организаций. Организации приложений могут создавать различные каналы приложений с различными наборами участников. В первые дни Fabric организации-заказчики контролировали, кто может присоединиться к консорциуму, и все каналы подачи заявок были подключены к группе организаций-заказчиков. С помощью Fabric 2.3 теперь можно создать канал подачи заявок и выборочно присоединяться к организациям отдельных заказчиков. Это позволяет масштабировать по горизонтали, так как каждый заказчик может быть добавлен в другой канал. Каждый канал управляется администраторами, которые определяют, могут ли все организации, большинство организаций или только отдельные организации утверждать изменения (например, добавлять новых участников в канал). Каждая организация несет ответственность за подготовку своих администраторов. Администраторы каналов отвечают за управление потоком установки смарт-контрактов. Прежде чем смарт-контракт может быть установлен или обновлен, он должен быть одобрен необходимым количеством администраторов организации.
Администратор сети отвечает за внедрение новых организаций и настройку параметров сети. Администраторы организации управляют конфигурацией узла и участвуют в процессах смарт-контрактов, потоковой установки и обновления (в явном режиме). Существует возможность создания отдельной сети в сети Corda. Это позволяет иметь настраиваемого нотариуса, скрывать участников и управлять конфигурацией подсети, сохраняя возможность подключения к глобальным сетям в будущем. Corda позволяет создавать бизнес-сеть – логическую подсеть в сети Corda. Администраторы бизнес-сети могут утверждать новые роли, назначать их участникам или удалять. Участники глобальной сети не знают об участниках бизнес-сети. Можно создать ветку, который позволяет общаться друг с другом только участникам бизнес-сети.
Управление Corda более централизовано, поскольку единая организация контролирует узлы, подключение и конфигурацию сети. В Corda узел может участвовать только в одной сети. По умолчанию пользователи могут взаимодействовать с каждым узлом в сети, как только у них установлен смарт-контракт. Они могут явно запретить другому узлу взаимодействовать с их узлом или иметь более детальный доступ через бизнес-сеть Corda.
Структура управления Fabric позволяет создавать и определять каналы, в которых участники совместно контролируют конфигурацию сети и управление смарт-контрактами. Обе платформы могут просматривать и утверждать новые версии смарт-контрактов перед обновлением.
Важно учитывать, насколько легко найти новых разработчиков для продукта и сколько времени может потребоваться новичкам, чтобы работать на полную мощность.
Fabric. Существует новая архитектура для выполнения транзакций – Выполнение-Заказ-Проверка, которая устраняет недетерминизм в транзакции. В результате для разработки смарт-контрактов можно использовать любой стандартный язык программирования. В настоящее время, Go, Java и Node.js поддерживаются. Существуют также библиотеки SDK, написанные на Go, Java, Node.js и Python. Хотя кажется полезным использовать так много разных языков, может быть трудно найти разработчика, который знает как структуру, так и один из поддерживаемых языков одновременно. В целом работа со смарт-контрактами Fabric напоминает разработку сервисов API, где пользователи проверяют входные параметры, форматируют данные и выполняют чтение/запись в хранилище. Авторизация и одобрение могут быть определены декларативно во время установки цепного кода или на уровне кода.
Corda. Архитектура транзакций требует, чтобы выполнение кода было детерминированным. Для достижения детерминизма используется модифицированная виртуальная машина Java. Основными языками программирования в Corda являются Kotlin и Java. В отличие от других реализаций блокчейна, смарт-контракт в Corda состоит из трех блоков: состояние, функция контракта и поток. Состояние – это данные смарт-контракта. Функция контракта проверяет, являются ли изменения состояния допустимыми. Поток отвечает за инициирование связи между сторонами, создание состояния ввода/вывода, проверку действительности изменения состояния и сбор всех необходимых подписей от контрагентов. Существуют различные встроенные потоки для проверки транзакции, сбора необходимых подписей и нотариального заверения транзакции. Понимание всех библиотек SDK Corda может занять много времени.
Кривая обучения относительно одинакова для обеих систем.
Из-за распределенного характера блокчейна развертывание новой частной сети не является тривиальной задачей. Рамки развертывания блокчейна далеки от совершенства, и часто пользователи в конечном итоге разрабатывают свои собственные решения.
Fabric. Существует множество взаимодействующих компонентов, предоставляемых в виде контейнеров docker, и пользователи сами должны создать рабочее решение из этих частей. В 2021 году все еще есть компании, осуществляющие развертывание производства с помощью сценариев образцов. Эти сценарии отлично подходят для обучения, но они не соответствуют критериям высокой доступности и надежности решений. Существует множество различных платформ развертывания, созданных для облегчения жизни либо с помощью Hyperledger, либо с помощью сообщества с открытым исходным кодом. Однако они все еще далеки от идеала, поэтому вполне вероятно, что для поддержки сетевого развертывания потребуется хороший инженер-разработчик DevOps. Блокчейн-платформа IBM в настоящее время является наиболее зрелой платформой развертывания.
Corda. Есть два основных варианта: присоединиться к существующей общедоступной сети Corda или создать частную сеть. Сеть Corda — это общедоступная сеть узлов Corda, и цель состоит в том, чтобы создать единую глобальную сеть для всех. Поскольку у Corda нет глобального состояния, а данные передаются по мере необходимости, добавление дополнительных узлов не влияет на общую производительность сети. Однако узел должен быть открыт для доступа в общедоступный Интернет, что может оказаться труднодостижимым для некоторых строго регулируемых предприятий. Существует возможность создать свою собственную сеть. Для этого в Corda Enterprise есть инструмент управления сетью. В качестве альтернативы, существует бесплатная реализация сетевого картографического сервиса/швейцара, предоставляемая сообществом Cordite, с более ограниченным набором функций – без поддержки HSM, без потоков для утверждения новых запросов пользователей и т.д.
Развертывание и управление сетью как на Fabric, так и на Corda — непростая задача. С Corda есть отличная возможность присоединиться к сети Corda, где вам нужно будет развернуть только свой узел. Структура не имеет глобальной сети и обычно требует развертывания новой сети для каждого варианта использования.
В будущем, если у большинства компаний будет развитая инфраструктура, это будет проще. Если пользователям необходимо развернуть частную сеть для Corda, усилия по развертыванию будут аналогичными как для Fabric, так и для Corda. Еще один момент, о котором стоит упомянуть, заключается в том, что использование структуры включает в себя гораздо большее управление сертификатами. В Fabric каждый участник сети, включая клиентов и сетевые компоненты, имеет свой собственный сертификат. Это требует тщательной разработки потоков истечения срока действия и отзыва сертификатов как для конечных пользователей, так и для компонентов приложения. В Corda вам нужно только позаботиться об удостоверении узла и сертификате TLS.
Токенизация – это процесс, который преобразует активы (недвижимость, акции, фиатные деньги) в цифровое представление. Это позволяет легко создавать новые рынки для любого возможного типа активов. В основном он используется в финансовых учреждениях, недвижимости, цифровой валюте и т.д.
Существует два типа токенов: взаимозаменяемые (акции, опционы, цифровая валюта) и незаменяемые (недвижимость, произведения искусства, бриллианты, права на землю). Взаимозаменяемые токены в качестве представления цифровой валюты обычно интенсивно обмениваются, и эффективность этого решения должна быть тщательно продумана.
Кроме того, существует два популярных подхода к управлению состояниями цифровых токенов – учетная запись и вывод неизрасходованных транзакций (UTXO).
Модель учетной записи используется в Ethereum. Это похоже на сеть банковских счетов, где у каждого пользователя есть учетная запись, а перевод денег — это процесс вычитания суммы с одного счета и перемещения ее на другой счет. Это относительно простое решение, хотя оно снижает производительность для активно используемых учетных записей, поскольку вы можете обновлять информацию только для одной учетной записи за раз.
Модель UTXO используется в биткойне. Это похоже на бумажные деньги в вашем кошельке. Если пользователь хочет дать кому-то 50 долларов, ему нужно достать необходимые купюры из своего кошелька и отдать их другому человеку. Если у пользователя есть только банкнота в 100 долларов, транзакция обменяет ее на две купюры по 50 долларов, передаст одну другому лицу, а другую отдаст пользователю в качестве сдачи. В целом, модель UTXO может обеспечить более высокую пропускную способность, так как можно параллельно выбирать разные банкноты для разных транзакций. Однако модель UTXO сложнее в разработке.
Fabric. В настоящее время в структуре Fabric отсутствует библиотека токенов. Были планы добавить альфа-версию FabToken, но она была отложена. На данный момент можно реализовать пользовательский токен либо с использованием модели учетной записи, либо стандарта ERC20. Важно помнить об ограничениях производительности: то, что хорошо работает в Ethereum с его примерно 15 транзакциями в секунду, может плохо работать с Fabric с ее сотнями транзакций в секунду. Модель UTXO может быть реализована в Fabric, хотя это не было бы тривиальной задачей.
Corda. Поскольку блокчейн изначально был разработан для финансовых учреждений, у Corda уже есть SDK для токенов для взаимозаменяемых и несменяемых токенов. Состояние Corda основано на модели UTXO. Он предоставляет библиотеки для сбора необходимого количества токенов, и сбор токенов может выполняться параллельно для одновременного умножения различных транзакций.
Corda имеет встроенный пакет SDK для токенов, предназначенный для эффективного управления как взаимозаменяемыми, так и несменяемыми токенами. Модель состояния Corda основана на UTXO, что позволяет параллельно обрабатывать транзакции токенов. Например, магазин электронной коммерции может получать большое количество транзакций в секунду, при этом каждая транзакция обновляет свой баланс. Модель Corda UTXO справится с этим делом более эффективно, чем модель состояния учетной записи. В настоящее время Fabric не имеет встроенного пакета SDK для токенов. Единственный вариант для пользователей – создать свой собственный.
Блокчейн – это распределенная бухгалтерская книга с историей записей об изменениях активов.
Fabric. Структура книги состоит из двух компонентов: блокчейна и мирового состояния. Блокчейн – это журнал транзакций, который записывает все исторические изменения, внесенные в актив, и реализуется в виде файла. Мировое состояние содержит текущее состояние актива, которое реализовано в виде базы данных. Существует два варианта хранения мирового состояния: база данных LevelDB и база данных CouchDB; обе они не являются базами данных SQL. CouchDB предоставляет более расширенные возможности запросов. Хотя существует ограничение, препятствующее эффективным запросам, схему вложенных объектов использовать не следует, так как это увеличивает количество ошибок параллелизма записи. Поскольку это не SQL, существуют очень ограниченные возможности для объединения различных типов документов. Поэтому лучше разработать схему данных, более ориентированную на запись, и для сложных запросов использовать автономное хранилище. Таким образом, можно преобразовать и переместить данные во внешнее хранилище в формате, более подходящем для сложных запросов.
Corda. Данные главной книги не передаются глобально. Каждый узел содержит только данные, относящиеся к владельцу узла. Данные хранятся в реляционной базе данных. Сообщество Corda имеет поддержку H2 и Postgres. Corda Enterprise поддерживает еще больше баз данных: Azure SQL, SQL Server, Oracle и PostgreSQL. Это означает, что можно хранить данные главной книги в существующей базе данных и использовать все возможности реляционных баз данных для запроса и объединения данных как из главной книги, так и из приложения.
Corda позволяет работать с реляционными базами данных. Это дает явные преимущества при разработке сложных запросов и даже при объединении данных главной книги с данными приложений. Структура поддерживает только базы данных без SQL, и существуют ограниченные возможности для эффективного проектирования ее структуры как для чтения, так и для записи таким образом, чтобы избежать конфликтов параллелизма. При наличии сложной схемы активов лучше разработать хранилище структуры для запросов только на запись и использовать автономную базу данных для запросов.
В некоторых случаях вам необходимо улучшить смарт-контракт с помощью вложенных файлов, таких как юридическое соглашение, прилагаемое к контракту для облегчения разрешения споров, pdf-файл счета или источники кода контракта.
Fabric. Хотя вы потенциально можете хранить файлы внутри книги структуры, это категорически не рекомендуется, так как это резко влияет на производительность приложения. Рекомендуется, чтобы в книге сохранялись только хэши файлов. Если необходимо сохранить вложение, связанное со смарт-контрактом, необходимо будет реализовать пользовательское автономное хранилище.
Corda. Вложения поддерживаются как часть потока транзакций. Файл может быть загружен и прикреплен к любому смарт-контракту. Кроме того, можно проверить содержимое вложений во время выполнения транзакции. В случае Corda существуют некоторые ограничения на размеры файлов, поэтому это может оказаться не лучшим вариантом для больших видео или клинических фотографий.
Corda имеет встроенную поддержку вложений, что означает возможность реализации потоков управления документами или прикрепления счетов-фактур к смарт-контракту. Это сэкономит время, затрачиваемое на внедрение внешнего хранилища файлов. Ткань не имеет встроенной поддержки крепления.
Блокчейн-оракул – это внешняя служба, которая предоставляет смарт-контракты с данными вне цепочки. Смарт-контракты по своей конструкции должны быть детерминированными, и они не должны напрямую обращаться к внешним сервисам, поскольку данные могут очень часто меняться, что не позволяет участникам достичь консенсуса. оракул создает прокси-сервер между смарт-контрактами и внешними данными. Внешняя информация может быть любой, например, курсы обмена валют, результаты спортивных мероприятий или календарь наличия свободных мест в отелях.
Fabric. В Fabric нет реализации службы оракулов. Однако структура достаточно гибка, чтобы обеспечить подобную реализацию. У вас может быть отдельная организация с собственным интеллектуальным контактом, действующая как служба оракулов. Только организация оракула может записывать данные, а все остальные могут их читать. Таким образом, смарт-контракт оракула может быть вызван из смарт-контракта клиента. Подпись организации оракула может быть включена в смарт-контракт клиента с помощью политики одобрения.
Corda. Архитектура Corda имеет пакет SDK для создания службы оракулов. Поток транзакций может взаимодействовать со службой оракулов для подписания, чтобы убедиться, что все правильно. Архитектура Corda поддерживает отключение транзакций для фильтрации частей транзакции, которые оракулам не нужны для проверки данных. Разрыв транзакции основан на древовидной структуре Merkle.
Corda имеет встроенную поддержку оракула, предлагающую возможность отрывать конфиденциальные части транзакции до проверки данных. Fabric же требует специальной реализации оракула.
Сравнение производительности блокчейн-фреймворков — непростая задача. Результаты производительности зависят от количества узлов, топологии сети, задержки в сети, размера полезной нагрузки и базового хранилища базы данных. Обычно официальные показатели производительности собираются в оптимальных условиях: высокопроизводительный ПК с 32/64 ГБ оперативной памяти и 8/16 ядрами процессора, тесно связанными компонентами для обеспечения минимальной задержки и минимального разумного количества узлов. В результате производственное развертывание может быть медленнее, чем предусмотренные контрольные показатели производительности, поэтому всегда лучше проводить тестирование производительности в среде, в которой будет использоваться платформа.
Fabric. Существует рабочая группа по производительности и масштабированию Hyperledger, которая руководит процессом стандартизации тестирования производительности для Hyperledger. Эта группа разрабатывает ключевые показатели и основные условия для оценки эффективности. Группа создала тест с использованием суппорта Hyperledger, инструмента, предназначенного для тестирования производительности блокчейн-фреймворков. Тестируемая топология системы относительно проста. Она состоит из двух одноранговых узлов и одного компонента-заказчика, где одноранговые узлы принадлежат разным организациям. Сценарий тестирования по умолчанию заключается в записи ресурсов в хранилище. Вы можете получить результаты тестов как для Go, так и для JavaScript здесь. Существуют определенные критерии, влияющие на производительность структуры: репликация глобального состояния и общее количество узлов, количество подписчиков, топология и конфигурация кластера заказчиков, количество организаций, сложность кода цепочки и используемый язык. В общем, чем сложнее сеть, тем она медленнее. База данных LevelDB работает быстрее, чем CouchDB, а цепной код, написанный в Go, должен быть быстрее, чем код, написанный на JavaScript.
Corda. Производительность Corda тесно связана с версией Corda Enterprise, так как версия для сообщества имеет определенные ограничения. В версии сообщества узел может обрабатывать только один поток за раз. В корпоративной версии параллелизм потоков может быть увеличен, что значительно повышает производительность одного узла.Corda Enterprise поддерживает MSSql, Oracle и PostgreSQL. Версия сообщества также поддерживает PostgreSQL, который должен масштабироваться намного лучше, чем база данных H2 по умолчанию. Следует учитывать, что контрольные показатели для версии Corda для сообщества были собраны для хранения H2. Сценарий тестирования по умолчанию – выдача токенов и многократная передача токенов с одного узла на другой. Более подробную информацию о тестах Corda Enterprise можно найти здесь.
Основное различие между Corda и большинством других реализаций блокчейна заключается в том, что нет глобальной репликации состояний, а это означает, что потенциально нет ограничений на размер сети. Тем не менее, существуют определенные узкие места, такие как нотариальное заверение транзакций (с которым можно справиться, добавив в сеть больше нотариусов), сложность потока, увеличивающая количество обходов сетевого взаимодействия, и длительность истории состояний, влияющая на время транзакции, поскольку все изменения состояния должны быть воспроизведены контрагентам для проверки.
Главное преимущество Corda заключается в том, что она не имеет глобальной репликации состояний. Теоретически, можно создать единую глобальную сеть для всех организаций без штрафных санкций за производительность. По-прежнему можно измерить производительность для каждого отдельного узла в сети. Тестовые примеры по умолчанию из предоставленной эталонной производительности относительно похожи (если мы используем цепной код Fabric Go).
Corda против Hyperledger Fabric: примеры использования во всех отраслях промышленности
Обе структуры подходят для этих случаев. Corda имеет преимущества благодаря присущей ей конфиденциальности данных, поскольку данные не передаются по всему миру. В Corda конфиденциальные данные могут использоваться для сокрытия данных предыдущих владельцев. Однако сведения об активах по-прежнему будут видны будущим владельцам. В Fabric пользователям может потребоваться создать несколько каналов или частных коллекций для каждого частного сотрудничества, что усложняет управление сетью. При использовании частных коллекций данных можно использовать миксер удостоверений, чтобы скрыть личность создателя транзакции.
Corda поставляется со множеством встроенных компонентов: SDK для токенов, вложения для юридической прозы и счетов-фактур, а также оракулы для получения данных в режиме реального времени. Разработчику необходимо предоставить пользовательскую реализацию этих функций в Fabric.
Обе структуры должны хорошо работать в случаях использования цепочки поставок для отслеживания происхождения и перемещения активов. В некоторых случаях может потребоваться хранить цены на активы в блокчейне и скрывать цены от определенных участников. Например, оптовый торговец не хотел бы показывать розничному торговцу, сколько он заплатил производителю за товары.
В этом случае Fabric предлагает возможность обновлять частные и общедоступные данные в одной и той же транзакции, поэтому изменения в собственности активов видны всем, но цены видны только между продавцом и покупателем. В Corda цены и движение активов в одной транзакции будут видны всем участникам, поэтому необходимо будет разделить смену владельца активов и обмен деньгами на разные транзакции.
Поток страхового бизнеса обычно включает в себя личное общение между различными сторонами. Застрахованный создает претензию для страховщика, и страховщик проверяет претензию через третьих лиц, таких как больница или полиция. Обычно эти взаимодействия осуществляются один на один и не передаются другим участникам сети. Corda обеспечивает такую конфиденциальность по умолчанию. В Fabric необходимо явно определить эти частные отношения.
Структура может быть полезна в случаях использования, требующих высокой прозрачности между всеми участниками, поскольку она имеет общее глобальное состояние. То же самое можно реализовать в Corda, но для этого требуется явный обмен информацией между каждой заинтересованной стороной.
В последние годы конфиденциальности персональных данных уделяется значительное внимание. В Европе было принято Общее положение о защите данных (GDPR) для защиты анонимности пользователей, их несвязанности и их права быть забытыми. В настоящее время ни Fabric, ни Corda не соответствуют требованиям GDPR. Вся личная информация должна храниться вне сети. Как это часто бывает при сравнении двух зрелых фреймворков, определить победителя не так просто. Короткий ответ на вопрос о том, какую структуру выбрать, заключается в том, что это зависит от обстоятельств. Fabric могла бы охватывать более возможные варианты использования. Это похоже на Lego: пользователи могут брать кирпичи и создавать любую конструкцию, которую они хотят.
Обе платформы могут обеспечить анонимность и отсутствие связи, если учетные данные частного пользователя хранятся на стороне сервера. Corda не позволяет хранить учетные данные на стороне клиента. Fabric позволяет подписывать транзакции на стороне клиента, но анонимные учетные данные доступны только для Java SDK, поэтому вы не можете использовать эту функцию в браузере или на iPhone.
Эти ограничения делают обе платформы частично применимыми для определенных случаев использования. Они могут не работать там, где необходимо сохранить полную анонимность и учетные данные должны храниться на стороне клиента.
В таких случаях может потребоваться интеграция с Hyperledger Indy. Indy предназначен для управления цифровыми удостоверениями личности и соответствует требованиям GDPR. В целом, Fabric предоставляет больше возможностей для управления удостоверениями. Это позволяет регистрировать личность и подписывать транзакции на стороне клиента, а также позволяет создавать сертификаты с пользовательскими атрибутами для улучшения процессов проверки транзакций и контроля доступа.
Как это часто бывает при сравнении двух зрелых фреймворков, определить победителя не так просто. Короткий ответ на вопрос о том, какую структуру выбрать, заключается в том, что это зависит от обстоятельств. По итогу fabric могла бы охватывать более возможные варианты использования. Это похоже на Lego: пользователи могут брать кирпичи и создавать любой опыт, который они хотят. Fabric имеет более тщательно разработанную архитектуру управления идентификацией и ключами, позволяющую пользователям владеть своими ключами идентификации без необходимости размещения узла блокчейна, и позволяет пользователям настраивать детальный доступ к безопасности на уровне цепного кода.
Что касается Corda, то нам нравится идея сети Corda, где пользователи присоединяются к глобальной сети и получают доступ ко всем существующим участникам. Как и в случае с Fabric, пользователи могут оказаться во многих изолированных подсетях.
В некоторых случаях Corda просто будет играть лучше, так как у нее уже есть некоторые уникальные функции, готовые к работе. Функции Corda, такие как вложения, модель UTXO и оракулы, предлагают возможности, которые не так просто или, в некоторых случаях, невозможно реализовать в Fabric.
Стоит отметить, что в Corda многие функции доступны только в корпоративной версии, такие как коммерческие базы данных (Oracle, MSSql), HSM, выполнение параллельного потока, режим высокой доступности и инструменты развертывания в частной сети. В Fabric все с открытым исходным кодом, хотя вам может потребоваться коммерческий инструмент развертывания, такой как блокчейн-платформа IBM.