Hyperledger Fabric、Corda和以太坊對比

時間 2019-11-10

標籤 hyperledger fabric corda 以太對比简体版

原文原文鏈接

Hyperledger Fabric 、 Corda 和以太坊的對比html

三種不一樣的框架

咱們從 Hyperledger Fabric、R3 Corda和以太坊的白皮書中能夠看到，三種框架在可能的應用領域上分別具備徹底不一樣的想法。git

Fabric[1] 和 Corda[2] 的開發是受具體用例驅動的。其中，Corda 的用例來自於金融服務行業，這也是 Corda 可見的主要應用領域。Fabric 設計提供一種模塊化、可擴展的架構，可用於從銀行、醫療保健到供應鏈等各個行業。github

以太坊表現出徹底獨立於任何特定的應用領域 [3]。然而與 Fabric 相比，以太坊並未突出模塊化，而重在爲各類交易和應用提供一個通用平臺。算法

對等端的參與

在傳統的集中式數據存儲中，只有一個實體（即全部者）能夠保留帳本這一底層數據庫的副本。所以，該實體控制了哪些數據能夠提供，以及容許其它實體提供什麼數據。DLT 的出現，從根本上改變了分佈式數據存儲的方式，實現了多個實體擁有底層數據庫副本，天然也支持每一個拷貝作出貢獻。參與分佈式數據存儲的全部實體，造成一種由所謂「節點」或「對等端」構成的網絡。因爲數據是分佈式存儲的，所以難以確保全部節點對一些「共同事實」（例如，帳本的正確性）達成一致。由於一個節點所作的更改，必須傳播到網絡中的全部其它的對等節點上。達成共同事實的結果，稱之爲節點間的「共識」(consensus)，將在下文介紹。數據庫

針對是否參與達成共識，存在兩種操做模式，即無受權（permissionless）和有受權（permissioned）。若是參與無需受權，那麼任何人均可以參與網絡。受權模式適用於做爲公共區塊鏈的以太坊。另外一方面，若是參與需受權，那麼參與者是通過預先選擇的，而且僅限於這些參與者訪問網絡。Fabric 和 Corda 都屬於後者。選擇無受權或有受權的參與模式，將對達成共識具備深遠的影響。編程

共識以太坊

使用以太坊，不管參與者是否參與了某個特定的交易（Transaction），全部參與者必須就所有已發生交易的順序達成共識。交易的順序對帳本的一致狀態相當重要。若是沒法創建明確的交易順序，那麼可能會出現雙重支付（double-spends）問題，即兩筆並行交易將同一枚貨幣轉帳給了不一樣的收款人，使其憑空受益。因爲網絡所涉及的各方多是互不信任的，而且是匿名的，所以必須採用共識機制來保護帳本免受雙重支付欺詐，或者心懷鬼胎參與者的影響。在目前的以太坊實現中，這種共識機制的創建是使用基於工做證實（PoW，Proof of Work）方案的挖礦。全部參與者必須認同一個共同帳本，而且能夠訪問帳本中全部的記錄條目。其結果是，PoW 會對交易的處理性能產生不利的影響 [5]。儘管記錄是匿名的，可是存儲在帳本中的數據仍然可供全部參與者訪問。所以對於有更高隱私度需求的應用而言，這種機制存在問題。網絡

不一樣於以太坊，Fabric 和 Corda 給出了更精細的共識設計，再也不僅僅侷限於基於 PoW 或其它衍生物的挖礦。因爲 Fabric 和 Corda 運行在許可模式下，所以可爲記錄提供更細粒度的訪問控制，從而加強了隱私。此外，因爲只有參與交易的各方纔必需要達成共識，所以在性能上有所提升。架構

Fabric

Fabric 提供了範圍很廣的共識理解，涵蓋從將交易提交網絡到將交易記錄到帳本的整個交易流程 [6]。此外，節點在達成共識的過程當中承擔了不一樣的角色和任務。這徹底不一樣於以太坊，其中參與達成共識的節點具備相同的角色和任務。框架

Fabric 將節點區分爲客戶節點（Client）、對等節點（Peer）和訂購節點（Orderer）[7]。客戶節點表明最終用戶，建立並調用交易。他們與對等節點和訂購節點溝通。對等節點維護帳本，並接收訂購節點訂購的更新消息，以向帳本提交新的交易。背書節點（Endorser）是一類特殊的對等節點，任務是經過檢查自身是否知足一些必要的和充分的條件（例如提供所需的簽名），對交易提供背書。訂購節點在客戶節點和對等節點間提供了通訊通道，用於廣播包含交易的消息。特別是對於共識，這些通道確保了全部已鏈接的對等節點按照徹底相同的邏輯順序傳遞徹底相同的消息。less

可是問題會出如今這一點上。若是其中涉及多個互不信任的訂購節點，在傳遞消息時可能會出現錯誤。所以，必須引入一致性算法，使得在出現故障（例如，消息順序不一致）時仍然能夠達成一致，從而使分佈式帳本的複製過程支持容錯。Fabric 所採用的算法是「可插入的」，便可以根據特定應用的需求而使用各類算法。例如，爲了處理如上所述的隨機或惡意複製錯誤，咱們可使用拜占庭式容錯（BFT）的一種變體算法。此外，通道劃分了消息流，這意味着客戶節點只能看到它們鏈接通道中的消息及相關聯的交易，而不知道其它通道的狀況。經過這種方式，對交易的訪問將僅限於相關方。其結果是隻能在交易層面達成共識，而不能像以太坊那樣在帳本層面達成共識。

上面介紹了節點，如今介紹交易流的上下文。客戶節點向已鏈接的背書節點發送交易，啓動對帳本的更新。全部背書節點都必須就提出的交易達成一致，所以須要根據更新所建議的帳本達成某種共識。客戶節點依次收集全部背書節點的批准，而後將經批准的交易發送給已鏈接的訂購節點，由這些訂購節點再次達成共識。隨後，交易將被轉發給持有分類帳的對等節點，以提交交易。

咱們在此再也不作進一步的詳細介紹。很顯然，Fabric 支持對共識作細粒度的控制，並提供對交易的受限訪問，這提升了性能的可擴展性和隱私性。

Corda

相似於 Fabric，Corda 的共識也是在交易層面達成的，僅涉及交易的各方。交易取決於共識是知足交易合法性（validity），仍是交易惟一性（uniqueness）[8]。交易合法性經過運行與交易相關聯的智能合約代碼（智能合約將在下文給出詳細介紹），檢查須要的全部簽名，並確保所引用的任何交易也是有效的。交易惟一性涉及交易的輸入狀態。具體而言，必須確保有疑問的交易是全部輸入狀態的惟一消費者。換句話說，不存在任何消耗同一狀態的其它交易。這是爲了不產生雙重支付。實現交易惟一性的共識，是在稱爲「公證人」（Notary）[9] 的參與節點中達成的。其中使用的算法和 Fabric 同樣，是「可插拔的」。所以，咱們一樣可使用 BFT 算法。

智能合約

在第一次接觸「智能合約」（smart contract）一詞時，人們不免會產生至關大的誤解，將其理解爲某種智能地表達了某人利益的合約。儘管合約的本質仍然存在含糊不清之處，可是在直觀上它彷佛應與法律有關。也就是說，咱們所關注的合約在本意上並不是智能的，至少目前仍還沒有由人工智能驅動，也還沒有在其中編入具備法律約束力的義務和權利。Clark 及其同事 [10] 在給出「智能合約」這一有用術語時，強調指出了該術語的兩種不一樣的經常使用方式。第一種方式是智能合約代碼（smart contract code），另外一種方式是智能法律合約（smart legal contracts）。本文着重介紹二者間的區別。

智能合約代碼就是用某種編程語言編寫的軟件。它做爲一個軟件代理，或是表明其中某一方，目的是履行某些義務、行使某些權利，並以自動的方式控制分佈式帳本中的資產。所以，智能合約經過代碼執行模擬，或模擬現實世界中合約邏輯，承擔了分佈式帳本的任務和責任，儘管其合法性可能還沒有明確。

全部的 DLT 都支持以智能合約代碼的形式履行智能合約。代碼可使用 Go、Java for Fabric [11]、Solidity[12] for Ethereum，以及 Java/Kotlin for Corda [13] 編寫。在 Fabirc 中使用了術語「鏈碼」（chaincode），以此做爲智能合約的同義詞。舉例說明，Corda 爲確保交易的有效性，會提醒讀者在共識機制中使用智能合同代碼。一方面，Fabric 和 Ethereum 之間存在着顯著的差別。另外一方面，這是與 Corda 使用另外一種「智能合約」方式相關。

在 Corda 中，智能合約不只能夠包含代碼，還容許包含法律行文（Legal Prose）。所以，上述智能法律合約是法律行文，其制定方式能夠經過智能合同代碼來表達和實施。其背後的基本原理，是賦予植根於相關法律行爲的代碼以合法性。這種結構稱爲「Ricardian 合約」[14]。這清晰地代表，Corda 是設計用於金融服務行業這一受嚴格監管的環境。而 Fabric 和 Ethereum 都不具有此功能。

代幣

另外一個值得注意的區別，是以太坊提供一種稱爲「以太」的內置加密貨幣。以太用於向幫助經過挖礦達成共識的節點支付獎勵，並支付交易費用。所以，去中心化應用（DApps）能夠基於支持貨幣交易的以太坊構建。此外，經過部署符合預約義標準的智能合約，能夠建立爲用例定製的數字代幣 [15]。使用這種方式，人們能夠定義本身的貨幣或資產。

Fabric 和 Corda 不支持經過挖礦達成共識，所以不須要內建的加密貨幣。可是使用 Fabric，也能夠開發本地貨幣，或是帶有區塊鏈代碼的數字代幣 [16]。使用 Corda，不建議建立數字貨幣或代幣 [17]。

總結：定製平臺對比通用平臺

一方面是 Fabric 和以太坊。它們在不一樣的方面上具備很是大的靈活性。以太坊是一種強大的智能合約引擎，基本上可做爲任何類型應用的通用平臺。可是，以太坊的無受權操做模式及全面透明度，是以犧牲性能可擴展性和隱私性爲代價的。Fabric 採用有受權的操做模式，即便用 BFT 算法和細粒度訪問控制解決了性能可擴展性和隱私問題。此外，Fabric 的模塊化體系結構使其能夠針對衆多應用進行定製。咱們可將 Fabric 比作一個多功能的工具箱。

另外一方面是 Corda。它專門設計爲一種用於金融服務行業的 DLT。應注意的是，Corda 經過增長法律行文的智能合同，考慮了受高度管制的環境。

顯然，與 Fabric 相比，專一於金融服務交易使 Corda 得以簡化其架構設計。所以，Corda 能夠提供更多的開箱便可用體驗。不過，Fabric 的模塊化支持定製相似於 Corda 的功能集。一些工做力圖將 Corda 歸入 Hyperledger 項目。所以，不能將 Corda 視爲 Fabric 的競爭對手，而更多的是一種補充。

查看英文原文：https://medium.com/@philippsandner/comparison-of-ethereum-hyperledger-fabric-and-corda-21c1bb9442f6

參考文獻：

[1] https://docs.google.com/document/d/1Z4M_qwILLRehPbVRUsJ3OF8Iir-gqS-ZYe7W-LE9gnE/pub

[2] https://docs.corda.net/_static/corda-introductory-whitepaper.pdf

[3] https://github.com/ethereum/wiki/wiki/White-Paper

[4] e.g. https://github.com/jpmorganchase/quorum

[5] Vukolić M. (2016). The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication, in: Camenisch J., Kesdoğan D. (eds.) Open Problems in Network Security, iNetSec 2015, Lecture Notes in Computer Science, Vol. 9591, Springer.

[6] https://hyperledger-fabric.readthedocs.io/en/latest/fabric_model.html#consensus

[7] https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md

[8] https://docs.corda.net/key-concepts-consensus.html

[9] https://docs.corda.net/key-concepts-notaries.html

[10] http://arxiv.org/abs/1608.00771

[11] http://hyperledger-fabric.readthedocs.io/en/latest/chaincode.html

[12] http://solidity.readthedocs.io/en/latest/

[13] https://docs.corda.net/tutorial-contract.html

[14] http://iang.org/papers/ricardian_contract.html

[15] https://www.ethereum.org/token

[16] https://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html#chaincode-smart-contracts-and-digital-assets

[17] https://discourse.corda.net/t/mobile-consumer-payment-experiences-with-corda-on-ledger-cash/966?source_topic_id=962