Fabric和Sawtooth技術分析（上）

https://mp.weixin.qq.com/s?__biz=MjM5MDAxMTE0MA==&mid=2652049866&idx=1&sn=5b4aea961f3d64c9b240e042b6b434ee&chksm=bdaceba18adb62b7b8d935f122b4f90159640fb5ef88e83e0ba31421812ce7c082584c6df604&scene=21#wechat_redirect

 

背景

Fabric 和 Sawtooth 是 Hypherlegder 的兩個重要企業級項目，在國家鼓勵區塊鏈無幣化的當下，受到了普遍的關注。當咱們但願改造傳統項目，實現多方數據自動化對帳、自動化運維等功能時，它們每每成爲了最佳的選擇。但它們各自有什麼特色，又應該如何選擇呢？本文將分別分析這兩個項目的結構和特色，又對它們進行了比較和總結。

區塊鏈自己和虛擬貨幣（Token）沒有任何關係，比特幣，Ethereum 等引入虛擬貨幣所起的做用是費用計量，並經過費用來控制用戶對資源的使用權限。在傳統互聯網體系結構中，訪問權限的實現方式並非只有經過貨幣一種。因此，區塊鏈的應用價值本質上仍是取決於它能作什麼，或者說它是否能夠做爲一種通用技術普遍服務於商業領域，並提供現有系統沒法實現的功能。

固然，有人看到 Fabric 框架的問題之後，選擇本身改動其中不合理的部分。假如A看到了問題，項目開發者也看到了，隨後B在新版本中進行更改，並且改法與A不一樣，那樣就會有版本更新的風險。因此最合理的方式仍是儘可能不改要動現有項目的核心部分，而是搞清楚以後，再進行合理的選擇。從最後的比較結果看，筆者是強烈推薦 Sawtooth ，由於從通用性，靈活性角度看，幾乎找不到 Sawtooth 的缺點。

本文將分爲上下兩部，本篇將講述 Fabric 的相關內容，下一篇將爲小夥伴們帶來 Sawtooth 的相關內容敬請期待。

1、Hypherlegder Fabric 的分析

Fabric 是 IBM 公司推出的企業級區塊鏈，2017年 IBM 將其貢獻給 Hypherlegder 項目。本文將主要從 Fabric 產生的緣由，Fabric 的特色，和 Fabric 的結構及工做流程作簡要介紹。

Fabric 產生的緣由

Fabric 的誕生主要是由於在金融、銷售、供應鏈等特殊應用領域中，一些機構的數據不能公開，並且並非全部的機構都有權力發起 Transaction。而在 Fabric 誕生以前，主流的區塊鏈結構 Ethereum 的體系結構不能知足數據的隱私與訪問控制需求。正是看到這一機會，IBM 在2017年推出了 Fabric。這以前其實有個插曲，2014年美國幾十家銀行成立了一個 R3 區塊鏈聯盟，目的就是知足金融領域中帶有特殊訪問控制和隱私保護需求的區塊鏈技術，結果2017年，R3 以爲當隱私保護和訪問控制需求變爲主流需求後，區塊鏈並非必須的，因而把本身從「區塊鏈新創公司」改爲了「受區塊鏈啓發的新創公司」。

因此，在分析 Fabric 時也沒必要把「區塊鏈」這種新存儲結構看得和傳統結構有什麼不一樣，由於 Fabric 主要是要彌補在它出現前的技術的不足。從體系結構角度看，Fabric 其實並不新穎。

Fabric 的特色

Fabric 把區塊鏈分爲須要許可的和不須要許可的區塊鏈（Permissioned vs Permissionless Blockchains）。衆所周知參與 Ethereum 的用戶是匿名的，也就是任何人均可以參與，因此 Ethereum 是不須要許可的區塊鏈，向 Ethereum 網絡中提交一個合法的（只要有以太幣即合法） Transaction，全部節點都會獨立執行合約（根據數據）獲得輸出並生成區塊。對 Ethereum 這種不須要許可的區塊鏈來講，因爲程序和數據在全部節點上執行，跟本沒啥保密可言。這對不少應用是不行的，好比，作銷售，供應的，哪裏還有底價一說，你們知道的都同樣。還有用戶位置、等等隱私數據也不能全網暴露。

Fabric 針對不須要許可的（Permissionless）區塊鏈存在的問題提出須要許可的（Permissioned）區塊鏈，簡單來講，就是在全部節點中選擇一部分，造成一個個的聯盟，特定 Transaction 只在聯盟內的節點獨立運行，這樣只有通過選擇的特定節點參與執行 Transaction，數據只在這部分節點範圍內公開，這樣隱私和訪問控制就有可能緩解了（與Ethereum相比，效率提升也是天然的，雖然不是 Fabric的主要目標）。

具體怎麼解呢：配置文件。在不一樣的配置文件裏寫好訪問控制邏輯便可，誰能夠作什麼一目瞭然。這裏 Fabric 假設，進到聯盟中的就沒有壞人了，不會有節點經過有問題智能合約搗亂。爲此，Fabric 提供了一套 CA ，確保聯盟內任何人的身份都是能夠驗證的，其行爲，包括修改網絡設置，部署智能合約等能夠被記錄在區塊鏈上，而且有人爲其背書。這就能夠識別出搗亂的人。

Ethereum 等技術是遵循順序執行的體系結構 （order-execute architecture） 的。須要先驗證全部 Transaction 的執行順序，而後把狀態複製到全部節點上，而後每一個節點各自順序執行。簡單來講就是在架構上就沒考慮過 Transaction 的並行。Fabric 引入了一種稱爲（execute-order-validate）的架構。先執行 Transaction 而後再檢查它的正確性，而後爲其背書；經過可插拔的共識協議給 Transaction排序；在提交給帳本前，用應用程序描述的背書策略（application-specific endorsement policy）驗證 Transaction。這裏所謂「程序描述的背書策略」是指哪些節點，多少節點，須要保證給定智能合約執行的正確性。這種結構容許 Transaction 並行執行，提升了效率，由於非肯定性的（non-determinism）、不一致（inconsistent）的結果能夠在排序（ordering）前被過濾掉，使得 Fabric 能夠支持標準編程語言（standard programming languages），智能合約能夠用 Go 或者 Node.js 來寫，未來也支持 Java。

當咱們面對隱私保護需求的時候，可能有不一樣的解決方法。Fabric 列出了下面幾種：

1) Fabric 認爲，一種是數據加密。但因爲加密數據被部署到每一個節點上，只要給定足夠的時間和計算資源，加密能夠被破解。(這顯然是Fabirc的設計者想固然，但 Fabric 把它做爲 Permissioned 體系結構存在乎義的證據)。

2) Fabric 認爲，另外一種是零知識證實，但零知識證實須要至關可觀的時間和計算資源。

因此，爲了解決數據的訪問控制與隱私保護問題，Fabric提出了一種稱爲 channel 的體系結構，只有參加 channel 的 nodes 有權訪問 smart contract（Fabric 稱爲 chaincode）和數據。(在我印象中，76年現代密碼學的開山之做就是說怎麼幹這事，說是 Fabric 提出的，不太合適，但 Fabric 確實是用這種方法在網絡中隔離出一個個的聯盟)。

Fabric 的網絡結構

下面是一個 Fabric 示例網絡結構圖。圖中的字母：R表明 organizations，圖中共有 R一、R二、R3 和 R4四個組織（organizations）。P表明 Peer node，P1 隸屬於 R1。S 表明 Smart Contract，L 表明 Ledger，圖中 L1，S5 物理部署於 P1 上。C 表明 channel。NC 是n etwork configuration。CC 是 channel configuration。CA 是 Certificate Authority。A 表明 Client application，這裏是用戶操做的界面。O 是 ordering service，或者叫 orderer。

放眼過去，是否是以爲很雜亂？不要急，接下來 Fabric 會告訴咱們怎麼一步步造成這樣的複雜體系結構。先來看圖中的 R4 以及它的網絡配置文件 NC4，以及排序服務O4，和提供身份服務的 CA4。NC4 包含初始網絡管理能力設置的策略。簡單點說，就是 R4 有權配置網絡。CA 的功能比較簡單，基本上衆所周知，就再也不贅述了。

接下來增長一個新的組織 R1 和爲 R1 內用戶提供身份服務的 CA1。此時，能夠由 R4 修改配置文件 NC4，令 R1 具備和 R4 同樣的管理權限。

在聯盟的基礎上，就能夠建立 channel 了。C1 表示 channel ，根據CC1 建立。它是聯盟內部成員之間的主要通訊機制。這裏聯盟內有 R1 和 R2，CC1 由它們控制，R4 不能參與。注意，C1 須要與 O4 相連。這樣的目的是，只要能連上 O4，就能與 C1 鏈接的節點通訊。

接下來，Peer node P1 鏈接到 channel，它能夠經過 C1 與 O4 通訊。注意，L1 物理部署在P1上，從數據存儲角度，能夠把 L1 看作待訪問資源。邏輯上，L1 能夠被全部可以鏈接到 C1 的節點訪問。加入過程是經過 P1 發送一個鏈接 C1 的請求給 O4，而後 O4 根據 CC1 的策略設置決定 P1 能否鏈接 C1。

接下來，智能合約 S5 能夠被安裝到 P1 上，P1 能夠看到 S5 的代碼。R1 中的一個 Client Application A1 能夠加入 C1，並經過 P1 執行 S5 來訪問 L1。這時，因爲 A1 是 R1 的成員，它能夠選擇鏈接O4 或者 R1，經過它們中的哪一個均可以鏈接上 P1。S5 由 R1 實現，並在 P1 上安裝。並且 S5 還要在 C1 上安裝，以便別的 Client Application 能夠找到它。

咱們能夠繼續加入資源P2到C1上：

把上圖中的C1簡化掉，獲得下圖：

而後能夠再增長一個聯盟以下圖：

而後再在新聯盟內創建一個 channel 以下圖：

在新 channel 上鍊接新的資源 P3 以下圖：

此時，P2 既能夠被 C1 內節點訪問，也能夠被 C2 內節點訪問，能夠把 P3 上的資源同步到 P2 上，以下圖：

這樣就獲得了開始看到的網絡結構圖。

經過上述網絡結構能夠看到，Fabric 的訪問控制機制大致上分爲兩層，一層是關於安全的，或者叫成員服務，也就是說畫個圈，把成員划進來。另外一層是關於隱私的，意思是一個 Transaction 能夠指定由全部成員中的一部分來執行，這樣別人就看不到程序和數據了。

Fabric 的通訊流程

咱們先看看Client Application請求資源的流程，以下圖：

首先，經過 orderers ，Peers 確保 Ledger 老是保持最新狀態。以 A調用 S1 來查詢或者更像 L1 爲例，P1 收到合法調用請求後，調用 S1 生成一個應答。A 在收到應答。若是是查詢請求就結束了。若是是更新請求，A 在它收到的全部應答基礎上構造 Transaction 發給 O1 。O1 收集網絡上的 Transactions，而且分發給全部 peers，包括P1 。peers 驗證 Transaction，經過後更新 L1，而後生成一個事件。

接下來，咱們再看看通訊的具體流程：

endorsing peer 主要是給 client 背書的。它的功能是驗證，而後再簽名，有些 endorsing peer 可能不在線，有些可能不理 client。client 在收集到足夠的(達到背書策略要求的)背書 endorsing peer 後，把 transaction 發給 orderer。orderer 再把 transaction 發給具體執行智能合約的 committing peers。這裏 Fabric 說得不夠細緻，orderer 在這樣的通訊流程中是很重要的，如何保證 orderer 在處理這些來自不一樣節點的信息的時序性呢。Fabric 沒說清楚，咱們只能假設它作到了。但這是隱患，在分佈式系統中保持全局時序一致性並不容易。

咱們知道，更新 Transaction 和查詢 Transaction 是不一樣的，更新涉及到寫入操做，須要全部相關節點達成共識後才能執行，一個 peer 是不能更新 Ledger 的。因此，爲了實現共識，Fabric 更新涉及到3個階段。

Phase 1: Proposal：Transaction proposals 被每一個返回背書 proposal 的 peer 獨立執行。

A1生成 Transaction T1 帶 proposal P，而後發給 channel C 上的 P1 和 P2 。P1 執行 S1 使用 T1 帶 P，以 R1 帶 E1 相應。P2 執行 S1 使用 T1 帶 P，以 R2 帶 E2 相應。A1 收到這兩個響應。

Phase 2: Packaging：orderer 的第一個角色是給 proposed ledger updates 打包。

A1 發送由 E1 和 E2 背書的 Transaction T1 給O1。並行的 A2 發送由 E1 背書的 Transaction T2 給 O1。O1 把來自 A1 的 T1 和來自 A2 的 T2，以及其它可能得 Transactions 打包 到 Block B2 中。咱們能夠看到 transaction order 是T一、T二、T三、T四、T六、T5。

Phase 3: Validation：orderer 的第二個角色是把 Block 分發給 peers。

O1 把 block B2 發給 peer P1 和 P2 。P1 處理 B2，添加一個新的 block 到 P1 的 L1 上。並行地，P2 也處理 B2 ，添加一個新的 block 到 P2 的 L1 上。一旦這一過程完成，L1 就在 P1 和 P2 上被一致更新了。而後它們分別通知本身鏈接的 applications ，Transaction就被處理了。

帳本示例：fabcar

fabcar 是一個 Fabric 的例子應用，執行它會建立以下 Ledger 。該例子建立一個 car 的集合，有不一樣的顏色、製造商、牌子、全部者。

帳本 L 包括一個 world state W 和一個區塊鏈 B 。W 包含4個狀態，key 是 CAR一、CAR二、CAR3 和 CAR4。B包含兩個blocks：0 和 1。Block 1 包含4個 Transactions T一、T二、T三、T4。

總結

看完 Fabric 結構流程等介紹，筆者的第一個感受是 Fabric 對標的是 Ethereum ，它全部的技術、結構等的設計都是爲了解決 Ethereum 中的問題，能夠看到它確實作到了。

因此，給人一種直觀的感受是 Fabric 不像是一個通用企業級架構，而是一個企業級的解決方案。Fabric 定義的 Transactions 有兩類，一種叫 Deploy transactions，是用來部署 chaincode 的。另外一種叫 Invoke transactions，是用來執行已經部署的 chaincode 的。從這裏的 Deploy transactions 設計能夠看出，Fabric 已經有把 Transaction 自己做爲 on-chain 的設計思想了，但整體上卻又大量依賴配置文件，並未充分利用區塊鏈自己實現對區塊鏈的配置。

所以讓人感受雖然 Fabric 能夠實現預設的功能，但若是想稍做改動（實際狀況中的常態），配置文件的管理可能隱藏不少潛在問題。Fabric 中的 Ordering service 是一個關鍵。它爲 clients 和 peers 提供了共享的通訊 channel，爲包含 Transaction 的消息提供廣播服務。Client 鏈接 channel ，能夠廣播消息到全部 peers 。換句話說，channel以相同的邏輯順序將一樣的消息發送給全部與其相連的 peers 。

簡單來講它的功能就是按照當前配置文件中設定的網絡結構，或者說控制結構規則將收到的消息或者交易轉發給相應的節點。order 很是像如今網絡中的路由器，或者說入口網關。Fabric 的並行化更像是傳統電腦中的進程級的並行，針對的改進對象是單用戶沒有並行功能的系統。