Hyperledger Fabric架構介紹 — MSP篇

運用"雲端服務"加速企業的數位轉型願景

17 min readOct 11, 2022

Hyperledger Fabric 是一個分佈式帳本解決方案平台，以模組化架構為基礎，提供高度機密性、彈性、靈活性和可擴充性。主要在支援不同組件是可插拔的，並適應整個經濟生態系統中存在的複雜性。

基本上，一般公有區塊鏈存在以下特性

分佈式帳本
帳本中的資料式不可變的
匿名性
交易資料完全透明
群體共識
智慧合約

但企業等級的區塊鏈卻要去除匿名性、交易資料完全透明、群體共識。至於為什麼要去除這些特性，有興趣的讀者可以參考"私有區塊鍊 — Hyperledger Fabric介紹"這篇文章。

主要概念

在Fabric中的每筆交易都會出現三個需要被回答的問題，而這些問題都有獨立的功能來負責。

參與到交易網路中的身分是否合法?
聲稱是合法身分的人真的是哪個合法身分的擁有者嗎?
這個有合法身分的人可以做哪些事呢?

第一個問題的回答由MSP(Membership Service Provide)負責。第二個問題則由Certificate Authority(以下簡稱CA)回答。最後則是ACL(Access Control control)，這通常是由MSP 或在channel 等級上決定的。

由於 Fabric 是一個許可制網路，區塊鏈參與者需要一種方法來向網路的其餘參與者證明他們的身份，以便在網路上進行交易。MSP是使用PKI(Public Key Infrastructure)的方式來進行身分驗證的。通常使用LADP、Windows AD 或oAuth。

Certificate Authority通過產生公鑰和私鑰來確認其身份，公鑰和私鑰形成可用於證明身份的密鑰對(key-pair)。這種身份證明需要一種被網路識別的方式，這時就需要跟MSP來搭配。例如，交易對方使用其私鑰對交易進行數位簽章或背書。 MSP 用於檢查是否允許交易對方對交易進行背書。然後使用對方憑證(certificate)中的公鑰來驗證附加到交易的簽名是否有效。因此，MSP 是允許該身份被網路的其他參與者信任和識別的機制。

讓我們回顧一下我們使用信用卡時的場景(如下圖)，Certificate Authority就像一個卡片發行商(如VISA or Mastercard) — — 它分發許多不同類型的可驗證身份。另一方面，MSP 確定商店接受哪些信用卡發行商。通過這種方式，MSP 將身份（就是信用卡）變成為角色（在商店購買東西）。

這種將可驗證身份轉變為角色的能力是 Fabric 網路運行方式的基礎，因為建立MSP需要"組織、節點和渠道"這三種資訊來確定允許誰在組織、節點和渠道這三個層級之間執行什麼樣的操作。

假設台灣有好幾家銀行共同組成的區塊鏈。每家銀行都運行對等節點(peer nodes)和排序節點(Ordering nodes)，對等節點對寫入到網路的交易進行背書。然而，每家銀行也會有不同部門和銀行帳號持有者。每個組織都會有銀行帳號持有者，但不會在網路上運行節點。銀行帳號持有者只會從他們的行動裝置或網站與銀行系統交互。那麼區塊鏈網路是如何識別和區分這些身份的呢？ CA 用於建立身份，但就像信用卡範例那樣，這些身份不能只是發出去就好，它們需要被區塊鏈的網路識別。 MSP 用於定義網路成員所信任的組織。 MSP 也是在網路中為成員提供一組角色和權限的機制。由於定義這些組織的 MSP 為網路成員所知，因此它們可用於驗證嘗試執行其被允許執行作業的網路實體。

最後，如果一個新成員要加入一個現有的網絡，我們需要一種方法來將新成員的身份變成區塊鏈網路是可以識別的東西。 MSP 是使我們能夠參與許可制區塊鏈網路的機制。要在 Fabric 網路上進行交易，成員需要：

擁有由組織信任的 CA 發行的身份(信用卡)。組織的MSP 確定組織哪些 CA可以被信任。
檢查組織的 MSP 是否已加入到渠道中。這意味著這組織得到了網路成員的認知和核可。
確保 MSP 包含在網路上的政策定義中。

甚麼是MSP

MSP實際上並沒有提供任何東西。相反，MSP 要求的是實現一組加到網路配置中的文件夾，用於內部（組織決定其管理員是誰）和外部（通過允許其他組織驗證這個實體(entities)有權限做他們可以做的作業）。Certificate Authorities產生代表身份的憑證，而 MSP 包含合法身份的清單。

MSP 通過列出受信任網域(trust domain)成員的身份來確定哪些Root CA 和Intermediate CA是可接受的，藉此來定義信任網域(trust domain)的成員或是通過確定哪些 CA 有權為其成員發行合法身份。。

但是 MSP 的能力不僅僅是列出誰是參與者或渠道成員。正是 MSP 通過識別參與者在節點或渠道上的特定權限將合法身份轉換為角色。當用戶向 Fabric CA 註冊時，admin、peer、client、orderer或member等角色(role)必須與使用者(User)關聯起來。例如，使用“peer”角色註冊的身份自然應該提供給peer。同樣，應將使用“admin”角色註冊的身份提供給組織管理員。我們後面部分會深入探討這些角色的重要性。

此外，MSP 可以允許識別已被撤銷的身份列表，但我們將討論該過程如何擴伸到 MSP。

MSP domains

MSP在區塊鏈網路中有兩個不同的域名。

Local MSP — 存在於單一個節點中
Channel MSP — 存在於渠道的配置檔中(Configuration)

Local MSPs
這是為client和node(Peers node與Orderer node)定義的。Local MSP 定義節點的權限（例如，可以操作該節點的peer admin）。Client的Local MSP（上述銀行場景中的帳戶持有者）允許用戶在其交易中作為渠道成員（例如在chaincode交易中）或作為系統中特定角色的所有者進行身份驗證，例如，在configuration transactions中是組織的管理者。

每個節點都必須定義一個Local MSP，因為它定義了誰在該等級中具有管理或參與權限（peer admin不一定是channel admin，反之亦然）。這允許在渠道脈絡之外對成員資訊進行身份驗證，並定義對特定節點的權限（例如，該節點能夠在對等節點上安裝chaincode）。一個或多個節點可以歸一個組織所有。 MSP 定義組織管理員。並且組織、組織的管理員、節點的管理員和節點本身都應該具有相同的信任來源。

一個orderer local MSP 也在節點的檔案系統上定義，並且僅適用於該節點。與對等節點一樣，一個組織只有一個Orderers，因此會有單一個MSP 來列出它信任的參與者或節點。

Channel MSP
這定義了渠道等級的管理和參與權。 Application channel上的對等節點和排序節點共享channel MSP 的相同視角，因此能夠正確驗證渠道參與者。這意味著，如果組織希望加入渠道，則需要將包含組織成員信任鏈(chain of trust)的 MSP 包含在渠道配置中。否則來自該組織身份的交易將被拒絕。 Local MSP 呈現的是檔案系統上的文件夾結構，而Channel MSP 則在渠道配置中進行描述(如下圖)。

Channel MSP 確定誰擁有渠道等級的權限。Channel MSP 定義了渠道成員的身份與渠道等級政策的實施之間的關係。渠道 MSP 包含渠道成員所在組織的 MSP。

參與渠道的每個組織都必須為其定義 MSP。實際上，我們建議在組織和 MSP 之間進行一對一的對應。 MSP 定義了哪些成員有權代表組織進行作業。這包括 MSP 本身的配置以及核可組織具有角色的管理任務，例如向渠道添加新成員。如果所有網路成員都是同一個組織或 MSP 的一部分，則會犧牲資料的隱私性。多個組織通過將分佈帳本資料僅分配給渠道成員來實現隱私性，也就是一個渠道一個分佈式帳本。如果組織內需要更多細緻度，則可以將組織進一步劃分為OU(organizational units)，我們將在後面更詳細地描述這些OU。

Channel MSP 會包含渠道上所有組織的 MSP。這不僅包括擁有對等點並呼叫chaincodes的“對等組織(peer organization)”，還包括擁有和運作Ordering service的組織。

Local MSP 僅在其應用的節點或用戶的檔案系統上定義。因此，在物理上和邏輯上，每個節點只有一個Local MSP。但是，由於渠道 MSP 可用於渠道中的所有節點，因此它們在渠道配置中定義。但是，渠道 MSP 也在渠道中每個節點的檔案系統上實體化(instantiated)，並通過共識協議保持同步。因此，雖然每個節點的Local file system上都有每個渠道 MSP 的副本，但從邏輯上來說，渠道 MSP 是廷留在渠道或網路上並由渠道或網路維護。

下圖說明了Local MSP 與Channel MSP共存在同一個網路上。

上圖中，ORG1 擁有Ordering node(誰可以加入渠道)。與 ORG1 相關的 MSP、節點的Local MSP 和在渠道上呈現 ORG1 的Global MSP 已由 ORG1 的 RCA1 建立。 Peer organization 的ORG2 也有一個用於其對等的Local MSP 和另一個代表渠道上 ORG2 的Global MSP。 ORG1 和 ORG2 都是渠道成員，在各自的管理區域內管理渠道，並信任彼此的 CA 所建立的合法身份。

組織(organization)在MSP中扮演的角色

組織是成員的邏輯管理群組。組織（orga）最重要的是它們在單一 MSP 下管理其成員。 MSP 允許將身份連接到組織。

組織與其 MSP 之間的排他關係使得以組織命名 MSP 是合理的，這是大多數政策配置(policy configurations)中使用的習慣。例如，組織 ORG1 可能有一個稱為 ORG1-MSP 之類的 MSP。在某些情況下，一個組織可能需要多個成員群組 — — 例如，其中渠道用於在企業之間執行非常不同的業務功能。在這些情況下，擁有多個 MSP 並相應地命名它們是有意義的，例如 ORG2-MSP-PARTNER-A 和 ORG2-MSP-PARTNER-B，這表示該企業可能與不同的合作夥伴建立不同的渠道。

OU與MSPs

一個組織也可以有多個OU，每個OU都有一定的職責，也稱為從屬關係。將 OU 視為組織內的一個部門。例如，ORG1 組織可能同時具有 ORG1.SALES 和 ORG1.FINANCE 這兩個部門，以反映這些單獨的業務線。當 CA 發行X.509 憑證時，憑證中的 OU field指定身份所屬的業務線。像這樣使用 OU 的一個好處是，這些OU名稱可以用於政策定義中以限制存取或用於基於屬性的存取控制的Chaincode。否則，就需要為每個組織建立單獨的 MSP。

指定 OU 不是必須的。如果不使用 OU，則作為 MSP 一部分的所有合法身份（由Root CA 和Intermediate CA 文件夾標識）都將被視為組織的成員。

Node OU roles與MSPs

此外，還有一種特殊的 OU，有時稱為Node OU，可用於將角色(role)給予一個身份。這些Node OU 角色在 $FABRIC_CFG_PATH/msp/config.yaml 文件中定義，並包含一個OU清單，OU裡的成員被視為該 MSP 所代表的組織的一部分。當我們希望將組織的成員限制為是具有特定Node OU 角色的身份（由 MSP 指定的 CA 之一簽署）的成員時，這將很有效。例如，使用Node OU，我們可以實施更細緻的背書政策，要求 Org1 peer這個組織來背書交易，而不是 Org1 的任一個成員。

為了使用Node OU 角色，必須為網路啟用“identity classification”功能。當使用基於文件夾的 MSP 結構時，這是通過在位於 MSP 文件夾根目錄的 config.yaml 文件中啟用“Node OUs”來實現的(如下所示)：

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.jasonkao-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.jasonkao-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.jasonkao-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.jasonkao-cert.pem
    OrganizationalUnitIdentifier: orderer

上面的範例中有四種Node OU角色在MSP中。分別是client/peer/admin/orderer。

這種方式讓我們使用 X509 憑證的 CommonName 屬性中存在的 OU 來區分 MSP 角色。上面的範例是指，任何由 cacerts/ca.jasonkao-cert.pem 發行的憑證。新的管理員角色意味著我們不再需要特別說明憑證放置在 MSP 目錄的 admincerts 文件夾中。相反的，admin role在用戶的合法憑證呈現的就會是 admin user。

當 Fabric 的CA 或 SDK 用於向 CA 註冊用戶時，這些角色和 OU 屬性會被分配到一個身份(identity)。隨後用CLI的方式註冊用戶會在user的 /msp 文件夾中產生憑證(產生的結構如下圖)。

產生的 ROLE 和 OU 屬性在位於 /signcerts 文件夾中的 X.509 憑證中可以看到。 ROLE 屬性被標識為 hf.Type 並且是指代替參與者在其組織內的角色（例如，指定參與者是peer）。以下顯示憑證中的一部分，顯示ROLE和 OU 在憑證中的呈現方式。

對於CHannel MSP，參與者具有管理員角色並不意味著他們可以管理特定資源。特定身份在管理系統方面的實際權限由管理系統資源的政策(policy)來決定。例如，channel policy可能指定 ORG1-SALES管理員，即具有 admin 角色和 ORG1-SALES node OU 的身份，有權限將新組織加到channel中，而 ORG1-DINANCE 管理員則沒有這樣的權限。

最後，OU 可以被不同的組織用來區分彼此。但在這種情況下，不同的組織必須為其信任鏈chain of trust)使用相同的Root CA 和Intermediate CA，並分配 OU field來識別每個組織的成員。當每個組織都具有相同的 CA 或信任鏈時，這會使系統比可能需要的更加中心化，使用這種中心化方式必須經過考量。

MSP結構

說了這麼多，以下讓我們以文件結構化方式來說明。以下是一個Local MSP在檔案系統中的文件夾及其底下子資料夾的結構。

config.yaml — 用在當啟用“Node OU”並定義角色來配置 Fabric 中的身份分類(identity classification)功能。
cacerts — 此文件夾包含由這個 MSP 代表的組織信任的Root CA 的self-signed X.509 憑證清單。這個MSP 文件夾中必須至少有一個Root CA 憑證。這是最重要的文件夾，因為它標識了所有其他憑證必須是從這邊衍生的 CA，才能被視為相對於組織成員來形成信任鏈。
intermediatecerts — 這個文件夾包含此組織信任的intermediate CA 的 X.509 憑證清單。每個憑證必須由 MSP 中的Root CA 其中之一或由其發行 CA chain最終能返回到受信任Root CA 的任何intermediate CA所衍生的。Intermediate CA 可能代表組織的不同部門細分（如 ORG1-SALES 和 ORG1-FINANCE ），或組織本身（如果將商業用的 CA 用於組織的身份管理，可能就是這種情況）。在後一種情況下，Intermediate CA 可用於表示組織部門細分。 Intermediate CA不是必需的，在這種情況下，這個文件夾將是空的。與Root CA 文件夾一樣，此文件夾定義了必須從中發行的憑證才能被視為是組織成員的 CA。
admincert — 這個在Fabric v1.4.3之後就已經廢除，故不再描述。
key store(private key) — 這個文件夾是為 peer 或 orderer node 的local MSP 定義的，並包含node的private key。這個密鑰對資料進行數位簽名 — — 例如簽署交易提案的回應，作為交易背書階段的一部分。此文件夾對於local MSP 是必需的，並且必須只包含一個private。顯然，對該文件夾的存取必須只能是admin。channel MSP 配置不包括此文件夾，因為channel MSP 主要是在提供身份驗證功能而不是數位簽章功能。如果我們有使用HSM(Hard Security Module)進行密鑰管理，哪這個此文件夾就會是空的，因為private key由 HSM 生成並存儲在 HSM 中。
signcert(public key) — 對於 peer node 或 orderer node（或在local MSP 中），此文件夾包含 CA 發行的節點憑證。該憑證代表節點的身份，該憑證對應的private可用於產生數位簽章，任何擁有該憑證副本的人都可以驗證該簽章。該文件夾對於local MSP 是必需的，並且必須包含一個public key。對於這個文件夾的存取應該一樣只有admin。
tlscerts — 這個文件夾包含此組織信任的Root CA 的self-signed X.509 憑證清單，用於使用 TLS 在節點之間進行加密通訊。 TLS 通訊的一個範例是當peer node需要連接到ordered node以便它可以接收分類帳本的更新時。此文件夾中必須至少有一個 TLS Root CA 憑證。
tlsintermediatecacerts — 此文件夾包含一個intermediate CA 憑證的清單，這用於使用 TLS 的node之間的加密通訊。當商業用的 CA 用於組織的 TLS 憑證時，這個文件夾是有用的。與membership intermediate CA 類似，指定intermediate TLS CA 不是必需的。
operationscerts — 這是與Fabric Operations Service API通訊時所需要的憑證。

而channel MSP還包含了以下額外的資料夾:

Revoked Certificates — 如果用戶的身份已被撤銷，則有關身份的識別資訊（而不是身份本身）將保存在此文件夾中。對於基於 X.509 的身份，這些標識符號是稱為SKI(Subject Key Identifier) 和AKI(Authority Access Identifier) 的字串對(strings pair)，每當使用憑證時都會對其進行檢查，以確保證書未被撤銷。這個清單在概念上與 CA 的CRL(Certificate Revocation List) 相同，但它也與組織成員資格的撤銷有關。因此，channel MSP 的管理員可以通過通告 CA 的新版CRL 來快速從組織中撤銷參與者或節點。這個“清單中的清單”是選用的。它只會在憑證被吊銷時才會更新內容。

結論

根據上面的解說。我們現在應該能夠理解了身份(identity)和 MSP 在 Hyperledger Fabric 中的作業方式。我們已經了解瞭如何使用 PKI 和 MSP 來識別在區塊鍊網絡中協同作業的參與者。除了 MSP 的物理和邏輯結構外，我們還介紹了憑證、public/private key和root of trust的作業原理。