Hyperledger Fabric、Corda和以太坊对比

 

 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