区块链vs分布式数据库：二分法和融合
摘要
区块链已经走过了漫长的道路——一个最初专门为加密货币提出的系统，现在被调整和采用为一个通用的交易系统。随着区块链演变成另一个数据管理系统，自然的问题是它与分布式数据库系统的比较。关于这种比较的现有工作集中在高级别属性上，如安全性和吞吐量。他们没有显示底层设计的选择是如何促成整体差异的。我们的工作填补了这一重要空白，为分析区块链-数据库融合的新兴趋势提供了一个原则性框架。我们将区块链和分布式数据库系统作为两种类型的交易系统进行了孪生研究。我们提出了一个分类法，说明了四个维度的二分法，即复制、并发、存储和分片。在每个维度中，我们讨论了设计选择如何由两个目标驱动：区块链的安全性和分布式数据库的性能。为了揭示不同设计选择对整体性能的影响，我们对两个区块链，即Quorum和Hyperledger Fabric，以及两个分布式数据库，即TiDB和etcd，进行了深入的性能分析。最后，我们提出了一个用于区块链-数据库混合体的后台性能预测的框架
1 介绍
第一个区块链系统，即比特币，是一个记录加密货币交易的去中心化的账本。该账本由多个区块组成，用加密的哈希指针链在一起，每个区块包含多个交易。这个区块链分布在一个节点网络中，其中一些节点以拜占庭（或恶意）的方式行事。该网络运行一个共识协议，即工作证明（PoW），以保持账本在各节点之间的一致性。比特币是第一个在拜占庭点对点（P2P）环境中运行的数字货币（或加密货币）系统，不依赖共同的可信第三方。但它只能执行简单的交易，将一些硬币从一个地址（或用户）转移到另一个地址。最近的区块链，如Ethereum和Hyperledger Fabric支持通用交易。关键的促成因素是智能合约——由区块链中所有节点执行的用户定义的计算。通过智能合约，区块链可以执行迄今为止几乎完全由数据库处理的交易性工作负载。换句话说，区块链已经演变成了交易管理系统，因此可以与分布式数据库相媲美。与后者相比，它们的优势包括数据透明度和防止拜占庭式故障的安全性。事实上，许多公司和政府机构正在探索区块链，以取代或补充他们的企业级数据库。
区块链和分布式数据库之间的平行关系并非没有被注意到。现有的工作表明，两者之间没有什么相似之处。当应用程序运行在不信任的敌对环境中时，区块链是适合的，而当性能比安全更重要时，数据库则适合。它们的区别因性能上的巨大差距而进一步加剧，例如，比特币每秒处理约10个交易，而etcd--一个最先进的分布式NoSQL数据库--每秒处理超过50，000个操作。
另一方面，我们注意到数据库和区块链之间设计融合的趋势。传统上由数据库使用的设计原则和技术正在被区块链采用。例如，归属于数据库的并发控制技术被用来提高区块链的性能。此外，分片也被用来扩大许可区块链的规模。同时，区块链的安全特性被用于混合区块链-数据库系统，以提供可验证的数据。
比较区块链和数据库的现有作品的一个局限性是，它们只关注应用层面的、可观察和可测量的属性，如吞吐量和安全性。特别是，他们展示了这两类系统的不同之处，而没有确定其根本原因。例如，BLOCKBENCH比较了三个私有区块链，即Hyperledger Fabric、Ethereum和Parity，与H-Store在两个流行的数据处理工作负载下进行比较。作者揭露了性能上的巨大差距，但没有提供对该差距的进一步分析。因此，所报告的差异并不能推广到实验中使用的两个工作负载之外。例如，在高争论的工作负载下，性能差异可能会急剧缩小。
为了克服这些限制，我们旨在提供一个全面的区块链和数据库的二分法。我们的方法是将它们定位在同一设计空间内，即一般交易系统的设计空间。我们提出了一个由四个设计维度组成的分类法，并讨论了这两类系统如何在每个维度上做出不同的设计选择。第一个维度是复制，它决定了哪些数据被复制到哪些节点，以及保持复制体一致所需的机制。第二个维度是并发性，它决定了在执行并发事务时性能和正确性之间的权衡。第三是存储，它决定了数据模型和访问方法。最后一个维度是分片，它决定了数据如何被分割，以及跨分片事务的原子性机制。
我们分类法中的四个维度抓住了区块链和数据库之间的基本相似性。此外，它们对整体性能的影响是可以衡量的，因此这些维度形成了一个框架，用于在这些系统之间进行精细的、量化的比较。我们通过应用它来比较最近的混合数据库-区块链系统的性能，来证明我们的分类法在实践中是有用的。
综上所述，我们在本文中做出了以下贡献：
- 我们将区块链和分布式数据库作为两种不同类型的分布式交易系统进行比较。我们提出了一个新的分类法，沿着四个设计维度来描述这两类系统及其混合体：复制、并发、存储和分片。
- 我们对四个流行的系统进行了全面的性能研究，包括两个许可的区块链，即Fabric[10]和Quorum[16]，以及两个数据库系统，即TiDB[18]和etcd[7]。结果证明了不同的设计选择对性能的影响。
- 我们使用我们的分类法来分析新兴混合区块链-数据库系统的安全性和性能。我们提出了一个框架，解释它们的性能差异，并估计未来混合鸟系统的性能。
第2节提供了相关的背景，然后在第3节对上述四个方面进行了定性比较。第4节和第5节分别讨论了实验设置和结果。第6节回顾了相关的工作，第7节是结论。
2 背景
在本节中，我们讨论了区块链和分布式数据库的相关背景。图1显示了一个高级别的比较。
从这幅图可以看出来，分布式数据库与区块链相比，他的性能更好，但是安全性没有区块链好。而有权限的区块链与没有权限的区块链相比，有权限的区块链显示出更好的性能，但是安全性没有无权限的好
2.1 区块链
从数据结构的角度来看，区块链是一个由加密哈希指针链接的区块列表。这些区块包含加密货币交易[65]。根据这个定义，区块链是一个记录交易的不可篡改的账本。通过智能合约，交易是以合约部署和调用的形式进行的。从系统的角度来看，区块链是一个由多个节点组成的分布式系统，其中一些节点是恶意的。这些节点通过使用拜占庭容错（BFT）共识协议，如PoW或PBFT[36]，维持一个一致的账本。
在早期的设计中，区块链交易仅限于加密货币，并且状态被建模为未花费的交易输出（UTXO）。例如，比特币[65]和其他类似的altcoin使用UTXO模型。从以太坊[8]开始，区块链支持智能合约，允许用户在账本上编码和执行任意的图灵完备计算。账本状态被建模为账户而不是UTXO。其他支持智能合约的系统包括Quorum、Parity和Hyperledger Fabric[24]。在这些系统中，账本上的交易是以合约调用的形式进行的。交易根据其在账本中的顺序，依次修改系统状态，由共识协议决定。任何节点都可以进行只读交易，而不需要经过共识并被纳入账本。我们在本文中只考虑支持智能合约的区块链，因为早期的区块链（没有智能合约）不能支持数据库交易工作负载，因此不能与分布式数据库进行比较。
无权限与有权限。区块链可以大致分为两类：无权限（或公共），和有权限（或私有）。在前者中，例如在比特币和以太坊，任何节点和用户都可以以假名的方式加入系统。在后者中，例如在Fabric和Quorum中，节点和用户必须经过授权才能加入系统。由于有强大的成员控制和行动监管，许可的区块链更适合企业应用，尤其是在金融领域的应用。图1显示了区块链的安全性能权衡。它强调了无许可区块链如何实现更强的安全性，因为它们不做身份假设。相比之下，有许可的区块链由于身份假设，安全性较弱，但可以实现更高的性能，因为它们可以采用效率更高的共识协议。关于无许可区块链与有许可区块链设计的更详细的讨论，可以在以下文章中找到。
2.2 分布式数据库
与区块链不同，数据库系统已经存在了几十年。关系型数据库，支持易于使用的SQL语言和直观的ACID交易语义，多年来一直是主流。最近，大数据处理的需求和摩尔定律正在达到其极限的事实是扩展数据库设计趋势的主要因素。现在，数据和计算都分布在多个节点上，以实现高可用性和可扩展性。设计和扩展分布式数据库的原则和技术在[68]中有详细描述。基本上，在这个新的分布式设计方向下，有两个独特的运动，即NoSQL和NewSQL。
NoSQL与NewSQL。 为了实现可扩展性，许多分布式数据库放弃了复杂的关系模型和强ACID语义。这些系统被称为NoSQL。它们支持更灵活的数据模型和更弱的一致性。在CAP定理[51]的意义上，这些NoSQL系统为了可用性而牺牲了一致性。他们支持的各种数据模型包括键值存储（如Redis[35]、etcd[7]）、文档存储（如CouchDB[23]）、图存储（如Neo4J[80]）、面向列（如Cassandra[56]）等等。最宽松的一致性模型是最终一致性，它对读写操作的顺序没有任何保证。在最终一致性和强一致性之间，研究人员探索了各种其他的抽象概念，如顺序、因果和PRAM一致性。为了便于推理，他们对允许的操作行为进行了标准化。大多数NoSQL数据库提供可配置的选项，用户可以在性能和一致性之间进行权衡。
然而，NoSQL系统的激增并没有掩盖可用性的代价和应用复杂性的增加。一类新的分布式数据库系统，称为NewSQL，旨在恢复关系模型和ACID语义，而不牺牲很多可扩展性。自从Google推出第一个NewSQL系统Spanner[40]后，NewSQL就引起了人们的关注。紧随其后的是一些数据库供应商，如CockroachDB[5]和TiDB[18]。在本文中，我们同时考虑NoSQL和NewSQL系统。
3 分类法
表1比较了分布式数据库和区块链在我们分类法中每个维度下的设计选择。
| 区块链 | 分布式数据库 | |
|---|---|---|
| 复制 | 事务复制；拜占庭式容错共识：PBFT、PoW等 | 状态复制；崩溃容错的共识：Raft, Paxos等 |
| 并发 | 线性执行 | 并发执行 |
| 存储 | 仅适用于分类账的抽象；认证的数据结构：Merkle Tree等 | 直接访问，无需历史查询；注重硬件的指数：PSL、FAST等。 |
| 分片 | 节点感知的分片形成；基于2PC和BFT的复制 | 工作负载感知的分片形成；带有集中协调器的2PC |
3.1 复制
复制是将数据的副本存储在称为副本的多个节点上的技术。这种系统的关键挑战是在故障情况下确保一致性。在这一节中，我们通过它们复制的内容、它们如何保持副本的一致性以及它们的故障模型来描述区块链和分布式数据库的特点。
3.1.1 复制模型
复制的单位可以是交易或读/写操作。图2显示，区块链复制的是交易的有序日志（或账本）。分布式数据库在存储的基础上复制读写操作的有序日志。数据库中的节点对交易逻辑视而不见，因为它们一次只看到一个操作。这种模式的一个后果是，协调交易执行的交易经理必须被信任。相比之下，区块链没有这样受信任的实体，因此它复制了整个交易，使其执行可以由每个参与节点重放。
通过复制交易，账本包含应用层面的信息，如交易背景、客户端签名、执行时间戳等，使得交易验证变得容易。由于这种可验证性，区块链经常被用作相互不信任的各方的数据和计算平台。另一方面，复制存储操作意味着可以有更多的并发性，因为操作可以按不同的顺序复制，但对存储的影响是一样的。
3.1.2 复制方法
有两种主要的方法来维持副本之间的一致性。第一种是主-备份，它将一个副本作为主副本，将其状态与备份副本同步。这被许多数据库所采用。例如，Replex[77]使用链式复制。Cassandra[56]使用客户端作为主副本来同步复制。
第二种方法是状态机复制，它基本上是在每个副本上维护一个有序的操作/交易日志。每个副本从相同的初始状态开始，然后以相同的顺序应用日志中的操作/交易。许多系统使用共识协议，如Paxos[58]、Raft[67]和PBFT[36]，以使副本在有序日志上达成一致。例子包括Quorum [16], TiDB [18], Spanner [40]。与主备份相比，共识协议通过引入视图变化，实现了自动主故障切换。也就是说，当进度停止时，复制体可以共同同意进入一个新的纪元/视图，在那里选出一个新的主节点。除了共识之外，其他系统依赖于提供分布式共享日志抽象的外部服务，如Kafka[13]和Corfu[27]。操作/交易被附加到日志中，而副本作为日志的客户，独立地应用它们。共享日志系统的例子包括Fabric [10], Hyder [30], 和Tango [28].
主备协议比较简单，在状态较小且没有故障的情况下，可以比状态机复制的性能更好。例如，链式复制协议可以比共识协议更均匀地将网络成本分散到各个副本中，而且它可以实现更好的读取性能[77]。在没有故障的情况下，基于共享日志的系统有望比基于共识的系统表现更好。这是因为共享日志将排序与状态复制解耦，因此它可以被优化为具有高吞吐量。此外，虽然共识协议的吞吐量随着复制的增加而减少，但共享日志系统的吞吐量预计将保持不变，直到日志消费者的数量超过日志生产者的能力[27]。
3.1.3 故障模型
复制协议很复杂，因为它们需要在故障情况下保持一致性。在崩溃故障模型下，节点只因崩溃而失效，协议需要容忍硬件和软件的故障。在拜占庭失败模型下，节点任意失败，协议需要容忍任何软件和硬件的失败，以及任何恶意的行为。这个模型适合于实现安全，因为它考虑了完全破坏系统中一些节点的攻击。
节点故障模型的一个正交维度是网络假设。当网络延迟有界且已知时，网络是同步的。当网络延迟是无界的时候，它是异步的。在同步网络模型下，容忍崩溃故障或CFT的协议需要f+1个副本来容忍f个故障[33]，而在异步网络模型下需要2f+1个副本[67, 58]。容忍拜占庭故障的协议，即BFT，在同步和异步网络模型下，分别需要2f+1和3f+1个副本来容忍f个故障[36, 87, 32]。
数据库假设为崩溃故障模型，因为它们被认为是内部系统，不会受到安全攻击。例如，Spanner[17]使用Paxos[57]，一个CFT协议。授权区块链支持两种故障模型。例如，Quorum为CFT协议的Raft[67]和BFT协议的IBFT提供实现。这些系统允许应用程序在安全性和性能之间做出不同的权衡。另一方面，公共区块链无处不在地采用BFT协议，因为它们允许任何节点进入系统。特别是，PoW协议经常被使用，因为它们解决了公共设置中的一个基本问题：一个节点可以有很多身份。在PoW中，一个节点解决计算难题的概率，从而达成共识并获得奖励，与它的物理资源成正比，而物理资源是很难被伪造的。
在异步网络和故障情况下，FLP定理[49]排除了任何可以同时实现安全和活泼的确定性共识协议。公共区块链选择了有效性而不是安全性，这意味着系统在网络分区下仍然是可用的，但这些分区可能会出现分歧，而分歧的形式是分叉。这里，可用性指的是系统的行为，即新的区块被追加到账本上。个人交易可能会被审查，并被排除在区块链之外。
PoW协议的吞吐量低，主要是由于资源要求[46]。CFT协议比BFT协议有更好的性能，因为前者会产生O(N)网络成本，而后者会产生O(N^2)，其中N是节点数。因此，BFT协议不能扩展到大量的节点，其性能对规模化的网络条件更加敏感。具体来说，当N很大时，BFT协议更有可能进入视图变化--这是协议中更换当前领导者的昂贵阶段。
3.2 并发
并发指的是事务在同一时间执行的程度。有两种选择：交易要么串行（或顺序）执行，要么并发执行。大多数区块链只支持串行执行，而分布式数据库采用复杂的并发控制机制，以尽可能多地提取并发性。
区块链缺乏对并发性的支持背后有两个原因。首先，串行执行可能不会影响整体性能，因为交易执行往往不是瓶颈[46]。例如，在比特币中，共识协议可能需要几分钟才能完成，这是协议要求的区块间隔，而交易执行，即调用比特币脚本来验证加密流，可以在几毫秒内完成。其次，串行执行意味着当交易执行在许多节点上复制时，智能合约的行为是确定性的。确定性的好处是，很容易对账本的状态进行推理。
与区块链不同，并发性仍然是数据库的一个主要研究课题，因为它是性能改进的主要来源。提取并发性的挑战是确保并发性执行的正确性。事实上，存在着广泛的隔离级别[38, 26]，它们在正确性和性能之间做出了不同的权衡。今天，大多数生产级数据库都提供了一个以上的隔离级别。
我们观察到，最近的区块链正在采用一些在数据库中常见的简单并发技术。例如，在Hyperledger Fabric中，交易在被送去排序之前，会针对账本状态进行并行模拟（执行）。在后来的提交阶段，系统使用一个简单的乐观的并发控制来实现可序列化，中止模拟状态过期的交易。也有人提出了更成熟的技术来减少中止[74, 71]。
3.3 存储
3.3.1 存储模型
存储可以只建立在最新的状态上，可以进行变异，也可以建立在所有的历史信息上，可以进行追加。分布式数据库的存储只暴露了对最新记录的直接访问。在没有明确的出处支持的数据库中，历史数据以有限的形式被维护，例如，作为先写日志。我们注意到，这种日志主要用于故障恢复，而且会定期修剪。区块链，除了状态存储外，还暴露了一个仅适用于分类帐的抽象概念。账本是一个区块链，记录历史交易和对全局状态的改变。我们注意到，这样的账本是受哈希保护的，以保持历史的完整性。一些区块链允许应用程序只访问最新的状态，例如，Hyperledger Fabric v0.6。最近，有人提出了新的区块链定制的存储系统，以便在智能合约执行期间能够访问任何历史状态[70]。
3.3.2 索引
索引在状态存储中发挥着重要作用，以促进数据访问。除了性能方面的考虑外，一些面向安全的系统还依靠索引来计算摘要，从而唯一地识别状态内容。分布式数据库更关注性能，也就是说，索引上的任何小的优化都可以转化为性能上的显著改善。现代索引被设计成具有硬件意识的，以便从硬件中获取最大的效率。例如，内存数据库放弃了对磁盘友好的B树结构，而采用其他结构，如FAST[54]和PSL[84]，这些结构是为更好地利用缓存和多核并行而设计的。
为了计算内容唯一的摘要，区块链采用了一个认证的数据结构，如Merkle树索引，以提供状态存储之上的完整性保护。例如，Ethereum使用了一个前缀三角，名为Merkle Patricia Trie（MPT）[14]。在MPT中，状态被存储在叶子中。具有共同密钥前缀的状态被组织在同一分支下。每个节点都与它在存储引擎中的内容的加密哈希值相关联，这样，根哈希值代表了完整的全局状态。访问路径作为检索值的完整性证明。Hyperledger Fabric的旧版本使用Merkle Bucket Tree（MBT），其中树的大小是固定的。与区块链中无处不在的分类账抽象不同，我们注意到并非所有的区块链都采用了状态组织的认证数据结构。例如，Hyperledger Fabric从版本1开始就放弃了这种设计。
3.4 分片
分片是分布式数据库中实现可扩展性的一种常见技术，其中数据被分割成多个分片。虽然它在数据库中被广泛研究，但分片技术最近才被引入到区块链中，以利用跨分片的并发性。在本节中，我们将讨论任何分片系统的两个关键挑战，即（i）如何形成分片，以及（ii）如何确保跨分片交易的原子性。
3.4.1 分片形成
分片形成协议决定了哪些节点和数据会进入哪个片区。区块链的安全性取决于故障数量低于某个阈值的假设。因此，分片形成协议必须确保该假设对每个分片都成立。特别是，分片的规模必须足够大，这样拜占庭节点的比例才会小。此外，攻击者必须不能影响分片的分配，否则，它可以为一个分片保留足够的资源来打破安全假设。目前最先进的分片区块链有不同的方法。例如，Elastico使用PoW来形成分片[61]，而最近版本的Ethereum使用Proof-of-Stake来为每个分片选择验证人[9]。OmniLedger[55]采用了复杂的加密协议，而AHL[42]则使用可信硬件。这些协议对Sybil攻击是安全的，并以分片重构的形式定期执行，以防范适应性攻击者。
分布式数据库中分片的目标是可扩展性。因此，这些系统旨在以优化某些工作负载性能的方式将数据分配给分片。在实践中，它们提供了多种分区方案，例如哈希分区和范围分区，这样用户就可以选择最适合其工作负载的方案。有些系统，例如Cassandra[56]，甚至允许用户指定工作负载的分布，这样数据就可以以局部感知的方式进行分区。与区块链不同，数据库没有必要进行分片重构，除非当工作负载分布发生重大变化时。
3.4.2 原子性
当一个事务触及多个分片中的数据时，分片引入了事务原子性的问题。原子性要求一个跨分片的事务在所有分片中要么提交，要么中止。在数据库中，这个问题是由两阶段提交（2PC）协议解决的。这个协议需要一个专门的交易协调人，这个协调人必须是可信的，但是可能会失败，使交易永远被阻塞。最近的一项工作提出了平行提交，将提交时间减少到一次往返[76]。
分片区块链在确保原子性方面面临额外的挑战，因为在拜占庭失败模型下，协调者是不可信的。为了克服这个问题，Eth2引入了一个单独的运行Casper共识的链[34]，称为Beacon Chain，协调跨区块的交易[9]。同样，[42，52]提出将2PC协调器作为运行BFT协议的分片中的一个状态机来实现。BFT协议确保分片区不容易受到攻击，不会成为故障点。任何跨分片的交易必须涉及这个2PC BFT复制的状态机，以确保原子性。共识的有效性保证了协调者的高可用性，因此缓解了阻塞问题。但区块链中的拜占庭设置给2PC过程带来了相当大的开销。
3.5 区块链和数据库的融合
上述分类法对分布式交易系统的设计空间进行了全面描述。这个分类法有助于说明区块链和分布式数据库之间的相似性和差异。它还可以作为理解最近出现的混合区块链-数据库系统的原则性框架。在本节中，我们讨论了这些系统如何融入设计空间。我们在第5.6节对它们的性能进行了深入的分析。
区块链外的数据库。 实现混合设计的一种方法是以区块链（或类似区块链的系统）为起点，在其上建立数据库功能。这种方法的例子包括BlockchainDB[47]、Veritas[22]和FalconDB[69]，它们为多个不信任方提供共享和可验证的数据库。他们使用区块链作为完整性保护的存储，并在其上建立其他数据库组件。在这些系统中，复制是交易无关的，有重复的状态、日志和元数据。BlockchainDB复制存储操作，并使用PoW来达成共识。它继承了底层区块链的认证状态组织，并采用了多个区块链进行存储。因此，它适合于分片。然而，交易在每个分片内是按顺序执行的。FalconDB和Vertias也采用了基于存储的复制，但分别使用Tendermint[32]来达成共识和Kafka[13]作为共享日志。它们使用与Fabric类似的乐观并发控制机制。FalconDB将验证任务外包给IntegriDB[91]，这使得一个轻量级的客户端能够在不持有整个分类账的情况下产生证明。Veritas依靠可信的验证器来保证状态的完整性。
数据库外的区块链。另一种混合设计方法是以数据库为起点，然后在其中加入区块链功能。这种方法的例子包括BigchainDB[62]、区块链关系型数据库（BRD）[66]和ChainifyDB[72]。在这些系统中，每个节点都有自己的数据库，并根据通过共识实现的全球秩序在其数据库上执行交易。这些系统采用了基于交易的复制模型，其中账本作为一个安全的共享日志来存储交易。各节点执行相同的交易序列，但在不同的本地数据库上。特别是，BRD使用PostgreSQL[75]，交易包含存储程序的调用上下文。BigchainDB使用MongoDB[15]，因此其交易是JSON格式。ChainifyDB允许异构的关系型数据库，交易是标准化的SQL语句的形式。ChainifyDB使用Kafka代理来共享日志以提高效率。相比之下，BigchainDB使用Tendermint共识协议，以牺牲性能为代价容忍拜占庭式故障。BRD联合使用Kafka[13]和BFT-MaRt[31]，这是PBFT的一个实现。这些系统继承了其底层数据库的并发支持，并根据分类账的顺序提供可序列化的约束。然而，这些系统没有用Merkle树来保护本地状态，而只是依赖于分类帐的完整性保护。最后，这些系统不支持分片。
总之，数据库外的区块链保留了分布式数据库的许多设计选择，因为它们的主要目标是性能。相比之下，数据库外的区块链数据库继承了许多区块链的特征，因为它们更受安全驱动。一些集中式和云中数据库也从区块链中学习，依靠散列链进行可验证的交易。例如Spitz[90]、QLDB[2]和LedgerDB[86]。一些系统在类似账本的结构上提供了量身定制的优化，如LogBase[79]。
3.6 讨论
表2总结了一些有代表性的交易系统和他们基于我们提出的分类法的设计选择。我们只考虑具有通用智能合约的区块链和具有键值数据模型的NoSQL数据库。我们在定量分析中排除了无权限区块链，因为它们的安全性能权衡已经得到了广泛的研究[50]。从表2可以看出，混合系统，就像有权限的区块链一样，与区块链共享一些面向安全的设计选择和一些面向性能的设计选择。
4 实验设置
4.1 系统
我们选择了四个代表系统：两个许可区块链，即Quorum[16]和Hyperledger Fabric[10]，以及两个分布式数据库，即TiDB[18]和etcd[7]。Quorum代表订单-执行的区块链，而Fabric代表执行-订单-验证的区块链。它们还采用了不同的复制方法，如图3所示。Fabric采用了一个外部订购服务，而Quorum则依靠Raft共识。Quorum是geth的一个分叉，是以太坊的Golang实现。Quorum用一个CFT协议，即Raft，和一个名为伊斯坦布尔BFT（IBFT）的BFT协议取代了以太坊最初的工作证明（PoW）。然而，它继承了以太坊虚拟机（EVM）来调用智能合约。Fabric的特点是其模块化设计。特别是，一个节点的角色被分离成订购者和对等人，详见图3b。
TiDB[18]和etcd[7]分别代表NewSQL和NoSQL分布式数据库。TiDB由三个独立的模块组成，即协调集群管理的Placement Driver，作为复制键值存储的TiKV，以及以无状态方式解析和调度SQL查询的TiDB-server。TiDB只支持快照隔离。Etcd提供了一个简单的键值数据模型，具有宽松的交易限制，但侧重于可用性和一致性之间的权衡。与区块链类似，etcd采用了一个单一的共识实例来对所有的请求进行排序。在没有分片的情况下，etcd在每个节点上完全复制了数据。我们还对CockroachDB[5]，另一个NewSQL数据库进行了基准测试。由于它表现出与TiDB类似的性能趋势，我们决定在本文中略去它。
4.2 设置
为了进行公平的比较，我们在完全复制模式下运行所有的系统，每个节点都有一个完整的状态副本。特别是，对于Fabric来说，背书策略被设定为一个交易被执行并被所有对等体背书。对于TiDB，我们将复制系数设置为与节点数量相同。换句话说，即使TiDB将数据分割到多个分片，并分别管理这些分片，每个节点都有整个系统状态的副本。我们将Quorum和Fabric配置为使用Raft，一个CFT共识。对于Fabric，我们将订购者的数量固定为三个，同时扩展对等体。对于TiDB，我们将其所有模块的规模与节点的数量挂钩。
除非另有说明，我们在实验中使用YCSB和Smallbank工作负载。表3总结了YCSB的实验参数，默认值用下划线表示。对于数据库实验，我们使用YCSB的开源驱动[19]和Smallbank的OLTPBench[44]驱动。Fabric和Quorum都使用Caliper[3]进行基准测试。我们注意到，尽管对区块链和数据库进行基准测试的驱动程序类型存在差异，但它们本身并不能说明下一节中报告的巨大性能差距
我们的实验是在一个由96个节点组成的内部集群上进行的，这些节点通过1Gb以太网连接。每个节点都配备了英特尔至强E5-1650 CPU，32GB内存和2TB硬盘。所有的实验都重复了三次，我们报告的是平均值。
5 结果和分析
我们首先总结了主要的发现，然后提供详细的实验分析。基于这些发现，我们提出了一个实证框架，对最近的混合区块链-数据库系统的性能进行比较。该框架不仅解释了现有系统的性能差异，而且对于理解未来的混合系统也很有用。
- 峰值性能。区块链和分布式数据库之间的性能差距是很大的。然而，这种差距并不像以前报告的那样显著。
- 复制。 基于事务的复制模型限制了并发性，这限制了不同的复制方法和故障模型对系统的峰值性能的影响。
- 并发性。 在具有高争论和约束的工作负载下，执行命令-验证区块链的性能很低。工作负载对性能的影响在NewSQL数据库中很突出，在NewSQL数据库中，并发性是在复制之上的。
- 存储。 区块链中的分类账抽象产生了大量的存储开销。另一方面，保证状态防篡改证据所需的开销很小。
- 分片。 分片区块链的性能远远落后于分布式数据库，因为对分片的形成和定期重新配置有安全要求。
5.1 峰值性能
5.1.1 YCSB
我们首先分析了四个系统在表3所示的默认配置下的峰值性能。具体来说，我们为每个系统填充了10万条记录，每条记录的大小为1KB。然后，我们针对两个YCSB工作负载测量吞吐量和延迟：统一更新（100%写）和统一查询（100%读）。我们还独立测量了TiKV的性能，即TiDB的复制存储，并将其包括在此比较中。
图4显示了五个系统的峰值吞吐量。 关系型NewSQL数据库（TiDB）的性能优于区块链，而复制型存储（etcd和TiKV）的性能优于关系型数据库。 具体来说，两个区块链的更新吞吐量低于每秒1500次交易，而TiDB达到了5159次。两个键值存储，etcd和TiKV，实现了大约15,000tps。两者的性能都超过了NewSQL数据库，因为它们没有产生支持ACID事务的开销。这一点从TiDB和TiKV之间的差距可以看出，TiDB-服务器的开销包裹着键值存储，造成了这种差距。 但是在查询工作负载下，这种差距就不那么明显了，因为ACID语义对只读事务的限制较少。
图5显示了系统不饱和时的延迟。 与吞吐量类似，我们观察到区块链和数据库之间有明显的区别。 我们注意到，与数据库提供的保证相比，区块链对只读交易的保证较弱（线性化）。 前者对读取请求的响应仍然比后者的可线性读取要长（在Fabric中高达6倍）。Fabric和Quorum的更新（查询）延迟分别为3500ms（9ms）和500ms（4ms）左右，而在数据库中则低于100ms（1ms）。
我们的结果证实了[46]中得出的结论：区块链的性能远远落后于最先进的数据库。然而，我们观察到的差距比[46]中的报告要小。特别是，关系型数据库TiDB在统一更新的工作负载下，实现了比最快的区块链Fabric高4倍的吞吐量（5159 tps vs. 1294 tps）。这与[46]形成鲜明对比，H-Store比区块链表现出120倍以上的速度提升。关键原因是H-Store是一个内存中的分布式数据库，具有主-备份复制功能。H-Store代表了设计空间的一个极端点，使其与区块链相当不同。相比之下，我们工作中考虑的所有系统都会产生一些共识协议的开销。
5.1.2 小型银行
图6比较了Smallbank工作负载下的OLTP性能。请求键遵循Zipfian分布，系数θ=1，在1M记录上。我们不包括etcd，因为它不支持一般的事务性工作负载。与YCSB相比，除了偏度，Smallbank交易施加了更多的约束，可能会触及到两条记录，但记录的大小较小。 令我们惊讶的是，实验表明，区块链和分布式数据库之间的性能差异很小。例如，Fabric和Quorum的吞吐量分别为835和655tps，而TiDB仅表现为1031tps。当从YCSB切换到Smallbank时，Fabric和TiDB的性能下降了，而Quorum的性能有所提高，在Smallbank下的峰值吞吐量比YCSB高2.5倍。我们将这一改进归功于Small-bank较小的记录规模。正如我们将在第5.3.3节中看到的，Quorum的性能容易受到访问大记录的事务的影响。同样，请求偏斜度也是Fabric和TiDB报告的吞吐量下降的原因。
5.2 复制
5.2.1 复制模型的影响
为了了解复制模型的影响，我们把重点放在Fabric和TiDB上，因为它们支持不同的交易生命周期。图8a比较了系统不饱和和饱和时的交易延迟。除了与TiDB相比有更高的延迟外，Fabric在系统饱和时还表现出延迟的显著增加。为了研究这个问题，我们用Fabric代码库来记录交易的每个阶段的详细延迟分解。特别是，我们测量了执行、订购和验证阶段的延迟。当Fabric不饱和时，订单和验证阶段大约各需要700ms，而执行阶段需要低于500ms。但当请求率超过系统容量时，验证阶段成为瓶颈，如图8a所示。
我们将这种延迟的增加归因于Fabric中区块的串行验证，其中区块在提交其交易之前堆积起来。即使在一个区块内，事务也会根据其内部顺序，按顺序坚持其效果。更糟糕的是，交易处理中的大量开销是由数据处理以外的因素造成的。例如，我们观察到，在饱和的情况下，Fabric花费了42%的块验证时间来验证交易签名。我们注意到，串行验证是Fabric的实现选择，也就是说，它可以并发地提交交易。然而，出于安全考虑，大多数区块链都规定了严格的交易顺序以实现确定性的执行。相比之下，数据库交易在其基于存储的复制下不会受到这种严格的顺序性的影响，也不会产生安全开销。
安全开销在查询交易中最为突出，这两个系统都不涉及共识。我们在图8b中显示，Fabric花了大部分的查询时间来验证客户端。相比之下，TiDB没有产生任何加密开销，它的大部分查询时间都用于获取数据。
5.2.2 复制方法的影响
我们增加节点的数量来比较共享日志和基于共识的系统在完全复制模式下的可扩展性，并将结果总结在表4中。这里，Fabric是唯一的共享日志系统。即使Fabric采用了Raft共识来获得交易顺序，但这是一个有3个固定订购者的外部服务。越来越多的Fabric对等体消费相同的共享有序日志，而对于其他系统，它们的所有节点都参与了共识。
与我们对两个区块链的预期相反，我们既没有观察到共享日志系统的性能不变，也没有观察到基于共识的系统的性能下降。特别是，Fabric的吞吐量从3到19个节点下降了3倍，而Quorum的吞吐量基本没有变化。在Fabric中，我们发现区块验证的延迟增加了38%。这是因为背书政策要求一个交易必须得到所有节点的支持。因此，更多的节点导致交易有更多的签名，因此，验证的时间更长。由于基于交易的复制的顺序性，验证时间的增加转化为吞吐量的减少，正如我们在第5.2.1节解释的那样。另一方面，Quorum没有充分利用Raft，使其性能对共识组的大小不敏感。具体来说，Quorum首先在账本的顶端预先执行交易，然后再将这些交易批量化为一个区块进行共识。因此，区块提议率受到账本顺序性的影响。
在相同的Raft协议下，与区块链相比，NoSQL数据库etcd实现了更高的峰值性能，但性能随着节点数量的增加而下降。我们将此归因于共识协议。NewSQL数据库没有表现出恒定或下降的性能趋势。相反，TiDB在7个节点上达到了其峰值性能。这是因为TiKV存储和TiDB服务器上的交易处理之间的相互作用。为了研究这种相互作用，我们独立改变TiDB服务器和TiKV节点的数量，并在表5中报告了吞吐量。TiDB服务器，由于其无状态的性质，应该随着节点数量的增加而表现出线性的速度提升[20]。然而，我们观察到，当TiDB服务器的数量较少时，它们会成为瓶颈，因为没有足够的处理能力用于SQL语句。但是当TiDB服务器的数量增加时，TiKV就成为了瓶颈。我们发现有两个不同的因素影响了TiKV的性能。一方面，在完全复制模式下，TiKV中较大的共识组会导致更大的开销。
另一方面，在完全复制的情况下，有更多的TiKV节点可以为请求提供服务，从而缓解了热点[20]。当固定TiDB服务器的数量时，我们注意到随着TiKV节点的增加，性能也在下降。这意味着共识的开销超过了TiKV中热点缓解的收益。
最后，我们得出结论，基于交易的复制模式对区块链的性能有明显的影响，而复制方法对分布式数据库的性能有普通的影响。
5.2.3 崩溃模型的影响
我们比较了Quorum中Raft和Istanbul Byzantine Fault Tolerant（IBFT）共识的性能，以说明不同故障模型的影响。回顾一下，Raft只容忍崩溃性故障，而IBFT可以容忍拜占庭式故障。IBFT共享PBFT的核心，包括一个三阶段提交。但IBFT为区块链进行了大量的优化。例如，通过在账本中嵌入共识元数据，IBFT节省了PBFT的检查点工作。IBFT还可以容纳动态验证器，而PBFT则假设有固定的成员。
图7显示了类似的峰值吞吐量，在增加可容忍的故障数量时保持相对稳定。然而，我们观察到IBFT的吞吐量在更大的网络中表现出更高的变异性，正如更大的误差条所证明的那样。这是由于在IBFT中需要更大的商数，在3f+1中需要2f+1，而在Raft中需要2f+1的复制。与Raft相比，IBFT需要在一个时间窗口内联系更多的副本，以避免视图改变，在此期间，相应的交易处理被中断。当f增加时，这种中断的概率也相应增加，因此，这导致了性能的较大差异。
5.3 并发
5.3.1 偏度的影响
为了分析并发控制机制的效果，我们使用倾斜的工作负载，其中每个事务修改（先读，然后更新和回写）一个记录。记录的键遵循Zipfian分布，根据偏度系数θ而变化。图9显示了不同偏度下的吞吐量和相应的中止率。我们在这里的关键观察是，区块链和数据库在高争论的工作负载下是可比的，因为当θ从0增加到1时，TiDB从5461吨急剧下降到173吨。Etcd和Quorum没有并发控制，因为它们以串行方式执行交易。因此，它们的性能不受偏斜度的影响。
尽管Fabric按顺序提交事务，但我们观察到，从统一工作负载到θ=1的倾斜工作负载，吞吐量下降了31%。这是由于Fabric对读写冲突的乐观的并发控制造成的。也就是说，一个事务包含在提议阶段读取的记录的版本，然后在验证阶段进行检查。如果这些版本不是最新的，事务就会中止。倾斜的工作量意味着许多事务正在访问相同的记录，导致事务中止的概率更高。例如，图9b显示，当θ=1时，Fabric中44%的交易中止了。
另一个有趣的观察是，TiDB的吞吐量下降与中止率的增加不成正比。具体来说，当θ=1时，只有30%的TiDB交易失败，但吞吐量却下降了90%。这是因为每个事务协调人都必须获得一个主记录的锁存器，其写入结果决定了整个事务状态。但是写必须经过复制的共识。在高度倾斜的工作负载下，这样的锁存机制使交易协调人在解决争论上花费的时间超过了交易有效负载的实际执行，导致整体吞吐量的显著下降[20]。因此，我们得出结论，工作负载倾斜度对基于存储的复制、并发复制架构产生了巨大的影响。
5.3.2 操作数的影响
我们在每个事务中逐渐加入更多的更新操作，以分析事务的原子性对性能的影响。为了消除交易规模的影响，对于给定的操作数，我们改变了记录的大小，使交易的总规模为1000字节。例如，如果一个事务写了10条记录，那么每条记录包含100字节。
如图10a所示，当每个事务的操作数增加时，Fabric、TiDB和etcd的性能下降。特别是，在每个事务有10个操作的情况下，TiDB只实现了单个操作事务的32%的吞吐量。有两个来源的开销促成了这种性能的下降。首先，当一个事务写入更多的记录时，会有更多的冲突，这导致了更高的中止率。其次，TiDB使用分片，这意味着一个10次操作的事务可能跨越多个分片。随着分片的增多，TiDB中2PC协调的开销也会增加。Etcd和Quorum不受影响，因为它们不需要跨分片交易。
图10b显示了随着每个事务操作数量的增加，TiDB和Fabric的中止率。两个系统都经历了高中止率。TiDB为26.9%，Fabric为87%。有趣的是，TiDB的中止主要是由于写-写冲突，而Fabric的中止来自两个方面：不一致的读和读写冲突。一方面，在Fabric的提议阶段，客户端必须从对等体收集相同的读取结果。这是因为我们规定，每个交易提案必须经过模拟，并得到所有对等体的认可。但是，不同的结果可能会被返回，因为对等体有不相干的状态，这是很有可能的，因为他们以不同的速率提交块。在这种情况下，客户端立即中止交易。另一方面，任何一个表现出读写冲突的修改记录都可能使交易无效。在每个交易有10个操作的情况下，这两个来源分别占据了所有中止的14%和86%。
5.3.3 记录大小的影响
我们扩大了统一更新工作负载中的记录，以增加每个事务的复杂性，而不加剧事务间的冲突。如图11a所示，所有数据库都表现出适度的吞吐量下降和延迟增加。然而，两个区块链的行为是不同的。当记录从10字节增长到1，000字节时，Fabric的性能大致保持在1400 tps，在5，000字节时下降了一半。但Quorum的吞吐量大幅下降，从10字节的1547 tps下降到5000字节记录的58 tps。为了理解这一点，我们分析了Fabric和Quorum的交易延迟细分，并在图11b中展示了结果。Fabric的块提交时间只增加了一倍，而在Quorum中，从10字节记录的3ms增加到5000字节记录的221ms，增加了70倍，在一个交易生命周期中，共识的比例从88%减少到50%。对于每次提交，Quorum的虚拟机需要重建一个MPT数据结构，这涉及许多昂贵的密码学计算。同时，哈希函数的成本随着记录大小而增加。特别是，我们发现，当记录大小从10到5000字节时，MPT重建的成本从56us增加到2.5ms。
图11b中另一个有趣的现象是，Quorum中提议阶段的延迟与提交阶段的延迟增长速度相同。 这是由于Quorum的顺序执行模型，在提议阶段，交易首先被分批执行，并由提议者连续执行。在达成共识后，所有其他节点再次串行执行分批交易以进行验证和提交。因此，Quorum的性能受到双重执行和块内交易顺序验证的开销的影响。 相比之下，Fabric采用了执行-顺序-提交的模式，交易在提议阶段被并发执行，然后在共识阶段被排序和分批执行。 串行处理只在提交阶段发生一次。 然而，正如我们在上一节中所看到的，并发是以可能中止的块内事务为代价的，这将破坏可序列化。 因此，当交易的计算量很大时，通过在后面引入顺序性要求，执行-顺序-提交的区块链优于顺序-执行的区块链。 但与区块链相比，具有基于存储的复制的NewSQL数据库可以利用更多的并发性。
5.4 存储
5.4.1 记录大小对存储的影响
图12显示了当我们增加记录大小时每条记录的存储成本。 Fabric产生的存储开销比TiDB高得多。对于一个5000字节的记录，状态存储消耗了大约5000bytes，而块存储消耗了21725bytes。TiDB没有使用额外的存储，因为没有维护历史信息，相关的元数据也可以忽略不计。这一结果表明，由于底层账本的抽象性，区块链的存储成本明显高于数据库。
5.4.2 篡改证据的安全开销
为了量化区块链中完整性保护机制产生的开销，我们比较了Hyperledger Fabric v0.61的Merkle Bucket Tree（MBT）和Quorum的Merkle Patricia Trie（MPT）性能。这种比较是在系统行为的整体上进行的。我们请读者参考[88]的深入分析。
在这个比较中，我们插入不同大小的10K记录，测量每条记录的状态存储成本。图13显示，MBT每条记录额外增加了24个字节，而MPT每条记录增加了1KB以上。由于MBT和MPT都在叶子中存储数据记录，它们的差异来自于树状结构：树越深，存储开销越大。MBT的规模是固定的。具体来说，MBT首先将所有记录哈希成1,000个桶，在此基础上建立一个具有特定扇出的Merkle树。在我们的实验中，考虑到1，000个桶和4个扇出，树的深度上限为5（dlog41000e）。作为一个前缀树，MPT的深度受到密钥长度的影响，在我们的设定中，密钥长度为16字节。具体来说，每个MPT内部节点持有4比特的密钥，因此，深度和扇出可以分别达到32和16。这解释了为什么MPT需要更多的空间。
5.5 分片
为了比较分片对数据库和区块链的影响，我们禁用了TiDB中的完全复制，并将其性能与基于云的NewSQL数据库Spanner和基于Hyperledger Fabric v0.6的最先进的分片区块链Attested Hyperledger（AHL）[42]进行比较。AHL利用可信的硬件来减少分片大小，提高每个分片的吞吐量。它通过运行一个实现2PC状态机的BFT分片来支持跨分片交易，并定期重新配置分片以减轻自适应对手。这个实验是在谷歌云平台上运行的，因为Spanner是一个纯云的服务。我们将所有系统的分片中的节点数设置为3，并预先用1M 1KB大小的记录填充状态。我们用Zipfian系数为1的倾斜工作负载来评估这些系统，其中每个事务修改了两条记录。
图14显示，当增加节点（和分片）的数量时，TiDB与Spanner相比实现了更高的吞吐量。这是因为TiDB一旦检测到冲突就会立即中止交易。相比之下，Spanner中冲突的事务会在悲观的并发控制下争夺锁。为了实现更强的安全性，与固定分片的AHL相比，定期重新配置分片的AHL在性能上牺牲了30%。尽管如此，由于PBFT和其他安全开销的高成本，AHL和这两个数据库之间的差距还是很大。
5.6 混合系统的性能
基于我们的分类法和实验结果，我们提出了一个框架来比较现有混合系统的性能。我们强调，该框架只支持高层次的、信封式的比较，并不能取代详细的实验分析。它关注的是作为关键性能指标的吞吐量，并没有考虑我们分类法中的所有维度。然而，这个框架根据系统的报告结果解释了它们之间的性能差异。更重要的是，它可以指导未来混合系统的设计。
图15展示了我们的框架和一些混合系统的报告性能。我们注意到，复制模型是决定峰值吞吐量的决定性因素。第5.2.1节中的结果表明，复制模型会影响并发性。特别是，基于交易的复制比基于存储的复制暴露出较低的并发性，这导致了较低的吞吐量。下一个影响吞吐量的因素是故障模型。正如第3.1.3节所解释的，CFT协议由于其较低的网络开销而比BFT协议更有效，因此，使用CFT的系统可能会有更高的吞吐量。特别是当CFT协议被实现为一个共享的日志服务时，情况更是如此。我们注意到，即使我们的实验没有显示出CFT和BFT在Quorum中的差别很大，这是因为这些协议不是瓶颈所在。
图15说明了我们框架内六个混合系统的报告性能。使用上述的两个因素，我们可以有效地预测吞吐量。例如，Vertias表现出比Chainify更好的吞吐量（29k vs. 6.1k），因为它使用基于存储的复制和CFT协议。但是它的性能有很高的变异性，因为在高争用下，吞吐量会显著下降，正如第5.3节所解释的那样
6 相关工作
比较。 现有的比较区块链和数据库的工作强调了它们的高层差异。[45]展示了性能上的巨大差距，而[41, 83, 37, 85]则侧重于应用层的差异。其中一些研究提出了经验性的流程图，以指导用户寻求选择基于区块链或数据库的解决方案[83, 37, 85]。相比之下，我们的工作通过研究两个系统的基本设计，提出了一个更深入、更全面的比较。
调查和基准测试。有一些作品对分布式数据库[39, 25, 21, 89]和区块链[78, 29, 92]分别进行了调查和基准测试。BLOCKBENCH[46]是第一个对它们进行并排比较的作品，证明区块链的性能仍然远远落后于分布式数据库。我们的工作比[46]更全面，因为我们考虑了与区块链有关的系统的设计。我们进行了更精细的测量，并调查了各种因素。
衔接区块链和数据库。现在有一种趋势是将数据库设计整合到区块链中，反之亦然。特别是，一些作品应用成熟的并发控制技术来提高区块链的性能[43，74]或推理智能合约的行为[73]。[81，70]使用数据库技术来增强区块链存储层，并向智能合约暴露更丰富的信息。[66, 22, 47]提出了支持关系型数据模型和强大安全性的混合设计。我们的工作为探索混合型数据库-区块链系统的设计空间提供了一个新的框架。
7 结论
在本文中，我们提出了区块链和分布式数据库之间的全面二分法，将它们视为两种不同类型的事务性分布式系统。我们提出了一个由四个设计维度组成的分类法：复制、并发、存储和分片。利用这个分类法，我们讨论了这两种系统类型如何在其高层次目标的驱动下做出不同的设计选择，即区块链的安全性，以及数据库的性能。然后，我们进行了定量的性能比较，涵盖了设计空间的大部分区域。我们的结果说明了不同设计选择对整体性能的影响。最后，我们的工作提供了第一个框架来探索未来的数据库-区块链设计融合。
