区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载Hyperledger Fabric 作为一个企业级许可制permissioned分布式账本框架其整个区块链网络的配置均由策略Policy管理。本文以仓库文档 docs/source/policies.rst 为骨架系统讲解 Fabric 策略的核心概念、两种策略类型SignaturePolicy 与 ImplicitMetaPolicy的构造原理、通道配置中的层级结构与默认策略并结合仓库源码common/policies、common/cauthdsl与sampleconfig/configtx.yaml中的真实配置提供从原理到实战的完整参考。读者读完后将能够读懂任意 channel config 中的策略定义、自行设计签名策略并理解策略在通道读写、链码背书、系统管理中的实际作用。什么是策略Policy在 Fabric 中策略本质上是一个函数它接收一组签名数据signed data作为输入当签名数据满足策略要求时评估成功返回 nil否则返回错误指出签名数据中某些方面未满足策略。更具体地说策略用来判定某数据的签名者或签名者集合是否满足某个条件从而确认正确的参与方已经同意了一笔交易或一项变更。例如一个策略可以定义5 个不同组织中的任意 2 个组织的管理员必须签名任意组织的任意成员必须签名两个特定证书必须都签名。这些只是最简单的例子借助下面的策略类型可以构造出功能强大得多的规则。策略的运行时接口在仓库源码 common/policies/policy.go 中策略被抽象为Policy接口包含两个核心评估方法type Policy interface { // EvaluateSignedData 接收一组 SignedData评估 // 1) 签名相对于相关消息是否有效 // 2) 签名身份是否满足策略 EvaluateSignedData(signatureSet []*protoutil.SignedData) error // EvaluateIdentities 接收一组身份评估它们是否满足策略 EvaluateIdentities(identities []mspi.Identity) error }EvaluateSignedData首先通过policies.SignatureSetToValidIdentities同样位于 common/policies/policy.go对签名集进行合法性校验与去重再委托给EvaluateIdentities做策略判定。这套接口是所有策略实现包括下面的两种类型的统一契约。策略的两种类型Fabric 目前实现了两种策略类型SignaturePolicy签名策略功能最强的一种。它以 MSP PrincipalMSP 主体的求值规则组合来表达策略支持任意组合的AND、OR、NOutOf从而可以构造诸如组织 A 的管理员加上另外 2 个管理员或者 20 个组织管理员中的 11 个这样极其强大的规则。ImplicitMetaPolicy隐式元策略灵活性不如 SignaturePolicy仅在配置上下文中有效。它聚合配置层级中更深处策略的求值结果——这些底层策略最终仍由 SignaturePolicy 定义。它擅长表达组织管理员策略的大多数这类好的默认规则。策略的 Protobuf 编码两种策略都被编码在common.Policy消息中其定义位于fabric-protos/common/policies.protomessage Policy { enum PolicyType { UNKNOWN 0; // 保留用于检查是否正确初始化 SIGNATURE 1; MSP 2; IMPLICIT_META 3; } int32 type 1; // 对外部实现者前 1000 个类型编号保留否则使用 PolicyType 之一 bytes policy 2; }编码时只需选择SIGNATURE或IMPLICIT_META作为type字段的值再把对应策略实现 proto 的 marshal 结果填入policy字段即可。注意UNKNOWN0类型仅用于初始化检查而MSP2类型在当前实现中不实际使用。在 common/policies/policy.go 的ManagerImpl.NewManagerImpl中可以看到配置管理器在解析策略时依据policy.GetType()分派IMPLICIT_META类型走NewImplicitMetaPolicy其余类型则从providers注册表中查找对应的Provider如 cauthdsl 提供的 SignaturePolicy Provider进行编译未知类型会直接报错保证配置的严格性。通道配置与策略的层级结构通道配置表现为配置组ConfigGroup的层级结构每个配置组都关联一组 Values 和 Policies。对于一个配置合理的、包含两个应用组织和排序组织的应用通道其配置最小形态如下Channel: Policies: Readers Writers Admins Groups: Orderer: Policies: Readers Writers Admins Groups: OrderingOrganization1: Policies: Readers Writers Admins Application: Policies: Readers ----------- Writers Admins Groups: ApplicationOrganization1: Policies: Readers Writers Admins ApplicationOrganization2: Policies: Readers Writers Admins上图中用-------标记的Writers策略可以用简写路径/Channel/Application/Writers引用。注意形似目录路径的各段是组名而最后形似文件名的部分是策略名。仓库源码 common/policies/policy.go 中定义了这些标准策略路径的常量例如ChannelReaders/Channel/Readers涵盖排序与应用的读者策略ChannelApplicationReaders/Channel/Application/ReadersChannelApplicationAdmins/Channel/Application/AdminsBlockValidation/Channel/Orderer/BlockValidationChannelOrdererWriters/Channel/Orderer/Writers。系统不同组件会引用这些策略名来完成访问控制。例如在 orderer 上调用Deliver服务请求签名必须满足/Channel/Readers策略而要将区块通过 gossip 发给 peer则要求满足/Channel/Application/Readers策略。通过设置不同的策略系统即可获得丰富的访问控制能力。这在sampleconfig/configtx.yaml的 ACL 映射中体现得非常直观——例如_lifecycle/CommitChaincodeDefinition映射到/Channel/Application/Writersqscc/GetBlockByNumber映射到/Channel/Application/Readers。构造 SignaturePolicy签名策略与所有策略一样SignaturePolicy 以 protobuf 表达message SignaturePolicyEnvelope { int32 version 1; SignaturePolicy policy 2; repeated MSPPrincipal identities 3; } message SignaturePolicy { message NOutOf { int32 N 1; repeated SignaturePolicy policies 2; } oneof Type { int32 signed_by 1; NOutOf n_out_of 2; } }外层SignaturePolicyEnvelope定义了一个版本当前仅支持0common/cauthdsl/policy.go 中NewPolicy会校验版本必须为 0、一组以MSPPrincipal表达的身份以及一个通过索引引用这些identities的策略规则。SignaturePolicy是一个递归数据结构它要么表示来自特定MSPPrincipal的单一签名要求要么表示一组SignaturePolicy的集合要求其中N个得到满足。基本示例双签名策略SignaturePolicyEnvelope{ version: 0, policy: SignaturePolicy{ n_out_of: NOutOf{ N: 2, policies: [ SignaturePolicy{ signed_by: 0 }, SignaturePolicy{ signed_by: 1 }, ], }, }, identities: [mspP1, mspP2], }该策略作用于 MSP PrincipalmspP1和mspP2要求签名集中同时存在一个满足mspP1的签名和一个满足mspP2的签名。复杂示例嵌套 NOutOfSignaturePolicyEnvelope{ version: 0, policy: SignaturePolicy{ n_out_of: NOutOf{ N: 2, policies: [ SignaturePolicy{ signed_by: 0 }, SignaturePolicy{ n_out_of: NOutOf{ N: 1, policies: [ SignaturePolicy{ signed_by: 1 }, SignaturePolicy{ signed_by: 2 }, ], }, }, ], }, }, identities: [mspP1, mspP2, mspP3], }该策略要求一个满足mspP1的签名加上一个满足mspP2或mspP3的签名。可以看到借助递归的NOutOf几乎任意复杂的逻辑都可以用 SignaturePolicy 表达。源码层面的编译与求值从源码结构看common/cauthdsl/cauthdsl.go 中的compile函数会把上述 protobuf 结构递归编译成 Go 可执行的闭包SignaturePolicy_SignedBy分支校验索引t.SignedBy是否在identities范围内然后对签名集中每个未使用used[i] false的身份调用sd.SatisfiesPrincipal(signedByID)进行匹配成功后把该身份标记为已使用并返回 trueSignaturePolicy_NOutOf_分支递归编译所有子策略统计满足的子策略个数verified当verified N时该门gate求值成功。这正是AND / OR / NOutOf 任意组合能力的来源。而 common/cauthdsl/policy.go 的provider.NewPolicy负责将策略字节反序列化、校验版本并调用compile生成可评估的policy实例使其实现policies.Policy接口。已知限制签名消耗顺序限制在针对签名集评估签名策略时签名会按照它们出现的顺序被消耗consumed无论它们是否满足多个策略主体。例如考虑一个需要如下签名的策略2 of [org1.Member, org1.Admin]该策略的朴素意图是要求一个管理员和一个成员都签名。对于签名集[org1.MemberSignature, org1.AdminSignature]策略求值为 true正如预期。然而对于签名集[org1.AdminSignature, org1.MemberSignature]这个签名集不满足该策略。失败原因是当org1.AdminSignature满足了org1.Member角色时它就被org1.Member需求消耗掉了而org1.MemberSignature无法满足org1.Admin主体因此策略求值为 false。这一行为与 common/cauthdsl/cauthdsl.go 中compile函数里used数组的标记逻辑完全一致——每个身份在签名集遍历中一旦被某条signed_by规则使用后续规则便会跳过它。规避方法在策略 identities 规范中身份应按从最高权限到最低权限排序在签名集中签名应按从最低权限到最高权限排序。MSP PrincipalsMSP 主体MSP Principal 是密码学身份的广义概念。虽然 MSP 框架设计上可与 X.509 以外的密码学类型协同工作但本文档默认底层 MSP 实现为基于 X.509 的默认 MSP 类型。MSPPrincipal 定义于fabric-protos/msp_principal.protomessage MSPPrincipal { enum Classification { ROLE 0; ORGANIZATION_UNIT 1; IDENTITY 2; } Classification principal_classification 1; bytes principal 2; }principal_classification必须设为ROLE或IDENTITY。ORGANIZATIONAL_UNIT在本文档写作时尚未实现仓库代码中同样没有对应实现。IDENTITY类型principal字段设置为证书字面量的字节ROLE类型更常用因为它允许主体匹配由该 MSP 证书颁发机构签发的多个不同证书。对于ROLE类型principal是一个被 marshal 的MSPRole消息message MSPRole { string msp_identifier 1; enum MSPRoleType { MEMBER 0; // 表示 MSP 成员 ADMIN 1; // 表示 MSP 管理员 CLIENT 2; // 表示 MSP 客户端 PEER 3; // 表示 MSP Peer } MSPRoleType role 2; }msp_identifier设为将评估该签名的 MSP 的 ID由通道配置中该组织的MSPConfigproto 定义role设为MEMBER、ADMIN、CLIENT或PEER之一。特别地MEMBER匹配该 MSP 签发的任何证书ADMIN匹配在 MSP 定义中被枚举为管理员admin的证书CLIENTPEER匹配携带客户端peer组织单元OU的证书。构造 ImplicitMetaPolicy隐式元策略ImplicitMetaPolicy只能在通道配置上下文中正确定义。它之所以Implicit隐式是因为它是基于当前配置隐式构造的之所以Meta元是因为它的求值对象不是 MSP 主体而是其他策略。它定义于fabric-protos/common/policies.protomessage ImplicitMetaPolicy { enum Rule { ANY 0; // 要求任一子策略被满足若不存在子策略恒返回 true ALL 1; // 要求所有子策略被满足 MAJORITY 2; // 要求严格多数超过一半子策略被满足 } string sub_policy 1; Rule rule 2; }求值语义示例示例一考虑定义在/Channel/Readers的策略ImplicitMetaPolicy{ rule: ANY, sub_policy: foo, }该策略会隐式选择/Channel的子组此例中为Application和Orderer取出名为foo的策略得到/Channel/Application/foo和/Channel/Orderer/foo。求值时检查这两个策略中任意一个ANY是否能无错通过若规则是ALL则要求两者都通过。示例二考虑定义在/Channel/Application/Writers的策略且配置了 3 个应用组织OrgA、OrgB、OrgCImplicitMetaPolicy{ rule: MAJORITY, sub_policy: bar, }此时收集到的策略为/Channel/Application/OrgA/bar、/Channel/Application/OrgB/bar、/Channel/Application/OrgC/bar。由于规则要求MAJORITY该策略要求 3 个组织的bar策略中至少 2 个被满足。源码实现细节common/policies/implicitmeta.go 中的NewImplicitMetaPolicy精确实现了上述语义它反序列化ImplicitMetaPolicy定义后遍历当前组的所有子管理器managers为每个子组取出同名子策略随后按规则计算阈值thresholdswitch definition.GetRule() { case cb.ImplicitMetaPolicy_ANY: threshold 1 case cb.ImplicitMetaPolicy_ALL: threshold len(subPolicies) case cb.ImplicitMetaPolicy_MAJORITY: threshold len(subPolicies)/2 1 } // 特例无子策略时将 0 视为 majority 或 any if len(subPolicies) 0 { threshold 0 }EvaluateSignedData则逐个对子策略求值每成功一个就将remaining减一直到满足阈值为止——这与文档描述对更深处策略的求值结果进行聚合完全吻合。策略默认值Policy Defaults与 configtx.yaml 实战configtxgen工具使用的策略必须在 configtx.yaml 中显式指定。需要特别注意的是层级较高处的策略一律定义为ImplicitMetaPolicy而叶子节点必然定义为SignaturePolicy。这组默认值设计得很巧妙当组织数量变化时ImplicitMetaPolicy无需重新定义而每个组织可以自行选择自己的 Reader、Writer、Admin 规则和阈值。仓库示例sampleconfig/configtx.yaml样本配置 完整展示了这套策略体系该文件同时定义了SampleOrg的读者/写者/管理员/背书四类策略Policies: SampleOrgPolicies Readers: Type: Signature Rule: OR(SampleOrg.member) # 若 MSP 配置了新的 NodeOUs可使用更精确的规则 # Rule: OR(SampleOrg.admin, SampleOrg.peer, SampleOrg.client) Writers: Type: Signature Rule: OR(SampleOrg.member) Admins: Type: Signature Rule: OR(SampleOrg.admin) Endorsement: Type: Signature Rule: OR(SampleOrg.member)注意SampleOrg组织级策略的规范路径是/Channel/Application|Orderer/OrgName/PolicyName——这与文档中介绍的层级引用方式一一对应。在 Application 层级规范路径/Channel/Application/PolicyName默认策略全部是 ImplicitMeta聚合各组织同名策略Policies: ApplicationDefaultPolicies LifecycleEndorsement: Type: ImplicitMeta Rule: MAJORITY Endorsement Endorsement: Type: ImplicitMeta Rule: MAJORITY Endorsement Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY AdminsOrderer 层级规范路径/Channel/Orderer/PolicyName同样遵循高层 ImplicitMeta、叶子 Signature的约定并额外定义了区块校验策略Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins # BlockValidation 指定区块中必须包含 orderer 的哪些签名peer 才会校验通过 BlockValidation: Type: ImplicitMeta Rule: ANY WritersChannel 根层级规范路径/Channel/PolicyName则定义了系统级访问边界——注释中明确说明Readers控制谁可调用DeliverAPIWriters控制谁可调用BroadcastAPIAdmins控制谁可修改本层配置Channel: ChannelDefaults Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins策略在链码生命周期与 ACL 中的应用除了通道配置策略还渗透到链码与系统资源访问控制中。从 sampleconfig/configtx.yaml 的 ACLs 默认段可以看到大量资源到策略路径的映射例如链码生命周期_lifecycle的CheckCommitReadiness、CommitChaincodeDefinition、QueryChaincodeDefinition均映射到/Channel/Application/Writers查询类系统链码qscc、lscc、cscc的各类查询接口映射到/Channel/Application/Readers事件订阅event/Block、event/FilteredBlock映射到/Channel/Application/Readerspeer/Propose调用链码与peer/ChaincodeToChaincode链码间调用映射到/Channel/Application/Writers。这意味着通道的 Writers 策略一旦被修改所有依赖该策略的链码提交、提案与配置更新操作的访问控制会同步生效——这正是通过设置不同策略获得丰富访问控制在真实网络中的落地形态。总结与设计建议Fabric 的策略体系可归纳为三层心智模型叶子层 SignaturePolicy由各组织自行定义直接表达谁哪个 MSP 的哪种角色、哪个证书签名才算数支持 AND / OR / NOutOf 任意嵌套组合聚合层 ImplicitMetaPolicy位于配置层级较高处隐式收集所有子组的同名策略再按 ANY / ALL / MAJORITY 规则聚合出结果从而对组织数量的增减天然免疫消费层 系统组件引用orderer 的 Deliver/Broadcast、peer 的 gossip 区块分发、链码生命周期与各类系统链码的 ACL均通过/Channel/...这样的规范路径引用策略完成鉴权。在设计自己的通道策略时请务必记住两条关键原则遵循层级约定高层用 ImplicitMeta 聚合、叶子用 Signature 落地这样组织扩展时无需重写聚合策略警惕签名消耗顺序策略 identities 按高权限 → 低权限排序签名集按低权限 → 高权限排序避免出现2 of [org1.Member, org1.Admin]在签名顺序变化时求值失败的陷阱。赞分享区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载相关推荐Hyperledger Fabric 策略Policies完全指南从 Signature 与 ImplicitMeta 语法到通道配置实战Hyperledger Fabric 策略Policies完全指南从 Signature 与 ImplicitMeta 语法到通道配置实战 导读 本指南区块链密码学Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略与 ACL 实战解析Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略与 ACL 实战解析 通道是组织之间进行私有通信区块链密码学Hyperledger Fabric 背书策略Endorsement Policy完全指南链码级、集合级与键级配置与验证Hyperledger Fabric 背书策略Endorsement Policy完全指南链码级、集合级与键级配置与验证 导读 背书策略是 Hyperle区块链密码学创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hyperledger Fabric 通道配置策略（Policy）完全指南：SignaturePolicy 与 ImplicitMetaPolicy 原理与实践
区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载Hyperledger Fabric 作为一个企业级许可制permissioned分布式账本框架其整个区块链网络的配置均由策略Policy管理。本文以仓库文档 docs/source/policies.rst 为骨架系统讲解 Fabric 策略的核心概念、两种策略类型SignaturePolicy 与 ImplicitMetaPolicy的构造原理、通道配置中的层级结构与默认策略并结合仓库源码common/policies、common/cauthdsl与sampleconfig/configtx.yaml中的真实配置提供从原理到实战的完整参考。读者读完后将能够读懂任意 channel config 中的策略定义、自行设计签名策略并理解策略在通道读写、链码背书、系统管理中的实际作用。什么是策略Policy在 Fabric 中策略本质上是一个函数它接收一组签名数据signed data作为输入当签名数据满足策略要求时评估成功返回 nil否则返回错误指出签名数据中某些方面未满足策略。更具体地说策略用来判定某数据的签名者或签名者集合是否满足某个条件从而确认正确的参与方已经同意了一笔交易或一项变更。例如一个策略可以定义5 个不同组织中的任意 2 个组织的管理员必须签名任意组织的任意成员必须签名两个特定证书必须都签名。这些只是最简单的例子借助下面的策略类型可以构造出功能强大得多的规则。策略的运行时接口在仓库源码 common/policies/policy.go 中策略被抽象为Policy接口包含两个核心评估方法type Policy interface { // EvaluateSignedData 接收一组 SignedData评估 // 1) 签名相对于相关消息是否有效 // 2) 签名身份是否满足策略 EvaluateSignedData(signatureSet []*protoutil.SignedData) error // EvaluateIdentities 接收一组身份评估它们是否满足策略 EvaluateIdentities(identities []mspi.Identity) error }EvaluateSignedData首先通过policies.SignatureSetToValidIdentities同样位于 common/policies/policy.go对签名集进行合法性校验与去重再委托给EvaluateIdentities做策略判定。这套接口是所有策略实现包括下面的两种类型的统一契约。策略的两种类型Fabric 目前实现了两种策略类型SignaturePolicy签名策略功能最强的一种。它以 MSP PrincipalMSP 主体的求值规则组合来表达策略支持任意组合的AND、OR、NOutOf从而可以构造诸如组织 A 的管理员加上另外 2 个管理员或者 20 个组织管理员中的 11 个这样极其强大的规则。ImplicitMetaPolicy隐式元策略灵活性不如 SignaturePolicy仅在配置上下文中有效。它聚合配置层级中更深处策略的求值结果——这些底层策略最终仍由 SignaturePolicy 定义。它擅长表达组织管理员策略的大多数这类好的默认规则。策略的 Protobuf 编码两种策略都被编码在common.Policy消息中其定义位于fabric-protos/common/policies.protomessage Policy { enum PolicyType { UNKNOWN 0; // 保留用于检查是否正确初始化 SIGNATURE 1; MSP 2; IMPLICIT_META 3; } int32 type 1; // 对外部实现者前 1000 个类型编号保留否则使用 PolicyType 之一 bytes policy 2; }编码时只需选择SIGNATURE或IMPLICIT_META作为type字段的值再把对应策略实现 proto 的 marshal 结果填入policy字段即可。注意UNKNOWN0类型仅用于初始化检查而MSP2类型在当前实现中不实际使用。在 common/policies/policy.go 的ManagerImpl.NewManagerImpl中可以看到配置管理器在解析策略时依据policy.GetType()分派IMPLICIT_META类型走NewImplicitMetaPolicy其余类型则从providers注册表中查找对应的Provider如 cauthdsl 提供的 SignaturePolicy Provider进行编译未知类型会直接报错保证配置的严格性。通道配置与策略的层级结构通道配置表现为配置组ConfigGroup的层级结构每个配置组都关联一组 Values 和 Policies。对于一个配置合理的、包含两个应用组织和排序组织的应用通道其配置最小形态如下Channel: Policies: Readers Writers Admins Groups: Orderer: Policies: Readers Writers Admins Groups: OrderingOrganization1: Policies: Readers Writers Admins Application: Policies: Readers ----------- Writers Admins Groups: ApplicationOrganization1: Policies: Readers Writers Admins ApplicationOrganization2: Policies: Readers Writers Admins上图中用-------标记的Writers策略可以用简写路径/Channel/Application/Writers引用。注意形似目录路径的各段是组名而最后形似文件名的部分是策略名。仓库源码 common/policies/policy.go 中定义了这些标准策略路径的常量例如ChannelReaders/Channel/Readers涵盖排序与应用的读者策略ChannelApplicationReaders/Channel/Application/ReadersChannelApplicationAdmins/Channel/Application/AdminsBlockValidation/Channel/Orderer/BlockValidationChannelOrdererWriters/Channel/Orderer/Writers。系统不同组件会引用这些策略名来完成访问控制。例如在 orderer 上调用Deliver服务请求签名必须满足/Channel/Readers策略而要将区块通过 gossip 发给 peer则要求满足/Channel/Application/Readers策略。通过设置不同的策略系统即可获得丰富的访问控制能力。这在sampleconfig/configtx.yaml的 ACL 映射中体现得非常直观——例如_lifecycle/CommitChaincodeDefinition映射到/Channel/Application/Writersqscc/GetBlockByNumber映射到/Channel/Application/Readers。构造 SignaturePolicy签名策略与所有策略一样SignaturePolicy 以 protobuf 表达message SignaturePolicyEnvelope { int32 version 1; SignaturePolicy policy 2; repeated MSPPrincipal identities 3; } message SignaturePolicy { message NOutOf { int32 N 1; repeated SignaturePolicy policies 2; } oneof Type { int32 signed_by 1; NOutOf n_out_of 2; } }外层SignaturePolicyEnvelope定义了一个版本当前仅支持0common/cauthdsl/policy.go 中NewPolicy会校验版本必须为 0、一组以MSPPrincipal表达的身份以及一个通过索引引用这些identities的策略规则。SignaturePolicy是一个递归数据结构它要么表示来自特定MSPPrincipal的单一签名要求要么表示一组SignaturePolicy的集合要求其中N个得到满足。基本示例双签名策略SignaturePolicyEnvelope{ version: 0, policy: SignaturePolicy{ n_out_of: NOutOf{ N: 2, policies: [ SignaturePolicy{ signed_by: 0 }, SignaturePolicy{ signed_by: 1 }, ], }, }, identities: [mspP1, mspP2], }该策略作用于 MSP PrincipalmspP1和mspP2要求签名集中同时存在一个满足mspP1的签名和一个满足mspP2的签名。复杂示例嵌套 NOutOfSignaturePolicyEnvelope{ version: 0, policy: SignaturePolicy{ n_out_of: NOutOf{ N: 2, policies: [ SignaturePolicy{ signed_by: 0 }, SignaturePolicy{ n_out_of: NOutOf{ N: 1, policies: [ SignaturePolicy{ signed_by: 1 }, SignaturePolicy{ signed_by: 2 }, ], }, }, ], }, }, identities: [mspP1, mspP2, mspP3], }该策略要求一个满足mspP1的签名加上一个满足mspP2或mspP3的签名。可以看到借助递归的NOutOf几乎任意复杂的逻辑都可以用 SignaturePolicy 表达。源码层面的编译与求值从源码结构看common/cauthdsl/cauthdsl.go 中的compile函数会把上述 protobuf 结构递归编译成 Go 可执行的闭包SignaturePolicy_SignedBy分支校验索引t.SignedBy是否在identities范围内然后对签名集中每个未使用used[i] false的身份调用sd.SatisfiesPrincipal(signedByID)进行匹配成功后把该身份标记为已使用并返回 trueSignaturePolicy_NOutOf_分支递归编译所有子策略统计满足的子策略个数verified当verified N时该门gate求值成功。这正是AND / OR / NOutOf 任意组合能力的来源。而 common/cauthdsl/policy.go 的provider.NewPolicy负责将策略字节反序列化、校验版本并调用compile生成可评估的policy实例使其实现policies.Policy接口。已知限制签名消耗顺序限制在针对签名集评估签名策略时签名会按照它们出现的顺序被消耗consumed无论它们是否满足多个策略主体。例如考虑一个需要如下签名的策略2 of [org1.Member, org1.Admin]该策略的朴素意图是要求一个管理员和一个成员都签名。对于签名集[org1.MemberSignature, org1.AdminSignature]策略求值为 true正如预期。然而对于签名集[org1.AdminSignature, org1.MemberSignature]这个签名集不满足该策略。失败原因是当org1.AdminSignature满足了org1.Member角色时它就被org1.Member需求消耗掉了而org1.MemberSignature无法满足org1.Admin主体因此策略求值为 false。这一行为与 common/cauthdsl/cauthdsl.go 中compile函数里used数组的标记逻辑完全一致——每个身份在签名集遍历中一旦被某条signed_by规则使用后续规则便会跳过它。规避方法在策略 identities 规范中身份应按从最高权限到最低权限排序在签名集中签名应按从最低权限到最高权限排序。MSP PrincipalsMSP 主体MSP Principal 是密码学身份的广义概念。虽然 MSP 框架设计上可与 X.509 以外的密码学类型协同工作但本文档默认底层 MSP 实现为基于 X.509 的默认 MSP 类型。MSPPrincipal 定义于fabric-protos/msp_principal.protomessage MSPPrincipal { enum Classification { ROLE 0; ORGANIZATION_UNIT 1; IDENTITY 2; } Classification principal_classification 1; bytes principal 2; }principal_classification必须设为ROLE或IDENTITY。ORGANIZATIONAL_UNIT在本文档写作时尚未实现仓库代码中同样没有对应实现。IDENTITY类型principal字段设置为证书字面量的字节ROLE类型更常用因为它允许主体匹配由该 MSP 证书颁发机构签发的多个不同证书。对于ROLE类型principal是一个被 marshal 的MSPRole消息message MSPRole { string msp_identifier 1; enum MSPRoleType { MEMBER 0; // 表示 MSP 成员 ADMIN 1; // 表示 MSP 管理员 CLIENT 2; // 表示 MSP 客户端 PEER 3; // 表示 MSP Peer } MSPRoleType role 2; }msp_identifier设为将评估该签名的 MSP 的 ID由通道配置中该组织的MSPConfigproto 定义role设为MEMBER、ADMIN、CLIENT或PEER之一。特别地MEMBER匹配该 MSP 签发的任何证书ADMIN匹配在 MSP 定义中被枚举为管理员admin的证书CLIENTPEER匹配携带客户端peer组织单元OU的证书。构造 ImplicitMetaPolicy隐式元策略ImplicitMetaPolicy只能在通道配置上下文中正确定义。它之所以Implicit隐式是因为它是基于当前配置隐式构造的之所以Meta元是因为它的求值对象不是 MSP 主体而是其他策略。它定义于fabric-protos/common/policies.protomessage ImplicitMetaPolicy { enum Rule { ANY 0; // 要求任一子策略被满足若不存在子策略恒返回 true ALL 1; // 要求所有子策略被满足 MAJORITY 2; // 要求严格多数超过一半子策略被满足 } string sub_policy 1; Rule rule 2; }求值语义示例示例一考虑定义在/Channel/Readers的策略ImplicitMetaPolicy{ rule: ANY, sub_policy: foo, }该策略会隐式选择/Channel的子组此例中为Application和Orderer取出名为foo的策略得到/Channel/Application/foo和/Channel/Orderer/foo。求值时检查这两个策略中任意一个ANY是否能无错通过若规则是ALL则要求两者都通过。示例二考虑定义在/Channel/Application/Writers的策略且配置了 3 个应用组织OrgA、OrgB、OrgCImplicitMetaPolicy{ rule: MAJORITY, sub_policy: bar, }此时收集到的策略为/Channel/Application/OrgA/bar、/Channel/Application/OrgB/bar、/Channel/Application/OrgC/bar。由于规则要求MAJORITY该策略要求 3 个组织的bar策略中至少 2 个被满足。源码实现细节common/policies/implicitmeta.go 中的NewImplicitMetaPolicy精确实现了上述语义它反序列化ImplicitMetaPolicy定义后遍历当前组的所有子管理器managers为每个子组取出同名子策略随后按规则计算阈值thresholdswitch definition.GetRule() { case cb.ImplicitMetaPolicy_ANY: threshold 1 case cb.ImplicitMetaPolicy_ALL: threshold len(subPolicies) case cb.ImplicitMetaPolicy_MAJORITY: threshold len(subPolicies)/2 1 } // 特例无子策略时将 0 视为 majority 或 any if len(subPolicies) 0 { threshold 0 }EvaluateSignedData则逐个对子策略求值每成功一个就将remaining减一直到满足阈值为止——这与文档描述对更深处策略的求值结果进行聚合完全吻合。策略默认值Policy Defaults与 configtx.yaml 实战configtxgen工具使用的策略必须在 configtx.yaml 中显式指定。需要特别注意的是层级较高处的策略一律定义为ImplicitMetaPolicy而叶子节点必然定义为SignaturePolicy。这组默认值设计得很巧妙当组织数量变化时ImplicitMetaPolicy无需重新定义而每个组织可以自行选择自己的 Reader、Writer、Admin 规则和阈值。仓库示例sampleconfig/configtx.yaml样本配置 完整展示了这套策略体系该文件同时定义了SampleOrg的读者/写者/管理员/背书四类策略Policies: SampleOrgPolicies Readers: Type: Signature Rule: OR(SampleOrg.member) # 若 MSP 配置了新的 NodeOUs可使用更精确的规则 # Rule: OR(SampleOrg.admin, SampleOrg.peer, SampleOrg.client) Writers: Type: Signature Rule: OR(SampleOrg.member) Admins: Type: Signature Rule: OR(SampleOrg.admin) Endorsement: Type: Signature Rule: OR(SampleOrg.member)注意SampleOrg组织级策略的规范路径是/Channel/Application|Orderer/OrgName/PolicyName——这与文档中介绍的层级引用方式一一对应。在 Application 层级规范路径/Channel/Application/PolicyName默认策略全部是 ImplicitMeta聚合各组织同名策略Policies: ApplicationDefaultPolicies LifecycleEndorsement: Type: ImplicitMeta Rule: MAJORITY Endorsement Endorsement: Type: ImplicitMeta Rule: MAJORITY Endorsement Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY AdminsOrderer 层级规范路径/Channel/Orderer/PolicyName同样遵循高层 ImplicitMeta、叶子 Signature的约定并额外定义了区块校验策略Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins # BlockValidation 指定区块中必须包含 orderer 的哪些签名peer 才会校验通过 BlockValidation: Type: ImplicitMeta Rule: ANY WritersChannel 根层级规范路径/Channel/PolicyName则定义了系统级访问边界——注释中明确说明Readers控制谁可调用DeliverAPIWriters控制谁可调用BroadcastAPIAdmins控制谁可修改本层配置Channel: ChannelDefaults Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins策略在链码生命周期与 ACL 中的应用除了通道配置策略还渗透到链码与系统资源访问控制中。从 sampleconfig/configtx.yaml 的 ACLs 默认段可以看到大量资源到策略路径的映射例如链码生命周期_lifecycle的CheckCommitReadiness、CommitChaincodeDefinition、QueryChaincodeDefinition均映射到/Channel/Application/Writers查询类系统链码qscc、lscc、cscc的各类查询接口映射到/Channel/Application/Readers事件订阅event/Block、event/FilteredBlock映射到/Channel/Application/Readerspeer/Propose调用链码与peer/ChaincodeToChaincode链码间调用映射到/Channel/Application/Writers。这意味着通道的 Writers 策略一旦被修改所有依赖该策略的链码提交、提案与配置更新操作的访问控制会同步生效——这正是通过设置不同策略获得丰富访问控制在真实网络中的落地形态。总结与设计建议Fabric 的策略体系可归纳为三层心智模型叶子层 SignaturePolicy由各组织自行定义直接表达谁哪个 MSP 的哪种角色、哪个证书签名才算数支持 AND / OR / NOutOf 任意嵌套组合聚合层 ImplicitMetaPolicy位于配置层级较高处隐式收集所有子组的同名策略再按 ANY / ALL / MAJORITY 规则聚合出结果从而对组织数量的增减天然免疫消费层 系统组件引用orderer 的 Deliver/Broadcast、peer 的 gossip 区块分发、链码生命周期与各类系统链码的 ACL均通过/Channel/...这样的规范路径引用策略完成鉴权。在设计自己的通道策略时请务必记住两条关键原则遵循层级约定高层用 ImplicitMeta 聚合、叶子用 Signature 落地这样组织扩展时无需重写聚合策略警惕签名消耗顺序策略 identities 按高权限 → 低权限排序签名集按低权限 → 高权限排序避免出现2 of [org1.Member, org1.Admin]在签名顺序变化时求值失败的陷阱。赞分享区块链密码学【免费下载链接】fabricHyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.项目地址https://gitcode.com/gh_mirrors/fabr/fabric点击查看免费下载相关推荐Hyperledger Fabric 策略Policies完全指南从 Signature 与 ImplicitMeta 语法到通道配置实战Hyperledger Fabric 策略Policies完全指南从 Signature 与 ImplicitMeta 语法到通道配置实战 导读 本指南区块链密码学Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略与 ACL 实战解析Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略与 ACL 实战解析 通道是组织之间进行私有通信区块链密码学Hyperledger Fabric 背书策略Endorsement Policy完全指南链码级、集合级与键级配置与验证Hyperledger Fabric 背书策略Endorsement Policy完全指南链码级、集合级与键级配置与验证 导读 背书策略是 Hyperle区块链密码学创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考