背書策略

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部分的代碼，

在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，

https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/56088.html

標籤：其他