Hyperledger Fabric 、 Corda 和以太坊的對比

三種不同的框架

我們從 Hyperledger Fabric、R3 Corda和以太坊的白皮書中可以看到，三種框架在可能的應用領域上分別具有完全不同的想法。

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

以太坊表現出完全獨立於任何特定的應用領域 [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）是一類特殊的對等節點，任務是通過檢查自身是否滿足一些必要的和充分的條件（例如提供所需的簽名），對交易提供背書。訂購節點在客戶節點和對等節點間提供了通訊通道，用於廣播包含交易的訊息。特別是對於共識，這些通道確保了所有已連線的對等節點按照完全相同的邏輯順序傳遞完全相同的訊息。

但是問題會出現在這一點上。如果其中涉及多個互不信任的訂購節點，在傳遞訊息時可能會出現錯誤。因此，必須引入一致性演算法，使得在出現故障（例如，訊息順序不一致）時仍然可以達成一致，從而使分散式賬本的複製過程支援容錯。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