Capabilities каналов¶

Эта статья предназначается для администраторов каналов и администраторов узлов.

Обратите внимание: это продвинутая идея Fabric, новые в Fabric пользователи и разработчики могут ее пропустить. Однако с развитием каналов и сетей, понимание и управление capabilites необходимо.

Так как Fabric — это распределенная система, состоящая часто из нескольких организаций, в ней скорее всего будут существовать узлы с разными версиями Fabric. Fabric это допускает, и именно это позволяет проводить rolling upgrades узлов (обновлять один узел, потом другой и т.д., без необходимости в одновременном обновлении всей системы).

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

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

Иногда необходимо обновить канал на новый уровень capability, чтобы включить новую функцию.

Версии узлов и версии capability¶

Вы, наверное, знакомы с тем, как Fabric нумерует версии: v1.1, v1.2.1, v2.0 и т.д. Эти версии указывают на релизы.

Capabilities нумерует версии аналогично, существуют capabilities v1.1, v1.2, v2.0 и т.д., но есть и отличия:

Релиз не всегда определяет новый уровень capability.

Необходимости в определении новой capability зависит от случая, в основном от том, насколько обратно совместимы новые функции с предыдущими релизами. Например, добавление Raft, реализации ордеринг-службы, в v1.4.1, не изменило ни работу транзакций, ни работу ордеринг-служб, поэтому тут новые capabilities не нужны. С другой стороны, Конфиденциальные данные не могут быть обработаны пирами версий раньше v1.2, поэтому для этого требовалось добавление нового capability-уровня.
Узлы должны быть хотя бы быть в уровне capabilities канала. Когда пир присоединяется к каналу, он считывает все блоки реестра последовательно, начиная с genesis-блока канала. Если узел, например, пир, пробует считать блок, включающий не понятные ему capabilities (например, пир v.1.4.x, пытающийся считать блок, содержащий v2.0 application capability), то узел упадет. Такое поведение было выбрано не случайно, так как после этого пир v1.4.x не должен проверять или сохранять транзакции. До того как присоединятся к каналу, убедитесь, что узел имеет входит в уровень capabilities, указанный в конфигурации канала. Крайне рекомендуется обновить все узлы до требуемого уровня (предпочтительно до последнего релиза) до обновления capabilities. Это сходится со стандартной рекомендацией Fabric всегда использовать последний релиз и последние уровни capability.

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

Группы capability¶

В канале не существует единого уровня capability. Существует три capabilities, каждая из которых представляет свою область администрирования:

Orderer: Эти capabilities контролируют задачи, связанные только с ордеринг-службой. Так как эти capabilities не включают процессы, связанные с обработкой транзакций на пирах, их обновление доступно тольк администраторам ордеринг-службы. Заметьте, что эти capability не изменялись между v1.1 и v1.4.2. Однако, как мы увидим далее, это не означает, что узлы оредринг-службы v1.1 будут работать на всех канал с уровнями capability ниже v1.4.2.
Application: Эти capabilities контролируют задачи, связанные только с пирами. Так как администраторы ордеринг-службы не контролируют транзакции в канале, изменение этого capability level подвластно только организациям. Например, Конфиденциальные данные могут быть включены в канале только начиная с v1.2 application capability. В случае Конфиденциальных данных, только эта capability должна быть включена, так как Конфиденциальные данные не касаются ни ордеринг-службы, ни администрации канала.
Channel: Эта группа включает те задачи, которые администрируются совместно организациями и ордеринг-службой. Например, эта capability определяет уровень, на котором обрабатываются обновления конфигурации канала, которые создаются организациями и осуществляются ордеринг-службой. На практике эта группа определяет минимальный уровень всех програм канала, как пиров, так и ордеринг-узлов.

Capabilities групп orderer и channel канала по умолчанию наследуются от системного канала, где их изменить могут только администраторы ордеринг-службы. Поэтому организаци должны проверить genesis-блок канала до того, как присоединят к нему пиров. Хотя capability канала управляется ордерерами в системном канале (как и состав консорциумов). Ожидается, что администраторы ордеринг-службы будут координировать свои действия с администраторами консорциума — чтобы capability канала были обновлены только если консорциум на это готов.

Так как системный канал не определяет application capability, эта capability должна быть указана в профиле канала в genesis-блоке.

Будьте осторожными, когда указываете или изменяете application capability. Так как ордеринг-служба не проверяет, что указанный уровень capability существует, она может позволить каналу использовать v1.8 application capability, хотя такой не существует. Пир, попытающийся считать конфигурационный блок с такой capability, упадет. Даже если можно обновить конфигурацию и указать существующий capability-уровень, это уже не будет иметь значения, так как ни один пир не сможет продвинуться дальше блока с v1.8 capability.

Действительные orderer, application и channel capabilities пример файла configtx.

За более подробной информации о capabilities и в каком месте конфигурации канала они содержаться, обратитесь к этой статье.