蝸牛講-Fabric入門之管道

好音樂相伴，讓技術不再孤單

原有的數據保密性是通過對交易中的敏感數據進行哈希操作，因此，就需要每個節點維護所有其他節點上的數據來對敏感數據進行安全保障，即使這些數據是我這個節點一點不關心的，特別是有多個聯盟加入的時候。所以在fabric中引入了管道概念。管道的設計目的是為了讓交易方在各自獨立的管道內進行交易，保障交易的秘密性和私有性。一個管道內的交易對其他管道是不可見的，這樣所有在交易中的敏感數據都不需要一個單獨的資料庫來維護。

Fabric管道的原理類似於訂閱者發布者的消息隊列，一個管道就像一個topic，每個授權通過的節點都可以訂閱這個topic，成為這個管道的一個成員，而之後這個管道內的所有交易都會通知到這個節點，但是對於其他沒有訂閱這個管道的節點來說，這些交易是不可見的。

在之前的文章中，我們已經知道一比交易需要經過背書籤名，排序分發以及驗證三個過程。Ordering服務提供了基於消息訂閱發布模式的消息格式。每個節點通過一個或是多個管道與ordering服務通信，通信的方式類似於客戶端的訂閱發布通信系統。經過排序後的交易發布到所有訂閱了這個管道的節點上，保證每個節點接收到的交易是一樣的，順序也一致。這些消息在管道內是以塊的形式傳播。每個節點驗證交易塊並把交易塊提交到賬本，之後提供一些服務給應用，方便這些應用使用賬本。Ordering服務會根據交易的參數，區分出不同管道的消息，並獨立處理，現在的消息還不能跨管道通信。

一個網路中的部分節點可以創建一個管道用於交易，這些節點之間就共享所有發生在這個管道內的所有交易信息，也只有這些節點可以接收這個管道內的交易塊。這些交易塊對於其他管道的節點來說是完全不可見的。一個未授權訂閱這個管道節點無法在這個管道內進行交易。

一個管道上可以有任意多的節點，關鍵是要節點可到達（可以理解為圖論里的「頂點可到達」），也就是要求管道內的所有節點都是「在線」狀態（「離線」為長時間不響應或是取消了訂閱這個管道）。節點在訂閱了一個管道，就維護一個交易賬本，如果一個節點參與訂閱了兩個管道，那這個節點將有兩個交易記錄或是2本賬本，如下圖顯示：

如上圖顯示，節點1，2，N訂閱了紅色管道，這幾個節點之間維護了一份紅色賬本，節點1和N訂閱了藍色管道並維護了一份藍色賬本，注意，節點2由於沒有訂閱藍色管道，所有沒有藍色賬本。同樣的，節點2，N訂閱了黑色管道，所有維護了一份黑色賬本。可以看到節點1，2，N每個節點都維護了不止一份賬本。

看到這裡也許有部分讀者會有困惑，不是說區塊鏈是去中心化，所有節點共享賬本的嗎？其實區塊鏈是講去中心化，但是沒有說一定是完全去中心化，也沒有說我的賬本一定是全局共享的。對於公有鏈來說，它是一個完全去中心化的，並且對於整個公有鏈來說只有一條主鏈，所有的節點都維護一本賬本。但是fabric屬於聯盟鏈，聯盟鏈是部分去中心化，中心化的程度沒有公有鏈這麼高，並且數據是可以根據自己的規則來實現部分節點共享。應用根據自己的業務邏輯來決定一個交易是發送到1個或是多個管道，沒有固定的限制。

有些區塊鏈網路如果所有的交易都是公開的，就根本不需要多個管道，比如以太坊，這樣，所有的交易對所有的節點可見，每個節點有且僅有一份賬本。如果區塊鏈網路中有部分數據具有一定的私有性和保密性，只是針對網路中的部分成員可見的，這種就可以創建一個獨立的管道來專門處理這些數據。當然管道只是實現數據隔離訪問的一種方法，對於只有一份賬本來說，想要實現數據訪問的隔離性也可以用非對稱加密演算法。

注意，ordering服務接收整個區塊鏈網路中的所有管道交易，所以數據的保密性只是針對節點，而不是針對ordering服務。這種設計適合於業務要求數據對ordering服務可見這種情況，也就是說ordering服務對於整個區塊鏈網路是可信的。另一方面，如果有數據需要對ordering服務不可見，就需要使用其他技術來隔離敏感數據，例如加密敏感數據或是再搭建一個ordering服務。

蝸牛講技術，滿滿的都是乾貨，你值得關注。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！