CN111339106B - 一种区块链数据索引的方法 - Google Patents

Abstract

本发明公开了一种区块链数据索引的方法，该方法首先持久化区块到区块文件，持久化一层索引数据到索引数据库，然后根据查询条件获取符合的交易位置，最后从区块文件得到完整交易。本发明通过扩展区块链数据存储的处理过程，将区块链索引数据存储在独立索引数据库中且保证多数据库事务原子性，建立了一种将业务信息自定义在交易附注字段，然后通过自定义交易附注索引字段来关联交易与业务信息的联系，最后基于交易关键信息从而获取完整交易的数据索引机制；由于无需对区块链上的区块进行重新遍历和解析就能快速索引到具体交易，极大地提高了区块链交易回溯的效率，同时又保证了数据可靠性，为交易数据回溯奠定基石。

Description

一种区块链数据索引的方法

技术领域

本发明属于区块链技术领域，尤其涉及一种区块链数据索引的方法。

背景技术

随着区块链技术的快速发展和普及，区块链的技术研究及其衍生应用也呈现出爆发式的增长。区块链数据不可篡改、数据可验证以及数据可追溯的特点，使其成为实现智慧政务、智慧医疗、慈善追踪和存证溯源的核心前沿技术。现有区块链***一般采用Key-Value型数据库存储引擎以及文件存储的混合存储架构，对于区块与交易这种连续型数据存储在文件，其它数据存储在Key-Value型NoSQL数据库。因此，对于数据的检索，只能基于Key值进行粗粒度查询，无法针对Value的结构化数据进行检索。比如，想要查询某个账户下面的所有交易，则必须遍历整个区块链，以区块号为Key得到对应的Value，反序列化区块的内容，然后筛选出交易发送方和交易接收方都为指定账户的交易。这种查询方法效率极低，不具备可用性。再比如，用户想要筛选出与某个业务应用相关的交易，只能根据交易接收方（也即合约地址）来过滤，无法根据业务数据来过滤，对用户来说，直观性不够强。

为了解决这个问题，现有的一些解决方案包括两个：1.在链外部署关系型数据库实时同步区块链上的数据，将从区块链上同步过来的数据进行结构化存储。2.使用关系型数据库作为底层区块链***的存储架构。前者数据同步效率较低、实时性不强、增加了额外冗余存储开销，并且从链外数据库进行查询已然脱离了区块链，数据不具备可靠性。后者将区块链区块数据、交易数据结构化，存储到关系型数据库中，对于现有基于Key-Value型的存储架构来说改造成本较高且性能表现不如NoSQL。

因此，如何扩展现有存储架构，在尽最大努力减少额外冗余存储开销、减少对***吞吐量影响的基础上，使得现有区块链***支持基于Value的查询，甚至支持快速检索与某个业务相关的交易，是区块链广泛应用于溯源场景需要关注的重点问题。

发明内容

本发明的目的在于针对现有技术的不足，提供一种区块链数据索引的方法。

本发明的目的是通过以下技术方案来实现的：一种区块链数据索引的方法，包括以下步骤：

（1）区块链客户端生成一笔区块链交易发送给验证节点；所述区块链交易包括交易发送方、交易接收方、交易生成时间、交易附注和交易附注索引；所述交易附注索引的数据类型为数字、字符串或者数组；所述数组由数字、字符串中至少一种组成，数组中的元素是有序的；

（2）验证节点接收到步骤（1）发送的交易，共识产块生成区块后执行区块，然后提取区块中每条交易的交易关键信息，组成交易关键信息列表，构建一层索引数据；所述一层索引数据包括区块号和交易关键信息列表；所述交易关键信息包括交易发送方、交易接收方、交易生成时间、交易附注索引、交易在区块内的位置；

（3）验证节点持久化步骤（2）生成的区块到区块文件，持久化步骤（2）构建的一层索引数据到索引数据库；

（4）客户端向验证节点发送查询请求，包括查询条件和检索模式；所述查询条件由指定的交易发送方、交易接收方、交易生成时间、交易附注索引中的一个或多个组成；所述检索模式包括多条件与查询、多条件或查询、基于交易附注索引的按序精准查询、基于交易附注索引的非按序精准查询和基于交易附注索引的非按序匹配查询；

（5）验证节点根据步骤（4）中客户端发送的查询请求中的检索模式，从步骤（3）得到的索引数据库里获取符合查询条件的交易关键信息对应的区块号和交易在区块内的位置，从步骤（3）得到的区块文件里查询得到完整交易，返回给客户端。

进一步地，当查询条件只有交易附注索引且为指定的数组时，所述检索模式选自基于交易附注索引的按序精准查询、基于交易附注索引的非按序精准查询或基于交易附注索引的非按序匹配查询；当查询条件为其它情况时，所述检索模式选自多条件与查询或多条件或查询。

进一步地，所述多条件与查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息符合查询条件的所有项； 所述多条件或查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息符合查询条件中至少一项；其中，某条交易的交易关键信息中的交易发送方、交易接收方或交易生成时间与查询条件中指定的交易发送方、交易接收方或交易生成时间相同时，表示该条交易的交易关键信息符合查询条件中对应的一项；当查询条件中指定的交易附注索引为数组时，某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素及其顺序相同时，表示该条交易的交易关键信息符合查询条件中的该项；当查询条件中指定的交易附注索引不是数组时，某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的数字或字符串相同时，表示该条交易的交易关键信息符合查询条件中的该项。

进一步地，所述基于交易附注索引的按序精准查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素及其顺序相同；所述基于交易附注索引的非按序精准查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素相同；所述基于交易附注索引的非按序匹配查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引包括至少一个查询条件中指定的交易附注索引的元素。

进一步地，进一步对步骤（3）得到的索引数据库中的一层索引数据中的某个字段创建原生数据库索引作为二层索引，验证节点将新交易构建的一层索引数据持久化到索引数据库时，自动更新二层索引。

进一步地，所述二层索引为全部索引或部分索引；所述全部索引指为索引数据库内每个一层索引数据的某个字段创建原生数据库索引；所述部分索引指针对一层索引数据的某个字段，选择索引数据库内部分一层索引数据来创建其某个字段的原生数据库索引，即创建部分索引的时候，添加过滤表达式来指定对哪一些一层索引数据建立二层索引，哪一些一层索引数据不建立二层索引。

进一步地，所述交易附注为区块链客户端自定义的任何与交易相关的数据；所述交易附注索引为区块链客户端自定义的任何与交易相关的索引。

进一步地，所述数组中的元素不超过30个。

进一步地，所述字符串不超过1024位。

进一步地，所述区块文件支持Key-Value型查询；所述索引数据库采用支持类SQL查询的非关系型数据库。

本发明的有益效果是：本发明通过扩展区块链数据存储的处理过程，将区块链索引数据存储在独立索引数据库中且保证多数据库事务原子性，建立了一种将业务信息自定义在交易附注字段，然后通过自定义交易附注索引字段来关联交易与业务信息的联系，最后基于交易关键信息从而获取完整交易的数据索引机制。由于无需对区块链上的区块进行重新遍历和解析就能快速索引到具体交易，极大地提高了区块链交易回溯的效率，同时因为数据源于区块链账本而不是区块链之外的数据库，又保证了数据可靠性，为交易数据回溯奠定基石。

附图说明

为了更清楚地说明本发明的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本发明实施例提供的一种区块链数据索引的方法的流程示意图；

图2是本发明实施例提供的一种区块链数据索引的方法中一层索引数据结构示意图；

图3是本发明实施例提供的一种区块链数据索引的方法中数据流向示意图；

图4是本发明实施例提供的一种基于区块链的跨行转账业务***架构图。

具体实施方式

下面根据附图和具体实施例详细描述本发明，本发明的目的和效果将变得更加明显。

一种区块链数据索引的方法，具体的如图1所示，包括如下步骤：

S1，区块链客户端生成一笔区块链交易发送给验证节点；

所述区块链交易包括交易参与方、交易生成时间、交易附注信息和交易附注索引信息，交易参与方包括交易发送方和交易接收方。其中，交易附注信息字段和交易附注索引信息字段，是本发明对现有交易数据结构的扩展。

所述交易附注信息字段为由客户端自定义的任何与业务相关的数据，比如存证哈希、商品信息、版权信息等；

所述交易附注索引信息字段为客户端自定义的任何与业务相关的索引信息，其数据类型为数字、字符串（不超过1024位）或者数组；所述数组由数字、字符串中至少一个组成，表示区块链交易拥有多个交易附注索引信息，数组中的元素（数字、字符串）不超过30个，该索引信息可以与交易附注信息字段存在对应关系，也可以不存在对应关系，这完全取决于客户端是如何定义的。根据交易附注索引信息字段可以快速定位到具体某一条或多条交易，从而得到交易里定义的完整业务数据，比如根据交易附注索引字段里定义的商品ID得到定义在交易附注字段里的商品详情、根据交易附注索引字段里定义的商品ID以及商品增删改查操作码得到定义在交易附注字段里的操作详情、根据交易附注索引字段存储的上一次业务操作关联的交易哈希来追溯前一笔交易，等等。这两个字段的内容完全由客户端自由定义，节点不必关心其内容是什么，只需要限制这两个字段的大小防止DDoS攻击。通过这种设计，客户端可以运用区块链的特性，灵活开发自己想要的应用。

S2，验证节点接收到步骤S1发送的交易，共识产块生成区块后执行区块；然后根据区块数据和交易数据提取出区块内每条交易的关键信息，构建一层索引数据。

如图2所示，所述一层索引数据以区块为单位，包括区块号和交易关键信息列表两个字段。所述交易关键信息列表里的每一条交易均包括交易参与方、交易生成时间、交易附注索引信息、交易在区块内的位置信息。

S3，验证节点持久化步骤S2生成的区块到区块文件，持久化步骤S2构建的一层索引数据到索引数据库。

如图3所示，一层索引数据与对应的区块存储在同一验证节点的不同数据库里。所述区块存储在支持Key-Value型查询的区块文件里，其中Key为区块号，Value为区块详情；区块文件只支持根据区块号得到区块详情，进而根据区块号以及交易在区块内的位置得到交易详情。所述一层索引数据存储在索引数据库，索引数据库为支持类SQL查询的非关系型数据库，比如MongoDB。一层索引数据仅仅为交易关键信息，被存储在索引数据库，而交易的完整的详细信息及交易附注信息存储在区块文件中，这有效避免了索引数据库过多的冗余存储。

索引数据库与区块文件的数据***具备事务原子性，所述事务原子性指的是节点每生成一个区块，会产生一个数据***事务，多个数据库的***需要保证事务原子性，要么所有数据库都成功***新数据，要么都不***新数据。如果区块成功写入到区块文件，而索引数据库数据***失败，则区块文件进行回滚。如果索引数据库成功***索引数据，而区块文件写入失败，则索引数据库进行回滚。因此，只要节点生成并存储了一个新区块，就可以认为会生成对应的索引数据存储在索引数据库里。

S4，如图3所示，客户端向验证节点发送查询请求时，验证节点根据客户端发送的查询条件，从步骤S3的索引数据库里获取符合查询条件的交易，得到该交易所在区块号以及交易在区块内的位置信息，再根据区块号和交易在区块内的位置信息从步骤S3的区块文件里以O(1)时间复杂度查询得到完整交易，返回给客户端；

所述查询请求包括查询条件和检索模式。

所述查询条件由交易发送方、交易接收方、交易生成时间、交易附注索引信息条件中的任意一个或者多个组成；其中，交易附注索引信息为数组时，其中的数字或字符串有相应的顺序。

所述检索模式包括多条件与查询、多条件或查询、基于交易附注索引信息的按序精准查询、基于交易附注索引信息的非按序精准查询和基于交易附注索引信息的非按序匹配查询。当查询条件只有交易附注索引信息且为数组时，检索模式选自基于交易附注索引信息的按序精准查询、基于交易附注索引信息的非按序精准查询或基于交易附注索引信息的非按序匹配查询；当查询条件为其它情况时，检索模式选自多条件与查询或多条件或查询。

所述多条件与查询为验证节点从索引数据库里检索出交易信息完全符合查询条件的交易；即当查询条件包括交易发送方、交易接收方或交易生成时间时，对应地，检索出的交易信息中的交易发送方字段、交易接收方字段和交易生成时间字段的值等于查询条件指定的交易发送方、交易接收方和交易生成时间的值；当查询条件包括交易附注索引信息条件时，对应地，检索出的交易信息中的交易附注索引字段等于查询条件指定的交易附注索引值，对应地，如果查询条件里指定的交易附注索引值为一个数组，则检索出的交易信息的交易附注索引字段值也为一个数组，且数组里元素值及元素顺序与查询条件指定的数组完全一致。

所述多条件或查询为验证节点从索引数据库里检索出交易信息部分或完全符合相同查询条件的交易；即检索出的交易信息至少符合查询条件中的一项，其中仅当检索出的交易信息包括交易附注索引信息条件的指定值及其顺序时，认为该交易信息符合查询条件中的交易附注索引信息条件。

所述基于交易附注索引信息的按序精准查询为验证节点从索引数据库里检索出交易附注索引字段完全等于查询条件指定的交易附注索引字段的交易；当查询条件里指定的交易附注索引信息的数据类型为数组时，则要求索引数据库检索出来的交易中的交易附注索引字段必须为一个数组，且数组的元素和顺序完全等于查询条件指定的交易附注索引字段指定的值和顺序。

所述基于交易附注索引信息的非按序精准查询为验证节点从索引数据库里检索出交易附注索引字段包含查询条件指定的全部交易附注索引信息的交易；这种检索模式下，查询条件指定的交易附注索引信息的数据类型必须为数组，要求索引数据库检索出来的交易中的交易附注索引字段必须为一个数组且包含查询条件指定的交易附注索引信息数组里的所有值，对数组里值的顺序无要求。

所述基于交易附注索引信息的非按序匹配查询为验证节点从索引数据库里检索出交易附注索引字段包含部分或全部的查询条件指定的交易附注索引信息的交易；这种检索模式下，查询条件指定的交易附注索引信息的数据类型必须为数组，索引数据库检索出来的交易中的交易附注索引字段为数组或者非数组，只要包含或等于查询条件数组里的任意值即可。如果检索到的交易附注索引字段为数组且数组里包含多个查询条件指定的交易附注索引信息数组里指定的多个值，不管这些值在数组里的顺序是否与查询条件数组一致，都认为是符合查询条件的交易；

随着数据量的剧增，索引数据库的检索效率将受到数据量的影响；为了进一步加快数据检索效率，当查询条件使用率较高且查询效率低下时，对索引数据库一层索引中的区块号、交易参与方、交易生成时间、交易附注索引信息等字段中的某个字段创建索引，即二层索引来提高索引数据库查询效率。如果验证节点创建了二层索引，则步骤S3持久化一层索引数据到索引数据库的时候，自动更新索引数据库的二层索引。

所述二层索引指为索引数据库内一层索引中的某个字段创建的原生数据库索引，其目的是加快索引数据库内数据查询效率。区块链网络里运行着多个去中心化应用，往往区块链节点查询条件使用率取决于区块链之上的不同应用场景，而不同应用场景生成的交易结构都是一样的。假设，区块链上运行了多个去中心化应用（DApp），其中，DApp A对根据交易附注索引信息查询完整交易详情的需求比较大，该查询条件使用率比较高，为了提升Dapp A该查询条件下的查询效率，一般会对索引数据库内的交易附注索引字段创建二层索引。但是，对于其他DApp来说，对该查询条件的使用率并不大，而与这些DApp相关的交易也会生成对应的二层索引数据，浪费了节点存储空间。

因此，所述二层索引需要分为全部索引和部分索引。所述全部索引指为索引数据库内全部一层索引的某个字段创建原生数据库索引。所述部分索引指通过过滤表达式来为索引数据库内部分一层索引的某个字段创建原生数据库索引，即创建二层索引的时候，添加过滤表达式来指定对哪些一层索引的该字段建立二层索引，哪些不建立二层索引。部分索引可以降低存储压力，减少创建二层索引、更新二层索引带来的性能损耗。在区块链的交易结构里，账户地址有内部账户地址和外部账户地址，内部账户地址指的是普通转账的账户地址，外部账户地址指的是合约地址，交易结构里的交易接收方可以为内部账户地址或外部账户地址。因此，可以为每个DApp初始化一个外部账户地址，然后通过交易接收方地址来区分不同的DApp。为了进一步说明，继续以前文提到的例子为例，我们可以为DApp A创建部分索引来提高其根据交易附注索引信息查询完整交易详情的查询效率，并指定该部分索引的过滤表达式：交易接收方地址为DApp A地址。通过这种做法，可以使得节点只为交易接收方地址为DApp A地址的交易创建二层索引，而对其他交易不创建二层索引。

具体的，为了便于读者进一步理解一种区块链数据索引方法所带来的收益效果，下面将举例子来详细介绍一种区块链数据索引方法。

示例性的，一个基于区块链的跨行转账业务***，***总体架构如图4所示，银行A和B分别部署了两个区块链验证节点，并且都有各自的业务***。

假设银行A的用户转账给银行B的用户，一笔跨行转账流水包括发出方发起转账申请，然后由银行A和银行B对该申请进行审批，审批内容为验证用户账户是否合法、账户是否冻结以及余额是否足够，审批通过以后才进行转账扣款。由此可见，转账流水是由多个步骤组成，每个步骤都对应一笔区块链交易用于记录转账流水的状态。业务***需要查询转账流水的状态才能得知用户跨行转账是否成功。在这种业务背景下，就需要有一个转账流水ID来作为每次转账的唯一标识，并且能够使用转账流水ID作为查询条件，从验证节点查询得到与该转账流水相关的区块链交易。因此，需要将转账流水ID定义在交易附注索引字段，然后通过由包括交易附注索引信息的查询条件和基于交易附注索引的按序精准查询检索模式组成的查询请求，从验证节点查询得到需要的区块链交易数据。

示例性的，一个基于区块链的音乐版权信息追踪***，通过本发明提供的技术很容易实现音乐版权信息的公开透明性、侵权可追踪性。比如，歌曲所有者将歌曲版权信息发布到区块链上，歌曲版权信息包括作词者、作曲者、演唱者、版权所有者等等，如果歌曲使用者利用该歌曲获取商业收益且不在版权所有者里面，则可认为该使用者存在侵权。每一次歌曲版权的变更都对应生成一笔区块链交易用于记录最新版权信息。在这种业务背景下，歌曲版权信息定义在交易附注字段，歌曲音频文件哈希定义在交易附注索引字段，然后通过由包括交易附注索引信息的查询条件和基于交易附注索引的按序精准查询检索模式组成的查询请求，从验证节点查询得到符合条件的区块链交易数据，进而得到定义在交易附注字段的详细歌曲版权信息。

示例性的，下面列举基于交易附注索引信息的按序精准查询、基于交易附注索引信息的非按序精准查询和基于交易附注索引信息的非按序匹配查询这三种检索模式的查询例子，来促进读者对这类检索模式的理解，进而开发出期望的基于区块链的业务***。

假设将交易附注字段命名为“EXTRA”，将交易附注索引字段命名为“EXTRA_ID”，进一步地，假设现在区块链上存在EXTRA_ID分别为 [123, "abc"]、["abc", 123]、[123, "efg", "abc"]、[123]、["abc"]、123、"abc"的7笔交易。

当检索模式为基于交易附注索引信息的按序精准查询时：

如果查询条件为{ "EXTRA_ID": [123] }，则符合查询条件的 EXTRA_ID 只有一个: [123]。

如果查询条件为{ "EXTRA_ID": "abc" }，则符合查询条件的 EXTRA_ID 只有一个: "abc"。

如果查询条件为{ "EXTRA_ID": [123, "abc"] }，则符合查询条件的 EXTRA_ID只有一个: [123, "abc"]。

当检索模式为基于交易附注索引信息的非按序精准查询时：

如果查询条件为 { "EXTRA_ID": 123 } 或者 { "EXTRA_ID": "abc" }，则返回错误。因为这种检索模式下，查询条件必须为数组类型。

如果查询条件为 { "EXTRA_ID": [123] }，则符合查询条件的 EXTRA_ID有四个：[123, "abc"]、["abc", 123]、[123, "efg", "abc"]、[123]。

如果查询条件为 { "EXTRA_ID": [123, "abc"] }，则符合查询条件的 EXTRA_ID有三个：[123, "abc"]、["abc", 123]、[123, "efg", "abc"]。

当检索模式为基于交易附注索引信息的非按序匹配查询时：

如果查询条件为 { "EXTRA_ID": 123 } 或者 { "EXTRA_ID": "abc" }，则返回错误。因为这种检索模式下，查询条件必须为数组类型。

如果查询条件为 { "EXTRA_ID": [123] }，则符合查询条件的 EXTRA_ID有五个：[123, "abc"]、["abc", 123]、[123, "efg", "abc"]、[123]、123。

如果查询条件为 { "EXTRA_ID": [123, "abc"] }，则所有 EXTRA_ID都符合查询条件，即：[123, "abc"]、["abc", 123]、[123, "efg", "abc"]、[123]、["abc"]、123、"abc"。

Claims (9)

1.一种区块链数据索引的方法，其特征在于，包括以下步骤：

(1)区块链客户端生成一笔区块链交易发送给验证节点；所述区块链交易包括交易发送方、交易接收方、交易生成时间、交易附注和交易附注索引；所述交易附注索引的数据类型为数字、字符串或者数组；所述数组由数字、字符串中至少一种组成，数组中的元素是有序的；

(2)验证节点接收到步骤(1)发送的交易，共识产块生成区块后执行区块，然后提取区块中每条交易的交易关键信息，组成交易关键信息列表，构建一层索引数据；所述一层索引数据包括区块号和交易关键信息列表；所述交易关键信息包括交易发送方、交易接收方、交易生成时间、交易附注索引、交易在区块内的位置；

(3)验证节点持久化步骤(2)生成的区块到区块文件，持久化步骤(2)构建的一层索引数据到索引数据库；

(4)客户端向验证节点发送查询请求，包括查询条件和检索模式；所述查询条件由指定的交易发送方、交易接收方、交易生成时间、交易附注索引中的一个或多个组成；所述检索模式包括多条件与查询、多条件或查询、基于交易附注索引的按序精准查询、基于交易附注索引的非按序精准查询和基于交易附注索引的非按序匹配查询；

(5)验证节点根据步骤(4)中客户端发送的查询请求中的检索模式，从步骤(3)得到的索引数据库里获取符合查询条件的交易关键信息对应的区块号和交易在区块内的位置，从步骤(3)得到的区块文件里查询得到完整交易，返回给客户端；

所述基于交易附注索引的按序精准查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素及其顺序相同；所述基于交易附注索引的非按序精准查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素相同；所述基于交易附注索引的非按序匹配查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息中的交易附注索引包括至少一个查询条件中指定的交易附注索引的元素。

2.根据权利要求1所述区块链数据索引的方法，其特征在于，当查询条件只有交易附注索引且为指定的数组时，所述检索模式选自基于交易附注索引的按序精准查询、基于交易附注索引的非按序精准查询或基于交易附注索引的非按序匹配查询；当查询条件为其它情况时，所述检索模式选自多条件与查询或多条件或查询。

3.根据权利要求2所述区块链数据索引的方法，其特征在于，所述多条件与查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息符合查询条件的所有项；所述多条件或查询为验证节点从索引数据库里检索得到的某条交易的交易关键信息符合查询条件中至少一项；其中，某条交易的交易关键信息中的交易发送方、交易接收方或交易生成时间与查询条件中指定的交易发送方、交易接收方或交易生成时间相同时，表示该条交易的交易关键信息符合查询条件中对应的一项；当查询条件中指定的交易附注索引为数组时，某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的元素及其顺序相同时，表示该条交易的交易关键信息符合查询条件中的交易附注索引项；当查询条件中指定的交易附注索引不是数组时，某条交易的交易关键信息中的交易附注索引与查询条件中指定的交易附注索引的数字或字符串相同时，表示该条交易的交易关键信息符合查询条件中的交易附注索引项。

4.根据权利要求1所述区块链数据索引的方法，其特征在于，进一步对步骤(3)得到的索引数据库中的一层索引数据中的某个字段创建原生数据库索引作为二层索引，验证节点将新交易构建的一层索引数据持久化到索引数据库时，自动更新二层索引。

5.根据权利要求4所述区块链数据索引的方法，其特征在于，所述二层索引为全部索引或部分索引；所述全部索引指为索引数据库内每个一层索引数据的某个字段创建原生数据库索引；所述部分索引指针对一层索引数据的某个字段，选择索引数据库内部分一层索引数据来创建其某个字段的原生数据库索引，即创建部分索引的时候，添加过滤表达式来指定对哪一些一层索引数据建立二层索引，哪一些一层索引数据不建立二层索引。

6.根据权利要求1所述区块链数据索引的方法，其特征在于，所述交易附注为区块链客户端自定义的任何与交易相关的数据；所述交易附注索引为区块链客户端自定义的任何与交易相关的索引。

7.根据权利要求1所述区块链数据索引的方法，其特征在于，所述数组中的元素不超过30个。

8.根据权利要求1所述区块链数据索引的方法，其特征在于，所述字符串不超过1024位。

9.根据权利要求1所述区块链数据索引的方法，其特征在于，所述区块文件支持Key-Value型查询；所述索引数据库采用支持类SQL查询的非关系型数据库。

Images