文件的第一部分（Organizations）定义了网络中的组织。在每个组织的定义中设置了默认策略，Readers, Writers, Admins, and Endorsement，但是你可以任意定义策略命名。每个策略都有一个 Type 和 Rule， Type 描述了策略的表达式类型（Signature 或 ImplicitMeta）。
下边的 BYFN 示例展示了组织 Org1 在系统通道中的定义，其中策略的 Type 是 Signature 背书策略规则定义为 “OR(‘Org1MSP.peer’)”，表示需要 Org1MSP 成员中的 peer 来签名。正是这些签名策略形成了隐元策略指向的子策略。
Click here to see an example of an organization defined with signature policies
The next example shows the ImplicitMeta policy type used in the Application section of the configtx.yaml. These set of policies lie on the /Channel/Application/ path. If you use the default set of Fabric ACLs, these policies define the behavior of many important features of application channels, such as who can query the channel ledger, invoke a chaincode, or update a channel config. These policies point to the sub-policies defined for each organization. The Org1 defined in the section above contains Reader, Writer, and Admin sub-policies that are evaluated by the Reader, Writer, and Admin ImplicitMeta policies in the Application section. Because the test network is built with the default policies, you can use the example Org1 to query the channel ledger, invoke a chaincode, and approve channel updates for any test network channel that you create.
Click here to see an example of ImplicitMeta policies
Fabric链码生命周期
Fabric 2.0 发布版本中，介绍了一个新的链码生命周期过程，这是一个在网络中更民主的治理链码的过程。新的过程允许多个组织在链码应用到通道之前如何操作进行投票。这个很重要，因为这是新生命周期过程和策略的融合，策略是在过程中指定的决定着网络的安全性。关于该流程的更多细节在 操作者的链码 教程中，但是为了本主题的目的，你应该理解策略在流程中的使用。新的流程指定策略包含两步，当链码被组织成员批准的时候，以及当它被提交到通道后。
configtx.yaml 文件中 Application 部分包含了默认的链码生命周期背书策略。在生产环境中你应该为你的用例自定义这个。
################################################################################
SECTION: Application
- This section defines the values to encode into a config transaction or
genesis block for application related parameters
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
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"
LifecycleEndorsement 策略控制需要谁 批准链码定义 。
Endorsement 策略是 链码的默认背书策略 。更多细节请继续阅读。
链码背书策略
当使用 Fabric 链码生命周期链码被批准并提交到通道时会指定一个背书策略（这个背书策略会覆盖与该链码相关的所有状态）。背书策略可以引用通道配置中的背书策略或者明确指定签名策略。
如果在批准阶段没有明确指明背书策略，就默认使用 Endorsement 策略 “MAJORITY Endorsement”，意味着要想使交易生效就需要大多数不同通道成员（组织）的执行并验证交易。默认策略允许加入通道的组织自动加入链码背书策略。如果你不想使用默认背书策略，你可以使用签名策略格式来指定更复杂的背书策略（这样就需要链码先被通道中的一个组织签名，然后让其他组织签名）。
签名策略也允许你包含主角（principals），这是匹配角色和身份的一种简单方式。主角类似用户 ID 或者 组 ID，但是更广泛，因为它们可以包含更大范围演员身份的属性，比如演员的组织、组织单元、角色，甚至演员指定的身份。我们讨论的主角是决定他们权限的属性。主角被描述为 ‘MSP.ROLE’，MSP 表示需要的 MSP ID（组织），ROLE 表示一下四种可接受的角色之一：Member、 Admin、 Client 和 Peer。角色在用户使用 CA 登记（enroll）的时候与之关联。你可以在 Fabric CA 中自定义可用的角色列表。
一些有效的主角：
‘Org0.Admin’: Org0 MSP 的一个管理员
‘Org1.Member’: Org1 MSP 的一个成员
‘Org1.Client’: Org1 MSP 的一个客户端
‘Org1.Peer’: Org1 MSP 的一个 Peer 节点
‘OrdererOrg.Orderer’: OrdererOrg MSP 的一个排序节点
有一些场景可能需要一些特殊的状态（特殊的键-值对，或这其他的）有不同的背书策略。基于状态的背书可以指定与默认链码级别背书策略不同的键的背书策略。
如何写一个背书策略的更多信息请参考操作指南中的 背书策略 主题。
注意： 不同版本 Fabric 的策略有所不同：
在 Fabric 2.0 之前，链码的背书策略可以在链码实例化或者使用链码生命周期命令时更新。如果没有在实例化时指明，默认背书策略是“通道中组织的任意成员”。例如。在有 “Org1” 和 “Org2” 的通道中，将有一个 “OR(‘Org1.member’, ‘Org2.member’)” 的默认策略。
从 Fabric 2.0 开始，Fabric 提出了一个新的链码生命周期过程，允许多组织同意在链码应用到通道之前如何操作。新的过程需要组织同意链码定义的参数，比如名字、版本以及链码背书策略。
覆盖策略定义
Hyperledger Fabric 包含了用于快速入门、开发、测试去快来你的默认策略，但是在生产环境中需要自定义。你应该留意 configtx.yaml 文件中的默认策略。通道配置策略可以使用任意单词扩展，不仅仅是 configtx.yaml 中的 Readers、 Writers、 Admins。当你编辑 configtx.yaml 文件重写了排序系统通道或这指定通道的默认策略并提交了配置更新，就会覆盖排序系统和应用通道的默认策略。