本Fabric中文文档专栏的阅读前言：前言

---

---

什么是策略

在最基础的层面上，策略是一组规则，定义了决策是如何做出以及特定结果是如何达成的结构。为此，策略通常描述“谁”以及“做什么”，比如某人对某个资源拥有的访问权限。我们生活中处处可见策略的使用，它们保护着我们珍视的资产，从租车、健康保险、到房屋等。

例如，保险策略定义了保险赔付的条件、条款、限额和有效期。该策略由保单持有者和保险公司共同同意，并定义了双方的权利和责任。

而在 Hyperledger Fabric 中，策略是用于基础设施管理的机制。Fabric 策略代表成员如何就接受或拒绝网络、通道或智能合约的变更达成共识。策略在通道初次配置时由成员同意，但通道随着发展还可以修改策略。

例如，策略可定义添加或移除通道成员的标准，改变区块生成方式，或指定验证智能合约所需的组织数量。这些行为由策略定义“谁”能够执行。简而言之，你想在 Fabric 网络执行的任何操作都受策略控制。

---

为什么需要策略

策略是 Hyperledger Fabric 与 Ethereum 或 Bitcoin 等其他区块链的不同之处。在那些系统中，任何节点都可以生成和验证交易，且网络治理策略在任何时刻都是固定且只能通过与代码相同的过程修改。

而 Fabric 是一个许可区块链，用户由基础设施识别，能在网络启动前决定网络治理规则，也能在网络运行时变更治理。

策略允许成员决定哪些组织可以访问或更新 Fabric 网络，并提供执行这些决策的机制。策略包含对特定资源（如用户或系统链码）的访问组织列表，也指定了多少组织需要同意才能更新资源（如通道或智能合约）。

一旦策略编写完成，它会评估附加在交易和提案上的签名集合，验证这些签名是否符合网络约定的治理标准。

---

策略如何实现

策略定义在与特定动作相关的管理域内。例如，将 peer 组织添加到通道的策略定义在 peer 组织的管理域中（即 Application 组）。同样地，将排序节点添加到通道共识节点列表的策略则定义在 Orderer 组中。

跨 peer 和排序组织管理域的操作则包含在 Channel 组中。

通常，这些策略默认要求所在组的大多数管理员签名（例如，大多数 peer 组织管理员；Channel 策略需大多数 peer 和排序组织管理员），但你可以定义任何规则。更多信息请查看 下文Signature 策略。

访问控制列表 (ACLs)

网络管理员应当关注 Fabric 中 ACL（访问控制列表）的用途，它允许通过关联现有策略来配置对资源的访问权限。这些“资源”可以是系统链码的函数（例如 qscc 的 “GetBlockByNumber”），也可以是其他资源（例如谁可以接收区块事件）。ACL 引用通道配置中定义的策略，并扩展它们以控制附加资源。

默认 ACL 集位于 configtx.yaml 文件的 Application: &ApplicationDefaults 部分中，但在生产环境中应覆盖它们。configtx.yaml 中列出的资源是 Fabric 当前定义的所有内部资源的完整列表。

在该文件中，ACL 使用如下格式表达：

# 限制调用链码的 ACL:
peer/Propose: /Channel/Application/Writers

其中 peer/Proposee 表示受保护的资源，/Channel/Application/Writers 是必须满足的策略路径。

这行配置表示：只有满足 '/Channel/Application/Writers' 策略的身份才能调用链码。在默认 ACL 下，只要满足对应的隐式元策略即可访问资源。

如下图：/Channel/Application/Writers策略满足 peer/Propose ACL。可以使用任何writers签名策略的客户应用程序从任何组织提交的交易来满足此策略。

深入了解 ACL，请参考文末的访问控制列表(ACL) 章节。

智能合约背书政策

每个链码包中的智能合约都有一个背书策略，该策略指定了需要多少来自不同通道成员的 peers 执行并验证该事务，以使其被认为有效。因此，背书策略定义了哪些组织（通过它们的 peers）必须对提案执行进行“背书”（即批准）。

修改策略

最后，还有一种关键策略类型：Modification policy（修改策略）。这类策略指定了修改配置更新所需的签名身份组。它定义了策略本身如何更新。因此，每个通道配置元素都引用了一个管理其修改的策略。

---

如何在 Fabric 中编写策略

如果你想变更 Fabric 中的任何内容，相关资源对应的策略会说明谁需要批准，是显式签署还是通过群体隐式同意。在保险领域中，显式签署可以是单个家庭财产保险代理；隐式签署则类似于要求多数管理团队成员同意。

这种方式特别有用，因为组成员可能随时间变动而无需更新策略。在 Hyperledger Fabric 中，显式签署策略使用 Signature 语法表示，隐式签署则使用 ImplicitMeta 语法表示。

Signature policies

Signature 策略定义必须签署以使策略满足条件的用户类型，例如 OR('Org1.peer', 'Org2.peer')。它支持构造非常具体的规则，如：“组织 A 中的一名管理员和另外两名管理员，或者六个组织管理员中的五名”。语法支持任意组合的 AND、OR 和 NOutOf。

例如：

AND('Org1.member', 'Org2.member')

表示需要 Org1 和 Org2 各至少一名成员的签名。

ImplicitMeta policies

ImplicitMeta 策略仅在基于配置树的层级结构中有效，它聚合配置树中更深层的策略结果，这些子策略最终由 Signature 策略定义。

它们称为“Implicit”，因为它们是基于通道配置中组织动态构建的；称为“Meta”，因为它们不是针对具体 MSP 身份，而是对配置树下的子策略进行评估。

下图展示了应用通道的策略层级结构，以及 ImplicitMeta 通道配置管理员策略（路径 /Channel/Admins）在配置层级结构中是如何解析的（每个勾号表示该子策略的条件得到满足）。

正如上图所示，ImplicitMeta 策略，类型 = 3，使用如下语法：

<ANY|ALL|MAJORITY> <SubPolicyName>

例如：

MAJORITY Admins

图中显示 Admins 子策略，指的是配置树下面的所有 Admins 策略。你可以创建自己的子策略，随意命名，然后在各组织中定义。

我们也可以换一个形式来多维的了解策略层级关系，如下图所示：

这张图显示：Channel/Application/Admins 隐式元策略可由大多数组织的 Admin 签名策略满足。

如果对通道提交更新的请求包含 Org1、Org2 和 Org3 的签名，则满足对应的策略；但如果 Org3 是第一个超过多数之后多余的签名，其提示可能以浅绿色显示，表示冗余。如下图所示：

同样，Channel/Application/Endorsement 策略可由大多数组织的 Endorsement 签名策略满足，这是 Fabric 链码生命周期的默认背书策略。除非你明确指定其他策略，否则调用链码需要大多数通道组织背书才能被加入区块。如下图

正如前文所述，ImplicitMeta 策略（例如 MAJORITY Admins）的一个关键优势是，当你向通道添加新的管理员组织时，无需更新通道策略。因此，ImplicitMeta 策略被认为更灵活。当它最终解析为配置树下的 Signature 子策略时，将有效控制。

你也可以定义跨组织的应用级隐式策略，例如在通道中，要求满足 ANY、ALL 或 MAJORITY 中的任意一种。这种格式更自然，且为不同组织提供了灵活的默认值，使它们能够确定何为有效背书。

如果包含 NodeOUs 更高的粒度控制，可以将身份类别与数字证书中的组织单位关联。Fabric 的 NodeOUs 可以在 Fabric CA 客户端配置文件中启用，并与生成的身份关联。例如，某组织启用了特定 NodeOUs 后，可以要求“peer”签署才能算背书有效，而未启用的组织则可能只要求任意成员签署。

还有一个用于验证区块有效性的策略：/Channel/Orderer/BlockValidation。peer 节点在接收新块时使用此策略来确认其由通道排序节点签发、未被篡改。默认情况下，拥有 Writers 签名策略的排序组织可以生成和验证区块。

---

例子: 通道配置策略

理解策略从查看 configtx.yaml 中定义的通道策略开始。我们可以使用 Fabric 测试网络中的 configtx.yaml 示例，查看两种策略语法的示例。

我们将检查 fabric-samples/test-network 示例中使用的文件。

Organizations 部分

文件第一部分定义了将成为通道成员的各组织。在每个组织定义内部，存在默认策略 Readers、Writers、Admins 和 Endorsement，当然你也可以自定义名称。每个策略都有一个 Type，表示策略类型 (Signature 或 ImplicitMeta) 和一个 Rule。

下面的测试网络示例展示了通道中 Org1 组织的定义。其中 Type 为 Signature，Endorsement 策略规则定义为：

"OR('Org1MSP.peer')"

表示 Org1MSP 的一个 peer 必须签署。正是这些 Signature 策略成为 ImplicitMeta 策略指向的子策略。

- &Org1# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: Org1MSP# ID to load the MSP definition asID: Org1MSPMSPDir: ../organizations/peerOrganizations/org1.example.com/msp# Policies defines the set of policies at this level of the config tree# For organization policies, their canonical path is usually#   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>Policies:Readers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"Writers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.client')"Admins:Type: SignatureRule: "OR('Org1MSP.admin')"Endorsement:Type: SignatureRule: "OR('Org1MSP.peer')"

Application部分

接下来展示的是 ImplicitMeta 策略类型在 configtx.yaml 的 Application 区段中的用法。这一系列策略位于 /Channel/Application/ 路径下。如果你使用默认的 Fabric ACL，这些策略定义了应用通道许多重要功能的行为，例如谁可以查询通道账本、调用链码、或更新通道配置。这些策略指向为每个组织定义的子策略。

前文 Org1 中定义的 Reader、Writer 和 Admin 子策略，会被 Application 区域中的 Reader、Writer 和 Admin ImplicitMeta 策略所评估。因为测试网络使用默认策略，你可以使用上述 Org1 示例来查询通道账本、调用链码以及批准所创建测试网络通道的更新。

################################################################################
#
#   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 networkOrganizations:# 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: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

注：完整的文件详解请看本专栏 《configtx通道配置文件》 一文。

---

Fabric 链码生命周期

Fabric 链码生命周期在链码由组织成员批准并提交到通道过程中使用策略。

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 networkOrganizations:# 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: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

• LifecycleEndorsement 策略控制谁需要批准链码定义。

• Endorsement 策略是链码的默认背书策略。

---

链码背书策略

当链码通过 Fabric 链码生命周期审批并提交到通道时，需要指定背书策略（一个策略适用于与该链码相关的所有状态）。背书策略可通过引用通道配置中定义的策略，或显式使用 Signature 策略指定。

如果在审批阶段未显式指定背书策略，则使用通道的 Endorsement 策略，默认值为 "MAJORITY Endorsement"，意味着通道中大多数组织的 peer 必须执行一次交易，才能使其被视为有效。该默认策略允许加入通道的新组织自动成为链码背书策略的一部分。

如需使用非默认背书策略，可使用 Signature 策略格式指定更复杂的条件（例如要求一个组织背书，再加上通道中另一个组织的背书）。

Signature 策略还支持使用 principals，它可以将身份映射为角色。principals 类似于用户 ID 或组 ID，但更通用，因为它们可以包含身份的诸多属性，如组织、组织单位、角色，甚至特定身份。身份角色定义为 'MSP.ROLE'，其中 MSP 是 MSP ID（组织），ROLE 是四种可接受角色之一：Member、Admin、Client、Peer。这些角色在用户通过 CA 注册时被关联。你也可以自定义 Fabric CA 上可用的角色。

一些有效的 principals 示例：

• 'Org0.Admin'：Org0 MSP 的管理员

• 'Org1.Member'：Org1 MSP 的成员

• 'Org1.Client'：Org1 MSP 的客户端

• 'Org1.Peer'：Org1 MSP 的 Peer

• 'OrdererOrg.Orderer'：排序组织 MSP 的排序节点

在某些情况下，特定状态（例如某个键值对）可能需要不同的背书策略。这种基于状态的背书允许你覆盖默认的链码级别背书策略，为指定键设置不同策略。

如需深入了解如何编写背书策略，请参考文末的 背书策略 一章节。

---

覆盖策略定义

Hyperledger Fabric 包含一些默认策略，适用于入门、开发和测试，但在生产环境中应进行自定义。在 configtx.yaml 文件中，你应该了解这些默认策略。通道配置策略可以扩展，除了 configtx.yaml 中默认的 Readers, Writers, Admins，你可以定义任意策略。

如需了解如何更新通道配置，请参考本专栏 《向通道中添加组织》 一文，绝大多数通道配置的修改更新步骤和文中添加组织的例子一致，区别仅在于配置文件的修改。

访问控制列表（ACL）

什么是访问控制列表？

注意：本主题涉及通道管理级别的访问控制和策略。

Fabric 使用访问控制列表（ACL）通过将一个 策略（Policy） 与一个资源关联来管理对资源的访问。Fabric 内置了多个默认 ACL。本篇文档将讨论它们的格式，以及如何覆盖这些默认设置。

但在开始之前，我们先需要理解一下资源与策略的概念。

资源

用户通过调用用户链码（user chaincode）、事件流源（events stream source），或某些系统链码（system chaincode）与 Fabric 进行交互。因此，这些接口都被视为应受访问控制保护的“资源”。

应用开发者需要了解这些资源以及它们对应的默认策略。configtx.yaml 文件中包含了这些资源的完整列表。你可以在本专栏 《configtx通道配置文件》 一文获得详解。 这里查看 configtx.yaml 示例文件。

在 configtx.yaml 中资源的命名形式几乎囊括了 Fabric 当前定义的所有内部资源。命名约定类似 <component>/<resource>，例如 cscc/GetConfigBlock 指的是 CSCC 组件中的 GetConfigBlock 调用。

策略

策略是 Fabric 的核心机制，它允许检查请求附带的身份（或身份集合）是否满足资源所需的策略。背书策略（endorsement policies）用于判断交易是否被正确背书。通道配置中定义的策略既用于配置变更，也用于访问控制，所有策略都存储在通道配置内。

策略通常分为两种格式：Signature 策略 或 ImplicitMeta 策略。

Signature 策略

此类策略定义必须由哪些具体用户签名才能满足策略。例如：

Policies:MyPolicy:Type: SignatureRule: "OR('Org1.peer', 'Org2.peer')"

该策略表示，名为 MyPolicy 的策略只有在“Org1 的 peer”或“Org2 的 peer”签名时才满足。Signature 策略支持结合 AND、OR 以及 NOutOf 语法，灵活构建复杂规则，例如：“组织 A 的一名管理员和两名其他管理员，或 20 名组织管理员中的 11 人”。

ImplicitMeta 策略

ImplicitMeta 策略会聚合配置树中更深层定义的 Signature 策略结果。它允许使用类似“大多数组织管理员”这样的默认规则，语法形式更简单，例如：

<ALL|ANY|MAJORITY> <SubPolicyName>

例子：

Policies:AnotherPolicy:Type: ImplicitMetaRule: "MAJORITY Admins"

该策略表示，只需配置树中大多数 Admins 策略满足即可。默认策略中一般将 Admins 用于敏感或操作性的网络行为（例如在通道上实例化链码）；Writers 通常用于提出账本更新；Readers 只能访问信息但无更新或操作权限。如果开启了 NodeOU 支持，还可加入新的 peer 和 client 角色。

访问控制在哪里指定？

访问控制默认值位于 configtx.yaml 文件中，这是 configtxgen 用来构建通道配置的模板文件。

你可以通过两种方式更新访问控制：一是直接编辑 configtx.yaml（用于创建新通道）；二是更新已有通道配置中的 ACL。

configtx.yaml 中 ACL 的格式

ACL 的格式由资源名称映射到策略路径构成，示例如下：

# 调用 peer 上链码的 ACL 策略
peer/Propose: /Channel/Application/Writers# 接收区块事件的 ACL 策略
event/Block: /Channel/Application/Readers

上述 ACL 表示：只有满足 /Channel/Application/Writers 策略的身份才能访问 peer/Propose；满足 /Channel/Application/Readers 策略的身份才能访问 event/Block。

在 configtx.yaml 中更新 ACL 默认值

如果你希望在引导网络时覆盖默认 ACL，或者在通道创建前修改 ACL，最佳实践是直接编辑 configtx.yaml。

例如，将 peer/Propose ACL 默认值从 /Channel/Application/Writers 修改为某个策略 MyPolicy：

1. 在 Application.Policies 中定义一个名为 MyPolicy 的签名策略，例如：

Policies: &ApplicationDefaultPoliciesReaders:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"MyPolicy:Type: SignatureRule: "OR('SampleOrg.admin')"

2. 在 Application: ACLs 部分，将 peer/Propose 引用的策略从旧值修改为 MyPolicy。

背书策略

每个链码都有一个背书策略，用于指定在通道上哪些 peer 必须执行链码并背书执行结果，才能使交易被视为有效。背书策略定义了哪些组织（通过它们的 peer）必须“背书”（即批准）提案的执行。

注意
请记住，状态（以键值对形式表示）与区块链数据是分离的。

作为 peer 验证交易的一部分，每个验证 peer 会检查交易是否包含了符合背书策略要求的背书次数，并且背书来自预期的源（这两个条件都由背书策略指定）。还会验证背书是否有效（即是否来自有效证书的有效签名）。

---

多种方式指定背书策略

默认情况下，背书策略在链码定义中指定，由通道成员达成一致后提交到通道（即一个背书策略覆盖一个链码相关的所有状态）。

对于私有数据集合，还可以在集合级别指定背书策略，该策略会覆盖链码级别的背书策略，针对私有数据集合中的键施加更严格的写入控制。

此外，还可以针对特定公共通道状态或私有数据集合状态（即特定键值对）设置不同的背书策略。这种“基于状态的背书”允许使用不同于链码级别或集合级别的策略。例如，一个代表资产的键可能需要持有执照的评估员的背书，或者资产所有人（若属于通道成员）希望他们的 peer 签署。此类策略适用于那些需要与默认背书策略不同的资产。

---

设置链码级别背书策略

链码级别的背书策略在通道成员批准链码定义时达成一致。在链码定义提交到通道前，需要满足 Channel/Application/LifecycleEndorsement 策略（默认是大多数应用组织的签名）。

链码一旦被提交，任何写入数据到账本的调用都必须经过足够的通道成员签名以满足背书策略。

可以通过 CLI 在审批和提交链码定义时使用 --signature-policy 标志指定背书策略。例如：

peer lifecycle chaincode approveformyorg --channelID mychannel \--signature-policy "AND('Org1MSP.member', 'Org2MSP.member')" \--name mycc --version 1.0 --package-id <package-id> --sequence 1 \--tls --cafile <tls-cert> --waitForEvent

上述命令审批了 mycc 链码定义，背书策略为 AND('Org1MSP.member', 'Org2MSP.member')，要求 Org1 和 Org2 的成员都签名。审批数达到要求后，通过以下命令提交：

peer lifecycle chaincode commit --channelID mychannel \--signature-policy "AND('Org1MSP.member', 'Org2MSP.member')" \--name mycc --version 1.0 --sequence 1 --init-required \--tls --cafile <tls-cert> --peerAddresses <peers> ...

值得注意的是，如果启用了 MSP 的角色识别（如 peer），你可以只限制 peer 签名：

peer lifecycle chaincode approveformyorg ... \--signature-policy "AND('Org1MSP.peer', 'Org2MSP.peer')" ...

此外，也可以使用通道配置中的策略路径：使用 --channel-config-policy 标志选择通道配置中的策略，如：

peer lifecycle chaincode approveformyorg ... \--channel-config-policy Channel/Application/Admins ...

如果未指定策略，默认使用 Channel/Application/Endorsement 策略，该策略要求大多数通道成员背书。该策略会随着组织成员的增减自动更新。若使用 --signature-policy，则在组织变动时需手动更新策略，否则新加入的组织将无法背书。

---

背书策略语法

如上所述，策略以“主体（principals）”表达，形式为 'MSP.ROLE'，其中 MSP 是 MSP ID，ROLE 是以下四种之一：member、admin、client、peer。

有效主体示例：

• 'Org0MSP.admin'：Org0 内任何管理员

• 'Org1MSP.member'：Org1 内任何成员

• 'Org1MSP.peer'：Org1 的任何 peer

语法格式为：

EXPR(E[, E...])

EXPR 为 AND、OR 或 OutOf，E 可以是主体或嵌套的表达式。例如：

• AND('Org1MSP.member', 'Org2MSP.member')：要求这两名成员的签名

• OR('Org1MSP.member', 'Org2MSP.member')：任意一名成员签名即可

• OR('Org1MSP.member', AND('Org2MSP.member', 'Org3MSP.member'))：Org1 成员签名或同时有 Org2 和 Org3 成员签名

• OutOf(1, 'Org1MSP.member', 'Org2MSP.member') 等同于 OR(...)

• OutOf(2, ...) 等同于 AND(...)，也可组合构造复杂逻辑

---

设置集合级别背书策略

在审批和提交链码定义时，还可以为私有数据集合指定集合级别背书策略。若设置了此策略，则写入该私有数据集合的事务必须满足集合级别的背书要求。

集合级别策略可以更宽松或更严格，例如链码层可能要求大多数组织背书，但私有集合可能要求特定组织背书。

如果未指定集合级别策略，则默认使用链码级别背书策略。这在某些场景下很有用，比如授权组织能写入他人私有集合；而在其他情况下，应强制集合级别控制，则应明确设置策略。

集合级别策略语法与链码级别完全一致：在集合配置文件中使用 endorsementPolicy，可通过 signaturePolicy 或 channelConfigPolicy 设定。

---

设置键级别背书策略

链码级别或集合级别背书策略与链码生命周期绑定，只能在定义链码时设置。而键级别背书策略可在链码内部更灵活地设置和修改，作为交易读写集的一部分。

Shim API 提供设置和读取背书策略的接口：

SetStateValidationParameter(key string, ep []byte) error
GetStateValidationParameter(key string) ([]byte, error)

若键属于私有数据集合，则使用：

SetPrivateDataValidationParameter(collection, key string, ep []byte) error
GetPrivateDataValidationParameter(collection, key string) ([]byte, error)

Go shim 还提供 KeyEndorsementPolicy 接口方便构建策略：

type KeyEndorsementPolicy interface {Policy() ([]byte, error)AddOrgs(roleType RoleType, organizations ...string) errorDelOrgs(organizations ...string) errorListOrgs() ([]string)
}

例如，为某键设置两个组织背书：调用 AddOrgs() 后用 Policy() 获取字节表示，并传入 SetStateValidationParameter()。

---

验证

提交时，设置键值与设置背书策略在处理方式上无区别，都是状态更新并按相同规则验证。

• 若键没有键级策略，则默认使用链码级别或集合级别策略；

• 若首次为键设置键级策略，需满足原先的链码/集合级策略；

• 若存在键级策略，则其优先级高于链码/集合级策略，它可以更宽松或严格；

• 若删除键级策略（设为 nil），则回退到默认策略。

若交易修改了多个键且它们有不同键级策略，则所有相关策略都需满足方可成立。