原文来自这里。
如果不熟悉capability，那么操作前可以查阅Capabilities。需要注意的是在启用capabilities前，需要升级归属该通道的peer节点和排序节点。
更多关于最新版Fabric中capabilities版本的信息，详见Upgrading your components。
注意：在Hyperledger Fabric中使用术语升级时，指的是升级组件的版本（例如，将可执行文件升级到最新版）。使用更新时，指的是配置的更新，例如更新通道的配置或部署脚本。在Fabric中，如果没有数据迁移的话，我们不会使用术语迁移。
先决条件和注意事项
更新前，请先确保你的机器上有Prerequisites中所提及的所有依赖。这将保证你拥有更新通道配置所需的最新版工具。
由于Fabric可以并且应该滚动更新，所以启用capabilities前需要完成Fabric的升级。任何没有升级到至少capabilities相关的可执行程序都将引起崩溃，并指出错误的配置，否则会导致账本分叉。
一旦启用capabilities，它成为该通道的永久记录。这意味着即使之后禁用了capabilities，旧的可执行程序也无法参与到该通道中，因为它无法处理启用capabilities到禁用capabilities期间的所有区块。结果就是一旦启用了capabilities，就不建议或不支持禁用它。
有鉴于此，可将启用capabilities视为不可逆的。所以在测试设置新capabilities，并在生成环境下启用之前，请三思。
概览
在接下来的教程中，我们将展示如何在所有的系统通道和应用程序通道中配置capabilities更新。
是否需要为所有的通道更新配置的每个部分，这取决于最新版的内容以及你的使用场景。详情参见Upgrading to the latest version of Fabric。需要注意的是在使用最新版功能前，可能需要更新到最新的capability版本，最好的做法是始终使用最新版的可执行程序和最新的capability版本。
因为更新capability版本涉及到配置更新事务流程，相关命令详见Updating a 通道 configuration。
与通道其它配置更新一样，capability版本更新也分三步（每个通道）：
- 获取最新的通道配置
- 创建修改后的通道配置
- 创建配置更新事务
我们将按照下面的顺序来启用capabilities：
-
Orderer system 通道
- Orderer group
- 通道 group
-
Application 通道
- Orderer group
- 通道 group
- Application group
尽管可以同时编辑通道配置的多个部分，但在本教程中我们将展示如何逐步处理这些过程。也就是说我们不会在一次配置修改中同时修改系统通道的Orderer组和通道组。这是因为并不是每次发布都有新的Orderer组capability和通道组capability。
在生成网络中，单个用户可以独立完成所有通道（和其它配置）更新时不可能的，也是不明智的。例如，orderer system 通道更新，只能由组织的管理员来执行（尽管可以将peer组织添加到排序服务组织中）。同样地，更新其它的Orderer或通道组的通道配置除了需要排序服务组织的签名外还需要peer组织的签名。分布式系统需要协同管理。
新建capabilities配置文件
本教程假设名为capabilities.json的文件已创建，它包含所有你想更新的capabilities。使用jq将编辑的配置应用到修改后的文件中。
你也不是非要创建类似capabilities.json的文件或使用jq工具。修改后的配置也可手动编辑，详见sample 通道 configuration。
然而，这里所描述的过程（使用JSON文件和jq工具）在脚本化方面确实有优势，这使得它适合想大量的通道进行配置更新。这也是这种方式为什么会成为更新通道的推荐方式。
示例中，capabilities.json文件内容如下（如果将更新通道作为你Fabric升级到最新版的一部分，则需要将capabilities设置为适合该版本的版本）：
{
"通道": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
},
"orderer": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
},
"application": {
"mod_policy": "Admins",
"value": {
"capabilities": {
"V2_0": {}
}
},
"version": "0"
}
}
默认情况下，peer节点并不是orderer system 通道的管理员，所以peer节点不能发起orderer system 通道配置更新。排序组织的管理员必须创建类似的文件（没application组capability，因为系统通道中不存在application组）来执行系统通道配置更新操作。默认情况下应用程序通道配置是复制系统通道的，所以除非为了特定的capability版本而创建了不同的通道配置，否则应用程序通道的Orderer组和通道组与网络中其它的系统通道是一样的。
orderer system 通道 capabilities
默认情况下应用程序通道复制系统通道的配置，所以最好的操作是在跟应用程序通道前先更新系统通道的capabilities。就像Upgrading your components中所述，更新peer之前先将排序节点更新至最新版。
orderer system 通道归排序服务组织管理。默认情况下，只有一个组织（在排序服务初始化节点时创建的组织），但也可以扩展多个组织（例如，有多个组织为排序服务提供节点）。
在更新Orderer和通道 capability之前，请确保在你的排序服务中的所有节点都已经升级到所需版本。如果排序节点没有升级到所需版本，它将无法处理具有该capability的配置块，并且将崩溃。类似的，如果排序服务中新增一条通道，那所有将被加入到该通道的peer节点必须至少处于通道和Application capabilities相近的节点版本，否则在处理配置块时这些peer节点将会崩溃。要了解更多信息，详见Capabilities。
设置环境变量
你需要导入以下环境变量：
- CH_NAME：待更新的系统通道名称。
- CORE_PEER_LOCALMSPID：执行通道更新操作的MSP ID，排序服务组织中的MSP。
- TLS_ROOT_CA：排序节点TLS证书的绝对路径。
- CORE_PEER_MSPCONFIGPATH：标识你的组织的MSP存放的绝对路径。
- ORDERER_CONTAINER：排序节点的容器名称。访问排序服务时，你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。
Orderer组
关于如何拉取、传递和确定通道配置范围的命令，详见Step 1: Pull and translate the config。如果你有了modified_config.json文件，那你可以使用下面的命令来新增Orderer组capabilities：
jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
因为你现在更新的是系统通道，系统通道修改策略只需要排序服务组织的管理员签名。
通道组
关于如何拉取、传递和确定通道配置范围的命令，详见Step 1: Pull and translate the config。如果你有了modified_config.json文件，那你可以使用下面的命令来新增通道组capabilities：
jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
因为你现在更新的是系统通道，系统通道的修改策略只需要排序服务组织的管理员签名。在应用程序通道中，假如你没有修改默认值，通常需要同时满足Application组（由peer组织的MSPs组成）和Orderer组（由排序服务组织组成）的大多数管理员策略。
在已有通道上启用capabilities
现在我们来更新orderer system 通道的capabilities，我们将会更新已有通道（你想更新的）的配置。
应用程序通道的配置与系统通道的非常相似。这样，我们就能复用capabilities.json文件，并使用相同的命令来进行更新（只需要重新设置环境变量即可）。
在更新capabilities前，请确保排序服务中的所有排序节点和通道中的所有peer节点都已升级至要求的版本，否则未升级的节点将无法处理启用了capability的配置块并引起崩溃。更多信息详见Capabilities。
设置环境变量
- CH_NAME：待更新的应用程序通道名称。
- CORE_PEER_LOCALMSPID：执行通道更新操作的MSP ID，peer组织中的MSP。
- TLS_ROOT_CA：peer组织TLS证书的绝对路径。
- CORE_PEER_MSPCONFIGPATH：标识你的组织的MSP存放的绝对路径。
- ORDERER_CONTAINER：排序节点的容器名称。访问排序服务时，你可以访问排序服务中的任意节点。你的请求会自动提交给leader节点。
Orderer组
Step 1: Pull and translate the config。如果你有了modified_config.json文件，那你可以使用下面的命令来新增Orderer组capabilities：
jq -s '.[0] * {"通道_group":{"groups":{"Orderer": {"values": {"Capabilities": .[1].orderer}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Orderer组中大多数管理员同意（即，大多数排序服务的管理员）。peer组织可以更新该capability，但这种情况下，peer组织的签名并不满足该策略。
通道组
Step 1: Pull and translate the config。如果你有了modified_config.json文件，那你可以使用下面的命令来新增通道组capabilities：
jq -s '.[0] * {"通道_group":{"values": {"Capabilities": .[1].通道}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Application和Orderer组大多数管理员审核通过。也就是说，需要peer组织和排序服务组织中大多数管理员对该请求进行签名认证。
Application组
Step 1: Pull and translate the config。如果你有了modified_config.json文件，那你可以使用下面的命令来新增通道组capabilities：
jq -s '.[0] * {"通道_group":{"groups":{"Application": {"values": {"Capabilities": .[1].application}}}}}' config.json ./capabilities.json > modified_config.json
然后执行步骤Step 3: Re-encode and submit the config。
该capability默认的修改策略是需要Application组大多数管理员审核通过。也就是说，需要peer组织中的大多数管理员进行投票。排序服务的管理员不需要参与。
这样的结果就是不要将此capability设置为不存在的版本。因为排序节点既不会解析应用程序capabilities，也不会验证它，排序节点会审核通过所有的应用程序capabilities版本并将新的配置块分发给peer节点以便peer节点将其保存到账本中。这样的话，peer节点将无法处理该capability并引起崩溃。即使之后再将一个合法的capability版本配置到peer节点上，但之前的配置块仍存在于账本中，当尝试处理之前的配置块时还是会引发崩溃。
这也是为什么需要capabilities.json这样的文件。它可以有效防止简单的用户错误，例如，当将应用程序的apability设置为V20，而不是V2_0时，这会导致通道不可用且无法恢复。
启用capabilities后进行验证
验证capabilities是否成功启用的最好方式是在所有的通道上执行一次chaincode调用。未升级到相应版本的节点都无法解析新的capabilities，这些节点都会崩溃。在这些节点成功重启之前你需要将它们升级至相应的版本。
声明：本作品采用署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)进行许可，使用时请注明出处。
Author: MonsterMeng92