leaf

企業級區塊鏈（也稱聯盟鏈）主要針對大型公司、政府機構和產業聯盟的區塊鏈技術需求，提供企業級的區塊鏈網絡解決方案。聯盟鏈的各個節點通常對應一個實體的機構組織，節點的加入和退出需要經過授權。各個機構組成利益相關的聯盟，共同維護區塊鏈網絡的健康運轉。

與私有鏈和公有鏈不同，企業級區塊鏈更加著眼於區塊鏈技術的實際落地，在區塊鏈的性能速度和安全性、成員認證管理、數據隱私保護上有著更高的要求。除此之外，企業級區塊鏈的研發往往直接和實際業務場景相關聯，更加貼近行業痛點，為企業聯盟提供一套更加完善的一體化區塊鏈解決方案。

圖展示了聯盟鏈平台和區塊鏈應用之間的相互促進關係。一方面，聯盟鏈平台為實際行業應用研發、落地提供了底層技術支撐；另一方面，行業應用以及概念的驗證落地也推動著聯盟鏈平台的不斷發展成熟。

Hyperchain 支持企業基於現有雲平台快速部署、擴展和配置管理區塊鏈網絡，對區塊鏈網絡的運行狀態進行實時可視化監控，是符合 ChinaLedger 技術規範的國產區塊鏈核心系統平台。Hyperchain 具有驗證節點授權機制、多級加密機制、共識機制、圖靈完備的高性能智能合約執行引擎等核心特性，是一個功能完善、性能高效的聯盟鏈基礎技術平台。在面向企業和產業聯盟需求的應用場景中，Hyperchain 能夠為資產數字化、數據存證、供應鏈金融、數字票據、支付清算等多中心應用提供優質的底層區塊鏈支撐技術平台和便捷可靠的一體化解決方案。

hyperchain 的整體系統架構如圖

對於企業級聯盟鏈基礎技術平台，我們主要考慮以下基本特性：

• 參與者的成員身份認證許可機制

• 商業交易數據的安全與隱私

• 較高的交易吞吐量和較低的交易延遲

• 安全完備的智能合約引擎

• 高用戶體驗的互操作性

對於參與者成員身份認證許可機制，平台有如下功能。

• 聯盟自治 ACO。平台許可在聯盟鏈網絡中創建聯盟鏈自治成員組織，通過提案的形式進行提交和組織內部表決聯盟中的狀態行為，如系統升級、合約升級、成員管理等，這種方式為區塊鏈聯盟治理提供了一種有效模式。

• 成員管理。平台通過 CA 體系認證的方式實現了聯盟成員的準入控制，支持自建 CA 和 CFCA 兩種模式，並提供鏈級管理員、節點管理員以及普通用戶的分級權限管理機制，實現不同的權限訪問控制。

對於交易數據的安全和隱私，平台有如下功能。

• 多級加密機制。採用可插拔的加密機制，對於業務完整生命周期所涉及的數據、用戶、通信連接等方面都進行了不同策略的加密，通過多級加密保證平台數據的安全，而且完全支持國密算法。

• 隱私保護。平台提供了 Namespace 分區共識和隱私交易兩種機制實現隱私保護。其中分區共識將敏感交易數據的存儲和執行空間進行隔離，允許部分區塊鏈節點創建屬於自己的分區，分區成員之間的數據交易以及存儲對其他分區中的節點不可見。而隱私交易通過在發送時指定該筆交易的相關方，該交易明細只在相關方存儲，隱私交易的哈希在全網共識後存儲，既保證了隱私數據的有效隔離，又可驗證該隱私交易的真實性。

• 可信數據源。區塊鏈是一個封閉的確定性環境，鏈上無法主動獲取鏈外真實世界的數據，平台引入了 Oracle 預言機機制，支持將外界信息寫入區塊鏈內，完成區塊鏈與現實世界的數據互通，並且該預言機通過第三方可信機構簽名實現信任背書，滿足可證誠實的要求。

對於吞吐量以及交易延遲，平台有如下功能。

• 高效共識算法。平台採用 RBFT（Robust Byzantine Fault-Tolerant，高健壯性拜占庭容錯算法）共識算法，在保證節點數據強一致性的前提下，提升系統整體交易吞吐能力以及系統穩定性，TPS（每秒處理交易數量）達到萬級，延時可控制在 300 ms 以內，同時平台可使用基於 GPU 的驗簽加速，進一步提升整體性能，充分滿足區塊鏈商業應用的需求，並且支持動態節點管理和失效恢復機制，增強了共識模塊的容錯性和可用性。後續將集成其他共識算法（如 RAFT）以適配不同的業務場景需求。

• 數據分離。區塊鏈中賬本數據主要分為區塊數據和狀態數據兩部分，考慮到區塊數據會不斷增長，而狀態數據只會頻繁更新，平台引入了 Filelog 存儲引擎，實現區塊數據與狀態數據的分離，保證在系統數據量不斷增大的情況下讀寫性能不受影響。

對於安全完備的智能合約引擎，平台有如下功能。

• 平台支持 EVM、JVM、HVM 等多種智能合約引擎；

• 支持 Solidity、Java 等編程語言；

• 提供完善的合約生命周期管理；

• 具有編程友好、合約安全、執行高效的特性，可以適應多變複雜的業務場景。

對於高用戶體驗的互操作性，平台有如下功能。

• 數據歸檔。為解決區塊鏈中區塊式存儲數據無限增長的問題，我們通過數據歸檔的方式將一部分舊的線上數據歸檔移到線下轉存，同時提供了 Archive Reader 用於歸檔數據瀏覽。

• 數據可視化。為方便用戶實時查閱區塊鏈上的合約狀態數據，平台提供了一個數據可視化組件 Radar，能夠在區塊鏈正常運行的同時將區塊鏈中的合約狀態數據導入關係型數據庫（如 MySQL）中，使得合約狀態可視化、可監控，方便商業應用的業務統計和分析。

• 消息訂閱。平台提供統一的消息訂閱接口，以便外部系統捕獲、監聽區塊鏈平台的狀態變化，從而實現鏈上鏈下的消息互通，支持區塊事件、合約事件、交易事件、系統異常監控等事件的訂閱。

接下來就以 Hyperchain 為例，闡述構成企業級區塊鏈平台的核心技術模塊，主要就共識算法、智能合約、賬本、安全機制以及數據管理等方面的實現原理進行深入分析。

共識算法是保證區塊鏈平台各節點賬本數據一致的關鍵，目前常見的分佈式系統一致性算法包括 PoW、PoS、Paxos、Raft、PBFT 等。其中 PoW 依賴機器的計算能力獲取賬本的記帳權，資源消耗較高且可監管性弱，每次交易共識的達成需要全網共同參與計算，因此不適合聯盟鏈對監管以及性能的要求 PoS 的主要思想是節點獲得記帳權的難度與其持有的權益數量成反比，相比 PoW 性能較好，但是依然存在可監管性弱的問題。Paxos 和 Raft 是傳統分佈式系統的一致性成熟解決方案，此類型算法的性能高、消耗資源低，但是不具備對拜占庭節點的容錯。PBFT 算法同 Paxos 算法的處理流程類似，是一種許可投票、少數服從多數的共識機制。該算法具備容忍拜占庭錯誤的能力，且能夠允許強監管節點的參與，算法性能較高，適合企業級平台的開發。目前主流的企業級區塊鏈解決方案 Fabric 和 Hyperchain 都提供了 PBFT 的實現方案。然而原生 PBFT 算法在可靠性與靈活性方面不夠完善，Hyperchain 平台對可靠性與靈活性進行了增強，設計實現了 PBFT 的改進算法，即 RBFT。

1. RBFT 概述

   Hyperchain 的共識模塊採用可拔插的模塊化設計，能夠針對不同的業務場景需求選擇配置不同的共識算法，目前支持 PBFT 的改進算法 RBFT。Hyperchain 通過優化 PBFT 的執行過程，增加主動恢復與動態節點增刪等機制，極大地提高了傳統 PBFT 的可靠性與性能。RBFT 能夠將交易的延遲控制在 300 ms，並且最高可以支持每秒上萬筆的交易量，為區塊鏈的商業應用提供了穩定高性能的算法保障。下面就 RBFT 的核心算法進行詳細闡述。

2. RBFT 常規流程

   RBFT 的常規流程保證了區塊鏈各節點以相同的順序處理來自客戶端的交易。RBFT 同 PBFT 的容錯能力相同，需要至少 3f+1 個節點才能容忍f個拜占庭錯誤。圖 6.3 中的示例為最少集群節點數，其f的值為 1。圖中的 Primary 為區塊鏈節點中動態選舉出來的主節點，負責對客戶端消息的排序打包，Replica 節點為備份節點，所有 Replica 節點與 Primary 節點執行交易的邏輯相同，Replica 節點能夠在 Primary 節點失效時參與新 Primary 節點的選舉。

   RBFT 的共識保留了 PBFT 原有的三階段處理流程（PrePrepare、Prepare、Commit），但是穿插增加了重要的交易驗證環節。

RBFT 算法的常規共識流程如下所示。

(1) Client 將交易發送到區塊鏈中的任意節點。

(2) Replica 節點接收到交易之後轉發給 Primary 節點，Primary 自身也能直接接收交易消息。

(3) Primary 會將收到的交易進行打包，生成 batch 進行驗證，剔除其中的非法交易。

(4) Primary 將驗證通過的 batch 構造 PrePrepare 消息廣播給其他節點，這裡只廣播批量交易的哈希值。

(5) Replica 接收來自 Primary 的 PrePrepare 消息之後構造 Prepare 消息發送給其他 Replica 節點，表明該節點接收到來自主節點的 PrePrepare 消息並認可主節點的 batch 排序。

(6) Replica 接收到 2f個節點的 Prepare 消息之後對 batch 的消息進行合法性驗證，驗證通過之後向其他節點廣播 Commit 消息，表示自己同意了 Primary 節點的驗證結果。

(7) Replica 節點接收到 2f+1 個 Commit 之後執行 batch 中的交易並同主節點的執行結果進行驗證，驗證通過將會寫入本地賬本，並通過檢查點（checkpoint）來進行結果校驗的步驟，檢查點規則可配置。

由以上的 RBFT 常規流程可以看出，RBFT 將交易的驗證流程穿插於共識算法的整個流程中，做到了對寫入區塊結果的共識。首先，Primary 節點接收到交易之後首先進行驗證，這保證了平台的算力不會被非法交易所消耗，使 Replica 節點能夠高效地處理 Primary 節點的拜占庭失效。其次，Replica 節點在接收到 2f個 Prepare 消息之後對 Primary 節點的驗證結果進行驗證，如果結果驗證不通過則會觸發 ViewChange 消息，這再一次保證了系統的安全性。

在 PBFT 算法中，參與共識的節點可根據角色分為主節點（Primary）和從節點（Replica），從節點會將自己收到的交易轉發給主節點，主節點最重要的功能就是將收到的所有交易按照一定策略打包成塊，讓所有節點參與共識驗證。那么，一個很自然的問題就是，如果主節點發生宕機、系統錯誤或者被攻占（即成為拜占庭節點），其他從節點如何才能及時發現主節點的異常並選舉產生新的主節點繼續共識？這是保證 BFT 類算法穩定性必須要解決的問題。

PBFT 和 RBFT 中都引入了視圖（View）的概念，每次更換一個主節點同時切換視圖，視圖更換（ViewChange）機制是保證整個共識算法健壯性的關鍵。

目前能夠檢測到的主節點的拜占庭行為有 3 種情景：

(1) 節點停止工作，不再發送任何消息；

(2) 節點發送錯誤的消息，錯誤可能是消息內容不正確、包含惡意交易的消息等，需要注意的是，這裡的消息類型可能是 batch，也可能是用於視圖更換的功能性消息；

(3) 偽裝正常節點，發送正確的消息。

對於情景 (1)，可以由 nullRequest 機制保證，行為正確的主節點會在沒有交易發生時向所有從節點發送 nullRequest 來說明這一情況的屬實性，如果從節點在規定時間內沒有收到主節點的 nullRequest，則會引發視圖更換行為選舉新的主節點。

對於情景 (2)，從節點在接收主節點的消息時，會通過驗證機制檢測對內容進行相應的判斷，如果發現主節點的交易包含不符合相應格式的交易或者惡意交易，即驗證不通過，會發起視圖更換選舉新的主節點。

對於情景 (3)，無須考慮，一個極端的情形是，如果一個拜占庭節點在行為上一直像正常節點那樣工作，那麼可以認為它不是一個拜占庭節點，由整個系統保證結果的正確性。

從節點檢測到主節點有以上異常情況或者接收來自其他f+1 個節點的視圖更換消息之後會向全網廣播視圖更換消息。當新主節點收到N-f個視圖更換消息時，會發送 NewView 消息。從節點接收到 NewView 消息之後進行消息的驗證和對比，驗證視圖的切換信息相同之後正式更換視圖並打印 FinishVC 消息，從而完成整個視圖更換流程，如圖 6.5 所示（其中 ViewChange 代表視圖更換、Primary 代表主節點，Replica 代表從節點）

區塊鏈網絡在運行過程中由於網絡抖動、突然斷電、磁碟故障等原因，可能會導致部分節點的執行速度落後於大多數節點或者直接宕機。在這種場景下，節點需要自動恢復並將賬本同步到當前區塊鏈的最新賬本狀態，才能參與後續的交易執行。為了解決這類數據恢復工作，RBFT 算法提供了一種動態數據自動恢復機制。

RBFT 的自動恢復機制通過主動索取區塊和正在共識的區塊信息，使自身節點的存儲儘快和系統中的最新存儲狀態一致。自動恢復機制大大增強了整個區塊鏈系統的可用性。RBFT 為了恢復的方便，對執行的數據設置檢查點，檢查點是通過全網共識的結果。這樣就保證了每個節點上檢查點之前的數據都是一致的。除了檢查點之外，還有部分數據存儲的是當前還未共識的本地執行進度。這樣在恢復過程中，首先需要本節點的檢查點與區塊鏈其他正常服務節點的檢查點同步。其次需要恢復檢查點之外的部分數據。圖 6.6 為檢查點的示意圖，左邊為檢查點部分，右邊為當前執行檢查點之外的部分。圖 6.7 所示是自動恢復機制的基本處理流程。

在聯盟鏈場景下，由於聯盟的擴展或者某些成員的退出，需要聯盟鏈支持成員的動態進出服務，而傳統的 PBFT 算法不支持節點的動態增刪。RBFT 為了能夠更加方便地控制聯盟成員的準入和準出，為 PBFT 添加了保持集群非停機的情況下動態增刪節點的功能。如圖 6.8 所示，RBFT 為新節點加入了算法處理流程。

新的節點需要得到證書頒發機構頒發的證書，然後向聯盟中的所有節點發送請求。各個節點確認同意後會向聯盟中的其他節點進行全網廣播，當一個節點得到 2f+1 個同意加入的回覆後，會與新的節點建立連接。其次，當新的節點和N-f（N為區塊鏈聯盟節點總數）個節點建立連接後就可以執行主動恢復算法，同步區塊鏈聯盟成員的最新狀態。再次，新節點再向主節點請求加入常規共識流程。最後，主節點確認過新節點的請求後會定義在哪個塊號後需要改變節點總數N來共識（確保新節點的加入不會影響原有的共識，因為新節點的加入會導致全網共識N的改變，意味著f值可能改變）。

RBFT 節點的動態刪除和節點的動態增加流程類似，其主要處理函數如圖 6.9 所示，其主要流程如下。

(1) 退出節點需要通過調用 RPC 請求得到本節點的哈希值，然後向全網所有節點發起退出請求。

(2) 接收到刪除請求的節點的管理員確認同意該節點退出，然後向全網廣播 DelNode 消息，表明自己同意該節點退出整個區塊鏈共識的請求。

(3) 當現有節點收到 2f+1 條 DelNode 消息後，該節點更新連接信息，斷開與請求退出的節點間的連接；並在斷開連接之後向全網廣播 AgreeUpdateN 消息，表明請求整個系統暫停執行交易的處理行為，為更新整個系統參與共識的N，view 做準備。

(4) 當節點收到 2f+1 個 AgreeUpdateN 消息後，更新節點系統狀態。

動態節點退出函數調用

至此，請求退出節點正式退出區塊鏈系統。

以上便是 Hyperchain 改進版的共識算法 RBFT 的主要算法流程。RBFT 通過增加常規共識流程中的驗證步驟，增加節點自動恢復機制，增加動態節點加入以及刪除等功能，比傳統 PBFT 算法更加穩定、靈活、高效，可以更好地滿足企業級聯盟鏈的生產環境需求。動態節點退出函數調用

至此，請求退出節點正式退出區塊鏈系統。

以上便是 Hyperchain 改進版的共識算法 RBFT 的主要算法流程。RBFT 通過增加常規共識流程中的驗證步驟，增加節點自動恢復機制，增加動態節點加入以及刪除等功能，比傳統 PBFT 算法更加穩定、靈活、高效，可以更好地滿足企業級聯盟鏈的生產環境需求。

P2P 網絡是節點之間共識和信息傳遞的通道，是 Hyperchain 的網絡基礎。

網絡通信模塊主要由 Node 、Peer 和加密傳輸 3 個子模塊構成。Node 子模塊主要用於提供本節點的 gRPC 調用服務，作為服務端存在。Peer 子模塊主要作為本節點向其他節點請求時的客戶端。加密模塊採用 ECDH 密鑰協商算法，生成只有兩個節點間認可的密鑰，然後基於增強版的 AES 對稱加密節點間傳輸的數據，保證數據傳輸的安全。

• Hyperchain 的主要架構設計是將 Peer 和 Node 分離開來，Peer 為上層模塊提供消息發送接口。而 Node 主要負責接收消息並將消息拋往上層：接收各節點的信息，然後作為一個消息分發路由，將各類消息 post 到各層。Peer 和 Node 都通過 gRPCManager 進行管理，用於控制各層的通信和分發，實現 Peer 對外暴露接口以及真正控制節點的各個狀態。在 P2P 模塊中也實現了各模塊相互分離，由一個控制層進行控制，子模塊各司其職。

• 節點類型

  Hyperchain 的節點分為驗證節點（VP）和非驗證節點（NVP）兩類：

  • 驗證節點是指區塊鏈網絡中參與共識驗證的節點；

  • 非驗證節點在區塊鏈網絡中不參與共識驗證，僅參與記帳。

  NVP 主要用來做交易轉發和災備，不會自己處理交易，也不參與共識，因而需要依靠相連的 VP 來保證與全網狀態的最終一致性。但 NVP 可以接收交易，並將收到的交易轉發給相連的 VP 進行處理。

  VP 不會主動連接 NVP，所以當 VP 重啟後，與其相連的 NVP 會全部斷開且不會自動重連，需要手動連接。而 NVP 擁有完善的狀態恢復機制，能夠在剛剛啟動或其他原因導致狀態落後之後及時同步。

  VP 之間通過 gRPC 遠程調用服務實現通信構成 P2P 網絡，其中 gRPC 服務採用 protobuf3 進行數據的序列化和反序列化，能夠確保數據的完整和傳輸的高效和安全。

• 流控機制

  底層平台可根據業務需要對允許進入區塊鏈系統的流量進行人為控制，當系統流量超過系統設置的上限時，會對超過部分拒絕接收。這樣可以防止網絡通信過程中因大量無用交易請求佔用了節點處理時間而耽誤其他交易，從而在滿足業務要求的前提下保證系統的安全性。

可通過配置文件對合約交易以及普通交易進行按需流量配置。配置項及配置信息如表

智能合約是部署在區塊鏈上的一段可以自動執行的程序，廣泛意義上的智能合約包含編程語言、編譯器、虛擬機、事件、狀態機、容錯機制等。其中，對應用程序開發影響較大的是編程語言以及智能合約的執行引擎，即虛擬機。虛擬機作為沙盒被封裝起來，整個執行環境被完全隔離。虛擬機內部執行的智能合約不能接觸網絡、文件系統或者系統中的其他線程等系統資源。合約之間只能進行有限調用。

目前智能合約的編寫及其運行環境有 3 種典型的實現範例：

(1) IBM 的 Hyperledger Fabric 項目用 Docker 作為智能合約的執行環境；

(2) R3 Corda 項目中的智能合約使用 JVM 作為合約的底層執行環境；

(3) 以太坊項目中的智能合約採用 Solidity 進行編寫，並使用內嵌型的 Solidity 虛擬機進行執行。

1. 智能合約執行引擎

   因為智能合約本質上是一段可自動執行的腳本程序，存在出錯的可能性，甚至會引發嚴重問題或連鎖反應，因此，智能合約執行引擎的安全性對企業區塊鏈的安全性來說至關重要。

   Solidity 是一種高級編程語言，它專為智能合約的編寫而設計，語法與 JavaScript 相似。其編寫十分簡單，是一門圖靈完備的語言，更重要的是它只能用來實現合約的邏輯功能，不提供任何訪問系統資源的接口（例如打開文件、訪問操作系統底層資源等），這在語言層面上就保證了用 Solidity 編寫的智能合約能且只能運行在一個獨立於操作系統的沙盒中，無法操縱任何系統資源。而 Fabric 基於 Docker 形式的虛擬機，對語言並未進行特殊限制，因此不能完全保證安全性。

   與 Docker 和 JVM 相比，Solidity 語言及其智能合約執行引擎在程序體積上更小，對資源的控制粒度更細，並且採用 Solidity 語言能夠最大程度地利用開源社區在智能合約技術和經驗方面的積累，提高智能合約的可重用性。因此 Hyperchain 平台在智能合約的實現上選擇了 Solidity 語言，並設計研發了支持 Solidity 執行的高效智能合約執行引擎 HyperVM。

   HyperVM 是 Hyperchain 的可插拔智能合約引擎通用框架，允許不同智能合約執行引擎接入，目前實現了兼容 Solidity 語言的 HyperEVM 以及支持 Java 語言的智能合約引擎 HyperJVM 和 HVM，之後將繼續集成其他虛擬機如 WVM、JSVM。

   • HyperEVM

• HyperEVM 是為了最大程度利用開源社區在智能合約技術和經驗方面的積累，提高智能合約的重用性而深度重構 EVM 的虛擬機，完全兼容 EVM 上開發的智能合約。HyperEVM 在保持 Solidity 開發語言的兼容性的基礎上，對智能合約虛擬機進行性能優化，保持了以太坊虛擬機的沙盒安全模型，做了充分的容錯機制，並進行系統級別的優化，結合環境隔離能夠保證合約在有限時間內安全執行，在執行性能方面逼近二進制原生代碼的效率。

• HyperJVM

  HyperJVM 通過微服務的架構設計以及多重安全檢查機制為原生 Java 智能合約執行提供了一個高性能安全的執行沙盒。HyperJVM 具有以下優點：

  • 支持 Java 語言進行智能合約開發，大大降低了開發門檻；

  • 支持完整智能合約生命周期管理，包括合約部署、升級、凍結等；

  • 支持豐富的賬本操作，KV 接口、批量處理、範圍查詢以及列式數據操作；

  • 支持複雜合約邏輯開發和授權跨合約調用；

  • 支持合約自定義事件監聽。

   

• HVMHVM（Hyperchain virtual machine）是集成在 Hyperchain 中的輕量級 Java 智能合約運行時。它提供了一個沙盒環境來執行 Java 語言編寫的智能合約，並能通過多種方式保證其安全性。在 HVM 上，用戶可以高效地寫出簡單強大的智能合約。HVM 具有以下優點：

  • 完善的合約生命周期支持；

  • 更安全的 Java 語言智能合約執行環境；

  • 更高效的狀態空間操作機制；

  • 更友好的編程接口方案。

   

• HyperVM 設計原理

  HyperVM 的設計如圖 6.11 所示，主要組件包括用於合約編譯的編譯器，用於代碼執行優化的優化器，用於合約字節碼執行的解釋器，用於合約執行引擎安全性控制的安全模塊，以及用於虛擬機和賬本交互的狀態管理模塊。

是 HyperVM 執行交易的典型流程圖，HyperVM 執行一次交易之後會返回一個執行結果，系統將其保存在被稱為交易回執的變量中，之後平台客戶端可以根據本次的交易哈希進行交易結果的查詢。

HyperVM 的具體執行流程如下。

(1) HyperVM 接收到上層傳遞的 transaction，並進行初步的驗證。

(2) 判斷 transaction 的類型，如果是部署合約則執行步驟 (3)，否則執行步驟 (4)。

(3) HyperVM 新建一個合約賬戶來存儲合約地址以及合約編譯之後的代碼。

(4) HyperVM 解析 transaction 中的交易參數等信息，並調用其執行引擎執行相應的智能合約字節碼。

(5) 指令執行完成之後，HyperVM 會判斷其是否停機，未停機就跳轉步驟 (2)，否則執行步驟 (6)。

(6) 判斷 HyperVM 的停機狀態是否正常，正常則結束執行，否則執行步驟 (7)。

(7) 進行 Undo 操作，狀態回滾到本次交易執行之前，交易結束。

圖 6.12 中的執行指令集模塊是 HyperVM 執行模塊的核心，指令的執行模塊有兩種實現，分別是基於字節碼的執行以及更加複雜高效的即時編譯（Just-in-time compilation，JIT）。

字節碼執行的方式比較簡單，HyperVM 實現的虛擬機會有指令執行單元。該指令執行單元會一直嘗試執行指令集，當指定時間未執行完成時，虛擬機會中斷計算邏輯，返回超時錯誤信息，以此防止智能合約中的惡意代碼執行。

JIT 方式的執行相對複雜，即時編譯也稱為及時編譯、實時編譯，是動態編譯的一種形式，是一種提高程序運行效率的方法。通常程序有兩種運行方式：靜態編譯與動態直譯。前者是指程序在執行前全部被翻譯為機器碼，而後者則是一邊翻譯一邊執行。即時編譯器混合了靜態編譯和動態直譯，一句一句地編譯源代碼，但同時會將翻譯過的代碼緩存起來，這樣做的好處使可以降低性能損耗。即時編譯的代碼相對於靜態編譯代碼可以處理延遲綁定並增強安全性。JIT 模式執行智能合約主要包含以下步驟。

(1) 將所有同智能合約相關的信息封裝在合約對象中，然後通過該代碼的哈希值去查找該合約對象是否已經存儲編譯。合約對象有 4 種常見狀態，即合約未知、合約已編譯、合約準備好通過 JIT 執行、合約錯誤。

(2) 如果合約狀態是合約準備好通過 JIT 執行，則 HyperVM 會選擇 JIT 執行器來執行該合約。執行過程中虛擬機將會對編譯好的智能合約進一步編譯成機器碼並對push、jump等指令進行深度優化。

(3) 如果合約狀態處於合約未知的情況下，HyperVM 首先需要檢查虛擬機是否強制 JIT 執行，如果是則順序編譯並通過 JIT 的指令進行執行。否則，開啟單獨線程進行編譯，當前程序仍然通過普通的字節碼編譯。當下次虛擬機執行過程中再次遇到相同編碼的合約時，虛擬機會直接選擇經過優化的合約。這樣合約的指令集由於經過了優化，該合約的執行和部署的效率能夠獲得較大的提高。

區塊鏈本質上是一個分佈式賬本系統，因此區塊鏈平台的賬本體系設計至關重要。Hyperchain 的賬本設計主要包含 3 個部分：首先對客戶的交易信息通過區塊鏈這種鏈式結構進行存儲，保證了客戶交易的不易篡改以及可追溯性；其次，採用賬戶體系模型維護區塊鏈系統的狀態，即圖 6.13 中的合約狀態部分；最後，為了快速判斷賬本信息、交易信息等關鍵信息是否存在，賬本採用了改進版的 Merkle 樹進行相關信息存儲。

區塊結構中分為兩部分：區塊頭和交易列表。區塊頭中記錄了一些固定大小的區塊元數據信息，在交易列表中記錄了所有被收錄在該區塊的交易信息。區塊中的相應存儲內容的具體定義如表

區塊頭進行 SHA256 哈希計算，可以生成一個哈希值，該值可以用作在區塊鏈中唯一標識該區塊的數字指紋。同時，在區塊頭信息中引用了上個產生區塊的哈希值，即在每一個區塊中，都包含其父區塊的哈希值。通過這種方式，所有的區塊都被串聯成一個垂直的鏈式結構，通過不斷迭代訪問父區塊，最終可以追溯至區塊鏈的創世區塊（第一個區塊）。

正是由於這種特殊的鏈式結構設計，父區塊有任何改動時，父區塊的哈希值也會發生變化，迫使子區塊中的 “父區塊哈希值” 字段發生變化，導致產生的子區塊哈希值變化。Hyperchain 節點之間每隔一個檢查點會進行一次最新區塊哈希的比較，如果本地維護的最新區塊哈希值與區塊鏈網絡維護的最新區塊哈希值一致，則能確定本地維護的區塊鏈信息是合法的，否則表示本地節點已經成為了一個 “拜占庭節點”。

Hyperchain 區塊頭定義

交易結構定義

Hyperchain 系統除了維護區塊鏈數據以外，還維護了系統當前的狀態信息。與比特幣系統採用 UTXO 模型不同，Hyperchain 採用了一個賬戶模型來表示系統狀態。

當 Hyperchain 節點收到一筆 “待執行” 的交易後，會首先交由執行模塊執行。執行交易結束後，會更改相關合約賬戶的狀態，例如某用戶 A 發起一筆交易調用已部署的合約 B，使得合約 B 中的變量值b由 0 變為 1，並持久化到合約狀態中存儲。

每一筆交易的執行，即意味著合約賬戶狀態的一次轉移，也代表著系統賬本的一次狀態轉移。因此，Hyperchain 也可以被認為是一個狀態轉移系統。

在 Hyperchain 賬本中，會記錄鏈上所有合約的狀態信息。合約狀態元數據共有以下幾個字段，如表

除以上元數據以外，合約賬戶還有兩個數據字段：可執行代碼以及變量存儲空間。可執行代碼就是一段用字節數組編碼的指令集，每一次合約的調用其實就是一次可執行代碼的運行。合約中定義的變量則會被存儲在合約所屬的存儲空間中，合約賬戶存儲空間示意圖如圖

存儲空間與標準的存儲結構類似，在邏輯上是由一片地址連續的存儲單元組成的（為了節省磁碟存儲空間，空的存儲單元不被寫入磁碟）。每一個存儲單元稱為一個槽，大小為 32 字節。合約變量通過在合約編譯階段得到其在存儲空間的索引地址，內容存儲在相應的槽中。

一個簡易的合約狀態數據示意圖如圖

將區塊中收錄的交易依次處理之後，合約賬戶從原先的狀態轉移至一個新的狀態，為了快速生成一個用於標識所有合約賬戶集新狀態的哈希值，Hyperchain 系統中引入了 Merkle 樹進行哈希計算，接下來先簡明扼要地介紹一下 Merkle 樹的結構和作用。

Merkle 樹是一種哈希二叉樹，它是一種用作快速歸納和校驗大規模數據完整性的数据結構。這種二叉樹包含加密哈希值，在比特幣網絡中，Merkle 樹被用來歸納一個區塊中的所有交易，同時生成整個交易集合的數字指紋，且提供了一種校驗區塊是否存在某交易的高效途徑。但是傳統的 Merkle 樹性能較差，在面對高頻海量數據時，計算的表現不能達到聯盟鏈的需求。因此在 Hyperchain 中，設計了一種融合了 Merkle 樹和哈希表兩種數據結構各自優勢的 HyperMerkle 樹，大大提升了賬本哈希計算的速率。

傳統的 Merkle 樹是自底向上構建的，如圖 6.17 所示，從 L1、L2、L3、L4 這 4 個數據塊開始構建 Merkle 樹。首先對這 4 個數據塊的數據哈希化，然後將哈希值存儲至相應的葉子節點。這些葉子節點分別是 Hash0-0、Hash0-1、Hash1-0 和 Hash1-1。

完成最底層葉子節點的賦值之後，開始計算非葉子節點的值，計算方法為串聯相鄰葉子節點的哈希值，並以此為輸入計算哈希，所得結果即為這對葉子節點父節點的哈希值。

繼續類似的操作，直到只剩下頂部的一个節點，即 Merkle 根。根節點的哈希值即代表著這一批數據塊的標識。

這種傳統的 Merkle 樹只適用於像比特幣系統中對批量交易數據進行哈希的場景，而無法滿足聯盟鏈中快速計算賬本哈希的需求。因此在 Hyperchain 中重新設計了結合哈希表特性的 HyperMerkle 樹。

HyperMerkle 樹是一棵構建在哈希表上的多叉樹，哈希表的每個存儲單元均是 HyperMerkle 樹的一個葉子節點，所有的葉子節點稱為n層節點。將相鄰若干個葉子節點歸納為一個父節點，生成的父節點集合稱為n-1 層節點。遞歸上述操作直到只剩下頂部的一个節點即為 HyperMerkle 樹的根節點。每個父節點維護著子節點哈希值列表。HyperMerkle 樹結構如圖

HyperMerkle 樹的一次計算過程如下所示。

(1) 將輸入數據集中的每一個元素按照 key 值哈希到不同的位置，產生哈希衝突時採用拉鏈法進行處理。

(2) 對每一個涉及改動的葉子節點進行哈希重計算，輸入為葉子節點的內容；計算完成後將計算結果寫入相應父節點的孩子節點哈希列表中。

(3) 對每一個涉及改動的n-1 層節點進行哈希重計算，輸入為節點的孩子節點哈希列表（本次計算未涉及的孩子節點的哈希值使用上次計算的值）；計算完成後將計算結果寫入相應父節點的孩子節點哈希列表中。

(4) 重複步驟 (3)，直至計算至 1 層節點。1 層節點也稱為根節點，賬本的當前哈希值用根節點哈希值表示。

(5) 將本次重計算的所有節點的內容持久化。

一棵 HyperMerkle 樹維護一批數據，且每次修改後只針對被修改的部分進行哈希重計算，通過這種機制可以大幅提升計算效率。

HyperMerkle 樹在 Hyperchain 中具體進行兩部分內容的哈希計算：合約賬戶存儲空間的哈希計算；合約賬戶集的哈希計算。

對於每個合約賬戶，存儲空間的內容是 HyperMerkle 樹的輸入，輸出保存在合約賬戶的元數據中；對於合約賬戶集，每個合約的內容是 HyperMerkle 樹的輸入，輸出保存在區塊中，視作當前合約賬戶集狀態的標識。

企業級區塊鏈平台也即聯盟鏈。“聯盟鏈” 這個名詞包含兩層含義：首先它是區塊鏈，其次它是有限成員聯盟性質的。因此，在企業區塊鏈安全性機制的設計上，既需要考慮傳統區塊鏈面對的各成員之間的信任問題，又要考慮聯盟成員的準入準出的安全管理機制。為此，Hyperchain 平台提出了基於密碼學的多級加密機制，在交易網絡、交易雙方以及交易實體等多個層面使用安全加密算法對用戶信息進行了全方位加密，還提出了基於 CA 的權限控制機制；另外，為滿足企業級區塊鏈平台的高擴展性、高可用性等需求，平台推出了數據管理、消息訂閱等功能。

為了提高數據安全隱私保護以及支持靈活獨立的業務場景，Hyperchain 通過設計 Namespace（命名空間）機制實現區塊鏈網絡內部交易的分區共識。使用者可以按照 Namespace 進行業務交易劃分，同一個 Hyperchain 聯盟鏈網絡中的節點按照其所參與的業務組成以 Namespace 為粒度的子網絡，像一個個盒子實現了不同業務之間的物理隔離，使各空間的交易互不干擾。

單個 Hyperchain 節點按照其業務需求可以選擇參與一個或者多個 Namespace。如圖 6.19 所示，Node1、Node2、Node4 和 Node5 組成 namespace1，而 Node2、Node3、Node5 和 Node6 組成 namespace2。其中，Node1 僅參與了 namespace1，而 Node2 則同時參與了兩個 Namespace，Namespace 中通過 CA 認證的方式控制節點的動態加入和退出。

帶特定 Namespace 信息的交易的驗證、共識、存儲以及傳輸僅在參與特定 Namespace 的節點之間進行，不同 Namespace 之間的交易可實現並行執行。例如，圖 6.19 中的 Node1 僅能參與 namespace1 中交易的驗證以及相應賬本的維護，而 Node2 能夠同時參與 namespace1 和 namespace2 的交易執行和賬本維護，但 Node2 中的 namespace1 和 namespace2 的賬本互相隔離，互不可見。
為了提供更細粒度的聯盟鏈隱私保護方案，Hyperchain 主要實現了隱私交易的存證，隱私合約的部署、調用、升級等。

Hyperchain 可支持交易粒度的隱私保護，發送交易時指定該筆交易的相關方，該交易明細只在相關方存儲，隱私交易的哈希在全網共識後存儲在公共賬本，既保證了隱私數據的有效隔離，又可驗證該隱私交易的真實性。

圖展示了隱私交易與普通共識交易各自的流程及差異性。

• 加密上鏈 / 哈希上鏈

  對於某些高敏感信息，若與交易和賬本無強相關性，則可將數據明文在上鏈之前以對稱加密的方式進行加密，將隱私數據保護起來，也可以將原始數據和文件在鏈下保存，通過哈希的方式僅將其數字摘要保存到鏈上，同時解決數據容量和數據敏感的問題。
   

• 合約訪問控制

  合約編碼者可以通過智能合約和訪問控制策略來限制訪問數據的角色和用戶，即在合約中針對節點、角色、用戶定制不同的合約函數訪問權限。合約編碼者可以在合約中為一些高權限的函數設置權限控制，使得該函數只能被固定地址的調用者調用，從而實現訪問權限控制。

Hyperchain 採用了可插拔的多級加密機制，對於業務完整生命周期所涉及的數據、用戶、通信連接等都進行了不同策略的加密，方便企業用戶按照具體業務的場景選擇加密方式，同時保障系統的安全性和高效性。

1. 哈希算法

   通過哈希算法可以把任意長度的輸入變換成固定長度的輸出（哈希值），哈希值的空間通常遠小於輸入的空間，並且哈希函數具有不可逆性，根據哈希值無法反推輸入原文的內容。

• 哈希算法在 Hyperchain 平台中有著廣泛運用，例如交易的摘要、合約的地址、用戶地址等都運用了哈希算法。Hyperchain 提供了可拔插的、不同安全級別的哈希算法選項。安全等級由低到高分別有 SHA2-256、SHA2-256、SHA2-384、SHA2-384 等，這些哈希算法都可以保證為消息生成體積可控、不可逆推的數字指紋，保證平台的數據安全。
   

• 基於 ECDSA 的交易簽名

  為了防止交易被篡改，Hyperchain 採用了成熟的椭圓曲線數字簽名算法（elliptic curve digital signature algorithm，ECDSA）對交易進行簽名，保證平台的身份安全。簽名過程如圖所示。

椭圓曲線密碼體制的安全性是基於椭圓曲線離散對數問題的難解性，由於該問題沒有亞指數時間的解決方法，椭圓曲線密碼系統（elliptic curve cryptography，ECC）的單位比特強度要遠高於傳統的離散對數系統，因此計算參數更小，密鑰更短，運算速度更快，簽名也更加短小。

Hyperchain 使用 secp256k1 曲線和 r1 曲線兩種方式實現了數字簽名算法，用戶可自行選擇，對平台交易進行簽名驗證，保證交易的正確性和完整性。同時平台支持使用該算法對節點間消息進行簽名驗證，保證節點間消息通信的正確性和完整性。考慮到在數字簽名及簽名驗證過程中涉及大量複雜的計算，Hyperchain 採取 C 語言封裝的椭圓曲線加密標準，在簽名和驗證的性能上有更好的表現。

基於 ECDH 的密鑰協商

在網絡通信過程中，使用會話密鑰對傳輸的信息進行加密，可以防止黑客竊聽機密消息進行欺詐等行為。Hyperchain 通過實現椭圓曲線 Diffie-Hellman（ECDH）密鑰協商協議，來完成會話密鑰的建立和網絡中用戶之間的相互認證，保證通信雙方可以在不安全的公共媒介上創建共享的機密協議，而不必事先交換任何私有信息。

在 Hyperchain 中，首先利用 ECDH 實現共享密鑰的交換，交換過程如圖 6.22 所示。ECDH 算法以安全身份認證為前提建立了密鑰協商安全信道，任何截獲交換的組織都能夠複製公共參數和通信雙方公鑰，但是無法從公開共享值生成共享機密協議。協商出共享公鑰後，再通過對稱加密來極大地提高通信效率。

• ECDH 密鑰協商在身份認證和交易安全中都具有重要的作用，通過密鑰協商建立起的安全通信信道能夠實現安全的信息交換，保證平台的通信安全。以安全身份認證為前提建立的密鑰協商安全信道，能夠確認通信雙方的身份合法，再通過對稱加密能夠大大提高通信效率，因為不需要每次通信都去認證身份了。
   

• 基於對稱加密的密文傳輸

  Hyperchain 在通信雙方協商出一個機密共享密鑰後，再基於對稱加密算法保證節點間的密文傳輸，使得計算上破解傳輸內容的難度更高，從而保證平台消息傳輸的高安全性。

  對稱加密也稱常規加密、私鑰加密或者單鑰加密，一個完整的對稱加密方案由 5 個部分組成。

  • 明文（plaintext）：原始的消息或者數據，作為算法輸入。

  • 加密算法（encryption algorithm）：加密算法對明文進行各種替換和轉換。

  • 秘密密鑰（secret key）：算法輸入、算法進行替換和轉換都依賴於秘密密鑰。

  • 密文（ciphertext）：已被打亂的消息，作為加密算法的輸出，取決於明文和秘密密鑰。對於一個給定的消息，兩個不同的秘密密鑰會產成不同的密文。

  • 解密算法（decryption algorithm）：本質上是加密算法的逆運算。使用密文和秘密密鑰產生原始明文。Hyperchain 支持 AES（advanced encryption standard，高級加密標準）算法 —— 是一個基於排列和置換運算的、迭代的、對稱密鑰分組的密碼。它可以使用 128 位、192 位和 256 位密鑰，用 128 位（16 字節）分組加密和解密數據。

   

• 傳輸層安全

  除了上述密鑰協商與密文傳輸以外，Hyperchain 節點間還通過傳輸層安全 TLS（transport layer security）來保證通信安全。TLS 能夠在傳輸層保障信息傳輸的安全性，是目前較為通用的網絡傳輸實施標準，幾乎所有的網絡安全傳輸中都採用了該技術，比如 Google、淘寶、百度、微信等。

  傳輸層安全是 Hyperchain 默認開啟的功能，採用 TLSCA 簽發的證書進行安全通信，即在網絡傳輸過程中需要驗證傳輸層安全協議證書的安全性，驗證通過即可以進行正常網絡通信，否則無法進行網絡通信。該選項是配置可選的。
   

• 國密支持

  相比於其他區塊鏈平台，Hyperchain 在加密算法上有一個很大的優勢：完全支持國密算法的集成。目前 Hyperchain 已集成了國密算法 SM2、SM3 和 SM4，並符合 SSL VPN 技術規範。

  其中，SSL VPN 包括各類網絡通信協議，用於替代 OpennSSL；SM2 是基於椭圓曲線密碼的公鑰密碼算法標準，包含數字簽名、密鑰交換和公鑰加密，用於替換 RSA、DiffieHellman、ECDSA、ECDH 等國際算法；SM3 為密碼雜湊算法，用於替代 MD5、SHA-1、SHA-256 等國際哈希算法；SM4 為分組密碼算法，用於替代 AES、DES、3DES 等國際對稱加密算法。

Hyperchain 主要通過 CA 體系進行身份認證，採用證書頒發精簡體系，如圖

Root.ca（根證書頒發機構）代表 PKI 體系中的信任錨。根 CA 是 PKI 層次結構中最上層的 CA，用於簽發證書認證機構以及角色證書準入認證機構。

ECert（enrollment certificate）為準入證書，ECA（enrollment certificate authority）為準入證書頒發機構，該機構能夠向下頒發節點準入證書。持有 ECert 的節點才能夠同 Hyperchain 鏈上服務交互，否則無法加入相應的 Namespace。

另外，Hyperchain 的 ECert 設計上有兩種實現。持有 ECert1 的機構不僅擁有同 Hyperchain 鏈上服務交互的權限，還能夠向下頒發 TCert（transaction certificate）交易證書。交易證書用於實現偽匿名交易，客戶發起交易的時候需攜帶，客戶端會使用 TCert 相匹配的私鑰對 Transaction 進行加密。TCert 可以實現線上申請，由各個節點簽發，每一條 Transaction 都用一個新的 TCert 進行簽名，從而實現每條交易的相對匿名，但是可以由簽發方審查。

RCA（role certificate authority）為角色證書認證機構，該機構有權限頒發 RCert（role certificate）。RCert 主要是用於區分區塊鏈節點中的驗證節點和非驗證節點，擁有 RCert 才被認為是區塊鏈中的驗證節點，參與區塊鏈節點之間的共識。RCert 和 TCert 一樣，只能作為身份證明的證書存在，不能向下頒發證書。

Hyperchian 的證書均符合 ITU-T X.509 國際標準，它僅包含公鑰信息而沒有私鑰信息，是可以公開發布的。

同時 Hyperchain 平台集成了 CFCA（China financial certification authority）實現數字證書管理功能，可以滿足對於證書系統安全性與權威性要求較高的銀行或金融公司等機構的需求。CFCA 證書體系如圖 6.24 所示，它提供兩種服務模式：CRL 模式和 RA 模式。CRL 是托管 RA 服務，通過 CFCA 托管 RA 服務進行證書的簽發和校驗，RA 模式是本地部署私有化 RA 服務進行證書的簽發和校驗。目前這兩種模式平台都已集成。

• CFCA 證書體系可應用於 Hyperchain 節點驗證 SDK 的證書及有效性，將購買的證書配置於 SDK 中，同時 Hyperchain 節點需要配置好由 CFCA 提供的驗證證書鏈，當 SDK 向節點發送證書時，Hyperchain 會驗證證書及其有效性，同時需要通過網絡請求獲取 CRL，驗證該證書是否被列入黑名單。

  在 JavaSDK 方面，SDK 在發送 SDKCert 時根據 CFCA 特性開關選擇相應的簽名算法對傳輸內容進行簽名。其中 SDK 和 Hyperchain 的 CFCA 特性開關需要保持一致，同時打開或者同時關閉。
   

• 證書管理

  Hyperchain 提供了證書管理的配套工具 certgen，主要用來生成和管理相關的 CA 證書和數字證書，功能包括證書簽發、公私鑰生成、證書檢查等。

  • 證書簽發

    節點啟動前需要生成一對公私鑰，節點啟動時各節點先根據公鑰生成自簽證書，並以此生成根證書。

    簽發子證書時可以由本節點根證書生成指定類型的子證書（ECert、RCert、TCert 和 SDKCert），或者用戶提供公鑰給簽發方，再由簽發方為其簽發子證書。
     

  • 節點準入

    新節點先向各節點發出加入請求，鏈上所有 VP 節點根據申請節點的握手信息查詢其 CA 公鑰證書，並使用公鑰證書進行簽名驗證，然後通過 ACO 表決是否允許持有該 CA 證書的節點加入。如果允許，則向其簽發本節點的 ECert 證書，同時新節點也向被申請節點發放 ECert 證書。
     

  • 證書檢查

    certgen 提供證書檢查服務，檢查內容包括證書是否由 CA 證書簽發、簽名是否合法、是否為能夠簽發子證書的 CA 證書。
     

  • 證書撤銷

    證書撤銷一般發生在當用戶個人身份信息變更、私鑰丟失、泄露或疑似泄露時。一般步驟為：首先證書用戶向 CA 提出證書的撤銷請求，然後 CA 將此證書放入公開發布的證書撤銷列表，該列表中包含所有在有效期內但被撤銷的數字證書。

    此外，數字證書也可能在日期失效之前被撤銷。例如一些特殊情況：證書用戶擅自將證書進行了非正當用途且被 CA 發現，或者政府機關等權力部門因為某種原因要求證書撤銷。
     

• 密鑰管理

  對於用戶公私鑰對，Hyperchain 提供了兩種密鑰管理模式：一是將私鑰交由銀行與第三方機構進行托管，二是由用戶自行保管。兩種管理模式均配備了相應的密鑰找回解決方案。

  (1) 用戶私鑰在頒發時拆為兩部分分別進行加密，其中一部分由銀行進行托管，另一部分交由可信的第三方機構進行托管，從而保證任意一個機構都無法獨立盜取用戶的私鑰進行簽名交易。

  若用戶私鑰丟失，機構會在線下對用戶進行身份鑑定鑑定通過後，發起私鑰找回流程。用戶分別從兩個托管私鑰的機構獲得部分私鑰