Policy 规则设计
本文主要是讲解一下在fabric中Policy的规则和写法,让大家有一个初步的认识,本文是基于fabric 1.1版本
Policy Type
Policy Type 目前包括两种:SIGNATURE 和 IMPLICIT_META
signature 类型的policy 本质上是由msp principals 构成的 ,可以按照以下的方式去组织policy:5个org中要有4个org admin进行签名。或者”由组织A去签名,或其他两个组织的admin进行签名”。
ImplicitMetaPolicy,此策略类型不如SignaturePolicy灵活,并且仅在配置上下文中有效。 它汇总了在配置层次结构中更深层次评估策略的结果,这些策略最终由SignaturePolicies定义。 它支持良好的默认规则,如“大多数组织管理员策略”。
message Policy {
enum PolicyType {
UNKNOWN = 0; // Reserved to check for proper initialization
SIGNATURE = 1;
MSP = 2;
IMPLICIT_META = 3;
}
int32 type = 1; // For outside implementors, consider the first 1000 types reserved, otherwise one of PolicyType
bytes policy = 2;
}
Configuration and Policies
一个channel中policies是呈一个层次结构的,每一个层次都有一个与之对应的value和policy,下面给出一个示例中,包含两个app组织和一个orderer组织:
Channel:
Policies:
Readers
Writers
Admins
Groups:
Orderer:
Policies:
Readers
Writers
Admins
Groups:
OrdereringOrganization1:
Policies:
Readers
Writers
Admins
Application:
Policies:
Readers
-----------> Writers
Admins
Groups:
ApplicationOrganization1:
Policies:
Readers
Writers
Admins
ApplicationOrganization2:
Policies:
Readers
Writers
箭头指定的策略可以简写为“/Channel/Application/Writers”,最后一个元素说明了Policy的类型,是指定写入策略的。不同的情况会去执行不同的policy,比如说:
- 一个实例去向orderer投递一个Deliver请求,就需要符合“/Channel/Readers”
- 普通客户端去执行一个 chaincode Endorsor 类型的交易就需要符合“/Channel/Application/Writers”
- gossip 协议, 去向peer发送一个gossip某块的请求,就需要符合 “/Channel/Application/Readers”
这些策略在编写的时候都是由多个的Policy嵌套组合在一起的。
构造 Signature Policies
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;
}
}
先看一下policy的部分,SignaturePolicy有AND, OR, and NoutOf 三种模式。oneof 表示结构体中要在两者中填充一个; identities,指定具体实施签名的对象。下面给出两个signatrue policy的示例:
SignaturePolicyEnvelope{
version: 0,
policy: SignaturePolicy{
n_out_of: NOutOf{
N: 2,
policies: [
SignaturePolicy{ signed_by: 0 },
SignaturePolicy{ signed_by: 1 },
],
},
},
identities: [mspP1, mspP2],
}
指定两个签名身份:mspP1、mspP2,需要两个签名,则必然mspP2和mspP2必须签名,相当于AND模式。
SignaturePolicyEnvelope{
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),指定要有两个以上的签名,其中mspP1(identities[0])必须签名,mspP2和mspP3中有一个要签名。
注意 : 签名身份未必指定是Admin,可能是一个Member。而且签名策略设计的时候需要注意,比如我们指定了以下策略:
2 of [org1.Member, org1.Admin]
我们用Admin和User1签名[Admin, User1]后发送交易去验证,会发现仍证失败了。这时因为Admin的签名在先对应了org1.Member,User1对应了org1.Admin自然会失败,如果把两个签名的顺序颠倒就可以验证通过了。
为了避免这种缺陷,应在策略身份排序中从最大特权到最小特权指定标识,并且签名应从签名集中的最小特权到最大特权排序。
参考网址
https://hyperledger-fabric.readthedocs.io/en/release-1.1/policies.html