Blockchain区块链架构设计之四：Fabric多通道和下一代账本设计
Hyperledger Fabric架構(gòu)使用具有保證的發(fā)布-訂閱模式消息傳遞通道（如Kafka中的主題分區(qū)）將共識(shí)服務(wù)與交易日志（賬本）分離。 共識(shí)服務(wù)由稱為Orderers的網(wǎng)絡(luò)節(jié)點(diǎn)提供，并且賬本由Peer節(jié)點(diǎn)管理。
每個(gè)Peer節(jié)點(diǎn)連接到共識(shí)服務(wù)的一個(gè)或多個(gè)通道，就像發(fā)布-訂閱通信系統(tǒng)中的客戶端一樣。 在通道上廣播的交易按共識(shí)的順序排列（例如PBFT、kafka），訂閱通道的Peer節(jié)點(diǎn)接收到加密的區(qū)塊。 每個(gè)peer節(jié)點(diǎn)驗(yàn)證區(qū)塊并將其提交到賬本，然后向應(yīng)用程序提供其他使用賬本的服務(wù)。
?
一、定義和術(shù)語(yǔ)
?
?
●Orderers:提供共識(shí)服務(wù)的網(wǎng)絡(luò)節(jié)點(diǎn)，例如，使用Kafka或PBFT。
●Peers:維護(hù)賬本的網(wǎng)絡(luò)節(jié)點(diǎn)，通常在Hyperledger Fabric架構(gòu)中存在各種角色，如endorser和committer。
●通道：Order 服務(wù)提供Peer節(jié)點(diǎn)供訂閱的主題（如發(fā)布-訂閱消息隊(duì)列），每個(gè)主題是一個(gè)通道。 peer可以在訂閱多個(gè)通道，并且只能訪問訂閱通道上的交易。
●賬本：賬本保存Orders提交經(jīng)節(jié)點(diǎn)確認(rèn)的交易記錄。
●成員：訪問和使用賬本的網(wǎng)絡(luò)節(jié)點(diǎn)。
●鏈：基本上，一個(gè)鏈由1個(gè)通道+ 1個(gè)賬本+ N個(gè)成員組成。非鏈的成員無法訪問該鏈上的交易。鏈的成員可以由應(yīng)用程序動(dòng)態(tài)指定。
?
二、數(shù)據(jù)隔離和保密
?
?
在共識(shí)服務(wù)上支持多通道消息傳遞，使得Peer節(jié)點(diǎn)可以基于應(yīng)用訪問控制策略來訂閱任意數(shù)量的通道; 也就是說，應(yīng)用程序指定Peer節(jié)點(diǎn)的子集中架設(shè)通道。 這些peer組成提交到該通道交易的相關(guān)者集合，而且只有這些peer可以接收包含相關(guān)交易的區(qū)塊，與其他交易完全隔離。
此外，peers的子集將這些私有塊提交到不同的賬本上，允許它們保護(hù)這些私有交易，與其他peers子集的賬本隔離開來。應(yīng)用程序根據(jù)業(yè)務(wù)邏輯決定將交易發(fā)送到1個(gè)或多個(gè)通道。 這不是內(nèi)置的限制，區(qū)塊鏈網(wǎng)絡(luò)不知道并假設(shè)不同通道上的交易之間沒有關(guān)系。
例如，如上圖所示，peer 1,2和N訂閱紅色通道，并共同維護(hù)紅色賬本; peer 1和N訂閱藍(lán)色通道并維護(hù)藍(lán)色賬本; 類似地，peer 2和peer N在黑色通道上并維護(hù)黑色賬本。
在這個(gè)例子中，peer N在訂閱了所有通道，我們看到每個(gè)通道都有一個(gè)相關(guān)的賬本。 一般來說，我們稱不涉及所有peer的賬本為子賬本，另一種是系統(tǒng)賬本，即全賬本。
通道和賬本的組合是一個(gè)虛擬鏈，因此一個(gè)區(qū)塊鏈網(wǎng)絡(luò)可以具有1個(gè)共識(shí)服務(wù)的多個(gè)鏈。 系統(tǒng)通道和全賬本構(gòu)成系統(tǒng)鏈。 每個(gè)區(qū)塊鏈網(wǎng)絡(luò)只有1個(gè)系統(tǒng)鏈。如果交易是公開的，區(qū)塊鏈網(wǎng)絡(luò)可能永遠(yuǎn)不需要多個(gè)鏈; 所有的交易對(duì)所有Peers成員都可見。 然而，在成員間進(jìn)行私密交易（例如雙邊合同），單獨(dú)的鏈?zhǔn)歉綦x數(shù)據(jù)、提供保密的方式。
注意：共識(shí)服務(wù)接收所有鏈的所有交易，因此保密性僅與peer而不是Orderers相關(guān)。 當(dāng)共識(shí)服務(wù)由被許可網(wǎng)絡(luò)中的可信方和監(jiān)管機(jī)構(gòu)組成時(shí)，這樣是合理的，也就是說，這些交易作為業(yè)務(wù)需求僅對(duì)他們可見。 另一方面，如果應(yīng)用程序不希望Orderers知道交易的內(nèi)容，它必須利用其他技術(shù)來隱藏敏感數(shù)據(jù)，例如哈希散列或加密。共識(shí)服務(wù)作為一個(gè)信任方存在，如果是由拜占庭容錯(cuò)（BFT）共識(shí)協(xié)議實(shí)現(xiàn)（例如PBFT），可以防止不可信的Orderers破壞賬本的一致性和阻礙系統(tǒng)可用性。然而，現(xiàn)在還沒有一種協(xié)議可以在有不可信的Orderers存在的情況下，提供多通道設(shè)計(jì)的同時(shí)提供數(shù)據(jù)保密性。
?
三、實(shí)現(xiàn)
?
?
當(dāng)前的Fabric共識(shí)服務(wù)實(shí)現(xiàn)中，通道是隱含的; 當(dāng)peer連接至區(qū)塊鏈網(wǎng)絡(luò)時(shí)，不會(huì)指定一個(gè)通道。 所以為了支持多渠道，Orderer和peer都需要改變。 Orderer必須提供多通道訂閱，peer需要知道可以訂閱哪些頻道。 以下部分描述了技術(shù)細(xì)節(jié)。
1） 引導(dǎo)
共識(shí)服務(wù)由1個(gè)或多個(gè)Orderers組成。 每個(gè)Orderer配置有匹配的創(chuàng)世區(qū)塊，其由引導(dǎo)CLI命令生成，其提供了一些必要的數(shù)據(jù)，包括一系列可信根節(jié)點(diǎn)的列表，Order證書和IP地址的列表，一組特定的共識(shí)算法配置以及訪問控制策略（誰(shuí)可以創(chuàng)建信道）。
要啟動(dòng)并連接到共識(shí)服務(wù)，peer至少需要以下配置：
1.準(zhǔn)入網(wǎng)絡(luò)的注冊(cè)證書。 證書可以來自任意CA，只要CA是peer將連接到的共識(shí)服務(wù)的可信任根的一部分
2.來自共識(shí)服務(wù)管理CLI生成的Orderer證書和IP地址的列表
3.可信任根節(jié)點(diǎn)列表
4.peer可以訂閱的通道可選列表。 除非明確配置，否則peer在啟動(dòng)時(shí)不訂閱任何通道
注意，＃2和＃3來自引導(dǎo)的創(chuàng)世區(qū)塊，我們可以從引導(dǎo)CLI命令獲得。
通過CLI或使用SDK API的應(yīng)用程序，peer可以訂閱已經(jīng)存在的通道。 order通過在通道創(chuàng)建或重新配置期間收到的消息決定誰(shuí)可以加入通道。
2） 創(chuàng)建通道
可以通過發(fā)送通道配置事務(wù)和參與成員證書列表到共識(shí)服務(wù)來創(chuàng)建通道。
應(yīng)用程序決定哪些成員創(chuàng)建通道。成員證書在Peers之間是公開的，且能被查詢到。通道中成員間的共識(shí)的達(dá)成，為了避免在Orderer處理過程中不必要的麻煩，不需要使用Chaincode類型的交易背書，直接使用通道配置事務(wù)就行了。
我們將介紹一個(gè)新的系統(tǒng)chaincode，叫做配置系統(tǒng)chaincode（CSCC），主要負(fù)責(zé)處理所有的配置相關(guān)的事務(wù)。CSCC提供方法查詢眾多的配置數(shù)據(jù)，包括通道配置。
例如，假設(shè)peer A和B屬于2個(gè)不同成員Alice和Bob。 請(qǐng)注意，Alice和Bob可能在網(wǎng)絡(luò)上有多個(gè)Peer，并且他們的任何Peer都可以加入通道。 以下是一個(gè)典型的序列：
1.應(yīng)用程序/ SDK獲得A和B的背書用于創(chuàng)建通道“foo”的配置交易。
2.應(yīng)用程序/ SDK調(diào)用Broadcast RPC，將背書過的配置交易傳遞給order服務(wù)。
3.應(yīng)用程序/ SDK然后調(diào)用在通道foo上deliver RPC。此RPC將返回一個(gè)錯(cuò)誤，直到order服務(wù)成功創(chuàng)建通道。
4.當(dāng)通道最終被創(chuàng)建后，Deliver RPC將返回通道的信息到應(yīng)用程序/ SDK。在這一時(shí)點(diǎn)，通道foo應(yīng)當(dāng)僅具有包含相關(guān)訂閱者的創(chuàng)世區(qū)塊，并且與該配置交易一起被（或最近的重新配置交易）引導(dǎo)。
5.應(yīng)用程序/ SDK在A和B上調(diào)用JoinChannel API，將通道foo的創(chuàng)世區(qū)塊傳遞給A和B，添加CSCC到通道上。
6.A和B上的CSCC檢查創(chuàng)世區(qū)塊，包括檢查區(qū)塊中的配置交易的背書。如果一切正確，他們調(diào)用在通道上的Deliver RPC來開始接收塊。
如果通道已經(jīng)存在，則參與者列表將被替換。 Orderers自動(dòng)替換訂閱者并且將該交易與該通道上的其他交易一起發(fā)送給新成員，新成員將會(huì)同步完整的塊。
3） 關(guān)閉通道
應(yīng)用程序可以通過發(fā)送類似于創(chuàng)建通道的配置交易來關(guān)閉其創(chuàng)建的通道。 它需要根據(jù)應(yīng)用程序設(shè)置的策略從通道參與方得到背書。 peer不會(huì)自動(dòng)銷毀相關(guān)的賬本，但是裁剪進(jìn)程會(huì)在適當(dāng)?shù)臅r(shí)候處理。
應(yīng)用程序可以繼續(xù)從已關(guān)閉的賬本中讀取數(shù)據(jù)，只要該賬本尚未被刪除，但由于通道已被銷毀，因此不能執(zhí)行交易了。
4） 查詢通道
通道只能被該通道的成員查詢。也就是說，交易發(fā)起方的簽名能夠被存儲(chǔ)在賬本配置區(qū)塊中的CA證書驗(yàn)證通過。這是通過發(fā)起一個(gè)查詢交易到CSCC，同時(shí)附上鏈的ID，返回的結(jié)果是一個(gè)配置區(qū)塊，里面包含了成員證書和一些其他的配置信息。
5） 鏈上的交易
一個(gè)交易必須包含目標(biāo)的鏈ID（鏈ID =通道ID =賬本ID）。 共識(shí)服務(wù)將把交易放置在由鏈ID標(biāo)識(shí)的指定通道上，并且在該通道內(nèi)被排序，而與其它通道上的交易無關(guān)。 最終在該通道上產(chǎn)生一個(gè)包含交易的區(qū)塊并發(fā)送到訂閱了該通道的那些peer。
注意，每個(gè)鏈都是獨(dú)立和并行的，因此一個(gè)peer可以同時(shí)接收和處理不同鏈上的區(qū)塊。
chaincode事務(wù)只能操作指定鏈中的狀態(tài)變量（類似于對(duì)對(duì)象的實(shí)例變量操作的函數(shù)）。
6） 鏈上的Chaincode
chaincode被部署到鏈上并只能在這個(gè)鏈上被調(diào)用。 有些應(yīng)用場(chǎng)景，我們要從另一個(gè)鏈調(diào)用數(shù)據(jù)，修改自己的鏈或其他鏈的狀態(tài)值。當(dāng)我們需要一個(gè)chaincode只部署一次但是可以在任何鏈上可以被調(diào)用的時(shí)候，跨鏈調(diào)用就變得特別有用。
例如，假設(shè)系統(tǒng)賬本具有記錄輸入事件的Weather chaincode，ABC是新創(chuàng)建的賬本。 我們可能想從ABC調(diào)用Weather，從系統(tǒng)鏈查詢返回值，因此發(fā)送事務(wù)[ABC，Weather.worldMap（）]將返回系統(tǒng)鏈上的當(dāng)前天氣圖。 但我們可能還希望Weather chaincode操作局部變量，因此發(fā)送[ABC，Weather.temperature（）]將返回ABC鏈上的當(dāng)前溫度，而不是系統(tǒng)鏈上的當(dāng)前溫度。該示例的需求是特殊的，但它說明我們需要從一個(gè)交易或從另一個(gè)chaincode調(diào)用不同鏈之間的chaincode的能力，這對(duì)于系統(tǒng)鏈上的那些chaincode特別有用，我們只需要部署一次并可以從任意私有鏈調(diào)用它們。
我們需要一個(gè)可編程模型來表達(dá)被調(diào)用chaincode的操作。 一個(gè)可選的方案是包括一個(gè)上下文，它封裝了chaincode將運(yùn)行的賬本（數(shù)據(jù)對(duì)象）。 然而，chaincode可能在每個(gè)部署的賬本上具有一些初始化參數(shù)（init函數(shù)），所以我們需要能夠在每個(gè)新的賬本上初始化chaincode，我們希望chaincode可以在本地執(zhí)行。
在這一點(diǎn)上，我們應(yīng)該設(shè)定一些約定以使得編程模型清晰：
1.從交易調(diào)用chaincode總是在交易被發(fā)送的鏈上進(jìn)行操作
2.只有系統(tǒng)鏈上的chaincode可以被私有鏈上的其他chaincode調(diào)用并且是只讀的
?
四、API
?
?
如上面實(shí)現(xiàn)部分所述，我們將在peer上增加一個(gè)新的gRPC API和一個(gè)新的頂層交易類型。API允許App / SDK通知peer已成功加入的通道。 加入通道API的輸入是由新創(chuàng)建的通道上的共識(shí)服務(wù)返回的創(chuàng)世區(qū)塊，peer使用此區(qū)塊設(shè)置與通道關(guān)聯(lián)的賬本。
新的交易類型稱為配置交易，這種類型的交易可以由Orderer和peer處理。 創(chuàng)建或重新配置通道的交易都屬于配置交易，其中背書請(qǐng)求是讓peer批準(zhǔn)和不批準(zhǔn)它們創(chuàng)建或重新配置通道。 peer可以通過提案請(qǐng)求返回接受或拒絕。 為了保持靈活性，我們將提供一個(gè)系統(tǒng)chaincode來處理通道創(chuàng)建的背書請(qǐng)求，它將自動(dòng)響應(yīng)簽名請(qǐng)求。 chaincode還提供查詢此通道上參與成員列表的功能。
配置交易具有ConfigurationEnvelope類型的payload，其嵌入序列號(hào)，鏈ID和簽名配置條目的列表。配置交易包含整個(gè)鏈的配置，并且單個(gè)配置總是獨(dú)立存在。這種簡(jiǎn)單的編碼將允許在將來很容易進(jìn)行裁剪和簡(jiǎn)化配置交易的開銷。新配置交易必須包含所有先前的配置條目，并且所有新/修改的配置條目必須用其包含配置包絡(luò)的序列號(hào)和鏈ID標(biāo)記。每個(gè)配置條目都具有枚舉類型，唯一（按類型劃分）ID以及由名稱引用的修改策略。Order服務(wù)將根據(jù)現(xiàn)有配置策略驗(yàn)證配置交易，如果不滿足全部修改策略，則拒絕它。
SDK可以向API提供進(jìn)一步的抽象。 例如，它可以提供1個(gè)API，創(chuàng)建通道（成員證書列表），它將執(zhí)行在創(chuàng)建通道部分中討論的所有6個(gè)步驟。 最后，SDK將調(diào)用應(yīng)用程序上的回調(diào)，返回創(chuàng)建通道的狀態(tài)。
原文鏈接：https://www.8btc.com/article/117576
總結(jié)
以上是生活随笔為你收集整理的Blockchain区块链架构设计之四：Fabric多通道和下一代账本设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Fabric架构演变之路
- 下一篇： scp时候出现ssh Connectio