會當凌絕頂，一覽眾山小。進入區塊鏈底層開發前，我們需要了解區塊鏈底層的通用架構是如何設計的，從上而下地審視區塊鏈底層的結構，做到了然於胸，才能胸有成竹。
他山之石，可以攻玉。在介紹區塊鏈底層通用架構之前，我們不妨先從比特幣、以太坊、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，可以實現自動化配置，提高開發效率。
閱讀更多 幣圈狼桀 的文章
