摘要：技術(shù)上需要哪些特性去達(dá)到數(shù)據(jù)可信任以上面提出的清算系統(tǒng)為例，可能有人提出，雙方使用同一個(gè)分布式數(shù)據(jù)庫不就可以達(dá)到實(shí)時(shí)的數(shù)據(jù)同步了嘛。

前言
Hyperledger Project 由Linux基金會創(chuàng)辦于2015年10月，是一個(gè)開源的區(qū)塊鏈研發(fā)孵化項(xiàng)目，致力于提供可協(xié)同開發(fā)以區(qū)塊鏈為底層的分布式賬本。旗下的Fabric項(xiàng)目目標(biāo)為打造一個(gè)提供分布式賬本解決方案的平臺。

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

那么實(shí)際的業(yè)務(wù)場景中的需求應(yīng)該是怎樣的呢？比如說，銀行結(jié)算清算系統(tǒng)，傳統(tǒng)的銀行交易系統(tǒng)中，如果出現(xiàn)跨行交易，那么交易數(shù)據(jù)便需要一個(gè)清算系統(tǒng)進(jìn)行定時(shí)對賬確保雙方的交易數(shù)據(jù)是同步無誤的，那么就可能導(dǎo)致跨行轉(zhuǎn)賬需要T+1的時(shí)長，而主要的原因是因?yàn)殡p方的系統(tǒng)及數(shù)據(jù)相互獨(dú)立，數(shù)據(jù)互不“信任”，所以需要一個(gè)清算系統(tǒng)去驗(yàn)證交易數(shù)據(jù)，而區(qū)塊鏈可以說是為了解決這種“信任”問題而產(chǎn)生的技術(shù)，在雙方進(jìn)行交易的同時(shí)對數(shù)據(jù)進(jìn)行了認(rèn)證，那么便無需交易后再進(jìn)行清算而達(dá)到實(shí)時(shí)轉(zhuǎn)賬等功能。下面來說為了解決“信用”問題，技術(shù)上需要哪些手段去滿足。

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

上面說到區(qū)塊鏈的各種特性，從功能上來說這些特性有些是相輔相成。那么應(yīng)當(dāng)如何去實(shí)現(xiàn)這些功能呢，接下來結(jié)合Fabric的一些具體實(shí)現(xiàn)來一一闡述。

要達(dá)到數(shù)據(jù)不可篡改首先從數(shù)據(jù)結(jié)構(gòu)上來看，也是區(qū)塊鏈之所以稱之為區(qū)塊鏈的原因。如下圖所示，每個(gè)存儲單元包含上一存儲單元的hash值（圖中hash值的對應(yīng)關(guān)系不完全精確，僅示意用）以及自身存儲的交易數(shù)據(jù)塊，可以從表象來看就像把所有數(shù)據(jù)塊連接在一起，稱之為“區(qū)塊鏈”，形成鏈狀可追述的交易記錄。這種鏈狀結(jié)構(gòu)的數(shù)據(jù)稱之為賬本數(shù)據(jù)，保存著所有交易的記錄，此外還有一個(gè)“世界狀態(tài)”，其實(shí)質(zhì)為Key-Value數(shù)據(jù)庫，維護(hù)著交易數(shù)據(jù)的最終狀態(tài)，便于查詢等操作運(yùn)算，并且每個(gè)數(shù)據(jù)都有其對應(yīng)的版本號。

總體來說，市面上各種區(qū)塊鏈的實(shí)現(xiàn)方案都是基于這種數(shù)據(jù)結(jié)構(gòu)，而僅靠數(shù)據(jù)結(jié)構(gòu)并不能保證數(shù)據(jù)不可篡改，還有一個(gè)非常重要的因素，便是共識機(jī)制，一個(gè)好的共識機(jī)制才是保障整個(gè)業(yè)務(wù)運(yùn)轉(zhuǎn)的根本，相當(dāng)于雙方簽訂的合同或者協(xié)議，只有雙方都遵守條約才能合作將業(yè)務(wù)展開進(jìn)行。例如常見的POW，POS，PBFT等都屬于共識機(jī)制，而其原理或者弊端這里不做贅述，主要來詳細(xì)講解Fabric應(yīng)用的設(shè)計(jì)方案及其原理，此前先解釋下一些特定名詞的概念。

首先說”智能合約“的概念。在傳統(tǒng)中心化的系統(tǒng)中，例如支付寶用戶A給B轉(zhuǎn)賬100元，那么假設(shè)起始A有100元B有0元，那么在支付寶系統(tǒng)內(nèi)調(diào)用轉(zhuǎn)賬的函數(shù)可能是這樣的一個(gè)流程，調(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)，那么這個(gè)僅是在支付寶的系統(tǒng)內(nèi)執(zhí)行了便完成了，那如何形成一個(gè)合約呢？

就如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)行校驗(yà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的交易流程中，主要有幾個(gè)關(guān)鍵節(jié)點(diǎn)參與，包括Peer節(jié)點(diǎn)、Orderer節(jié)點(diǎn)、CA節(jié)點(diǎn)及client端。

Peer節(jié)點(diǎn)

該節(jié)點(diǎn)是參與交易的主體，可以說是代表每個(gè)參與到鏈上的成員，他負(fù)責(zé)儲存完整的賬本數(shù)據(jù)即區(qū)塊鏈數(shù)據(jù)，負(fù)責(zé)共識環(huán)節(jié)中的執(zhí)行智能合約，其中所有的Peer節(jié)點(diǎn)都維護(hù)完整的賬本數(shù)據(jù)稱之為Committer，而根據(jù)具體的業(yè)務(wù)劃分背書策略時(shí)決定哪些Peer。

Orderer節(jié)點(diǎn)

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

CA節(jié)點(diǎn)

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

client

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

以上簡單的闡述了各模塊的功能，當(dāng)然實(shí)際當(dāng)中包含更多服務(wù)支持的功能，那么這里在套進(jìn)供應(yīng)鏈金融來舉例，更好地理解各節(jié)點(diǎn)的意義。

一個(gè)簡單的供應(yīng)鏈模型，一個(gè)核心企業(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)鏈的融資交易了。

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

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

來描述一下上圖的交易流程，首先由client發(fā)起一個(gè)交易請求，而上圖中的背書策略要求Peer1、Peer2及Peer3參與交易，所以client將請求分別發(fā)給Peer1、Peer2和Peer3，然后三個(gè)Peer接收到交易請求后執(zhí)行對應(yīng)的智能合約并對結(jié)果進(jìn)行簽名然后分別將輸出結(jié)果返回給client，client收到所有執(zhí)行結(jié)果后打包一并發(fā)送到Orderer，Orderer將接收到的該次交易在交易池里進(jìn)行排序并組合打包生成一個(gè)新的區(qū)塊，Orderer將新的區(qū)塊發(fā)送給所有的Peer節(jié)點(diǎn)，每個(gè)Peer節(jié)點(diǎn)接收到新區(qū)塊后，對其中的每一筆交易結(jié)果的簽名進(jìn)行驗(yàn)證是否符合背書策略，以及比對讀寫集合（Read-Write Set，在下面的章節(jié)中解釋）與本地的版本是否相同，如滿足所有條件則將新的區(qū)塊寫入本地賬本內(nèi)完成交易。

以上是相對粗略的描述了交易流程，而實(shí)際當(dāng)中還有很多細(xì)節(jié)的處理。除此外可能有人會問，共識節(jié)點(diǎn)去哪了？為什么有Orderer這樣的中心節(jié)點(diǎn)？如果再細(xì)細(xì)思考一下，你會發(fā)現(xiàn)共識機(jī)制已經(jīng)融合在整個(gè)交易流程中了，這也是這個(gè)設(shè)計(jì)優(yōu)越的所在，我們來分析一下，假設(shè)Orderer節(jié)點(diǎn)是惡意節(jié)點(diǎn)，是否能控制交易生成”假賬“呢？那么再來看一下Orderer的功能，接收交易數(shù)據(jù)進(jìn)行排序并打包成塊，假設(shè)Orderer要造假數(shù)據(jù)，那么他需要繞過的是每個(gè)Peer節(jié)點(diǎn)將數(shù)據(jù)寫入前進(jìn)行的背書策略的校驗(yàn)，那么數(shù)據(jù)里就必須包含背書策略里要求的節(jié)點(diǎn)簽名，而Orderer是沒有辦法獲取到各Peer節(jié)點(diǎn)的私鑰也就沒辦法生成對應(yīng)的簽名，由此Orderer是沒辦法控制交易鏈造假的，可以說Orderer是一個(gè)工具服務(wù)并不參與到任何業(yè)務(wù)流程內(nèi)，其關(guān)心的只是服務(wù)的穩(wěn)定性，如果需要數(shù)據(jù)對Orderer節(jié)點(diǎn)保密，目前需要自行實(shí)現(xiàn)數(shù)據(jù)加密。正因?yàn)槠浔硶呗缘脑O(shè)定，可以精確地滿足的具體的業(yè)務(wù)場景需求不會受到任何形式的惡意節(jié)點(diǎn)入侵，這也是區(qū)別于POW或者拜占庭容錯(cuò)等，他們在一定條件后是可能被惡意節(jié)點(diǎn)所操控的。

對Fabric的主體模塊及流程有一定認(rèn)識后，我們在繼續(xù)深究里面的細(xì)節(jié)功能，為了讓整個(gè)框架能運(yùn)作起來當(dāng)然需要用到更多的技術(shù)手段，這里主要講幾個(gè)相對核心的功能點(diǎn)。

Gossip Protocol

回顧上述的交易流程圖中，Orderer將交易數(shù)據(jù)排序打包后分發(fā)給各個(gè)Peer節(jié)點(diǎn)，若假設(shè)有成百上千甚至更多的Peer節(jié)點(diǎn)都由Orderer節(jié)點(diǎn)進(jìn)行分發(fā)那么首先單點(diǎn)的壓力是否能承受，其次如果出現(xiàn)失敗的情況又該如何同步等問題。在Fabric的實(shí)現(xiàn)當(dāng)中，采用的是讓Peer節(jié)點(diǎn)之間相互同步而非Orderer節(jié)點(diǎn)來分發(fā)消息，每個(gè)Peer節(jié)點(diǎn)都會維護(hù)其他Peer節(jié)點(diǎn)的信息，隨機(jī)的與部分其他Peer節(jié)點(diǎn)進(jìn)行通信互換區(qū)塊信息，傳輸時(shí)利用Peer-to-Peer的技術(shù)去加快數(shù)據(jù)的傳輸，而Orderer節(jié)點(diǎn)僅是將打包好的區(qū)塊發(fā)送至特定的Leader Peer（可手動指定也可由Orderer自行選?。缓驪eer節(jié)點(diǎn)之間在通過Gossip協(xié)議相互交換數(shù)據(jù)達(dá)到最終一致性。

Eventhub

那么根據(jù)上面描述的Gossip協(xié)議，可見每個(gè)Peer節(jié)點(diǎn)寫入?yún)^(qū)塊的時(shí)間可能是不一致的，那么client端進(jìn)行業(yè)務(wù)邏輯判斷（如事務(wù)邏輯）如何獲知特定交易數(shù)據(jù)是否已經(jīng)寫入Peer節(jié)點(diǎn)內(nèi)呢？實(shí)際上每個(gè)Peer都會和client端保持一個(gè)Eventhub的連接，在Peer節(jié)點(diǎn)完成交易后，如將區(qū)塊寫入賬本后便會發(fā)送消息通知各個(gè)client，但是也要注意，回調(diào)總是不可信的，存在消息丟失的可能性，F(xiàn)abric也并沒有保證消息的最終到達(dá)。

Read-Write Set

在Peer節(jié)點(diǎn)將一個(gè)區(qū)塊寫入賬本前，如上所述會進(jìn)行背書策略的校驗(yàn)，以防止惡意節(jié)點(diǎn)的入侵，達(dá)到有權(quán)重劃分，可實(shí)名制交易的聯(lián)盟鏈。除去驗(yàn)證各節(jié)點(diǎn)簽名驗(yàn)證，當(dāng)然還要比對個(gè)節(jié)點(diǎn)輸出的結(jié)果是否一致，那如何去衡量結(jié)果是否一致呢？這里提出了讀寫集合的概念，一段程序我們化做為IO，如果使用相同Input得出一致的Output，那么我們便可以認(rèn)同在這一特定情況下函數(shù)性質(zhì)是相同的。在這里我們并不關(guān)心Input，只要寫入/修改的數(shù)據(jù)一致便可認(rèn)為達(dá)成了共識，所以Write Set是用于保存最終需要寫入/修改的數(shù)據(jù)集，這個(gè)是用來比對各節(jié)點(diǎn)的結(jié)果集是否一致，而Read Set中存著各節(jié)點(diǎn)執(zhí)行合約中讀取了哪些數(shù)據(jù)，并會把這個(gè)數(shù)據(jù)的當(dāng)前版本記錄在Read Set中，在Peer節(jié)點(diǎn)寫入?yún)^(qū)塊前也會校驗(yàn)Read Set中讀取的數(shù)據(jù)版本是否和當(dāng)前數(shù)據(jù)環(huán)境中的版本一致，以防止交易并發(fā)帶來的錯(cuò)亂。

認(rèn)證體系

剛接觸區(qū)塊鏈的同學(xué)可能會有一個(gè)概念，區(qū)塊鏈應(yīng)該保證公平公正公開，所以形成了“公有鏈”的一個(gè)概念，例如比特幣，全員可參與，對所有人透明。但是區(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銀行的所有交易或許都要上報(bào)給央行，可見此處“公有鏈”是不可取的。那如何去保證公平公正公開呢？首先代碼必須對成員開源，所有服務(wù)可由自身搭建，利益相關(guān)成員共同審核“智能合約”，全員共識的背書策略，相互授權(quán)或由可信第三方認(rèn)證中心授權(quán)。那么最基礎(chǔ)的一道認(rèn)證體系便顯得尤為重要了，我們在來看看Fabric是如何去實(shí)現(xiàn)他的認(rèn)證體系的。

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

PKI(Public Key Infrastructure)

X.509 證書

Membership Service Providers(MSP)

在劃分成員結(jié)構(gòu)的時(shí)候Fabric用MSP來定義一個(gè)成員，在最佳實(shí)例推薦中，一個(gè)企業(yè)或者機(jī)構(gòu)可以是一個(gè)多帶帶的MSP，例如上述說到的供應(yīng)鏈的案例，由例圖來說明，核心企業(yè)便是一個(gè)MSP，銀行和供應(yīng)商各代表一個(gè)MSP，那么在一個(gè)MSP下可以有多個(gè)Peer節(jié)點(diǎn)，而不同的授權(quán)便有不同的功能，MSP具體應(yīng)用場景主要如下。

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

為新節(jié)點(diǎn)或用戶注冊證書時(shí)，需要CA對該操作證書賦予權(quán)限（一般為Admin用戶）。

在背書策略中可通過MSP來代表背書成員，可設(shè)定單個(gè)Peer節(jié)點(diǎn)代表其MSP達(dá)成協(xié)議（也可以要求全部Peer節(jié)點(diǎn)通過才達(dá)成協(xié)議）。

在跨MSP間的Peer節(jié)點(diǎn)通信，先通過各MSP內(nèi)指定的Anchor Peer收集MSP內(nèi)的Peer列表，然后通過各MSP下的Anchor
Peer交互其Peer列表，將其他MSP下的Peer列表同步到內(nèi)部Peer后，便通過Gossip協(xié)議Peer節(jié)點(diǎn)間隨機(jī)通信。

每個(gè)MSP都有自己獨(dú)立的CA節(jié)點(diǎn)，為其提供所有的證書需求，各MSP共享其CA節(jié)點(diǎn)的ROOT證書達(dá)到互相認(rèn)證。

匿名交易。在一筆交易中，包含著每一個(gè)參與背書的用戶證書，這可以認(rèn)為是公開實(shí)名制的交易，所有鏈內(nèi)成員都可以看見每一筆交易是由誰參與的，但是如果我們希望匿名交易該如何實(shí)現(xiàn)呢？在Fabric
0.6版本內(nèi)有Ecert和Tcert的概念，Ecert即為用戶的證書，而Tcert則是用于匿名交易，用戶可以通過向CA申請一批Tcert用于交易，而該Tcert不包含用戶的信息，當(dāng)需要驗(yàn)證查驗(yàn)信息時(shí)可通過CA來認(rèn)證該用戶的身份。（此功能在1.0版本尚未實(shí)現(xiàn)）

Revoke，廢除證書。在PKI體系中，其最大的優(yōu)勢便是Off
line的，即在證書頒發(fā)后，不需要CA節(jié)點(diǎn)的存在也可以在本地進(jìn)行認(rèn)證，而遇到很大的問題是類似于廢除證書時(shí)如果希望能即是將廢除證書的消息通知到各個(gè)節(jié)點(diǎn)，目前的做法是需要CA節(jié)點(diǎn)保持在線并與各節(jié)點(diǎn)保持通信。（獲取Tcert也需要CA節(jié)點(diǎn)在線）

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

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

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

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

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

本文作者：楓爺

閱讀原文