vChain: Enabling Verifiable Boolean Range Queries over Blockchain Databases(sigmod‘2019)

---

Abstract

由于加密货币和去中心化应用程序的繁荣，区块链最近受到关注。查询存储在区块链数据库中的数据的需求越来越大。为了保证查询的完整性，用户可以维护整个区块链数据库并在本地查询数据。但是，由于区块链的庞大数据量和可观的维护成本，这种方法即使不是不可行，也是不经济的。在本文中，我们迈出了研究区块链数据库上可验证查询处理问题的第一步。我们提出了一个新的框架，称为 vChain，它可以减轻用户的存储和计算成本，并采用可验证的查询来保证结果的完整性。为了支持可验证的布尔范围查询，我们提出了一种基于累加器的身份验证数据结构，可以对任意查询属性进行动态聚合。进一步开发了两个新索引来聚合块内和块间数据记录，以实现有效的查询验证query verification。我们还提出了一种倒置前缀树结构来同时加速大量订阅查询的处理。安全分析和实证研究验证了所提出技术的稳健性和实用性.

---

1 Introduction

由于比特币 [1] 和以太坊 [2] 等加密货币的成功，区块链技术近年来获得了压倒性的发展势头。 区块链是一种仅附加的数据结构，分布式存储在网络中的对等点之间。 尽管网络中的对等点可能不相互信任，但区块链从两个方面确保数据完整性。 首先，在哈希链技术的支持下，存储在区块链上的数据是不可变的。 其次，由于其共识协议，区块链保证所有对等方都维护相同的数据副本。 这些密码学保证的安全机制，加上区块链的去中心化和出处特性，使区块链成为彻底改变数据库系统的潜在技术 [3, 4, 5, 6, 7].

从数据库的角度来看，区块链可以看作是存储大量时间戳数据记录的数据库。随着区块链在金融、供应链和知识产权管理等数据密集型应用中的广泛采用，用户对查询存储在区块链数据库中的数据的需求不断增加。例如，在比特币网络中，用户可能希望找到满足各种范围选择谓词的交易，例如“交易费用≥50 美元”和“099 万美元≤总产出≤101 万美元”[8]。在基于区块链的专利管理系统中，用户可以使用布尔运算符在专利摘要中搜索关键字组合，例如“区块链”∧（“查询”∨“搜索”）[9]。而许多公司，包括数据库巨头 IBM、Oracle 和 SAP，以及 FlureeDB [10]、BigchainDB [11] 和 SwarmDB [12] 等初创公司，都致力于开发区块链数据库解决方案以支持 SQL类似查询，所有这些都假设存在一个可信方，该方可以忠实地执行基于区块链数据库的物化视图的用户查询。但是，这样的可信方可能并不总是存在，并且无法保证查询结果的完整性。具有完整性保证的查询处理仍然是区块链研究中未探索的问题。

在典型的区块链网络 [1, 2],1 中，如图 1 所示，存在三种类型的节点：全节点、矿工和轻节点。 全节点存储区块链中的所有数据，包括区块头和数据记录。 矿工是具有强大计算能力的全节点，负责构建共识证明（例如比特币区块链中的随机数）。 轻节点仅存储块头，其中包括共识证明和块的加密哈希。 请注意，数据记录不存储在轻节点中。
为确保区块链数据库查询的完整性，查询用户可以作为全节点加入区块链网络。然后，用户可以下载并验证整个数据库并在本地处理查询，而不会影响查询的完整性。但是，维护整个数据库的完整副本对于普通用户来说可能成本太高，因为它需要大量的存储、计算和带宽资源。例如，运行比特币全节点的最低要求包括 200GB 的可用磁盘空间、上传速度至少为每秒 50KB 的不限流量宽带连接以及每天 6 小时的运行时间 [13]。为了迎合资源有限的查询用户，特别是移动用户，一个更有吸引力的替代方案是将存储和查询服务委托给一个强大的全节点，而查询用户只充当一个轻节点来接收结果。然而，如何确保查询结果的完整性仍然是一个挑战，因为全节点是不可信的，这是区块链的内在假设。

为了解决上述查询完整性问题，在本文中，我们提出了一个新的框架，称为 vChain，它采用可验证的查询处理来保证结果的完整性。 更具体地说，我们用一些额外的经过身份验证的数据结构 (ADS) 来扩充每个块，在此基础上，一个（不受信任的）全节点可以构造并返回一个称为验证对象 (VO) 的加密证明，供用户验证每个块的结果 询问。 查询用户（轻节点）和全节点之间的通信如图 1 所示，其中 Q 表示查询请求，R 表示结果集。

值得注意的是，这个 vChain 框架的灵感来自于为外包数据库研究的查询身份验证技术 [14、15、16、17、18]。然而，有几个关键差异使得传统技术不适用于区块链数据库。首先，传统技术依赖于数据所有者使用私钥对 ADS 进行签名。相反，在区块链网络中没有数据所有者。只有矿工才能通过根据共识协议构建共识证明来将新数据附加到区块链中。但是，他们不能充当数据所有者，因为他们无法持有私钥并签署 ADS。其次，传统的 ADS 建立在固定的数据集之上，无法有效适应数据无界的区块链数据库。第三，在传统的外包数据库中，总是可以根据需要生成和附加新的 ADS，以支持涉及不同属性集的更多查询。但是，由于区块链的不变性，这将是困难的，其中一刀切的 ADS 更适合支持动态查询属性。

显然，ADS 的设计是 vChain 框架的一个关键问题。 为了解决这个问题，本文重点关注布尔范围查询，如前所述，它在区块链应用程序中很常见 [8, 9]。 我们提出了一种新颖的基于累加器的 ADS 方案，可以对任意查询属性进行动态聚合，包括数值属性和集值属性。 这种新设计的 ADS 独立于共识协议，因此与当前的区块链技术兼容。 在此基础上，开发了高效的可验证查询处理算法。 我们还分别为块内数据和块间数据提出了两种经过身份验证的索引结构，以实现批量验证。 为了支持大规模订阅查询，我们进一步提出了一种查询索引方案，可以对类似的查询请求进行分组。 总而言之，我们在本文中所做的贡献如下：

• 据我们所知，这是第一个利用内置 ADS 实现区块链数据库查询完整性的可验证查询处理工作。
• 我们提出了一个新的vChain 框架，以及一个新的ADS 方案和两个可以聚合块内和块间数据记录的索引结构，以实现高效的查询处理和验证。
• 我们开发了一种新的查询索引，可以同时处理大量订阅查询。
• 我们进行安全分析和实证研究来验证所提出的技术。 我们还解决了实际的实施问题。

本文的其余部分安排如下。 第 2 节回顾了关于区块链和可验证查询处理的现有研究。 第 3 节介绍了正式的问题定义，然后是第 4 节中的密码原语。第 5 节介绍了我们的基本解决方案，然后通过第 6 节设计的两个索引结构对其进行了改进。第 7 节讨论了可验证的订阅查询。 第 8 节介绍了安全性分析。第 9 节介绍了实验结果。 最后，我们在第 10 节结束我们的论文。

示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。

2 相关工作

在本节中，我们将简要回顾相关研究并讨论相关技术。
区块链。自比特币加密货币推出以来，区块链技术受到了学术界和工业界的极大关注[1,2,5]。区块链本质上是一种特殊形式的默克尔哈希树（MHT）[19]，被构建为一系列块。如图 2 所示，每个块存储一个交易记录列表和一个建立在它们之上的 MHT。每个块的头部由四个部分组成： (i) PreBkHash，它是前一个块的哈希； (ii) TS，即区块创建时的时间戳； (iii) ConsProof，由矿工构建，保证区块的共识； (iv) MerkleRoot，它是 MHT 的根哈希。 ConsProof 通常基于 PreBkHash 和 MerkleRoot 计算，并根据共识协议而变化。在广泛使用的 ProofofWork (PoW) 共识协议中，ConsProof 是由矿工计算的随机数：
hash(PreBkHash | TS | MerkleRoot | nonce) ≤ Z
其中 Z 对应于挖矿难度。 矿工找到随机数后，会将新区块打包并广播到全网。 其他矿工验证交易记录和新区块的随机数，一旦验证，将其附加到区块链。

为了解决区块链系统的各种问题，包括系统协议 [20、21]、共识算法 [22、23]、安全性 [24、25]、存储 [7] 和性能基准测试 [4]，已经做出了巨大的努力 ]。 最近，包括 IBM [26]、Oracle [27] 和 SAP [28] 在内的主要数据库供应商都将区块链与其数据库管理系统集成在一起，它们允许用户通过数据库前端在区块链上执行查询 . 此外，FlureeDB [10]、BigchainDB [11] 和 SwarmDB [12] 等许多初创公司一直在为去中心化应用程序开发基于区块链的数据库解决方案。 但是，它们通常将查询处理与底层区块链存储分开，并依靠受信任的数据库服务器来保证查询完整性。 相比之下，我们提出的 vChain 解决方案将经过身份验证的数据结构构建到区块链结构中，因此即使是不受信任的服务器也可以提供完整性保证的查询服务。

可验证的查询处理。 可验证查询处理技术已被广泛研究，以确保针对不受信任的服务提供者的结果完整性（例如，[14,15,16,17,18,29]）。现有的大多数研究都集中在外包数据库上，有两种典型的方法：使用基于电路的可验证计算（VC）技术支持一般查询和使用经过身份验证的数据结构（ADS）支持特定查询。基于 VC 的方法（例如，SNARKs [30]）可以支持任意计算任务，但代价是非常高且有时不切实际的开销。此外，它需要昂贵的预处理步骤，因为数据和查询程序都需要硬编码到证明密钥和验证密钥中。为了解决这个问题，Ben-Sasson 等人。 [31] 开发了一种 SNARK 的变体，其中预处理步骤仅取决于数据库和查询程序的上限大小。最近，张等人。 [29] 提出了一个 vSQL 系统，它利用交互式协议来支持可验证的 SQL 查询。但是，它仅限于具有固定模式的关系数据库。

相比之下，基于 ADS 的方法通常更有效，因为它适合特定查询。 我们提出的解决方案属于这种方法。 两种类型的结构通常用作 ADS：数字签名和 MHT。 数字签名基于非对称加密验证数字消息的内容。 为了支持可验证的查询，它需要对每个数据记录进行签名，因此无法扩展到大型数据集 [14]。 另一方面，MHT 是建立在分层树上的 [19]。 叶节点中的每个条目都分配有数据记录的哈希摘要，内部节点中的每个条目都分配有从子节点派生的摘要。 数据所有者签署 MHT 的根摘要，可用于验证任何数据记录子集。 MHT 已广泛适用于各种索引结构 [15, 16, 17]。 最近，已经研究了对集值数据的可验证查询 [32, 33, 34, 35, 36]。

另一个密切相关的研究方向是数据流的可验证查询处理[37,38,39,40]。 然而，以前的研究 [38, 39] 专注于一次性查询以检索最新版本的流数据。 [40]要求数据所有者为所有数据记录维护一个MHT，并且查询延迟长，不适合实时流媒体服务。 另一方面，在 [41, 42, 43] 中研究了对数据流的订阅查询。 到目前为止，还没有工作考虑过区块链数据库订阅查询的完整性问题。

问题定义

如第 1 节所述，本文提出了一种新颖的 vChain 框架，并研究了区块链数据库上的可验证查询处理。 图 3 显示了系统模型 vChain，涉及三方：（i）矿工，（ii）服务提供商（SP）和（iii）查询用户。 矿工和 SP 都是维护整个区块链数据库的全节点。 查询用户是一个轻节点，仅跟踪块头。 矿工负责构建共识证明并将新块附加到区块链。 SP为轻量级用户提供查询服务。
存储在区块链中的数据可以建模为时间对象块的序列{o1，o2，···，on}。 每个对象 oi 由⟨ti,Vi,Wi ⟩ 表示，其中 ti 是对象的时间戳，Vi 是表示一个或多个数值属性的多维向量，Wi 是集值属性。 为了实现可验证的查询处理，由矿工构建并嵌入到每个块中的经过身份验证的数据结构（ADS）（将在第 5-7 节中详细说明）。 我们考虑两种形式的布尔范围查询：（历史）时间窗口查询和订阅查询。

时间窗口查询。 用户可能希望搜索在某个时间段内出现的记录。 在这种情况下，可以发出时间窗口查询。 具体来说，时间窗口查询的形式为 q = ⟨[ts, te ], [α, β], ϒ⟩，其中 [ts, te ] 是时间范围的时间范围选择谓词，[α , β] 是数值属性的多维范围选择谓词， ϒ 是集值属性上的单调布尔函数。 结果，SP 返回所有满足 {oi = ⟨ti,Vi,Wi ⟩ | ti ∈ [ts, te ]∧Vi ∈ [α, β] ∧ ϒ(Wi ) = 1}。 为简单起见，我们假设 ϒ 是合取范式 (CNF)。
例 3.1。 在比特币交易搜索服务中，每个对象 oi 对应一个硬币转移交易。 它由存储在 Vi 中的转账金额和存储在 Wi 中的一组发送方/接收方地址组成。 用户可以发出查询 q = ⟨[2018-05, 2018-06], [10, +∞], send:1FFYc∧receive:2DAAf⟩ 以查找 2018 年 5 月至 6 月发生的所有转账金额的交易 大于 10 并与地址“send:1FFYc”和“receive:2DAAf”相关联。

订阅查询。 除了时间窗口查询，用户还可以通过订阅查询来注册他们的兴趣。 具体来说，订阅查询的形式为 q = ⟨−, [α, β], ϒ⟩，其中 [α, β] 和 ϒ 与时间窗查询中的查询条件相同。 反过来，SP 连续返回所有对象，使得 {oi = ⟨ti,Vi,Wi ⟩ | Vi ∈ [α, β] ∧ ϒ(Wi ) = 1} 直到查询被注销。
例 3.2。 在基于区块链的汽车租赁系统中，每个租赁对象由存储在 Vi 中的租金价格和存储在 Wi 中的一组文本关键字组成。 用户可以订阅查询 q = ⟨−, [200, 250], “Sedan”∧(“Benz”∨“BMW”)⟩ 以接收价格在 [200, 250] 范围内的所有租赁消息，并且 包含关键字“轿车”和“奔驰”或“宝马”。

时间窗口查询和订阅查询的其他示例可以在图 3 中找到。

威胁模型。 我们认为 SP 作为区块链网络中不受信任的对等方，是潜在的对手。 由于程序故障、安全漏洞和商业利益等各种问题，SP 可能返回被篡改或不完整的查询结果，从而违反了区块链的预期安全性。 为了解决这种威胁，我们采用了可验证的查询处理，使 SP 能够证明查询结果的完整性。 具体来说，在查询处理过程中，SP 检查嵌入在区块链中的 ADS，并构造一个包含结果验证信息的验证对象（VO）。 VO 连同结果一起返回给用户。 使用 VO，用户可以根据以下标准确定查询结果的健全性和完整性：
• 稳健性。 结果返回的对象没有一个被篡改，并且都满足查询条件。
• 完整性。 没有关于查询窗口或订阅期的有效结果丢失。
当我们在第 8 节中进行安全分析时，上述安全概念将被形式化。该模型的主要挑战是如何设计 ADS，以便它可以轻松地容纳在区块链结构中，同时具有成本效益的 VO（ 可以为时间窗口查询和订阅查询有效地构建产生小带宽开销和快速验证时间）。 我们将在接下来的几节中解决这一挑战。

4 预赛

本节对我们的算法设计中所需的密码结构进行了一些初步的介绍。
加密哈希函数。 加密哈希函数 hash(·) 接受任意长度的字符串作为其输入并返回一个固定长度的位字符串。 它是抗冲突的并且很难找到两个不同的消息，m1 和 m2，使得 hash(m1) = hash(m2)。 经典加密哈希函数包括 SHA-1、SHA-2 和 SHA-3 系列。
双线性配对。 令 G 和 H 是两个具有相同素数阶 p 的循环乘法群。 令 д 是 G 的生成器。双线性映射是一个函数 e : G × G → H，具有以下属性： • 双线性：Ifu,v ∈ G 和 e(u,v) ∈ H，然后 e(ua ,vb ) = e(u,v)ab 对于任何 u,v。
• 非退化：e(ä, ä) , 1。
双线性配对作为多集累加器的基本操作，如本文后面所示。

5 基本解决方案

为了在我们的 vChain 框架中启用可验证的查询，一个简单的方案是构建一个传统的 MHT 作为每个块的 ADS，并应用传统的基于 MHT 的身份验证方法。 然而，这种幼稚的方案具有三个主要缺点。 首先，MHT 仅支持构建 Merkle 树的查询键。 为了支持涉及任意属性集的查询，需要为每个块构建指数数量的 MHT。 其次，MHT 不适用于设置值属性。 第三，不同区块的 MHT 无法有效聚合，无法利用区块间优化技术。 为了克服这些缺点，在本节中，我们提出了基于新的基于累加器的 ADS 方案的新型身份验证技术，该方案将数值属性转换为集值属性，并支持对任意查询属性进行动态聚合。

下面，我们从考虑单个对象开始并专注于布尔时间窗口查询以便于说明（第 5.1 和 5.2 节）。 然后我们将其扩展到范围查询条件（第 5.3 节）。 我们将在第 6 节讨论批量查询处理和多个对象的验证。订阅查询在第 7 节详细说明

5.1 ADS 生成和查询处理

可验证的查询处理。给定一个布尔查询条件和一个数据对象，只有两种可能的结果：匹配或不匹配。第一种情况的健全性可以通过返回对象作为结果轻松验证，因为它的完整性可以通过存储在块头中的 ObjectHash 进行验证，该对象哈希可供轻节点上的查询用户使用（回忆图 3） .挑战在于如何使用 AttDigest 有效地验证第二种情况。由于 CNF 是用 OR 运算符的 AND 列表表示的布尔函数，我们可以将 CNF 中的布尔函数视为集合列表。例如，一个查询条件“Sedan”∧(“Benz”∨“BMW”)等价于两个集合：{“Sedan”}和{“Benz”,“BMW”}。考虑一个不匹配的对象 oi：{“Van”, “Benz”}。很容易观察到存在一个等价集（即{“Sedan”}），它与对象属性的交集是空的。因此，我们可以应用 ProveDisjoint({“Van”, “Benz”}, {“Sedan”}, pk) 来生成不相交证明 π 作为不匹配对象的 VO。因此，用户可以从块头中检索 AttDigesti = acc({“Van”, “Benz”}) 并使用 VerifyDisjoint(AttDigesti, acc({“Sedan”}), π, pk) 来验证不匹配。整个过程在算法 1 中有详细说明。

5.2 多组蓄能器的结构

5.3 范围查询的扩展

6 批量验证

6.1 块内索引

6.2 块间索引

6.3 在线批量验证

7 可验证的订阅查询

7.1 可扩展处理的查询索引

7.2 惰性身份验证

8 安全分析

8.1 多集累加器分析

8.2 查询认证分析

9 绩效评估

在本节中，我们评估 vChain 框架在时间窗口查询和订阅查询方面的性能。 实验中使用了三个数据集：

• Foursquare (4SQ) [46]：4SQ 数据集包含 1M 条数据记录，即用户签到信息。我们将 30s 间隔内的记录打包为一个块，每个对象的形式为⟨timestamp, [longitude, latitude], {check-in place’s keywords}⟩。平均而言，每条记录有 2 个关键字。

• 天气 (WX)：WX 数据集包含 2012-2017.2 美国、加拿大和以色列 36 个城市的每小时 150 万条天气记录。对于每条记录，它包含七个数字属性（例如湿度和温度）和一个天气描述属性平均有 2 个关键字。同一小时间隔内的记录被打包为一个块。

• 以太坊（ETH）：ETH 交易数据集是从 2017 年 1 月 15 日至 2017 年 1 月 30 日期间从以太坊区块链中提取的。3 它包含 90,000 个区块和 112 万条交易记录。每笔交易的形式为 ⟨timestamp, amount, {addresses}⟩，其中 amount 是转移的以太币数量，{addresses} 是发送者和接收者的地址。大多数交易有两个地址。

请注意，4SQ、WX 和 ETH 中出块的时间间隔大致分别为 30 秒、1 小时和 15 秒。

查询用户设置在具有 Intel Core i5 CPU 和 8GB RAM 的商用笔记本电脑上，在 CentOS 7 上以单线程运行。 SP 和矿工设置在具有双 Intel Xeon 2.67GHz、X5650 CPU 和 32 GB RAM 的 x64 刀片服务器上，运行在 CentOS 7 上。实验用 C++ 编写，使用以下库： MCL 用于双线性配对计算 ,4 Flint 用于模块化算术运算，Crypto++ 用于 160 位 SHA-1 哈希运算，OpenMP 用于并行计算。 此外，SP(service provider(full node)) 运行 24 个超线程以加速查询处理。

为了评估 vChain 中可验证查询的性能，我们主要使用三个指标：
（i）SP CPU 时间方面的查询处理成本，(全节点)
（ii）用户 CPU 时间方面的结果验证成本，以及
（iii）传输的 VO 的大小从 SP 到用户。
对于每个实验，我们随机生成 20 个查询并报告平均结果。 默认情况下，我们将数值范围的选择性设置为 10%（对于 4SQ 和 WX）和 50%（对于 ETH），并使用大小为 3（对于 4SQ 和 WX）和 9（对于 ETH）的析取布尔函数 . 对于 WX，每个范围谓词都涉及两个属性。

9.1 设置成本

表 1 报告了矿工的设置成本，包括 ADS 构建时间和 ADS 大小。在我们的实验中比较了三种方法：（i）nil：不使用索引； (ii) intra：仅使用块内索引； (iii)both：使用块内和块间索引，其中块间索引中 SkipList 的大小设置为 5。每种方法都使用两种不同的累加器结构（标记为 acc1 和 acc2 ) 在第 5.2 节中介绍。因此，在每个实验中总共评估了六个方案。不出所料，两者的 ADS 构建时间一般都比 nil 和 intra 的要长，但大多数情况下仍在 2s 以内。此外，与 acc1 相比，acc2 显着减少了两者的构建时间，因为它支持在线聚合，因此可以在构建块间索引时重用前一个块的索引。关于 ADS 大小，它与所使用的累加器无关，针对不同的索引和数据集，每个块的范围从 2.6KB 到 11.1KB。

我们还测量了用户运行轻节点以维护块头所需的空间。对于 nil 和 intra，每个块头的大小都是 800 位，无论数据集或累加器如何。由于块间索引，两者的块头大小都略微增加到 960 位。

9.2 时间窗口查询性能

为了评估时间窗口查询的性能，我们将 4SQ 和 ETH 的查询窗口从 2 小时更改为 10 小时，将 WX 的查询窗口从 20 小时更改为 100 小时。三个数据集的结果显示在图 9-11，分别。我们做了几个有趣的观察。首先，正如预期的那样，这些索引在几乎所有指标中都显着提高了性能。特别是对于 4SQ 和 ETH 数据集，使用索引的性能至少比使用相同累加器但不使用任何索引的性能好 2 倍。这是因为这两个数据集中的对象共享较少的相似性，因此从使用索引进行修剪中受益更多。其次，基于索引的方案的成本仅随着查询窗口的扩大而亚线性增加。在使用 acc2 的基于索引的方案的用户 CPU 时间方面尤其如此，它支持不匹配的批量验证（参见第 6.3 节）。第三，比较 intra 和 both，除了 4SQ 数据集的 SP CPU 时间外，两者总是不比 intra 差。一方面，这表明了使用块间索引的有效性。另一方面，两者在 SP CPU 时间上都比 intra 差的原因主要是因为在基于块间索引的方案中，更大的多重集被用作集合不联合证明的输入，这增加了 SP CPU 时间.附录 D.3 提供了对此的更多见解，我们在其中检查了 SkipList 大小的影响。对于 ETH 数据集，观察到两者相对于内部的最大改进。原因如下。与 4SQ 相比，ETH 中对象之间共享的相似度更低；与 WX 相比，ETH 每个区块中包含的对象更少。对于这两种情况，在块间索引中使用跳过列表可以获得更多的性能改进。

9.3 订阅查询性能

我们接下来评估订阅查询的性能。 首先，我们在启用块内索引和块间索引的默认设置下，使用或不使用 IP-Tree（表示为 ip 和 nip）检查 SP 的查询处理时间。 我们随机生成不同数量的查询。 我们将 4SQ 和 ETH 的默认订阅期设置为 2 小时，WX 设置为 20 小时。 如图 12 所示，IP-Tree 在所有测试案例中都将 SP 的开销减少了至少 50%。 由于数据分布更稀疏，ETH 数据集（图 12（c））中的性能提升更为显着。
为了比较实时认证和惰性认证，我们考虑了两种实时方案（使用 acc1 和 acc2）和一种惰性方案（仅使用 acc2，因为 acc1 不支持累积集和证明的聚合）。我们将 4SQ 和 ETH 的订阅期从 2 小时变为 10 小时，将 WX 的订阅期从 20 小时变为 100 小时。无花果。图 13-15 显示了改变订阅期的结果。显然，惰性方案在用户 CPU 时间方面比实时方案执行得更好。此外，惰性方案中的 CPU 时间和 VO 大小仅随着订阅期的增加而亚线性增加。这是因为惰性方案可以跨块聚合不匹配对象的证明。相反，实时方案在新块到达时立即计算所有证明，导致性能更差。在 SP CPU 时间方面，由于惰性方案需要牺牲 SP 的计算来聚合不匹配证明，因此在使用相同的累加器时，其性能通常比实时方案差。

10 结论

在本文中，我们在文献中首次研究了区块链数据库上的可验证查询处理问题。 我们提出了 vChain 框架来确保轻量级用户的布尔范围查询的完整性。 我们开发了一种新颖的基于累加器的 ADS 方案，将数值属性转换为集值属性，从而实现对任意查询属性的动态聚合。 在此基础上，设计了两个数据索引，即基于树的块内索引和基于跳过列表的块间索引，以及一个基于前缀树的订阅查询索引，并进行了一系列优化。 虽然我们提出的框架已被证明是可实际实施的，但所提出技术的稳健性已通过安全分析和实证结果得到证实。
本文为区块链研究开辟了一个新方向。 有许多有趣的研究问题值得进一步研究，例如，如何支持更复杂的分析查询； 如何利用现代硬件（例如多核和众核）来扩展性能； 以及如何解决查询处理中的隐私问题。

vChain + : Optimizing Verifiable Blockchain Boolean Range Queries ( Technical Report )

摘要

由于加密货币和去中心化应用程序的成功，区块链最近引起了广泛关注。凭借不变性和防篡改特性，它可以被视为一种很有前途的安全数据库解决方案。为了解决对区块链数据库的搜索需求，vChain 之前的工作提出了一种新颖的可验证处理框架，该框架可确保查询完整性，而无需维护区块链数据库的完整副本。然而，它受到一些限制，包括最坏情况下的线性扫描搜索性能和不切实际的公钥管理。在本文中，我们提出了一种新的可搜索区块链系统 vChain+，它支持具有附加功能的高效可验证布尔范围查询。具体来说，我们提出了一种滑动窗口累加器索引，即使在最坏的情况下也能实现高效的查询处理。我们还设计了一个对象注册索引，以在不影响安全保证的情况下实现实用的公钥管理。为了支持更丰富的查询，我们采用最佳的基于树的索引来索引关键字和数据对象的数字属性。还提出了一些优化以进一步提高查询性能。安全性分析和实证研究验证了所提出系统的鲁棒性和性能改进。与 vChain 相比，vChain+ 查询性能提升高达 913 倍。

Introduction

近年来，由于去中心化应用在加密货币、医疗保健和供应链管理等各个领域的巨大成功，区块链受到了极大的关注[1]-[3]。它是一个仅附加的分类账，建立在不受信任的节点网络同意的传入交易之上。利用哈希链和分布式共识协议，区块链具有不可篡改和防篡改的特点。在典型的区块链网络中，存在三种类型的节点：全节点、矿工和轻节点，如图 1 所示。全节点维护区块链数据的完整副本，包括区块头和完整的区块状态。矿工也是一个完整的节点，但有额外的责任来生成新的区块。另一方面，轻节点不维护整个区块链。轻节点仅存储包含共识证明和块状态摘要的块头。尽管尺寸很小，但块头提供了足够的信息来验证块的完整性。

区块链的独特特性使其成为一种很有前途的安全数据库解决方案，尤其是在去中心化环境中。因此，查询存储在区块链数据库中的数据的需求不断增长。例如，在比特币网络中，用户可能希望查找某个时间间隔内转账金额在 1 美元到 10 美元之间的所有交易或与某些特定发送方和接收方地址相关联的所有交易。一些数据库公司，例如 IBM 和 Oracle，通过在传统的集中式数据库中实现区块链数据的视图来提供可搜索的区块链数据库解决方案。然而，这样的设计对于去中心化的应用来说是不可取的。中心化方不保证查询执行的完整性，这可能是恶意的或被破坏的。或者，用户可以维护整个区块链数据库的完整副本并在本地查询数据。然而，这对于普通用户来说是不切实际的，因为它需要大量的存储、计算和带宽资源。

为了解决上述问题，Xu 等人。 [4] 提出了支持区块链数据库上可验证的布尔范围查询的 vChain 框架。 如图1所示，vChain中的查询用户只需充当轻节点即可； 而是将查询外包给区块链网络中的完整节点，该节点充当服务提供商 (SP)。 尽管 SP 可能不受信任，但用户仍然可以通过检查附加验证对象 (VO) 来验证查询结果的完整性。 VO 由 SP 借助嵌入在块头中的精心设计的认证数据结构 (ADS) 计算得出。 我们将简要讨论 vChain 框架的基本设计及其限制其实用性的挑战。

A、Vchain和它的限制

在 vChain 中，每个区块头都添加了一个专门设计的 ADS，AttDigest（如图 2 所示）。 AttDigest 是从一个加密集累加器计算出来的，它作为一个恒定大小的摘要来表示一组数据对象。它还可以用于通过使用集合不相交操作来有效地证明块中的数据对象与查询条件不匹配。例如，如果 blocki 中的对象 oi 有两个关键字 {“A”, “B”}，则对应的 AttDigest 计算为 AttDigest = acc({“A”, “B”})，其中 acc(·) 计算设置累计值。当用户询问 q = “B” ∧ “C” 时，我们可以看到 blocki 与 q 不匹配，因为 “C” ∩ {“A”, “B”} = ∅。因此，SP 计算一组不相交证明 π∅ 并将 VO = {π∅, “C”} 发送给用户。基于以上信息，用户可以使用π∅和区块头中的AttDigest来确定区块i与查询条件“C”不匹配。为了有效地批量处理多个不匹配的块以获得更好的性能，vChain 还提出了块间索引，这是一个skiplist用来聚合跨block的数据对象。对于每个跳过，根据跳过的块中的对象计算一个累积值。如果一个查询由于相同的不匹配查询条件而与聚合块不匹配，我们可以生成单个不匹配证明来跳过这些块，从而降低查询成本。 vChain 中的范围查询是通过在前缀树的帮助下将数值属性转换为集值属性并遵循类似的查询处理过程来实现的。
虽然 vChain 首次支持可验证在区块链数据库中的布尔范围查询，它仍然存在一些限制其实用性的挑战。第一个是在最坏的情况下，块间索引无法帮助加快对聚合不匹配块的证明，从而使查询退化为线性扫描过程。例如，假设 q = “A” ∧ “B” 和三个连续的块，分别包括关键字 o1 = {“A”, “C”}, o2 = {“B”, “D”}, o3 = {“A”、“E”}，聚合，以便块间索引中的累积值从 S = {“A”、“B”、“C”、“D”、“E”} 计算。在这种情况下，块间索引无法工作，因为 S 满足 q。这个例子表明，在最坏的情况下，vChain 必须逐个查询每个块，因为块间索引无法聚合具有不同不匹配原因的多个不匹配块。通过这一观察，我们使用 4SQ 数据集 [5] 评估 vChain，以测量块间索引对不匹配块的利用率。图 3 显示，在几乎 80% 的情况下，块间索引无法工作（即跳过长度为 0），这与之前的分析一致。 vChain 的第二个限制是其公钥管理的实际问题。由于密码累加器的特性，其公钥大小由系统中属性的最大可能值决定，如果使用 256 位散列对数据属性进行编码，则为 2^256。为了规避这个问题，vChain 提议引入一个可信的预言机来动态生成公钥。但是，去中心化环境中可能不存在这样的预言机，这使得 vChain 难以部署在现实生活中的应用程序中。最后但同样重要的是，由于 vChain 将数值属性转换为集值属性，它只能支持整数和定点数，这限制了它的应用。

B、our contributions

为了解决 vChain 的局限性，我们提出了一种新的可搜索区块链系统 vChain+，该系统支持高效的可验证布尔范围查询，并采用新颖的 ADS 设计，更加高效、实用和实用。 我们没有使用不匹配条件来处理块，而是提出了一种新颖的滑动窗口累加器设计，用于在每个块中构建 ADS(认证数据结构)。 具体来说，对于每个块，我们在最近的 k 个块中的数据对象上构建一个滑动窗口累加器 (SWA) 索引，其中 k 是滑动窗口大小。 通过这样的设计，一个时间窗历史查询q = [ts, te]首先被划分为多个子查询，每个子查询的时间窗大小为k。 然后，可以使用相应块中的 SWA 索引有效地处理和验证每个子查询。
SWA 索引的主要改进来自于使用最佳索引来支持不同的查询（例如，关键字查询的 trie 和范围查询的 B±tree）。 例如，考虑上述三个连续块的情况，我们设置 k = 3，可以构建一个基于 trie 的 SWA 索引，包括关键字“A”、“B”、“C”、“D”、“E” . 在查询处理过程中，我们首先搜索SWA索引，得到关键字“A”和“B”的对象集，分别为{o1，o3}和{o2}。 然后，使用两个对象集的累加值计算集合相交证明π∩，以证明结果为∅。 因此，SWA 索引可以帮助加快聚合块的证明，并缓解 vChain 中的块间索引问题。
除了 SWA 索引，我们还通过引入对象注册索引来解决公钥管理的实际问题。 请注意，密码集累加器的公钥大小取决于输入集元素的全域大小。 由于我们的 SWA 索引中的累加器是建立在数据对象上的（参见 vChain 中的keywords），我们使用一个小的整数 ID 注册和索引每个数据对象，以限制全域大小，从而限制公钥大小。 用户可以使用该索引从相应的 ID 中检索最终的查询结果，并保证完整性。 此外，与将数值属性转换为集值属性的 vChain 不同，我们使用 B±tree 来支持浮点数的数值范围查询。 我们还考虑了具有多个关键字的任意布尔查询（参见 vChain 中支持的有限单调布尔查询）。

此外，我们提出了一些优化以进一步提高系统性能。 我们建议为每个块构建多个具有不同滑动窗口大小的 SWA 索引，以便 SP 可以根据查询条件选择最佳的一个。 同时，由于查询可能涉及一系列可验证的集合操作，我们采用最优查询计划来减少密码集合累加器的计算开销。 我们还建议基于空集修剪不必要的集合操作。 安全分析和实证研究都对所提出的方法进行了验证。 实验结果表明，vChain+ 与 vChain [4] 的两种结构相比，查询性能分别提高了 913 倍和 1098 倍。

本文的其余部分安排如下。 第 II 节介绍了正式的问题表述，随后是第 III 节中密码构建块的一些预备知识。 第四节介绍了可验证布尔查询的处理，然后在第五节中将其扩展到丰富的查询类型。第六节介绍了几种优化技术，安全性分析在第七节中介绍。 第八节给出了实验结果。 第九节讨论了相关工作。 最后，我们在第 X 节结束我们的论文。

问题描述

如第一节所述，vChain+ 遵循与 vChain [4] 相同的系统模型，但提出了新颖的 ADS 设计以提供更好的查询处理效率和功能。 SP是区块链全节点，提供可验证查询服务，用户是轻节点，只维护区块头进行验证。 另一方面，矿工作为全节点，负责将新区块追加到区块链中，并在每个区块中构建专门设计的滑动窗口累加器（SWA）索引，以方便可验证的查询。 在 SWA 索引的帮助下，SP 返回结果和用于结果完整性验证的附加验证对象（VO）（如图 1 所示）。

区块链中的数据对象被建模为 oi = ⟨ti, vi,Wi⟩ 形式的元组，其中 ti 是对象的时间戳，vi 表示数值属性，Wi 是对象的关键字集。在本文中，我们关注特定时间窗口内可验证的历史布尔范围查询。具体查询形式为Q = ⟨[ts, te], [α, β], Υ⟩，其中[ts, te]为时间窗谓词， [α, β]为数值范围谓词, Υ 是对象关键字集上的任意布尔函数。与vChain不同的是，Υ不仅限于单调的布尔函数，还支持¬（NOT）、∧（AND）、∨（OR）运算符，表现力更强。给定一个查询，SP 返回所有满足查询条件的数据对象，即 {oi = ⟨ti, vi,Wi⟩ | ti ∈ [ts, te]∧vi ∈ [α, β]∧Υ(Wi) = 1}。例如，在比特币交易数据的上下文中，用户可能会询问查询 q = ⟨[2021-10, 2021-11], [10, 20], send:2AC0 ∧ ¬receive:3E7F⟩ 以查找所有交易这发生在 2021 年 10 月到 11 月，转账金额在 10 到 20 之间，关联的发送方 2AC0，但接收方 3E7F 除外。

威胁模型。 与 vChain [4] 类似，我们假设 SP 是不可信的，并且可能由于商业不诚实或安全漏洞等各种原因返回被篡改或不完整的结果。 另一方面，我们假设区块链在功能上工作，即区块链系统中的大多数矿工都是诚实的，区块链网络是强同步的。 此外，我们假设用户是受信任的，并且在查询验证过程中忠实地遵循协议。 具体来说，借助SP生成的VO，用户可以验证结果的健全性和完整性。 健全性是指所有返回的结果都来源于区块链数据库，并且满足查询条件。 完整性表示没有关于查询条件的有效结果丢失。
vChain+ 的目标是设计一种新颖的 ADS，与现有的 vChain 框架相比，它有助于系统在不影响安全保证的情况下实现更好的查询性能、更实用的公钥管理和更灵活的查询类型。 我们将在接下来的几节中展示满足这些要求的设计。

三、 预备知识

本节给出了密码学的一些预备知识在所提出的算法中使用的构建块。
加密哈希函数：加密哈希函数H(·)是将任意长度的消息m作为输入并输出固定长度的散列摘要H(m)的算法。 它具有一个重要的属性，即抗碰撞性，表明 PPT 对手可以找到两个消息 m1̸= m2，使得 H(m1) = H(m2) 的概率可以忽略不计。

Merkle Hash Tree [6]：Merkle Hash Tree (MHT) 是一种树结构，用于有效地验证一组数据对象。图 4 显示了一个具有八个对象的 MHT 示例。简而言之，MHT 是一种自底向上构造的二叉哈希树。具体来说，每个叶节点存储索引对象的哈希值。每个内部节点都包含一个使用其两个子节点计算的散列（例如，h6 = H(h3||h4)，其中“||”是连接操作）。由于抗冲突散列函数和分层结构，MHT 的根散列（图 4 中的 h7）可用于验证索引数据。例如，对于范围查询 [6, 25]，结果是 {8, 20} 及其对应的证明 {5, 31, h6}（如图 4 中的阴影节点所示）。可以通过使用证明重构根哈希并将其与签名根哈希进行比较来验证这些结果。如果它们匹配，则意味着结果没有被篡改。同时，证明中的边界数据5、31保证了结果的完整性。

为了支持其他查询，MHT 已扩展到用于范围查询的 Merkle B±tree [7]、用于空间查询的 Merkle R-tree [8] 和用于字符串搜索的 Merkle Patricia Trie [2]。

密码集累加器 [9]：密码集累加器是一个将集合 X 映射到恒定大小的摘要 acc(X) 的函数。 与密码散列函数类似，此摘要可以证明相应的集合。 此外，它还支持各种可验证的集合操作，包括交集（记作∩）、并集（记作∪）和差集（记作\）。 这些集合操作可以嵌套方式调用，并使用输入集合的累积值进行验证。 具体来说，密码集累加器方案由以下概率多项式时间算法组成：

• ACC.KeyGen(1λ, U) → pk：在输入安全参数 λ 和全域 U 时，它输出公钥 pk。
• ACC.Setup(X, pk) → acc(X)：输入集合 X 和公钥 pk，输出 X 的累加值 acc(X)。
• ACC.Update(acc(X), acc(Δ), pk) → acc(X+Δ)：输入集合X的设定累计值acc(X)，增量更新的累计值acc(Δ) Δ（包括集合元素的插入或删除）和公钥pk，输出相对于新集合X+Δ的累加值acc(X+Δ)。
• ACC.Prove(X1,X2, opt, pk) → {R, πopt}：在输入两个集合 X1、X2、集合运算 opt ∈ {∩、∪、} 和公钥 pk 时，它返回集合操作的结果 R = opt(X1,X2) 以及证明 πopt。
• ACC.Verify(acc(X1), acc(X2), opt, πopt, acc®, pk) → {0, 1}：输入集合 X1 的累积值 acc(X1), acc(X2)和 X2，分别是关于操作 opt、答案集 R 的累积值和公钥 pk 的证明 πopt，当且仅当 R = opt(X1,X2)。

在本文中，我们使用了 Zhang 等人提出的最先进的密码集累加器方案。 [9]，它不仅支持增量更新，还支持表达嵌套集操作。该方案的另一个不错的特性是任何集合操作的证明大小都是恒定的，并且证明一系列嵌套集合操作的成本与集合操作的数量成线性关系。然而，它的证明生成成本相对较高，复杂度为 O(N1 · N2)，其中 N1,N2 分别是输入集 X1,X2 的大小。此外，以牺牲表达性为代价，它的证明大小相对比 vChain [4] 中使用的要大。同时，该方案的公钥大小为 O(|U|^2)，其中 |U|是输入集元素的全域大小。为了弥补这些缺点，我们提出了一个对象注册索引，它为每个数据对象分配一个有界 ID，以解决第 IV-A 节中的公钥大小问题。此外，我们在第六节中提出了几种减少证明生成开销的技术。

四、可验证的布尔查询处理

在本节中，我们考虑具有多个关键字的可验证布尔查询。 正如我们之前解释的，vChain 的查询处理在最坏的情况下可能会退化为线性扫描。 为了解决这个问题，我们提出了一种新颖的滑动窗口累加器索引设计，用于高效的查询处理。 主要思想是为每个block为最近k个block中的数据对象构建一个sliding window accumulator trie（简称SWA-Trie），其中k为sliding window size。 SWA-Trie 的根哈希嵌入在区块链标头中（见图 5），以支持可验证的查询处理。 下面，我们将详细讨论与此设计相关的问题：（i）如何通过对象注册来管理累加器的公钥（第 IV-A 节），（ii）如何高效维护 SWA-Trie 索引（第 IV 节 -B），（iii）如何支持表达布尔关键字查询（第 IV-C 节），以及（iv）如何验证查询结果（第 IV-D 节）。

A 对象注册

如前所述，我们使用密码集合累加器方案来验证各种集合操作。 然而，我们设计中使用的累加器方案的公钥大小与输入集元素的全域大小成二次方。 回想一下，输入集元素是每个滑动窗口中的数据对象。 这对实际应用的公钥管理提出了挑战。 例如，我们不能简单地使用加密哈希函数将数据对象编码为 256 位整数，这将产生一个大小为 (2^256)2 = 2^512 的公钥。(数据量太大)为了解决类似的问题，vChain 建议引入一个 受信任的预言机，它拥有一个密钥来动态生成公钥 [4]。 然而，在区块链应用的背景下，这样的解决方案并不是很理想。 在去中心化的公有区块链环境中，要找到可信的第三方并不容易。
更改了区块链本身的数据结构如何不更改区块链的数据结构进行数据的处理分析，区块链本身的建立，我们如何抓取在超算上的准确的日志工作。
为了正确解决这个问题，我们建议在区块链的每个块中嵌入一个对象注（ObjReg）索引，如图 5 所示。我们不是将数据对象直接存储在集合累加器中，而是使用一个 ID 注册每个数据对象并将 ID 存储在设置的累加器中。 ObjReg 索引用于跟踪最近 2k−1 个块中的数据对象与其 ID 之间的映射。在这里，我们强制执行一个最大 ID，表示为 MaxID，它是跨越 2k-1 个块的数据对象（数据对象和block的区别是什么？每个block里面包括多个数据对象）的最大可能数量。因此，集合累加器的输入集合元素的全域大小限制为 MaxID，从而限制了公钥大小。例如，我们在实验中将数据集的 MaxID 设置为 2¹²，这将公钥大小限制为 (2¹²)² = 2²⁴。同时，这也保证了每连续 2k-1 个块中的数据对象始终具有不同的ID。正如稍后将显示的，我们的集合操作仅涉及 2k-1 个块内的数据对象。因此，任何集合操作中的每个对象都保证具有唯一的 ID。

ObjReg 索引是完全平衡 MHT具有固定扇出（fanout）。每当一个新的数据对象到达时，矿工将注册该对象并通过增加一个以 MaxID 为模的计数器来分配一个 ID。然后，对象根据其 ID 插入到 ObjReg 索引中。由于 ObjReg 索引是具有固定扇出的完整树，因此可以通过将 ID 解释为使用扇出作为基数的数字来轻松计算对象的位置。考虑图 6 中的数据对象 o6。由于 ID 6 可以解释为 radix-3 中的 020，因此可以通过跟踪相应树级别中的第 1、第 3 和第 1 个节点来定位 o6。通过 ObjReg 索引和查询结果的 ID，用户可以使用 ObjReg 索引来验证查询结果，就像在正常 MHT 中一样。在图 6 的示例中，其中 o6 是查询结果，SP 将返回 {o6, h11, h12, h1, h2} 给用户。在用户方面，ObjReg 树的根哈希被重构并与存储在块头中的哈希进行比较。如果验证通过，则可以确定数据对象o6确实对应了ID 6。

B. SWA-Trie 的维护

回想一下，在我们的设计中，每个 SWA-Trie 都是基于最近 k 个块中的数据对象构建的。 图 7 显示了我们设计的索引滑动窗口大小为 4 的 trie 结构的示例。为了便于说明，我们假设每个块包含单个数据对象（每个block中只有一个数据）。 在这个例子中，trie 结构体 Ti 建立在 ID 为 {id1, id2, id3, id4} 的对象之上。 每个 trie 节点 n 包含一个哈希摘要（用 hn表示）以形成 Merkle 树。 对于根节点和每个叶子节点，我们还存储了一个对象ID集合（用Sn表示）和对应的集合累加值（用accn表示）。 令 H(·) 为加密hash函数，|| 是字符串连接操作，acc(·) 是密码集累加器。 我们定义每个 trie 节点的字段如下。
累加器：
密码累加器
集合累加器
**

定义：（SWA-Trie 叶节点）。 叶节点 n 的字段定义为： • wn 是 n 的相关关键字段； • Sn = n 覆盖的对象的ID 集； • accn = acc(Sn)； • hn = H(H(wn)||accn)。
定义
定义 2（SWA-Trie 非叶节点）。 将非叶子节点n的子节点表示为{c1,····,cF}。 n 的字段定义为：
• wn = n 的相关关键字段；
• Sn = n 所覆盖的对象的 ID 集（如果 n 是根）；
• accn = acc(Sn)（如果 n 是根）；
• childHashn = H(hc1|| ···||hcF);
• hn = H(H(wn)||childHashn||acc(Sn))（如果 n 是根）； • hn = H(H(wn)||childHashn)（如果 n 是非根）。

• 这种增量更新，类似于纠删码中的相关的增量更新，他们之间是否可以相互使用。
  -
  为了增量更新 SWA-Trie 索引，我们将其维护为持久数据结构。 算法 1 描述了维护算法。 在接收到一个新的数据对象块后，算法会删除第 k 个最旧的块中的对象 ID（由 bi-k+1 表示）并将对象 ID 插入到新的块中（由 bi+1 表示）。 在图 7 所示的示例中，为构建 bi+1 的 SWA-Trie Ti+1，该算法从 Ti 中删除 o1，然后将 o5 插入 Ti+1。 之后，以自下而上的方式计算新节点 {n8, n9, n10, n11}。 值得注意的是，我们不需要从头开始重新计算新根 n8 的累积值。 相反，我们可以调用 ACC.Update 以根据更新的对象 ID 增量更新累积值。
  
  没怎么看明白到底是咋回事儿？一个个的往后滚，还是怎么办？
  

C. 可验证的查询处理

给定一个形式为 Q = ⟨[ts, te], Υ⟩ 的布尔查询，SP 应返回该时间段内关键字满足布尔表达式 Υ 的所有数据对象，即 {oi = ⟨ti,Wi⟩ | ti ∈ [ts, te] ∧ Υ(Wi) = 1}。 为了处理查询请求，我们的算法包括三个步骤。 首先，查询将被划分为一组子查询，每个子查询的时间窗口长度为 k。 然后，将利用 SWA 索引和 ObjReg 索引来处理每个子查询。 最后，将所有子查询的结果进行合并，生成最终结果。 整个查询处理过程在算法 2 中给出。

1）查询划分：给定一个查询Q，如果查询时间窗口长度不小于k，则将Q分成多个k个长度的子查询。 如果查询窗口不能正确划分，我们让最后一个子查询的时间窗口与前一个子查询的时间窗口重叠。 例如，假设 k = 4，给定一个时间窗为 [t1, t10] 的查询，除了时间窗为 [t1, t4] 和 [t5, t8] 的子查询外，最后一个子查询将创建为 时间窗口 [t7, t10]。 请注意，这可能会产生冗余结果，但不影响查询处理的正确性。 另一方面，如果查询时间窗口长度小于 k，Q 将被视为一个特殊的子查询，这将在第 IV-C3 节中讨论。
2）子查询处理：对于每个时间窗长度为k的子查询q = ⟨[ts′ , te′ ], Υ⟩，我们首先遍历位于块be′的SWA-Trie得到中间结果 Rw 与 Υ 中的每个关键字 w 对应的 Merkle 证明 πw。 为了减小证明大小，我们将 πws 合并为 πtrie。 然后，对中间结果进行基于Υ的可验证集合运算，得到结果ID集合RΥ和集合运算证明πΥ。 最后，SP 将查询位于 be’ 中的 ObjReg 索引以找到对应的具有 Merkle 证明 πobj 的数据对象。
更具体地说，首先，对于 Υ 中的每个关键字 w，SP 搜索 SWA-Trie 以找到包含 w 的 trie 中的所有对象，总结在算法 3 中。SP 从根开始，遍历 SWA-Trie 自上而下的方式。 如果某个 trie 节点 n 的关键字段与 w 不匹配，则该节点下的所有数据对象都不属于 Rw。 在这种情况下，如果 n 是叶节点，SP 将 wn 和 accn 添加到 πtrie 作为 Merkle 证明的一部分； 否则，SP 将 wn 和 childHashn（以及如果 n 是根，则添加 accn）到 πtrie。 对于每个关键字段匹配w的节点n，如果是叶子节点，SP将Sn添加到Rw和wn，accn到πtrie； 否则，将进一步探索子树，并将 wn（以及如果 n 是根，则为 accn）添加到 πtrie。 请注意，不同关键字的 Merkle 证明可以共享一些共同的路径。 因此，可以组合 Υ 中所有关键字的 Merkle 证明来减小证明大小。

例子。 在图 8 的示例中，考虑具有时间窗口 [ti-2, ti+1] 和两个关键字 5e7a 和 5e9b 的子查询。 我们应该搜索位于bi+1 中的trie Ti+1。 我们将得到结果 R5e7a = S6 = {id3, id4}, R5e9b = S7 = {id2, id3} 和 Merkle 证明 πtrie = {⟨*, acc8⟩, ⟨5e⟩, ⟨9a, childHash9⟩, ⟨7a, acc6⟩，⟨9b，acc7⟩}。

SP 在得到 trie 搜索的中间结果后，将使用集合累加器根据 Υ 进行可验证的集合操作。 为了支持任意布尔查询，包括 ¬ (NOT)、∧ (AND) 和 ∨ (OR) 运算符，我们使用了 [9] 中提出的累加器。 具体来说，查询布尔表达式中的¬、∧和∨运算符可以映射到集合累加器方案中对应的集合差（\）、集合交（∩）和集合并（∪）操作。

例子。在图 8 的运行示例中，对于布尔函数 Υ1 = 5e7a ∧ 5e9b，SP 可以得到结果 RΥ1= R5e7a ∩R5e9b = {id3} 和集合操作证明 πΥ1通过调用 ACC.Prove(R5e7a, R5e9b, ∩, pk)。同理，对于布尔函数Υ2 = 5e7a ∨ 5e9b，SP可以得到结果RΥ2
= R5e7a∪R5e9b = {id2, id3, id4} 和集合操作证明 πΥ2 通过调用 ACC.Prove(R5e7a, R5e9b, ∪, pk)。
对于布尔函数 Υ3 = ¬5e9b，SP 首先检索 Ti+1 中的所有对象 ID，即 R∗ = {id2, id3, id4, id5}，其 Merkle 证明 π∗ = {⟨∗, childHash8)⟩ }。然后，可以进行可验证集差运算，得到结果 RΥ3
= R∗ \ R5e9b = {id4, id5} 和证明 πΥ3
通过调用 ACC.Prove(R∗, R5e9b, , pk)。对于布尔函数 Υ4 = 5e7a ∧ (¬5e9b)，可以执行可验证集差 R5e7a \ R5e9b。对于布尔函数 Υ5 = 5e7a ∨ (¬5e9b)，将执行嵌套的可验证集合操作。具体来说，SP 将首先在 R∗\R5e9b 上调用 ACC.Prove 以获得 R¬5e9b。然后计算一个可验证的集合并集 R5e7a ∪ R¬5e9b 得到集合操作证明
接下来，SP 查询位于 be’ 中的 ObjReg 索引，根据结果 ID 找到对应的数据对象。 它还为检索到的结果对象计算 Merkle 证明 πobj。 请注意，最后一个子查询的结果可能与其前一个子查询共享一些公共对象。 这样，当搜索最后一个子查询的数据对象时，SP 将不会搜索在前一个子查询中已经获得的那些。 最后，SP 将 πtrie、RΥ、πΥ 和 πobj 打包在一起作为子查询的 VO。

3）结果合并：SP得到每个子查询的结果后，将它们合并为原始查询的最终结果。

注意，在查询时间窗口[ts, te]的长度小于k的特殊情况下，查询Q会进行如下处理。 SP 将首先访问块 be 并获得结果集 RΥ = {oi = ⟨ti,Wi⟩ | ti ∈ [te−k+1, te]∧Υ(Wi) = 1} 与证明。 接下来，SP 定位块 bs-1，其 SWA-Trie 的根节点用于检索 ID 集 Sns-1
所有对象的在滑动窗口 [ts−k, ts−1] 及其累加值 accns−1. 之后，SP 调用一个可验证的集合差异操作 ACC.Prove(RΥ, Sns-1, , pk) 来计算结果集合。

D、 查询结果验证

在用户方面，可以通过以下步骤验证查询结果的完整性。 首先，用户从 VO ⟨πtrie, RΥ, πΥ, πobj⟩ 中提取证明。 然后，用户可以通过分别使用 πtrie 和 πobj 重构根哈希来验证 SWA-Trie 索引上的关键字搜索和 ObjReg 索引上的对象搜索的完整性。 如果它们与存储在块头中的匹配，我们可以确定这些搜索的健全性和完整性。 之后，用户可以使用 πΥ 执行 ACC.Verify 来检查布尔函数 Υ 的集合操作的完整性。 完整的验证过程在算法 4 中给出。

例子。 在图 8 的运行示例中。在接收时
查询结果和VO，用户首先重构trie根哈希h′8 使用 πtrie 如下： h′6=H(H(7a)||acc6),H’7 = H(H(9b)||acc7), h′3=H(5e||H(h′6||h′7)), h′9 =H(9a||childHash9) 和 h′8 = H(*||H(h′3||h’ 9)||acc8)。 如果 h′8与从块头中检索到的 h8 相同，则验证了关键字搜索的完整性。 接下来，用户使用 πobj 验证关于 RΥ 的对象结果。 最后，用户通过调用 ACC.Verify 来验证集合操作的完整性（例如，ACC.Verify(acc6, acc7, ∩, πΥ, acc(RΥ), pk)。

扩展到其他查询类型

在本节中，我们将讨论如何扩展我们提出的方法以支持其他查询类型，例如范围查询和布尔范围查询。

之前的就是关键字查询的过程。

VI 优化

我们观察到查询处理的瓶颈在于可验证集操作，其开销由输入集的大小决定。 在本节中，我们提出了三种优化技术来提高查询性能。
一维范围查询。 给定 Q = ⟨[ts, te], [α, β]⟩ 形式的范围查询，SP 应返回数值在 [α, β] 范围内的所有数据对象，即 {oi = ⟨ti, vi⟩ | ti ∈ [ts, te] ∧ vi ∈ [α, β]}。 我们可以按照类似的滑动窗口设计来进行查询处理。 矿工可以构建一个 SWA-B±Tree 来索引数据对象的数值。 图 9 显示了这样一个 SWA-B±Tree 的示例，其中索引滑动窗口大小为 4。每个树节点 n 包含以下字段：哈希摘要（用 hn 表示）、数值或数值范围（用 vn 或 [ln, un])，一个对象 ID 集合（用 Sn 表示），以及对应的集合累加值（用 accn 表示）。 我们将它们定义如下。
定义

实验评估

我们在一台配备双 Intel Xeon E5-2620 v3 2.4GHz CPU、运行 CentOS 8 的机器上进行实验。我们限制查询用户在验证期间只能使用 4 个线程，而矿工和 SP 使用所有可用的 CPU 内核。 vChain+ 系统是用 Rust 编程语言实现的，并使用了以下依赖项：Arkworks 用于在 BN254 曲线上进行双线性配对以实现集合累加器，Blake2b3 用于 256 位哈希运算，Rayon4 用于并行计算。 源代码可在 https://github .com/hkbudb/vchain-plus。 相同的编程语言和依赖项也用于实现 vChain [4] 作为基线，包括两个建议的累加器结构，标记为 vChain-acc1 和 vChain-acc2。
两个累加器结构：

数据集

Foursquare (4SQ) [5]：4SQ 数据集包括 100 万条带有时间戳的用户签到记录。 我们将每 30 秒内的记录打包为一个块，每条记录以 ⟨timestamp、[longitude, latitude]、{check-in place’s keywords}⟩ 的形式表示。
• 以太坊 (ETH) [2]：ETH 数据集是从 2018 年 12 月 17 日至 2018 年 12 月 26 日的以太坊区块链中提取的。 它包含约 58,100 个区块，约 327 万条交易记录，区块的时间间隔约为 15 秒。 每条记录可以用⟨timestamp, [amount], {addresses}⟩的形式表示，其中amount是转账金额，{addresses}是发送方和接收方的地址。

性能评估：
（1）查询的CPU的时间：sp的查询时间+用户结果验证时间
（2）从sp传输到用户的VO（Verification object）大小
交集、并集不同数据集的查询结果。
范围查询性能
交集+范围查询
并集+范围查询

CPU的查询时间和OV的大小。
我们可以测CPU的查询时间
随机生成10个查询and计算平均值
A、ADS （authenticated data structure）认证数据结构
建设成本表二显示了矿工侧的 ADS 建设成本，包括 ADS 建设时间和 ADS 大小。 在 vChain 中，块间索引的最大大小设置为 32。对于 vChain+，我们将滑动窗口大小设置为 {2,4,8,16,32}，SWA-B±tree 的扇出和 ObjReg 索引为 4。第 VI 节中介绍的所有优化都用于 vChain+。 从表二可以看出，vChain+的索引构建时间比vChain-acc2长，但比vChain-acc1短。 此外，与 vChain 相比，vChain+ 产生更大的 ADS。 这是意料之中的，因为 vChain+ 中使用的集合累加器的大小比 vChain 中使用的更大，以支持更具表现力的集合操作。 此外，正如我们在第 VI-A 节中讨论的那样，多个滑动窗口的设计引入了多个 SWA（sliding window accumulator） 索引，这也增加了每个块中的 ADS 大小。 在用户端，块头的大小固定为 104 字节在Vchain和Vchain+中。
B、查询性能
图 10 到 17 对比 vChain 的查询性能和 vChain+ 通过将查询时间窗口从 100 个块更改为 8,100 个块。检查了五种类型的查询条件，包括∨-和∧-连接的布尔关键字查询、仅范围查询和∨-和∧-连接的布尔范围查询。得益于基于树的索引搜索和基于累加器的滑动窗口设计，vChain+ 可以高效处理各种类型的查询。总体而言，vChain+ 对 vChain-acc2 的查询性能提高了 913 倍，对 vChain-acc1 提高了 1098 倍。请注意，在大多数情况下，vChain+ 的 VO 大小比 vChain 大。这是因为 vChain+ 生成的集合操作证明的大小比 vChain 中的要大。然而，考虑到全球平均 29.06 Mbps 的移动网络速度 [12]，vChain+ 的 VO 传输和查询处理的总时间仍然优于 vChain。例如，如图16所示，查询时间窗口为8100时，vChain+的VO大小和查询时间分别为623KB和0.05s，vChain-acc2的VO大小和查询时间分别为68KB和1.59s。移动网速中值下vChain+的VO传输和查询处理总时间为0.221s，仍提升vChain性能7.3倍。在 ETH 上处理 ∨ 连接的布尔范围查询时，我们观察到当时间窗口长度为 100 个块时，vChain-acc2 的性能略优于 vChain+（图 17）。 这是因为集合操作证明的生成支配了 vChain+ 中的查询时间。 由于 ∨ 连接布尔条件涉及联合操作，它会导致 ACC.Prove 的输入集扩大，从而导致更繁重的密码操作。
C. 优化和选择性的影响
我们现在评估三种不同优化技术对查询性能和 VO 大小的影响。 我们在 ETH 数据集上测试 ∧ 连接的布尔范围查询。 我们启用所有优化作为基线（表示为全部），然后禁用每个优化以调查它们的影响。 具体来说，我们在 (i) 没有多滑动窗口（没有 multi-win）、（ii）没有优化查询计划（没有 qp）和（iii）没有修剪空集（没有修剪）的情况下运行实验。 图 18 通过将查询时间窗口从 100 块更改为 8,100 个块显示了不同优化的查询性能。 可以看出，修剪空集和优化查询计划对大多数查询都有效，并带来了最大的性能提升。