Hyperledger Fabric架構介紹 — 政策篇

17 min readOct 13, 2022

以下我們將會介紹Fabric中的policies功能

什麼是政策(policies)?
為什麼需要政策?
如何套用政策在Fabric內
我們如何編寫政策
Chaincode的生命週期(lifecycle)
覆寫政策定義

什麼是政策(Policy)

在最基本的層面上來說，政策是一組規則，這些規則定義了如何制定決策和要達到特定結果的結構。為此，政策通常描述了"誰(Who)和什麼(What)"，例如個人對資產的存取或權利。我們可以看到，政策在我們的日常生活中被用來保護對我們有價資產，像是汽車租賃、健康照護、住房等等。

例如，保險單定義了保險賠付的條件、條款、限制和到期日。保單由投保人與保險公司共同商定，明確各方的權利和責任。

雖然為風險管理制定了保險政策，但在 Hyperledger Fabric 中，政策是整體網路基礎設施管理的機制。 Fabric 政策代表成員如何就接受或拒絕對網路、渠道或chaincode的更改達成一致。政策在渠道最初配置時由渠道中的成員同意，但也可以隨著渠道的發展而修改。例如，政策描述了從渠道中加入或刪除成員的標準，更改區塊鍊區塊的形成方式，或指定所認可的chaincode所需要多少的組織數量。所有這些操作都由定義誰(Who)可以執行操作的政策來描述。簡單來說，我們想要在 Fabric 網路上執行的所有操作都受政策控制。

政策如何實施

政策(Policy)是在政策(policies)定義的特定運行的相關管理領域(administrative domain)內定義的。例如，將對等組織加入到渠道的政策是在對等組織的管理領域（稱為Application Group）中定義的。同樣，在渠道的一群同意者中加入Ordering node由Orderer Group內的政策來控制。跨越 peer 和 orderer 組織領域的操作都包含在 Channel Group中。

通常，這些政策預設為“大多數管理員”來管理的（例如，大多數對等組織管理員，或者在渠道政策的情況下，大多數peer organizations 和orderer organizations），不過它們也可以指定給用戶所希望定義的任何規則。

Access control lists (ACLs)

網路管理員將可以在Fabric中使用ACL對網路上的資源存取或執行做出限制，ACL 可以通過將這些資源與現有政策綁定起來。這些“資源(resources)”可以是system chaincode上的函數（例如，“qscc”system chaincode上的“GetBlockByNumber”）或其他資源（例如，誰可以接收塊Block event）。 ACL 是指在Application channel configuration中定義的政策，並延伸它們以控制其他資源。預設的 Fabric ACL set在configtx.yaml這個檔案中的Application:&ApplicationDefaults 的這一部分可以看到，但它們可以而且應該在正式環境中被更動。 configtx.yaml 中命名的資源清單是 Fabric 當前定義的所有內部資源的完整集合。

在configtx.yaml檔案中，ACL的格式如下:

# ACL policy for chaincode to chaincode invocation
peer/ChaincodeToChaincode: /Channel/Application/Writers

其中 peer/ChaincodeToChaincode 代表受保護的資源，/Channel/Application/Writers 指的是必須滿足相關交易(transaction)才能被視為有效的政策。

智慧合約的背書政策

Chaincode Package中的每個智慧合約都有一個背書政策，該政策指定需要多少個屬於不同渠道成員的對等方來執行和驗證針對特定慧能合約的交易，才能使交易被視為有效。因此，背書政策定義了必須“背書(endorse)”（即批准）交易提議執行的組織（使用他們的peer來執行）。

修改政策

最後一種政策對 Fabric 中政策的作業方式至關重要，即修改政策。修改策略明定簽署（批准）任何配置更新所需要的身份群組。定義政策如何更新的還是政策。因此，每個渠道配置元素都包含對管理其修改的政策的引用。

如何將政策寫入Fabric

如果我們想變更 Fabric 中的任何內容，與資源綁定的政策會描述需要誰(who)來批准它，可以是單一個人的明確(explicit)簽署，也可以是團體的隱含簽署。在保險產業，明確的簽署可以是房屋所有人的保險代理人(就是保險公司)的單一成員(就是保險公司的員工)。隱含式(implicit)的簽署類似於要求房屋所有人的保險公司(一個群組)的大多數管理成員的批准。這非常有用，因為該群組的成員可以隨著時間的推移而改變(員工會來來去去)，而無需更新政策(因為主體是保險公司)。在 Hyperledger Fabric 中，政策中的明確宣告註銷是使用 Signature 語法來表示，而隱含式註銷使用 ImplicitMeta 語法。

Signature policies(明確宣告政策)

簽署(Signature)政策定義了必須有特定用戶的簽名才能滿足政策，例如 OR(‘OrgA.peer’, ‘OrgB.peer’)。這些政策被認為是最通用的，因為它們允許構建極其具體的規則，例如：“組織 A 的管理員與(AND)其他 2 個管理員，或 6 個組織管理員中的其中 5 個”。該語法支持 AND、OR 和 NOutOf 的任意組合。例如，可以使用 AND(‘OrgA.member’, ‘OrgB.member’) 表達其政策，這意味著需要 OrgA 中的至少一個成員和 OrgB 中的一個成員的簽名才能滿足政策。

ImplicitMeta policies(隱含式政策)

ImplicitMeta 政策只在基於是配置階層(configuration tree)中政策分層結構的渠道配置的整體脈絡中有效。 ImplicitMeta 政策聚合了配置階層中更深層次的政策結果，這些政策最終由簽署政策定義。它們是隱含的，因為它們是基於渠道配置中的當前組織隱含式建造的，它們是meta，因為它們的評估不是針對特定的 MSP 主體，而是針對配置階層中它們下面的其他子政策(sub-policies)。

下圖說明了應用程式渠道的分層策略結構，並顯示ImplicitMeta 渠道配置如何控管政策。為了要達成這個隱含式的政策，Channel/Admnins底下所有的子政策都需要被滿足。

在上圖中我們可以看到 Type 3的ImplicitMeta政策，它是使用不一樣的語法。例如:

語法是這樣 — “<ANY|ALL|MAJORITY> <SubPolicyName>”

在上圖第二層右手邊的子政策就可以寫成

`MAJORITY sub policy: Admins`

如上所述，諸如 MAJORITY Admins 之類的 ImplicitMeta 政策的一個主要效益是，當我們向渠道添加新的管理員組織(admin organization)時，我們不必更新渠道政策。因此，隨著組織數量的增加，ImplicitMeta政策的方式式更更加靈活的。我們回想一下，ImplicitMeta政策最終會在配置階層中解析它們下面的簽名子政策。

我們還可以定義應用程式等級的隱含式政策以跨組織（例如在渠道中）的方式運作，並要求滿足其中ANY、滿足ALL或滿足MAJORITY。這種格式有助於更直覺的預設設定，以便每個組織都可以決定它對有效背書的意義。

如果我們在組織定義中包含 NodeOU，則可以實現進一步的細緻度和控制。OU 在 Fabric CA client configuration檔案中定義，並且可以在建立身份時與身份綁定。在 Fabric 中，NodeOU 提供了一種在數位憑證層次結構中對身份進行分類的方法。例如，啟用了特定 NodeOU 的組織可能需要“對等節點”簽署才能成為有效的背書，而沒有任何對等節點的組織可能只需要其中一個成員簽名就可以。

範例說明: 渠道配置政策

&Org1
       # DefaultOrg defines the organization which is used in the sampleconfig
       # of the fabric.git development environment
       Name: Org1MSP

       # ID to load the MSP definition as
       ID: Org1MSP

       MSPDir: ../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: Signature
               Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
           Writers:
               Type: Signature
               Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
           Admins:
               Type: Signature
               Rule: "OR('Org1MSP.admin')"
           Endorsement:
               Type: Signature
               Rule: "OR('Org1MSP.peer')"

我們了解政策首先要檢查定義渠道策略的 configtx.yaml。我們可以使用 Fabric 測試用網路中的 configtx.yaml 檔案來展示這兩種政策語法類型。

檔案的第一部分定義了將成為渠道成員的組織(就是Org1)。每個組織定義中都有該組織的預設政策、Readers、Writers、Admins和Endorsment，不過我們是可以對政策名稱隨意命名的。每個政策都有一個描述政策如何表達的類型（Signatire或ImplicitMeta）和一個規則。

上面的範例顯示了渠道中的 Org1 組織定義，其中policy type是Signature，而Endorsement的政策規則定義成“OR(‘Org1MSP.peer’)”。此策略指定需要作為 Org1MSP 成員的對等方進行簽署。正是這些簽名策略成為ImplicitMeta 政策會指向的子策略。

################################################################################
#
#   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 network
    Organizations:

    # 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: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

下一個範例(如上圖)顯示了在 configtx.yaml 的 Application(&ApplicationDefaults) 部分中使用的 ImplicitMeta 政策類型。這些政策集位於 /Channel/Application/ 路徑上。如果我們使用預設的 Fabric ACL set，這些政策將定義應用程式渠道的許多重要功能的行為，例如誰可以查詢渠道帳本、呼叫chaincode或更新渠道配置。這些政策指向為每個組織定義的子政策。上一部分中定義的 Org1 包含由 Application 部分中的 Reader、Writer 和 Admin ImplicitMeta 等是由 Reader、Writer 和 Admin 子策略來評估的。由於範例是使用預設政策構建的，因此我們可以使用範例 Org1 來查詢渠道帳本、呼叫chaincode並批准我們建立的渠道更新。

Fabric chaincode lifecycle

在 Fabric 2.0 版本中，導入了新的chaincode lifecycle process，從而使用更民主的流程來管理網路上的chaincode。新流程允許多個組織對chaincode在渠道上使用之前的運作方式進行投票。這很重要，因為正是這個新的生命週期過程和在該過程中指定的政策的組合決定了整體網路的安全性，並且區塊鏈的本質就是民主投票(雖然這是理想)。更多的Fabric chaincode lifecycle請參考本文，但就本文而言，我們要了解如何在此流程中使用政策。新流程包括指定策略的兩個步驟：chaincode何時被組織成員批准(approved)，以及何時提交(committed)給渠道。

以下範例configtx.yaml檔案的 SECTION: Application包含了預設chaincode lifecycle endorsement policy。在正式環境中我們應該要修改成我們需要的。其中LifecycleEndorsement政策是管理誰可以核准chaincode的定義。

################################################################################
#
#   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 network
    Organizations:

    # 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: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

Chaincode endorsement policies

當chaincode被批准並使用 Fabric chaincode lifecycle提交到渠道時，就會為chaincode指定背書政策（就是一個背書政策所涵蓋與chaincode綁定的所有狀態）。可以引用渠道配置中定義的背書政策或通過明確宣告指定簽名政策來指定背書政策。

如果在批准步驟中沒有明確指定背書政策，則會使用預設的背書政策“MAJORITY Endorsement”，這意味著屬於不同渠道成員（組織）的大多數對等方需要對chaincode的交易進行執行和驗證因為要使交易被認為是有效的。此預設政策允許加入渠道的組織自動加入到chaincode背書政策中。如果我們不想使用預設背書政策，請使用Signature policy format來指定更複雜的背書政策（例如要求鏈碼由一個組織背書，然後由渠道上的其他組織的其中之一也要背書）。

簽署政策還允許我們可以包含主體(principals)，這只是將身份與角色匹配的一種方式。主體就像用戶 ID 或群組 ID，但它們更加通用，因為它們可以包含參與者身份的廣泛屬性，例如參與者的組織、OU、角色甚至參與者的特定身份。當我們談到主體時，它們是確定其權限的屬性。主體被描述為“MSP.ROLE”，其中 MSP 代表所需的 MSP ID（組織），ROLE 代表四個角色之一：Member、Admin、Cleint和Peer。當用戶向 CA 註冊時，角色與身份會被綁定。我們可以自定義 Fabric CA 上可用的角色清單。

以下為一些有效的主體範例:

‘OrgA.Admin’: OrgA MSP的管理者
‘OrgA.Member’: OrgA MSP的成員
‘OrgA.Peer’: OrgA MSP的對等節點
‘OrdererOrg.Orderer’: OrdererOrg MSP的排序者(orderer)

在某些情況下，特定狀態（特定的key-value pair）可能需要具有不同的背書政策。這種基於狀態的背書(state-based endorsement)允許預設的chaincode的背書政策被指定有著不同key-value pair的不同政策給蓋過。

這邊要特明說明的是在Fabric 2.0版之後，Fabric 導入了一個新的chaincode lifecycle process，允許多個組織chaincode在渠道中使用之前就如何運作chaincode達成協議。新流程要求組織同意定義chaincode的參數，例如名稱、版本和chaoncode背書政策。

結論

Hyperledger Fabric 包含對開發和測試區塊鏈有著通用的預設政策，但它們主要是在正式環境中進行修改的。我們應該了解 configtx.yaml 檔案中的預設政策。除了 configtx.yaml 中預設的 Readers、Writers、Admins 之外，還可以使用任意動詞(類似命令的方式)擴展渠道配置政策。