Что нового в Hyperledger Fabric версии 2.x

Что нового в Hyperledger Fabric версии 2.4

Шлюз Fabric

Шлюз Fabric (Fabric Gateway) - это новый сервис на одноранговых узлах, который управляет отправкой и обработкой транзакций для клиентских приложений и имеет следующие преимущества:

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

Новые легковесные SDK шлюза (версии 1.0.0) доступны для Node, Java и Go. Эти SDK поддерживают гибкие шаблоны приложений.

  • Вы можете использовать высокоуровневую модель программирования, аналогичную предыдущим версиям SDK, позволяющую вашему приложению просто вызывать единственную функцию SubmitTransaction().
  • Более сложные приложения могут использовать отдельные службы шлюза Endorse, Submit и CommitStatus для отправки транзакций и службу Evaluate для запросов.
  • Вы можете полностью поручить одобрение транзакций шлюзу или, если это необходимо, явно указать одобряющие организации, и шлюз будет использовать одноранговый узел каждой из этих организаций.

Больше информации по этой теме вы найдете в статье Шлюз Fabric.

Отсоединение однорангового узла

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

Больше информации по этой теме вы найдете в описании команды peer node unjoin в справочнике команд.

Вычисление идентификатора пакета упакованного чейнкода

Вы можете вычислить идентификатор пакета упакованного чейнкода без его установки на одноранговые узлы, используя новую команду peer lifecycle chaincode calculatepackageid. Эта команда будет полезна, например, в следующих ситуациях:

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

Больше информации по этой теме вы найдете в описании команды peer lifecycle chaincode calculatepackageid в справочнике команд.

Примечание

Хотя в Fabric 2.4.0 представлены новые функции, Fabric 2.2.x остается текущим выпуском с долгосрочной поддержкой (LTS) до тех пор, пока не будет объявлено о следующем выпуске с LTS.

Что нового в Hyperledger Fabric версии 2.3

В Hyperledger Fabric 2.3 представлены новые функции для улучшения работы одноранговых и упорядочивающих узлов.

Управление каналами службы упорядочения без системного канала

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

Преимущества нового процесса:

  • Повышенная конфиденциальность: поскольку раньше все упорядочивающие узлы были присоединены к системному каналу, каждый из них знал о существовании всех каналов службы упорядочения. Теперь упорядочивающие узлы знают только о тех каналах, к которым они присоединены.
  • Масштабируемость: при наличии большого числа упорядочивающих узлов и каналов, определенных в системном канале, достижение консенсуса упорядочивающими узлами занимало много времени из-за членства во всех каналах. Теперь служба упорядочения может децентрализовано масштабироваться по горизонтали путем независимого присоединения упорядочивающих узлов к определенным каналам.
  • Операционные преимущества
    • Простой процесс присоединения упорядочивающего узла к каналу.
    • Возможность перечислить каналы, в которых упорядочивающий узел участвует в консенсусе.
    • Простой процесс удаления канала с упорядочивающего узла, который автоматически очищает блоки, связанные с этим каналом.
    • Организациям с одноранговыми узлами не нужно согласовывать свои действия с администратором системного канала для создания или обновления своего MSP.

Больше информации по этой теме вы найдете в статье create_channel/create_channel_participation.

Снимок реестра

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

Использование снимков реестра имеет следующие преимущества:

  • Одноранговым узлам не нужно обрабатывать все блоки, начиная с первичного: одноранговые узлы могут присоединиться к каналу без обработки всех блоков, начиная с первичного, значительно сокращая время присоединения узла к существующему каналу.
  • Одноранговые узлы могут присоединиться к каналу, используя последнюю его конфигурацию: так как снимки реестра уже включают последнюю конфигурацию канала, одноранговые узлы могут использовать ее при присоединении к каналу. Это особенно важно, если критические параметры канала, такие как адрес конечной точки службы упорядочения или сертификаты удостоверяющего центра TLS, были обновлены после создания первичного блока.
  • Снижение затрат на хранение: одноранговые узлы, присоединяющиеся через снимки реестра, не несут затрат на хранение всех блоков с момента создания первичного блока.
  • Контрольные точки состояния: администраторы одноранговых узлов могут делать снимки текущего состояния канала и сравнивать его с другими узлами, в той же огранизации или в других организациях, для проверки согласованности и целостности реестра на каждом узле. Согласованные снимки реестра могут быть контрольной точкой и использоваться при присоединении новых одноранговых узлов.

Больше информации по этой теме вы найдете в статье peer_ledger_snapshot.

Примечание

Хотя в Fabric 2.3.0 представлены новые функции, Fabric 2.2.x остается текущим выпуском с долгосрочной поддержкой (LTS) до тех пор, пока не будет объявлено о следующем выпуске с LTS.

Что нового в Hyperledger Fabric версий 2.0, 2.1, 2.2

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

Версии 2.1 и 2.2 основаны на версии 2.0, внося в нее дополнительные возможности, улучшения и исправления ошибок. Версия 2.2 представляет собой первый выпуск Fabric v2.x c долгосрочной поддержкой (long-term support, LTS). Правки будут добавляться в версии v2.2.x до тех пор, пока не выйдет следующая версия с долгосрочной поддержкой.

Давайте ознакомимся с кратким описанием выпуска Fabric версии 2.0…

Децентрализованное управление смарт-контрактами

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

  • Несколько организаций могут согласовывать параметры чейнкода. В версиях 1.x Fabric, каждая организация имела возможность задавать параметры чейнкода (например, политику одобрения) для всех остальных участников канала, которым было предоставлено лишь право отказаться от установки чейнкода и таким образом не участвовать в транзакциях, которые его вызывают. Новый жизненный цикл чейнкода Fabric более гибок и поддерживает как модели централизованного доверия (как в предыдущей версии), так и децентрализованные модели, в которых для запуска чейкнода в канале может требоваться, чтобы политика одобрения и другие параметры были приняты необходимым количеством организаций.
  • Более продуманный процесс обновления чейнкода. В предыдущей модели жизненного цикла транзакцию обновления могла выпустить одна организация сама по себе, при этом создавая риск для тех участников канала, которые еще не установили новый чейнкод. Новая модель разрешает обновить чейнкод лишь после того, как обновление будет одобрено необходимым количеством организаций.
  • Упрощенное обновление политик одобрения и коллекций приватных данных. Жизненный цикл Fabric позволяет изменить установленные политики одобрения или коллекции приватных данных не прибегая к переупаковке чейнкода или необходимости устанавливать его заново. Пользователи также оценят новые политики одобрения, установленные по умолчанию и требующие одобрения большинства организаций в канале. Такая политика автоматически обновляется при появлении новой организации в канале или выходе организации из канала.
  • Проверяемые пакеты чейнкода. Жизненный цикл Fabric пакует чейнкод в легко читаемые файлы .tar. Это облегчает проверку пакета чейнкода и координацию его установки с несколькими организациями.
  • Запуск нескольких чейнкодов в канале из одного пакета. Предыдущая модель жизненного цикла определяла каждый чейнкод в канале при помощи названия и номера версии, которые были указаны при установке пакета чейнкода. Теперь вы можете использовать один пакет чейнкода и разворачивать его несколько раз с разными именами в том же канале или в разных каналах. Например, вы хотите отслеживать разные типы активов их собственной ‘копией’ чейнкода.
  • Пакеты чейнкода не обязательно должны быть одинаковыми у всех участников канала. Организации могут расширять чейнкод для своего сценария использования, например, для выполнения различных проверок в своих интересах. До тех пор пока требуемое число организаций одобряет транзакции чейнкода с совпадающим результатом, транзакция будет признана действительной и будет записана в реестр. Это же позволяет организациям индивидуально внедрять незначительные исправления по собственному графику, не требуя, чтобы вся сеть делала то же самое.

Для существующих развертываний Fabric вы можете продолжать использовать старый жизненный цикл чейнкодов в Fabric 2.0. Новый жизненный цикл вступит в силу только после обновления функциональных возможностей канала до версии 2.0. В статье Жизненный цикл чейнкода Fabric сделан обзор нового жизненного цикла чейнкода.

Новые шаблоны чейнкода для сотрудничества и консенсуса

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

  • Автоматические проверки. Как говорилось выше, организации могут добавлять автоматические проверки в функции чейнкода для подтверждения дополнительной информации перед одобрением предложения транзакции.
  • Децентрализованное соглашение. То, как принимаются решения людьми, можно смоделировать с помощью чейнкода, который охватывает несколько транзакций. Чейнкод может требовать от участников из разных организаций указать свои условия соглашения в транзакции в реестре. Затем окончательный вызов чейнкода может подтвердить, что условия отдельных участников сделки выполнены, и «провести» финальную бизнес-транзакцию для всех участников канала. В качестве конкретного примера указания частных условий см. сценарий передачи активов в статье Конфиденциальные данные.

Улучшения в обращении с приватными данными

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

Для того, чтобы эти шаблоны работы с приватными данными были возможны, в Fabric 2.x сделаны следующие улучшения:

  • Совместное использование и верификация приватных данных. Когда приватные данные передаются участнику канала, который не является членом коллекции, или передаются в другую коллекцию приватных данных, которая содержит одного или более членов канала (путем записи ключа в эту коллекцию), принимающие стороны могут использовать функцию GetPrivateDataHash() из API чейнкода для проверки соответствия приватных данных хэшам в блокчейне, которые были созданы из приватных данных в предыдущих транзакциях.
  • Политики одобрения для коллекций. Коллекции приватных данных теперь могут быть определены политиками одобрения, которые отменяют политики одобрения на уровне чейнкода для ключей в коллекции. Эта функция может использоваться для ограничения того, какие организации могут записывать данные в коллекцию, и именно она позволяет использовать новый жизненный цикл чейкода и шаблоны применения чейнкода, упомянутые ранее. Например, у вас может быть политика одобрения чейнкода, которая требует одобрения большинством организаций, но для каждой конкретной транзакции вам может потребоваться, чтобы две организации, участвующие в транзакции, индивидуально одобрили свое соглашение в своих собственных коллекциях приватных данных.
  • Неявные коллекции данных каждой организации. Если вы хотите использовать разные шаблоны приватных данных для каждой организации, вам даже не нужно определять коллекции при развертывании чейнкода в Fabric v2.x. Неявные коллекции для конкретной организации можно использовать без предварительного определения.

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

Внешний запуск чейнкода

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

  • Удалена зависимость от демона Docker. В предыдущих версиях Fabric для создания и запуска чейнкода одноранговые узлы должны были иметь доступ к демону Docker, что может быть нежелательно в промышленных средах из-за привилегий, необходимых для процесса узла.
  • Альтернатива контейнерам. Больше не требуется запускать чейнкод в контейнерах Docker, и он может выполняться в выбранной оператором среде (включая контейнеры).
  • Внешние сборщики. Оператор может предоставить набор внешних исполняемых файлов сборщика, чтобы переопределить способ сборки и запуска чейнкода.
  • Чейнкод как внешний сервис. Традиционно чейнкоды запускаются одноранговым узлом, а затем подключаются обратно к одноранговому узлу. Теперь можно запускать чейнкод как внешний сервис, например, в модуле Kubernetes, к которому может подключаться одноранговый узел и использовать его для выполнения чейнкода. Подробные сведения об этом содержатся здесь - Чейнкод как внешняя служба .

Больше информации о возможности внешнего запуска чейнкода читайте в статье Внешние модули сборки и запуска.

Кэш базы данных состояний в CouchDB для улучшения производительности

  • Исторически узким местом при использовании внешней базы данных состояний на CouchDB были задержки при чтении во время этапов одобрения или подтверждения транзакций.
  • В Fabric v2.0 новый кэш однорангового узла заменяет многие из этих дорогостоящих поисков быстрым чтением локального кэша. Размер кэша может быть задан в конфигурации посредством свойства cacheSize в core.yaml.

Образы докеров на основе Alpine

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

Пример тестовой сети

Репозиторий fabric-samples теперь включает новую тестовую сеть Fabric. Тестовая сеть создана как модульный и удобный образец сети Fabric, который упрощает тестирование ваших приложений и смарт-контрактов. Сеть также поддерживает возможность развертывания с использованием центров сертификации в дополнение к cryptogen.

Больше информации о тестовой сети вы найдете в статье Использование примера сети Fabric.

Обновление до версии Fabric 2.x

Новая версия влечет за собой дополнительные сложности при обновлении. Однако, поддерживается плавное обновление с версии 1.4.x до версии 2.0, так что сетевые компоненты можно обновлять по одному без простоев. Вы также можете сделать обновление непосредственно с версии 1.4.x LTS до версии 2.2.x LTS.

Документация по обновлению была существенно переработана и расширена, и теперь занимает отдельный раздел Обновление до последней версии. В нем вы найдете статьи Обновление компонентов и Обновление уровня функциональных возможностей канала, а также детальное рассмотрение действий по обновлению до версии v2.x в статье Рекомендации по обновлению до версии 2.x.

Примечания к выпуску

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