FalconDB: Blockchain-based Collaborative Database（sigmod 2020）整理翻译

摘要

如今，一种新兴的应用程序基于在不同实体之间共享数据库上的协作。然而，现有的共享数据库解决方案可能需要对他人的信任、对硬件的要求高而单个用户负担不起，或者性能相对较差。其实，安全性，兼容性，效率之间本身就存着三个维度无法同时优化。在本文中，我们介绍了FalconDB，它使硬件资源有限的情况下各方面–指那些方面都能够在数据库上高效安全地进行协作。 FalconDB采用客户端具有可访问的验证接口的数据库服务器，并将digests存储在区块链上以进行查询/更新身份验证。 使用区块链作为共识平台和分布式账本，FalconDB可以在彼此不信任的情况下工作。 同时，FalconDB在每个客户端上只需要最小的–有多小 存储成本，并且提供对数据库的任何可用，实时和并发访问。 因此，FalconDB克服了先前解决方案的弊端，并使单个用户能够以高效率，低存储成本和区块链级安全保证参与协作。

1 introduction

互联网的发展为数据合作带来了巨大的机遇。许多应用可以从多方共享的数据库中获益，如collaborative benchmarking[4]、crowdsourcing[43]、共享经济[5]、协作科学计算[14]、协作机器学习[7]。
在这种情况下，主要的问题是共享的数据库管理系统，允许各方执行更新和对数据库的查询，同时在网络中所有参与者之间保持一致视图。 许多项目需要一组个人用户之间的协作。 作为个人参与者，他们可能需要通过其个人设备进行协作，而个人设备通常是有限的存储和计算能力。 此外，它们很容易被骗，并变成坏蛋！！！ 因此，设计一个共享数据库是至关重要的，该共享数据库使单个用户可以彼此合作而无需任何信任。
传统上，具有有限的计算机能力和本地存储能力的个人用户通常使用中央服务器来促进协作。这样的服务允许随时随地对数据库进行实时和并发的访问。但是，它需要完全信任中央服务器，期望它能正确地执行所有请求。恶意服务器可以欺骗任何客户端而不被发现，这个问题比较迫在眉睫。另一个问题来自客户端:客户可以为了自己的利益任意地操纵记录。必须采用一种复杂的机制来防止客户机发布不需要的更新。就是不能让客户端自己找事儿~*
区块链技术的出现带来了解决拜占庭式失败的实用解决方案[26]，也就是说，一方可以任意行事。 具体来说，可以将许可的区块链平台视为一个分布式系统，在该系统中，有一系列保存不可变记录的块。 所有区块链节点都通过某种可以容忍拜占庭式故障的共识协议来同意记录块。 这样的平台包括Hyperledger [2]，Tendermint [8]，HotStuff [47]和BigchainDB [33]。 这种设计不需要集中式服务器，并且可以在不信任的环境中工作，最多可以有很小比例的节点（例如1/3）故障或者被恶意篡改。系统会拒绝恶意更新等不需要的操作。
尽管区块链系统吸引了很多关注，但是，由于成本高昂，单个用户作为节点参与仍然非常罕见。 首先，区块链节点需要在本地存储块的完整副本，这很容易达到数百GB，可能会耗尽单个用户的本地磁盘空间。 其次，区块链节点必须保持与其他节点的网络通信，以迅速接收和验证新块，这会消耗网络带宽和计算能力。 最后，由于不再有方便查询的服务提供商，因此用户必须使用其个人硬件在本地执行查询。 在CPU能力有限的情况下执行复杂的查询可能会慢得无法接受。
区块链节点的高成本限制了区块链的兼容性。 提出了轻量级客户的概念，以减轻单个参与者的成本[35]。以太坊的全节点和轻节点 。轻量级客户端与完整节点通信以更新或查询区块链数据库。 因此，它们的功能受到整个节点公开的API的限制。 此外，如果全节点不可信，则需要确保查询完整性[45]。 基准解决方案是利用智能合约[22]。 用户可以向智能合约提交查询。 然后，所有完整节点都将执行查询，并对查询结果运行拜占庭式容错（BFT）共识协议。 一旦达成共识，结果将提交给区块链，并透露给客户。 这种方法保证了大多数诚实节点的完整性。 但是，它的吞吐量有限，延迟时间长，耗气量高，并引起隐私问题。
以前的解决方案都无法同时实现安全性，兼容性和效率。当我们需要所有三个属性时，这成为最重要的难题。考虑慈善捐赠的情况，其中大量捐赠者向多个非营利组织（NGOs）捐赠。一个非政府组织需要记录每笔收到的捐赠，而一个个人捐赠者可能想审核一个非政府组织如何花钱。实际上，这样的数据库已经存在[13]，其中集中式数据库服务器决定所有更新和查询的执行结果。在这种设计中，数据库主机能够隐藏任何可能的捐赠损坏或滥用，而用户则无法对其进行验证。因此，更需要去中心化的区块链数据库解决方案。但是，如上所述[33]的现有区块链数据库设计是不够的，因为：
1）个人贡献者几乎没有足够的本地存储来存储整个数据；
2）充当轻量级客户端并使用智能合约查询完整节点还不够高效。
因此，设计一个对用户来说成本低廉的有效系统，却仍然能够进行可追溯且无篡改的慈善捐赠历史记录这一点非常重要。
贡献
我们介绍FalconDB，这是一个区块链数据库，对单个客户端的硬件要求（例如，存储，计算，带宽）低，可实现高达集中式数据库设计的查询效率，并确保像区块链级别一样强大的安全保证。在FalconDB中，区块链节点可以是服务器节点（存储整个数据库），也可以是客户端节点（通过向服务器节点发送查询和更新请求来使用数据库）。为了使客户端能够验证是否正确执行了更新或查询，数据库内容与经过身份验证的数据结构（ADS）存储在服务器节点上。 ADS为当前数据库内容生成一小段摘要，然后客户端可以使用此摘要来验证服务器返回的结果。服务器和客户端在分散的区块链网络下同步。每个服务器节点是一个完整的区块链节点，用于存储整个数据库和区块链块，而每个客户端节点仅存储块头。最新的块头包含当前数据库内容的摘要，客户端可以访问这些摘要以进行身份??验证。通过此摘要，FalconDB可以容忍多达1/3的总区块链节点是恶意的，并且就算只有一个节点没问题，它可以通过身份验证数据库来继续使用。
请注意，许多先前关于外包数据库的工作（ODB）[21、28、29、34、36、37、46、46、49、50]研究了查询身份验证的问题，该问题使用基本摘要验证了数据库服务器的结果。 不幸的是，它们不能直接应用于协作数据库场景，正如我们将在2.3.1节中展示的那样。
存在什么问题
局限性。 在ADB中，仅设置一个客户端的ADS已被证明功能强大。 借助ADS，客户端可以确保服务器返回的查询结果的完整性，完整性和新鲜度，而无需在本地存储整个数据。 但是，将ADS应用于有多个客户端来更新数据的协作数据库时，仍有两个主要挑战需要解决：
ADS的安全性保证是基于用户拥有正确的最新数据摘要的假设。 但是，当有多个客户端要更新远程数据时，存储在客户端本地计算机上的摘要可能已过时。 考虑到网络存在延迟，更新可能存在冲突以及接收到的摘要可能是恶意生成的，因此，在其他人更新数据之后，客户端要获取最新的摘要是一项挑战。
?协作者可能会受到损害并变得恶意。 恶意客户端可能发布不需要的数据更新，例如，随机插入和删除记录。 不幸的是，发生这种情况，原始ADS无法恢复数据也无法识别攻击者

在本文中，我们在区块链网络上构建ADS优雅地解决这两个挑战。 作为BFT共识算法，可以自然地使用区块链在客户端之间同步摘要，从而解决了第一个挑战。 而且，每当有不希望的数据更新时，区块链带来的属性都提供了直接的解决方案来恢复数据（具有不变的属性）并检测攻击者（具有透明的属性），这解决了第二个挑战。

我们将我们的贡献总结如下：

1. 我们提出并实现了FalconDB，据我们所知，它是第一个允许个人用户在具有强大安全保障、低存储成本和高效率的数据库上协作的平台。
2. FalconDB利用了区块链平台，可以容忍1/3的参与者被恶意攻击，同时还使用了一个临时数据模型，它提供了一个透明的数据库历史日志，使客户机能够检查历史并恢复恶意协作者所做的更新。
3. FalconDB服务器节点使用非匹配的数据结构存储整个数据库。这样，客户端节点只需要存储块标头，并能够验证服务器节点返回的结果。因此，每个客户端都有最小的存储成本，FalconDB可以一个节点存活。
4. 此外，FalconDB提供了一个激励模型，促使每个服务器承担额外的存储成本并诚实地响应客户机的请求，这进一步减少了服务器被恶意攻击的机会。类比特币奖励鼓励大家多干活
5. 最后，我们通过实证评价来验证alcondb的性能。我们的结果表明，FalconDB能够实现与最先进的区块链协议一致的安全保证、作为外包数据库的高效率以及在客户端上的低存储成本。

3问题陈述

设计目标

设计安全保证

• 不变性。区块链上提交的数据库任何更新是不可变的。
• 透明度。对数据库的所有操作都是所有人可见的。
• 数据完整性。客户机可以验证服务器端的数据库（不正当更新或者是否做了未经授权的事情）。
• 查询的正确性。客户机可以本地验证服务器端反馈的结果是否正确。
• 可靠性。返回答案是否满足查询条件且没被修改过。
• 完整性。结果中有没有被遗漏的答案。
• 新鲜度。是不是最新版本结果。

性能

• 高表达。支持广泛查询和更新。（是不是可以采用NLP做数据接口）
• client成本低。空间计算网络都小。即使你就是个手机！也可以作为client参与其中，并获得好处。
• 性能。支持高并发，低延迟。与outsourced DB相比一致性&认证开销更大。

4 系统设计

系统概况

分为两个部分，一个是server node，一个是client node。

• server node（不同的实体托管）
  存！存数据库和完整的区块链数据。
  查！回答client的查询
  更！更新client
  验！验证区块链新块
  生！为查询生成证明
  钱！给server node钱！

  1、每个服务器的数据库存储在一个持久的数据结构中，保存所有的历史版本。可以参考：
  链接: 可持久数据结构.
  2、构造一个ADS（authenticated data structures）像客户端提供身份验证的查询和更新。

• client node（不本地存DB数据）
  有权限！ 对数据库进行读写
  通过ADS进行验证查询更新的结果
  部分数据上链，其他节点被动更新，但是不参加区块链共识。

在FalconDB中，一个区块链事务相当于一个数据库的操作。
block header H 包括 块提交的时候ADS的摘要，用在client验证请求是否已经正确执行。
在运行共识之前，每个服务器和每个客户端向以太坊等服务托管的智能合约进行存款（交钱给你建立激励机制！！！！），这有助于建立激励机制，如第4.3节所述。 此外，我们假设存在网络中所有节点都同意的特权函数。 此函数定义了特定客户端可以进行的更新类型。 此特权功能是动态的，可以调整。 例如，如果一个客户端受到威胁并变得恶意，则其他客户端可以撤消其所有访问数据库的特权。 任何智能合约都可以轻松实现此功能，因此我们跳过本文中的详细信息。 图2说明了查询的一般工作流程。
图2说明了查询的一般工作流程。 将查询费用从其存款转入服务器帐户后，客户端节点可以向任何服务器节点发送查询。 服务器将立即执行查询并将结果返回给客户端。 之后，客户端可以选择通过向智能合约发送身份验证请求来验证查询结果。 在这种情况下，客户向服务器支付了额外的钱，并且服务器必须生成可以由摘要验证的ADS证明。 不提供此类证明将导致服务器丢失其智能合约帐户中的所有费用，包括其初始存款和从客户获得的收入。
此外，客户端可以使用ADS接口向服务器发布更新。 与服务器交互后，客户端将向网络提议一个新块，包括块内容中的更新和交互式日志，以及块头中的updater和新摘要的标识。 区块链节点将检查更新是否有效以及新摘要是否正确。 通过BFT(拜占庭容错机制)共识协议在所有区块链节点之间达成共识后，该区块将被提交给区块链，并且客户端会将其摘要更新为这个新提议的区块中的区块。
为了像传统数据库一样支持交易，我们采用开放式并发控制（OCC）来提供快照隔离，这与许多现代数据库系统一样。 用户可以根据其所在区块的规格来开始交易。 仅当指定的块与当前块之间没有冲突时，才会接受包含此事务的块。

实验

在我们的评估中，FalconDB合并了以下组件：
1）MySQL服务器作为后端SQL服务器，
2）IntegriDB [50]提供ADS和支持身份验证
3）Tendermint [8]作为区块链平台。
选择这些组件是因为实践中显示了出色的特性，例如兼容性和安全性保证。但是，将来也可以插入提供类似功能的替代方案和更高级的解决方案，并将其用作FalconDB中的黑盒。实验在CloudLab [15]上进行，其中每个节点都配备了2.4 GHz十核Intel E5-2640v4处理器和64GB DRAM。我们在具有Ns服务器和Nc客户端的群集上运行实验。默认情况下，Ns = 5且Nc =27。为模拟服务器与客户端之间的差异，我们通过报告执行时间的10倍来手动减慢所有客户端节点上的处理速度，这是合理的比率。商业服务器和移动电话的处理速度。为简单起见，实验中忽略了访问控制。
我们将FalconDB的性能与第1节中提到的两个现有区块链数据库解决方案进行了比较：一个基于天真的区块链的共享数据库（每个用户存储完整的数据副本（BC））和一个基于智能合约的解决方案，用户可以向其提交智能合约 查询完整节点并获得同意的结果（SC）。 在BC省，所有服务器和客户端均充当区块链节点。 它们在本地执行查询，因为每个查询都存储数据库的完整副本。 当节点想要更新数据库时，它将把更新命令推送到区块链网络。 在达成共识并在链上提交后，所有区块链节点都在其本地副本上执行相同的更新。 在SC中，客户端通过向服务器维护的区块链网络发送命令来发出查询和更新。 服务器执行并达成共识后，客户端即可从已提交的块中获取结果。 为了公平起见，我们将Tendermint用作所有解决方案的基础区块链平台。
数据集。 在所有实验中，数据库的构建都遵循YCSB [11]：只有一个表，其中有一个主键列和其他字段的几列。 每个字段的值是一个100字节的ASCII字符串。 此外，该表还包含第4.4节中所述的另外两个列VF和VT。 我们将行数表示为n，将列数（包括VF和VT）表示为m。 在下文中，我们首先使用不同的合成工作流程评估FalconDB，然后使用YCSB工作流程进行测试。 所有SQL查询均按照4.5和4.6节中的描述进行包装