深度解析點融區塊鏈雲服務

最新 06-22

金融科技高級專家群內部講座系列活動。

由國內外金融科技相關頂尖團隊的技術專家、學者和負責人等組成，目前僅限邀請加入。

分享內容會在微信公眾號進行首發，歡迎關注。

嘉賓介紹

講座內容

大家好，很榮幸受邀在這裡與大家深入分享一下點融區塊鏈雲服務的設計方案。

在深入分享之前，首先了解一下點融區塊鏈雲服務平台的定位和特色（如下圖所示）。我們目前全面支持Hyperledger Fabric區塊鏈。另外，也支持創建一個用於測試目的的Corda區塊鏈。

我會分享以下三個方面的內容。

Fabric網路是由Orderer節點、Peer節點、以及Fabric-CA節點組成。在生產環境中，Orderer排序服務是用Kafka實現的。不同於比特幣和乙太網等公有鏈，Fabric區塊鏈是一個授權網路，即網路中的每一個參與節點都有明確的身份。

Fabric區塊鏈本質上是一個分散式的共享賬本，它通過「通道」這樣的邏輯結構來實現賬本的隔離。具體來說，一個Fabric區塊鏈中有若干個聯盟(consortium)和若干排序服務(Orderer)組成。每個聯盟由若干組織(Organization)組成，一個組織可以屬於不同的聯盟。在聯盟的概念下可以進一步劃分成若干個通道，每個通道都有一個獨立的賬本，僅在加入通道的組織之間共享賬本數據。每個組織都管理自己的若干個Peer節點。組織中的某些Peer節點如果安裝了智能合約，並且被實例化到了某個通道上，則該節點成為該通道上的該智能合約的背書節點(Endorser)；所有的Peer節點，都是committer節點。

Fabric交易流程的主要步驟如下（細節略有省略）：

組織A的客戶端（通過SDK）發送一個交易提案分別給組織A和組織B的背書節點。

兩個背書節點驗證提案的正確性、提案用戶身份合法性，然後調用智能合約進行交易模擬生成讀寫集合，對其進行背書後將提案響應返回給客戶端。

客戶端驗證來自於兩個背書節點的提案響應的一致性。

客戶端將兩個背書節點的提案響應組裝成一個交易，發送給Orderer服務節點。後者將一批交易打包為區塊。

區塊被發送給committer節點，它們對區塊鏈中的每一個交易驗證簽名是否符合背書策略的要求，並檢查提案相應中讀集合的數據未發生改變，據此，將交易標記為有效或者無效。

每個committer節點將區塊添加到本地的區塊鏈中，被標記為有效交易的寫集合將被提交到賬本的當前狀態資料庫。並將事件通過event hub通知給客戶端。

Fabric的安全機制：

基於MSP實現了強大的身份認證機制。

實現細粒度的訪問控制策略。如：通道創建和修改策略、智能合約實例化策略、背書策略等。

Fabric1.1版本還支持針對賬本數據的加密存取等機制。

業務系統上鏈，無論是自建底層區塊鏈還是使用現有的區塊鏈雲服務，都將面臨以下幾個挑戰。

挑戰一，搭建Fabric區塊鏈物理網路不是很容易。其難點在於幾個方面：

Fabric自身的網路構成還是比較複雜的。

由於業務需要，聯盟鏈的參與組織可能不希望完全中心化的運維管理。一方面他們希望對自己的Peer節點有完全的管控；另一方面希望區塊鏈節點和自己的應用系統部署在一起。這導致聯盟鏈的節點可能分布於不同的網路環境中。因此，區塊鏈的運維管理需要在中心化和去中心化的兩極之間找到平衡點。

區塊鏈物理網路應當允許動態加入新節點。

挑戰二，Fabric區塊鏈需要能適應業務變化。從不同層面體現出區塊鏈應對變化的要求：

物理網路層要求能添加新的節點、或者對已有節點進行資源擴容以提升機器性能和存儲容量，從而應對訪問量的增加。

在Fabric區塊鏈領域模型層面，因為業務發展，需要吸納新的組織（即新合作方）加入已有聯盟和通道以共享賬本，並且升級背書策略以讓新組織參與交易背書的過程。另外往通道中增加新的節點（比如：背書節點）也會提升智能合約調用的並發能力。

新增的業務邏輯要求發布新的智能合約，然後安裝部署到通道；業務邏輯的更改，會引發對已有智能合約的升級。同樣的智能合約應該也可以復用到不同的通道，但希望對合約有一個全局的管理視圖。另外，合約在安裝部署之前，一些重要參與方會希望能審核合約代碼以確保其遵從相關業務協議，在審核完成之後對合約安裝包進行簽名背書。這樣就可以保證每個參與方都安裝的是大家一致認可的智能合約。

挑戰三，對Fabric區塊鏈的運維管理要安全可控。同樣，從不同維度看有不同的要求：

需對物理節點的資源消耗情況進行監控。

需安全地管理私鑰和證書；對於區塊鏈配置的更改需要有基於許可權控制的審核機制。某些配置更改需多方簽名同意才能完成，此時需要有一個收集簽名的機制來協調大家的共識過程。比如：允許新組織加入通道時，需大多數已有成員組織簽名同意，才能對完成對通道配置的修改。問題是：誰有權來發起對通道配置的修改請求？誰來負責收集各方簽名後再將請求提交給Orderer服務讓配置生效？

Fabric的特點是，同一份智能合約可以安裝在不同節點上，這些節點可以加入到不同的通道中。並且同一個智能合約可以被實例化(instantiate)到不同的通道上。此外，智能合約可以有不同版本。如果沒有一個統一的視圖來管理「合約–節點–通道「之間的複雜關係，那麼將是一場噩夢。

挑戰四，區塊鏈應用開發的門檻較高。主要涉及兩個方面：

開發智能合約的學習成本；

開發調用智能合約的應用程序還不是很方便。原生的Fabric SDK功能非常豐富，提供的API比較基礎，但直接用來開發應用程序會有些不便。比如，調用合約時，需要應用去實現發起提案、驗證提案響應以及組裝並發送交易的這些交易流程細節。

開發應用時，希望使用更簡單的SDK，更希望有現成的智能合約可以復用。

因此，面對「上鏈」的諸多挑戰，點融區塊鏈雲服務平台的設計初衷是：

平台整體架構

首先來看一下我們平台的整體架構，從下到上分為四個層次。

底層是IaaS層，提供組成區塊鏈的機器資源，支持公有雲、外部節點、混合雲。

在IaaS之上是PaaS層，在這一層構建起不同類型的區塊鏈，目前支持Hyperledger Fabric區塊鏈以及Corda區塊鏈的開源版本；

在區塊鏈網路之上，是區塊鏈即服務層，點融提供一些通用場景的智能合約（如：數字積分、證據鏈等），以及鼓勵第三方開發者貢獻智能合約。這樣用戶可以在「智能合約商店」中購買這些合約。

在PaaS層之上是SaaS層，實現「應用商店」，其中包含點融為一些通用場景實現的區塊鏈應用（如：供應鏈金融、證據鏈等）以及第三方開發者貢獻的區塊鏈應用。

除此之外，還提供了對應層次的配套工具：

在PaaS層，提供了點融區塊鏈客戶端用於管理私鑰和證書，以及審批對區塊鏈配置的申請。

點融區塊鏈智能合約打包工具，顧名思義，是給開發者用來打包智能合約的工具，同時也可以用來從智能合約安裝包中提取出合約源碼進行審核。

在SaaS層提供了應用開發的SDK，讓開發者更方便地開發應用。

接下來將逐次展開對每個部分的介紹。

更開放的聯盟鏈

基於點融區塊鏈雲服務可以搭建出一個非常開放的聯盟鏈。組成聯盟鏈的節點可以來自於：

公有雲，通過點融的公有雲賬號創出來的節點。

用戶自己管理的公有雲或者專有雲，這種情用戶只需將其公有雲賬戶提供給點融。這個賬戶被限定了許可權，只能用於創建虛擬機而不能幹別的。

用戶的數據中心，即私有網路。這種情況要求用戶提供的機器對公網暴露相關埠，以確保安裝部署能順利進行，以及私有網路內的Peer節點能與區塊鏈網路中的Orderder節點和其他Peer節點的gRPC通信能夠保持通暢。

以上第2、3類被稱為外部節點。

資源彈性擴展

在點融區塊鏈雲服務平台上，用戶可以使用虛擬機硬體配置模版創建虛擬機。也可以在區塊鏈建成之後添加新的節點，或者對已有節點升級資源配置。

區塊鏈的搭建方式

用戶在註冊了雲服務賬號之後，可以有三種方式來搭建區塊鏈：

創建私有鏈。

作為盟主，創建聯盟鏈。盟主可以邀請其他用戶（擁有自己的雲服務賬號）加入聯盟鏈。

作為成員，受盟主邀請加入已有的聯盟鏈。

下圖從全局視角展示了在我們雲服務平台上私有鏈和聯盟鏈的構成方式。（被紅色小旗子標記的是盟主）

私有鏈和聯盟鏈

接下來，將介紹私有鏈和聯盟鏈的玩法。

私有鏈是由組織內部的各個機構之間組成的一個私有的區塊鏈。這裡所說的「組織」在現實中可以是一個公司或者企業。所說的「機構」是公司或企業內的某個職能部門，比如採購、財務、銷售等。Orderer節點也隸屬於某個Orderer組織。每個機構都有獨立的CA證書，使用它來為相應的Peer節點或Orderer節點簽發節點證書。下圖中反應了這樣的關係。通過一個雲服務賬號可以創出一個私有鏈網路，該賬號即為這條區塊鏈的管理員，他統一管理鏈上的所有節點，並進行配置管理。

聯盟鏈是由不同組織共同組建的一個可以在成員之間共享賬本的區塊鏈。這裡所說的「組織」在現實中對應為一個公司或者企業。舉兩個例子：一個行業協會中的不同公司為了共同的商業利益組成聯盟鏈；或者是在一個供應鏈中的上游企業與其下游供應商以及資金提供方一同組建一條聯盟鏈。在我們平台上，定義了「盟主」和「成員」兩個角色，他們都擁有獨立的雲服務賬號。盟主是聯盟鏈的發起者，通常由受各成員共同信任的組織擔當，他管理共識節點，並發起對區塊鏈相關配置的創建和更改。成員是聯盟鏈的參與者，他管理自己組織的Peer節點，並參與對區塊鏈配置管理的共識過程。聯盟鏈還支持動態加入新的成員組織，只需盟主發布邀請，並徵求已有組織同意之後將其加入相關通道即可。

基於許可權控制的區塊鏈管理

區塊鏈管理涉及三個方面：聯盟管理、通道管理和智能合約管理。我們設計了一套安全的基於許可權控制的區塊鏈管理方式，即：用戶在雲平台上發起管理請求，然後通過」點融區塊鏈客戶端「對請求進行審批。下圖中展示了這樣的操作方式，並給出了一個客戶端審批內容的示意圖。點融區塊鏈雲服務平台不保存任何的用戶私鑰。因此，我們設計了客戶端來管理用戶的私鑰和證書，它可以安裝在用戶本地的windows或者mac系統上。另外，我們讓客戶端承擔了對於配置管理的審批功能（對gRPC消息進行簽名）。因為配置管理屬於低頻次的操作，所以為了更高的安全性，在不使用時可以不啟動客戶端。

讓我們更加深入了解一下客戶端的原理。它是基於Electron和React開發的web app，具有良好的跨平台性。客戶端中有一個Crypto Service模塊負責管理私鑰和證書、以及簽名等功能，私鑰和證書被保存在一個本地的加密文件中。客戶端通過登錄點融區塊鏈雲服務後端獲取審批請求，在簽名同意之後將信息提交到雲服務後端，後者與Fabric區塊鏈網路節點進行gRPC調用以完成相關配置操作。在某些審批場景中，雲服務後端將承擔收集各成員組織簽名（通過各自客戶端）的職責，直到滿足相關簽名策略要求之後才提交給Fabric區塊鏈網路節點以完成配置。

以下給出了一個數字積分的聯盟鏈中，一個零售公司作為新成員加入通道的共識過程。假定原有通道中已經存在了三個公司分別是：航空公司、移動運營商、銀行。並且通道修改的策略為要求半數以上已有組織的簽名，修改才能被區塊鏈接受。當盟主發起邀請零售公司加入通道的請求(ChannelConfigUpdate)之後，三家公司的客戶端都可以收到該請求，對其簽名。當盟主收集到足夠簽名之後，方可提交給Orderer節點讓修改通道生效。

點融區塊鏈雲服務實現了智能合約的完整生命周期管理。當開發完智能合約之後，開發人員可以通過我們提供的智能合約打包工具將源代碼打包，然後由管理員通過點融區塊鏈客戶端將智能合約安全地上傳到雲服務平台。管理員可以將同一份智能合約發布到不同的區塊鏈上，使得合約得以復用。發布合約時需要在客戶端進行審批，當審批通過後，在智能合約的SCDS中將包含該用戶的背書表示對合約代碼的認可。合約發布到區塊鏈上之後，鏈中的所有成員組織的管理員各自將它安裝到自己的Peer節點上。接著，合約的發布者在線發起實例化請求，通過可視化的頁面選擇將合約部署到哪個通道，並指定初始化參數和背書策略，然後經由客戶端審批將合約部署到通道中。最後，平台還支持對智能合約的在線升級。