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