本Fabric中文文檔專欄的閱讀前言：前言

---

---

什么是策略

在最基礎的層面上，策略是一組規則，定義了決策是如何做出以及特定結果是如何達成的結構。為此，策略通常描述“誰”以及“做什么”，比如某人對某個資源擁有的訪問權限。我們生活中處處可見策略的使用，它們保護著我們珍視的資產，從租車、健康保險、到房屋等。

例如，保險策略定義了保險賠付的條件、條款、限額和有效期。該策略由保單持有者和保險公司共同同意，并定義了雙方的權利和責任。

而在 Hyperledger Fabric 中，策略是用于基礎設施管理的機制。Fabric 策略代表成員如何就接受或拒絕網絡、通道或智能合約的變更達成共識。策略在通道初次配置時由成員同意，但通道隨著發展還可以修改策略。

例如，策略可定義添加或移除通道成員的標準，改變區塊生成方式，或指定驗證智能合約所需的組織數量。這些行為由策略定義“誰”能夠執行。簡而言之，你想在 Fabric 網絡執行的任何操作都受策略控制。

---

為什么需要策略

策略是 Hyperledger Fabric 與 Ethereum 或 Bitcoin 等其他區塊鏈的不同之處。在那些系統中，任何節點都可以生成和驗證交易，且網絡治理策略在任何時刻都是固定且只能通過與代碼相同的過程修改。

而 Fabric 是一個許可區塊鏈，用戶由基礎設施識別，能在網絡啟動前決定網絡治理規則，也能在網絡運行時變更治理。

策略允許成員決定哪些組織可以訪問或更新 Fabric 網絡，并提供執行這些決策的機制。策略包含對特定資源（如用戶或系統鏈碼）的訪問組織列表，也指定了多少組織需要同意才能更新資源（如通道或智能合約）。

一旦策略編寫完成，它會評估附加在交易和提案上的簽名集合，驗證這些簽名是否符合網絡約定的治理標準。

---

策略如何實現

策略定義在與特定動作相關的管理域內。例如，將 peer 組織添加到通道的策略定義在 peer 組織的管理域中（即 Application 組）。同樣地，將排序節點添加到通道共識節點列表的策略則定義在 Orderer 組中。

跨 peer 和排序組織管理域的操作則包含在 Channel 組中。

通常，這些策略默認要求所在組的大多數管理員簽名（例如，大多數 peer 組織管理員；Channel 策略需大多數 peer 和排序組織管理員），但你可以定義任何規則。更多信息請查看 下文Signature 策略。

訪問控制列表 (ACLs)

網絡管理員應當關注 Fabric 中 ACL（訪問控制列表）的用途，它允許通過關聯現有策略來配置對資源的訪問權限。這些“資源”可以是系統鏈碼的函數（例如 qscc 的 “GetBlockByNumber”），也可以是其他資源（例如誰可以接收區塊事件）。ACL 引用通道配置中定義的策略，并擴展它們以控制附加資源。

默認 ACL 集位于 configtx.yaml 文件的 Application: &ApplicationDefaults 部分中，但在生產環境中應覆蓋它們。configtx.yaml 中列出的資源是 Fabric 當前定義的所有內部資源的完整列表。

在該文件中，ACL 使用如下格式表達：

# 限制調用鏈碼的 ACL:
peer/Propose: /Channel/Application/Writers

其中 peer/Proposee 表示受保護的資源，/Channel/Application/Writers 是必須滿足的策略路徑。

這行配置表示：只有滿足 '/Channel/Application/Writers' 策略的身份才能調用鏈碼。在默認 ACL 下，只要滿足對應的隱式元策略即可訪問資源。

如下圖：/Channel/Application/Writers策略滿足 peer/Propose ACL。可以使用任何writers簽名策略的客戶應用程序從任何組織提交的交易來滿足此策略。

深入了解 ACL，請參考文末的訪問控制列表(ACL) 章節。

智能合約背書政策

每個鏈碼包中的智能合約都有一個背書策略，該策略指定了需要多少來自不同通道成員的 peers 執行并驗證該事務，以使其被認為有效。因此，背書策略定義了哪些組織（通過它們的 peers）必須對提案執行進行“背書”（即批準）。

修改策略

最后，還有一種關鍵策略類型：Modification policy（修改策略）。這類策略指定了修改配置更新所需的簽名身份組。它定義了策略本身如何更新。因此，每個通道配置元素都引用了一個管理其修改的策略。

---

如何在 Fabric 中編寫策略

如果你想變更 Fabric 中的任何內容，相關資源對應的策略會說明誰需要批準，是顯式簽署還是通過群體隱式同意。在保險領域中，顯式簽署可以是單個家庭財產保險代理；隱式簽署則類似于要求多數管理團隊成員同意。

這種方式特別有用，因為組成員可能隨時間變動而無需更新策略。在 Hyperledger Fabric 中，顯式簽署策略使用 Signature 語法表示，隱式簽署則使用 ImplicitMeta 語法表示。

Signature policies

Signature 策略定義必須簽署以使策略滿足條件的用戶類型，例如 OR('Org1.peer', 'Org2.peer')。它支持構造非常具體的規則，如：“組織 A 中的一名管理員和另外兩名管理員，或者六個組織管理員中的五名”。語法支持任意組合的 AND、OR 和 NOutOf。

例如：

AND('Org1.member', 'Org2.member')

表示需要 Org1 和 Org2 各至少一名成員的簽名。

ImplicitMeta policies

ImplicitMeta 策略僅在基于配置樹的層級結構中有效，它聚合配置樹中更深層的策略結果，這些子策略最終由 Signature 策略定義。

它們稱為“Implicit”，因為它們是基于通道配置中組織動態構建的；稱為“Meta”，因為它們不是針對具體 MSP 身份，而是對配置樹下的子策略進行評估。

下圖展示了應用通道的策略層級結構，以及 ImplicitMeta 通道配置管理員策略（路徑 /Channel/Admins）在配置層級結構中是如何解析的（每個勾號表示該子策略的條件得到滿足）。

正如上圖所示，ImplicitMeta 策略，類型 = 3，使用如下語法：

<ANY|ALL|MAJORITY> <SubPolicyName>

例如：

MAJORITY Admins

圖中顯示 Admins 子策略，指的是配置樹下面的所有 Admins 策略。你可以創建自己的子策略，隨意命名，然后在各組織中定義。

我們也可以換一個形式來多維的了解策略層級關系，如下圖所示：

這張圖顯示：Channel/Application/Admins 隱式元策略可由大多數組織的 Admin 簽名策略滿足。

如果對通道提交更新的請求包含 Org1、Org2 和 Org3 的簽名，則滿足對應的策略；但如果 Org3 是第一個超過多數之后多余的簽名，其提示可能以淺綠色顯示，表示冗余。如下圖所示：

同樣，Channel/Application/Endorsement 策略可由大多數組織的 Endorsement 簽名策略滿足，這是 Fabric 鏈碼生命周期的默認背書策略。除非你明確指定其他策略，否則調用鏈碼需要大多數通道組織背書才能被加入區塊。如下圖

正如前文所述，ImplicitMeta 策略（例如 MAJORITY Admins）的一個關鍵優勢是，當你向通道添加新的管理員組織時，無需更新通道策略。因此，ImplicitMeta 策略被認為更靈活。當它最終解析為配置樹下的 Signature 子策略時，將有效控制。

你也可以定義跨組織的應用級隱式策略，例如在通道中，要求滿足 ANY、ALL 或 MAJORITY 中的任意一種。這種格式更自然，且為不同組織提供了靈活的默認值，使它們能夠確定何為有效背書。

如果包含 NodeOUs 更高的粒度控制，可以將身份類別與數字證書中的組織單位關聯。Fabric 的 NodeOUs 可以在 Fabric CA 客戶端配置文件中啟用，并與生成的身份關聯。例如，某組織啟用了特定 NodeOUs 后，可以要求“peer”簽署才能算背書有效，而未啟用的組織則可能只要求任意成員簽署。

還有一個用于驗證區塊有效性的策略：/Channel/Orderer/BlockValidation。peer 節點在接收新塊時使用此策略來確認其由通道排序節點簽發、未被篡改。默認情況下，擁有 Writers 簽名策略的排序組織可以生成和驗證區塊。

---

例子: 通道配置策略

理解策略從查看 configtx.yaml 中定義的通道策略開始。我們可以使用 Fabric 測試網絡中的 configtx.yaml 示例，查看兩種策略語法的示例。

我們將檢查 fabric-samples/test-network 示例中使用的文件。

Organizations 部分

文件第一部分定義了將成為通道成員的各組織。在每個組織定義內部，存在默認策略 Readers、Writers、Admins 和 Endorsement，當然你也可以自定義名稱。每個策略都有一個 Type，表示策略類型 (Signature 或 ImplicitMeta) 和一個 Rule。

下面的測試網絡示例展示了通道中 Org1 組織的定義。其中 Type 為 Signature，Endorsement 策略規則定義為：

"OR('Org1MSP.peer')"

表示 Org1MSP 的一個 peer 必須簽署。正是這些 Signature 策略成為 ImplicitMeta 策略指向的子策略。

- &Org1# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: Org1MSP# ID to load the MSP definition asID: Org1MSPMSPDir: ../organizations/peerOrganizations/org1.example.com/msp# Policies defines the set of policies at this level of the config tree# For organization policies, their canonical path is usually#   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>Policies:Readers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"Writers:Type: SignatureRule: "OR('Org1MSP.admin', 'Org1MSP.client')"Admins:Type: SignatureRule: "OR('Org1MSP.admin')"Endorsement:Type: SignatureRule: "OR('Org1MSP.peer')"

Application部分

接下來展示的是 ImplicitMeta 策略類型在 configtx.yaml 的 Application 區段中的用法。這一系列策略位于 /Channel/Application/ 路徑下。如果你使用默認的 Fabric ACL，這些策略定義了應用通道許多重要功能的行為，例如誰可以查詢通道賬本、調用鏈碼、或更新通道配置。這些策略指向為每個組織定義的子策略。

前文 Org1 中定義的 Reader、Writer 和 Admin 子策略，會被 Application 區域中的 Reader、Writer 和 Admin ImplicitMeta 策略所評估。因為測試網絡使用默認策略，你可以使用上述 Org1 示例來查詢通道賬本、調用鏈碼以及批準所創建測試網絡通道的更新。

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults# Organizations is the list of orgs which are defined as participants on# the application side of the networkOrganizations:# Policies defines the set of policies at this level of the config tree# For Application policies, their canonical path is#   /Channel/Application/<PolicyName>Policies:Readers:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

注：完整的文件詳解請看本專欄 《configtx通道配置文件》 一文。

---

Fabric 鏈碼生命周期

Fabric 鏈碼生命周期在鏈碼由組織成員批準并提交到通道過程中使用策略。

configtx.yaml 文件的 Application 區段包含默認鏈碼生命周期背書策略。在生產環境中，通常會根據具體應用場景自定義該策略。

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults# Organizations is the list of orgs which are defined as participants on# the application side of the networkOrganizations:# Policies defines the set of policies at this level of the config tree# For Application policies, their canonical path is#   /Channel/Application/<PolicyName>Policies:Readers:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"LifecycleEndorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"Endorsement:Type: ImplicitMetaRule: "MAJORITY Endorsement"

• LifecycleEndorsement 策略控制誰需要批準鏈碼定義。

• Endorsement 策略是鏈碼的默認背書策略。

---

鏈碼背書策略

當鏈碼通過 Fabric 鏈碼生命周期審批并提交到通道時，需要指定背書策略（一個策略適用于與該鏈碼相關的所有狀態）。背書策略可通過引用通道配置中定義的策略，或顯式使用 Signature 策略指定。

如果在審批階段未顯式指定背書策略，則使用通道的 Endorsement 策略，默認值為 "MAJORITY Endorsement"，意味著通道中大多數組織的 peer 必須執行一次交易，才能使其被視為有效。該默認策略允許加入通道的新組織自動成為鏈碼背書策略的一部分。

如需使用非默認背書策略，可使用 Signature 策略格式指定更復雜的條件（例如要求一個組織背書，再加上通道中另一個組織的背書）。

Signature 策略還支持使用 principals，它可以將身份映射為角色。principals 類似于用戶 ID 或組 ID，但更通用，因為它們可以包含身份的諸多屬性，如組織、組織單位、角色，甚至特定身份。身份角色定義為 'MSP.ROLE'，其中 MSP 是 MSP ID（組織），ROLE 是四種可接受角色之一：Member、Admin、Client、Peer。這些角色在用戶通過 CA 注冊時被關聯。你也可以自定義 Fabric CA 上可用的角色。

一些有效的 principals 示例：

• 'Org0.Admin'：Org0 MSP 的管理員

• 'Org1.Member'：Org1 MSP 的成員

• 'Org1.Client'：Org1 MSP 的客戶端

• 'Org1.Peer'：Org1 MSP 的 Peer

• 'OrdererOrg.Orderer'：排序組織 MSP 的排序節點

在某些情況下，特定狀態（例如某個鍵值對）可能需要不同的背書策略。這種基于狀態的背書允許你覆蓋默認的鏈碼級別背書策略，為指定鍵設置不同策略。

如需深入了解如何編寫背書策略，請參考文末的 背書策略 一章節。

---

覆蓋策略定義

Hyperledger Fabric 包含一些默認策略，適用于入門、開發和測試，但在生產環境中應進行自定義。在 configtx.yaml 文件中，你應該了解這些默認策略。通道配置策略可以擴展，除了 configtx.yaml 中默認的 Readers, Writers, Admins，你可以定義任意策略。

如需了解如何更新通道配置，請參考本專欄 《向通道中添加組織》 一文，絕大多數通道配置的修改更新步驟和文中添加組織的例子一致，區別僅在于配置文件的修改。

訪問控制列表（ACL）

什么是訪問控制列表？

注意：本主題涉及通道管理級別的訪問控制和策略。

Fabric 使用訪問控制列表（ACL）通過將一個 策略（Policy） 與一個資源關聯來管理對資源的訪問。Fabric 內置了多個默認 ACL。本篇文檔將討論它們的格式，以及如何覆蓋這些默認設置。

但在開始之前，我們先需要理解一下資源與策略的概念。

資源

用戶通過調用用戶鏈碼（user chaincode）、事件流源（events stream source），或某些系統鏈碼（system chaincode）與 Fabric 進行交互。因此，這些接口都被視為應受訪問控制保護的“資源”。

應用開發者需要了解這些資源以及它們對應的默認策略。configtx.yaml 文件中包含了這些資源的完整列表。你可以在本專欄 《configtx通道配置文件》 一文獲得詳解。 這里查看 configtx.yaml 示例文件。

在 configtx.yaml 中資源的命名形式幾乎囊括了 Fabric 當前定義的所有內部資源。命名約定類似 <component>/<resource>，例如 cscc/GetConfigBlock 指的是 CSCC 組件中的 GetConfigBlock 調用。

策略

策略是 Fabric 的核心機制，它允許檢查請求附帶的身份（或身份集合）是否滿足資源所需的策略。背書策略（endorsement policies）用于判斷交易是否被正確背書。通道配置中定義的策略既用于配置變更，也用于訪問控制，所有策略都存儲在通道配置內。

策略通常分為兩種格式：Signature 策略 或 ImplicitMeta 策略。

Signature 策略

此類策略定義必須由哪些具體用戶簽名才能滿足策略。例如：

Policies:MyPolicy:Type: SignatureRule: "OR('Org1.peer', 'Org2.peer')"

該策略表示，名為 MyPolicy 的策略只有在“Org1 的 peer”或“Org2 的 peer”簽名時才滿足。Signature 策略支持結合 AND、OR 以及 NOutOf 語法，靈活構建復雜規則，例如：“組織 A 的一名管理員和兩名其他管理員，或 20 名組織管理員中的 11 人”。

ImplicitMeta 策略

ImplicitMeta 策略會聚合配置樹中更深層定義的 Signature 策略結果。它允許使用類似“大多數組織管理員”這樣的默認規則，語法形式更簡單，例如：

<ALL|ANY|MAJORITY> <SubPolicyName>

例子：

Policies:AnotherPolicy:Type: ImplicitMetaRule: "MAJORITY Admins"

該策略表示，只需配置樹中大多數 Admins 策略滿足即可。默認策略中一般將 Admins 用于敏感或操作性的網絡行為（例如在通道上實例化鏈碼）；Writers 通常用于提出賬本更新；Readers 只能訪問信息但無更新或操作權限。如果開啟了 NodeOU 支持，還可加入新的 peer 和 client 角色。

訪問控制在哪里指定？

訪問控制默認值位于 configtx.yaml 文件中，這是 configtxgen 用來構建通道配置的模板文件。

你可以通過兩種方式更新訪問控制：一是直接編輯 configtx.yaml（用于創建新通道）；二是更新已有通道配置中的 ACL。

configtx.yaml 中 ACL 的格式

ACL 的格式由資源名稱映射到策略路徑構成，示例如下：

# 調用 peer 上鏈碼的 ACL 策略
peer/Propose: /Channel/Application/Writers# 接收區塊事件的 ACL 策略
event/Block: /Channel/Application/Readers

上述 ACL 表示：只有滿足 /Channel/Application/Writers 策略的身份才能訪問 peer/Propose；滿足 /Channel/Application/Readers 策略的身份才能訪問 event/Block。

在 configtx.yaml 中更新 ACL 默認值

如果你希望在引導網絡時覆蓋默認 ACL，或者在通道創建前修改 ACL，最佳實踐是直接編輯 configtx.yaml。

例如，將 peer/Propose ACL 默認值從 /Channel/Application/Writers 修改為某個策略 MyPolicy：

1. 在 Application.Policies 中定義一個名為 MyPolicy 的簽名策略，例如：

Policies: &ApplicationDefaultPoliciesReaders:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"MyPolicy:Type: SignatureRule: "OR('SampleOrg.admin')"

2. 在 Application: ACLs 部分，將 peer/Propose 引用的策略從舊值修改為 MyPolicy。

背書策略

每個鏈碼都有一個背書策略，用于指定在通道上哪些 peer 必須執行鏈碼并背書執行結果，才能使交易被視為有效。背書策略定義了哪些組織（通過它們的 peer）必須“背書”（即批準）提案的執行。

注意
請記住，狀態（以鍵值對形式表示）與區塊鏈數據是分離的。

作為 peer 驗證交易的一部分，每個驗證 peer 會檢查交易是否包含了符合背書策略要求的背書次數，并且背書來自預期的源（這兩個條件都由背書策略指定）。還會驗證背書是否有效（即是否來自有效證書的有效簽名）。

---

多種方式指定背書策略

默認情況下，背書策略在鏈碼定義中指定，由通道成員達成一致后提交到通道（即一個背書策略覆蓋一個鏈碼相關的所有狀態）。

對于私有數據集合，還可以在集合級別指定背書策略，該策略會覆蓋鏈碼級別的背書策略，針對私有數據集合中的鍵施加更嚴格的寫入控制。

此外，還可以針對特定公共通道狀態或私有數據集合狀態（即特定鍵值對）設置不同的背書策略。這種“基于狀態的背書”允許使用不同于鏈碼級別或集合級別的策略。例如，一個代表資產的鍵可能需要持有執照的評估員的背書，或者資產所有人（若屬于通道成員）希望他們的 peer 簽署。此類策略適用于那些需要與默認背書策略不同的資產。

---

設置鏈碼級別背書策略

鏈碼級別的背書策略在通道成員批準鏈碼定義時達成一致。在鏈碼定義提交到通道前，需要滿足 Channel/Application/LifecycleEndorsement 策略（默認是大多數應用組織的簽名）。

鏈碼一旦被提交，任何寫入數據到賬本的調用都必須經過足夠的通道成員簽名以滿足背書策略。

可以通過 CLI 在審批和提交鏈碼定義時使用 --signature-policy 標志指定背書策略。例如：

peer lifecycle chaincode approveformyorg --channelID mychannel \--signature-policy "AND('Org1MSP.member', 'Org2MSP.member')" \--name mycc --version 1.0 --package-id <package-id> --sequence 1 \--tls --cafile <tls-cert> --waitForEvent

上述命令審批了 mycc 鏈碼定義，背書策略為 AND('Org1MSP.member', 'Org2MSP.member')，要求 Org1 和 Org2 的成員都簽名。審批數達到要求后，通過以下命令提交：

peer lifecycle chaincode commit --channelID mychannel \--signature-policy "AND('Org1MSP.member', 'Org2MSP.member')" \--name mycc --version 1.0 --sequence 1 --init-required \--tls --cafile <tls-cert> --peerAddresses <peers> ...

值得注意的是，如果啟用了 MSP 的角色識別（如 peer），你可以只限制 peer 簽名：

peer lifecycle chaincode approveformyorg ... \--signature-policy "AND('Org1MSP.peer', 'Org2MSP.peer')" ...

此外，也可以使用通道配置中的策略路徑：使用 --channel-config-policy 標志選擇通道配置中的策略，如：

peer lifecycle chaincode approveformyorg ... \--channel-config-policy Channel/Application/Admins ...

如果未指定策略，默認使用 Channel/Application/Endorsement 策略，該策略要求大多數通道成員背書。該策略會隨著組織成員的增減自動更新。若使用 --signature-policy，則在組織變動時需手動更新策略，否則新加入的組織將無法背書。

---

背書策略語法

如上所述，策略以“主體（principals）”表達，形式為 'MSP.ROLE'，其中 MSP 是 MSP ID，ROLE 是以下四種之一：member、admin、client、peer。

有效主體示例：

• 'Org0MSP.admin'：Org0 內任何管理員

• 'Org1MSP.member'：Org1 內任何成員

• 'Org1MSP.peer'：Org1 的任何 peer

語法格式為：

EXPR(E[, E...])

EXPR 為 AND、OR 或 OutOf，E 可以是主體或嵌套的表達式。例如：

• AND('Org1MSP.member', 'Org2MSP.member')：要求這兩名成員的簽名

• OR('Org1MSP.member', 'Org2MSP.member')：任意一名成員簽名即可

• OR('Org1MSP.member', AND('Org2MSP.member', 'Org3MSP.member'))：Org1 成員簽名或同時有 Org2 和 Org3 成員簽名

• OutOf(1, 'Org1MSP.member', 'Org2MSP.member') 等同于 OR(...)

• OutOf(2, ...) 等同于 AND(...)，也可組合構造復雜邏輯

---

設置集合級別背書策略

在審批和提交鏈碼定義時，還可以為私有數據集合指定集合級別背書策略。若設置了此策略，則寫入該私有數據集合的事務必須滿足集合級別的背書要求。

集合級別策略可以更寬松或更嚴格，例如鏈碼層可能要求大多數組織背書，但私有集合可能要求特定組織背書。

如果未指定集合級別策略，則默認使用鏈碼級別背書策略。這在某些場景下很有用，比如授權組織能寫入他人私有集合；而在其他情況下，應強制集合級別控制，則應明確設置策略。

集合級別策略語法與鏈碼級別完全一致：在集合配置文件中使用 endorsementPolicy，可通過 signaturePolicy 或 channelConfigPolicy 設定。

---

設置鍵級別背書策略

鏈碼級別或集合級別背書策略與鏈碼生命周期綁定，只能在定義鏈碼時設置。而鍵級別背書策略可在鏈碼內部更靈活地設置和修改，作為交易讀寫集的一部分。

Shim API 提供設置和讀取背書策略的接口：

SetStateValidationParameter(key string, ep []byte) error
GetStateValidationParameter(key string) ([]byte, error)

若鍵屬于私有數據集合，則使用：

SetPrivateDataValidationParameter(collection, key string, ep []byte) error
GetPrivateDataValidationParameter(collection, key string) ([]byte, error)

Go shim 還提供 KeyEndorsementPolicy 接口方便構建策略：

type KeyEndorsementPolicy interface {Policy() ([]byte, error)AddOrgs(roleType RoleType, organizations ...string) errorDelOrgs(organizations ...string) errorListOrgs() ([]string)
}

例如，為某鍵設置兩個組織背書：調用 AddOrgs() 后用 Policy() 獲取字節表示，并傳入 SetStateValidationParameter()。

---

驗證

提交時，設置鍵值與設置背書策略在處理方式上無區別，都是狀態更新并按相同規則驗證。

• 若鍵沒有鍵級策略，則默認使用鏈碼級別或集合級別策略；

• 若首次為鍵設置鍵級策略，需滿足原先的鏈碼/集合級策略；

• 若存在鍵級策略，則其優先級高于鏈碼/集合級策略，它可以更寬松或嚴格；

• 若刪除鍵級策略（設為 nil），則回退到默認策略。

若交易修改了多個鍵且它們有不同鍵級策略，則所有相關策略都需滿足方可成立。