CN112541019B - 区块链资源的搜索方法和装置 - Google Patents

Abstract

本申请实施例提供了一种区块链资源的搜索方法和装置，涉及互联网技术领域，所述方法包括：预先进行资源和节点共有的空间属性Location ID的定义，并对资源的时间、类别等属性进行定义，向查找方分配启动节点，启动节点利用节点之间关联的拓扑结构不断学习并查询最佳节点，获得了越来越接近的节点，最终收敛到目标节点上。本申请将基于空间位置区块链n元组查找和兴趣社区、可用状态结合起来，能够在去中心化的区块链网络中实现模糊搜索找到位置最近且当前可用的资源。

Description

区块链资源的搜索方法和装置

技术领域

本申请实施例涉及互联网技术领域，具体而言，涉及一种区块链资源的搜索方法和装置。

背景技术

随着具有感知功能的海量传感器、RFID、M2M终端的广泛部署，旨在实现“万物互联、感知世界”的全球化物联网正在逐步形成。面对物联网中海量服务与计算资源产生的物理世界实体的动态复合信息，如何实现资源管理面临着很大的挑战。一方面，如果还使用中心化的管理方法，数据中心基础设施的投入和维护成本将越来越无法估量；但另一方面，若没有足够可靠的机构对此负责，资源所有者未必能信任并无偿或有偿地提供资源服务。

去中心的分布式系统区块链的提出为人们对于上述问题的解决提供了一种新的思路。但是区块链的去中心化特点导致其缺乏中心索引机制，区块链的计算节点上分散着不同的资源因此很难被搜索和访问，这给资源查找带来了很大困难。已经有很多被提出的分布式结构化拓扑模式可以实现分布式网络上资源的查找。例如使用P2P网络上的Kademlia协议，可以满足对于指定ID资源的查找，但在真实的使用场景中，用户只知道自己所需资源的类型，并不知道自己所需资源的所有公司(个人)、地理位置、具体资源的ID。另一方面，由于去中心化的特点，资源的时空属性无法直接得到整体的全局查询，关注于时空属性的智能服务资源查找需求无法直接应用现有的主流协议算法。

发明内容

本申请实施例提供一种区块链资源的搜索方法和装置，旨在解决现有区块链资源搜索方法无法适用于时空敏感性资源的问题。

本申请实施例第一方面提供一种区块链资源的搜索方法，所述区块链包括至少一个节点和至少一个资源，所述方法包括：

预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性Location ID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号；

向查找方分配启动节点并向所述启动节点发送查找方的空间属性Location ID；

先在所述启动节点处用所述查找方的空间属性Location ID进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID入队；

迭代的，从从所述队中选取队首的Location ID，向其发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组；

其中，计算空间属性Location ID的步骤包括：

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

可选的，所述预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性Location ID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

构造查找过程中的类，所述类至少包括以下一者：组类、资源类、事务类、消息类、桶类、节点类；

设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数。

可选的，预先计算所有资源的属性组和所有节点的空间属性Location ID，包括：

将节点的虚拟空间坐标定义为节点的空间属性Location ID。

可选的，搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于空间属性Location ID，最近距离计算包括以下步骤：

将两个Location ID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个LocationID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

可选的，所述设置系统范围复制参数k的值，设置请求并发数的值，设置LocationID的长度位数，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置Location ID的长度位数为64位。

本申请实施例第二方面提供一种区块链资源的搜索装置，所述区块链包括至少一个节点和至少一个资源，所述装置包括：

存储模块，用于预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性Location ID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号；

分配模块，用于向查找方分配启动节点并向所述启动节点发送查找方的空间属性Location ID；

节点查找模块，用于先在所述启动节点处用所述查找方的空间属性Location ID进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID入队；

迭代模块，用于迭代的，从所述队中选取队首的Location ID，向其发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

资源查找模块，用于在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组；

其中，空间属性Location ID由Location ID计算模块得到，所述Location ID计算模块包括

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

可选地，所述存储模块预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

资源和节点计算子模块，用于预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性Location ID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

消息类型定义子模块，用于定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

类事件构造模块，用于构造查找过程中的类，所述类至少包括以下一者：组类、资源类、事务类、消息类、桶类、节点类；

参数设置子模块，用于设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数。

可选的，所述装置还包括：最近距离计算模块

搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于空间属性Location ID，所述最近距离计算模块包括：

将两个Location ID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个LocationID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

可选的，所述参数设置子模块设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置Location ID的长度位数为64位。

本申请提出的区块链资源的搜索方法和装置，提出了资源和节点共有的属性Location ID的定义和其与空间坐标之间相互转化的方法，并对资源的时间、类别等属性进行定义，基于以上框架本申请将基于空间位置区块链n元组查找和兴趣社区、可用状态结合起来，能够在去中心化的区块链网络中实现模糊搜索找到位置最近且当前可用的资源。

附图说明

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

图1是本申请一实施例提出的区块链资源的搜索方法的流程图；

图2是本申请一实施例提出的区块链资源的搜索装置的示意图

图3是本申请一实施例提出的Bucket与Location ID之间的关系图；

图4是本申请一实施例提出的并发请求数为100正确性示意图；

图5是本申请一实施例提出的搜索结果正确率与并发搜索数、备份数之间的关系图；

图6是本申请一实施例提出的时间性能数据示意图；

图7是本申请一实施例提出的带宽bandwidth＝5时的时间性能对比图；

图8是本申请一实施例提出的带宽bandwidth＝10时的时间性能对比图；

图9是本申请一实施例提出的带宽bandwidth＝20时的时间性能对比图；

图10是本申请一实施例提出的带宽bandwidth＝inf时的时间性能对比图；

图11是本申请一实施例提出的节点个数变化数据示意图；

图12是本申请一实施例提出的平均搜索时间(Time)随节点个数指数增长的变化示意图；

图13是本申请一实施例提出的平均路由记录数(Contact)随节点个数指数增长的变化示意图；

图14是本申请一实施例提出的平均搜索精度范围(Contact)的自然对数随节点个数指数增长的变化示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

对于部分特殊的资源如智能合约等，由于资源数量众多且时空属性随时都在发生着变化(例如资源当前使用者的使用结束、新资源的加入等)，因此用户需求为在空间上距离较近、时间上当前可用、同时还满足用户指定类别或功能需求的一组资源，因此这些资源具有时空敏感性。

传统的分布式资源查找协议在面对用户查找时空敏感性资源的需求时，存在以下缺点：

(1)不具有时间敏感性，无法查找到当前可用(未被占用)状态的资源。

(2)不具有空间敏感性，无法计算用户与资源的空间距离，对于空间敏感性资源，用户在多数情况下会偏向于与自身空间距离近的资源，而并不太在意具体资源的供应商(个人)的身份。

(3)模糊搜索能力差，现有的Chord、Kademlia协议都是关注于分布式网络中指定资源的查找，对模糊搜索的兼容性差，对资源的空间位置在查找阶段没有相关性。

(4)不能应对资源的变动，一些资源会发生空间的位移但其部署的区块节点IP并未发生改变；资源在使用过程中不断在可用/被占用状态间切换，需要保证状态更新请求的互斥与同步。

本申请基于上述现有分布式资源查找协议在查找时空敏感性资源时的缺点，提出了一种时空敏感的资源搜索算法，首先，定义资源和节点的属性，将资源和节点的空间坐标、类别等引入区块链中，然后，基于节点的属性查找与查找方空间距离最近的节点进行，从寻找到的节点中查找满足用户需求的资源，本申请能够精确找到在空间上距离近、时间上当前可用、同时还满足用户指定类别或功能需求的一组资源，解决了现有技术中无法对资源的空间时间属性进行搜索，同时提到能过实现对模糊搜索的良好兼容性，本申请在并发搜索数较大且带宽有限的情形时间性能显著优于传统C/S模型。

参考图1，图1是本申请一实施例提出的区块链资源的搜索方法的流程图。如图1所示，该方法包括以下步骤：

步骤S100：预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性Location ID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号。

其中，计算空间属性Location ID的步骤包括：

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

资源和节点的空间属性Location ID都由其自身的空间坐标转换而来，空间坐标应至少包括：经度、纬度。

资源或者节点的实际地理位置可以采用一对经纬度坐标来描述，经度在前，范围是[-180,180]代表从西经180度到东经180度。纬度在后，范围是[-90,90]代表纬度是从南纬90度到北纬90度。例如北京大学图书馆(百度地图)的经纬度坐标为(116.316801,39.997899)，将北京大学图书馆的这组经纬度坐标和预设的ID长度输入，将纬度区间[-90,90]进行二分为[-90,0),[0,90]，称为左右区间，可以确定39.997899属于右区间[0,90]，给标记为1；接着将区间[0,90]进行二分为[0,45),[45,90]，可以确定39.997899属于左区间[0,45)，给标记为0；递归上述过程39.92324总是属于某个区间[a,b]。随着每次迭代区间[a,b]总在缩小，并越来越逼近39.997899；如果给定的纬度(39.997899)属于左区间，则记录0，如果属于右区间则记录1，这样随着算法的进行会产生一个序列10111000 1110001011001010 01100101，序列的长度跟给定的区间划分次数有关。同理，经度区间是[-180,180]，对经度116.316801进行二分编码。

通过上述计算，纬度产生的编码为10111000 11100010 11001010 01100101，经度产生的编码为11010010 10110110 11010011 11010001。偶数位放经度，奇数位放纬度，把2串编码组合生成新串：11100111 01001000 11011110 00101100 11110010 0100111010110110 00010011，将上面的二进制串转换为十进制整数形式为16665814705709692435，输出为一组经纬度坐标，例如经纬度坐标(116.316801,39.997899)。

在一般的区块链协议中，路由常选用节点的IP地址做SHA1哈希来生成160位的节点ID，其目的主要有二：

(1)唯一性：生成的节点ID是唯一的，不同的节点对应不同的IP地址，因此也就对应不同的节点ID值。

(2)单向性：通过IP地址可以很容易得到Hash值，但仅通过Hash值计算出节点的IP地址是困难的。这一特性可以在一定程度上实现对节点的IP保护。

本申请使用节点/资源的空间经纬坐标生成节点的Location ID作为节点的唯一标识，除了保留了以上两个特征外，本申请设计的搜索框架下路由表Location ID的计算还具有以下特性：

(3)Location ID近似唯一性：生成的节点Location ID是近似唯一的，不同的节点对应不同的虚拟空间位置(经纬度坐标)，因此也就对应不同的节点Location ID值。在实现上也许起始的节点具有非常相近的虚拟坐标，但我们通过增大这个Location ID的长度位数(64位)，经计算可以让空间面积上精确到约4e-6平方米的数量级，线度误差精确到1e-3米的数量级。也就是说除非两个节点的虚拟空间位置近到这个数量级以下，它们不能拥有相同的Location ID，在具体测试中我们发现这是几乎不可能的情况，因此节点的Location具有近似唯一性。

(4)Location ID与IP地址匿名化：IP地址作为节点ID的优势是利用SHA1哈希的单向性保护了节点的IP地址。而在我们的框架中，由于Location ID与IP地址脱钩，两者双向均无关联，可以说回避了IP的安全问题。

(5)Location ID与虚拟空间位置的双向可推性：每个节点的Location ID与其来源节点虚拟位置经纬度坐标是双向可计算的。可以由经纬度坐标计算出Location ID，也可逆向地由Location ID计算出原虚拟经纬度坐标。

(6)Location ID间距离的可计算性：与SHA1哈希或者别的散列方法不同，因为我们利用二分法将经纬度的二维坐标变成一个可排序、可比较的的字符串编码，相近的虚拟位置坐标可以得到相近但不同的Location ID。对两个Location ID做按位异或计算可以得到有计算意义的距离值。在大多数情况下，有较小的距离值的Location ID对所对应的位置坐标之间的实际空间距离也会较小。

资源的时间属性，表示当前资源在当前是否可用，资源的时间属性在实现上由一个bit来表示。1表示当前资源由于被占用/故障/维修等原因不能使用，0表示当前资源可用，本申请将时间属性Availability Code保存为8bit的二进制数。

资源的类别属性Name Code表示资源的类型，在实现上本申请假定资源的类型(例如共享打印机、共享咖啡机等等)总数不超过256种，因此我们使用一个8bit的二进制数来表示，本申请将这个8bit的二进制数称为Name Code。

对于资源的IP和用于交互的端口，由于合法的IP地址自身具有一定的规则，本申请使用一个长度为16的字符串来表述，端口号用一个INT(16)来存放。

一个原始资源自身的属性可以用一个<Location ID，Availability Code，NameCode，IP address，UDP port>的属性五元组来表述。

将资源的属性组存储在距离资源自身空间位置最近的节点上。

本申请所想要查询的资源并不具备路由功能、查找资源等功能，因此将资源的Location ID存储在距离资源自身空间位置最近的节点上，利用节点为查找方和资源之间提供路由查询，让查找方在节点上找到记录周围的资源属性组从而能够找到资源的地址，与资源进行互动。

步骤S110：向查找方分配启动节点并向所述启动节点发送查找方的空间属性Location ID。

区块链系统的节点一般具有分布式、自治性、开放可自由进出等特性,因而一般采用对等式网络(Peer-to-peer network,P2P网络)来组织散布全球的参与数据验证和记账的节点.P2P网络中的每个节点均地位对等且以扁平式拓扑结构相互连通和交互,不存在任何中心化的特殊节点和层级结构,每个节点均会承担网络路由、验证区块数据、传播区块数据、发现新节点等功能.按照节点存储数据量的不同,可以分为全节点和轻量级节点。前者保存有从创世区块到当前最新区块为止的完整区块链数据,并通过实时参与区块数据的校验和记账来动态更新主链.全节点的优势在于不依赖任何其他节点而能够独立地实现任意区块数据的校验、查询和更新,劣势则是维护全节点的空间成本较高。本申请的区块链采用轻节点(轻量级、SPV用户)和全节点混合的方式进行组网，资源并不需要不存储完整的账本数据，仅具备验证与转发功能，效率更高，节约资源处的硬件支出。因此，在本申请区块链的网络层除有特殊说明外，所有资源都是指轻节点，所有节点都是全节点。

当查找方想要查找某个资源时，由于查找方并不具备路由功能、查找资源等功能，因此首先要给查找方分配已经接入区块链的节点。当给查找方分配好节点后，本申请称这个分配的节点为启动节点，查找方向这个启动节点发送自己的空间坐标。

步骤S120：先在所述启动节点处用所述查找方的空间属性Location ID进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID入队；

步骤S121：迭代的，从所述队中选取队首的Location ID，向其发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

步骤S122：在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组。

搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于节点和资源的空间属性Location ID。

启动节点接收到查找方的的空间坐标后，将这个空间坐标转换为Location ID，利用这个查找方的Location ID先在启动节点记录的周围节点的Location ID中进行查找，得到对启动节点查询后的第一轮查找结果，将第一轮查找结果存储；在这个第一轮查找结果找到距离查找方最近的k个节点，将这k个节点的Location ID依据距离的远近排序后将这k个Location ID加入队列，将k个Location ID中的距离最近的排在队首。同时，利用这k个Location ID的建立node-set列表，对于node-set列表也将其按照距离的升序进行排序。

查找完启动节点内记录的其他节点后，选取之前保存的队列中队首的LocationID并将该Location ID弹出队列，向选中的Location ID的节点发送查找信息，这个节点接收到信息后会计算查找方与节点内记录的周围其他节点的距离，得到第二轮查找结果，利用返回第二轮查找结果更新之前保存的查找结果，在这个更新后查找结果找到距离查找方最近的k个节点，逐个判断k个节点中距离大于当前node-set列表中最后一项节点距离的，判断完后将符合条件的节点的Location ID加入队列和node-set列表。移除队列中重复的节点的Location ID和已发送过查找消息的节点，对队列的Location ID按照距离升序重新进行排序，选取排序后队列中前k个Location ID。同样的，对更新后的node-set列表移除重复的Location ID，按照距离升序排序，选取排序后node-set列表中前k个Location ID。判断队列是否为空，如果已经空了，那么node-set列表中k个Location ID的节点就是距离资源最近的节点，如果还未空，那么继续迭代，向其发送消息接收返回的消息的过程，直到队列最后为空。

得到距离查找方最近的k个节点后，向这个k个节点发送资源查找消息，资源查找消息参数设置为NC(查找方所需资源的类别属性Name Code)，收到资源查找消息的节点在该节点记录的资源的属性组中进行查找，找到每个节点中Name Code等于NC且当前Availability Code为0的所有的资源，将资源的属性组返回启动节点。将所有节点返回的资源属性组作为资源集合并将这个资源集合返回查找方，查找方在资源集合中悬着一个当前想使用的资源，就可以利用资源集合中记录的资源属性与该资源进行交互。

本申请实施例的区块链资源的搜索方法，提出了资源和节点共有的属性LocationID的定义和其与空间坐标之间相互转化的方法，并对资源的时间、类别等属性进行定义，基于以上框架本申请将基于空间位置区块链n元组查找和兴趣社区、可用状态结合起来，能够在去中心化的区块链网络中实现模糊搜索找到位置最近且当前可用的资源。

在本申请的一个可选实施例中，步骤S100的预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性Location ID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

构造查找过程中的类，所述类至少包括以下一者：组类、资源类、事务类、消息类、桶类、节点类；

设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数。

每个节点拥有自己所运行在的IP地址与UDP端口，其它节点可以通过自己记录的这两个信息向该节点发送消息。

每个节点维护一个路由表，路由表在实现上由一组列表(k-bucket)组成，每个列表对应节点Location ID的每一位(例如，具有64位标识符的节点LocationID将保留64个这样的列表)。通常，一个列表有许多条目，每个条目由一个三元组<Location ID，IPaddress，UDP port>定义。该三元组<Location ID，IP address，UDP port>指定定位节点所需的信息。每个列表都按最后访问时间排序。这些列表称为k-bucket。值k称为系统范围复制参数，并定义每个列表可以增长到的上限。

每个节点维护一个资源表，资源表由多个资源条目构成，存放对应资源的属性组<Location ID，Availability Code，Name Code，IP address，UDP port>，其中Location ID是主键值。

一个节点发送的每一条消息都包含它自身的<Location ID,IP address,UDPport>对，允许收到消息的节点在必要时(主要是更新自己的路由表时)记录下这些信息。

每个节点的基本消息类型有以下7种：

(1)PING

PING消息由一个节点发起，向另一个节点确认其还能正常工作，无参数。

返回结果为一个1bit的Boolean值表示节点是否运转正常。若成功运转，返回成功码(1)，否则返回错误码(0)或不返回(节点故障)。

(2)STORE_NODE

STORE_NODE消息由一个节点发起，参数为一个节点的属性组<Location ID，IPaddress，UDP port>，要求另一个节点在自己的路由表中存储这个节点的属性组(若k_buckets已满，有相关的替换策略)，成功存储返回成功码(1)，否则返回错误码(0)。

(3)STORE_RESOURCE

STORE_RESOURCE消息由一个节点发起，参数为一个资源的属性组<Location ID，Availability Code，Name Code，IP address，UDP port>，要求另一个节点存储这个资源的属性组，成功存储返回成功码(1)，否则返回错误码(0)。

(4)FIND_NODE

FIND_NODE消息由一个节点发起，参数为一个64位的Location ID，要求另一个节点返回它的路由表中，与这个Location ID的Hash距离最小的k个(这个k值为全局参数)Location ID所对应节点的<Location ID,IP address,UDP port>对组。

(5)FIND_RESOURCE

FIND_RESOURCE消息由一个节点发起，参数为一个资源的类别码NameCode，要求另一个节点返回所有它的资源表中的Name Code与之相同，且当前Availability Code为1处于可用状态的资源的<Location ID，Availability Code,NameCode，IP address，UDP port>对组。

(6)OCCUPY

OCCUPY消息由一个节点发起，参数为一个资源的类别码Location ID，要求另一个节点将它的资源表中存储的Location ID与之相同的资源的AvailabilityCode置为1。若原Availability Code已为1或该资源不存在，返回错误码(0)，否则返回成功码(1)。

(7)UNOCCUPY

UNOCCUPY消息由一个节点发起，是OCCUPY的逆操作。参数为一个资源的类别码Location ID，要求另一个节点将它的资源表中存储的Location ID与之相同的资源的Availability Code置为0。若原Availability Code已为0或该资源不存在，返回错误码(0)，否则返回成功码(1)。

Pair类是由节点的Location ID、IP address、UDP port整合而成的类。Pair类的元素有：locationId、ip、port。当一个节点获得了别的节点的Pair时，便可以向其发送消息，消息中附带上身节点的Pair。收到消息的节点可以执行相关操作并利用发送方的Pair返回结果。

Resource类的本质是存储目标资源的智能合约所运行的ip与port。Resource类的元素有继承自Pair类的locationId、ip、port和verification_code、name_code、availability_code。通过获取Resource类的ip和port，节点可以实现对目标资源智能合约所运行节点的访问，进而使用目标资源。因此在本申请中满足用户限定要求的Resource实例是搜索的最终目标。

Affair类(事务类)是节点操作的核心类。用户向预分配的启动节点发布事务，启动节点启动事务，并在事务的处理过程中与其它节点相互发送必要的消息(Message)，最终事务运行结束，启动节点将事务的运行结果返回给用户。Affair类的主要元素有继承自Pair类的locationId、ip、port和affair_id、affair_type、status、param、stop_count。affair_id由事务所在启动节点的affair_id_count计数，需要满足所有节点上所有事务的id的唯一性，这是因为当节点收到别的节点返回的消息后，需要立刻判断出该消息归属于自己节点上正在运行中的哪个事务，进而完成相应操作。affair_type分为"LAUNCH_SEARCH"、"LAUNCH_GUIDE"、"LAUNCH_STORE"三种，分别对应资源搜索事务、新节点加入事务和新资源寻址存储事务三种。status是事务的状态，主要有"INITIAL"、"WAITING"、"LEADING"、"FINISHED"四种。param是对应不同类型事务在布置事务的同时需要给予的参数，例如资源搜索事务需要给出目标资源类型、用户当前location等信息。stop_count用以追踪affair的完成，如果一段时间affair的进度不再更新就会扣减stop_count，扣减为负时事务的状态便可转为FINISHED。

Message类是规划节点间消息通信的类。Message类的主要元素有message_type、status、affair_id、pair_from、pair_to、param。关于message_type已经对7种消息类型做了详细的介绍。status分为"REQUEST","RECEIPT"，表示消息是请求消息还是回执消息。affair_id表示message所attach to的affair的id，pair_from和pair_to分别记录发信节点和收信节点的pair。param则是消息所必须负载的其它参数。

Bucket类是节点用以存放路由信息的单位类。每个Bucket对应一个Location ID的区段。Bucket类的元素有：bucket_id、list。bucket_id编号从1到64。list中存放在Bucket区段范围中的节点的Pair。对于本申请算法架构下长为64位的主键Location ID而言，每个Node拥有一个由64个Bucket构成的k_buckets，Bucket的id(0-63)表示它所代表的Location ID区段与其所在Node的Location ID是从第几位开始不相同的。以6位的Location ID为例，假设Node自身的Location ID为011010，那么它拥有6个bucket，用k_buckets[0],…,k_buckets[5]表示。那么它们各自表示的Location ID区段与区段长度如图3所示。

当某一节点A向节点B发送消息请求MESSAGE(MESSAGE可以是以上7种任一)时，将A的pair放在第一参数，B的pair放在第二参数，原本的参数放置在后面。例如当节点A向节点B发送FIND_NODE消息请求时，记为FIND_NODE(Pair_A,Pair_B,Location ID)；又例如节点A向节点B发送PING消息请求时，记为PING(Pair_A,Pair_B)。特别地，当Pair_A与Pair_B相同时，表示节点并没有发出消息让别的节点执行操作，而是在自身节点上执行相关的算法。

每个节点都会维护一个路由表，路由表由一组列表组成，每个列表对应节点Location ID的每一位(例如，具有64位标识符的节点Location ID将保留64个这样的列表)。通常，一个列表有许多条目，每个条目由一个三元组<Location ID，IP address，UDPport>定义。该三元组<Location ID，IP address，UDP port>指定定位节点所需的信息。每个列表都按最后访问时间排序。这些列表称为k-bucket。值k称为系统范围复制参数(System-wide Replication Parameter)，并定义每个列表可以增长到的上限。

本申请节点最重要的工作是收到FIND_NODE消息后返回k个最接近某个给定节点ID的节点的位置，这个过程被称为节点查找。发起方从其最近的非空k-bucket中选取alpha个节点。然后，发起程序将并行的异步FIND_NODE消息发送到它选择的alpha个节点。alpha的值定义了一个节点同时发起查找节点的数量。

进一步的，所述设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置Location ID的长度位数为64位。

我们使用Location ID作为节点主键来作为资源和节点中的ID。本申请的Location ID长度的主要目的是增加Location ID自带位置信息的精确度，以保证LocationID的近似唯一性。本申请通过增大这个Location ID的长度位数至64位，经计算可以让空间面积上精确到约4e-6平方米的数量级，线度误差精确到1e-3米的数量级。也就是说除非两个节点的虚拟空间位置近到这个数量级以下，它们不能拥有相同的Location ID，在具体测试中我们发现这是几乎不可能的情况，因此节点的Location具有近似唯一性，将location_length固定为64。

在本申请的一个可选实施例中，步骤S100的预先计算所有资源的属性组和所有节点的空间属性Location ID，包括：

将节点的虚拟空间坐标定义为节点的空间属性Location ID。

定义节点的虚拟地理位置为Location ID，因为节点实际管辖的地理位置而不一定是节点自身服务器所安置的位置。特别地，当服务器也确实安置在其的虚拟地理位置时，可以在一定程度上提升请求的访问速度。

在本申请的一个可选实施例中，搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于都基于空间属性Location ID，最近距离计算包括以下步骤：

将两个Location ID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个LocationID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

由于本申请的Location ID的计算过程可知，空间坐标相近的资源/节点的Location ID具有较长的公共前缀，因此可以直接按照按位异或的方式来获取两个Location ID间的Hash距离，例如16665814705709692435(北京大学图书馆)和16665814700764106491(邱德拔体育馆)。输出为一个64位二进制数的整数形式，例如北京大学图书馆和邱德拔体育馆的Location ID间Hash距离为00000000 00000000 0000000000000111 00111001 11001001 10111000 11101000，表示为十进制就是31034292456；又如北京大学图书馆和圆明园的Location ID间Hash距离为00000000 00000000 0000000001001110 01110110 10101000 00111100 11110011，表示为十进制就是336998186227。

两个LocationID间Hash距离计算的伪代码如下：

输入：LocationID 1、LocationID 2的十进制表示locationId_1、locationId_2

输出：两个LocationID的距离distance用十进制整数表示

function DistanceLocationID(locationId_1,locationId_2)

distance←locationId_1^locationId_2

return distance

end function

例如：DistanceLocationID(16665814705709692435,16665814700764106491)＝31034292456，其中“^”是按位异或的运算符。

发明人对本申请的搜索方法的正确性进行了验证。

搜索算法正确性验证是指，验证我们时空敏感的资源搜索算法得到的搜索结果与客观上正确的答案相比，是否正确率足够高。在这里我们会引入一个参数：备份数(backup)，表示同一份资源在加入分布式网络时进行的存放数量，例如备份数为5时表示其中1份存放具体资源的信息，而另4份指向这第一份资源存放的节点。

正确结果是使用枚举的方式，直接将所有节点与目标Location ID做平面欧氏距离并排序，得到参考的正确结果，

控制相同的节点个数(node number)为100预先生成同一幅节点资源地图。然后我们改变并发请求数(concurrent searching number)取值为10、100、1000进行三次测试。对于每个并发请求数的取值，我们都进行10次仿真，每次随机初始化每个查询的查询目标和启动节点。完成查询后计算备份数(backup)为1,2,…,10时可以获得正确资源位置节点的概率。

将模型运行在个人的阿里云云服务器上，使用tmux工具自主运行。生成存档文件，例如当并发请求数为100时的存档文件内容accuracy_100如图4所示。

对于实验结果，我们对于同并发搜索数的10次数据做平均值Avg，将结果绘制成图5。

分析图中的实验结果，可以得到如下结论：

(1)时空敏感的资源搜索算法是一种正确率有保证的资源搜索算法。

(2)备份数越大，成功查找到目标资源所在节点的概率越大，趋向于1。备份数取值大于1时就已经可以保证相当高的正确率了。

(3)并发搜索数对于结果的正确率影响不显著，表明算法能适用于各种并发规模的查询需求并保持正确率稳定。

发明人将本申请的区块链资源的搜索方法与传统的C/S模型进行了对比。

假设所有节点(包括时空敏感的资源搜索算法中的节点、C/S模型中的所有client和server节点)的带宽限制相等，为定值bandwidth。假定所有并发请求同时发出并被其对应启动节点处理，关注所有并发请求完成时间的平均值作为衡量系统处理并发请求的时间性能的主要指标。

C/S模型的理论时间性能，对于节点搜索算法这一核心步骤，在C/S模型下，理论上需要经历以下步骤：

(1)client节点向server节点发送请求message

(2)server节点响应收到的请求message，向client节点返回结果message

(3)client节点响应收到的结果message，完成查找

因此按照前文中我们对于时间片的定义，若不考虑带宽限制，在C/S模型下单个节点搜索请求的时间消耗为3时间片，即300ms(定义单个时间片的长度为100ms)。

显然在C/S模型下，由于client只与server节点信息交互，而与其它client节点无直接信息交互，带宽的限制最早体现在server节点的带宽拥堵上。因此当并发请求数量变化时，总的C/S模型的时间消耗性能(即Time-Concurrent SearchingNumber图像)近似满足以下两个性能阶段：

(1)阶段一：并发请求数较小，server节点带宽未饱和，则所有请求并发开始进行，同步经历以上(1)(2)(3)步骤，理论上将同步完成，请求的平均完成时间为T_avg＝3·100ms＝300ms。

(2)阶段二：并发请求数较大，server节点带宽饱和，新来的请求在server处排队，此时在server节点处的步骤(2)耗时将远大于步骤(1)和步骤(3)，因此总耗时近似于步骤(2)耗时，平均每个请求完成的时间近似等于这是因为最快完成的请求依旧只需要T_min＝300ms；而最慢完成的请求要等待所有Server处请求处理完毕才轮到自己，需要时间为/>这样所有请求的平均完成时间为/>

将以上两阶段绘制为分段函数，记为C/S模型时间性能理论值(Theoreticalvalue in C/Smodel)。

控制相同的节点个数(node number)为100，预先生成同一幅节点资源地图，即时间性能测量过程中所有测试使用的节点资源地图是相同的，起到控制变量的作用。然后我们改变带宽(bandwidth)的取值为5、10、20、inf进行四次测试。对于每个带宽的取值，我们都将并发查询数量(Concurrent Seaching Number)从2⁰＝1＝1开始，按照2的幂次扩大到2¹⁶＝＝65536(除bandwidth＝inf的case取到215为例外)，然后对于每个并发查询数量，进行10次仿真，每次随机初始化每个查询的查询目标和启动节点。完成查询后计算所有Concurrent Seaching Number次查询的完成时间的平均值。

将模型运行在个人的阿里云云服务器上，使用tmux工具自主运行。生成存档文件，例如当带宽为10、并发查询数为32768的存档文件内容job_100_10_32768如图6所示。

对于图6中的实验结果，我们对于同带宽、同并发搜索数的10次数据做最大值Max、最小值Min、平均值Avg、去掉最大值和最小值之后的平均值Avg_exp四个取值，绘制成折线图。再在折线图基础上加上对于传统C/S模型的理论性能曲线。

图7示出了带宽bandwidth＝5时的时间性能对比，图8示出了带宽bandwidth＝10时的时间性能对比，图9示出了带宽bandwidth＝20时的时间性能对比，图10示出了带宽bandwidth＝inf时的时间性能对比。

对于上述实验结果的对比，可分析出本申请资源搜索算法与C/S模型相比：

(1)当节点的带宽不为正无穷时(有限制)，随着并发请求数的增加，大约在100-200左右的并发规模之后，本申请的资源搜索算法的时间性能就开始显著优于传统C/S模型了。在真实的现实应用场景中，并发请求数的规模是远远大于这一临界值的。

(2)传统C/S模型在应对并发请求数的增长时主要体现两个阶段：空闲和过载。空闲阶段每个查询请求的完成时间一致且不受限；过载阶段由于请求在Server端积塞，请求完成的平均时间随并发数增长呈正比。

(3)本申请的资源搜索算法在应对并发请求数的增长时主要体现三个阶段：空闲、调度均衡、过载。空闲阶段每个查询请求的完成时间相似，并发数指数增加但请求平均完成时间基本不增长；调度均衡阶段是我们算法相对于传统C/S模式的主要优势阶段，由于节点之间互相传递消息分散了对于单一节点带宽的压力，虽然并发数指数增加，但请求的平均完成时间基本呈线性增长；过载阶段与C/S模式类似，经过进一步分析发现是个别路由上高访问量的节点积压了大量消息有待处理但很多普通节点都已经处理完毕处于空闲状态，因此请求平均完成时间与并发数成正比，即也一同指数增长。

(4)当节点的带宽无限制时(理论非真实情况)，时空敏感的资源搜索算法与传统C/S模式相似，请求的平均完成时间不随并发请求数的增长而增长，而是趋于定值，这是符合实验预期的。

发明人还注意到节点个数取值与搜索结果指标的相关性，发明人对不同节点数下的搜索结果进行了对比。

在上述对比验证中都假定了节点个数为100，节点的管辖地域大致为北京大学(燕园)片区。但在实际运用中，节点的个数是可以调整的，其数值的调整会对搜索结果的几项指标带来相应的变化。因此接下来关注这些指标的变化与节点个数变化之间的关系。

本申请的区块链资源搜索算法主要关注的指标有以下三个：搜索时间(Time)、平均路由记录数(Contact)、搜索精度范围(Bound)。这些指标的定义如下：

(1)平均搜索时间(Time)

平均搜索时间是指，从一项节点搜索事务被其启动节点接受开始计时，到分布式查询完成，得到结果为止的平均时间消耗。在这里我们依然假定每个时间片的大小为100ms。这一数值是搜索算法性能的主要衡量指标。

(2)平均路由记录数(Contact)

平均路由记录数是指，随着节点的创建与接受引导加入原有分布式节点网络，每个节点在完成全部节点创建后的平均需要记录的其它节点的路由个数。虽然在创建之后进行真实查询时这一指标的数量还会发生波动，但创建网络伊始的这一指标依旧能一定程度上反映节点的空间开销。

(3)平均搜索精度范围(Bound)

对于同一目标Location ID的搜索请求，分布式网络中节点数的个数越多，搜索结果的精度自然会越高。我们在这里的平均搜索精度范围是指，对于查找结果中的k个结果节点，我们计算其中最远的一个(第k个)节点与目标Location ID的绝对欧氏距离，单位为米。多次测量(10次)并取平均值。这一指标是验证性的，因为容易想见，随着节点数量的翻倍，最终结果的管辖面积范围应当减半，因此线度指标Bound应当理论上约为原值的倍。

搜索结果指标与节点个数取值变化的采集方式上，仅针对节点个数变化做测试，因此不考虑并发请求，即只有一个查询请求被执行。

我们改变节点个数(node number)的取值从25＝32开始，按照2的幂次扩大到213＝8192，每个节点个数值做10次单查询仿真测试，每次查询均随机生成对应节点个数的随机新节点资源地图。完成查询后计算所有每个节点个数对应10次查询的以上三项指标的平均值。

将模型运行在个人的阿里云云服务器上，使用tmux工具自主运行。生成存档文件，例如当节点个数为4096时的存档文件内容data_4096如图11所示。

对于同节点个数的10次数据的Time、Contact、Bound分别做最大值Max、最小值Min、平均值Avg、去掉最大值和最小值之后的平均值Avg_exp四个取值，绘制成折线图。

平均搜索时间(Time)随节点个数指数增长的变化如图12所示，平均路由记录数(Contact)随节点个数指数增长的变化如图13所示，平均搜索精度范围(Contact)的自然对数随节点个数指数增长的变化如图14所示，图14纵坐标值取了自然对数。

基于上述图像所示实验结果，可以得到如下结论：

(1)随着节点数的指数增长，单次查询的平均时间(Time)仅线性增长，时间可控。同时意味着真实应用场景中，节点数量的正常增多并不会对搜索算法的性能造成显著的影响。

(2)随着节点数的指数增长，每个节点平均记录的其它节点路由的数量(Contact)(可以认为是节点的硬件存储压力)仅仅呈线性增长，例如当Node Number＝8096时，正常运作中的每个节点只需要平均各“认识”其它的约140个节点，就可以完成有效的节点查找事务了。

(3)随着节点数目的增多，搜索结果的“精度”也相应提升，这是符合直觉的。因为按照常理，节点数增大为2倍，理论上结果的有效面积应当缩小2倍，因此线度上转化为一维的距离也应当缩小倍，这在结果上得到了印证。进一步使用Avg下的数据做线性回归，结果为节点数每增大为2倍，Bound缩小约1.46倍，该结果与/>吻合，验证了算法的合理性。

结合本申请资源搜索算法与C/S模型相比中的分析，搜索请求的平均耗时(Time)在过载前与并发请求数(S)的对数成正比，在本次实验中我们又得到它和节点个数(N)的对数成正比，因此有O(Time)＝lg^slg^N。

基于同一发明构思，本申请一实施例提供一种一种区块链资源的搜索装置。参考图2，图2是本申请一实施例提出的一种区块链资源的搜索装置的示意图。如图2所示，该装置包括：

存储模块，用于预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性Location ID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号；

分配模块，用于向查找方分配启动节点并向所述启动节点发送所述查找方的空间坐标；

节点查找模块，用于先在所述启动节点处用进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID入队；

迭代模块，用于迭代的，从所述队中选取队首的Location ID，向其发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

资源查找模块，用于在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组；

其中，空间属性Location ID由Location ID计算模块得到，所述Location ID计算模块包括：

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

在本申请的一个可选实施例中，所述存储模块预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

资源和节点计算子模块，用于预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性Location ID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

消息类型定义子模块，用于定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

类事件构造模块，用于构造查找过程中的类，所述类至少包括以下一者：组Pair类、资源类、事务类、消息类、桶类、节点类；

参数设置子模块，用于设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数。

在本申请的一个可选实施例中，所述存储模块的预先计算所有资源的属性组和所有节点的空间属性Location ID，包括：

将节点的虚拟空间坐标定义为节点的空间属性Location ID。

在本申请的一个可选实施例中，还包括：最近距离计算模块

搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于空间属性Location ID，所述最近距离计算模块包括：

将两个Location ID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个LocationID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

在本申请的一个可选实施例中，所述参数设置子模块设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数，设置节点个数的值，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置Location ID的长度位数为64位。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种区块链资源的搜索方法和装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种区块链资源的搜索方法，所述区块链包括至少一个节点和至少一个资源，其特征在于，所述方法包括：

预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性Location ID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号；

向查找方分配启动节点并向所述启动节点发送查找方的空间属性Location ID；

先在所述启动节点处用所述查找方的空间属性Location ID进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID依据距离的远近进行排序并入队，将距离最近的LocationID排在队首；

迭代的，从所述队中选取队首的Location ID，向队首的Location ID对应的节点发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组；

其中，计算空间属性LocationID的步骤包括：

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

2.根据权利要求1所述方法，其特征在于，所述预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性Location ID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

构造查找过程中的类，所述类至少包括以下一者：组类、资源类、事务类、消息类、桶类、节点类；

设置系统范围复制参数k的值，设置请求并发数的值，设置LocationID的长度位数。

3.根据权利要求1所述方法，其特征在于，预先计算所有资源的属性组和所有节点的空间属性LocationID，包括：

将节点的虚拟空间坐标定义为节点的空间属性LocationID。

4.根据权利要求1所述方法，其特征在于，搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于空间属性Location ID，最近距离计算包括以下步骤：

将两个LocationID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个LocationID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

5.根据权利要求2所述方法，其特征在于，所述设置系统范围复制参数k的值，设置请求并发数的值，设置LocationID的长度位数，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置LocationID的长度位数为64位。

6.一种区块链资源的搜索装置，所述区块链包括至少一个节点和至少一个资源，其特征在于，所述装置包括：

存储模块，用于预先计算所有资源的属性组和所有节点的空间属性Location ID，将资源的属性组存储在距离资源自身空间位置最近的节点上，所述属性组至少包括以下一者：资源的空间属性LocationID、资源的时间属性、资源的类别属性、资源的部署IP地址和相应端口号；

分配模块，用于向查找方分配启动节点并向所述启动节点发送查找方的空间属性Location ID；

节点查找模块，用于先在所述启动节点处用所述查找方的空间属性Location ID进行查找，得到查找结果，在所述查找结果中找到所述启动节点自身路由表中距离所述查找方最近的前k个节点，将所述前k个节点的Location ID依据距离的远近进行排序并入队，将距离最近的Location ID排在队首；

迭代模块，用于迭代的，从所述队中选取队首的LocationID，向队首的Location ID对应的节点发出查找消息后接收返回结果，利用所述返回结果更新所述查找结果，同时选择更新后查找结果中与所述查找方距离大于队尾距离的节点，将选择出的Location ID入队进行更新，截取更新后队中前k个节点，直到找寻到区块链网络中距离所述查找方最近的k个节点，所述队尾距离为所述队中队尾的Location ID与所述查找方距离；

资源查找模块，用于在所述最近的k个节点中查询，得到距离所述查找方最近的资源的属性组；

其中，空间属性LocationID由LocationID计算模块得到，所述Location ID计算模块包括：

将空间坐标通过二分法分别在经度和纬度的值域上二分细化，得到两个二进制字符串，再通过奇偶位交错拼接所述两个二进制字符串得到Location ID，空间坐标至少包括：经度、纬度。

7.根据权利要求6所述装置，其特征在于，所述存储模块预先计算所有资源的属性组和所有节点的空间属性Location ID，还包括：

资源和节点计算子模块，用于预先计算所有资源的属性组和所有节点的属性，节点的属性至少包括以下一者：节点的空间属性LocationID，节点的IP地址与端口，节点的路由表，节点的资源表，所述资源表用于存储至少一个资源的属性组；

消息类型定义子模块，用于定义节点之间的消息类型，所述消息类型至少包括以下一者：响应消息、存储节点消息、存储资源消息、查找节点消息、查找资源消息、占用消息、解除占用消息；

类事件构造模块，用于构造查找过程中的类，所述类至少包括以下一者：组类、资源类、事务类、消息类、桶类、节点类；

参数设置子模块，用于设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数。

8.根据权利要求6所述装置，其特征在于，所述存储模块的预先计算所有资源的属性组和所有节点的空间属性LocationID，包括：

将节点的虚拟空间坐标定义为节点的空间属性Location ID。

9.根据权利要求6所述装置，其特征在于，还包括：最近距离计算模块

搜索过程中节点之间最近距离的计算和资源与查找方之间最近距离的计算都基于空间属性LocationID，所述最近距离计算模块包括：

将两个Location ID都转换为64位二进制数的整数形式；

对两个二进制数的整数形式的Location ID进行异或运算，得到的两个Location ID之间的距离的二进制整数形式表示；

将所述两个Location ID之间的距离的二进制整数形式转换为十进制整数表示输出。

10.根据权利要求7所述装置，其特征在于，所述参数设置子模块设置系统范围复制参数k的值，设置请求并发数的值，设置Location ID的长度位数，包括：

设置系统范围复制参数k的值为20，设置请求并发数的值为3，设置LocationID的长度位数为64位。