區(qū)塊鏈的現(xiàn)狀
比特幣可以說是區(qū)塊鏈的第一個實踐項目，而對于區(qū)塊鏈的介紹資料卻大多“言簡意賅”，說到區(qū)塊鏈大家相對熟悉的幾個詞可能是“數(shù)據(jù)不可篡改”、“公開鏈”、“分布式數(shù)據(jù)”、“共識機(jī)制”等，但是對于這種技術(shù)本身來說悲哀的是大多數(shù)參與比特幣的用戶并不是相信該技術(shù)的可靠性，而更多的是因為平臺其擁有巨大的用戶量和交易金額。
在此我想先簡單說下我對區(qū)塊鏈的理解及其適合的應(yīng)用場景，讓讀者更容易明白區(qū)塊鏈?zhǔn)鞘裁?，能做什么，然后再一一闡述區(qū)塊鏈?zhǔn)侨绾螐募夹g(shù)上去解決實際業(yè)務(wù)中的問題。
業(yè)務(wù)上所期望解決的問題——信用問題
首先從比特幣說起，大家對比特幣算力證明（POW）的名詞應(yīng)該不陌生，先不說其耗費(fèi)大量的資源，從共識機(jī)制上來看，擁有超過50%的算力即可掌控整個比特幣，無論從技術(shù)還是業(yè)務(wù)的角度都是一個風(fēng)險極高的機(jī)制，但神奇的金融圈沒有人會去觸碰這樣的底線，一旦有人擁有超過50%的算力，比特幣可能就玩不下去了：）
那么實際的業(yè)務(wù)場景中的需求應(yīng)該是怎樣的呢？比如說，銀行結(jié)算清算系統(tǒng)，傳統(tǒng)的銀行交易系統(tǒng)中，如果出現(xiàn)跨行交易，那么交易數(shù)據(jù)便需要一個清算系統(tǒng)進(jìn)行定時對賬確保雙方的交易數(shù)據(jù)是同步無誤的，那么就可能導(dǎo)致跨行轉(zhuǎn)賬需要T+1的時長，而主要的原因是因為雙方的系統(tǒng)及數(shù)據(jù)相互獨立，數(shù)據(jù)互不“信任”，所以需要一個清算系統(tǒng)去驗證交易數(shù)據(jù)，而區(qū)塊鏈可以說是為了解決這種“信任”問題的而產(chǎn)生的技術(shù)，在雙方進(jìn)行交易的同時對數(shù)據(jù)進(jìn)行了認(rèn)證，那么便無需交易后再進(jìn)行清算而達(dá)到實時轉(zhuǎn)賬等功能。其中微眾銀行發(fā)布了其區(qū)塊鏈的解決方案，至于微眾銀行開源的區(qū)塊鏈源碼我還沒去深入研究過便不予評價。更多的業(yè)務(wù)場景案例后續(xù)中舉例，下面來說為了解決“信用”問題，技術(shù)上需要哪些手段去滿足。
技術(shù)上需要哪些特性去達(dá)到”數(shù)據(jù)可信任“
以上面提出的清算系統(tǒng)為例，可能有人提出，雙方使用同一個分布式數(shù)據(jù)庫不就可以達(dá)到實時的數(shù)據(jù)同步了嘛。確實，區(qū)塊鏈其中一個特性便是分布式，但是和傳統(tǒng)的分布式數(shù)據(jù)庫區(qū)別在哪呢？在回歸到業(yè)務(wù)中，如果雙方銀行進(jìn)行交易的時候，使用這樣一個分布式數(shù)據(jù)庫，難道不擔(dān)心對方偷偷的吧數(shù)據(jù)改了嗎？如果你說有日志可以追述的到修改記錄，首先日志也是容易被修改的，且日志也無法挽回動不動可能就上百萬千萬甚至過億的金額損失，所以說傳統(tǒng)的分布式數(shù)據(jù)庫對于企業(yè)之間來說是”不可信的“，那么便要求區(qū)塊鏈需要達(dá)到數(shù)據(jù)不可篡改、用戶有身份認(rèn)證、交易可追述、交易有權(quán)重等一系列的特性。
剖析技術(shù)原理
上面說到區(qū)塊鏈的各種特性，從功能上來說這些特性有些是相輔相成并不能劃分的那么開，那么應(yīng)當(dāng)如何去實現(xiàn)這些功能呢，接下來結(jié)合Fabric的一些具體實現(xiàn)來一一闡述。
存儲數(shù)據(jù)結(jié)構(gòu)
要達(dá)到數(shù)據(jù)不可篡改首先從數(shù)據(jù)結(jié)構(gòu)上來看，也是區(qū)塊鏈之所以稱之為區(qū)塊鏈的原因。如下圖所示，每個存儲單元包含上一存儲單元的hash值（圖中hash值的對應(yīng)關(guān)系不完全精確，僅示意用）以及自身存儲的交易數(shù)據(jù)塊，可以從表象來看就像把所有數(shù)據(jù)塊連接在一起，稱之為“區(qū)塊鏈”，形成鏈狀可追述的交易記錄。這種鏈狀結(jié)構(gòu)的數(shù)據(jù)稱之為賬本數(shù)據(jù)，保存著所有交易的記錄，此外還有一個“世界狀態(tài)”，其實質(zhì)為Key-Value數(shù)據(jù)庫，維護(hù)著交易數(shù)據(jù)的最終狀態(tài)，便于查詢等操作運(yùn)算，并且每個數(shù)據(jù)都有其對應(yīng)的版本號。
Fabric主要模塊
總體來說市面上各種區(qū)塊鏈的實現(xiàn)方案都是基于這種數(shù)據(jù)結(jié)構(gòu)，而僅靠數(shù)據(jù)結(jié)構(gòu)并不能保證數(shù)據(jù)不可篡改，還有一個非常重要的因素，便是是共識機(jī)制，一個好的共識機(jī)制才是保障整個業(yè)務(wù)運(yùn)轉(zhuǎn)的根本，相當(dāng)于雙方簽訂的合同或者協(xié)議，只有雙方都遵守條約才能合作將業(yè)務(wù)展開進(jìn)行。例如常見的POW，POS，PBFT等都屬于共識機(jī)制，而其原理或者弊端這里不做贅述，主要來詳細(xì)講解Fabric應(yīng)用的設(shè)計方案及其原理，此前先解釋下一些特定名詞的概念。
首先說”智能合約“的概念。在傳統(tǒng)中心化的系統(tǒng)中，例如支付寶用戶A給B轉(zhuǎn)賬100元，那么假設(shè)起始A有100元B有0元，那么在支付寶系統(tǒng)內(nèi)調(diào)用轉(zhuǎn)賬的函數(shù)可能是這樣的一個流程，調(diào)用transfer(A,B,100)，而函數(shù)內(nèi)可能會去讀取用戶A和B的賬戶余額，那么我們可以表達(dá)成input(A,B,100),read(A:100,B:0),write(A:0,B:100)，那么這個僅是在支付寶的系統(tǒng)內(nèi)執(zhí)行了便完成了，那如何形成一個合約呢？就如A、B在簽訂一份合同，雙方都要對合同進(jìn)行簽名認(rèn)可，在程序中就等于，用戶A在其本地執(zhí)行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并對其簽名認(rèn)證，用戶B在其本地執(zhí)行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并對其簽名認(rèn)證，然后雙方將結(jié)果發(fā)給對方，然后判斷對方結(jié)果是否一致并對其簽名進(jìn)行校驗無誤后便認(rèn)為合約達(dá)成將結(jié)果寫入本地。通俗來說就是將一段核心代碼抽出來，所有參與方都去執(zhí)行該代碼并對其結(jié)果進(jìn)行簽名認(rèn)證比對，便稱之為執(zhí)行智能合約，而其中共有的代碼便是“合約"。
再說”背書策略“的概念。那么根據(jù)上面所言的共有代碼在交易中是不是所有用戶都要執(zhí)行呢？比如說A、B用戶轉(zhuǎn)賬，那么C、D用戶顯然就不需要規(guī)定其參與執(zhí)行職能合約了，那么背書策略便是規(guī)定智能合約的結(jié)果需要哪些成員的簽名背書才算交易成功。
在Fabric的交易流程中，主要有幾個關(guān)鍵節(jié)點參與，包括Peer節(jié)點、Orderer節(jié)點、CA節(jié)點及client端。
Peer節(jié)點
??該節(jié)點是參與交易的主體，可以說是代表每個參與到鏈上的成員，他負(fù)責(zé)儲存完整的賬本數(shù)據(jù)即區(qū)塊鏈數(shù)據(jù)，負(fù)責(zé)共識環(huán)節(jié)中的執(zhí)行智能合約，其中所有的Peer節(jié)點都維護(hù)完整的賬本數(shù)據(jù)稱之為Committer，而根據(jù)具體的業(yè)務(wù)劃分背書策略時決定哪些Peer。
Orderer節(jié)點
??該節(jié)點負(fù)責(zé)收集交易請求進(jìn)行排序并打包生產(chǎn)新的區(qū)塊，主體功能便是對交易排序從而保證各Peer節(jié)點上的數(shù)據(jù)一致性，也包含了ACL進(jìn)行訪問控制。
CA節(jié)點
??該節(jié)點負(fù)責(zé)對加入鏈內(nèi)的所有節(jié)點進(jìn)行授權(quán)認(rèn)證，包括上層的client端，每一個節(jié)點都有其頒發(fā)的證書用于交易流程中的身份識別。
client
??Fabric對于client端提供了SDK讓開發(fā)人員可以更容易的對接到區(qū)塊鏈內(nèi)的交易環(huán)節(jié)，交易的發(fā)起便是通過SDK進(jìn)行。
供應(yīng)鏈金融中的應(yīng)用
以上簡單的闡述了各模塊的功能，當(dāng)然實際當(dāng)中包含更多服務(wù)支持的功能，那么這里在套進(jìn)供應(yīng)鏈金融來舉例，更好的理解各節(jié)點的意義。
一個簡單的供應(yīng)鏈模型，一個核心企業(yè)向其供應(yīng)商進(jìn)行采購1000w物資，按照賒銷合同在收到物資后半年進(jìn)行結(jié)賬，那么半年的賬期供應(yīng)商資金無法周轉(zhuǎn)開便拿著核心企業(yè)開具的銀行承兌匯票進(jìn)行抵押融資，那么銀行審核通過后將票據(jù)95%的金額馬上轉(zhuǎn)給了供應(yīng)商，半年賬期到后，核心企業(yè)便直接將貨款轉(zhuǎn)給銀行，這樣就形成了一次供應(yīng)鏈的融資交易了。
在實際的業(yè)務(wù)當(dāng)中大部分都是在線下進(jìn)行操作的，耗費(fèi)眾多的人力及時間，那如何將這樣的業(yè)務(wù)轉(zhuǎn)成線上電子化呢？有人或許說銀行提供這樣的平臺服務(wù)不就好了嘛，那假設(shè)這個平臺不僅僅是這一家銀行參與呢，若所有的銀行或者企業(yè)都可以在同一個平臺進(jìn)行，那么交由某一個銀行提供服務(wù)就顯得不合適了。好，那么我們用Fabric來實現(xiàn)這樣一個系統(tǒng)我們看看在部署上是怎樣分布的呢。
上面是理想下的模型，當(dāng)然在實際當(dāng)中這樣的部署方案也可能不成立，比如供應(yīng)商并不一定有能力在其內(nèi)部接入服務(wù)器等。我們?nèi)匀灰源藶槔f明節(jié)點的意義，圖中每個參與方都在本地部署Peer節(jié)點以及接入業(yè)務(wù)系統(tǒng)client端，那么每個Peer節(jié)點都保持了所有交易的數(shù)據(jù)，那么在查數(shù)據(jù)的時候僅在本地便可完成，當(dāng)然也可以去查他人的Peer節(jié)點比對數(shù)據(jù)，而中心的CA節(jié)點負(fù)責(zé)給每一個節(jié)點包括client端頒發(fā)證書讓其在交易流程中可以互相認(rèn)證從而防止外部惡意接入查看數(shù)據(jù)或者參與交易，而Orderer節(jié)點與所有的Peer節(jié)點相連接獲取交易結(jié)果進(jìn)行排序控制，那么這里涉及到了整體的交易流程，引用官方的示例圖來解釋。
來描述一下上圖的交易流程，首先由client發(fā)起一個交易請求，而上圖中的背書策略要求Peer1、Peer2及Peer3參與交易，所以client將請求分別發(fā)給Pee1、Peer2和Peer3，然后三個Peer接收到交易請求后執(zhí)行對應(yīng)的智能合約并對結(jié)果進(jìn)行簽名然后分別將輸出結(jié)果返回給client，client收到所有執(zhí)行結(jié)果后打包一并發(fā)送到Orderer，Orderer將接收到的該次交易在交易池里進(jìn)行排序并組合打包生成一個新的區(qū)塊，Orderer將新的區(qū)塊發(fā)送給所有的Peer節(jié)點，每個Peer節(jié)點接收到新區(qū)塊后，對其中的每一筆交易結(jié)果的簽名進(jìn)行驗證是否符合背書策略，以及比對讀寫集合（Read-Write
Set，在下面的章節(jié)中解釋）與本地的版本是否相同，如滿足所有條件則將新的區(qū)塊寫入本地賬本內(nèi)完成交易。
以上是相對粗略的描述了交易流程，而實際當(dāng)中還有很多細(xì)節(jié)的處理。除此外可能有人會問，共識節(jié)點去哪了？為什么有Orderer這樣的中心節(jié)點？如果在細(xì)細(xì)思考一下，你會發(fā)現(xiàn)共識機(jī)制已經(jīng)融合在整個交易流程中了，這也是這個設(shè)計優(yōu)越的所在，我們來分析一下，假設(shè)Orderer節(jié)點是惡意節(jié)點，是否能控制交易生成”假賬“呢？那么在來看一下Orderer的功能，接收交易數(shù)據(jù)進(jìn)行排序并打包成塊，假設(shè)Orderer要造假數(shù)據(jù)，那么他需要繞過的是每個Peer節(jié)點將數(shù)據(jù)寫入前進(jìn)行的背書策略的校驗，那么數(shù)據(jù)里就必須包含背書策略里要求的節(jié)點簽名，而Orderer是沒有辦法獲取到各Peer節(jié)點的私鑰也就沒辦法生成對應(yīng)的簽名，由此Orderer是沒辦法控制交易鏈造假的，可以說Orderer是一個工具服務(wù)并不參與到任何業(yè)務(wù)流程內(nèi)，其關(guān)心的只是服務(wù)的穩(wěn)定性，如果需要數(shù)據(jù)對Orderer節(jié)點保密，目前需要自行實現(xiàn)數(shù)據(jù)加密。正因為其背書策略的設(shè)定，可以精確的滿足的具體的業(yè)務(wù)場景需求不會受到任何形式的惡意節(jié)點入侵，這也是區(qū)別于POW或者拜占庭容錯等，他們在一定條件后是可能被惡意節(jié)點所操控的。
核心基礎(chǔ)服務(wù)
對Fabric的主體模塊及流程有一定認(rèn)識后我們在繼續(xù)深究里面的細(xì)節(jié)功能，為了讓整個框架能運(yùn)作起來當(dāng)然需要用到更多的技術(shù)手段，這里主要講幾個相對核心的功能點。
Gossip Protocol
回顧上述的交易流程圖中，Orderer將交易數(shù)據(jù)排序打包后分發(fā)給各個Peer節(jié)點，若假設(shè)有成百上千甚至更多的Peer節(jié)點都由Orderer節(jié)點進(jìn)行分發(fā)那么首先單點的壓力是否能承受，其次如果出現(xiàn)失敗的情況又該如何同步等問題。在Fabric的實現(xiàn)當(dāng)中，采用的是讓Peer節(jié)點之間相互同步而非Orderer節(jié)點來分發(fā)消息，每個Peer節(jié)點都會維護(hù)其他Peer節(jié)點的信息，隨機(jī)的與部分其他Peer節(jié)點進(jìn)行通信互換區(qū)塊信息，傳輸時利用Peer-to-Peer的技術(shù)去加快數(shù)據(jù)的傳輸，而Orderer節(jié)點僅是將打包好的區(qū)塊發(fā)送至特定的Leader
Peer（可手動指定也可由Orderer自行選?。?，然后Peer節(jié)點之間在通過Gossip協(xié)議相互交換數(shù)據(jù)達(dá)到最終一致性。
Eventhub
那么根據(jù)上面描述的Gossip協(xié)議，可見每個Peer節(jié)點寫入?yún)^(qū)塊的時間可能是不一致的，那么client端進(jìn)行業(yè)務(wù)邏輯判斷（如事務(wù)邏輯）如何獲知特定交易數(shù)據(jù)是否已經(jīng)寫入Peer節(jié)點內(nèi)呢？實際上每個Peer都會和client端保持一個Eventhub的連接，在Peer節(jié)點完成交易后，如將區(qū)塊寫入賬本后便會發(fā)送消息通知各個client，但是也要注意，回調(diào)總是不可信的，存在消息丟失的可能性，F(xiàn)abric也并沒有保證消息的最終到達(dá)。
Read-Write Set
在Peer節(jié)點將一個區(qū)塊寫入賬本前，如上所述會進(jìn)行背書策略的校驗，以防止惡意節(jié)點的入侵，達(dá)到有權(quán)重劃分，可實名制交易的聯(lián)盟鏈。除去驗證各節(jié)點簽名驗證，當(dāng)然還要比對個節(jié)點輸出的結(jié)果是否一致，那如何去衡量結(jié)果是否一致呢？這里提出了讀寫集合的概念，一段程序我們化做為IO，如果使用相同Input得出一致的Output，那么我們便可以認(rèn)同在這一特定情況下函數(shù)性質(zhì)是相同的。在這里我們并不關(guān)心Input，只要寫入/修改的數(shù)據(jù)一致便可認(rèn)為達(dá)成了共識，所以Write
Set是用于保存最終需要寫入/修改的數(shù)據(jù)集，這個是用來比對各節(jié)點的結(jié)果集是否一致，而Read
Set中存著各節(jié)點執(zhí)行合約中讀取了哪些數(shù)據(jù)，并會把這個數(shù)據(jù)的當(dāng)前版本記錄在Read Set中，在Peer節(jié)點寫入?yún)^(qū)塊前也會校驗Read
Set中讀取的數(shù)據(jù)版本是否和當(dāng)前數(shù)據(jù)環(huán)境中的版本一致，以防止交易并發(fā)帶來的錯亂。
認(rèn)證體系
剛接觸區(qū)塊鏈的同學(xué)可能會有一個概念，區(qū)塊鏈應(yīng)該保證公平公正公開，所以形成了“公有鏈”的一個概念，例如比特幣，全員可參與，對所有人透明。但是區(qū)塊鏈并不僅局限于“公有鏈”，對于大多數(shù)業(yè)務(wù)場景來說，應(yīng)該屬于“聯(lián)盟鏈”，即由特定成員參與、有權(quán)重分配的業(yè)務(wù)，例如銀行間的對賬環(huán)節(jié)，A、B、C銀行互相的交易中，A、B銀行間的交易當(dāng)然不愿意透露給C銀行，而A、B、C銀行的所有交易或許都要上報給央行，可見此處“公有鏈”是不可取的。那如何去保證公平公正公開呢？首先代碼必須對成員開源，所有服務(wù)可由自身搭建，利益相關(guān)成員共同審核“智能合約”，全員共識的背書策略，相互授權(quán)或由可信第三方認(rèn)證中心授權(quán)。那么最基礎(chǔ)的一道認(rèn)證體系便顯得尤為重要了，我們在來看看Fabric是如何去實現(xiàn)他的認(rèn)證體系的。
首先有幾個概念需要明確，F(xiàn)abric的CA認(rèn)證中心是基于PKI體系打造的，相關(guān)資料可參考如下。
PKI(Public Key Infrastructure)
Membership Service Providers(MSP)
在劃分成員結(jié)構(gòu)的時候Fabric用MSP來定義一個成員，在最佳實例推薦中，一個企業(yè)或者機(jī)構(gòu)可以是一個單獨的MSP，例如上述說到的供應(yīng)鏈的案例，由例圖來說明，核心企業(yè)便是一個MSP，銀行和供應(yīng)商各代表一個MSP，那么在一個MSP下可以有多個Peer節(jié)點，而不同的授權(quán)便有不同的功能，MSP具體應(yīng)用場景主要如下。
在部署智能合約或者初始化時需要擁有對應(yīng)CA賦權(quán)的證書才可執(zhí)行（默認(rèn)為PeerAdmin用戶）。
為新節(jié)點或用戶注冊證書時，需要CA對該操作證書賦予權(quán)限（一般為Admin用戶）。
在背書策略中可通過MSP來代表背書成員，可設(shè)定單個Peer節(jié)點代表其MSP達(dá)成協(xié)議（也可以要求全部Peer節(jié)點通過才達(dá)成協(xié)議）。
在跨MSP間的Peer節(jié)點通信，先通過各MSP內(nèi)指定的Anchor Peer收集MSP內(nèi)的Peer列表，然后通過各MSP下的Anchor
Peer交互其Peer列表，將其他MSP下的Peer列表同步到內(nèi)部Peer后，便通過Gossip協(xié)議Peer節(jié)點間隨機(jī)通信。
每個MSP都有自己獨立的CA節(jié)點，為其提供所有的證書需求，各MSP共享其CA節(jié)點的ROOT證書達(dá)到互相認(rèn)證。
匿名交易。在一筆交易中，包含著每一個參與背書的用戶證書，這可以認(rèn)為是公開實名制的交易，所有鏈內(nèi)成員都可以看見每一筆交易是由誰參與的，但是如果我們希望匿名交易該如何實現(xiàn)呢？在Fabric
0.6版本內(nèi)有Ecert和Tcert的概念，Ecert即為用戶的證書，而Tcert則是用于匿名交易，用戶可以通過向CA申請一批Tcert用于交易，而該Tcert不包含用戶的信息，當(dāng)需要驗證查驗信息時可通過CA來認(rèn)證該用戶的身份。（此功能在1.0版本尚未實現(xiàn)）
Revoke，廢除證書。在PKI體系中，其最大的優(yōu)勢便是Off
line的，即在證書頒發(fā)后，不需要CA節(jié)點的存在也可以在本地進(jìn)行認(rèn)證，而遇到很大的問題是類似于廢除證書時如果希望能即是將廢除證書的消息通知到各個節(jié)點，目前的做法是需要CA節(jié)點保持在線并與各節(jié)點保持通信。（獲取Tcert也需要CA節(jié)點在線）
在每個區(qū)塊鏈中其相關(guān)的配置信息也包含了MSP的劃分，闡述相對復(fù)雜這里便不描述，有興趣可以參考官方文檔：）
難點及待解決的問題
上述篇幅主要是給讀者對Fabric的整體框架有基本的認(rèn)識，仍有許多細(xì)微的問題無法一一討論。當(dāng)然，在區(qū)塊鏈尚未大規(guī)模能應(yīng)用于市場下其技術(shù)也是不完善的，在Fabric中也有許多需要解決的難點問題。
在官方推薦的實踐當(dāng)中，劃分?jǐn)?shù)據(jù)的隔離是通過賬本的粒度進(jìn)行隔離，不關(guān)聯(lián)的交易便在不同的賬本中了，但是實際業(yè)務(wù)當(dāng)中，總有需要在單賬本內(nèi)進(jìn)行數(shù)據(jù)隔離的場景，早前已經(jīng)看到有相關(guān)的設(shè)計文檔出稿了，不過距離正式發(fā)布該功能就不確定合適能完成了，目前只能自行在業(yè)務(wù)邏輯中對數(shù)據(jù)進(jìn)行加密隔離。
當(dāng)兩個數(shù)據(jù)通過賬本隔離后需要交互的場景目前來看是比較難實現(xiàn)的，及跨賬本調(diào)用，首要解決的問題便是認(rèn)證模型如何去進(jìn)行融合。
目前想要接入?yún)^(qū)塊鏈的成本仍然是很高的，即便Fabric項目大部分功能都無法通過可視化的配置，需要了解更多的底層細(xì)節(jié)才能正確搭建環(huán)境及配置。
尾聲
能看到最后的朋友相信對區(qū)塊鏈有一定的研究或者非常感興趣，也歡迎各位進(jìn)行交流討論，若對Fabric有更多的疑問我也會盡可能的去解答。
最后歡迎各位大咖加入，推動區(qū)塊鏈的發(fā)展：）
引用
https://hyperledger-fabric.readthedocs.io/en/release/
https://github.com/hyperledger/fabric
https://www.ibm.com/blockchain/hyperledger.html
文章轉(zhuǎn)自：http://www.blockchainbrother.com/article/235
