CN109766389A - 一种基于位图索引的区块链轻客户端验证查询方法 - Google Patents

Abstract

本发明公开了一种基于位图索引的区块链轻客户端验证查询方法，包括位图索引及交易验证信息生成步骤，查询请求步骤，区块扫描步骤，查询处理步骤、数据验证步骤和计算查询结果步骤：位图索引及交易验证信息生成步骤是对不同交易类型构造索引结构和验证信息；发送查询请求步骤是轻客户端将查询请求发送至全节点；区块扫描步骤是全节点根据位图索引结构，快速扫描得到需要被查询的所有区块；数据查询步骤是全节点通过查询得到查询结果集，并返回给轻客户端；数据验证步骤是轻客户端对全节点返回的结果集进行验证，得到正确的查询结果集；计算查询结果步骤是轻客户端基于正确的查询结果集进行计算，得到最终的查询结果。

Description

一种基于位图索引的区块链轻客户端验证查询方法

技术领域

本发明属于区块链技术领域，尤其涉及基于位图索引的面向区块链轻客户端的验证查询方法。

背景技术

区块链系统在发展的早期阶段只有一种节点，就是现在所说的全节点。这种全节点负责验证以及转发网络上的交易和区块。由于无需信任的环境(开放的网络)以及区块链本身的性质，每个全节点都需要下载并验证所有的区块，因此所有区块中的所有交易信息都需要经过全节点的验证。

现在，有些组织以及个人运行着全节点是因为他们的工作需求。比如说矿工，区块浏览器以及交易所。个人用户可能会因为全节点是与区块链交互的最安全的方式而运行一个全节点。在规模小很多的情况下，他们也会因为纯粹的利他因素而来帮助维护网络。但是每时每刻运行着一个全节点需要消耗大量的资源。虽然全节点对网络至关重要，但是除了矿工之外，让普通用户运行全节点，来将其当作客户端是一种很大的负担。

轻客户端或者轻节点是一种连接全节点以实现与区块链的交互的软件。与全节点不同的是，轻客户端不需要不停地运行，也不需要向区块链中读取写入大量信息。实际上，轻客户端不需要直接与区块链交互，它们使用全节点作为中介。轻客户端依赖全节点实现许多操作，比如请求最新的区块头、请求账户的余额等。

与全节点相比，轻客户端只需要下载区块链的区块头，提供了更好的终端用户体验。轻客户端是区块链生态系统中十分重要的元素。它们可以帮助用户以安全、分散的方式访问区块链并与区块链进行交互而无需同步完整的区块链。

然而，轻客户端进行查询时，全节点会扫描所有的区块，从中筛选出查询请求所涉及到的部分区块。随着时间的推移，整个系统中的区块数会越来越多，扫描所有的区块会给全节点造成很大的开销，导致全节点查询效率低下。

并且，全节点会将查询请求涉及的全部区块中的全部数据都返回给轻客户端。轻客户端通过重建每个区块的Merkle Hash Tree来验证数据正确性。若一次范围查询涉及到的区块数量较多，则会给轻客户端造成很大的通信开销，严重影响轻客户端查询性能。

发明内容

本发明的目的是为了克服了现有技术的全节点扫描区块效率低，全节点与轻客户端通信开销大的缺陷，提出了一种基于位图索引的面向区块链轻客户端的验证查询方法。

实现本发明目的的具体技术方案是：

一种基于位图索引的面向区块链轻客户端的验证查询方法，该方法包括以下具体步骤：

步骤1：位图索引及交易验证信息生成

该步骤是对不同交易类型构造索引结构和验证信息，提高查询及验证效率，具体包括：

A1：全节点对所有的交易数据按照类型划分，得到多个分类；

A2：全节点为每一个分类创建一行二进制串数据，每一行中的第i位二进制数据代表区块i中是否包含这种交易类型的数据，1代表包含，0代表不包含；

A3：若出现一种新的交易类型，则添加新的一行二进制串数据来记录此类型交易，所有交易类型的二进制数据共同组成了位图索引结构；

A4：全节点在每一个区块中都为每一种交易计算出验证信息。

步骤2：查询请求

该步骤是轻客户端将查询请求发送至全节点，具体包括：

B1：轻客户端组装好查询请求；

B2：轻客户端将查询请求发送至全节点，等待接收返回结果。

步骤3：区块扫描

该步骤是全节点根据位图索引结构，快速扫描得到需要被查询的所有区块，具体包括；

C1：创建区块扫描结果集，并将区块扫描结果集初始化为空；

C2：为查询请求所涉及到的每种交易类型创建一个区块列表键值对，键是交易类型，值是包含这种交易类型数据的区块列表，比如<donate,BlockList<block1,block2,…>>；

C3：全节点根据交易类型找到位图索引中对应的行，依次对每种交易类型进行区块扫描；

C4：按位扫描该行中所有的二进制数据，若为0则跳过，若为1则将对应的区块加入步骤C2中创建的区块扫描列表中；

C5：每扫描完一种交易类型后，将对应的键值对放入区块扫描结果集中，直至扫描完所有的交易类型。最终得到的区块扫描结果集包含了每种交易类型及该种类型的交易数据所在的所有区块，如<<donate,BlockList<block1,…>>,<borrow,BlockList<block2,…>>>。

步骤4：查询处理

该步骤是全节点通过查询得到查询结果集，并返回给轻客户端，具体包括；

D1：创建数据查询结果集，并将数据查询结果集初始化为空；

D2：为区块扫描结果集中的每个区块列表键值对创建一个交易列表键值对，键是交易类型，和区块列表键值对中的键相同，值是属于这种交易类型的交易数据列表，比如<donate,TransactionList<transaction1,transaction2，…>>；

D3：全节点依次遍历区块扫描结果集中的区块列表键值对，取出每个键值对中的区块列表，进行查询；

D4：遍历区块列表中所有区块中的所有交易数据，若交易数据的交易类型与步骤D3中的键值对的键相同，则将交易数据加入步骤D2创建的交易数据列表中，并对交易数据进行处理；

D5：每遍历完一个区块列表键值对后，将键值对放入数据查询结果集中，直至查询完所有的区块扫描列表。最终得到的数据查询结果集包含了每种交易类型及该种交易类型所有的交易数据，如<<donate,TransactionList<transaction1,…>>,<borrow,TransactionList<transaction1,…>>>；

D6：将步骤D1创建的查询结果集返回给轻客户端。

步骤5：数据验证

该步骤是轻客户端对全节点返回的结果集进行验证，得到正确的查询结果集，具体包括：

E1：轻客户端使用步骤D6中返回的查询结果集，在每一个区块中都为每一种交易计算验证信息；

E2：用验证信息组装验证请求，并发送给网络中其他多个全节点；

E3：其他全节点在本地验证后，将验证结果返回给轻客户端；

E4：轻客户端通过步骤E1和E3中得到的验证结果来判断步骤D6中返回的查询结果集是否正确完整；

E5：若验证通过则得到正确完整的查询结果集，若验证未通过，则轻客户端向其他全节点重新发送查询请求。

步骤6：计算查询结果

该步骤是轻客户端基于正确的查询结果集进行计算，得到最终的查询结果，具体包括：

F1：对步骤B1中的查询请求进行判断，若是范围查询则执行步骤F2，若是连接查询则执行步骤F3；

F2：使用范围查询算法对查询结果集进行查询，得到最终的查询结果；

F3：使用连接查询算法对查询结果集进行查询，得到最终的查询结果。

其中，步骤A4或E1所述在每一个区块中为每一种交易计算验证信息，具体包括：

G1：统计出本区块所有的交易种类，分别为每一种交易求解验证信息；

G2：将本区块中某一种类的交易数据全部取出，按照交易产生时间排序，将所有交易数据作为哈希函数的参数，求解哈希值；

G3：本区块之前是否存在区块，若有则执行步骤G4，否则执行步骤G5；

G4：将前一个区块中相同种类交易的验证信息取出，和步骤G2中的哈希值一起再次作为哈希函数的参数，求解哈希值，该哈希值就是此种交易类型在本区块中的验证信息；

G5：步骤G2中求得的哈希值就是此种交易类型在本区块中的验证信息。

其中，步骤D4所述对交易数据进行处理，具体包括：

H1：根据交易数据所在的区块号以及交易号对其进行编码，如transaction是区块3中第8个交易，则对其编码为T3-8；

H2：对交易数据编码后，将该交易数据在步骤D2创建的交易数据列表中进行排序。如当期交易数据列表中有两个交易，分别是T1-1，交易的值为100。另一个T2-1的值为180。待插入的交易T3-8的值为150，则最终交易列表的顺序为，T1-1，T3-8，T2-1。

本发明采用6个不同步骤来处理，即位图索引及交易验证信息生成步骤，查询请求步骤，区块扫描步骤，查询处理步骤，数据验证步骤和计算查询结果步骤。执行位图索引及交易验证信息生成步骤时，对不同交易类型构造索引结构，能够提高查询效率。为每种交易类型在每个区块都计算出验证信息，使得客户端有效地进行验证。执行查询请求步骤时，轻客户端将查询请求发送至全节点，等待全节点进行处理。执行区块扫描步骤时，全节点根据位图索引结构，快速扫描得到区块扫描结果集。执行查询处理步骤时，全节点检索得到数据查询结果集，并返回给轻客户端。执行数据验证步骤时，轻客户端对全节点返回的数据查询结果集进行验证，确定正确的数据查询结果集。执行计算查询结果步骤时，轻客户端根据查询请求种类的不同，基于正确的查询结果集进行计算，得到最终的查询结果。

本发明在索引生成时充分考虑了区块数量较多，和索引结构的空间占用问题，解决了由于区块数量巨大导致索引结构占用空间过多的问题，提高了全节点查询性能；本发明在全节点与轻客户端通信过程中，显著降低了全节点与轻客户端的通信开销，使得全节点返回给轻客户端的数据量显著减少，减轻了通信压力；本发明在每个全节点的每个区块中，都为各个类型的交易数据生成了验证信息，提高了轻客户端的验证效率；本发明在数据验证时同样考虑了部分全节点不可信的问题，解决了在不可信的区块链网络中数据验证困难的问题。

为了克服现有技术中轻客户端查询数据导致的过多开销，本发明提出了一种基于位图索引的面向区块链轻客户端的验证查询方法。

附图说明

图1是本发明流程图；

图2是区块链系统数据示例图；

图3是位图索引结构示例图；

图4是验证信息示例图；

图5是发送范围查询请求和区块扫描示例图；

图6是数据查询流程图；

图7是数据验证网络交互图；

图8是发送连接查询请求和区块扫描示例图。

具体实施方式

结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

图1显示的是本发明的总体流程图。本发明包括位图索引及交易验证信息生成步骤，查询请求步骤，区块扫描步骤，查询处理步骤、数据验证步骤和计算查询结果步骤六个步骤。六个步骤的功能描述如下：

区块链系统中的数据都是存储在区块中的，随着时间的推移，区块数量会越来越多。如何快速的在所有区块中筛选出包含特定交易数据的区块是一个迫切的需求，并且由于区块链网络中包含恶意节点，如何验证查询结果正确完整也是一个亟需解决的问题。步骤S1生成了基于位图的索引结构，实现了区块扫描时快速筛选所需区块的功能，是区块扫描步骤的基础。并且生成了交易验证信息，为客户端进行数据验证提供了极大的便利。

步骤S2查询请求步骤是轻客户端与全节点通信的开始，主要是轻客户端组装查询请求，并将请求发送至全节点，等待全节点返回查询结果。

步骤S3区块扫描步骤实现了全节点根据轻客户端查询请求，通过位图索引结构，快速扫描得到需要被查询的所有区块。

步骤S4查询处理步骤是基于区块扫描结果和轻客户端查询请求来实现的。首先，全节点只对扫描结果中的区块进行查询，因为其他区块不包含查询请求中的交易数据类型。然后，将轻客户端发送的查询请求进行解析，得到查询涉及的所有交易数据类型。最后根据交易类型，将所有属于该交易类型的交易数据放入数据查询结果集，返回给轻客户端。

步骤S5数据验证步骤是对数据查询结果集进行验证，判定数据查询结果集是否正确完整。轻客户端在得到查询结果集后，将验证请求发送给其他的全节点，在得到其他全节点返回的验证结果后，进行判定。

步骤S6计算查询结果步骤是对查询结果集进行计算，得到最终的查询结果。若轻客户端的查询请求是范围查询，则使用范围查询算法对其进行查询。若查询请求是连接查询，则使用归并排序连接算法对其进行查询。

本发明是基于上述构思提出的，关于上述步骤的具体实施过程作如下描述：

图2是一个区块链系统数据示例图，假设该区块链只有当前4个区块中的交易数据。这里使用四元组来代表交易数据，如[donate,Jack,Tom,1000]，代表Jack捐赠给Tom1000。[transfer,Tom,Jack,500]代表Tom给Jack转了500，[borrow,Tracy,Tom,800]代表Tracy借给Tom800。

为了更好地阐述本发明，以下所有具体实施方式都以图2中的区块链系统数据进行举例说明。

首先针对图2中所有区块中的交易数据来构造位图索引结构，图3显示的是位图索引结构结果图。

在第一个区块中，发现了donate和transfer类型的交易数据，然后去位图索引结构中查找是否有donate和transfer的二进制数据，发现没有则新创建两行二进制数据，分别代表donate和transfer。因为donate和transfer类型的交易数据在第一个区块中都出现了，所以donate和transfer的行数据第一位都是1。

在第二个区块中，可以发现borrow和transfer类型的交易数据，没有发现donate类型的交易数据。因为位图索引结构中没有borrow类型的二进制数据，所以在位图索引中新建一行二进制数据代表borrow。并且donate的第二位是0，而transfer和borrow对应的行数据第二位是1。

同理，在遍历前4个区块后，可以得到位图索引中，donate对应的行数据为1010，transfer对应的行数据为1100，borrow对应的行数据为0111。

接着，全节点需要为各交易类型在不同区块生成验证信息，图4是生成的验证信息图。

首先对交易进行编码处理，TM-N，M代表第M个区块，N代表第M个区块中的第N个交易，如果N为Null，则表示这是一个空交易，交易内不包含任何信息。如T2-1表示，第二个区块中的第一个交易。比较特殊的如T2-Null，表示区块2中的一个空交易。

然后对交易信息也进行处理，Type-BM，Type代表交易类型，M代表第M个区块。如donate-B1表示donate交易类型在第一个区块中的验证信息。

在第一个区块中，donate类型的交易只有T1-1，并且之前没有其他的区块，所以donate类型的交易在区块1中的验证信息为Hash(T1-1)。同理，transfer类型的交易在区块1中的验证信息为Hash(T1-2)。由于区块1中没有borrow类型的交易，所以构造一个空交易，即T1-Null，最终borrow类型的交易在区块1中的验证信息为Hash(T1-Null)。

在第二个区块中，不包含donate类型的交易信息，所以构造一个空交易T2-Null,因为区块2之前存在区块1，所以取出donate交易类型在区块1中的验证信息，即donate-B1，所以donate类型的交易在区块2中的验证信息为Hash(donate-B1,T2-Null)。区块2中transfer和borrow类型的交易分别为T2-2和T2-1，所以transfer类型的验证信息为Hash(transfer-B1,T2-2)，borrow类型的验证信息为Hash(borrow-B1,T2-1)。

同理，可求得donate，transfer和borrow类型的验证信息，如图4所示。

轻客户端要想查询查询全节点中的数据，首先要组装好查询请求，然后将请求发送给全节点。如图5所示，轻客户端想要查询哪个用户的单笔捐赠大于950，首先将查询消息组装好，然后将消息发送给全节点。

全节点收到轻客户端发来的查询请求后，就根据查询请求涉及的数据类型和位图索引结构来扫描区块。如图5所示，全节点收到轻客户端发送的查询请求，查询哪个用户的单笔捐赠大于950。首先，全节点创建区块扫描结果集，并将结果集初始化为空。然后，因为这个查询只涉及到donate这一种交易数据类型，所以创建一个区块列表键值对<donate,BlockList<>>，并直接在Bitmap索引结构里查询donate对应的二进制数据。按位扫描该行中所有的二进制数据，若为0则跳过，若为1则将对应的区块加入BlockList中。图5中可看到，区块1和区块3中包含donate类型的交易数据，所以区块1和区块3都被加入BlockList中。扫描完成后，将对应的键值对放入区块扫描结果集中，最终的区块扫描结果集为<<donate,BlockList<1,3>>>。

得到区块扫描结果集后，全节点开始进行数据查询。查询流程如图6所示，首先，全节点创建数据查询结果集，用来存放查询结果，并且将其初始化为空。因为区块扫描结果集中只包含donate类型，所以创建donate类型交易列表键值对<donate,TransactionList<>>。然后遍历区块扫描结果集，得到donate交易只存在于区块1和区块3中。所以遍历区块1和区块3，将所有donate类型的交易取出，得到数据查询结果集<<donate,TransactionList<T1-1,T3-1>>>。最后再对结果集中的交易进行排序，因为T1-1捐赠值为100，T3-1捐赠值为900，所以最终的查询结果集为<<donate,TransactionList<T3-1,T1-1>>>。

因为区块链网络中有可能存在恶意节点，所以全节点返回给我们的查询结果有可能是错误的信息。所以全节点将查询结果集返回给轻客户端后，轻客户端需要验证查询结果集是否正确完整。

查询结果集中只有donate一种交易类型，所以只需要求解donate类型的验证信息。可以求出donate交易类型在各个区块中的验证信息如下表所示：

表1验证信息示例表

然后轻客户端组装验证请求，并发给其他多个全节点进行验证，因为目前只有4个区块，所以请求区块4中的donate类型交易验证信息即可，过程如图7所示。

轻客户端可将验证请求广播给多个全节点，若共收到n个验证结果，则遍历这n个结果，分别和Hash(donate-B3,T4-Null)比较，看是否相等。若有m个验证结果和轻客户端计算出的验证信息相等，则这个查询结果正确完整的概率为：

n越大，计算结果越准确，用户可以动态调整n的大小来确认验证是否通过。若正确率较低，则可以向其他全节点重新进行查询，并验证。

若轻客户端验证通过后，则认为查询结果集正确完整，接下来就可以基于查询结果集来计算查询结果。计算查询结果共分为两类，一类是计算Range Query的查询结果，另一类是计算Join Query的查询结果。

首先讨论第一种情况，即轻客户端的查询请求为Range Query。比如查询“哪个用户的单笔捐赠大于950”，如图5所示。得到的查询结果集为<<donate,TransactionList<T3-1,T1-1>>>，因为T3-1的值为900，T1-1的值为1000，所以在遍历查询结果集后可以计算出最终的查询结果为T1-1中的捐赠者Jack。

然后讨论第二种情况，轻客户端的查询请求为Join Query。比如，轻客户端的查询请求是，“哪个用户既捐助了别人，又接受了别人的转账”，这个查询涉及了donate和transfer两种交易数据类型。图8显示了区块扫描的过程，最终的区块扫描结果集为<<donate,BlockList<1,3>>,<transfer,BlockList<1,2>>>。所以遍历区块1到区块3，在区块1和区块3中查找donate类型交易数据，在区块1和区块2中查找transfer类型的交易数据。得到所有donate类型的交易数据有：[donate,Jack,Tom,1000]，[donate,Jack,Tom,900]，所有transfer类型的交易数据有：[transfer,Tom,Jack,500]，[transfer,Tom,Rose,700]。最终的数据查询结果集为<<donate,TransactionList<T1-1,T3-1>>,<transfer,TransactionList<T1-2,T2-2>>>。

然后使用Sort Merge Join算法来对两种交易类型的数据进行连接，得到连接结果如表2所示。最终可以计算出最终的查询结果是用户Jack。

表2归并排序连接结果

编号

交易类型

捐助者

捐款金额

交易类型

收款者

转账金额

1

donate

Jack

1000

transfer

Jack

500

2

donate

Jack

900

transfer

Jack

500

本发明的保护内容不局限于以上实施例。在不背离发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。

Claims (9)

1.一种基于位图索引的区块链轻客户端验证查询方法，其特征在于，该方法包括以下具体步骤：

步骤1：位图索引及交易验证信息生成

对不同交易类型构造索引结构和验证信息；

步骤2：查询请求

轻客户端将查询请求发送至全节点；

步骤3：区块扫描

全节点根据位图索引结构，快速扫描得到需要被查询的所有区块；

步骤4：查询处理

全节点通过查询得到查询结果集，并返回给轻客户端；

步骤5：数据验证

轻客户端对全节点返回的结果集进行验证，得到正确的查询结果集；

步骤6：计算查询结果

轻客户端基于正确的查询结果集进行计算，得到最终的查询结果。

2.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤1具体包括：

A1：全节点对所有的交易数据按照交易类型划分，得到多个分类；

A2：全节点为每一个分类创建一个位向量，即一行二进制串数据，每一行中的第i位二进制数据代表区块i中是否包含这种交易类型的数据，1代表包含，0代表不包含；

A3：若出现一种新的交易类型，则添加新的一行二进制串数据来记录此类型交易，所有交易类型的二进制数据共同组成了位图索引结构；

A4：全节点在每一个区块中都为每一种交易计算出验证信息。

3.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤2具体包括：

B1：轻客户端组装好查询请求；

B2：轻客户端将查询请求发送至全节点，等待接收返回结果。

4.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤3具体包括：

C1：创建区块扫描结果集，并将其初始化为空；

C2：为查询请求所涉及到的每种交易类型创建一个键值对，键是交易类型，值是包含这种交易类型数据的区块列表；

C3：全节点根据交易类型找到位图索引中对应的行，依次对每种交易类型进行区块扫描；

C4：按位扫描该行中所有的二进制数据，若为0则跳过，若为1则将对应的区块加入步骤C2中创建的区块扫描列表中；

C5：每扫描完一种交易类型后，将对应的键值对放入步骤C1创建的区块扫描结果集中，直至扫描完所有的交易类型；最终得到的区块扫描结果集包含了每种交易类型及该种类型的交易数据所在的所有区块。

5.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤4具体包括：

D1：创建数据查询结果集，并将其初始化为空；

D2：为区块扫描结果集中的每个区块列表键值对创建一个键值对，键是交易类型，和区块列表键值对中的键相同，值是属于这种交易类型的交易数据列表；

D3：全节点依次遍历区块扫描结果集中的区块列表键值对，取出每个键值对中的区块列表，进行查询；

D4：遍历区块列表中所有区块中的所有交易数据，若交易数据的交易类型与步骤D3中的键值对的键相同，则将交易数据加入步骤D2创建的交易数据列表中，并对交易数据进行处理；

D5：每遍历完一个区块列表键值对后，将键值对放入数据查询结果集中，直至查询完所有的区块扫描列表；最终得到的数据查询结果集包含了多种交易类型及该种交易类型所有的交易数据；

D6：将步骤D1创建的查询结果集返回给轻客户端。

6.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤5具体包括：

E1：轻客户端使用步骤D6中返回的查询结果集，在每一个区块中都为每一种交易计算验证信息；

E2：用验证信息组装验证请求，并发送给网络中其他多个全节点；

E3：其他全节点在本地验证后，将验证结果返回给轻客户端；

E4：轻客户端通过步骤E1和E3中得到的结果来判断步骤D6中返回的查询结果集是否正确完整；

E5：若验证通过则得到正确完整的查询结果集，若验证未通过，则轻客户端向其他全节点重新发送查询请求。

7.根据权利要求1所述的区块链轻客户端验证查询方法，其特征在于，所述步骤6具体包括：

步骤F1：对步骤B1中的查询请求进行判断，若是范围查询则执行步骤F2，若是连接查询则执行步骤F3；

F2：使用范围查询算法对查询结果集进行查询，得到最终的查询结果；

F3：使用连接查询算法对查询结果集进行查询，得到最终的查询结果。

8.根据权利要求2或6所述的区块链轻客户端验证查询方法，其特征在于，所述步骤A4或E1中，在每一个区块中为每一种交易计算验证信息，具体包括：

G1：统计出本区块所有的交易种类，分别为每一种交易求解验证信息；

G2：将本区块中某一种类的交易数据全部取出，按照交易产生时间排序，将所有交易数据作为哈希函数的参数，求解哈希值；

G3：本区块之前是否存在区块，若有则执行步骤G4，否则执行步骤G5；

G4：将前一个区块中相同种类交易的验证信息取出，和步骤G2中的哈希值一起再次作为哈希函数的参数，求解哈希值，该哈希值就是此种交易类型在本区块中的验证信息；

G5：步骤G2中求得的哈希值就是此种交易类型在本区块中的验证信息。

9.根据权利要求5所述的区块链轻客户端验证查询方法，其特征在于，步骤D4所述对交易数据进行处理，具体包括：

H1：根据交易数据所在的区块号以及交易号对其进行编码；

H2：对交易数据编码后，根据交易值的大小，将该交易数据插入到步骤D2创建的交易数据列表中，使得插入后的交易数据列表从小到大依次有序，在全节点中进行排序会大大减少轻客户端的计算量，提升查询效率。