轉(zhuǎn):區(qū)塊鏈(Block Chain) Hyperledger Fabric 1.0 技術(shù)架構(gòu)詳解

區(qū)塊鏈的現(xiàn)狀

比特幣可以說是區(qū)塊鏈的第一個實踐項目,而對于區(qū)塊鏈的介紹資料卻大多“言簡意賅”若贮,說到區(qū)塊鏈大家相對熟悉的幾個詞可能是“數(shù)據(jù)不可篡改”作箍、“公開鏈”、“分布式數(shù)據(jù)”妈经、“共識機制”等,但是對于這種技術(shù)本身來說悲哀的是大多數(shù)參與比特幣的用戶并不是相信該技術(shù)的可靠性捧书,而更多的是因為平臺其擁有巨大的用戶量和交易金額吹泡。

在此我想先簡單說下我對區(qū)塊鏈的理解及其適合的應(yīng)用場景,讓讀者更容易明白區(qū)塊鏈是什么经瓷,能做什么荞胡,然后再一一闡述區(qū)塊鏈是如何從技術(shù)上去解決實際業(yè)務(wù)中的問題。

業(yè)務(wù)上所期望解決的問題——信用問題

首先從比特幣說起了嚎,大家對比特幣算力證明(POW)的名詞應(yīng)該不陌生,先不說其耗費大量的資源廊营,從共識機制上來看歪泳,擁有超過50%的算力即可掌控整個比特幣,無論從技術(shù)還是業(yè)務(wù)的角度都是一個風(fēng)險極高的機制露筒,但神奇的金融圈沒有人會去觸碰這樣的底線呐伞,一旦有人擁有超過50%的算力,比特幣可能就玩不下去了:)

那么實際的業(yè)務(wù)場景中的需求應(yīng)該是怎樣的呢慎式?比如說伶氢,銀行結(jié)算清算系統(tǒng)趟径,傳統(tǒng)的銀行交易系統(tǒng)中,如果出現(xiàn)跨行交易癣防,那么交易數(shù)據(jù)便需要一個清算系統(tǒng)進行定時對賬確保雙方的交易數(shù)據(jù)是同步無誤的蜗巧,那么就可能導(dǎo)致跨行轉(zhuǎn)賬需要T+1的時長,而主要的原因是因為雙方的系統(tǒng)及數(shù)據(jù)相互獨立蕾盯,數(shù)據(jù)互不“信任”幕屹,所以需要一個清算系統(tǒng)去驗證交易數(shù)據(jù),而區(qū)塊鏈可以說是為了解決這種“信任”問題的而產(chǎn)生的技術(shù)级遭,在雙方進行交易的同時對數(shù)據(jù)進行了認證望拖,那么便無需交易后再進行清算而達到實時轉(zhuǎn)賬等功能。其中微眾銀行發(fā)布了其區(qū)塊鏈的解決方案挫鸽,至于微眾銀行開源的區(qū)塊鏈源碼我還沒去深入研究過便不予評價说敏。更多的業(yè)務(wù)場景案例后續(xù)中舉例,下面來說為了解決“信用”問題丢郊,技術(shù)上需要哪些手段去滿足盔沫。

技術(shù)上需要哪些特性去達到”數(shù)據(jù)可信任“

以上面提出的清算系統(tǒng)為例,可能有人提出蚂夕,雙方使用同一個分布式數(shù)據(jù)庫不就可以達到實時的數(shù)據(jù)同步了嘛迅诬。確實,區(qū)塊鏈其中一個特性便是分布式婿牍,但是和傳統(tǒng)的分布式數(shù)據(jù)庫區(qū)別在哪呢侈贷?在回歸到業(yè)務(wù)中,如果雙方銀行進行交易的時候等脂,使用這樣一個分布式數(shù)據(jù)庫俏蛮,難道不擔(dān)心對方偷偷的吧數(shù)據(jù)改了嗎撑毛?如果你說有日志可以追述的到修改記錄愿棋,首先日志也是容易被修改的,且日志也無法挽回動不動可能就上百萬千萬甚至過億的金額損失免胃,所以說傳統(tǒng)的分布式數(shù)據(jù)庫對于企業(yè)之間來說是”不可信的“粉楚,那么便要求區(qū)塊鏈需要達到數(shù)據(jù)不可篡改辣恋、用戶有身份認證、交易可追述模软、交易有權(quán)重等一系列的特性伟骨。

剖析技術(shù)原理

上面說到區(qū)塊鏈的各種特性,從功能上來說這些特性有些是相輔相成并不能劃分的那么開燃异,那么應(yīng)當如何去實現(xiàn)這些功能呢携狭,接下來結(jié)合Fabric的一些具體實現(xiàn)來一一闡述。

存儲數(shù)據(jù)結(jié)構(gòu)

要達到數(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ù)庫线欲,維護著交易數(shù)據(jù)的最終狀態(tài),便于查詢等操作運算汽摹,并且每個數(shù)據(jù)都有其對應(yīng)的版本號李丰。

Fabric主要模塊

總體來說市面上各種區(qū)塊鏈的實現(xiàn)方案都是基于這種數(shù)據(jù)結(jié)構(gòu),而僅靠數(shù)據(jù)結(jié)構(gòu)并不能保證數(shù)據(jù)不可篡改逼泣,還有一個非常重要的因素趴泌,便是是共識機制,一個好的共識機制才是保障整個業(yè)務(wù)運轉(zhuǎn)的根本拉庶,相當于雙方簽訂的合同或者協(xié)議嗜憔,只有雙方都遵守條約才能合作將業(yè)務(wù)展開進行。例如常見的POW氏仗,POS吉捶,PBFT等都屬于共識機制,而其原理或者弊端這里不做贅述皆尔,主要來詳細講解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的賬戶余額每辟,那么我們可以表達成input(A,B,100),read(A:100,B:0),write(A:0,B:100)昔头,那么這個僅是在支付寶的系統(tǒng)內(nèi)執(zhí)行了便完成了,那如何形成一個合約呢影兽?就如A、B在簽訂一份合同莱革,雙方都要對合同進行簽名認可峻堰,在程序中就等于讹开,用戶A在其本地執(zhí)行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并對其簽名認證,用戶B在其本地執(zhí)行transfer(A,B,100)得出input(A,B,100),read(A:100,B:0),write(A:0,B:100)并對其簽名認證捐名,然后雙方將結(jié)果發(fā)給對方旦万,然后判斷對方結(jié)果是否一致并對其簽名進行校驗無誤后便認為合約達成將結(jié)果寫入本地。通俗來說就是將一段核心代碼抽出來镶蹋,所有參與方都去執(zhí)行該代碼并對其結(jié)果進行簽名認證比對成艘,便稱之為執(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é)點是參與交易的主體捂刺,可以說是代表每個參與到鏈上的成員,他負責(zé)儲存完整的賬本數(shù)據(jù)即區(qū)塊鏈數(shù)據(jù)商蕴,負責(zé)共識環(huán)節(jié)中的執(zhí)行智能合約叠萍,其中所有的Peer節(jié)點都維護完整的賬本數(shù)據(jù)稱之為Committer,而根據(jù)具體的業(yè)務(wù)劃分背書策略時決定哪些Peer绪商。

Orderer節(jié)點

??該節(jié)點負責(zé)收集交易請求進行排序并打包生產(chǎn)新的區(qū)塊苛谷,主體功能便是對交易排序從而保證各Peer節(jié)點上的數(shù)據(jù)一致性,也包含了ACL進行訪問控制格郁。

CA節(jié)點

??該節(jié)點負責(zé)對加入鏈內(nèi)的所有節(jié)點進行授權(quán)認證腹殿,包括上層的client端,每一個節(jié)點都有其頒發(fā)的證書用于交易流程中的身份識別锣尉。

client

??Fabric對于client端提供了SDK讓開發(fā)人員可以更容易的對接到區(qū)塊鏈內(nèi)的交易環(huán)節(jié),交易的發(fā)起便是通過SDK進行决采。

供應(yīng)鏈金融中的應(yīng)用

以上簡單的闡述了各模塊的功能自沧,當然實際當中包含更多服務(wù)支持的功能,那么這里在套進供應(yīng)鏈金融來舉例,更好的理解各節(jié)點的意義拇厢。

一個簡單的供應(yīng)鏈模型爱谁,一個核心企業(yè)向其供應(yīng)商進行采購1000w物資,按照賒銷合同在收到物資后半年進行結(jié)賬孝偎,那么半年的賬期供應(yīng)商資金無法周轉(zhuǎn)開便拿著核心企業(yè)開具的銀行承兌匯票進行抵押融資访敌,那么銀行審核通過后將票據(jù)95%的金額馬上轉(zhuǎn)給了供應(yīng)商,半年賬期到后衣盾,核心企業(yè)便直接將貨款轉(zhuǎn)給銀行寺旺,這樣就形成了一次供應(yīng)鏈的融資交易了。

在實際的業(yè)務(wù)當中大部分都是在線下進行操作的势决,耗費眾多的人力及時間阻塑,那如何將這樣的業(yè)務(wù)轉(zhuǎn)成線上電子化呢?有人或許說銀行提供這樣的平臺服務(wù)不就好了嘛徽龟,那假設(shè)這個平臺不僅僅是這一家銀行參與呢叮姑,若所有的銀行或者企業(yè)都可以在同一個平臺進行,那么交由某一個銀行提供服務(wù)就顯得不合適了据悔。好传透,那么我們用Fabric來實現(xiàn)這樣一個系統(tǒng)我們看看在部署上是怎樣分布的呢。

上面是理想下的模型极颓,當然在實際當中這樣的部署方案也可能不成立朱盐,比如供應(yīng)商并不一定有能力在其內(nèi)部接入服務(wù)器等。我們?nèi)匀灰源藶槔f明節(jié)點的意義菠隆,圖中每個參與方都在本地部署Peer節(jié)點以及接入業(yè)務(wù)系統(tǒng)client端兵琳,那么每個Peer節(jié)點都保持了所有交易的數(shù)據(jù),那么在查數(shù)據(jù)的時候僅在本地便可完成骇径,當然也可以去查他人的Peer節(jié)點比對數(shù)據(jù)躯肌,而中心的CA節(jié)點負責(zé)給每一個節(jié)點包括client端頒發(fā)證書讓其在交易流程中可以互相認證從而防止外部惡意接入查看數(shù)據(jù)或者參與交易,而Orderer節(jié)點與所有的Peer節(jié)點相連接獲取交易結(jié)果進行排序控制破衔,那么這里涉及到了整體的交易流程清女,引用官方的示例圖來解釋。

來描述一下上圖的交易流程晰筛,首先由client發(fā)起一個交易請求嫡丙,而上圖中的背書策略要求Peer1、Peer2及Peer3參與交易读第,所以client將請求分別發(fā)給Pee1曙博、Peer2和Peer3,然后三個Peer接收到交易請求后執(zhí)行對應(yīng)的智能合約并對結(jié)果進行簽名然后分別將輸出結(jié)果返回給client怜瞒,client收到所有執(zhí)行結(jié)果后打包一并發(fā)送到Orderer父泳,Orderer將接收到的該次交易在交易池里進行排序并組合打包生成一個新的區(qū)塊,Orderer將新的區(qū)塊發(fā)送給所有的Peer節(jié)點,每個Peer節(jié)點接收到新區(qū)塊后尘吗,對其中的每一筆交易結(jié)果的簽名進行驗證是否符合背書策略逝她,以及比對讀寫集合(Read-Write

Set,在下面的章節(jié)中解釋)與本地的版本是否相同睬捶,如滿足所有條件則將新的區(qū)塊寫入本地賬本內(nèi)完成交易。

以上是相對粗略的描述了交易流程近刘,而實際當中還有很多細節(jié)的處理擒贸。除此外可能有人會問,共識節(jié)點去哪了觉渴?為什么有Orderer這樣的中心節(jié)點介劫?如果在細細思考一下,你會發(fā)現(xiàn)共識機制已經(jīng)融合在整個交易流程中了案淋,這也是這個設(shè)計優(yōu)越的所在座韵,我們來分析一下,假設(shè)Orderer節(jié)點是惡意節(jié)點踢京,是否能控制交易生成”假賬“呢誉碴?那么在來看一下Orderer的功能,接收交易數(shù)據(jù)進行排序并打包成塊瓣距,假設(shè)Orderer要造假數(shù)據(jù)黔帕,那么他需要繞過的是每個Peer節(jié)點將數(shù)據(jù)寫入前進行的背書策略的校驗,那么數(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的主體模塊及流程有一定認識后我們在繼續(xù)深究里面的細節(jié)功能,為了讓整個框架能運作起來當然需要用到更多的技術(shù)手段更鲁,這里主要講幾個相對核心的功能點霎箍。

Gossip Protocol

回顧上述的交易流程圖中,Orderer將交易數(shù)據(jù)排序打包后分發(fā)給各個Peer節(jié)點澡为,若假設(shè)有成百上千甚至更多的Peer節(jié)點都由Orderer節(jié)點進行分發(fā)那么首先單點的壓力是否能承受漂坏,其次如果出現(xiàn)失敗的情況又該如何同步等問題。在Fabric的實現(xiàn)當中,采用的是讓Peer節(jié)點之間相互同步而非Orderer節(jié)點來分發(fā)消息顶别,每個Peer節(jié)點都會維護其他Peer節(jié)點的信息谷徙,隨機的與部分其他Peer節(jié)點進行通信互換區(qū)塊信息,傳輸時利用Peer-to-Peer的技術(shù)去加快數(shù)據(jù)的傳輸驯绎,而Orderer節(jié)點僅是將打包好的區(qū)塊發(fā)送至特定的Leader

Peer(可手動指定也可由Orderer自行選韧昊邸),然后Peer節(jié)點之間在通過Gossip協(xié)議相互交換數(shù)據(jù)達到最終一致性剩失。

Eventhub

那么根據(jù)上面描述的Gossip協(xié)議屈尼,可見每個Peer節(jié)點寫入?yún)^(qū)塊的時間可能是不一致的,那么client端進行業(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也并沒有保證消息的最終到達兄纺。

Read-Write Set

在Peer節(jié)點將一個區(qū)塊寫入賬本前,如上所述會進行背書策略的校驗是辕,以防止惡意節(jié)點的入侵囤热,達到有權(quán)重劃分,可實名制交易的聯(lián)盟鏈获三。除去驗證各節(jié)點簽名驗證旁蔼,當然還要比對個節(jié)點輸出的結(jié)果是否一致,那如何去衡量結(jié)果是否一致呢疙教?這里提出了讀寫集合的概念棺聊,一段程序我們化做為IO,如果使用相同Input得出一致的Output贞谓,那么我們便可以認同在這一特定情況下函數(shù)性質(zhì)是相同的限佩。在這里我們并不關(guān)心Input,只要寫入/修改的數(shù)據(jù)一致便可認為達成了共識裸弦,所以Write

Set是用于保存最終需要寫入/修改的數(shù)據(jù)集祟同,這個是用來比對各節(jié)點的結(jié)果集是否一致,而Read

Set中存著各節(jié)點執(zhí)行合約中讀取了哪些數(shù)據(jù)理疙,并會把這個數(shù)據(jù)的當前版本記錄在Read Set中晕城,在Peer節(jié)點寫入?yún)^(qū)塊前也會校驗Read

Set中讀取的數(shù)據(jù)版本是否和當前數(shù)據(jù)環(huán)境中的版本一致,以防止交易并發(fā)帶來的錯亂窖贤。

認證體系

剛接觸區(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銀行間的交易當然不愿意透露給C銀行,而A逊拍、B上鞠、C銀行的所有交易或許都要上報給央行,可見此處“公有鏈”是不可取的芯丧。那如何去保證公平公正公開呢芍阎?首先代碼必須對成員開源,所有服務(wù)可由自身搭建缨恒,利益相關(guān)成員共同審核“智能合約”谴咸,全員共識的背書策略,相互授權(quán)或由可信第三方認證中心授權(quán)骗露。那么最基礎(chǔ)的一道認證體系便顯得尤為重要了岭佳,我們在來看看Fabric是如何去實現(xiàn)他的認證體系的。

首先有幾個概念需要明確萧锉,F(xiàn)abric的CA認證中心是基于PKI體系打造的珊随,相關(guān)資料可參考如下。

PKI(Public Key Infrastructure)

X.509 證書

Membership Service Providers(MSP)

在劃分成員結(jié)構(gòu)的時候Fabric用MSP來定義一個成員柿隙,在最佳實例推薦中叶洞,一個企業(yè)或者機構(gòu)可以是一個單獨的MSP,例如上述說到的供應(yīng)鏈的案例禀崖,由例圖來說明衩辟,核心企業(yè)便是一個MSP,銀行和供應(yīng)商各代表一個MSP帆焕,那么在一個MSP下可以有多個Peer節(jié)點惭婿,而不同的授權(quán)便有不同的功能不恭,MSP具體應(yīng)用場景主要如下。

在部署智能合約或者初始化時需要擁有對應(yīng)CA賦權(quán)的證書才可執(zhí)行(默認為PeerAdmin用戶)财饥。

為新節(jié)點或用戶注冊證書時换吧,需要CA對該操作證書賦予權(quán)限(一般為Admin用戶)。

在背書策略中可通過MSP來代表背書成員钥星,可設(shè)定單個Peer節(jié)點代表其MSP達成協(xié)議(也可以要求全部Peer節(jié)點通過才達成協(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é)點間隨機通信宁改。

每個MSP都有自己獨立的CA節(jié)點缕探,為其提供所有的證書需求,各MSP共享其CA節(jié)點的ROOT證書達到互相認證还蹲。

匿名交易爹耗。在一筆交易中,包含著每一個參與背書的用戶證書谜喊,這可以認為是公開實名制的交易潭兽,所有鏈內(nèi)成員都可以看見每一筆交易是由誰參與的,但是如果我們希望匿名交易該如何實現(xiàn)呢斗遏?在Fabric

0.6版本內(nèi)有Ecert和Tcert的概念山卦,Ecert即為用戶的證書,而Tcert則是用于匿名交易诵次,用戶可以通過向CA申請一批Tcert用于交易账蓉,而該Tcert不包含用戶的信息,當需要驗證查驗信息時可通過CA來認證該用戶的身份藻懒。(此功能在1.0版本尚未實現(xiàn))

Revoke剔猿,廢除證書。在PKI體系中嬉荆,其最大的優(yōu)勢便是Off

line的归敬,即在證書頒發(fā)后,不需要CA節(jié)點的存在也可以在本地進行認證鄙早,而遇到很大的問題是類似于廢除證書時如果希望能即是將廢除證書的消息通知到各個節(jié)點汪茧,目前的做法是需要CA節(jié)點保持在線并與各節(jié)點保持通信。(獲取Tcert也需要CA節(jié)點在線)

在每個區(qū)塊鏈中其相關(guān)的配置信息也包含了MSP的劃分限番,闡述相對復(fù)雜這里便不描述舱污,有興趣可以參考官方文檔:)

難點及待解決的問題

上述篇幅主要是給讀者對Fabric的整體框架有基本的認識,仍有許多細微的問題無法一一討論弥虐。當然扩灯,在區(qū)塊鏈尚未大規(guī)模能應(yīng)用于市場下其技術(shù)也是不完善的媚赖,在Fabric中也有許多需要解決的難點問題。

在官方推薦的實踐當中珠插,劃分數(shù)據(jù)的隔離是通過賬本的粒度進行隔離惧磺,不關(guān)聯(lián)的交易便在不同的賬本中了,但是實際業(yè)務(wù)當中捻撑,總有需要在單賬本內(nèi)進行數(shù)據(jù)隔離的場景磨隘,早前已經(jīng)看到有相關(guān)的設(shè)計文檔出稿了,不過距離正式發(fā)布該功能就不確定合適能完成了顾患,目前只能自行在業(yè)務(wù)邏輯中對數(shù)據(jù)進行加密隔離番捂。

當兩個數(shù)據(jù)通過賬本隔離后需要交互的場景目前來看是比較難實現(xiàn)的,及跨賬本調(diào)用江解,首要解決的問題便是認證模型如何去進行融合设预。

目前想要接入?yún)^(qū)塊鏈的成本仍然是很高的,即便Fabric項目大部分功能都無法通過可視化的配置犁河,需要了解更多的底層細節(jié)才能正確搭建環(huán)境及配置絮缅。

尾聲

能看到最后的朋友相信對區(qū)塊鏈有一定的研究或者非常感興趣,也歡迎各位進行交流討論呼股,若對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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末彭谁,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子允扇,更是在濱河造成了極大的恐慌缠局,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,682評論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件考润,死亡現(xiàn)場離奇詭異狭园,居然都是意外死亡,警方通過查閱死者的電腦和手機糊治,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,277評論 3 395
  • 文/潘曉璐 我一進店門唱矛,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人井辜,你說我怎么就攤上這事绎谦。” “怎么了粥脚?”我有些...
    開封第一講書人閱讀 165,083評論 0 355
  • 文/不壞的土叔 我叫張陵窃肠,是天一觀的道長。 經(jīng)常有香客問我刷允,道長冤留,這世上最難降的妖魔是什么碧囊? 我笑而不...
    開封第一講書人閱讀 58,763評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮纤怒,結(jié)果婚禮上糯而,老公的妹妹穿的比我還像新娘。我一直安慰自己肪跋,他們只是感情好歧蒋,可當我...
    茶點故事閱讀 67,785評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著州既,像睡著了一般谜洽。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上吴叶,一...
    開封第一講書人閱讀 51,624評論 1 305
  • 那天阐虚,我揣著相機與錄音,去河邊找鬼蚌卤。 笑死实束,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的逊彭。 我是一名探鬼主播咸灿,決...
    沈念sama閱讀 40,358評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼侮叮!你這毒婦竟也來了避矢?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,261評論 0 276
  • 序言:老撾萬榮一對情侶失蹤囊榜,失蹤者是張志新(化名)和其女友劉穎审胸,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體卸勺,經(jīng)...
    沈念sama閱讀 45,722評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡砂沛,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了曙求。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片碍庵。...
    茶點故事閱讀 40,030評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖悟狱,靈堂內(nèi)的尸體忽然破棺而出怎抛,到底是詐尸還是另有隱情,我是刑警寧澤芽淡,帶...
    沈念sama閱讀 35,737評論 5 346
  • 正文 年R本政府宣布马绝,位于F島的核電站,受9級特大地震影響挣菲,放射性物質(zhì)發(fā)生泄漏富稻。R本人自食惡果不足惜掷邦,卻給世界環(huán)境...
    茶點故事閱讀 41,360評論 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望椭赋。 院中可真熱鬧抚岗,春花似錦、人聲如沸哪怔。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,941評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽认境。三九已至胚委,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間叉信,已是汗流浹背亩冬。 一陣腳步聲響...
    開封第一講書人閱讀 33,057評論 1 270
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留硼身,地道東北人硅急。 一個月前我還...
    沈念sama閱讀 48,237評論 3 371
  • 正文 我出身青樓,卻偏偏與公主長得像佳遂,于是被迫代替她去往敵國和親营袜。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,976評論 2 355

推薦閱讀更多精彩內(nèi)容