简介

本篇中，我们将学习Fabric区块链中通道的创建过程，并重点介绍有关通道策略的问题。

通过本系列前面几篇的学习，我们已经知道通道是Fabric网络提供的组织之间的一种私人沟通方式。因此，对通道配置的大多数更改都需要得到通道的其他成员的同意。如果一个组织可以加入通道并在没有得到其他组织批准的情况下读取分类账上的数据，那么通道就没有用处了。对通道结构的任何更改都需要得到一组能够满足通道策略的组织的批准。

策略还管理用户如何与通道交互的过程，例如在将链代码部署到通道之前需要哪些组织集合批准链代码，或者哪些操作需要由通道管理员来完成。

通道政策非常重要，需要专门进行讨论。与通道配置的其他部分不同，控制通道的策略由configtx.yaml文件的不同部分协同工作来确定。虽然通道策略可以在几乎没有限制的情况下为任何应用需求进行配置，但本篇将重点讨论如何使用Hyperledger Fabric提供的默认策略。

如果使用Fabric测试网络或Fabric示例配置使用的默认策略，则创建的每个通道都将使用签名策略——ImplicitMeta策略和访问控制列表（Access Control Lists）策略的组合，来确定组织如何与通道交互并同意更新通道结构。

您可以访问“策略”概念主题，了解有关策略在HyperledgerFabric中作用的更多的内容。

签名（Signature）策略¶

默认情况下，每个通道成员都定义了一组引用其组织的签名策略。当向Peer节点提交提案或向排序节点提交交易时，Peer节点读取附加到交易的签名，并根据通道配置中定义的签名策略对其进行评估。每个签名策略都有一个规则，该规则指定了一组组织和标识，这些组织和标识的签名可以满足配置文件中定义的策略。您可以在下面configtx.yaml的“Organizations”部分中看到Org1定义的签名策略：

- &Org1

  ...

  Policies:
      Readers:
          Type: Signature
          Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
      Writers:
          Type: Signature
          Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
      Admins:
          Type: Signature
          Rule: "OR('Org1MSP.admin')"
      Endorsement:
          Type: Signature
          Rule: "OR('Org1MSP.peer')"

Org1的签名可以满足上述所有策略。但是另一方面需要注意的是，每个策略都列出了组织内能够满足该策略的不同的角色集。例如，Admins策略只能由具有管理员角色的身份提交的交易来满足，而只有具有Peer节点角色的身份才能满足Endorsement策略。附加到单个交易的一组签名可以满足多个签名策略。例如，如果交易附带的背书由Org1和Org2提供，则此签名集将满足Org1和Org2的背书策略。

隐含元（ImplicitMeta）策略¶

如果您的通道使用的是默认策略，则每个组织的签名策略将由通道配置的更高级别的ImplicitMeta策略进行评估。值得注意的是，ImplicitMeta策略的规则不是直接评估提交到通道的签名，而是在通道配置中指定一组可以满足该策略的其他策略。如果交易可以满足策略引用的底层签名策略集，那么它就可以满足ImplicitMeta策略。

您可以在下面的configtx.yaml文件的Application节中看到定义的ImplicitMeta策略：

Policies:
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    LifecycleEndorsement:
        Type: ImplicitMeta
        Rule: "MAJORITY Endorsement"
    Endorsement:
        Type: ImplicitMeta
        Rule: "MAJORITY Endorsement"

Application节中的ImplicitMeta策略控制Peer节点组织如何与通道交互。每个策略都引用与每个通道成员关联的签名策略。您可以在下面的“Application”部分中看到策略与“Organizations”部分中的策略之间的关系：

图1:Admins ImplicitMeta策略可以由每个组织定义的大多数Admins签名策略来满足。

每个策略都引用其在通道配置中的路径。因为“Application”部分中的策略位于Application组中，而Application组位于Channel组内部，所以它们被称为Channel/Application策略。由于Fabric文档中的大多数地方都是按路径引用策略的，因此在本文的其余部分中，我们也按路径引用这些策略。

每个ImplicitMeta中的Rule引用可以满足该策略的签名策略的名称。例如，Channel/Application/Admins ImplicitMeta策略引用了每个组织的Admins签名策略。每个规则还包含满足ImplicitMeta策略所需的签名策略的数量。例如，Channel/Application/Admins策略要求满足大多数Admins签名策略。

图2：提交到通道的通道更新请求包含来自Org1、Org2和Org3的签名，满足每个组织的签名策略。因此，该请求满足Channel/Application/Admins策略。Org3复选框为浅绿色，因为签名不需要达到多数。

举另一个例子，Channel/Application/Endorsement策略可以由大多数组织的背书策略来满足，这些策略需要每个组织的Peer节点的签名。此策略由Fabric链代码生命周期用作默认链代码背书策略。除非使用不同的背书策略提交链代码定义，否则调用链代码的交易需要得到大多数通道成员的背书。

图3：来自客户端应用程序的交易调用了Org1和Org2中Peer节点上的链代码。链代码调用成功，应用程序得到了两家组织Peer节点的认可。由于此交易符合Channel/Application/Endorsement策略，因此该交易符合默认背书策略，可以添加到通道分类账中。

同时使用ImplicitMeta策略和签名策略的优点是，您可以在通道级别设置治理规则，同时允许每个通道成员选择为其组织签名所需的身份。例如，通道可以指定要求大多数组织管理员签署通道配置更新。但是，每个组织都可以使用其签名策略来选择其组织中的哪些身份是管理员，甚至要求其组织中有多个身份需要签名才能批准通道更新。

ImplicitMeta策略的另一个优点是，在向通道添加组织或从通道中删除组织时，它们不需要更新。以图3为例，如果将两个新组织添加到通道中，那么Channel/Application/Endorsement将需要三个组织的背书才能验证交易。

ImplicitMeta策略的一个缺点是，它们不会显式读取通道成员使用的签名策略（这就是为什么它们被称为隐式策略）。相反，他们假设用户具有基于通道配置的所需签名策略。Channel/Application/Endorsement策略的规则基于通道中Peer组织的数量。如果图3中的三个组织中有两个不拥有背书签名策略，那么任何交易都无法获得满足Channel/Application/Endorsement ImplicitMeta策略所需的多数。

通道修改策略¶

通道结构由通道配置中的修改策略控制。通道配置的每个组件都有一个需要满足的修改策略，以便由通道成员进行更新。例如，每个组织定义的策略和通道MSP、包含通道成员的应用程序组以及定义通道共识者集合的配置组件都有不同的修改策略。

每个修改策略都可以引用ImplicitMeta策略或签名策略。例如，如果使用默认策略，则定义每个组织的值将引用与该组织关联的Admins签名策略。因此，组织可以更新其通道MSP或设置锚点Peer节点，而无需获得其他通道成员的批准。定义通道成员集的应用程序组的修改策略是channel/application/Admins ImplicitMeta策略。因此，默认策略是大多数组织需要批准添加或删除通道成员。

通道策略和访问控制列表¶

通道配置中的策略也由访问控制列表（ACL）引用，ACL用于限制对通道使用的Fabric资源的访问。ACL扩展了通道配置中的策略，以管理通道的进程。您可以在示例configtx.yaml文件中看到默认的ACL。每个ACL都引用使用路径的通道策略。例如，以下ACL限制谁可以基于/Channel/Application/Writers策略调用链代码：

# ACL policy for invoking chaincodes on peer
peer/Propose: /Channel/Application/Writers

大多数默认ACL指向通道配置的应用程序部分中的ImplicitMeta策略。为了扩展上面的示例，如果组织能够满足/Channel/Application/Writers策略，则可以调用链代码。

图4：peer/Propose ACL策略符合/Channel/Application/Writers策略。任何组织的客户端应用程序提交的具有writers签名策略的交易都可以满足此策略。

排序（Orderer）策略¶

configtx.yaml的Orderer部分中的ImplicitMeta策略以与Application部分管理Peer节点组织类似的方式管理通道的排序节点。ImplicitMeta策略指向与排序服务管理员的组织相关联的签名策略。

图5:Channel/Order/Admins策略指向与排序服务的管理员相关联的Admins签名策略。

如果使用默认策略，则大多数排序组织都需要批准添加或删除排序节点。

图6：提交的从通道中删除排序节点的请求包含来自网络中三个排序组织的签名，满足channel/Order/Admins策略。Org3复选框为浅绿色，因为签名不需要达到多数。

Peer节点使用Channel/Orderer/BlockValidation策略来确认添加到通道的新区块是由作为通道共同者集合一部分的排序节点生成的，并且该区块没有被其他Peer节点组织篡改或创建。默认情况下，任何具有Writers签名策略的排序组织都可以为通道创建和验证块。

参考资料

• https://hyperledger-fabric.readthedocs.io/en/latest/create_channel/channel_policies.html
• https://hyperledger-fabric.readthedocs.io/en/latest/policies.html
•