【51CTO.com原創(chuàng)稿件】前言

說起當今最具代表性的數(shù)據(jù)通信技術(shù)，區(qū)塊鏈無疑在列。作為當下最受關(guān)注的次世代分布式系統(tǒng)，區(qū)塊鏈可謂眾說紛紜，莫衷一是。有人視之為引爆下一次互聯(lián)網(wǎng)技術(shù)革命的突破口，也有人稱其為投機工具，驚世騙局。本文旨在于盡可能懸置那些游離于技術(shù)層面之外的價值判斷，將視角重新移回到區(qū)塊鏈技術(shù)本身，完整回溯區(qū)塊鏈1.0到3.0的技術(shù)原理和設(shè)計理念之沿革，為讀者揭開籠罩在區(qū)塊鏈之上那層神秘的面紗。

第二章 Hyperledger Fabric與分布式聯(lián)盟數(shù)據(jù)庫

在上篇中已經(jīng)詳細介紹了基于區(qū)塊鏈1.0設(shè)計的比特幣電子記賬系統(tǒng)。不設(shè)準入機制和POW算法使得比特幣兼具了網(wǎng)絡開放性和數(shù)據(jù)安全性。但是POW算法過高的算力開銷也極大限制了區(qū)塊鏈網(wǎng)絡的數(shù)據(jù)處理效率。區(qū)塊鏈技術(shù)不僅能夠應用于電子記賬，還可以廣泛應用于如金融，安保等對數(shù)據(jù)安全性敏感度較高的領(lǐng)域。在強大的技術(shù)需求驅(qū)動下，一項專為企業(yè)機構(gòu)間信息共享而量身定做的區(qū)塊鏈項目應運而生，這就是Linux基金會旗下著名的Hyperledger Fabric項目。

一、Hyperledger Fabric的技術(shù)背景

Hyperledger Fabric是Linux基金會所主導的Hyperledger(超級賬本)項目之一。除Fabric外，Hyperledger生態(tài)下還包含了諸如Burrow，Sawtooth(以太坊拓展項目)，Indy(數(shù)字身份平臺)等專門化項目。不同于比特幣網(wǎng)絡的公鏈設(shè)計，Hyperledger采用了內(nèi)外網(wǎng)隔離和業(yè)務準入的聯(lián)盟鏈架構(gòu)，在區(qū)塊鏈1.0網(wǎng)絡架構(gòu)的基礎(chǔ)上進一步形成了節(jié)點角色的分化。這一設(shè)計規(guī)避了企業(yè)內(nèi)部數(shù)據(jù)外泄的風險，同時也盡可能排除了潛在的安全隱患。

Hyperledger Fabric基于谷歌的gRPC框架開發(fā)，實現(xiàn)了網(wǎng)絡內(nèi)任意節(jié)點的對等通信。同時使用Docker容器技術(shù)來托管構(gòu)成基本交互邏輯的智能合約。簡而言之，Hyperledger Fabric是專門為企業(yè)和機構(gòu)設(shè)計的通用型業(yè)務系統(tǒng)。

二、Hyperledger Fabric的數(shù)據(jù)結(jié)構(gòu)

1. Hyperledger Fabric的區(qū)塊鏈結(jié)構(gòu)

圖十四：Hyperledger Fabric的區(qū)塊鏈結(jié)構(gòu)

Hyperledger Fabric的區(qū)塊鏈結(jié)構(gòu)與比特幣大體相同，每個區(qū)塊都由區(qū)塊頭和區(qū)塊體組成，并通過父區(qū)塊哈希編碼構(gòu)成唯一鏈接。不過Hyperledger Fabric在區(qū)塊鏈1.0的基礎(chǔ)上進一步加入了一層狀態(tài)緩存設(shè)計，用以提高讀寫性能。

Hyperledger Fabric和比特幣網(wǎng)絡一樣，本質(zhì)上是一個分布式賬本(Hyperledger Fabric的賬本交互邏輯可以由使用者根據(jù)自身業(yè)務定制，在數(shù)據(jù)存儲的靈活性上要優(yōu)于區(qū)塊鏈1.0系統(tǒng))。在底層結(jié)構(gòu)中都是通過鍵值對的方式來存儲數(shù)據(jù)。而區(qū)塊鏈為了實現(xiàn)數(shù)據(jù)的時間可回溯性和數(shù)據(jù)防篡改機制，在鏈中并不保存數(shù)據(jù)的狀態(tài)，而只保存對數(shù)據(jù)的變更。這就使得對某條數(shù)據(jù)的狀態(tài)查詢需要進行全鏈遍歷，其查詢性能很難滿足一些企業(yè)級業(yè)務的性能需求，因此Hyperledger Fabric引入了“世界狀態(tài)(World State)”這一概念。當區(qū)塊中保存某一條記錄時，會同步更新對應Key的世界狀態(tài)。當需要查詢某個鍵值時，只需要查詢對應的世界狀態(tài)即可，而無需進行全鏈遍歷。

需要強調(diào)的是，世界狀態(tài)是脫鏈保存在LevelDB/CouchDB結(jié)構(gòu)中的，是一種鏈外附加緩存機制，世界狀態(tài)的丟失并不會對區(qū)塊鏈中的數(shù)據(jù)產(chǎn)生影響。

2. Hyperledger Fabric的賬本結(jié)構(gòu)

當網(wǎng)絡中的排序節(jié)點打包好最新區(qū)塊分發(fā)到每個記賬節(jié)點后，記賬節(jié)點會對本地的區(qū)塊鏈數(shù)據(jù)進行更新，其賬本存儲結(jié)構(gòu)如下圖所示：

圖十五：Hyperledger Fabric的賬本結(jié)構(gòu)

首先每個記賬節(jié)點都保存了所有的歷史區(qū)塊信息，區(qū)塊以文件系統(tǒng)的形式存儲，多個區(qū)塊以集合形式存儲在一個文件塊當中。區(qū)塊鏈通過文件編號，區(qū)塊編號，偏移量來實現(xiàn)對某個歷史區(qū)塊的快速索引。

區(qū)塊鏈數(shù)據(jù)也是記賬節(jié)點中唯一的持久化數(shù)據(jù)，永久保存且不可更改。某個區(qū)塊硬編碼為64M大小，以六位編碼區(qū)分，理論單鏈最多可以容納64*1000000M的數(shù)據(jù)量。當一個新的區(qū)塊請求寫入時，記賬節(jié)點首先會將新的區(qū)塊添加到本地區(qū)塊鏈中，然后將數(shù)據(jù)同步給狀態(tài)數(shù)據(jù)庫(世界狀態(tài)即目前數(shù)據(jù)的終態(tài)，也就是原始狀態(tài)+區(qū)塊鏈中所有交易操作的疊加后的最終狀態(tài))。

當每次節(jié)點啟動時，首先會校驗區(qū)塊鏈，世界狀態(tài)，鍵歷史索引中的數(shù)據(jù)是否一致，若不一致，則可以通過區(qū)塊鏈信息重構(gòu)狀態(tài)數(shù)據(jù)庫。當然如果從創(chuàng)世區(qū)塊開始重構(gòu)世界狀態(tài)性能開銷往往很大，因此Hyperledger Fabric加入了額外的歷史狀態(tài)模塊，這一模塊記錄了對世界狀態(tài)中每一個鍵值對的操作(交易請求)的編碼，當重構(gòu)某一鍵值對時只需要從區(qū)塊鏈中篩選出相應的交易請求執(zhí)行即可，無需遍歷整個區(qū)塊鏈)。

3. Hyperledger Fabric的讀寫集機制

讀寫集是Hyperledger Fabric進行數(shù)據(jù)更新時所依賴的核心技術(shù)，當背書節(jié)點進行交易模擬時會對交易請求進行驗證。讀寫集分為讀集(讀已提交的狀態(tài)值)和寫集(將要更新的狀態(tài)鍵值對，狀態(tài)鍵值對刪除標記，若對同一鍵值對進行多次更新則以最后一次為準)。執(zhí)行交易驗證時，對于某個更新操作，只有當讀集版本號=世界狀態(tài)版本號時，才會執(zhí)行寫集。寫集每更新一個鍵值對，都會同時更新這一鍵值對的版本號。這一設(shè)計的目的在于保障同一區(qū)塊中的多筆交易不會對世界狀態(tài)產(chǎn)生重復操作(類似于Redis的樂觀鎖機制)。

例如世界狀態(tài)中存在某一鍵值對(A,100,V1),此時兩筆時間相近的交易請求被打包進了同一個區(qū)塊中執(zhí)行：

請求一：讀出A值為100后執(zhí)行扣減50操作;

請求二：讀出A值為100后執(zhí)行扣減20操作;

當請求一執(zhí)行后世界狀態(tài)更新為(A,50,V2),此時如果請求二執(zhí)行，則仍然按照之前讀到的(A,100,V1)世界狀態(tài)進行操作，操作后世界狀態(tài)更新為(A,80,V2),繼而抹除了請求一的操作，因此進行版本驗證的目的在于避免在高并發(fā)情況下出現(xiàn)數(shù)據(jù)丟失的情形。

三、實用拜占庭容錯算法(Practical Byzantine Fault Tolerance)

1.PBFT的基礎(chǔ)模型

在前文中我們已經(jīng)介紹了分布式系統(tǒng)必然面臨的數(shù)據(jù)一致性問題——拜占庭將軍問題。區(qū)塊鏈1.0的網(wǎng)絡架構(gòu)主要通過POW算法實現(xiàn)全網(wǎng)共識，以強制記賬節(jié)點用物理開銷來換取記賬權(quán)的方式規(guī)避作弊行為。但是POW算法的解謎設(shè)計也造成了很大的資源浪費，大量的算力被浪費在了沒有實質(zhì)意義的數(shù)字謎題上。而Hyperledger Fabric作為聯(lián)盟鏈，其更偏重于滿足企業(yè)的分布式數(shù)據(jù)存儲和企業(yè)間的數(shù)據(jù)共享需求，因此性能成為了網(wǎng)絡架構(gòu)設(shè)計層面不得不考慮的問題。Hyperledger Fabric在區(qū)塊鏈1.0的基礎(chǔ)上引入了網(wǎng)絡準入機制，只有賦權(quán)節(jié)點才能訪問區(qū)塊鏈中的數(shù)據(jù)，節(jié)點數(shù)目要遠遠小于公鏈系統(tǒng)，POW已經(jīng)不再適合聯(lián)盟鏈系統(tǒng)的設(shè)計開發(fā)。因此，Hyperledger Fabric采用了成本開銷更低，性能更高的一種共識算法——“實用拜占庭容錯算法(PBFT)”。

由萊斯利·蘭伯特所提出的BFT算法僅僅只是在理論上證明了拜占庭容錯的可行性，但是在實際的分布式系統(tǒng)設(shè)計中，由于網(wǎng)絡阻滯等原因，BFT算法幾乎無法被應用。因此在BFT的基礎(chǔ)上，卡斯特羅，米格爾，芭芭拉•利斯科夫等三位計算機科學家進一步提出了能夠?qū)嶋H應用的PBFT算法。

PBFT算法首先區(qū)分了分布式系統(tǒng)的三種基本模型：

強同步性(Synchrony)模型，任意一個節(jié)點發(fā)出的消息都能在確定的時間周期內(nèi)送達目標節(jié)點。

強異步性(Asynchrony)模型，任意一個節(jié)點發(fā)出的消息都未必能到達目標節(jié)點。

弱同步性(Partial Synchrony)模型，任意一個節(jié)點發(fā)出的消息在可能的延遲范圍內(nèi)最終會送達目標節(jié)點。

強同步性與強異步性模型所設(shè)定的情況都過于極端，在實際的分布式系統(tǒng)中情況更加接近弱同步性模型。PBFT算法基于弱同步性模型設(shè)計，即消息可能延遲，但不會無限延遲。

假設(shè)一個分布式網(wǎng)絡中故障/惡意節(jié)點為F個，總節(jié)點數(shù)為N個，在弱同步性模型中，PBFT需要確保兩點：

當某個節(jié)點收到一條消息時，考慮到最多可能有F個節(jié)點保持靜默，因此當收到N-F條消息時就要開始驗證，而且N-F條消息中至少要有多于F條消息一致才能完成容錯判定。因此N和F需要滿足：

N  -  F  >  F

此外N-F條消息中還有可能包含F(xiàn)個來自惡意節(jié)點的假消息，因此真消息的數(shù)目至少要多于F條才可以完成容錯判定，故而N和F需要滿足：

N  -  F  -  F  >  F

綜上有：

故當惡意/故障節(jié)點不超過總結(jié)點數(shù)1/3的情況下，PBFT算法能夠?qū)崿F(xiàn)全局一致性。

2.PBFT的網(wǎng)絡拓撲模型

圖十六：PBFT的網(wǎng)絡拓撲模型

PBFT實現(xiàn)的分布式網(wǎng)絡需要滿足兩個條件：

• 每個節(jié)點具有相同的起始狀態(tài);
• 在相同的狀態(tài)下，同一操作產(chǎn)生的結(jié)果相同。

在一個PBFT算法實現(xiàn)的分布式網(wǎng)絡中，一組節(jié)點中選取一個節(jié)點作為主節(jié)點(Primary)，其它節(jié)點作為備份節(jié)點(Backup)。選取某個節(jié)點擔任主節(jié)點的事態(tài)稱為系統(tǒng)的一個視圖(View)。當主節(jié)點故障時將重新選取主節(jié)點，主節(jié)點發(fā)生變化時視為系統(tǒng)的視圖發(fā)生了一次更新。假設(shè)在View1視圖下網(wǎng)絡對某條消息m的排序n達成一致，為Order⟨view1,m,n⟩，那么當視圖更新后對m的排序仍然為Order⟨view2,m,n⟩，即視圖轉(zhuǎn)換前后消息排序不會發(fā)生改變。

3.PBFT的消息處理流程

圖十七：PBFT的消息處理流程

PBFT的消息處理流程大體上分為請求(Request)，預處理(Pre-prepare)，準備(Prepare)，提交(Commit)，響應(Reply)五個階段。我們通過一個四節(jié)點，一個客戶端的簡單網(wǎng)絡模型來對PBFT的信息傳輸校驗流程加以說明：

在該網(wǎng)絡模型中，Primary節(jié)點和Backup1，Backup2節(jié)點為正常節(jié)點，Backup3節(jié)點發(fā)生故障無法做出響應，符合N>3F要求。

首先在Request階段，Client向Primary發(fā)出一條請求，消息格式為:

其中o 表示操作請求內(nèi)容，t表示當前時間戳，c表示Client節(jié)點。

當Primary收到該消息并驗證后，進入Pre-prepare階段，Primary給予消息m一個序號n，向Backup1，Backup2，Backup3廣播預處理消息，消息格式為： 其中v表示當前的系統(tǒng)視圖，n為消息排序，m為消息內(nèi)容，d為消息m的哈希值。

當Backup1，Backup2節(jié)點接收到Primary節(jié)點的消息后，首先會驗證系統(tǒng)視圖是否發(fā)生了更新，消息簽名是否合法，排序n是否處于當前視圖高低水位之間(為了保證n不出現(xiàn)極大極小值，同一視圖下系統(tǒng)會對n的取值域進行限制，使n∈(h,H))，以及是否收到過其它排序為n的消息(確保不同的消息不會獲得相同的排序)。驗證通過后，進入PREPARE階段，該節(jié)點會向其它節(jié)點(包括Primary節(jié)點)發(fā)送一條準備消息并將該消息存入本地日志中，消息格式為： 其中i表示當前節(jié)點。

當其他節(jié)點收到該消息后，會進行如下校驗并將該消息存入本地日志：

第一步，校驗本地日志中是否存在消息m。

第二步，校驗本地日志中是否存在m的PRE-PREPARE消息。

第三步，校驗本地日志中是否存在至少2F個關(guān)于m的PREPARE消息。

若校驗通過，則稱本節(jié)點對消息m達成了PREPARED狀態(tài)。此時該節(jié)點會向其它節(jié)點廣播，消息格式為：

當其它節(jié)點收到該條COMMIT消息時，會進行如下校驗并將該消息存入本地日志：

第一步，檢驗本節(jié)點是否對消息m達成PREPARED狀態(tài)。

第二步，校驗本地日志中是否至少有2F條來自其它節(jié)點的關(guān)于m的COMMIT消息。

若校驗通過，則說明對m的排序已經(jīng)達成了全局一致，此時稱該節(jié)點對消息m達成了COMMITTED-LOCAL(m,v,n,i)狀態(tài)，可以直接返回給Client，消息格式為： 其中r和t相同，用于時間校驗，當Client收到F+1個一致的REPLY消息時，共識流程結(jié)束。

圖十八：節(jié)點本地日志庫狀態(tài)轉(zhuǎn)移圖

為了更直觀地理解這一流程，我們作出每個節(jié)點本地日志庫的狀態(tài)轉(zhuǎn)移圖。其中藍色標識的消息為節(jié)點自己產(chǎn)生，綠色標識的消息來自其它節(jié)點。

首先Client發(fā)出REQUEST消息，該消息被保存在Primary的日志庫中。然后Primary發(fā)送PRE-PREPARE消息給Backup1，Backup2，Backup3。Backup1，Backup2分別在日志庫中保存該條PRE-PREPARE消息。然后向其它節(jié)點發(fā)送PREPARE消息。

Primary收到來自Backup1，Backup2的兩條PREPARE消息并保存在日志庫中。而Backup1，Backup2除了一條自己產(chǎn)生的PREPARE消息外，還收到一條其它節(jié)點的PREPARE消息。此時三個正常節(jié)點日志庫均滿足：

• 存在消息m的日志;
• 存在消息m的PRE-PREPARE日志;
• 存在消息m的2F個PREPARE日志。

此時三個節(jié)點均達成了關(guān)于m的PREPARED狀態(tài)，繼而向其它節(jié)點發(fā)送COMMIT消息。

由圖可見，三個正常節(jié)點除了自身產(chǎn)生的一條COMMIT消息外，均收到了2條來自其它節(jié)點的COMMIT消息，均達成COMMITTED狀態(tài)，返回REPLY消息給客戶端，完成共識流程。

4.PBFT的垃圾回收機制

PBFT算法對信息的階段性校驗需要用到節(jié)點的日志庫，隨著信息的增加，日志庫中的冗余數(shù)據(jù)也會越來越多，因此PBFT會通過定期的垃圾回收來釋放內(nèi)存空間。PBFT的垃圾回收通過Checkpoint機制來完成。Checkpoint點的設(shè)置為某個常數(shù)K的整數(shù)倍。假設(shè)當前消息排序值n取值的高低水位為h到H之間，當被排序的消息數(shù)超過H時，節(jié)點便會發(fā)送CHECKPOINT消息，消息格式為：

當某個節(jié)點收到2F+1條CHECKPOINT消息后，便會將高低水位重新置為n∈(H,H+K)，并刪除排序值小于H的消息日志，釋放內(nèi)存空間。

5.PBFT的視圖更新機制

因為PBFT通過主節(jié)點完成對消息的排序，因此就存在主節(jié)點故障的風險。對此PBFT設(shè)計了一套對應的視圖更新機制來保證主節(jié)點故障的情況下整個系統(tǒng)的可用性。

當某個節(jié)點i監(jiān)測到主節(jié)點響應超時，便進入視圖更新流程，并發(fā)送一條VIEWCHANGE消息，消息格式為：

其中n為最近一個Checkpoint的序號，C為對應的2F+1個CHECKPOINT消息集合。P為一個達成PREPARED狀態(tài)的消息集合：

Pm表示序號大于n且達成PREPARED狀態(tài)的消息m的至少1個PRE-PREPARE消息和至少2F個PREPARE消息的集合(也就是使消息m達成PREPARED狀態(tài)的所有預處理消息和準備消息的總集)。

當新的主節(jié)點Primaryv+1收到2F個有效的VIEWCHANGE消息后，會廣播一條新視圖消息，消息格式為：

其中V是Primaryv+1收到的所有VIEWCHANGE消息的集合，O為以新視圖構(gòu)造的PRE-PREPARE消息的集合，至此視圖更新流程結(jié)束。這一機制有效確保了系統(tǒng)在視圖更新前后達成PREPARED狀態(tài)的消息排序不變。

四、Hyperledger Fabric的網(wǎng)絡拓撲結(jié)構(gòu)與共識機制

Hyperledger Fabric使用PBFT作為其共識算法的底層實現(xiàn)。對于分布式系統(tǒng)而言，數(shù)據(jù)一致性策略可分為強一致性策略和最終一致性策略。所謂強一致性策略是指系統(tǒng)能夠?qū)崿F(xiàn)在極端條件下的數(shù)據(jù)一致性，其涉及到復雜的數(shù)據(jù)交互，且對系統(tǒng)壓力較大，并不適合商業(yè)級數(shù)據(jù)存儲。因此Hyperledger Fabric采用了最終一致性策略，所謂最終一致性是指系統(tǒng)可以容忍在短時間內(nèi)不同節(jié)點數(shù)據(jù)不一致的情形，整個區(qū)塊鏈網(wǎng)絡只需要保證在一定時間周期內(nèi)達成一致即可。

圖十九：Hyperledger Fabric的網(wǎng)絡拓撲結(jié)構(gòu)

如圖所示，Hyperledger Fabric采用多中心的網(wǎng)絡架構(gòu)模式，由獨立的排序節(jié)點對來自不同終端的交易請求進行規(guī)整處理，封裝成區(qū)塊后再下發(fā)到整個區(qū)塊鏈網(wǎng)絡。

Hyperledger Fabric網(wǎng)絡下主要有四種類型的節(jié)點：

• Client節(jié)點(客戶端節(jié)點)，這一節(jié)點主要用于提供應用訪問區(qū)塊鏈網(wǎng)絡的入口，負責系統(tǒng)與區(qū)塊鏈之間的數(shù)據(jù)交互。
• Peer節(jié)點，包含了Anchor節(jié)點(錨節(jié)點)，Endorser節(jié)點(背書節(jié)點)和Committer節(jié)點(記賬節(jié)點)。其中錨節(jié)點每個組織中至多只有一個，負責和其他組織以及order節(jié)點交互，組織網(wǎng)絡中的非錨節(jié)點不直接參與和外部網(wǎng)絡的信息交換。背書節(jié)點負責模擬執(zhí)行來自用戶的交易請求，并對請求進行驗證和簽名。記賬節(jié)點負責保存區(qū)塊鏈信息，更新世界狀態(tài)等。需要強調(diào)的是這三種角色之間并非互斥關(guān)系，一個Peer節(jié)點可能同時兼有背書節(jié)點，記賬節(jié)點等多種角色，而且所有的Peer節(jié)點都是記賬節(jié)點。
• Order節(jié)點，共識機制的核心節(jié)點，負責對來自用戶的交易請求進行排序，打包成區(qū)塊后分發(fā)給其它組織的錨節(jié)點。
• CA節(jié)點(鑒權(quán)節(jié)點)，非必要節(jié)點，主要負責證書的頒發(fā)，身份驗證及用戶鑒權(quán)等。也可通過第三方證書鑒權(quán)機構(gòu)實現(xiàn)。

就Hyperledger Fabric的網(wǎng)絡拓撲結(jié)構(gòu)而言，其并不同于如比特幣，以太坊等常見公鏈的網(wǎng)狀拓撲結(jié)構(gòu)，而是更接近于具備一定層級關(guān)系的樹狀拓撲結(jié)構(gòu)(就此而言，Hyperledger Fabric并非是一個去中心網(wǎng)絡，而是一個多中心網(wǎng)絡)。

不同的組織分屬于不同的網(wǎng)域，每個組織結(jié)構(gòu)下只暴露一個錨節(jié)點作為與其它組織交互的接口。這一設(shè)計主要是出于部分企業(yè)的數(shù)據(jù)安全性考慮。很多企業(yè)核心數(shù)據(jù)往往不便于直接暴露在公網(wǎng)中，內(nèi)外網(wǎng)隔離的設(shè)計可以充分確保敏感數(shù)據(jù)的安全性。

除了不同的組織外，區(qū)塊鏈網(wǎng)絡中還存在由Order節(jié)點組成的排序網(wǎng)絡，Order節(jié)點有Solo和Kafka兩種運行模式。Solo模式由單個Order節(jié)點提供排序服務，往往只是用于網(wǎng)絡測試和節(jié)點數(shù)較少的場景。商業(yè)應用中一般采用Kafka模式，Order節(jié)點將接收到的交易請求發(fā)送給Kafka集群，由Kafka集群排序后再返回給Order節(jié)點，這一設(shè)計大大提升了Order集群的排序分發(fā)效率。

圖二十：Hyperledger Fabric的多通道排序機制

在企業(yè)應用場景中可能存在一個區(qū)塊鏈網(wǎng)絡需要承接多種業(yè)務的情形，因此Hyperledger Fabric采用了多通道設(shè)計。所謂通道指的是一個封閉的業(yè)務群，一個Hyperledger Fabric網(wǎng)絡中可能存在多個業(yè)務群處理不同的業(yè)務，彼此之間在邏輯和物理上均相互隔離。有幾個業(yè)務群就會存在幾條不同的區(qū)塊鏈，每個節(jié)點都只會保存自己加入的通道的區(qū)塊鏈數(shù)據(jù)，進而杜絕了多業(yè)務交叉場景下數(shù)據(jù)外泄的風險。而排序節(jié)點也會根據(jù)通道的不同將交易請求分發(fā)給不同的Kafka隊列，實現(xiàn)業(yè)務間的鏈級隔離。

Hyperledger Fabric網(wǎng)絡中一個完整的交易流程為：

客戶端首先提交交易提案發(fā)送給背書節(jié)點(至少兩個，具體可在背書策略中設(shè)置，用戶可指定要使用的背書節(jié)點)，背書節(jié)點收到交易提案后啟動鏈碼(運行在一個隔離的安全容器中，無法被人為干預)模擬交易(僅僅是模擬，并不會更新到區(qū)塊鏈網(wǎng)絡中)。鑒權(quán)驗證通過后背書節(jié)點會添加數(shù)字簽名并返回給客戶端(理論上多個背書節(jié)點返回的執(zhí)行結(jié)果應當一致)?？蛻舳藢⒑灻蟮慕灰渍埱蟀l(fā)送給Order節(jié)點，Order節(jié)點進行排序后打包成區(qū)塊分發(fā)給各組織錨節(jié)點。錨節(jié)點分發(fā)給組織內(nèi)記賬節(jié)點，記賬節(jié)點驗證完成后將最新的區(qū)塊添加到本地區(qū)塊鏈中，并更新世界狀態(tài)。

五、智能合約

圖二十一：發(fā)起交易和智能合約調(diào)用流程

智能合約(鏈碼)是Hyperledger Fabric用于應用和區(qū)塊鏈網(wǎng)絡之間交互的媒介。鏈碼部署在獨立且隔離的Docker容器中，無法被外界干預和篡改，通過gRPC與背書節(jié)點通信。背書節(jié)點將交易請求發(fā)送給鏈碼容器后，鏈碼容器返回給背書節(jié)點該筆交易的執(zhí)行結(jié)果。

智能合約類似于應用系統(tǒng)中的對外接口，而交易就是對接口的一次調(diào)用。鏈碼中對外接口只提供兩個方法，Init方法和Invoke方法。Init方法只會在區(qū)塊鏈網(wǎng)絡啟動時在任意一個節(jié)點執(zhí)行一次，Invoke方法則用于應用和區(qū)塊鏈網(wǎng)絡之間具體的交互。

鏈碼存在五個生命周期，打包(鏈碼的編譯)，安裝(上傳到背書節(jié)點)，實例化(執(zhí)行Init方法)，升級(鏈碼中的功能拓展和Bug修復)，交互(應用調(diào)用)。

企業(yè)用戶可以根據(jù)自身業(yè)務場景編寫不同功能的智能合約來實現(xiàn)應用和區(qū)塊鏈網(wǎng)絡之間的數(shù)據(jù)交互。

六、Hyperledger Fabric的業(yè)務應用

Hyperledger Fabric是一套專門為機構(gòu)和企業(yè)設(shè)計的通用型業(yè)務方案。其相比于區(qū)塊鏈1.0和2.0，可以靈活的根據(jù)用戶業(yè)務進行定制。而模塊化和插件式的服務模式也大大降低了用戶的組網(wǎng)成本。非常適用于金融，支付等高敏感性業(yè)務場景。而Hyperledger Fabric底層的鍵值對存儲結(jié)構(gòu)也具有很強的擴展性。傳統(tǒng)數(shù)據(jù)庫能夠存儲的數(shù)據(jù)，理論上Hyperledger Fabric都可以存儲。其多通道設(shè)計可以實現(xiàn)物理級別的業(yè)務解耦，多種業(yè)務都可以無干擾地掛載在同一區(qū)塊鏈網(wǎng)絡下。實現(xiàn)資源復用的同時又避免了機構(gòu)之間業(yè)務交叉產(chǎn)生的數(shù)據(jù)外泄風險。

Hyperledger Fabric的另一大優(yōu)勢在于用戶可以根據(jù)自身業(yè)務編寫智能合約，定制應用系統(tǒng)和區(qū)塊鏈網(wǎng)絡的數(shù)據(jù)交互模式。這就為復雜業(yè)務場景和區(qū)塊鏈技術(shù)的縫合提供了便利，使得“區(qū)塊鏈+”得以真正進入企業(yè)級應用之中。

結(jié)語

區(qū)塊鏈技術(shù)問世以來，十數(shù)年間歷經(jīng)三次迭代，其間或譽或諑，不絕于耳。唯有撥開籠罩在區(qū)塊鏈上的那層神秘面紗，深究其技術(shù)原理，方能得見其真容。單純作為一種技術(shù)而言，區(qū)塊鏈本身是價值無涉的。工具能釋放出怎樣的社會價值，終究取決于其使用者。我們也許驚嘆于設(shè)計者的曠世奇思，但絕無必要為其賦予太多超脫于技術(shù)之外的神秘色彩。區(qū)塊鏈也許是通往未來的一個入口，但任何技術(shù)奇點的引爆都并非來自于某個單點技術(shù)突破，而是醞釀于厚積薄發(fā)的逐步嬗變。勤懇與踏實才是推動社會進步的最終驅(qū)力，在技術(shù)瞬息萬變，發(fā)展一日千里的當下，我們更當持守此心。

參考文獻

[1] Satoshi Nakamoto: Bitcoin:A Peer-to-Peer Electronic Cash System[EB/OL]

[2] Castro,Miguel,Barbara Liskov: Practical Byzantine fault tolerance.OSDI.Vol.99.1999

[3] Kwon,Jae: Tendermint:Consensus without mining.Draft v.0.6,fall(2014)

作者簡介：

王翔，畢業(yè)于安徽大學2018屆電子信息工程專業(yè)，現(xiàn)就職于某知名世界五百強互聯(lián)網(wǎng)企業(yè)。致力于服務端系統(tǒng)的架構(gòu)設(shè)計，多活部署，性能優(yōu)化，業(yè)務開發(fā)等工作。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】