Hyperledger Fabric週週記:起源

NO IMAGE

本著“以教帶學,Learning by Doing”的想法,我於上週加入了Bob組織的HiBlock區塊鏈技術佈道群。這個群可不太好混,群規要求每個成員必需每週有輸出,連續兩次交白卷就要被踢出群。

在這樣的壓力之下,我決定開一個新坑:區塊鏈週週記,記錄下每週區塊鏈的學習成果和爬坑經驗。作為系列的新篇章,我選擇從超級賬本的Fabric開始。

為什麼選擇超級賬本作為起點?

我在之前的文章中曾說過會從超級賬本入手開始區塊鏈的學習和實踐,同時也給出了個人的理由。但作為一篇佈道類文章,單單個人喜好是沒有說服力的。

Fabric的文件中,它強調了自己面向企業應用而生的理由:

企業希望跟身份確定的人做生意,而非像公鏈那樣完全匿名的對手方
並非人人都可加入的商業網路
交易的私密性,比如,對於不同的渠道或經銷商,他們各自拿到的折扣不一樣,這些資訊必須是私密的,相互隔離。
效能和交易確認的時延

可以看得出,相比起公鏈激進的做法,以Fabric為代表的聯盟鏈要溫和的多,並且也容易為企業所接受。加上其給出的若干限制,技術上的落地也相對容易很多。

Fabric中的主要元件

關於區塊鏈本身的理論和介紹,目前已經爛大街了,在此也就是不再贅述。在本節,讓我們來看看Fabric是如何通過主要元件完成技術落地的。

從大的方面講,Fabric的主要元件大致可劃分成這幾個部分:

分散式賬本,解決資料共享問題,讓所有參與方擁有共同的交易歷史。
智慧合約,解決應用與賬本的互動問題,包括查詢和更新。
共識機制,解決資料同步問題,基於Endorsement Policy實現交易的傳播。
成員服務,解決參與方身份問題,只有可信成員之間才能完成交易。

分散式賬本

Fabric的分散式賬本狀態由兩部分組成:世界狀態(World State)和區塊鏈。前者代表賬本的當前狀態,變更和查詢頻繁,往往以資料庫形式實現;後者則用來捕獲前者的每次變更,作為交易的變更記錄,無法修改且極少查詢,常常實現為檔案形式。

對於世界狀態的DB載體,當前版本有兩個選擇:內建的LevelDB和外接的CouchDB,如果想要獲得更靈活的查詢能力,選擇後者。由此大家應該可以猜出:世界狀態中儲存的資料是以KV對的形式存在。

對於區塊鏈來講,它以Block的hash鏈組成,每個Block包含一組有序的交易。這個順序是交易順序,非常關鍵。

除了這兩個元件,Fabric還引入了一個獨特的設計:Channel,用來解決不同組織間的賬本共享問題。假如組織A同時與組織B和組織C做生意,並且組織B和組織C是競爭對手,那麼通過建立不同的Channel可以實現A和B,A和C分別共享各自的賬本。利用Channel,很好地解決了常見的B2B場景。

Channel抽象出了業務參與方的溝通,可視為業務網路的子網,實現了交易的相互隔離和業務私密性。

智慧合約

Fabric的智慧合約以“鏈碼(Chaincode)”的形式存在,外部客戶端利用它來完成對世界狀態的更改。與以太坊不同,鏈碼支援使用通用程式語言來書寫,當前版本支援Go和Node.js,但從Fabric Java SDK的原始碼中可以看出,離支援Java應該也不遠了:

public enum Type {
JAVA,
GO_LANG,
NODE
}

對於初學者需要注意的是:鏈碼 != Fabric SDK。前者執行於Fabric環境,執行業務邏輯。後者則由被客戶端程式用來與鏈碼完成互動。打個類似的比方:

將Fabric環境視為Tomcat這樣的容器。
鏈碼則可視為執行於其中的Servlet。
Fabric SDK則類似HttpClient這樣的類庫被Java客戶端利用發起請求,實現於Servlet的互動。

由此可知,鏈碼本身實際上是一個應用,其生命週期可分為:package、install、instantiate、upgrade。同樣,鏈碼可以繫結任意任意數量的Channel,並獨立執行。

關於鏈碼的教程,文件已經給出了詳細的說明,在此就不再囉嗦。

共識機制

Fabric中有三類節點:

Client,代表終端使用者向endorser提交事務呼叫(Transaction Invocation),向ordering service廣播事務提議(Transaction Proposal)。
Peer,提交事務,維護世界狀態和賬本副本(區塊鏈)。其中,有一類特殊的Peer是Endorser。
Orderer,提供節點間的通訊服務,保證訊息的交付和順序,典型如Kafka佇列。

整個事務流程在文件中有介紹:

client發起事務提議。
endorser peer驗證並執行。
client檢查事務提議的響應。
若endorsement policy滿足,client將endorsement打包進事務,提交給ordering service。訊息包括:endorser簽名、讀寫集和channel id。
事務被orderer提交給channel上所有的peer,它們會檢查並提交事務。
賬本更新。

從上面的流程可以看出,Fabric的共識機制建立在endorsement policy之上,它可以通過命令列引數進行配置,並不需要Channel的所有Peer參與。

成員服務

成員服務負責參與方的身份許可和驗證,它建立於數字證書和信任鏈基礎之上。所謂成員,既可以是組織(Org),也可以是組織部門(OU)。Fabric的成員服務配置可以出現在兩處:Local(節點)和Channel(Channel級)。

從開發角度來講,引入成員服務帶來的作用就是:如果應用(Client和Chaincode)要參與到區塊鏈網路中,則需要相應簽名和證書。

Fabric的開發套路

老實講,從上面的簡單介紹已經看出,Fabric的開發並不簡單,它至少涉及:

Client,提供UI、鏈碼互動以及其他輔助功能。
鏈碼,負責執行業務邏輯。
業務網路,定義參與方、Channel和Endorsement Policy。
成員管理,定義組織及其成員對映,這涉及到一系列證書的發放。
應用部署,將上面的各部分部署到Fabric環境。

這還不算完,如何測試也是一個大麻煩,相比起簡單的CRUD應用,光搭建Fabric的環境就讓人生畏。假如你對自己的要求更高點,想要實現一個持續整合環境,該怎麼辦?

此外,開發之後的運維成本也不會低,除了Fabric本身的基礎設施,鏈碼的平滑升級也對開發和運維提出了高標準。

鑑於這些麻煩的事情,假如你沒有辦法說服業務合作方也同樣部署一套Fabric,我覺得完全沒有必要去基於它來開發應用。單組織內的區塊鏈應用,我個人認為是一個偽命題,沒有存在的價值。

關於示例教程,Fabric的文件已經給出了範例,各位可以仔細閱讀。

為了降低區塊鏈應用的開發難度,超級賬本專案又引入了Composer。其目的在於加速應用的開發和部署,目前已經支援Fabric,當前處於孵化階段。它建立在諸多框架和工具之上:

node.js angular,幫助開發者完成全棧區塊鏈解決方案的開發。
yeoman,利用其模板功能快速搭建應用框架。
一套開發環境,實現應用的打包部署以及暴露成Restful Service。

看起來很不錯!

寫在最後

對於一個初學者來講,寫這篇文章真不容易!如文章存在錯誤,不要客氣,只管指出,:)。關於下一週的週記,我會去寫一個實際的Fabric應用的例子,同時給出Composer的例子,請保持關注。

附註:在寫此文的過程中,我還找到了一篇吐槽Fabric的文章,這裡一併給出連結,方便大家客觀評定。