區(qū)塊鏈通用設計及案例分析

崔順艷 陳寧 葉勁宏 楊晨光 孫宗錦

（廣東省網絡與信息安全漏洞研究重點實驗室 廣東省廣州市 510000）

1 背景概述

區(qū)塊鏈的興起，源于其創(chuàng)造性的算法、設計架構，以及由其帶來的新的市場價值。在區(qū)塊鏈技術出現(xiàn)之前，互聯(lián)網是基于數(shù)據(jù)流的基礎建立的，而互聯(lián)網的價值、信用交換基礎設施并不完善。區(qū)塊鏈技術的出現(xiàn)，給信用、價值網絡的建立，提供了新的解決方案。

區(qū)塊鏈概念的提出，源于比特幣。2009年，中本聰提出了一種不依賴第三方機構的，由純算法構成的，可以點對點交易的數(shù)字貨幣架構[1]。中本聰在他的文章中，創(chuàng)造性的提出了區(qū)塊鏈，工作量證明共識機制。中本聰?shù)乃惴ǎ瑥膶嵺`上，解決了在沒有中心化機構的情況下，無限多節(jié)點之間的互信問題。很快，開源社區(qū)將中本聰?shù)乃惴ㄟM行了實現(xiàn)，形成了比特幣。在比特幣之后，人們開始嘗試將區(qū)塊鏈和共識機制等應用于數(shù)字貨幣之外的其他領域。這其中典型的探索實踐是Ripple[2]和以太坊[3]。前者設計了一種基于區(qū)塊鏈技術的跨境銀行解決方案，把區(qū)塊鏈技術向商業(yè)場景的應用，推進了一步。而后者，建立了開源區(qū)塊鏈平臺，并首次將智能合約引入?yún)^(qū)塊鏈平臺，并在以后的平臺中成為標準配置。隨著比特幣，Ripple，以太坊一系列項目的市場認可度越來越高，IT、金融領域的巨頭們，開始進入了額區(qū)塊鏈領域的研發(fā)。一些公司或機構，嘗試以服務企業(yè)、政府部門的需求為出發(fā)點，開發(fā)區(qū)塊鏈系統(tǒng)，例如：IBM的Hyperledger[4][5]項目和R3的Corda項目[6][7]。由此可見，區(qū)塊鏈的發(fā)展，經歷了一個脫實向虛的過程，由算法，發(fā)展為虛擬貨幣的實現(xiàn)，進而發(fā)展為企業(yè)級解決方案。如果說，比特幣是區(qū)塊鏈的1.0形態(tài)，以太坊是2.0形態(tài)，那么，之后出現(xiàn)的面向企業(yè)的平臺就是區(qū)塊鏈的3.0形態(tài)。

隨著區(qū)塊鏈技術的發(fā)展，區(qū)塊鏈在我國的應用也逐漸多了起來。區(qū)塊鏈的多中心化治理結構，可以在保有層級的情況下，發(fā)揮平級之間的能動性，進而提高政府多部門協(xié)作工作的運行效率。共識機制可以解決政府多行政區(qū)之間的可信數(shù)據(jù)交換問題，進一步打破信息孤島。區(qū)塊鏈的可信存證與溯源特性，可以幫助建立更好的市場監(jiān)管體系；另外，對于證據(jù)的可信保存，信息溯源等場景，區(qū)塊鏈技術提供了新型高效IT解決方案。

在以下章節(jié)中，我們對區(qū)塊鏈應用設計進行詳細剖析討論。在章節(jié)2中，我們對區(qū)塊鏈技術的通用設計進行討論。在章節(jié)3中，我們探討一些IT行業(yè)中的區(qū)塊鏈經典設計案例，這些經典設計，對于如何應用好區(qū)塊鏈技術為我國發(fā)展服務具有參考價值。最后我們在章節(jié)4中，進行總結。

2 區(qū)塊鏈通用設計

區(qū)塊鏈的應用方案中，基礎區(qū)塊鏈平臺的設計是一個核心問題。下面進行討論。早期的區(qū)塊鏈平臺公鏈，定義的場景是，在無限多網絡節(jié)點，互無信任的前提下，利用共識機制，建立基于算法的互信體系。其代表為，比特幣和以太坊。

表 1：主流區(qū)塊鏈平臺

比特幣的共識算法，第一次證明了在無限多節(jié)點情況下，且節(jié)點間互無信任的前提下，可以通過一種實用算法，對交易數(shù)據(jù)在全網達成共識。比特幣的共識機制，是通過工作量證明算法實現(xiàn)的。然而，僅能共識交易，從機能上很難滿足政府和企業(yè)的需求。以太坊開創(chuàng)性的加入了智能合約，使得區(qū)塊鏈可以共識的內容從交易，拓展到了可編程的合約，其平臺適用范圍也更為廣泛。之后的區(qū)塊鏈平臺，也將智能合約作為了標準配置功能。智能合約是一種無需中介、自我驗證、自動執(zhí)行合約條款的計算機交易協(xié)議。智能合約的概念早在1990年代就被提出[8]。但是，區(qū)塊鏈技術出現(xiàn)之前，智能合約的實現(xiàn)缺少一種可信執(zhí)行環(huán)境。比特幣的工作量證明機制，賦予了智能合約真正的可信執(zhí)行環(huán)境。以太坊是基于工作量證明機制建立的智能合約。然而，以太坊定義的共識范圍仍然是無限多節(jié)點的全互聯(lián)網，這種定義使得其共識效率低下，例如，以太坊的共識效率為每秒確認10-20筆交易（注：這里的交易是指在區(qū)塊鏈上確認并記錄的事件，并不限于金融意義上的交易）。這使其在政府企業(yè)級的應用場景受到極大限制。

鑒于公鏈共識效率低下問題，一些新型平臺的設計者，將區(qū)塊鏈共識范圍從無限節(jié)點，縮小到在有限個節(jié)點范圍（如幾十到幾百個共識節(jié)點）。由此，誕生了聯(lián)盟鏈，即：在有限范圍進行共識的區(qū)塊鏈。聯(lián)盟鏈定義的場景，比起公鏈，更適合政府企業(yè)級應用，因為在這些場景，需要達成共識的節(jié)點往往是有限的，如：一個國家有若干個行政區(qū)，一個公司有若干個部門。由于需要共識節(jié)點少了，同時，各個共識節(jié)點間，也有了一定程度的信任，聯(lián)盟鏈的共識效率比起公鏈也就提高了，聯(lián)盟鏈的共識效率往往可以達到每秒確認百筆交易以上。

聯(lián)盟鏈的共識算法，和比特幣的公鏈共識算法有很大的不同。早在1982年，Lamport將有限節(jié)點間的共識問題總結為拜占庭將軍問題[9]。該問題描述如下：若干個拜占庭的將軍，聯(lián)合圍攻一個敵軍城堡，他們需要共同商定一個進攻時間，相互之間只能通過通信兵進行通信。問題假設，這些將軍當中可能有叛徒，同時假設通信兵之間的通信有可能被干擾，如被敵軍截獲或者被敵人換成假信息。那么，將軍間如何通信可以確保，在即使有叛徒的情況下，仍然可以準確的達成一致的進攻時間。這樣的問題稱為拜占庭將軍問題。而從數(shù)學上得到驗證，在叛徒和通信干擾不多于整體將軍數(shù)量1/3的情況下，拜占庭將軍問題可以得到解。拜占庭將軍問題的解法，稱為拜占庭容錯（BFT）。1999年，Miguel Castro等學者提出實用拜占庭容錯算法[10]，增強了拜占庭將軍問題的解決效率。而在一些場景中，可以假設沒有叛徒，只會存在通信無法送達的情況，在這種問題的解決方案被描述為宕機容錯（CFT）。解決CFT問題的RAFT算法于2013年被提出[11]。

而聯(lián)盟鏈的實現(xiàn)上，一些聯(lián)盟鏈是基于以太坊的改版，另一些是基于BFT類算法進行的實現(xiàn)。聯(lián)盟鏈當中的佼佼者是IBM的開源項目Hyperledger和R3公司的開源項目Corda。Corda平臺的應用場景是針對金融機構，這里不做過多論述。后文會有對IBM的Hyperledger的詳細介紹。IBM公司長期為企業(yè)服務，提供企業(yè)級IT級商業(yè)解決方案。該公司積累了大量政府、企業(yè)服務案例，對政府企業(yè)需求有較為深刻的認識。因此，其Hyperledger項目，從設計之初，就非常針對政府企業(yè)級需求痛點。

表1總結了目前主流的區(qū)塊鏈平臺特性。如表，以太坊（Ethereum）平臺是通用的公鏈平臺，也是最早的智能合約平臺，優(yōu)點是共識范圍廣，缺點是共識效率相對低下。廣泛應用于代幣、通證的發(fā)行，目前絕大多數(shù)的虛擬貨幣，都是基于以太坊平臺開發(fā)的。Corda平臺是針對金融業(yè)的平臺，其對金融銀行業(yè)的需求有較高的契合度。Fabric平臺（即Hyperledger），是針對企業(yè)級應用開發(fā)的平臺，其優(yōu)點是共識效率較高，且其智能合約的編程語言也是當今比較流行的Go語言。其缺點是，沒有辦法很容易的生成通證或代幣，這使其在金融領域的應用受到一定限制，往往實踐中，如在金融領域應用，會配合有代幣的平臺，如以太坊平臺共同使用。

基于上述總結，不難發(fā)現(xiàn)Hyperledger Fabric平臺比較適合于政府及企業(yè)的場景。其原因有如下幾點：

（1）政府及企業(yè)場景往往需要在有限的若干部門之間進行數(shù)據(jù)共識，且有一定的共識效率要求。

（2）政府企業(yè)類場景，相對封閉，需要對訪問者進行許可限制。

（3）這些場景一般不和金融相關，且不需要代幣。

3 區(qū)塊鏈設計案例剖析

3.1 國際平臺設計實踐--Ripple

Ripple是很好的平臺設計參考案例。其價值在于，Ripple是第一個面向企業(yè)的解決方案。Ripple公司成立于2013年，通過區(qū)塊鏈技術，提供銀行間清算服務，解決銀行間跨境交易時間長成本高的問題。在Ripple之前，銀行間跨境轉賬用的是基于1973年定的SWIFT code標準。以美國銀行為例，其國際轉賬單筆手續(xù)費大致在15-45美金不等，按照5萬美元一筆計算，轉賬費用在萬分之三到萬分之九之間，如金額較小則費率更高。而Ripple的解決方案，可以在3.59秒確認交易，每筆交易費用約為0.000003美元。如今Ripple已經與300余家銀行與金融機構簽署了服務協(xié)議，提供Ripple技術服務。Ripple的交易原理簡介如下：其會在服務的每家銀行設立Ripple網關，每家銀行需向網關中存入一定數(shù)量的XRP（一種Ripple發(fā)行的虛擬貨幣）。當銀行A向銀行B發(fā)起一筆轉賬，則網關A向網關B發(fā)送一定數(shù)量的XRP，以XRP計價A銀行向B銀行的轉賬數(shù)額。類比的講，Ripple做的事情就像交易中的路由器，而XRP就像路由器中的數(shù)據(jù)包，只不過這些XRP傳遞的是交易信息。

在技術設計上，Ripple有其獨到之處。一方面，Ripple的成立僅在比特幣誕生的4年后，還略早于以太坊，可以參考的同類型技術平臺不多；另一方面，Ripple的服務對象，不再像比特幣那樣，是公眾交易，而是企業(yè)，從性能到需求上都有其特殊的地方。雖然Ripple服務的金融領域有一定的特殊性，但是Ripple的設計，可以認為是企業(yè)級區(qū)塊鏈平臺的設計的經典案例。

在架構上，Ripple并不像比特幣那樣全部去中心化，而是參考了服務器與客戶端的設計，見圖 1 Ripple架構示意[12]。客戶端只負責發(fā)送接受客戶請求等少量任務，并不參與共識，多數(shù)任務在服務器端完成。服務器端采用分布式設計，共識機制只在服務器端的若干節(jié)點間進行。在服務器端，也分為追蹤節(jié)點（tracking node）和驗證節(jié)點（validating node）。其中，追蹤節(jié)點只負責分發(fā)交易信息以及響應客戶端的賬本請求，而驗證節(jié)點包含追蹤節(jié)點的所有功能，并且負責共識投票。除此之外， 驗證節(jié)點還維持一個可信節(jié)點名單（UNL），只有在名單中的節(jié)點才會被認為是合法可信的驗證節(jié)點。一個客戶端的請求，通過接入追蹤或驗證節(jié)點被廣播到整個服務器網絡。

圖1：Ripple架構示意[12]

在共識機制的選擇上面，Ripple并沒有選擇工作量證明機制。效率上講，工作量證明機制很難滿足銀行間動輒每秒上千筆交易的需求，例如：比特幣每秒確認的交易量只有3-4筆。因此，Ripple的共識機制，參考了BFT類的設計，具有PBFT的影子。

3.2 企業(yè)級解決方案Hyperledger平臺

Hyperledger是IBM公司發(fā)起的開源項目。其目的是建立一個幫助企業(yè)解決生產中實際問題的區(qū)塊鏈平臺。目前大多企業(yè)級區(qū)塊鏈應用，都是通過Hyperledger及其改版實現(xiàn)的。

Hyperledger在需求適配上，有以下特點：

（1）網絡采用許可制，這樣就保證了系統(tǒng)和共識服務只在小范圍節(jié)點間進行，是安全性和效率的前提保證。

（2）適配于企業(yè)需求的高吞吐量和低延時。

（3）具有私有數(shù)據(jù)概念，使得商業(yè)和政府的私有數(shù)據(jù)得到保護。

Hyperledger在設計上，采用模塊化。核心模塊有以下幾個：身份管理，賬本管理，交易管理，智能合約。見圖 2 Hyperledger 架構[13]。

圖2：Hyperledger架構[13]

（1）身份管理：主要是membership service provider: 系統(tǒng)會員權限管理模塊，對不同使用者分配不同的權限訪問等級。這點不同于比特幣等公鏈。在公鏈中，沒有準入權限，也就是，所有人的權限都是一樣的。

（2）賬本管理，主要是ordering service，交易排序服務，利用共識機制，將信息傳播至系統(tǒng)網絡。

（3）交易管理：peer-to-peer gossip service: 點對點傳輸服務，使用者可以在對等節(jié)點上訂閱服務。

（4）智能合約：在Hyperledger中稱為chaincode?？梢杂枚喾N主流開發(fā)語言編寫，可動態(tài)部署，且可以存在多個不同的合約。

這里，對Hyperledger的共識機制部分，進行單獨討論。Hyperledger采用了發(fā)布/訂閱的事件管理框架，參與者在有權限，且合法訂閱了內容后，可以通過監(jiān)聽的方式獲取系統(tǒng)內共識的事件。一些參與節(jié)點之間，可以通過Channel，形成一個子網絡，所有channel成員之間的信息，只限于子網內部傳播。對應公鏈的交易共識機制來看，Hyperledger的共識機制被拆分成兩個主要的服務：對賬本的共識部分主要放在排序服務中做，而點對點的交易服務，單獨成為一個服務。

而底層共識機制算法上，Hyperledger也沒有采納工作量證明機制（工作量證明共識的特征即為廣為人知的挖礦），在設計層面主要針對BFT和CFT類問題。Hyperledger在早期版本中，采用了PBFT算法進行節(jié)點間共識。然而，在后續(xù)比較穩(wěn)定的版本中，PBFT算法被剔除，雖然計劃在未來變?yōu)榭芍С值膫溥x算法，但目前版本以不再支持PBFT。新版本改用了CFT類的算法RAFT。RAFT算法原理為，從若干個節(jié)點中，選出一個領袖節(jié)點，所有共識信息以其為標準分發(fā)給其他節(jié)點，當領袖節(jié)點出現(xiàn)異常，如宕機情況，則由其余節(jié)點中重新選擇領袖節(jié)點。

雖然沒有說明，但是這樣的改動卻也是符合常理的，原因如下：

（1）PBFT算法共識，對于企業(yè)級解決方案來說，還是過于復雜，且效率低下。

（2）企業(yè)級解決方案中，大部分場景可以假設并沒有惡意節(jié)點，更多情況是通信丟失或者宕機這樣的情況。由此，基于CFT的RAFT算法就成為了項目的核心共識算法。這樣的算法簡單且共識效率高。

3.3 我國IT應用場景的實踐

國內區(qū)塊鏈發(fā)展，主要分為基礎區(qū)塊鏈平臺和區(qū)塊鏈應用兩類?；A平臺，大都是基于開源平臺的改版，如以太坊平臺，Hyperledger平臺等。除了一些專門做平臺的IT公司，國內主要做云服務平臺的公司，大都提供自己的區(qū)塊鏈平臺。由于上述討論的Ripple就是區(qū)塊鏈平臺，同時我們下面還要討論的到平臺，我們這里不妨看一下應用的典型設計案例。應用企業(yè)中的典型是阿里巴巴和螞蟻。由于阿里和螞蟻豐富的生態(tài)，為其在區(qū)塊鏈中的探索，提供了豐富的場景。這里列出了一些已經實現(xiàn)的區(qū)塊鏈應用場景：

3.3.1 公益

（1）2016年的7月，上線區(qū)塊鏈公益籌款項目"聽障兒童重獲新聲”。

（2）2017年3月，支付寶愛心捐贈平臺利用區(qū)塊鏈技術所有捐贈數(shù)據(jù)上了鏈。

3.3.2 溯源

（1）2017年3月，阿里巴巴與多家公司合作，利用區(qū)塊鏈技術溯源食品原產地。

（2）2017年10月，螞蟻金服技術實驗室宣布開放區(qū)塊鏈技術,支持進口食品安全和正品商品的溯源。第一個落地場景是對澳洲、新西蘭的26個品牌奶粉的追蹤，

（3）2017年11月，天貓國際宣布升級全球原產地溯源計劃。

（4）2018年2月，菜鳥與天貓國際啟用區(qū)塊鏈技術追蹤跨境進口商品的物流全鏈路信息。

（5）2018年3月，阿里正式宣布天貓海淘將利用區(qū)塊鏈技術跟蹤、上傳、查證跨境進口商品的物流全鏈路信息，防止造假。

（6）租房。

（7）2018年1月，雄安建成區(qū)塊鏈租房應用平臺螞蟻區(qū)塊鏈上線。

3.3.3 金融

（1）2016年6月，阿里金融云和易城互動也聯(lián)合推出“云優(yōu)商城” 。

（2）2018年6月25日，螞蟻金服宣布上線全球首個基于區(qū)塊鏈的電子錢包跨境匯款服務，并且現(xiàn)場完成了第一筆匯款。據(jù)了解，第一筆匯款由在中國香港工作22年的菲律賓人格蕾絲(Grace)完成，耗時僅3秒，省錢省事、安全透明。

以商品溯源場景為例，螞蟻通過區(qū)塊鏈技術，完成對若干食品的溯源，典型如阿里的五常大米溯源，為食品安全提供了額外保障。一個商品的流通往往經過：生產商、關檢、商檢、倉儲方、物流、分銷商等環(huán)節(jié)。區(qū)塊鏈技術，配合商品二維碼，電子標簽等采集端技術，為商品在各個領域的流通，建立全生命周期的可信電子身份，使得商品購買者可以很容易的將商品追溯到其產地。

4 總結

區(qū)塊鏈技術經由10多年發(fā)展，已經從開始的工作量證明機制，演化到更高效、小范圍共識算法研究；共識內容也從簡單的交易信息，演化到智能合約。在應用領域，算法和架構的精進，使得區(qū)塊鏈技術不再只能做虛擬的如數(shù)字游戲般的虛擬交易。區(qū)塊鏈的應用場景經由最初的，比特幣為代表的虛擬貨幣，已經發(fā)展到了企業(yè)和政府端的應用。在這個時間節(jié)點，我們需要對區(qū)塊鏈的應用設計進行剖析研究。本文側重于區(qū)塊鏈和實際應用領域的結合。技術與案例相結合，通過實踐案例剖析區(qū)塊鏈技術的設計。為區(qū)塊鏈的發(fā)展和使用提供參考。