Comparison of Ethereum, Hyperledger Fabric and Corda
我们分析了 Hyperledger Fabric，R3 Corda 和以太坊这三种分布式账本技术间存在的最显著差异，目的是为决策者提供一个新的 DLT 指南，了解 Hyperledger Fabric、Corda 和以太坊的最适合用例。
本文中，我们将简要分析 Hyperledger Fabric，R3 Corda 和以太坊这三种分布式账本技术（DLT,distributed ledger technologies）间存在的最显著差异。本文的目的在于为决策者提供一个新的 DLT 指南，了解 Hyperledger Fabric、Corda 和以太坊的最适合用例。
**With this paper, we provide a brief analysis of the most notable differences between the distributed ledger technologies (DLT) Hyperledger Fabric, R3 Corda and Ethereum. Our intention is to give decision makers new to DLT guidance for what use cases Hyperledger Fabric, Corda and Ethereum are most suitable. — **Authors: Martin Valenta, Philipp Sandner
Download the article as PDF file.
三种不同的框架我们从 Hyperledger Fabric、R3 Corda（下文分别简称为 Fabric 和 Corda）和以太坊的白皮书中可以看到，三种框架在可能的应用领域上分别具有完全不同的想法。Fabric[1] 和 Corda[2] 的开发是受具体用例驱动的。其中，Corda 的用例来自于金融服务行业，这也是 Corda 可见的主要应用领域。Fabric 设计提供一种模块化、可扩展的架构，可用于从银行、医疗保健到供应链等各个行业。以太坊表现出完全独立于任何特定的应用领域 [3]。然而与 Fabric 相比，以太坊并未突出模块化，而重在为各种交易和应用提供一个通用平台。表 1 给出了三种框架的情况汇总。
表 1: 以太坊、Hyperledger Fabric 和 Corda 的对比
Table 1: Comparison of Ethereum, Hyperledger Fabric and Corda
Three different frameworks
From the white papers of Hyperledger Fabric, R3 Corda (in the following only referred to as Fabric and Corda, respectively) and Ethereum it becomes obvious that these frameworks have very different visions in mind with respect to possible fields of application. Development of both Fabric[i] and Corda[ii] is driven by concrete use cases, whereas Corda’s use cases are drawn from the financial services industry. Consequently, this is where Corda sees its main field of application. In contrast, Fabric intends to provide a modular and extendable architecture that can be employed in various industries, from banking and healthcare over to supply chains. Ethereum also presents itself as utterly independent of any specific field of application.[iii] However, in contrast to Fabric, it is not modularity that stands out but the provision of a generic platform for all kinds of transactions and applications. Table 1 provides a summary of the three frameworks.
对等端的参与在传统的集中式数据存储中，只有一个实体（即所有者）可以保留账本这一底层数据库的副本。因此，该实体控制了哪些数据可以提供，以及允许其它实体提供什么数据。DLT 的出现，从根本上改变了分布式数据存储的方式，实现了多个实体拥有底层数据库副本，自然也支持每个拷贝做出贡献。参与分布式数据存储的所有实体，形成一种由所谓“节点”或“对等端”构成的网络。由于数据是分布式存储的，因此难以确保所有节点对一些“共同事实”（例如，账本的正确性）达成一致。因为一个节点所做的更改，必须传播到网络中的所有其它的对等节点上。达成共同事实的结果，称之为节点间的“共识”(consensus)，将在下文介绍。
针对是否参与达成共识，存在两种操作模式，即无授权（permissionless）和有授权（permissioned）。如果参与无需授权，那么任何人都可以参与网络。授权模式适用于作为公共区块链的以太坊。另一方面，如果参与需授权，那么参与者是经过预先选择的，并且仅限于这些参与者访问网络。Fabric 和 Corda 都属于后者。选择无授权或有授权的参与模式，将对达成共识具有深远的影响。
Participation of peers
With conventional central data storage, only a single entity, the owner, keeps a copy of the underlying database, e.g. a ledger. Consequently, this entity controls what data is contributed and what other entities are permitted to contribute. With the advent of DLT this radically changes in favor of distributed data storage where multiple entities hold a copy of the underlying database and are naturally permitted to contribute. All entities that participate in distributed data storage form a network of so-called nodes or peers. Due to distributed data storage, the difficulty arises to ensure that all nodes agree upon a common truth, e.g. the correctness of a ledger, as changes made by one node have to be propagated to all other peer nodes in the network. The result of arriving at a common truth is called consensus among nodes and is described below.
With respect to participating to consensus, there are two modes of operation: permissionless and permissioned. If participation is permissionless, anybody is allowed to participate in the network. This mode is true for Ethereum as a public blockchain. On the other hand, if participation is permissioned, participants are selected in advance and access to the network is restricted to these only. This is true for Fabric and Corda. The mode of participation, permissionless or permissioned, has a profound impact on how consensus is reached.
共识 以太坊使用以太坊，无论参与者是否参与了某个特定的交易（Transaction），所有参与者必须就全部已发生交易的顺序达成共识。交易的顺序对账本的一致状态至关重要。如果无法建立明确的交易顺序，那么可能会出现双重支付（double-spends）问题，即两笔并行交易将同一枚货币转账给了不同的收款人，使其凭空受益。由于网络所涉及的各方可能是互不信任的，并且是匿名的，因此必须采用共识机制来保护账本免受双重支付欺诈，或者心怀鬼胎参与者的影响。在目前的以太坊实现中，这种共识机制的建立是使用基于工作证明（PoW，Proof of Work）方案的挖矿。所有参与者必须认同一个共同账本，并且可以访问账本中所有的记录条目。其结果是，PoW 会对交易的处理性能产生不利的影响 [5]。尽管记录是匿名的，但是存储在账本中的数据仍然可供所有参与者访问。因此对于有更高隐私度需求的应用而言，这种机制存在问题。
不同于以太坊，Fabric 和 Corda 给出了更精细的共识设计，不再仅仅局限于基于 PoW 或其它衍生物的挖矿。由于 Fabric 和 Corda 运行在许可模式下，因此可为记录提供更细粒度的访问控制，从而增强了隐私。此外，由于只有参与交易的各方才必须要达成共识，因此在性能上有所提高。
FabricFabric 提供了范围很广的共识理解，涵盖从将交易提交网络到将交易记录到账本的整个交易流程 [6]。此外，节点在达成共识的过程中承担了不同的角色和任务。这完全不同于以太坊，其中参与达成共识的节点具有相同的角色和任务。
Fabric 将节点区分为客户节点（Client）、对等节点（Peer）和订购节点（Orderer）[7]。客户节点代表最终用户，创建并调用交易。他们与对等节点和订购节点沟通。对等节点维护账本，并接收订购节点订购的更新消息，以向账本提交新的交易。背书节点（Endorser）是一类特殊的对等节点，任务是通过检查自身是否满足一些必要的和充分的条件（例如提供所需的签名），对交易提供背书。订购节点在客户节点和对等节点间提供了通信通道，用于广播包含交易的消息。特别是对于共识，这些通道确保了所有已连接的对等节点按照完全相同的逻辑顺序传递完全相同的消息。
Consensus
**Ethereum. **With Ethereum, all participants have to reach consensus over the order of all transactions that have taken place, irrespectively of whether a participant has taken part in a particular transaction or not. The order of the transactions is crucial for the consistent state of the ledger. If a definitive order of transactions cannot be established there is a chance that double-spends might have occurred, that is, two parallel transactions transfer the same coin to different recipients, thus making money out of thin air. As the network might involve mutually distrusting and anonymous parties, a consensus mechanism has to be employed that protects the ledger against fraudulent or adverse participants that attempt double-spends. In the current implementation of Ethereum, this mechanism is established by mining based on the proof-of-work (PoW) scheme. All participants have to agree upon a common ledger and all participants have access to all entries ever recorded. The consequences are that PoW unfavorably affects the performance of transactions processing.[v] Concerning the data stored on the ledger, even though records are anonymized, they are nevertheless accessible to all participants, which is problematic for applications that require a higher degree of privacy.
In contrast to Ethereum, Fabric’s and Corda’s interpretation of consensus is more refined and does not merely boil down to mining based on PoW or a derivative thereof. Due to operating in a permissioned mode, Fabric and Corda provide a more fine-grained access control to records and thus enhance privacy. Furthermore, a gain in performance is achieved as only parties taking part in a transaction have to reach consensus.
**Fabric. **Fabric’s understanding of consensus is broad and encompasses the whole transaction flow, starting from proposing a transaction to the network to committing it to the ledger.[vi] Furthermore, nodes assume different roles and tasks in the process of reaching consensus. This contrasts to Ethereum where roles and tasks of nodes participating in reaching consensus are identical.
Within Fabric, nodes are differentiated based on whether they are clients, *peers *or orderers.[vii] A client acts on behalf of an end-user and creates and thereby invokes transactions. They communicate with both peers and orderers. Peers maintain the ledger and receive ordered update messages from orderers for committing new transactions to the ledger. Endorsers are a special type of peer, whereas their task is to endorse a transaction by checking whether they fulfill necessary and sufficient conditions (e.g. the provision of required signatures). Orderers provide a communication channel to clients and peers over which messages containing transactions can be broadcasted. With respect to consensus in particular, the channels ensure that all connected peers are delivered exactly the same messages with exactly the same logical order.
但是问题会出现在这一点上。如果其中涉及多个互不信任的订购节点，在传递消息时可能会出现错误。因此，必须引入一致性算法，使得在出现故障（例如，消息顺序不一致）时仍然可以达成一致，从而使分布式账本的复制过程支持容错。Fabric 所采用的算法是“可插入的”，即可以根据特定应用的需求而使用各种算法。例如，为了处理如上所述的随机或恶意复制错误，我们可以使用拜占庭式容错（BFT）的一种变体算法。此外，通道划分了消息流，这意味着客户节点只能看到它们连接通道中的消息及相关联的交易，而不知道其它通道的情况。通过这种方式，对交易的访问将仅限于相关方。其结果是只能在交易层面达成共识，而不能像以太坊那样在账本层面达成共识。
上面介绍了节点，现在介绍交易流的上下文。客户节点向已连接的背书节点发送交易，启动对账本的更新。所有背书节点都必须就提出的交易达成一致，因此需要根据更新所建议的账本达成某种共识。客户节点依次收集所有背书节点的批准，然后将经批准的交易发送给已连接的订购节点，由这些订购节点再次达成共识。随后，交易将被转发给持有分类账的对等节点，以提交交易。
我们在此不再做进一步的详细介绍。很显然，Fabric 支持对共识做细粒度的控制，并提供对交易的受限访问，这提高了性能的可扩展性和隐私性。
At this point, the problem arises that there might occur faults in the delivery of messages when many mutually untrusting orderers are employed. As a consequence, a consensus algorithm has to be used in order to reach consensus despite faults, e.g. inconsistent order of messages, thus making the replication of the distributed ledger faults tolerant. With Fabric, the algorithm employed is “pluggable”, meaning that depending on application-specific requirements various algorithms can be used. For example, in order to deal with random or malicious replication faults as outlined above a variant of the Byzantine fault-tolerant (BFT) algorithms could be used. Furthermore, channels partition message flows, meaning that clients only see the messages and associated transactions of the channels they are connected to and are unaware of other channels. This way, access to transactions is restricted to involved parties only with the consequence that consensus has only to be reached at transaction level and not at ledger level as with Ethereum.
The roles of nodes outlined above are now described in the context of the transaction flow: A client sends a transaction to connected endorsers in order to initiate an update of the ledger. All endorsers have to agree upon the proposed transaction, thus some sort of consensus has to be reached regarding the proposed ledger update. The client now successively collects approval of all endorsers. The approved transaction is now sent to connected orderers which again reach consensus. Subsequently, the transaction is forwarded to peers holding the ledger for committing the transaction.
Without going further into detail, it becomes clear that Fabric allows fine-grained control over consensus and restricted access to transactions which results in improved performance scalability and privacy.
Corda类似于 Fabric，Corda 的共识也是在交易层面达成的，仅涉及交易的各方。交易取决于共识是满足交易合法性（validity），还是交易唯一性（uniqueness）[8]。交易合法性通过运行与交易相关联的智能合约代码（智能合约将在下文给出详细介绍），检查需要的所有签名，并确保所引用的任何交易也是有效的。交易唯一性涉及交易的输入状态。具体而言，必须确保有疑问的交易是所有输入状态的唯一消费者。换句话说，不存在任何消耗同一状态的其它交易。这是为了避免产生双重支付。实现交易唯一性的共识，是在称为“公证人”（Notary）[9] 的参与节点中达成的。其中使用的算法和 Fabric 一样，是“可插拔的”。因此，我们同样可以使用 BFT 算法。
**Corda. **Similar to Fabric, consensus in Corda is also reached at transaction level by involving parties only. Subject to consensus is transaction validity and transaction uniqueness[viii]. Validity is ensured by running the smart contract code (smart contracts are described in detail below) associated with a transaction, by checking for all required signatures and by assuring that any transactions that are referred to are also valid. Uniqueness concerns the input states of a transaction. Specifically, it has to be ensured that the transaction in question is the unique consumer of all its input states. In other words, there exists no other transaction that consumes any of the same states. The reason for this is to avoid double-spends. Consensus over uniqueness is reached among participants called notary[ix] nodes, whereas the employed algorithm is “pluggable” as with Fabric. So once again a BFT algorithm might be used.
智能合约在第一次接触“智能合约”（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 都不具备此功能。
Smart contracts
The term “smart contract” causes considerable misunderstanding when first encountered as it evokes the idea of some sort of contract that intelligently acts on one’s behalf. The contract’s nature, however, remains vague, but intuitively appears to be linked to legal matters. That said, focal contracts are neither smart in the sense that they are e.g. driven by artificial intelligence, at least not yet, nor do they generally encode obligations and rights that are legally binding. Clark and colleagues[x] provide a useful terminology by highlighting two different ways the term “smart contracts” is commonly used. The first refers to smart contract code, the second to smart legal contracts, two distinctions that prove to be beneficial in the context of this comparison.
Smart contract code simply denotes software written in a programming language. It acts as a software agent or delegate of the party that employed it with the intention that it fulfills certain obligations, exercises rights and may take control of assets within a distributed ledger in an automated way. Thus, it takes on tasks and responsibilities in the distributed ledger world by executing code that models or emulates contract logic in the real world, though its legal justification may be unclear.
All DLTs feature smart contracts in the sense of smart contract code that can be written in Go or Java for Fabric[xi], in Solidity[xii] for Ethereum and in Java or Kotlin for Corda[xiii]. In Fabric, the term “chaincode” is used as a synonym for smart contract. As an illustrative example, the reader is reminded of the usage of a smart contract code in the consensus mechanism of Corda in order to ensure transaction validity. However, there is a notable difference between Fabric and Ethereum on the one hand and Corda on the other that is connected to the second way the “smart contracts” term is used.
In Corda, smart contracts not only consist of code but additionally are allowed to contain legal prose. Thus above smart legal contracts are legal prose that are formulated in a way that they can be expressed and implemented in smart contract code. The rationale behind this is to give the code legitimacy that is rooted in the associated legal prose. Such a construct is called Ricardian Contract[xiv]. At this point, it again becomes clear that Corda was explicitly designed to account for the highly regulated environment of the financial services industry. Both Fabric and Ethereum lack this feature.
内建代币另一个值得注意的区别，是以太坊提供一种称为“以太”的内置加密货币。以太用于向帮助通过挖矿达成共识的节点支付奖励，并支付交易费用。因此，去中心化应用（DApps）可以基于支持货币交易的以太坊构建。此外，通过部署符合预定义标准的智能合约，可以创建为用例定制的数字代币 [15]。使用这种方式，人们可以定义自己的货币或资产。
Fabric 和 Corda 不支持通过挖矿达成共识，因此不需要内建的加密货币。但是使用 Fabric，也可以开发本地货币，或是带有区块链代码的数字代币 [16]。使用 Corda，不建议创建数字货币或代币 [17]。
总结：定制平台对比通用平台总结一下，本文中分析的 DLT 横贯东西。一方面是 Fabric 和以太坊。它们在不同的方面上具有非常大的灵活性。以太坊是一种强大的智能合约引擎，基本上可作为任何类型应用的通用平台。但是，以太坊的无授权操作模式及全面透明度，是以牺牲性能可扩展性和隐私性为代价的。Fabric 采用有授权的操作模式，即使用 BFT 算法和细粒度访问控制解决了性能可扩展性和隐私问题。此外，Fabric 的模块化体系结构使其可以针对众多应用进行定制。我们可将 Fabric 比做一个多功能的工具箱。
另一方面是 Corda。它专门设计为一种用于金融服务行业的 DLT。应注意的是，Corda 通过增加法律行文的智能合同，考虑了受高度管制的环境。
显然，与 Fabric 相比，专注于金融服务交易使 Corda 得以简化其架构设计。因此，Corda 可以提供更多的开箱即可用体验。不过，Fabric 的模块化支持定制类似于 Corda 的功能集。一些工作力图将 Corda 纳入 Hyperledger 项目。因此，不能将 Corda 视为 Fabric 的竞争对手，而更多的是一种补充。
Built-in currency
Another noteworthy difference is that Ethereum features a build-in cryptocurrency called Ether. It is used to pay rewards to nodes that contribute to reach consensus by mining blocks as well as to pay transaction fees. Therefore decentralized apps (DApps) can be built for Ethereum that allow monetary transactions. Furthermore, a digital token for custom use cases can be created by deploying a smart contract that conforms to a pre-defined standard.[xv] This way, own currencies or assets can be defined.
Fabric and Corda do not require a build-in cryptocurrency as consensus is not reached via mining. =With Fabric, however, it is possible to develop a native currency or a digital token with chaincode=.[xvi] With Corda, a creation of digital currencies or tokens is not intended.[xvii]
Summary: customized vs. generic platform
To sum up, the examined DLTs span a continuum. On the one side, there is Fabric and Ethereum. They both are highly flexible, but in different aspects. Ethereum’s powerful smart contracts engine makes it a generic platform for literally any kind of application. However, Ethereum’s permissionless mode of operation and its total transparency comes at the cost of performance scalability and privacy. Fabric solves performance scalability and privacy issues by permissioned mode of operation and specifically by using a BFT algorithm and fine-grained access control. Further, the modular architecture allows Fabric to be customized to a multitude of applications. An analogy to a versatile toolbox can be drawn.
Corda is located at the other end. It has been consciously designed as DLT for the financial services industry. Most notably, it takes the highly regulated environment into account by augmenting smart contracts with legal prose.
Apparently, Corda’s focus solely on financial services transactions simplified its architectural design compared to Fabric. Therefore, it might offer a more out-of-the-box experience. However, it might be possible that Fabric, due to its modularity, can be tailored to resemble Corda’s feature set. Efforts exist that seek to integrate Corda into the Hyperledger project. Corda therefore cannot be seen as a competitor to Fabric but more as a complement.
查看英文原文：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
[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
