區(qū)塊鏈密碼學(xué)【免費下載鏈接】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 作為一個企業(yè)級許可制permissioned分布式賬本框架其整個區(qū)塊鏈網(wǎng)絡(luò)的配置均由策略Policy管理。本文以倉庫文檔 docs/source/policies.rst 為骨架系統(tǒng)講解 Fabric 策略的核心概念、兩種策略類型SignaturePolicy 與 ImplicitMetaPolicy的構(gòu)造原理、通道配置中的層級結(jié)構(gòu)與默認(rèn)策略并結(jié)合倉庫源碼common/policies、common/cauthdsl與sampleconfig/configtx.yaml中的真實配置提供從原理到實戰(zhàn)的完整參考。讀者讀完后將能夠讀懂任意 channel config 中的策略定義、自行設(shè)計簽名策略并理解策略在通道讀寫、鏈碼背書、系統(tǒng)管理中的實際作用。什么是策略Policy在 Fabric 中策略本質(zhì)上是一個函數(shù)它接收一組簽名數(shù)據(jù)signed data作為輸入當(dāng)簽名數(shù)據(jù)滿足策略要求時評估成功返回 nil否則返回錯誤指出簽名數(shù)據(jù)中某些方面未滿足策略。更具體地說策略用來判定某數(shù)據(jù)的簽名者或簽名者集合是否滿足某個條件從而確認(rèn)正確的參與方已經(jīng)同意了一筆交易或一項變更。例如一個策略可以定義5 個不同組織中的任意 2 個組織的管理員必須簽名任意組織的任意成員必須簽名兩個特定證書必須都簽名。這些只是最簡單的例子借助下面的策略類型可以構(gòu)造出功能強(qiáng)大得多的規(guī)則。策略的運(yùn)行時接口在倉庫源碼 common/policies/policy.go 中策略被抽象為Policy接口包含兩個核心評估方法type Policy interface { // EvaluateSignedData 接收一組 SignedData評估 // 1) 簽名相對于相關(guān)消息是否有效 // 2) 簽名身份是否滿足策略 EvaluateSignedData(signatureSet []*protoutil.SignedData) error // EvaluateIdentities 接收一組身份評估它們是否滿足策略 EvaluateIdentities(identities []mspi.Identity) error }EvaluateSignedData首先通過policies.SignatureSetToValidIdentities同樣位于 common/policies/policy.go對簽名集進(jìn)行合法性校驗與去重再委托給EvaluateIdentities做策略判定。這套接口是所有策略實現(xiàn)包括下面的兩種類型的統(tǒng)一契約。策略的兩種類型Fabric 目前實現(xiàn)了兩種策略類型SignaturePolicy簽名策略功能最強(qiáng)的一種。它以 MSP PrincipalMSP 主體的求值規(guī)則組合來表達(dá)策略支持任意組合的AND、OR、NOutOf從而可以構(gòu)造諸如組織 A 的管理員加上另外 2 個管理員或者 20 個組織管理員中的 11 個這樣極其強(qiáng)大的規(guī)則。ImplicitMetaPolicy隱式元策略靈活性不如 SignaturePolicy僅在配置上下文中有效。它聚合配置層級中更深處策略的求值結(jié)果——這些底層策略最終仍由 SignaturePolicy 定義。它擅長表達(dá)組織管理員策略的大多數(shù)這類好的默認(rèn)規(guī)則。策略的 Protobuf 編碼兩種策略都被編碼在common.Policy消息中其定義位于fabric-protos/common/policies.protomessage Policy { enum PolicyType { UNKNOWN 0; // 保留用于檢查是否正確初始化 SIGNATURE 1; MSP 2; IMPLICIT_META 3; } int32 type 1; // 對外部實現(xiàn)者前 1000 個類型編號保留否則使用 PolicyType 之一 bytes policy 2; }編碼時只需選擇SIGNATURE或IMPLICIT_META作為type字段的值再把對應(yīng)策略實現(xiàn) proto 的 marshal 結(jié)果填入policy字段即可。注意UNKNOWN0類型僅用于初始化檢查而MSP2類型在當(dāng)前實現(xiàn)中不實際使用。在 common/policies/policy.go 的ManagerImpl.NewManagerImpl中可以看到配置管理器在解析策略時依據(jù)policy.GetType()分派IMPLICIT_META類型走NewImplicitMetaPolicy其余類型則從providers注冊表中查找對應(yīng)的Provider如 cauthdsl 提供的 SignaturePolicy Provider進(jìn)行編譯未知類型會直接報錯保證配置的嚴(yán)格性。通道配置與策略的層級結(jié)構(gòu)通道配置表現(xiàn)為配置組ConfigGroup的層級結(jié)構(gòu)每個配置組都關(guān)聯(lián)一組 Values 和 Policies。對于一個配置合理的、包含兩個應(yīng)用組織和排序組織的應(yīng)用通道其配置最小形態(tài)如下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上圖中用-------標(biāo)記的Writers策略可以用簡寫路徑/Channel/Application/Writers引用。注意形似目錄路徑的各段是組名而最后形似文件名的部分是策略名。倉庫源碼 common/policies/policy.go 中定義了這些標(biāo)準(zhǔn)策略路徑的常量例如ChannelReaders/Channel/Readers涵蓋排序與應(yīng)用的讀者策略ChannelApplicationReaders/Channel/Application/ReadersChannelApplicationAdmins/Channel/Application/AdminsBlockValidation/Channel/Orderer/BlockValidationChannelOrdererWriters/Channel/Orderer/Writers。系統(tǒng)不同組件會引用這些策略名來完成訪問控制。例如在 orderer 上調(diào)用Deliver服務(wù)請求簽名必須滿足/Channel/Readers策略而要將區(qū)塊通過 gossip 發(fā)給 peer則要求滿足/Channel/Application/Readers策略。通過設(shè)置不同的策略系統(tǒng)即可獲得豐富的訪問控制能力。這在sampleconfig/configtx.yaml的 ACL 映射中體現(xiàn)得非常直觀——例如_lifecycle/CommitChaincodeDefinition映射到/Channel/Application/Writersqscc/GetBlockByNumber映射到/Channel/Application/Readers。構(gòu)造 SignaturePolicy簽名策略與所有策略一樣SignaturePolicy 以 protobuf 表達(dá)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定義了一個版本當(dāng)前僅支持0common/cauthdsl/policy.go 中NewPolicy會校驗版本必須為 0、一組以MSPPrincipal表達(dá)的身份以及一個通過索引引用這些identities的策略規(guī)則。SignaturePolicy是一個遞歸數(shù)據(jù)結(jié)構(gòu)它要么表示來自特定MSPPrincipal的單一簽名要求要么表示一組SignaturePolicy的集合要求其中N個得到滿足?；臼纠p簽名策略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的簽名。復(fù)雜示例嵌套 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幾乎任意復(fù)雜的邏輯都可以用 SignaturePolicy 表達(dá)。源碼層面的編譯與求值從源碼結(jié)構(gòu)看common/cauthdsl/cauthdsl.go 中的compile函數(shù)會把上述 protobuf 結(jié)構(gòu)遞歸編譯成 Go 可執(zhí)行的閉包SignaturePolicy_SignedBy分支校驗索引t.SignedBy是否在identities范圍內(nèi)然后對簽名集中每個未使用used[i] false的身份調(diào)用sd.SatisfiesPrincipal(signedByID)進(jìn)行匹配成功后把該身份標(biāo)記為已使用并返回 trueSignaturePolicy_NOutOf_分支遞歸編譯所有子策略統(tǒng)計滿足的子策略個數(shù)verified當(dāng)verified N時該門gate求值成功。這正是AND / OR / NOutOf 任意組合能力的來源。而 common/cauthdsl/policy.go 的provider.NewPolicy負(fù)責(zé)將策略字節(jié)反序列化、校驗版本并調(diào)用compile生成可評估的policy實例使其實現(xiàn)policies.Policy接口。已知限制簽名消耗順序限制在針對簽名集評估簽名策略時簽名會按照它們出現(xiàn)的順序被消耗consumed無論它們是否滿足多個策略主體。例如考慮一個需要如下簽名的策略2 of [org1.Member, org1.Admin]該策略的樸素意圖是要求一個管理員和一個成員都簽名。對于簽名集[org1.MemberSignature, org1.AdminSignature]策略求值為 true正如預(yù)期。然而對于簽名集[org1.AdminSignature, org1.MemberSignature]這個簽名集不滿足該策略。失敗原因是當(dāng)org1.AdminSignature滿足了org1.Member角色時它就被org1.Member需求消耗掉了而org1.MemberSignature無法滿足org1.Admin主體因此策略求值為 false。這一行為與 common/cauthdsl/cauthdsl.go 中compile函數(shù)里used數(shù)組的標(biāo)記邏輯完全一致——每個身份在簽名集遍歷中一旦被某條signed_by規(guī)則使用后續(xù)規(guī)則便會跳過它。規(guī)避方法在策略 identities 規(guī)范中身份應(yīng)按從最高權(quán)限到最低權(quán)限排序在簽名集中簽名應(yīng)按從最低權(quán)限到最高權(quán)限排序。MSP PrincipalsMSP 主體MSP Principal 是密碼學(xué)身份的廣義概念。雖然 MSP 框架設(shè)計上可與 X.509 以外的密碼學(xué)類型協(xié)同工作但本文檔默認(rèn)底層 MSP 實現(xiàn)為基于 X.509 的默認(rèn) 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必須設(shè)為ROLE或IDENTITY。ORGANIZATIONAL_UNIT在本文檔寫作時尚未實現(xiàn)倉庫代碼中同樣沒有對應(yīng)實現(xiàn)。IDENTITY類型principal字段設(shè)置為證書字面量的字節(jié)ROLE類型更常用因為它允許主體匹配由該 MSP 證書頒發(fā)機(jī)構(gòu)簽發(fā)的多個不同證書。對于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設(shè)為將評估該簽名的 MSP 的 ID由通道配置中該組織的MSPConfigproto 定義role設(shè)為MEMBER、ADMIN、CLIENT或PEER之一。特別地MEMBER匹配該 MSP 簽發(fā)的任何證書ADMIN匹配在 MSP 定義中被枚舉為管理員admin的證書CLIENTPEER匹配攜帶客戶端peer組織單元OU的證書。構(gòu)造 ImplicitMetaPolicy隱式元策略ImplicitMetaPolicy只能在通道配置上下文中正確定義。它之所以Implicit隱式是因為它是基于當(dāng)前配置隱式構(gòu)造的之所以Meta元是因為它的求值對象不是 MSP 主體而是其他策略。它定義于fabric-protos/common/policies.protomessage ImplicitMetaPolicy { enum Rule { ANY 0; // 要求任一子策略被滿足若不存在子策略恒返回 true ALL 1; // 要求所有子策略被滿足 MAJORITY 2; // 要求嚴(yán)格多數(shù)超過一半子策略被滿足 } 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是否能無錯通過若規(guī)則是ALL則要求兩者都通過。示例二考慮定義在/Channel/Application/Writers的策略且配置了 3 個應(yīng)用組織OrgA、OrgB、OrgCImplicitMetaPolicy{ rule: MAJORITY, sub_policy: bar, }此時收集到的策略為/Channel/Application/OrgA/bar、/Channel/Application/OrgB/bar、/Channel/Application/OrgC/bar。由于規(guī)則要求MAJORITY該策略要求 3 個組織的bar策略中至少 2 個被滿足。源碼實現(xiàn)細(xì)節(jié)common/policies/implicitmeta.go 中的NewImplicitMetaPolicy精確實現(xiàn)了上述語義它反序列化ImplicitMetaPolicy定義后遍歷當(dāng)前組的所有子管理器managers為每個子組取出同名子策略隨后按規(guī)則計算閾值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減一直到滿足閾值為止——這與文檔描述對更深處策略的求值結(jié)果進(jìn)行聚合完全吻合。策略默認(rèn)值Policy Defaults與 configtx.yaml 實戰(zhàn)configtxgen工具使用的策略必須在 configtx.yaml 中顯式指定。需要特別注意的是層級較高處的策略一律定義為ImplicitMetaPolicy而葉子節(jié)點必然定義為SignaturePolicy。這組默認(rèn)值設(shè)計得很巧妙當(dāng)組織數(shù)量變化時ImplicitMetaPolicy無需重新定義而每個組織可以自行選擇自己的 Reader、Writer、Admin 規(guī)則和閾值。倉庫示例sampleconfig/configtx.yaml樣本配置 完整展示了這套策略體系該文件同時定義了SampleOrg的讀者/寫者/管理員/背書四類策略Policies: SampleOrgPolicies Readers: Type: Signature Rule: OR(SampleOrg.member) # 若 MSP 配置了新的 NodeOUs可使用更精確的規(guī)則 # 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組織級策略的規(guī)范路徑是/Channel/Application|Orderer/OrgName/PolicyName——這與文檔中介紹的層級引用方式一一對應(yīng)。在 Application 層級規(guī)范路徑/Channel/Application/PolicyName默認(rèn)策略全部是 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 層級規(guī)范路徑/Channel/Orderer/PolicyName同樣遵循高層 ImplicitMeta、葉子 Signature的約定并額外定義了區(qū)塊校驗策略Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins # BlockValidation 指定區(qū)塊中必須包含 orderer 的哪些簽名peer 才會校驗通過 BlockValidation: Type: ImplicitMeta Rule: ANY WritersChannel 根層級規(guī)范路徑/Channel/PolicyName則定義了系統(tǒng)級訪問邊界——注釋中明確說明Readers控制誰可調(diào)用DeliverAPIWriters控制誰可調(diào)用BroadcastAPIAdmins控制誰可修改本層配置Channel: ChannelDefaults Policies: Readers: Type: ImplicitMeta Rule: ANY Readers Writers: Type: ImplicitMeta Rule: ANY Writers Admins: Type: ImplicitMeta Rule: MAJORITY Admins策略在鏈碼生命周期與 ACL 中的應(yīng)用除了通道配置策略還滲透到鏈碼與系統(tǒng)資源訪問控制中。從 sampleconfig/configtx.yaml 的 ACLs 默認(rèn)段可以看到大量資源到策略路徑的映射例如鏈碼生命周期_lifecycle的CheckCommitReadiness、CommitChaincodeDefinition、QueryChaincodeDefinition均映射到/Channel/Application/Writers查詢類系統(tǒng)鏈碼qscc、lscc、cscc的各類查詢接口映射到/Channel/Application/Readers事件訂閱event/Block、event/FilteredBlock映射到/Channel/Application/Readerspeer/Propose調(diào)用鏈碼與peer/ChaincodeToChaincode鏈碼間調(diào)用映射到/Channel/Application/Writers。這意味著通道的 Writers 策略一旦被修改所有依賴該策略的鏈碼提交、提案與配置更新操作的訪問控制會同步生效——這正是通過設(shè)置不同策略獲得豐富訪問控制在真實網(wǎng)絡(luò)中的落地形態(tài)。總結(jié)與設(shè)計建議Fabric 的策略體系可歸納為三層心智模型葉子層 SignaturePolicy由各組織自行定義直接表達(dá)誰哪個 MSP 的哪種角色、哪個證書簽名才算數(shù)支持 AND / OR / NOutOf 任意嵌套組合聚合層 ImplicitMetaPolicy位于配置層級較高處隱式收集所有子組的同名策略再按 ANY / ALL / MAJORITY 規(guī)則聚合出結(jié)果從而對組織數(shù)量的增減天然免疫消費層 系統(tǒng)組件引用orderer 的 Deliver/Broadcast、peer 的 gossip 區(qū)塊分發(fā)、鏈碼生命周期與各類系統(tǒng)鏈碼的 ACL均通過/Channel/...這樣的規(guī)范路徑引用策略完成鑒權(quán)。在設(shè)計自己的通道策略時請務(wù)必記住兩條關(guān)鍵原則遵循層級約定高層用 ImplicitMeta 聚合、葉子用 Signature 落地這樣組織擴(kuò)展時無需重寫聚合策略警惕簽名消耗順序策略 identities 按高權(quán)限 → 低權(quán)限排序簽名集按低權(quán)限 → 高權(quán)限排序避免出現(xiàn)2 of [org1.Member, org1.Admin]在簽名順序變化時求值失敗的陷阱。贊分享區(qū)塊鏈密碼學(xué)【免費下載鏈接】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點擊查看免費下載相關(guān)推薦Hyperledger Fabric 策略Policies完全指南從 Signature 與 ImplicitMeta 語法到通道配置實戰(zhàn)Hyperledger Fabric 策略Policies完全指南從 Signature 與 ImplicitMeta 語法到通道配置實戰(zhàn) 導(dǎo)讀 本指南區(qū)塊鏈密碼學(xué)Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略與 ACL 實戰(zhàn)解析Hyperledger Fabric 通道策略完全指南Signature 策略、ImplicitMeta 策略與 ACL 實戰(zhàn)解析 通道是組織之間進(jìn)行私有通信區(qū)塊鏈密碼學(xué)Hyperledger Fabric 背書策略Endorsement Policy完全指南鏈碼級、集合級與鍵級配置與驗證Hyperledger Fabric 背書策略Endorsement Policy完全指南鏈碼級、集合級與鍵級配置與驗證 導(dǎo)讀 背書策略是 Hyperle區(qū)塊鏈密碼學(xué)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考