FastFabric:提高Hyperledger Fabric性能到20000TPS

原文地址：www.xuanzhangjiong.top/2019/09/21/…

Hyperledger Fabric：一種分佈式操做系統-基於准入控制的區塊鏈

摘要

Hyperledger Fabric 是一種模塊化的，可擴展的開源的用於部署和操做權限的區塊鏈系統。Fabric目前被用於超過400多種原型以及概念證實階段的分佈式帳本技術的場景中，如不少生產系統，跨越了不一樣行業和使用場景。

基於「one-sizefits-all」解決方案的前提出發，Fabric是第一個運用於分佈式應用程序的真正可擴展的區塊鏈系統。它支持模塊化的共識協議，容許系統根據特定用例和信任模型進行定製。Fabric也是第一個用通用編程語言開發智能合約，不依賴本機加密貨幣的運行分佈式應用的區塊鏈系統。這與現有須要使用特定編程語言或者依賴加密貨幣才能開發智能合約的區塊鏈平臺造成了鮮明的對比。此外，它使用一個與行業標準身份管理相結合的易於理解的成員服務來實現許可模型。爲了支持這種靈活性，Fabric採用了一種新穎的方法來設計帶有權限控制的區塊鏈系統和改進方式以應對非肯定性，資源耗盡以及性能攻擊。

本文描述了Fabric，它的架構，各類設計決策背後的基本原理，安全模型和保證，它最突出的實現方面，以及分佈式應用程序編程模型。咱們經過實現和測試基於比特幣的數字貨幣進一步評估Fabric。咱們展現了Fabric在某些流行的部署配置中實現了每秒超過3500TPS的吞吐量，具備亞秒級的延遲。

1.介紹

區塊鏈能夠定義爲在分佈式網絡中維護在相互不信任的節點間的用於記錄交易的不可變的分類帳本。每一個節點持有一份帳本的拷貝。節點執行共識協議來驗證交易，將它們打包進區塊，在區塊上創建hash鏈。這個過程由對交易進行排序造成，這是一致性所必須的一步。區塊鏈技術中出現了比特幣bitcoin.org/被普遍認爲是一項有前途的在數字世界中運行可信賴的交換的技術。在公共或者無權限的區塊鏈中，任何人均可以在沒有特定身份的狀況下參與。公共區塊鏈一般涉及原生的加密貨幣，而且使用「工做量證實」（POW）和經濟激勵的共識。另外一方面，帶有準入機制的區塊鏈運行在一組已知的已肯定的參與者中。帶有準入機制的區塊鏈提供了一種在一組有共同目標可是互不信任對方的羣體間進行交換的一種方法，例如企業間交換資金，貨物或者信息。依靠節點的身份，帶有準入機制的區塊鏈可使用傳統拜占庭（BFT）協議進行共識。區塊鏈能夠以智能合約的形式執行任意的可編程交易邏輯，例如以太坊 ethereum.org/。比特幣中的腳本是該概念的前身。智能合約充當受信任的分佈式應用程序，並從區塊鏈和基本的共識中獲取安全性。這很是相似於使用狀態及構建彈性應用程序的衆所周知的方法複製狀態機（SMR）[31]。然而，區塊鏈離開了傳統的複製狀態機很重要的緣由是：（1）同時不只僅只運行一個，而是多個應用程序；（2）應用程序能夠被任何人動態部署；（3）這些應用代碼多是不可信的，甚至是惡意的。這些差別致使須要一個新的設計。

許多現有的有智能合約的區塊鏈遵循狀態複製機[31]以及實現了所謂的主動複製[13]：一種共識協議或者原子廣播，首先排序交易而後將它們傳播給peer節點；第二，每一個節點按順序執行交易。咱們將這個模式稱做排序-執行架構；它要求全部的節點執行每一個交易同時全部交易都是肯定的。在現有的區塊鏈系統中，從公有鏈，如以太坊（基於POW的共識），聯盟鏈，如Tendermint tendermint.com/，Chain chain.com/和Quorum www.jpmorgan.com/global/Quor…中都是基於排序執行架構的。排序-執行架構設計不是全部系統都能馬上顯現出來的，由於額外的交易驗證步驟可能會模糊它，排序-執行的限制在於：全部節點都須要執行交易，全部交易必須是肯定的。

事先得到許可的區塊鏈受到不少限制，這些限制一般來源於他們沒有權限的親屬或者使用排序-執行的架構。特別是：

• 共識在平臺內是硬編碼的，這與已有的理解相矛盾，沒有「一刀切」的（BFT）共識協議；
• 交易驗證的信任模型由共識協議決定，不能適應智能合約的要求；
• 智能合約必須用固定的，非標準的，或者特定領域的語言來開發，這阻礙了智能合約普遍傳播採用並可能致使程序錯誤；
• 全部節點須要按順序執行全部的交易，須要複雜的措施來防止不受信任的合約針對平臺的拒絕服務攻擊（如以太坊中在運行時計算的「gas」）；
• 交易必須是肯定的這一點，很難以編程方式來保證；
• 每一個智能合約運行在全部節點上，這和保密性以及禁止將合約代碼和狀態傳播給其餘節點相違背。

在本文中，咱們描述了Hyperledger Fabric或者簡稱Fabric，一個開源的克服了這些限制的區塊鏈平臺github.com/hyperledger… 。Fabric是一個Linux基金會linuxfoundation.org支持下的Hyperledger www.hyperledger.org的項目之一。Fabric被用於超過400多種原型，概念證實，在生產環境下的分佈式帳本系統，跨越了不一樣行業和用例。這些用例包括可是不限於解決爭議等領域，貿易物流，外匯淨額，食品安全，合同管理，鑽石出處，獎勵積分管理，低流動性證券交易和結算，身份管理，以及經過數字貨幣結算。

Fabric引入了一種新的具備彈性，靈活性，可擴展性和機密性的區塊鏈架構。Fabric是一種模塊化的可擴展的通用的帶有準入權限的區塊鏈，支持執行用標準編程語言編寫的分佈式應用程序。這使得Fabric成爲第一個用於帶有準入權限的區塊鏈的分佈式系統。

Fabric的體系架構遵循一種新的執行-排序-校驗，用於不可信的分佈式環境下執行不可信的代碼的範式。它將交易氛圍3個步驟，運行於系統的不一樣實體上：

1. 執行交易而且驗證它的正確性，從而對其背書（對應於其餘區塊鏈系統中的「交易驗證」）；
2. 經過共識協議進行排序，不考慮交易的語義；
3. 針對特定於應用程序的信任假設進行交易驗證，這能夠防止併發性致使的競爭條件。

這種設計與排序-執行的方式徹底不一樣，Fabric在順序達成一致以前先執行了交易。這結合了兩種衆所周知的複製方法，被動和主動，以下。

首先，Fabric使用了被動或者主備複製[6,13]，這種方式常常在分佈式數據庫中被使用，但它是基於中間件的非對稱更新處理[24,25]，而且被移植到了拜占庭錯誤的非信任環境下。在Fabric中，每一個交易僅僅被一小部分節點執行，容許並行執行，解決潛在的不肯定性問題，借鑑「執行驗證」BFT複製[21]。靈活的背書策略能夠指定須要哪些節點以及多少節點爲正確執行正確的智能合約進行擔保。

其次，Fabric包括了主動複製，其中交易對帳本狀態的影響只有在全部交易通過共識排序以後才被更新，在肯定性校驗階段分別在各自節點獨立執行。這容許Fabric根據交易的背書策略來承認特定應用程序的信任假設。此外，狀態更新的排序被委託給一個共識模塊（即，原子廣播）是無狀態的，而且在邏輯上與執行交易和維護帳本的節點分離。因爲共識是模塊化的，所以能夠根據特定部署的信任假設來定製其實現。雖然能夠何容易實現使用peer節點來進行共識，可是分離兩個角色增長了靈活性，讓人們能夠依靠完善的CFT（故障容錯）或者BFT（拜占庭容錯）排序的工具包。

整體而言，這種混合複製設計混合了拜占庭模型中的被動和主動複製，以及執行順序驗證範例，表明了Fabric架構的主要創新。他們解決了以前提到的問題，並使Fabric成爲了支持靈活信任假設的帶有準入權限的可擴展的區塊鏈系統。爲了實現這個架構，Fabric包含了如下每一個組件的模塊化構建：

排序服務：一個排序服務自動廣播狀態更新到Peer節點上，創建對交易的共識。由Apache Kafka/ZooKeeper (kafka.apache.org/) 和 BFT-SMaRt [3]實現。

身份和成員服務：成員服務提供者負責將節點和加密身份關聯起來。它保持了Fabric的基於權限的特性。

可伸縮的傳播：一個可選的點對點的Gossip服務用於廣播排序服務產生的區塊到全部節點。

智能合約執行：在Fabric中，智能合約運行在一個隔離的容器環境中。它們能夠由標準的編程語言開發，可是不能直接訪問帳本狀態。

維護帳本：每一個節點都維護一個本地僅能追加的區塊鏈帳本，而且維護一個最新狀態的快照在key-value存儲中（KVS）。KVS可使用標準庫實現，例如LevelDB或者Apache CouchDB。

本文剩餘部分描述了Fabric的架構以及咱們使用它的經驗。第2節總結了當前的發展情況，並解釋了各類設計決策背後的基本原理。第3節詳細介紹了Fabric的體系結構和執行-排序-校驗方法，說明了交易執行流程。在第4節中，定義了Fabric的關鍵組件，特別是，排序服務，成員服務，點對點的消息廣播，帳本，智能合約API。基於公有云虛擬機環境下的Fabric參考比特幣加密貨幣的性能評估中的結果和看法在第5節中給出。他們代表，Fabric在流行的部署配置中實現了超過3500tps的吞吐量，實現了延遲時間爲幾百毫秒的結果[36]。最後，在第6章中討論了相關的工做。

2.背景

2.1 區塊鏈的排序-執行架構

在之前的區塊鏈系統中，無論帶不帶有權限，都遵循排序執行架構。這意味着區塊鏈網絡先對交易進行排序，使用共識協議對交易進行排序，而後按照相同的順序在全部節點執行它們。

在複製服務中的排序執行架構

舉個例子，基於PoW的無權限的區塊鏈例如以太坊組合了共識和執行，以下：

1. 每一個節點（即，一個節點參與了共識）假設一個區塊包含了合法的交易（來驗證，這個節點已經預執行了這些交易）；
2. 這個節點嘗試解決PoW謎題[28]；
3. 若是這個節點比較幸運解決了這個謎題，它將經過gossip協議向整個網絡公佈這個區塊。
4. 每一個節點受到區塊後會校驗這個謎題的解法是否正確以及區塊中全部的交易。 有效地，每一個節點所以從第一步開始，重複執行幸運節點所作的。此外，全部節點都按順序執行交易（一個區塊接一個區塊）。排序-執行架構如圖一所示。

目前現存的帶有權限控制的區塊鏈，例如Tendermint，Chain，Quorum一般使用BFT共識算法[9]，由PBFT[11]提供，或者由其餘原子廣播協議提供。不過，他們都遵循排序執行的架構，實現經典的複製狀態機[13,31]。

2.2 排序執行的限制

排序執行架構在概念上很簡單，所以被普遍使用。然而，當用於聯盟鏈時，它有幾個缺點。接下來咱們討論三個最重要的問題。

順序執行。在全部節點上執行交易限制了區塊鏈的吞吐量。特別是，吞吐量和交易延遲成反比，這可能成爲除了簡單智能合約之外全部智能合約的性能瓶頸。此外，與傳統狀態複製機相比，區塊鏈平臺造成了一個通用計算平臺，其上的有效負載應用程序可能由對手部署。拒絕服務攻擊將嚴重下降區塊鏈的性能，能夠簡單的引入一個執行時間很長的智能合約。例如，執行一個死循環的智能合約將會產生致命的影響，可是不能自動檢測，由於停機問題是沒法解決的。

在不少區塊鏈中應用程序被硬編碼，例如比特幣，交易執行叫作「transaction validation.」這裏咱們把這一步交易執行，來協調術語。

爲了解決這個問題，公鏈使用帶有加密貨幣帳戶來計算執行成本。例如，以太坊在交易執行的時候引入了gas的概念，gas的價格轉換爲加密貨幣的成本，由交易提交者支付。以太坊用了很長時間來實現這個概念，爲每一步底層計算分配一個開銷，引入本身的VM監視器來控制執行。雖然對公有鏈來講，這彷佛是一個可行的解決方案，可是對聯盟鏈來講這是不夠的，由於沒有本地加密貨幣的支持。

分佈式系統文獻提出了許多方法與順序執行相比，提升性能的辦法。例如，經過執行不相關的操做[30]。不幸的是，這樣的技術仍然成功地應用於智能合約的區塊鏈上下文中。例如，一個挑戰是須要肯定智能合約中的全部依賴關係，這是特別有挑戰的。並且，這些技術對智能合約抵禦不信任的開發者的DoS攻擊是無效的。

不肯定的代碼。另外一個關於這種併發地排序執行架構的問題是不肯定性地交易問題。在共識完以後在狀態複製機中執行操做，須要保證肯定性，帳本的複製，全部節點狀態的一致性，可是這個方式違背了區塊鏈最初的設計。這一般經過領域特定語言來解決（例如，以太坊），對於應用來講足夠用於表達，可是僅限於肯定性執行。然而，這種語言實現較爲困難，並且要求開發人員學習額外的知識。採用通用編程語言開發智能合約（例如Go、Java、C/C++）反而顯得更有吸引力，加快了區塊鏈解決方案被接受的程度。

不幸地是，通用開發語言帶來了許多肯定性執行的問題。即便應用程序開發人員不明顯地進行不肯定性地操做，那些被隱藏的細節一樣具備破壞性（例如Go語言中的map迭代器）。更糟糕的是，區塊鏈負擔創造肯定性應用程序以來潛在的不可信的程序員。只要一個非肯定性的帶有惡意意圖的合約足以讓區塊鏈中止。過濾發散的模塊解決方案也研究過[8]，但在實踐中代價高昂。

執行的保密性。根據公有鏈中的藍圖，許多徐鶴的系統將智能合約運行在全部節點上。可是，許多聯盟鏈中指望的案例須要保密，例如智能合約邏輯、交易數據、可分類的帳本。雖然從數據加密到零知識證實[2]到可驗證計算[26]，能夠幫助實現保密性，可是一般會帶來至關大的開銷，在實踐中不可行。

幸運的是，將相同的狀態傳播給全部人就足夠了，而不是處處運行相同的代碼。所以，智能合約的執行能夠限制在對這個任務可信的子集中執行，這樣就證實告終果的可靠。這種設計將主動複製往被動複製[6]偏移，適應了區塊鏈的信任模型。

2.3 現有架構的進一步限制

固定的信任模型。大多數聯盟鏈依賴異步的拜占庭容錯算法去創建共識[36]。這類協議一般依賴一個安全的假設，即n>3f節點，最多能夠容忍f個節點做惡，所謂的拜占庭錯誤[4]。在相同的安全假設下，相同的節點也常常執行應用邏輯（即便實際上能夠限制BFT在較少的節點執行）。然而這樣的量化信任假設，不管節點在系統中是什麼角色，可能與智能合約所需的信任不匹配。在一個靈活的系統中，應該信任應用程序級別而不是固定在協議級別的信任。通用區塊鏈應該結偶這兩個假設並容許靈活的應用程序信任模型。

硬編碼的共識。Fabric是第一個引入可插拔共識的區塊鏈系統。在Fabric以前，幾乎全部區塊鏈系統都採用了硬編碼的共識協議。然而，幾十年來對共識協議的研究代表，沒有這樣的「一刀切」的解決方案。例如，BFT協議在潛在的敵對環境[33]下性能差別很大。在具備對稱和同構鏈路[18]的LAN集羣上，具備「鏈」通訊模式的協議表現出了可證實的最優吞吐量，但在廣域異構網絡上性能不好。此外，諸如負載，網絡參數和實際故障或攻擊之類的外部條件可能在給定部署中隨時間變化。出於這些緣由，BFT共識應該具備內在的可重構性，而且理想地適應不斷變化的環境[1]。另外一個重要方面是將協議的信任假設與給定的區塊鏈部署場景匹配。實際上，人們可能但願使用基於可選信任模型(如XFT[27])的協議來替代BFT協商一致，或者使用CFT協議(如Paxos/Raft[29]和ZooKeeper[20])，甚至使用無許可協議。

2.4 排序執行的區塊鏈的經驗

在瞭解執行排序校驗架構的Fabric以前，Fabric團隊已經有利用排序執行模型構建使用PBFT[11]共識算法的帶有準入權限的區塊鏈構建經驗。從許多概念證實的應用的反饋來看，這種方法的侷限性當即變得清晰。舉個例子，用戶常常觀察到節點間狀態不一致並報告共識協議的bug；在全部狀況下，仔細檢查會發現罪魁禍首是非肯定性交易。其餘投訴以及限制的表現，例如，有用戶反應「每秒只有5筆交易」，可是他們的交易每筆平均須要200毫秒才能執行完成。咱們已經瞭解到區塊鏈系統的關鍵屬性，即一致性，安全性和性能，必須不依賴於用戶的知識和意願，特別是區塊鏈運行在不受信任的狀況下運行的。

3. 架構

在這一節，咱們將介紹3階段 執行-排序-校驗架構並解釋交易流程。Fabric的組建將在第4章介紹。

3.1 Fabric概覽

Fabric是一個帶有準入權限的分佈式區塊鏈系統，能夠執行使用通用編程語言編寫的分佈式應用（例如：Go，Java，Node.js）。它安全地在只能追加的帳本結構上追蹤執行歷史，並且沒有內置的加密貨幣。

Fabric介紹了執行-排序-嬌豔的區塊鏈架構，並無採用標準的排序執行設計，緣由在第二章中介紹。簡而言之，一個Fabric的分佈式應用由兩部分組成：

• 一個智能合約，叫鏈碼，是實現了應用邏輯的程序代碼，運行在執行階段。鏈碼在fabric中是分佈式應用的核心，可能被不受信任的開發者開發。有一類特殊的鏈碼爲了管理區塊鏈系統和維護參數，存在於系統中，叫作系統鏈碼。（見4.6）
• 背書策略，在校驗階段執行。背書策略不能被不信任的應用開發者選擇和修改；它們是系統的一部分。背書策略在Fabric中是一個靜態庫，能夠由鏈碼經過參數指定。只有指定的管理員能夠運行系統管理功能，並有權修改背書策略。

一個典型的背書策略讓鏈碼指定交易的背書者，由一系列須要進行背書的peer節點指定；它使用一個簡單的邏輯表達集合，例如「五個中的三個」或者「A and B or B and C」。自定義的背書策略能夠實現任意邏輯（例如，咱們的比特幣加密貨幣，見5.1節）。

客戶端發送交易到背書策略指定的peer節點。每一個交易被特殊的節點執行，同時結果被記錄，這步也叫作背書。在執行完了以後，交易進入排序階段，使用可插拔的共識協議生產統一排序的交易，交易被打包進區塊。這些區塊會藉助Gossip協議廣播到全部的節點。不像標準的積極複製[31]，會徹底排序交易輸入，Fabric排序結合狀態的交易輸出，在交易執行階段計算所得。每一個節點在校驗階段校驗背書交易的狀態變化以及執行的一致性。全部節點驗證交易在同一個順序而且驗證是肯定性的。在這個意義上，Fabric在拜占庭模型中引入了一種新的混合複製範例，它結合了被動複製（狀態更新的預一致計算）和主動複製（執行結果和狀態更改的後一致驗證）。

Fabric的執行-排序-校驗架構（rw-set的意思是讀集和寫集合，在3.2中介紹）

執行順序驗證方法如圖2所示。

一個Fabric區塊鏈系統由一系列的node組成一個網絡。正如Fabric是有權限控制的，全部參與網絡的節點都帶有身份，經過一個模塊化的成員服務提供者（MSP）（4.1節）。節點在Fabric網絡中承擔3個角色：

Client： 提交交易提案用於執行，幫助編排執行階段，最終，廣播交易到排序服務。

Peers：執行交易提案同時校驗交易。Peer一樣維護區塊鏈帳本，一個只能追加的數據結構用於記錄交易，組成一條hash鏈，一樣也有狀態，一個簡潔的表現帳本狀態。不是全部的節點執行全部的交易提案，只有一部分叫作背書節點（或者簡單說，背書者），由鏈碼策略指定和哪一個交易有關。然而，全部的節點都持有完整的帳本。

排序服務節點

簡單講叫作Orderer，是公共的排序服務組件。簡短地來講，排序服務在Fabric中創建了全部交易的順序，在執行階段每一個交易包含了狀態更新和計算的依賴，並帶有背書節點的簽名。Orderers不知道應用狀態，也不參與交易的執行或者校驗。這種設計在Fabric中渲染了模塊化的共識並簡化了共識協議的更換。

Fabric中high level交易流程

由於在同一個物理節點上扮演不一樣的角色成爲了可能，所以Fabric能夠被操做像傳統的點對點區塊鏈系統同樣，在每一個節點維護狀態，調用，校驗，排序交易。不一樣節點的交易流程在圖三中描述。

對比目前未知只支持單鏈的區塊鏈，目前爲止，Fabric網絡已經支持多鏈機制，支持多條鏈鏈接到排序服務。每一個區塊鏈叫作channel，而且擁有不一樣的節點做爲成員。可是基於channel的共識不是協調進全部交易的，每一個channel是相對於其餘channel獨立的。全部的部署都認爲全部的orderer是可信的，一樣實如今peer級別的基於channel的權限控制。在下面，咱們簡單提一下channel，集中精力在一個通道上。

接下來三個章節解釋了Fabric中的交易流程，闡明瞭執行，排序和校驗的步驟。一個Fabric網絡如圖四所示。

一個帶有聯盟MSP的Fabric網絡以及運行了（不一樣陰影和顏色的）鏈碼，根據策略有選擇地安裝到節點上。

背書節點模擬提案，經過安裝在區塊鏈中的特定鏈碼執行操做。鏈碼運行在Docker容器中，與背書進程獨立。

一個提案在這時候基於背書節點本地狀態進行模擬，沒有與其餘節點同步；甚至背書節點沒有持久化模擬的結果到帳本狀態中。區塊鏈的狀態被 peer transaction manager (PTM)在帶有版本的鍵值對維護，成功地更新將單調增長版本的值（見4.4）。一個鏈碼建立的狀態不能直接被另外一個鏈碼訪問。鏈碼不該該在程序代碼中維護狀態。惟一可以維護的應該是 GetState, PutState, and DelState操做。手續適當的權限，一個鏈碼能夠調用另外一個鏈碼在相同的通道中去獲取狀態。

做爲模擬的結果，每一個背書者產生了writeset，包含模擬執行產生的狀態更新（例如用一個新的值修改一個key），同時產生一個readset，表明提案模擬基於的依賴版本（例如，全部讀出的key的版本）。在模擬以後，背書節點簽名一個消息叫作背書，包含了讀集，寫集，（同時包含元數據例如交易id，背書者id,背書者簽名），併發送回客戶端一個提案響應。一個客戶端收集直到知足鏈碼背書策略，交易調用（參見3.4）。特別地，這要求全部的背書者肯定地生產一樣的執行結果（例如，相同的讀集和寫集）。而後，客戶端繼續建立交易，發送到排序服務。

**關於設計選擇的討論。**背書節點模擬執行交易沒有與其餘背書節點同步，2個背書節點可能根據不一樣的帳本狀態執行從而產生不一樣的輸出。對於標準的背書策略，須要多個背書節點產生相同的結果，這意味着在多個操做對同一個key的爭論，一個客戶端可能不能知足背書策略。與複製中的主備複製（經過中間件[24]）相比，這是一個新元素：假設沒有一個節點的執行結果在區塊鏈網絡中是可信的。

咱們有意識地採用了這個設計，由於它簡化了架構並且很是適用於區塊鏈應用。正如比特幣演示的，分佈式應用程序在正常狀況下，訪問相同狀態的操做能夠減小或者徹底消除（例如，在比特幣中，2個操做修改了一樣的對象是不容許的，表明雙花攻擊[28]）。

在排序階段前執行交易是容忍不肯定性鏈碼很是重要的一點在第二節。Fabric中一個不肯定性交易只會危及其自身的活性，由於客戶端沒法收集足夠多數量的背書，這是更容易接受的在實踐中，相比於排序執行架構，排序執行架構會致使節點狀態的不一致。

最後，容忍不肯定性執行還能夠處理不可信鏈碼的DoS攻擊，由於若是背書節點懷疑DoS攻擊，能夠根據本地執行策略終止執行。這不會影響系統的一致性，並且在排序執行架構中，這種單方面終止是不可能的。

3.3 排序階段

當客戶端在提案上收集了足夠多的背書時，他會組裝一個交易並講它提交給排序服務。該交易包括交易的有效負載（例如，鏈碼操做相關參數），交易元數據，一系列背書。排序服務爲每一個渠道上的全部交易進行排序。換句話說，排序源原子廣播[7]背書，從而在交易上達成共識，儘管可能有錯誤的排序者。此外，排序服務將多個交易打包進區塊，並輸出包含交易的帶有hash鏈的區塊。將交易分組或者批量打包進區塊能夠提高廣播協議的吞吐率，這是容錯廣播環境中衆所周知的技術。

在高層次來看，排序服務僅僅支持下列2個操做。這些操做由peer節點經過通道標識隱式參數化：

broadcast：客戶端調用此操做來廣播任意交易tx，該交易一般包含交易有效負載和客戶端的簽名，以便進行傳播。

deliver：客戶端調用此方法以檢索具備非負序號s的塊B.該塊包含交易列表和表示序列號爲的塊的哈希鏈值h，即。因爲客戶端能夠屢次調用它而且一旦它可用就老是返回相同的塊，咱們說當在調用deliver時第一次接收B時，Peer傳遞具備序列號s的塊B。

排序服務確保一個通道上交付的塊徹底有序。更具體地說，排序確保了每一個渠道的如下安全屬性：

協議：對於任何帶有序列號s和的兩個塊B，在正確的Peer上傳送，如s=s'，它保證B=B'。

Hashchain完整性：若是某個正確的節點傳遞帶有編號s的塊B而另外一個正確的節點傳遞帶有編號s+1的塊B'=([tx1,...,txk],h')，則它保持h'=H(B)，其中H(.)表示加密散列函數。

不跳過：若是正確的節點p爲每一個i=0,...,s-1發送一個編號爲s>0的塊，則節點p已經發送了一個編號爲i的塊。

無建立：當正確的節點傳遞帶有編號s的塊B時，則對於每一個tx < B，某個客戶端已經廣播了tx。

爲了活躍，排序服務至少支持如下「最終」屬性：

有效性：若是正確的客戶端調用廣播（tx），則每一個正確的節點最終都會傳送包含tx的塊B，其中包含一些序列號。

可是，容許每一個單獨的訂購實現都有本身的客戶請求的活躍性和公平性保證。

因爲區塊鏈網絡中可能存在大量節點，但預計只有相對較少的節點實現排序服務節點，所以能夠將Fabric配置爲使用內置Gossip服務將所交付的塊從排序服務傳播到全部Peer節點（第4.3節）。Gossip的實現是可擴展的，而且與排序服務的特定實現無關，所以它適用於CFT和BFT訂購服務，確保了Fabric的模塊化。

排序服務還能夠執行訪問控制檢查以查看是否容許客戶端在給定信道上廣播消息或接收塊。排序服務的這一功能和其餘功能將在第4.2節中進一步說明。

關於設計選擇的討論。排序服務不維護區塊鏈的任何狀態很是重要，既不驗證也不執行交易。這種架構是Fabric的一個重要的定義功能，它使Fabric成爲第一個區塊鏈系統，能夠徹底區分執行和驗證的共識。這使得共識儘量模塊化，並實現了實現排序服務的共識協議生態系統。

3.4 驗證階段

經過直接鏈接到排序服務或經過八卦將塊交付給Peer節點。當新塊到達時，它進入驗證階段，包括三個連續步驟：

1.對於塊內的全部交易，背書政策校驗並行發生。校驗是所謂的驗證系統鏈碼（VSCC）的任務，VSCC是一個靜態庫，是區塊鏈配置的一部分，負責驗證對鏈碼所配置的背書政策的校驗（參見第4.6節） 。若是校驗不滿意，則交易被標記爲無效，其影響將被忽略。

2.按順序對塊中的全部交易進行讀寫衝突檢查。對於每一個交易，它將readset字段中的密鑰版本與分類賬的當前狀態中的密鑰版本進行比較，由節點本地存儲，並確保它們仍然相同。若是版本不匹配，則事務將標記爲無效，並忽略其影響。

3.分類賬更新階段最後運行，其中塊附加到本地存儲的分類賬，並更新區塊鏈狀態。特別是，當將塊添加到分類賬時，前兩個步驟中的有效性檢查結果也會以位掩碼的形式保留，表示塊內有效的交易。這有利於稍後重建狀態。此外，經過將writeset中的全部鍵值對寫入本地狀態來應用全部狀態更新。

Fabric中的默認VSCC容許在表示鏈代碼的配置的背書集合上單調邏輯表達式。VSCC評估證實，經過對交易的承認經過有效簽名表達的節點集合知足表達式。可是，不一樣的VSCC策略能夠靜態配置。

關於設計選擇的討論。 Fabric的分類賬包含全部交易，包括那些被視爲無效的交易。這是從總體設計得出的，由於與鏈碼狀態無關的排序服務產生了塊的鏈，而且由於驗證是由共識後的Peer節點完成的。在某些須要在後續審計期間跟蹤無效交易的用例中須要此功能，並與其餘區塊鏈造成對比圖5. Fabric Peer節點組件。

4. Fabric組件

Fabric是用Go編寫的，使用gRPC框架（grpc.io/）進行客戶端，Peer…

4.1 成員服務

成員服務提供者（MSP）維護系統中全部節點的標識（客戶端，Peer節點和排序者），並負責頒發用於身份驗證和受權的節點憑據。因爲Fabric是通過許可的，所以節點之間的全部交互都經過通過身份驗證的消息進行，一般使用數字簽名。會員服務包括每一個節點的組件，能夠在其中驗證交易，驗證交易的完整性，簽署承認，驗證承認以及驗證其餘區塊鏈操做。用於密鑰管理和節點註冊的工具也是MSP的一部分。

MSP是一種抽象，可使用不一樣的實例。Fabric中的默認MSP實現處理基於數字簽名的標準PKI方法，而且能夠容納商業認證機構（CA）。還提供獨立CA和Fabric，稱爲Fabric-CA。此外，設想了替代的MSP實現，例如依賴於匿名憑證來受權客戶端調用事務而不將其連接到身份[10]。

Fabric容許兩種模式來設置區塊鏈網絡。在fl ine模式中，憑證由CA生成並在帶外分發到全部節點。同儕和訂購者只能在fl ine模式下注冊。對於註冊客戶端，Fabric-CA提供了一種在線模式，能夠向其發出加密憑據。MSP配置必須確保全部節點（尤爲是全部節點）識別出與有效相同的身份和身份驗證。

MSP容許身份聯合，例如，當多個組織運行區塊鏈網絡時。每一個組織都向本身的成員發放身份，每一個同行都承認全部組織的成員。這能夠經過多個MSP實例來實現，例如，經過在每一個組織和MSP之間建立映射。

4.2 排序服務

排序服務管理多個通道。在每一個通道，它提供一下服務：

1. 用於簡歷交易順序，實現廣播和傳遞服務。
2. 當成員經過廣播配置更新交易時，能夠從新配置通道。
3. 可選地，在排序服務充當可信實體的那些配置中，能夠限制向特定的客戶端和Peer節點廣播交易。

排序服務在系統通道上使用創世區塊進行啓動。該區塊定義了排序服務的屬性。

當前的生產實現包括實現此處描述的操做並經過系統通道進行通訊的訂購服務節點（OSN）。實際的原子廣播功能由Apache Kafka（http：// kafka.apache.org）的實例提供，該實例基於ZooKeeper提供可擴展的發佈 - 訂閱消息傳遞和節點崩潰的強一致性。Kafka能夠在與OSN分開的物理節點上運行。OSN充當Peer和Kafka之間的代理。

OSN直接將新接收的交易注入原子廣播（例如，向Kafka broker）。另外一方面，節點批量交易從原子廣播的塊中接收。只要知足如下三個條件之一，就會切一個塊：（1）該塊包含指定的最大交易數量; （2）塊已達到最大大小（以字節爲單位）;或（3）自收到新區塊的第一次交易以來已通過的時間量，以下所述。

該批處理過程是肯定性的，所以在全部節點處產生相同的塊。考慮到從原子廣播接收的交易流，很容易看出前兩個條件是平凡的肯定性。爲了確保第三種狀況下的肯定性塊生成，節點在從原子廣播讀取塊中的第一個交易時啓動計時器。若是在計時器到期時塊還沒有被切下，則節點在通道上廣播特殊的切割時間交易，該事務指示它想要切割的塊的序列號。另外一方面，每一個節點在接收到給定塊號的第一個切換時間交易時當即切斷新塊。因爲此交易以原子方式傳遞到全部鏈接的節點，所以它們都在塊中包含相同的交易列表。 （要在存在f拜占庭故障的OSN的狀況下部署此方案，只有在接收f+1時間切換交易時纔會切斷該塊。）排序者將最近交付的一系列塊直接保存到其文件系統中，所以它們能夠回答Peer節點經過交付檢索塊。

使用Kafka的排序服務是目前可用的三種排序服務之一。名爲Solo的集中式排序服務在一個節點上運行，用於開發。基於BFT-SMaRt的概念驗證排序[3]也已經提供[34];它確保原子廣播服務，但還沒有從新配置和訪問控制。這說明了Fabric中共識的模塊性。

4.3 Peer Gossip

排序和驗證分離執行的一個優勢是他們能夠獨立擴展。可是，因爲大多數一致性算法（在CFT和BFT模型中）都是帶寬限制的，所以排序服務的吞吐量受其節點的網絡容量限制。經過添加更多節點沒法擴大共識[14,36]，相反，吞吐量會下降。可是，因爲排序和驗證是分離的，所以咱們感興趣的是在排序段以後將執行結果有效地廣播到全部Peer節點以進行驗證。這正是Gossip組件的目標，它爲此目的利用流行多播[15]。這些塊由排序服務簽署。這意味着Peer節點能夠在接收到全部塊時獨立地組裝區塊鏈並驗證其完整性。

與覆蓋網絡相比，經過八卦傳播是強大的而且抵抗節點故障。進行隨機選擇容許八卦減小維持Peer節點之間鏈接的開銷，而且還減小了攻擊面。Gossip在容許的環境中運行良好，能夠承受sybil攻擊和消息僞造。

用於八卦的通訊層基於gRPC而且利用具備相互認證的TLS，這使得每一方可以將TLS憑證綁定到遠程Peer的身份。八卦組件維護系統中在線Peer的最新成員視圖。全部Peer獨立地從按期傳播的成員資格數據構建本地視圖。此外，在崩潰或網絡中斷後，節點能夠從新鏈接到視圖。

八卦的主要目的是利用推輓協議可靠地在節點之間分配消息，即來自排序階段的塊。它使用兩個階段進行信息傳播：在推送期間，每一個節點從成員資格視圖中選擇一組隨機的活動鄰居，並將它們轉發給它們;在拉取期間，每一個節點週期性地探測一組隨機選擇的節點並從新尋找丟失的消息。已經顯示[15,22]使用兩種方法串聯對於最佳地利用可用帶寬並確保全部節點以高几率接收全部消息是相當重要的。

爲了減小從排序節點到網絡的發送塊的負載，該協議還選擇了一個領導節點，它表明它們從排序服務中提取塊並啓動八卦分發。這種機制對領導者失敗具備彈性。

八卦的另外一個任務是將狀態轉移到新鏈接的節點和長時間斷開鏈接的節點。他們須要接收鏈中的全部塊。該特徵依賴於每一個節點存儲的最大塊序列號與成員資格數據一塊兒傳播的事實。

4.4 分類帳

每一個Peer的分類賬組件在持久存儲上維護分類賬和區塊鏈狀態，並啓用模擬，驗證和分類賬更新階段。從廣義上講，它由塊存儲和節點交易管理器（PTM）組成。

Ledger塊存儲。分類賬塊存儲持久化交易塊，並實現爲一組僅附加文件。因爲塊是不可變的而且以有限的順序到達，所以僅附加結構能夠提供最大的性能。此外，塊存儲維護一些索引，用於隨機訪問塊或塊中的交易。

節點交易管理器（PTM）。 PTM在版本化的鍵值存儲中維護最新狀態。它爲由任何鏈代碼存儲的每一個惟一條目key存儲形式（key，val，ver）的一個元組，包含其最近存儲的值val及其最新版本ver。版本由塊序列號和塊內的交易（存儲條目）的序列號組成。這使得版本獨特且單調增長。

PTM使用本地鍵值存儲來實現版本化鍵值存儲，由Go中實現的LevelDB鍵值數據庫實現（https：// github.com / syndtr / goleveldb）或Apache CouchDB（http：// couchdb.apache.org/）。

在模擬期間，PTM爲交易提供最新狀態的穩定快照。如3.2節所述，PTM在readset中爲GetState訪問的每一個條目記錄元組（key，ver），在writeset中記錄事務用PutState更新的每一個條目的元組（key，val）。此外，PTM支持範圍查詢，爲此計算查詢結果的加密哈希值（一組元組（key，ver）），並將查詢字符串自己和哈希值添加到readset。

對於交易驗證（第3.4節），PTM按順序驗證塊中的全部交易。這將檢查交易是否與任何先前的交易（在塊內或更早的交易中）衝突。對於readset中的任何鍵，若是readset中記錄的版本與最新狀態中存在的版本不一樣（假設全部先前的有效交易都已提交），則PTM將該事務標記爲無效。對於範圍查詢，PTM從新執行查詢並將散列與readset中存在的散列進行比較，以確保不會發生幻像讀取。這種讀寫衝突語義致使單拷貝可串行化[23]。

分類賬組件在分類賬更新期間容忍Peer崩潰，以下所示。在接收到新塊以後，PTM已使用第3.4節中提到的位掩碼在塊中執行驗證並將交易標記爲有效或無效。分類賬如今將塊寫入分類賬塊存儲，將其複製到磁盤，而後更新塊存儲索引。而後，PTM將全部有效交易的writeset的狀態更改應用於本地版本存儲。最後，它計算並保持值保存點，表示最大成功應用的塊編號。值savepoint用於在從崩潰中恢復時從持久塊中恢復索引和最新狀態。

4.5 Chaincode執行

Chaincode在與Peer節點的其他部分鬆散耦合的環境中執行，而且支持用於爲編程鏈代碼添加新語言的插件。目前，鏈代碼支持三種語言：Go，Java和Node。

每一個用戶級或應用程序鏈代碼都在Docker容器環境中的單獨進程中運行，該環境將鏈代碼彼此隔離，並與節點代碼隔離。這也簡化了鏈代碼生命週期的管理（即，啓動，中止或停止鏈代碼）。鏈代碼和對等體使用gRPC消息進行通訊。經過這種鬆散耦合，Peer節點不知道實現鏈代碼的實際語言。

與應用程序鏈代碼相反，系統鏈代碼直接在對等進程中運行。系統鏈代碼能夠實現Fabric所需的特定功能，而且能夠在用戶鏈代碼之間的隔離過分限制的狀況下使用。有關係統鏈代碼的更多詳細信息，請參見下一節。

4.6 配置與系統鏈碼

Fabric的基本行爲是經過通道配置和特殊鏈碼（稱爲系統鏈碼）組成的。

渠道配置。回想一下，一個通道造成一個邏輯區塊鏈。通道的配置保存在特殊配置塊中的元數據中。每一個配置塊包含完整的通道配置，不包含任何其餘交易。每一個區塊鏈都以一個稱爲創世塊的配置塊開始，該塊用於引導通道。渠道配置包括：

•參與節點的MSP定義。 •OSN的網絡地址。 •共識實現和排序服務的共享配置，例如批量大小和超時。 •管理排序服務操做（廣播和交付）訪問的規則。 •能夠修改管理通道配置的每一個部分的規則。

可使用通道配置更新事務來更新信道的配置。此事務包含對配置所作更改的表示，以及一組簽名。訂購服務節點經過使用當前配置來驗證更新是否有效，以驗證使用簽名受權修改。而後，排序者生成一個新的配置塊，它嵌入了新的配置和配置更新交易。接收此塊的節點根據當前配置驗證配置更新是否被受權;若是有效，他們會更新當前的配置。

系統鏈代碼。部署應用程序鏈代碼時引用了承認系統鏈代碼（ESCC）和驗證系統鏈代碼（VSCC）。以對稱方式選擇這兩個鏈代碼，使得ESCC的輸出（承認）能夠被驗證爲VSCC的輸入的一部分。

ESCC將提案和提案模擬結果做爲輸入。若是結果使人滿意，那麼ESCC會產生一個包含結果和承認的回覆。對於默認的ESCC，此承認只是對等方本地簽名身份的簽名。

VSCC將事務做爲輸入，並輸出該事務是否有效。對於默認的VSCC，將根據爲鏈代碼指定的承認政策收集和評估承認。

其餘系統鏈代碼實現其餘支持功能，例如配置和鏈代碼生命週期。

5. 評估

儘管Fabric還沒有通過性能調整和優化，但咱們將在本節中報告一些初步性能數據。Fabric是一個複雜的分佈式系統;它的性能取決於許多參數，包括分佈式應用程序和交易大小的選擇，排序服務和共識實現及其參數，網絡中節點的網絡參數和拓撲，節點運行的硬件，節點數量和通道，進一步的配置參數和網絡動態。所以，Fabric的深刻性能評估被推遲到將來的工做中。

在沒有區塊鏈標準基準的狀況下，咱們使用最突出的區塊鏈應用來評估Fabric，這是一種簡單的權威鑄造加密貨幣，它使用比特幣的數據模型，咱們稱之爲Fabric coin（如下簡稱爲Fabcoin）。這容許咱們將Fabric的性能放在其餘許可區塊鏈的上下文中，這些區塊鏈一般來自比特幣或以太坊。例如，它也是其餘許可區塊鏈基準測試中使用的應用程序[19,32]。

在下文中，咱們首先描述了Fabcoin（第5.1節），它還演示瞭如何定製驗證階段和承認政策。在5.2節中，咱們提出基準並討論咱們的結果。

5.1 Fabric coin

UTXO加密貨幣。比特幣[28]引入的數據模型已被稱爲「未使用的交易輸出」或UTXO，而且還被許多其餘加密貨幣和分佈式應用程序使用。UTXO表示數據對象演變中的每一個步驟，做爲分類賬上的單獨原子狀態。這種狀態由交易建立，並由稍後發生的另外一個惟一交易銷燬（或「消耗」）。每一個給定的交易都會破壞許多輸入狀態並建立一個或多個輸出狀態。比特幣中的「硬幣」最初是經過幣基交易建立的，該交易獎勵塊的「礦工」。這在分類賬中顯示爲指定礦工爲全部者的硬幣狀態。任何硬幣均可以花費在硬幣經過一個交易分配給新全部者的意義上，該交易原子地破壞指定前一個全部者的當前硬幣狀態並建立表明新全部者的另外一個硬幣狀態。

咱們在Fabric的鍵值存儲中捕獲UTXO模型，以下所示。每一個UTXO狀態對應於一次建立的惟一KVS條目（硬幣狀態爲「未花費」）而且銷燬一次（硬幣狀態爲「花費」）。等價地，每一個州能夠被視爲建立後具備邏輯版本0的KVS條目;當它再次被銷燬時，它會收到版本1。不該該對這些條目進行任何併發更新（例如，嘗試以不一樣方式更新硬幣狀態等於硬幣的雙倍花費）。

UTXO模型中的值經過引用幾個輸入狀態的交易傳輸，這些輸入狀態都屬於發出交易的實體。實體擁有一個狀態，由於該實體的公鑰包含在狀態自己中。每一個交易在表明新全部者的KVS中建立一個或多個輸出狀態，刪除KVS中的輸入狀態，並確保輸入狀態中的值之和等於輸出狀態值的總和。還有一個策略肯定如何建立價值（例如，比特幣中的硬幣羣交易或其餘系統中的特定薄荷操做）或銷燬（即，做爲執行所消耗的費用）。

Fabcoin實現。 Fabcoin中的每一個狀態都是形式的元組（鍵，val =txid.j,( 金額，全部者，標籤))，表示做爲具備標識符txid的交易的第j個輸出建立的硬幣狀態，並將標記爲label的金額單位分配給公鑰全部者的實體。標籤是用於識別給定類型的硬幣的字符串（例如，「USD」，「EUR」，「FBC」）。交易標識符是惟一標識每一個Fabric交易的短值。Fabcoin實施包括三個部分：（1）客戶錢包，（2）Fabcoin鏈碼，以及（3）Fabcoin實施其承認政策的定製VSCC。

Fabcoin鏈碼。Peer運行Fabcoin的鏈代碼，模擬交易並建立讀取集和寫入集。簡而言之，在SPEND交易的狀況下，對於∈輸入中的每一個輸入硬幣狀態，鏈碼首先執行GetState（in）;這與Fabric的版本化KVS（Sec.4.4）中的當前版本一塊兒進入readset。而後鏈代碼爲每一個輸入狀態執行DelState（in），它還會添加到writeset並有效地將硬幣狀態標記爲「花費」。最後，對於j=1,...,|輸出|，鏈代碼執行PutState（txid.j, out）第j個輸出=(金額，全部者，標籤）。此外，節點可選地運行交易驗證代碼，以下面在Fabcoin的VSCC步驟中所描述的;這不是必需的，由於自定義VSCC實際上驗證了交易，但它容許（正確的）節點過濾掉可能格式錯誤的交易。在咱們的實現中，鏈代碼運行Fabcoin VSCC而無需加密驗證簽名。

自定義VSCC。最後，每一個對等方使用自定義VSCC驗證Fabcoin交易。這個驗證首先是相應公共方法論下的sig中的加密簽名。在每一個實驗中，在第一階段，咱們調用僅包含Fabcoin MINT操做的交易來生成硬幣，而後運行實驗的第二階段，咱們在先前鑄造的硬幣上調用Fabcoin SPEND操做（有效地運行單輸入，單輸出SPEND交易）。在報告吞吐量測量時，咱們使用在單個VM上運行的愈來愈多的Fabric CLI客戶端（修改成發出併發請求），直到端到端吞吐量飽和，並在飽和以前說明吞吐量。吞吐量數據被報告爲平均吞吐量密鑰，並執行以下的語義驗證。對於MINT交易，它檢查輸出狀態是否在匹配的交易標識符（txid）下建立，而且全部輸出量都是正數。對於SPEND交易，VSCC還驗證（1）對於全部輸入硬幣狀態，已建立readset中的條目，而且它也是Client wallet。默認狀況下，每一個Fabric客戶端維護一個添加到writeset並標記爲已刪除，（2）本地存儲全部輸入硬幣狀態的金額的加密密鑰集合的Fabcoin錢包總和等於容許客戶花費的總和硬幣。爲了建立全部輸出硬幣狀態的SPEND數量，以及（3）傳輸一個或多個硬幣的輸入和輸出，客戶端錢包將硬幣標籤匹配。這裏，VSCC經過從分類賬中檢索它們的當前值來得到爲輸入硬幣建立Fabcoin請求請求=(輸入，輸出，sigs的金額。

2在Fabric主分支中使用提交ID 9e770062進行分配。

包含：（1）輸入硬幣狀態列表，在,...|中輸入=|，指定客戶但願花費的硬幣狀態（in，...），注意Fabcoin VSCC不檢查transacwell爲（2）輸出列表硬幣狀態，輸出金額，全部者，雙重支出的tions，由於這經過Fabric的標籤),...|發生。客戶端錢包使用私鑰進行簽名，該私鑰是在自定義VSCC以後運行的標準驗證。在與輸入硬幣狀態相對應的狀況下，若是兩個事務試圖分配相同的unFabcoin請求和nonce（這是每一個Fabric花費的硬幣狀態的一部分給新的全部者），則二者的串聯都將經過VSCC事務，並在一組sigs中添加簽名。當PTM執行的不肯定性檢查中的金額總和時，SPEND邏輯但隨後將在讀寫事務中被捕獲。根據Secput，硬幣狀態至少是輸出3.4和4.4中的金額之和，PTM驗證當前版本的輸出量和輸出量是正數。對於存儲在分類賬中的MINT編號與readset中的編號匹配;建立新硬幣的交易，輸入僅包含一個所以，在第一個交易更改了特殊硬幣狀態的標識符（即，對公鑰的引用）以後，第二個訂購的交易將被稱爲中央銀行（ CB），而輸出包含nized爲無效。任意數量的硬幣狀態。要被視爲有效，sigs中的MINT事務的5.2實驗簽名必須是加密設置。除非另有明確說明，不然咱們在CB的公鑰下的外部簽名實驗中：（1）節點運行在Fab版本請求的Fabric版本v1.1-preview2上，以及前面提到的經過本地lognonce進行性能評估的儀表。Fabcoin能夠配置爲使用多個CB或ging，（2）節點託管在單個IBM Cloud（SoftLayer）中，指定來自一組CB的閾值數量的簽名。數據中心做爲與1Gbps網絡互連的專用虛擬機最終，客戶端錢包包括將Fabcoin請求轉換爲工做，（3）全部節點都是運行事務的2.0 GHz 16-vCPU虛擬機，並將其發送給其選擇的對等方。Ubuntu具備8GB的RAM和SSD做爲本地磁盤，（4）單通道訂購服務運行典型的Kafka訂購者設置，包括3個ZooKeeper節點，4個Kafka代理和3個Fabric orderers，全部這些都在不一樣的VM上，（5）有5個總共同行，全部這些都是Fabcoin代言人，（6）簽名使用默認的256位ECDSA方案。爲了在跨越多個節點的事務流中測量和分級延遲，在整個實驗中節點時鐘與NTP服務同步。Fabric節點之間的全部通訊都配置爲使用TLS。

咱們能夠觀察到吞吐量並無顯着超過2MB的塊大小，可是延遲會變得更糟（正如預期的那樣）。所以，咱們採用2MB做爲如下實驗的塊大小，目標是最大化測量的吞吐量，假設大約500ms的端到端延遲是可接受的。

交易規模。在此實驗期間，咱們還觀察了MINT和SPEND事務的大小。特別是，2MB塊包含473個MINT或670個SPEND事務，即SPEND的平均事務大小爲3.06kB，MINT的平均事務大小爲4.33kB。一般，Fabric中的事務很大，由於它們帶有證書信息。此外，Fabcoin的MINT交易大於SPEND交易，由於它們帶有CB證書。這是Fabric和Fabcoin將來改進的途徑。

對等CPU的影響。 Fabric對等體運行許多CPU密集型加密操做。爲了估計CPU對吞吐量的影響，咱們進行了一系列實驗，其中4個對等體在4個，8個，16個和32個vCPU VM上運行，同時還進行了塊驗證的粗粒度延遲分級以更好地識別瓶頸。咱們的實驗側重於驗證階段，由於Kafka訂購服務的訂購從未成爲咱們實驗的瓶頸。驗證最後，在本實驗中，咱們測量了32-vCPU對等體上每秒3560個事務處理（tps）的平均SPEND吞吐量。通常來講，MINT吞吐量略低於SPEND，但差別仍在10％之內。

延遲分階段進行。咱們在上一次實驗中進一步對報告的峯值吞吐量進行了粗粒度延遲分析。結果如表1所示。排序階段包括在驗證開始以前對等體內的廣播傳遞延遲和內部延遲。該表報告了MINT和SPEND的平均延遲，標準誤差和尾部延遲（99％和99.9％）。

咱們能夠觀察到排序主導了總體延遲。咱們觀察到平均潛伏期低於550毫秒，尾部潛伏期爲亞秒級。特別是，咱們實驗中最高的端到端延遲來自負載創建期間的第一個塊。經過利用定貨人的時間切割參數（參見第3.3節）能夠調節和減小低負荷下的延遲，咱們在實驗中基本上不使用該參數，由於咱們將其設置爲較大的值。

SSD與RAM磁盤。爲了評估使用本地SSD進行穩定存儲的開銷，咱們重複了以前的實驗，將RAM磁盤（tmpfs）做爲穩定存儲安裝在全部節點虛擬機。好處有限，由於tmpfs只能幫助同行驗證的分類帳階段。咱們在32vCPU同行測得的持續峯值吞吐量爲3870 SPEND tps，比SSD大約高出9％。

表1. MINT和SPEND的延遲統計信息（以毫秒（ms）爲單位），在具備2MB塊的32-vCPU對等體上分爲五個階段。驗證（6）包括第3,4和5階段;端到端延遲包含1-5階段。

6. 相關工做

Fabric的架構相似於Kemme和Alonso [24]開創的中間件複製數據庫。可是，全部關於此的現有工做僅解決了崩潰失敗，而不是對應於BFT系統的分佈式信任的設置。例如，具備非對稱更新處理的複製數據庫[25，Sec。 6.3]依賴於一個節點來執行每一個事務，這不適用於區塊鏈。Fabric的執行順序驗證體系結構能夠解釋爲對Byzantine模型的這項工做的歸納，以及分佈式分類帳的實際應用。從BFT數據庫複製的角度來看，Byzantium [17]和HRDB [35]是Fabric的另外兩個前身。Byzantium容許事務並行運行並使用主動複製，但徹底使用BFT中間件命令BEGIN和COMMIT / ROLLBACK。在樂觀模式中，每一個操做都由一個主副本協調;若是懷疑主設備是拜占庭，則全部副本都執行主設備的事務操做，並觸發昂貴的協議來更改主設備。HRDB以更強大的方式依賴於正確的主人。與Fabric相比，兩個系統都使用主動複製，沒法處理靈活的信任模型，而且依賴於副本的肯定性操做。可是，他們的數據庫API比Fabric的KVS模型更豐富。

在Eve [21]中，在BFT模型中也探索了SMR的相關架構。它的對等體同時執行事務，而後使用共識協議驗證它們是否都達到相同的輸出狀態。若是狀態發散，則它們會回滾並按順序執行操做。Eve包含獨立執行的元素，它也存在於Fabric中，但不提供其餘功能。

許可模型中的大量分佈式分類賬平臺最近問世，這使得沒法與全部分佈式分類賬進行比較（一些突出的是Tendermint [5]，Quorum [19]，Chain Core [12]，Multichain <https：/ /www.multichain.com/>,Hyperledger Sawtoothsawtooth.hyperledger.org，Volt提案[32]等，請參閱最近的概述[9,16]中的參考文獻。全部平臺都遵循訂單執行架構，如第2節所述。做爲一個表明性的例子，採用Quorum平臺[19]，一個以企業爲中心的以太坊版本。基於Raft [29]的共識，它使用八卦向全部同伴傳播交易，而且Raft領導者（稱爲minter）將有效交易組裝到一個區塊，並使用Raft分配這個。全部對等方按照領導者決定的順序執行交易。所以，它受到第1-2節中提到的限制。

參考

[1] P.-L. Aublin, R. Guerraoui, N. Knezevi ˇ c, V. Qu ´ ema, and M. Vukolic. The next 700 BFT protocols. ´ ACM Trans. Comput. Syst., 32(4):12:1–12:45, Jan. 2015.

[2] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza. Zerocash: Decentralized anonymous payments from bitcoin. In IEEE Symposium on Security & Privacy, pages 459–474, 2014.

[3] A. N. Bessani, J. Sousa, and E. A. P. Alchieri. State machine replication for the masses with BFT-SMART. In International Conference on Dependable Systems and Networks (DSN), pages 355–362, 2014.

[4] G. Bracha and S. Toueg. Asynchronous consensus and broadcast protocols. J. ACM, 32(4):824–840, 1985.

[5] E. Buchman. Tendermint: Byzantine fault tolerance in the age of blockchains. M.Sc. Thesis, University of Guelph, Canada, June 2016. [6] N. Budhiraja, K. Marzullo, F. B. Schneider, and S. Toueg. The primary-backup approach. In S. Mullender, editor, Distributed Systems (2nd Ed.), pages 199–216. ACM Press/AddisonWesley, 1993.

[7] C. Cachin, R. Guerraoui, and L. E. T. Rodrigues. Introduction to Reliable and Secure Distributed Programming (2. ed.). Springer, 2011.

[8] C. Cachin, S. Schubert, and M. Vukolic. Non-determinism ´ in byzantine fault-tolerant replication. In 20th International Conference on Principles of Distributed Systems (OPODIS), 2016.

[9] C. Cachin and M. Vukolic. Blockchain consensus protocols ´ in the wild. In A. W. Richa, editor, 31st Intl. Symposium on Distributed Computing (DISC 2017), pages 1:1–1:16, 2017.

[10] J. Camenisch and E. V. Herreweghen. Design and implementation of the idemix anonymous credential system. In ACM Conference on Computer and Communications Security (CCS), pages 21–30, 2002.

[11] M. Castro and B. Liskov. Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst., 20(4):398–461, Nov. 2002.

[12] Chain. Chain protocol whitepaper. chain.com/ docs/1.2/protocol/papers/whitepaper, 2017.

[13] B. Charron-Bost, F. Pedone, and A. Schiper, editors. Replication: Theory and Practice, volume 5959 of Lecture Notes in Computer Science. Springer, 2010.

[14] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. G. Sirer, et al. On scaling decentralized blockchains. In International Conference on Financial Cryptography and Data Security (FC), pages 106–125. Springer, 2016.

[15] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry. Epidemic algorithms for replicated database maintenance. In ACM Symposium on Principles of Distributed Computing (PODC , pages 1–12. ACM, 1987.

[16] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang. Untangling blockchain: A data processing view of blockchain systems. e-print, arXiv:1708.05665 [cs.DB], 2017.

[17] R. Garcia, R. Rodrigues, and N. M. Preguic¸a. Efficient middleware for Byzantine fault tolerant database replication. In European Conference on Computer Systems (EuroSys), pages 107–122, 2011.

[18] R. Guerraoui, R. R. Levy, B. Pochon, and V. Quema. Through- ´ put optimal total order broadcast for cluster environments. ACM Trans. Comput. Syst., 28(2):5:1–5:32, 2010.

[19] J. P. Morgan. Quorum whitepaper. github.com/ jpmorganchase/quorum-docs, 2016.

[20] F. P. Junqueira, B. C. Reed, and M. Serafini. Zab: Highperformance broadcast for primary-backup systems. In International Conference on Dependable Systems & Networks (DSN), pages 245–256, 2011.

[21] M. Kapritsos, Y. Wang, V. Quema, A. Clement, L. Alvisi, ´ and M. Dahlin. All about Eve: Execute-verify replication for multi-core servers. In Symposium on Operating Systems Design and Implementation (OSDI), pages 237–250, 2012.

[22] R. Karp, C. Schindelhauer, S. Shenker, and B. Vocking. Randomized rumor spreading. In Symposium on Foundations of Computer Science (FOCS), pages 565–574. IEEE, 2000.

[23] B. Kemme. One-copy-serializability. In Encyclopedia of Database Systems, pages 1947–1948. Springer, 2009.

[24] B. Kemme and G. Alonso. A new approach to developing and implementing eager database replication protocols. ACM Transactions on Database Systems, 25(3):333–379, 2000.

[25] B. Kemme, R. Jimenez-Peris, and M. Pati ´ no-Mart ˜ ´ınez. Database Replication. Synthesis Lectures on Data Management. Morgan & Claypool Publishers, 2010.

[26] A. E. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou. Hawk: The blockchain model of cryptography and privacypreserving smart contracts. In 37th IEEE Symposium on Security & Privacy, 2016.

[27] S. Liu, P. Viotti, C. Cachin, V. Quema, and M. Vukoli ´ c. XFT: ´ practical fault tolerance beyond crashes. In Symposium on Operating Systems Design and Implementation (OSDI), pages 485–500, 2016.

[28] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. www.bitcoin.org/bitcoin.pdf, 2009.

[29] D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference (ATC), pages 305–320, 2014.

[30] F. Pedone and A. Schiper. Handling message semantics with Generic Broadcast protocols. Distributed Computing, 15(2):97–107, 2002.

[31] F. B. Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Comput. Surv., 22(4):299–319, 1990.

[32] S. Setty, S. Basu, L. Zhou, M. L. Roberts, and R. Venkatesan. Enabling secure and resource-efficient blockchain networks with VOLT. Technical Report MSR-TR-2017-38, Microsoft Research, 2017.

[33] A. Singh, T. Das, P. Maniatis, P. Druschel, and T. Roscoe. BFT protocols under fire. In Symposium on Networked Systems Design & Implementation (NSDI), pages 189–204, 2008.

[34] J. Sousa, A. Bessani, and M. Vukolic. A Byzantine fault- ´ tolerant ordering service for the Hyperledger Fabric blockchain platform. Technical Report arXiv:1709.06921, CoRR, 2017.

[35] B. Vandiver, H. Balakrishnan, B. Liskov, and S. Madden. Tolerating Byzantine faults in transaction processing systems using commit barrier scheduling. In ACM Symposium on Operating Systems Principles (SOSP), pages 59–72, 2007.

[36] M. Vukolic. The quest for scalable blockchain fabric: Proof- ´ of-work vs. BFT replication. In International Workshop on Open Problems in Network Security (iNetSec), pages 112– 125, 2015.

[37] J. Yin, J. Martin, A. Venkataramani, L. Alvisi, and M. Dahlin. Separating agreement from execution for Byzantine fault tolerant services. In ACM Symposium on Operating Systems Principles (SOSP), pages 253–267, 2003.

本文翻譯自：arxiv.org/pdf/1801.10… 版權歸做者全部，商業使用請聯繫做者