Что изменилось в версии Hyperledger Fabric 2.x¶

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

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

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

Давайте ознакомимся с кратким описанием версии Fabric v2.0…

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

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

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

Использование нового жизненного цикла чейнкода¶

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

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

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

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

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

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

Для того, чтобы эти шаблоны работы с приватными данными были возможны, в Fabric v2.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, так что сетевые компоненты можно обновлять по одному без простоев.

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

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

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