來源 | 《區塊鏈底層設計·Java 實戰》
責編 | 喬治
出品 | CSDN、區塊鏈大本營
會當凌絕頂，一覽眾山小。進入區塊鏈底層開發前，我們需要了解區塊鏈底層的通用架構是如何設計的，從上而下地審視區塊鏈底層的結構，做到了然於胸，才能胸有成竹。
他山之石，可以攻玉。在介紹區塊鏈底層通用架構之前，我們不妨先從比特幣、以太坊、Hyperledger 的架構解讀開始。（一定要讀完喲，因為有書拿！！！）
比特幣架構
根據中本聰的論文《Bitcoin: A Peer-to-Peer Electronic Cash System》中對比特幣系統的描述，我們可以整理出如下圖所示的比特幣系統架構。
比特幣系統架構
如圖所示，比特幣系統分為 6 層，由下至上依次是儲存層、資料層、網路層、共識層、RPC 層、應用層。
其中，儲存層主要用於儲存比特幣系統執行中的日誌資料及區塊鏈後設資料，儲存技術主要使用檔案系統和 LevelDB。
資料層主要用於處理比特幣交易中的各類資料，如將資料打包成區塊，將區塊維護成鏈式結構，區塊中內容的加密與雜湊計算，區塊內容的數字簽名及增加時間戳印記，將交易資料構建成 Merkle 樹，並計算 Merkle 樹根節點的雜湊值等。
區塊構成的鏈有可能分叉，在比特幣系統中，節點始終都將最長的鏈條視為正確的鏈條，並持續在其後增加新的區塊。
網路層用於構建比特幣底層的 P2P 網路，支援多節點動態加入和離開，對網路連線進行有效管理，為比特幣資料傳輸和共識達成提供基礎網路支援服務。
共識層主要採用了 PoW(Proof Of Work)共識演算法。在比特幣系統中，每個節點都不斷地計算一個隨機數(Nonce)，直到找到符合要求的隨機數為止。在一定的時間段內，第一個找到符合條件的隨機數將得到打包區塊的權利，這構建了一個工作量證明機制。從 PoW 的角度，是不是發現 PoW 和分散式鎖有異曲同工之妙呢?
RPC 層實現了 RPC 服務，並提供 JSON API 供客戶端訪問區塊鏈底層服務。
應用層主要承載各種比特幣的應用，如比特幣開原始碼中提供了 bitcoin client。該層主要是作為 RPC 客戶端，透過 JSON API 與 bitcoin 底層互動。除此之外，比特幣錢包及衍生應用都架設在應用層上。
以太坊架構
根據以太坊白皮書《A Next-Generation Smart Contract and Decentralized Application Platform》的描述，以太坊架構如下圖所示。
如圖所示，以太坊架構分為 7 層，由下至上依次是儲存層、資料層、網路層、協議層、共識層、合約層、應用層。
其中儲存層主要用於儲存以太坊系統執行中的日誌資料及區塊鏈後設資料，儲存技術主要使用檔案系統和 LevelDB。
資料層主要用於處理以太坊交易中的各類資料，如將資料打包成區塊，將區塊維護成鏈式結構，區塊中內容的加密與雜湊計算，區塊內容的數字簽名及增加時間戳印記，將交易資料構建成 Merkle 樹，並計算 Merkle 樹根節點的 hash 值等。
與比特幣的不同之處在於以太坊引入了交易和交易池的概念。交易指的是一個賬戶向另一個賬戶傳送被簽名的資料包的過程。而交易池則存放透過節點驗證的交易，這些交易會放在礦工挖出的新區塊裡。
以太坊的 Event(事件)指的是和以太坊虛擬機器提供的日誌介面，當事件被呼叫時，對應的日誌資訊被儲存在日誌檔案中。
與比特幣一樣，以太坊的系統也是基於 P2P 網路的，在網路中每個節點既有客戶端角色，又有服務端角色。
協議層是以太坊提供的供系統各模組相互呼叫的協議支援，主要有 HTTP、RPC協議、LES、ETH 協議、Whipser 協議等。
以太坊基於 HTTP Client 實現了對 HTTP 的支援，實現了 GET、POST 等 HTTP方法。外部程式透過 JSON RPC 呼叫以太坊的 API 時需透過 RPC (遠端過程呼叫) 協議。
Whisper 協議用於 DApp 間通訊。
LES 的全稱是輕量級以太坊子協議(Light Ethereum Sub-protocol)，允許以太坊節點同步獲取區塊時僅下載區塊的頭部，在需要時再獲取區塊的其他部分。
共識層在以太坊系統中有 PoW(Proof of Work)和 PoS(Proof of Stake)兩種共識演算法。
合約層分為兩層，底層是 EVM(Ethereum Virtual Machine，即以太坊虛擬機器)，上層的智慧合約執行在 EVM 中。智慧合約是執行在以太坊上的程式碼的統稱，一個智慧合約往往包含資料和程式碼兩部分。智慧合約系統將約定或合同程式碼化，由特定事件驅動觸發執行。因此，在原理上適用於對安全性、信任性、長期性的約定或合同場景。在以太坊系統中，智慧合約的預設程式語言是 Solidity，一般學過 JavaScript 語言的讀者很容易上手 Solidity。
應用層有 DApp(Decentralized Application，分散式應用)、以太坊錢包等多種衍生應用，是目前開發者最活躍的一層。
Hyperledger 架構
超級賬本(Hyperledger)是 Linux 基金會於 2015 年發起的推進區塊鏈數字技術和交易驗證的開源專案，該專案的目標是推進區塊鏈及分散式記賬系統的跨行業發展與協作。
目前該專案最著名的子專案是 Fabric，由 IBM 主導開發。按官方網站描述，Hyperledger Fabric 是分散式記賬解決方案的平臺，以模組化體系結構為基礎，提供高度的彈性、靈活性和可擴充套件性。它旨在支援不同元件的可插拔實現，並適應整個經濟生態系統中存在的複雜性。
Hyperledger Fabric 提供了一種獨特的彈性和可擴充套件的體系結構，使其不同於其他區塊鏈解決方案。我們必須在經過充分審查的開源架構之上對區塊鏈企業的未來進行規劃。超級賬本是企業級應用快速構建的起點。
目前，Hyperledger Fabric 經歷了兩大版本架構的迭代，分別是 0.6 版和 1.0 版。其中，0.6 版的架構相對簡單，Peer 節點集眾多功能於一身，模組化和可拓展性較差。1.0 版對 0.6 版的 Peer 節點功能進行了模組化分解。目前最新的 1.1 版本處於 Alpha 階段。
在 1.0 版中，Peer 節點可分為 peers 節點和 orderers 節點。peers 節點用於維護狀態(State)和賬本(Ledger)，orderers 節點負責對賬本中的各條交易達成共識。
系統中還引入了認證節點(Endorsing Peers)，認證節點是一類特殊的 peers 節點， 負責同時執行鏈碼(Chaincode)和交易的認證(Endorsing Transactions)。
Hyperledger Fabric 的分層架構設計如圖下所示。
Hyperledger Fabric 的分層架構設計
Hyperledger Fabric 可以分為7層，分別是儲存層、資料層、通道層、網路層、共識層、合約層、應用層。
其中儲存層主要對賬本和交易狀態進行儲存。賬本狀態儲存在資料庫中，儲存的內容是所有交易過程中出現的鍵值對資訊。比如，在交易處理過程中，呼叫鏈碼執行交易可以改變狀態資料。狀態儲存的資料庫可以使用 LevelDB 或者 CouchDB。LevelDB 是系統預設的內建的資料庫，CouchDB 是可選的第三方資料庫。區塊鏈的賬本則在檔案系統中儲存。
資料層主要由交易(Transaction)、狀態(State)和賬本(Ledger)三部分組成。
其中，交易有兩種型別：
部署交易：以程式作為引數來建立新的交易。部署交易成功執行後, 鏈碼就被安裝到區塊鏈上。
呼叫交易：在上一步部署好的鏈碼上執行操作。鏈碼執行特定的函式，這個函式可能會修改狀態資料，並返回結果。
狀態對應了交易資料的變化。在 Hyperledger Fabric 中，區塊鏈的狀態是版本化的，用 key/value store(KVS) 表示。其中 key 是名字，value 是任意的文字內容，版本號標識這條記錄的版本。這些資料內容由鏈碼透過 PUT 和 GET 操作來管理。如儲存層的描述，狀態是持久化儲存到資料庫的，對狀態的更新是被檔案系統記錄的。
賬本提供了所有成功狀態資料的改變及不成功的嘗試改變的歷史。
賬本是由 Ordering Service 構建的一個完全有序的交易塊組成的區塊雜湊鏈 (Hash Chain)。
賬本既可以儲存在所有的 peers 節點上，又可以選擇儲存在幾個 orderers 節點上。 此外，賬本允許重做所有交易的歷史記錄，並且重建狀態資料。
通道層指的是通道 (Channel)，通道是一種 Hyperledger Fabric 資料隔離機制，用於保證交易資訊只有交易參與方可見。每個通道都是一個獨立的區塊鏈，因此多個使用者可以共用同一個區塊鏈系統，而不用擔心資訊洩漏問題。
網路層用於給區塊鏈網路中各個通訊節點提供 P2P 網路支援，是保障區塊鏈賬本一致性的基礎服務之一。
在 Hyperledger Fabric 中，Node 是區塊鏈的通訊實體。Node 僅僅是一個邏輯上的功能，多個不同型別的 Node 可以執行在同一個物理伺服器中。Node 有三種型別，分別是客戶端、peers 節點和 Ordering Service。
其中，客戶端用於把使用者的交易請求傳送到區塊鏈網路中。
peers 節點負責維護區塊鏈賬本，peers 節點可以分為 endoring peers 和 committing peers 兩種。endoring peers 為交易作認證，認證的邏輯包含驗證交易的有效性，並對交易進行簽名；committing peers 接收打包好的區塊，並寫入區塊鏈中。與 Node 類似，peers節點也是邏輯概念，endoring peers 和 committing peers 可以同時部署在一臺物理機上。
Ordering Service 會接收交易資訊，並將其排序後打包成區塊，然後，寫入區塊鏈中，最後將結果返回給 committing peers。
共識層基於 Kafka、SBTF 等共識演算法實現。Hyperledger Fabric 利用 Kafka 對交易資訊進行排序處理，提供高吞吐、低延時的處理能力，並且在叢集內部支援節點故障容錯。相比於 Kafka，SBFT(簡單拜占庭演算法)能提供更加可靠的排序演算法，包括容忍節點故障以及一定數量的惡意節點。
合約層是 Hyperledger Fabric 的智慧合約層 Blockchain，Blockchain 預設由 Go 語言實現。Blockchain 執行的程式叫作鏈碼，持有狀態和賬本資料，並負責執行交易。在Hyperledger Fabric 中，只有被認可的交易才能被提交。而交易是對鏈碼上的操作的呼叫，因此鏈碼是核心內容。同時還有一類稱之為系統鏈碼的特殊鏈碼，用於管理函式和引數。
應用層是 Hyperledger Fabric 的各個應用程式。
此外，既然是聯盟鏈，在 Hyperledger Fabric中 還有一個模組專門用於對聯盟內的成員進行管理，即 Membership Service Provider(MSP)，MSP 用於管理成員認證資訊，為客戶端和 peers 節點提供成員授權服務。
區塊鏈通用架構
至此，我們已經瞭解了比特幣、以太坊和 Hyperledger 的架構設計，三者根據使用場景的不同而有不同的設計，但還是能抽象出一些共同點，我們可以基於這些共同點設計企業級聯盟鏈的底層架構。
本文提供的聯盟鏈底層架構如下圖所示。
聯盟鏈底層架構
我們將區塊鏈底層分為 6 層，從下至上分別是儲存層、資料層、網路層、共識層、激勵層和應用層。
儲存層主要儲存交易日誌和交易相關的內容。其中，交易日誌基於 LogBack 實現。交易的內容由內建的 SQLite 資料庫儲存，讀寫 SQLite 資料庫可以基於 JPA 實現；交易的上鍊後設資料資訊由 RocksDB 或 LevelDB 儲存。
資料層由區塊和區塊“鏈”(區塊的鏈式結構)組成。其中，區塊中還會涉及交易列表在 Merkle 樹中的儲存及根節點雜湊值的計算。交易的內容也需要加密處理。由於在聯盟鏈中有多個節點，為有效管理節點資料及保障資料安全，建議為不同節點分配不同的公、私鑰，以便加密使用。
網路層主要提供共識達成及資料通訊的底層支援。在區塊鏈中，每個節點既是資料的傳送方，又是資料的接收方。可以說每個節點既是客戶端，又是服務端，因此需要基於長連線來實現。我們可以基於 WebSocket 用原生方式建立長連線，也可以基於長連線第三方工具包實現。
共識層採用 PBFT(Practical Byzantine Fault Tolerance)共識演算法。不同於公鏈的挖礦機制，聯盟鏈中更注重各節點資訊的統一，因此可以省去挖礦，直奔共識達成的目標。
激勵層主要是幣(Coin)和 Token 的頒發和流通。在公鏈中，激勵是公鏈的靈魂；但在聯盟鏈中不是必需的。
應用層主要是聯盟鏈中各個產品的落地。一般聯盟鏈的應用層都是面向行業的，解決行業內的問題。
Java 版聯盟鏈的部署架構如下圖所示。
Java 版聯盟鏈的部署架構
聯盟鏈由 1 個超級節點和若干個普通節點組成，超級節點除具備普通節點的功能外，還具備在聯盟中實施成員管理、許可權管理、資料監控等工作。因此相較於完全去中心化的公鏈，聯盟鏈是部分去中心化的，或者說聯盟的“鏈”是去中心化的，但是聯盟鏈的管理是中心化的。
整個開發環境建議基於 Spring Boot 2.0 實現。基於 Spring Boot 開發，可以省去大量的 xml 配置檔案的編寫，能極大簡化工程中在 POM 檔案配置的複雜依賴。Spring Boot 還提供了各種 starter，可以實現自動化配置，提高開發效率。
