摘要：作為系列的新篇章，我選擇從超級賬本的開始。為什么選擇超級賬本作為起點(diǎn)我在之前的文章中曾說過會(huì)從超級賬本入手開始區(qū)塊鏈的學(xué)習(xí)和實(shí)踐，同時(shí)也給出了個(gè)人的理由。檢查事務(wù)提議的響應(yīng)。為了降低區(qū)塊鏈應(yīng)用的開發(fā)難度，超級賬本項(xiàng)目又引入了。

本著“以教帶學(xué)，Learning by Doing”的想法，我于上周加入了Bob組織的HiBlock區(qū)塊鏈技術(shù)布道群。這個(gè)群可不太好混，群規(guī)要求每個(gè)成員必需每周有輸出，連續(xù)兩次交白卷就要被踢出群。

在這樣的壓力之下，我決定開一個(gè)新坑：區(qū)塊鏈周周記，記錄下每周區(qū)塊鏈的學(xué)習(xí)成果和爬坑經(jīng)驗(yàn)。作為系列的新篇章，我選擇從超級賬本的Fabric開始。

我在之前的文章中曾說過會(huì)從超級賬本入手開始區(qū)塊鏈的學(xué)習(xí)和實(shí)踐，同時(shí)也給出了個(gè)人的理由。但作為一篇布道類文章，單單個(gè)人喜好是沒有說服力的。

在Fabric的文檔中，它強(qiáng)調(diào)了自己面向企業(yè)應(yīng)用而生的理由：

企業(yè)希望跟身份確定的人做生意，而非像公鏈那樣完全匿名的對手方

并非人人都可加入的商業(yè)網(wǎng)絡(luò)

交易的私密性，比如，對于不同的渠道或經(jīng)銷商，他們各自拿到的折扣不一樣，這些信息必須是私密的，相互隔離。

性能和交易確認(rèn)的時(shí)延

可以看得出，相比起公鏈激進(jìn)的做法，以Fabric為代表的聯(lián)盟鏈要溫和的多，并且也容易為企業(yè)所接受。加上其給出的若干限制，技術(shù)上的落地也相對容易很多。

關(guān)于區(qū)塊鏈本身的理論和介紹，目前已經(jīng)爛大街了，在此也就是不再贅述。在本節(jié)，讓我們來看看Fabric是如何通過主要組件完成技術(shù)落地的。

從大的方面講，F(xiàn)abric的主要組件大致可劃分成這幾個(gè)部分：

分布式賬本，解決數(shù)據(jù)共享問題，讓所有參與方擁有共同的交易歷史。

智能合約，解決應(yīng)用與賬本的交互問題，包括查詢和更新。

共識(shí)機(jī)制，解決數(shù)據(jù)同步問題，基于Endorsement Policy實(shí)現(xiàn)交易的傳播。

成員服務(wù)，解決參與方身份問題，只有可信成員之間才能完成交易。

Fabric的分布式賬本狀態(tài)由兩部分組成：世界狀態(tài)（World State）和區(qū)塊鏈。前者代表賬本的當(dāng)前狀態(tài)，變更和查詢頻繁，往往以數(shù)據(jù)庫形式實(shí)現(xiàn)；后者則用來捕獲前者的每次變更，作為交易的變更記錄，無法修改且極少查詢，常常實(shí)現(xiàn)為文件形式。

對于世界狀態(tài)的DB載體，當(dāng)前版本有兩個(gè)選擇：內(nèi)置的LevelDB和外置的CouchDB，如果想要獲得更靈活的查詢能力，選擇后者。由此大家應(yīng)該可以猜出：世界狀態(tài)中保存的數(shù)據(jù)是以KV對的形式存在。

對于區(qū)塊鏈來講，它以Block的hash鏈組成，每個(gè)Block包含一組有序的交易。這個(gè)順序是交易順序，非常關(guān)鍵。

除了這兩個(gè)組件，F(xiàn)abric還引入了一個(gè)獨(dú)特的設(shè)計(jì)：Channel，用來解決不同組織間的賬本共享問題。假如組織A同時(shí)與組織B和組織C做生意，并且組織B和組織C是競爭對手，那么通過建立不同的Channel可以實(shí)現(xiàn)A和B，A和C分別共享各自的賬本。利用Channel，很好地解決了常見的B2B場景。

Channel抽象出了業(yè)務(wù)參與方的溝通，可視為業(yè)務(wù)網(wǎng)絡(luò)的子網(wǎng)，實(shí)現(xiàn)了交易的相互隔離和業(yè)務(wù)私密性。

Fabric的智能合約以“鏈碼（Chaincode）”的形式存在，外部客戶端利用它來完成對世界狀態(tài)的更改。與以太坊不同，鏈碼支持使用通用編程語言來書寫，當(dāng)前版本支持Go和Node.js，但從Fabric Java SDK的源碼中可以看出，離支持Java應(yīng)該也不遠(yuǎn)了：

public enum Type {
    JAVA,
    GO_LANG,
    NODE
}

對于初學(xué)者需要注意的是：鏈碼 != Fabric SDK。前者運(yùn)行于Fabric環(huán)境，執(zhí)行業(yè)務(wù)邏輯。后者則由被客戶端程序用來與鏈碼完成交互。打個(gè)類似的比方：

將Fabric環(huán)境視為Tomcat這樣的容器。

鏈碼則可視為運(yùn)行于其中的Servlet。

Fabric SDK則類似HttpClient這樣的類庫被Java客戶端利用發(fā)起請求，實(shí)現(xiàn)于Servlet的交互。

由此可知，鏈碼本身實(shí)際上是一個(gè)應(yīng)用，其生命周期可分為：package、install、instantiate、upgrade。同樣，鏈碼可以綁定任意任意數(shù)量的Channel，并獨(dú)立運(yùn)行。

關(guān)于鏈碼的教程，文檔已經(jīng)給出了詳細(xì)的說明，在此就不再啰嗦。

Fabric中有三類節(jié)點(diǎn)：

Client，代表最終用戶向endorser提交事務(wù)調(diào)用（Transaction Invocation），向ordering service廣播事務(wù)提議（Transaction Proposal）。

Peer，提交事務(wù)，維護(hù)世界狀態(tài)和賬本副本（區(qū)塊鏈）。其中，有一類特殊的Peer是Endorser。

Orderer，提供節(jié)點(diǎn)間的通信服務(wù)，保證消息的交付和順序，典型如Kafka隊(duì)列。

整個(gè)事務(wù)流程在文檔中有介紹：

client發(fā)起事務(wù)提議。

endorser peer驗(yàn)證并執(zhí)行。

client檢查事務(wù)提議的響應(yīng)。

若endorsement policy滿足，client將endorsement打包進(jìn)事務(wù)，提交給ordering service。消息包括：endorser簽名、讀寫集和channel id。

事務(wù)被orderer提交給channel上所有的peer，它們會(huì)檢查并提交事務(wù)。

賬本更新。

從上面的流程可以看出，F(xiàn)abric的共識(shí)機(jī)制建立在endorsement policy之上，它可以通過命令行參數(shù)進(jìn)行配置，并不需要Channel的所有Peer參與。

成員服務(wù)負(fù)責(zé)參與方的身份許可和驗(yàn)證，它建立于數(shù)字證書和信任鏈基礎(chǔ)之上。所謂成員，既可以是組織（Org），也可以是組織部門（OU）。Fabric的成員服務(wù)配置可以出現(xiàn)在兩處：Local（節(jié)點(diǎn)）和Channel（Channel級）。

從開發(fā)角度來講，引入成員服務(wù)帶來的作用就是：如果應(yīng)用（Client和Chaincode）要參與到區(qū)塊鏈網(wǎng)絡(luò)中，則需要相應(yīng)簽名和證書。

老實(shí)講，從上面的簡單介紹已經(jīng)看出，F(xiàn)abric的開發(fā)并不簡單，它至少涉及：

Client，提供UI、鏈碼交互以及其他輔助功能。

鏈碼，負(fù)責(zé)執(zhí)行業(yè)務(wù)邏輯。

業(yè)務(wù)網(wǎng)絡(luò)，定義參與方、Channel和Endorsement Policy。

成員管理，定義組織及其成員映射，這涉及到一系列證書的發(fā)放。

應(yīng)用部署，將上面的各部分部署到Fabric環(huán)境。

這還不算完，如何測試也是一個(gè)大麻煩，相比起簡單的CRUD應(yīng)用，光搭建Fabric的環(huán)境就讓人生畏。假如你對自己的要求更高點(diǎn)，想要實(shí)現(xiàn)一個(gè)持續(xù)集成環(huán)境，該怎么辦？

此外，開發(fā)之后的運(yùn)維成本也不會(huì)低，除了Fabric本身的基礎(chǔ)設(shè)施，鏈碼的平滑升級也對開發(fā)和運(yùn)維提出了高標(biāo)準(zhǔn)。

鑒于這些麻煩的事情，假如你沒有辦法說服業(yè)務(wù)合作方也同樣部署一套Fabric，我覺得完全沒有必要去基于它來開發(fā)應(yīng)用。單組織內(nèi)的區(qū)塊鏈應(yīng)用，我個(gè)人認(rèn)為是一個(gè)偽命題，沒有存在的價(jià)值。

關(guān)于示例教程，F(xiàn)abric的文檔已經(jīng)給出了范例，各位可以仔細(xì)閱讀。

為了降低區(qū)塊鏈應(yīng)用的開發(fā)難度，超級賬本項(xiàng)目又引入了Composer。其目的在于加速應(yīng)用的開發(fā)和部署，目前已經(jīng)支持Fabric，當(dāng)前處于孵化階段。它建立在諸多框架和工具之上：

node.js + angular，幫助開發(fā)者完成全棧區(qū)塊鏈解決方案的開發(fā)。

yeoman，利用其模板功能快速搭建應(yīng)用框架。

一套開發(fā)環(huán)境，實(shí)現(xiàn)應(yīng)用的打包部署以及暴露成Restful Service。

看起來很不錯(cuò)！

對于一個(gè)初學(xué)者來講，寫這篇文章真不容易！如文章存在錯(cuò)誤，不要客氣，只管指出，:)。關(guān)于下一周的周記，我會(huì)去寫一個(gè)實(shí)際的Fabric應(yīng)用的例子，同時(shí)給出Composer的例子，請保持關(guān)注。

附注：在寫此文的過程中，我還找到了一篇吐槽Fabric的文章，這里一并給出鏈接，方便大家客觀評定。