功能需求¶

由于Fabric是一个分布式系统，通常会涉及多个组织(有时在不同的国家甚至大洲)，所以网络中可能(而且是典型的)存在许多不同版本的Fabric代码。然而，重要的是，网络以相同的方式处理交易，这样每个人对当前网络状态都有相同的看法。

这意味着每个网络，以及该网络中的每个通道，必须定义一组我们称为“功能”的东西，以便能够参与处理交易。例如，Fabric v1.1引入了新的MSP角色类型“Peer”和“Client”。但是，如果1.0版本的节点不理解这些新角色类型，那么它将无法恰当地验证引用它们的背书策略。这意味着在使用新角色类型之前，网络必须同意启用v1.1的“通道”功能需求，确保所有节点都做出相同的决定。

只有支持所需功能的二进制文件才能参与通道，较新的二进制版本在启用相应功能之前不会启用新的验证逻辑。通过这种方式，功能需求确保即使使用不同的构建和版本，网络也不可能出现状态分支。

定义功能需求¶

功能需求是在通道配置中为每个通道定义的(可以在通道的最新配置区块中找到)。通道配置包含三个位置，每个位置定义了一个不同类型的功能。

功能类型	标准路径	JSON路径
通道	/通道/功能	.channel_group.values.Capabilities
排序器	/通道/排序器/功能	.channel_group.groups.Orderer.values.Capabilities
应用	/通道/应用/功能	.channel_group.groups.Application.values. Capabilities

**Channel：**这些功能同时适用于节点和排序器，并且位于根“通道”组中。
**Orderer：**只适用于排序器，并且位于“排序器”组中。
**Application:**只适用于节点，并且位于“应用程序”组中。

为了与现有的管理结构保持一致，将功能分解为这些组。更新排序器功能是排序器组织独立于应用组织来管理的。类似地，只有应用管理员才会管理更新应用功能。通过在“Orderer”和“Application”之间划分功能，一个假设的网络可以运行v1.6排序服务，同时支持v1.3节点应用网络。

然而，有些功能跨“Application”和“Orderer”组。正如我们前面看到的，添加新的MSP角色类型是排序器和应用管理员都同意和需要确认。排序器必须理解MSP角色的含义，以便允许交易通过排序，而节点必须理解角色，以便验证交易。这些跨应用和排序器组件的功能在顶层“Channel”组中定义。

注解

有可能将通道功能定义为版本v1.3，而将排序器和应用功能分别定义为版本1.1和版本1.4。在“通道”组级别启用功能并不意味着在更特定的“Orderer”和“Application”组级别也可以使用相同的功能。

设置功能¶

功能被设置为通道配置的一部分(作为初始配置的一部分，我们稍后将讨论它，或者作为重新配置的一部分)。

注解

我们有两个文档讨论通道重新配置的不同方面。首先，我们有一个教程:doc: ` channel_update_tutorial `，将带您通过这个过程。我们还有一个文档:doc: ‘ config_update ‘来进行讨论，它概述了各种可能的更新，并更全面地查看了签名过程。

由于新通道默认情况下复制了排序器系统通道的配置，因此将自动配置新通道，使其使用排序器系统通道的功能，以及通道创建交易指定的应用功能。但是，必须重新配置已经存在的通道。

功能值的数据结构在protobuf中定义为:

message Capabilities {
      map<string, Capability> capabilities = 1;
}

message Capability { }

例如，在JSON中呈现:

{
    "capabilities": {
        "V1_1": {}
    }
}

初始配置中的功能¶

在文件“configtx.yaml”的发布构件的“config”目录中，有一个“功能”部分，列举了每种功能类型(通道、排序器和应用)的可能功能。

用功能的最简单方法是选择一个v1.1示例概要文件（profile），并为您的网络定制它。例如:

SampleSingleMSPSoloV1_1:
    Capabilities:
        <<: *GlobalCapabilities
    Orderer:
        <<: *OrdererDefaults
        Organizations:
            - *SampleOrg
        Capabilities:
            <<: *OrdererCapabilities
    Consortiums:
        SampleConsortium:
            Organizations:
                - *SampleOrg

注意，在根级别(用于通道功能)和排序器级别(用于排序器功能)定义了一个“‘Capabilities’”部分。上面的示例使用了一个YAML引用来包含YAML底部定义的功能。

当定义排序器系统通道时，没有应用部分，因为这些功能是在创建应用通道时定义的。要在通道创建时定义新通道的应用功能，应用管理员应该在“SampleSingleMSPChannelV1_1”概要文件(profile)之后为其通道创建交易建模。

SampleSingleMSPChannelV1_1:
     Consortium: SampleConsortium
     Application:
         Organizations:
             - *SampleOrg
         Capabilities:
             <<: *ApplicationCapabilities

这里，Application部分有一个新元素``Capabilities`` ，它引用了在YAML末尾定义的``ApplicationCapabilities``部分。

注解

通道和排序器部分的功能继承自排序器系统通道中的定义，并在通道创建过程中由排序器自动包含。