背书策略

Fabric支持设置两种级别的背书策略：

当验证某一交易是否满足背书策略的时候，如果该交易修改的key没有设置key级别的背书策略，那么默认使用chaincode级别的背书策略进行验证，否则使用key级别的背书策略。

语法

支持三个关键字：AND、OR、OutOf，可以嵌套，下面举例说明。

AND('Org1.member', 'Org2.member', 'Org3.member')：需要三个组织的member为其背书，与OutOf(3, 'Org1.member', 'Org2.member', 'Org3.member')一致。
OR('Org1.member', 'Org2.member')：需要Org1或者Org2的member之一为其背书，OutOf(1, 'Org1.member', 'Org2.member')一致。
OR('Org1.member', AND('Org2.member', 'Org3.member'))：需要（Org1的member）或者（Org2和Org3的member）为其背书，与OutOf(1, 'Org1.member', OutOf(2, 'Org2.member', 'Org3.member'))一致。

可以看出AND和OR的表达式可以替换成只含有OutOf的表达式，而Fabric源码中第一步也是对背书策略做了这样的替换，然后继续后续的处理。

在之前的一篇博客【VSCC】中，我们介绍了VSCC的前半部分，由于Endorsement Policy有点复杂，且需要对【MSP】有些了解，我们当时没有详细讲解这部分，这里继续（建议先去看【VSCC】和【MSP】这两篇博客作为基础）。

我们从core/common/validation/statebased/validator_keylevel.go的Validate函数开始。

首先根据endorsement构建了signatureSet，然后调用了checkSBAndCCEP开始检查该tx是否满足policy
checkSBAndCCEP首先尝试（从数据库中）获取key级别的policy，如果没有的话就使用chaincode级别的policy，然后调用core/committer/txvalidator/plugin_validator.go中的Evaluate
该函数调用了common/cauthdsl/policy.go中的NewPolicy获取了一个Policy实例，然后调用该实例的Evaluate方法检查了该tx是否满足背书策略。
在NewPolicy中，调用了最关键的方法： common/cauthdsl/cauthdsl.go中的compile，该函数递归的调用自己对Policy进行检查。

chaincode data也是存到db里了，chaincode级别的policy也包含在其中。在peer开始验证chaincode级别的policy时，也是从db中获取该policy的。那么该policy是如何构建如何存进去db的？

于是我们继续看instantiate部分的代码。

扫描二维码关注公众号，回复： 11701944 查看本文章

在peer/chaincode/instantiate.go中的instantiate函数中调用了peer/chaincode/common.go中的getChaincodeSpec函数，接着getChaincodeSpec又调用了checkChaincodeCmdParams。
checkChaincodeCmdParams函数调用了common/cauthdsl/policyparser.go中的 p, err := cauthdsl.FromString(policy)来构建endorsement Policy。
然后cauthdsl模块的common/cauthdsl/cauthdsl_builder.go和common/cauthdsl/policyparser.go对用户指定的policy进行了解析，创建了SignaturePolicyEnvelope对象。
然后就是正常的交易流程了，只不过该交易chaincode是system chaincodelscc，在后续的阶段略有不同，最终在commit阶段存入db。