联盟链中的请求处理方法、系统、装置及设备
技术领域
本说明书实施例涉及信息技术领域,尤其涉及联盟链中的请求处理方法、系统、装置及设备。
背景技术
在联盟链中,常常存在功能差异很大的多个节点,例如,在一条著作权存证的联盟链上,可能包括作品发布节点、版权登记节点、版权转让节点以及公证节点等等。而基于用户的不同需求,和用户对接的往往只是其中的一个节点,该节点可以认为是该用户的对接节点。不同的节点所对接的用户数量各不相同。有的多,有的少。
在某些业务场景下,例如,客户端需要对联盟链进行可信度验证时,此时联盟链中的用户需要向其它节点(非对接节点)发出业务请求时,则会造成用户多的节点经常会请求到用户少的节点,造成联盟链中的节点对于请求的处理不平衡。
基于此,需要一种对联盟链中的请求进行处理的方案。
发明内容
针对现有联盟链中的请求处理不平衡的问题,为在联盟链的各节点中对请求实现更平衡的处理,本说明书实施例提供一种联盟链中的请求处理方案,该方案的第一方面,包括一种联盟链中的请求处理方法,在客户端生成交易,并通过对接节点将所述交易上链存证后,包括:
客户端发送请求至联盟链中的多个节点,所述请求包括交易位置查询请求和/或简单支付验证SPV请求,所述请求中包含所述交易的摘要哈希;
任一节点接收所述请求,确定所述客户端是自身节点用户还是其它节点用户;
当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理;
客户端基于多个节点分别返回的请求结果的一致程度,验证包含所述交易信息的联盟链的可信度。
第二方面,本说明书实施例还提供一种联盟链的可信度验证方法,在用户生成交易,并通过对接节点将所述交易上链存证后,包括:
获取联盟链中的多个节点地址以发送请求;
在发送请求前,针对所述多个节点中的任一节点,判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求;
接收所述多个节点地址返回的请求结果;
根据所述多个请求结果的一致程度,验证所述联盟链的可信度;
其中,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希。
第三方面,本说明书实施例还提供一种联盟链中的请求处理方法,在用户生成交易,并通过对接节点将所述交易上链存证后,包括:
接收客户端所发送的请求,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希;
确定所述客户端是自身节点用户还是其它节点用户;
当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理。
与第一方面对应的,本说明书实施例还提供一种联盟链中的请求处理系统,在客户端生成交易,并通过对接节点将所述交易上链存证后,包括:
客户端发送请求至联盟链中的多个节点,所述请求包括交易位置查询请求和/或简单支付验证SPV请求,所述请求中包含所述交易的摘要哈希;
任一节点接收所述请求,确定所述客户端是自身节点用户还是其它节点用户;
当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理;
客户端基于多个节点分别返回的请求结果的一致程度,验证包含所述交易信息的联盟链的可信度。
与第二方面对应的,本说明书实施例还提供一种联盟链的可信度验证装置,在用户生成交易,并通过对接节点将所述交易上链存证后,包括:
获取模块,获取联盟链中的多个节点地址以发送请求;
判断模块,在发送请求前,针对所述多个节点中的任一节点,判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求;
接收模块,接收所述多个节点地址返回的请求结果;
验证模块,根据所述多个请求结果的一致程度,验证所述联盟链的可信度;
其中,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希。
与第三方面对应的,本说明书实施例还提供一种联盟链中的请求处理装置,位于所述联盟链中的节点上,在用户生成交易,并通过对接节点将所述交易上链存证后,所述装置包括:
接收模块,接收客户端所发送的请求,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希;
身份确定模块,确定所述客户端是自身节点用户还是其它节点用户;
处理次数确定模块,当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
判断模块,根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理;
发送模块,发送请求处理结果至所述客户端。
本说明书实施例所提供的方案,在客户端需要向联盟链中的其它节点发送业务请求的场景下,通过在节点中对于自身处理其它节点用户请求的第一处理次数,和其它节点处理自身用户请求的第二处理次数,并进行计算,进而得出判断结果是否需要对该请求进行延迟处理还是转发至另一节点进行处理,从而可以在联盟链的各节点之间对请求实现更为平衡的处理。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书实施例。
此外,本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书实施例中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1为当前联盟链中所涉及的一种架构示意图;
图2是本说明书实施例提供的系统方面的一种联盟链中的请求处理方法的流程示意图;
图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图;
图4为本说明书是实施例所提供的一种联盟链中的请求处理方法的流程示意图;
图5为本说明书实施例所提供的一种联盟链的可信度验证装置的结构示意图;
图6为本说明书实施例所提供的一种请求处理装置的结构示意图;
图7是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本说明书的一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于保护的范围。
在联盟链中通常包含了多个不同的功能节点,在当前,联盟链常采用的一种架构为,各功能节点分别面向各自的用户,用户通过他们感兴趣的功能节点接入联盟链。
在本说明书实施例所涉及的联盟链中的节点,可以认为每个节点都参与联盟链网络的路由功能,同时也可以包含其他功能,例如,每个节点都可以参与验证并传播交易及区块信息,发现并维持与对等节点的连接,以及还可以在本地存储有完整的联盟链,和一些与联盟链相关的数据。
如图1所示,图1为当前联盟链中所涉及的一种架构示意图。在图1中,联盟链网络中的节点可能都包含有不同的功能,以及,各节点由于提供不同的功能,面向的目标用户也常常并不相同,在同一联盟链中,各功能节点还经常分别开发自己的应用程序APP让自身节点用户进行注册并接入。而用户则通常从中选取一个节点对接联盟链,进行交易发布以及验证。
在这种方式下,各节点的对接用户的数量各不相同,有些节点的用户数量多,如图1中的A节点,有些节点的用户数量少,如图1中的C节点,而有些节点则可能由于需要对公众保密,则完全没有注册用户如图1中的E、F节点。在一些业务场景下,当用户需要向其它节点(非对接节点)发送请求时,各节点之间对于请求的处理就显的很不平衡,注册用户少的节点总是会接收到超出本身本应负责处理的请求数量。因此,本说明书实施例提供一种联盟链中的请求处理方法,实现在联盟中对用户请求的平衡处理。
以下结合附图,详细说明本说明书各实施例提供的技术方案。本说明书实施例的方案的第一方面,如图2所示,图2是本说明书实施例提供的系统方面的一种联盟链中的请求处理方法的流程示意图,在客户端生成交易,并通过对接节点将所述交易上链存证后,该流程具体包括如下步骤:
S201,客户端发送请求至联盟链中的多个节点,所述请求包括交易位置查询请求和/或简单支付验证SPV请求,所述请求中包含所述交易的摘要哈希。
由于在用户完成交易并通过对接节点上链存证之后,就会收到一个关于该存证交易的通知消息,通常其中就包括摘要哈希,并保存于客户端本地。因此,客户端总是可以从本地中获取该摘要哈希,并将其加入交易位置查询请求中。
在客户端方面,可以是在收到该通知消息后,根据用户的指令发起查询请求;也可以是,接收到该通知消息即触发查询请求。
在用户通过对接节点接入联盟链进行交易处理时,交易的完成和验证仿佛是对接节点为中心的,进而,用户就会对该对接节点以及联盟链的可信度产生疑虑。因此,在这种业务场景下,客户端可以发送位置查询请求和/或简单支付验证SPV请求,目的是为了对联盟链的可信度进行验证。
S203,任一节点接收所述请求,确定所述客户端是自身节点用户还是其它节点用户。
确定的方式可以是通过客户端标识或者用户ID等等方式来确认。在联盟链中,各节点可以事先约定好一套互相认可的协议,用于识别各节点的客户端或者节点用户。
例如,给各节点所提供的客户端进行序号标记,每个序号对应一个节点,在请求中携带该序号,任一节点接收到请求时即可确认该请求来自于哪个节点的对接用户。
又例如,各节点可以在提供各节点用户注册时,对各节点用户ID分别加入头部标识,在用户发送请求是携带该用户ID,从而任一节点接收到请求时可以解析用户ID的头部得知该请求来自于哪个节点的对接用户。
S205,当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数。
若节点为自身节点用户,则直接进行处理即可。在节点为其它节点用户时,则需要进行进一步的判断。具体而言,可以在联盟链各节点之间共同维护一张表格,用以记载各节点所处理的任一其它节点的请求的次数,从而,对于任一节点,可以通过该表得出自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数。
第一处理次数和第二处理次数可以以一段时间为周期,例如,每天或者每月,定期进行清零,也可以是全部历史数据的数量统计。
S207,根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理。
判断是否延迟处理或者转发的条件,可以是根据第一处理次数X和第二处理次数Y计算获得一个贡献值Z与预设阈值进行比较,例如,Z=(X-Y)/Y,或者,Z=X/Y,或者Z=(X-Y)等等。贡献值表征了一个节点在处理请求时的“自身贡献”和“请求他人”的差异,一旦贡献值超过了一定阈值,则表示该节点已经做出了较多贡献,则该节点可以延迟处理接收到的其它节点用户所发送的请求,或者将其它节点所发送的请求转发出去。当然,如果不满足预设的贡献值条件,则依然在本地进行处理即可。
基于联盟共享的原则,若任一用户在选取节点发送请求时随机选取的情形下,容易理解,总是那些自身注册用户少的节点会接收到更多的请求。如图1中的架构下,节点E和F因为没有注册用户,其贡献比例值为无穷大,其次则为C节点。而在实际运用中,注册用户少的节点,因为其一般无需处理较大规模的业务,其一般对于大流量的处理能力相对弱(可称此类节点为弱节点,例如图1中的节点E、F和C)。对请求进行延迟处理请求可以有效降低弱节点的负荷。由于在本说明书实施例的方案中,客户端并不需要即时得到验证结果,因此各节点对于请求的处理可以是异步的,延迟处理并不会影响客户端对于联盟链的可信度的验证效果。
在延迟或者转移请求时,一种可实施方式为只要到达了贡献阈值条件即执行延迟或者转移处理,另一种可实施方式为,到达了贡献阈值条件之后,进一步区分用户是自身节点用户还是其它节点用户,并将其它节点用户的请求执行延迟或者转移处理。
对于延迟处理而言,一般而言,可以设置一个时间阈值,将接收到的请求推迟3个小时处理;或者,确定处理次数阈值为1000,如果自身的贡献值Z=(X-Y)超过了该阈值,则延迟处理之后的所有请求。
而节点在转发请求时,在一种实施方式下,可以随机进行转发,此时,在另一节点接收到该请求时,仍然可以进行延迟判断或者请求判断。在本说明书实施例所提供的方案中,为提高验证结果的可信度,在将请求随机转移所述请求至另一其它节点时,所述另一其它节点不包括所述客户端的对接节点。
在另一种实施方式下,也可以根据上述的贡献值进行转发。例如,根据联盟链之间共同维护的表格确定出各节点的贡献值,将请求优先转发至贡献值最小的节点。需要说明的是,延迟处理或者转发请求并非不处理,在延迟处理时限到达时,则应继续处理该类请求,并将处理结果返回至客户端。
本说明书实施例所涉及的请求包括交易位置查询请求和/或简单支付验证SPV请求,均可用在用户对于联盟链的可信度进行验证的场景下。
对于位置查询请求而言,由于一个区块链由多个区块组成,同时,一个区块中通常包含多个交易。因此,在本说明书实施例中,所述的位置信息具体指的是该交易被存证时,处于区块链中的哪个区块上,以及,在该区块中的什么位置。在区块链中,可以有多种方式用来标识不同的区块,例如,区块头哈希值或者区块高度(block height)。区块头哈希值即为区块头进行哈希计算而得到的哈希值,可以用于唯一、明确地标识一个区块。在区块链中,通常第一个区块其区块高度为0,以后每增加一个区块,区块高度加1。一个区块通常有一个明确的区块高度。因此,区块头哈希值或者区块高度可以作为区块元数据的一部分,被存储在节点中一个独立的数据库表中,以便于索引和更快地检索到该区块。同时,在一个区块中,由于通常包含了多个交易,因此,还可以用各交易在该区块中的地址偏移量来分别标识区块中的交易。显而易见,在同一个区块中,各交易的地址偏移量并不相同。
进而,可以在交易所处的区块上链存证以后,各节点中可以通过维护一张形如(交易摘要哈希,区块头哈希值,地址偏移量),或者,(交易摘要哈希,区块高度,地址偏移量)的数据表,就可以通过交易的摘要哈希查询得到对应的区块标识以及交易在区块中的地址。换言之,节点可以通过交易的摘要哈希确定该交易在联盟链中的位置。当然,由于区块链的具体格式是可以自定义的,在不同的区块格式下,位置信息的内容也会有所不同,这并不构成对本方案的限定。
而对于SPV验证而言,在区块链的每个区块中,包含了记录于该区块的所有交易,并且可以默克尔Merkle树表示。区块中所有的交易将数据哈希化,然后将哈希值存储至相应的叶子节点中。树中的每个叶子节点表征了一个交易。树中的一个叶子节点表征区块中存在一笔对应的交易。为了证明区块中存在某个特定的目标交易,一个节点只需要计算log2N个哈希值,形成一条从目标交易到树根的Merkle路径即可。节点在进行简单支付验证(Simplified Payment Verification,SPV)时,不必保存所有交易也不必下载整个区块。节点可以仅仅保存区块头,并通过目标交易的哈希和Merkle路径来验证目标交易是否存在于该区块中。换言之,各节点的SPV验证结果是一个二值结果,要么为“是”,要么为“否”。
S209,客户端基于多个节点分别返回的请求结果的一致程度,验证包含所述交易信息的联盟链的可信度。
对于位置查询请求而而言,由于一个交易在联盟链中只会有一个确定的位置,因此,联盟链的可信度可以基于查询结果的一致程度而定。理论上,各节点所返回的位置信息应该完全相同。一个较为严格的验证方式即为,若所有位置查询结果均一致,则该联盟链为可信的。当然,由于各种网络原因、设备原因等等,可以容许一定的偏差。例如,根据返回的所有结果的对一致程度进行计算,若返回的结果中不存在占比超过95%的相同查询结果,则认为联盟度可信度为0,否则,将所述相同结果的占比作为该联盟链的可信度。
而对于SPV验证请求而言,由于一个交易在联盟链中要么存在,要么不存在,理论上,当联盟链没有问题时,各节点所返回的SPV验证结果应该完全相同。因此,一个较为严格的可信度确认方式为,若所有SPV验证结果均一致为“是”,则确认该联盟链是可信的,否则是不可信的。当然,由于各种网络原因、设备原因等等,可以容许一定的偏差。例如,设定一个阈值,若SPV验证结果的一致为“是”的程度超过该阈值,则确认该联盟链是可信的。
需要说明的是,上述基于位置查询结果的一致性进行验证的方案,和基于SPV验证的结果的一致性进行验证的方案,属于可以同时分开进行的方案。在实际操作中,二者的验证结果是分别独立的。换言之,客户端可以只选择一种方式执行验证,也可以同时选择两种方式执行验证,在同时执行两种验证方案时,需要二种验证方案的结果同时满足一致性条件,才认为联盟链是可信的。以及,在验证的过程中,两种方案的执行不分先后。
进一步地,当确认该联盟链不可信时,还可以发出警报。具体的,警报消息中可以指出各节点的请求结果不一致的程度是多少(例如,各SPV结果中“是”和“否”的结果分别是多少),以及,具体的给出与多数结果不一致的节点和该类节点的请求结果。以及,还可以根据返回的所有结果的不一致的程度计算一个可信度数值作为参考。例如,若返回的结果中不存在占比超过一定阈值的相同查询结果,则认为联盟度可信,否则,则认为联盟链不可信。
本说明书实施例所提供的方案,在客户端需要向联盟链中的其它节点发送业务请求的场景下,通过在节点中对于自身处理其它节点用户请求的第一处理次数,和其它节点处理自身用户请求的第二处理次数,并进行计算,进而得出判断结果是否需要对该请求进行延迟处理还是转发至另一节点进行处理,从而可以在联盟链的各节点之间对请求实现更为平衡的处理。
在一种具体的实施方式下,客户端获取联盟链中的多个节点地址,可以是客户端随机获取联盟链中的多个节点地址,随机获取节点地址验证可以使得验证结果更加公正,同时,也会使得用户的请求平均的流向各节点。又或者,客户端获取联盟链中包含所述对接节点地址的多个节点地址,在这种方式下,用户可以首先选取一批节点地址,然后再将对接节点的地址加入即可。加入对接节点进行验证时,在返回的结果中也包含对接节点的验证结果,可以使得验证更具有针对性,提高用户体验。
在一种实施方式下,节点可以对于任意连接自己的客户端所发送的查询请求或者SPV请求进行处理。在另一种实施方式下,基于联盟共享的原则,各节点还可以提供查询服务或者SPV服务给白名单用户,节点可以根据白名单确认所述客户端的用户类型为非法用户或者合法用户,以及进一步地对合法用户进行区分,确认是自身节点用户还是其它节点用户,如果根据白名单判断客户端是非法用户,则不进行处理。此处的非法用户可以认为是没有注册过的用户,或者时限到期的用户,或者权限受限的用户等等。换言之,节点可以根据白名单确认发送请求的客户端是非法用户、自身节点合法用户或者非自身节点合法用户,客户端是合法用户时节点才对请求进行处理。
确定白名单用户的具体方式包括:联盟链中的任一节点确定自身的白名单,并广播白名单至联盟链中的其它节点,以便其它节点根据所述白名单确定是否执行查询处理。一种常见的处理方式即为,联盟链中的任一节点将自身的注册用户确认为白名单用户并进行广播。而其它节点则可以根据请求所包含的客户端标识是否是白名单用户,来决定是否进行进一步的处理。此处的白名单可以以节点为最小单元,也可以以用户为最小单元,各节点所保存的白名单用户可以相同,也可以不同。节点接收到白名单用户所发送的请求时才进行处理。
例如,假设联盟链中存在A、B、C、D四个节点,在上述方案中,可以B、C、D节点将A节点的对接用户确认为白名单用户,四个节点共同维护;也可以在B节点的白名单用户中包括A节点的用户,但是C、D节点的白名单用户中不包括A节点的用户。具体的情形可以基于业务情形自行确定。
在较为一般的情形中,政府机构(例如公证处)或者公益机构(例如慈善机构)节点的对接用户可以是所有联盟链中其它节点的白名单用户,一个节点的业务伙伴节点的节点用户也可以是该节点的白名单用户。进一步,在各节点中还可以根据用户的来源或者历史行为数据以及其它因素(例如,第三方信用评估分),对白名单用户进行权限分级,例如,最低权限的白名单用户只有查询权限,更高权限的白名单用户可能还可以拥有进一步的其它权限等等。
在一种实施方式下,客户端在选取多个节点时,有可能连续多次选到同一个节点,在这种方式下,客户端可以判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求。发送次数的统计可以统计一段时间内的次数,也可以统计所有的历史次数。通过上述方式,在客户端方面即可以避免连续的请求同一节点,避免对另一节点的负荷的影响。
本说明书实施例的方案的第二方面,如图3所示,图3为本说明书是实施例所提供的客户端方面的一种联盟链的可信度验证方法的流程示意图,在用户生成交易,并通过对接节点将所述交易上链存证后,包括:
S301,获取联盟链中的多个节点地址以发送请求;其中,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希;
S303,在发送请求前,针对所述多个节点中的任一节点,判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求;
S305,接收所述多个节点地址返回的请求结果;
S307,根据所述多个请求结果的一致程度,验证所述联盟链的可信度。
进一步地,所述方法中S301中,获取联盟链中的多个节点地址,包括随机获取联盟链中的多个节点地址;或者,获取联盟链中包含所述对接节点地址的多个节点地址。
本说明书实施例的方案的第三方面,如图4所示,图4为本说明书是实施例所提供的一种联盟链中的请求处理方法的流程示意图,在用户生成交易,并通过对接节点将所述交易上链存证后,包括:
S401,接收客户端所发送的请求,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希;
S403,确定所述客户端是自身节点用户还是其它节点用户;
S405,当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
S407,根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理。
进一步地,在接收客户端所发送的请求之前,上述方法还包括:确定自身节点的白名单用户,所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户,所述合法用户包括自身节点用户或者其它节点用户;发送白名单至联盟链中的其它节点,以便其它节点接收并存储所述白名单。
进一步的,上述方法还包括,接收到请求时,判断所述客户端是否为合法用户,若否,不对请求执行处理。
进一步的,所述步骤S407中的,转移所述请求至其它节点处理,包括随机转移所述请求至另一其它节点,所述另一其它节点不包括所述客户端的对接节点。
与第一方面对应的,本说明书实施例还提供一种联盟链中的请求处理系统,包括客户端和联盟链网络,所述联盟链网络包括多个节点;在客户端生成交易,并通过对接节点将所述交易上链存证后,
客户端发送请求至联盟链中的多个节点,所述请求包括交易位置查询请求和/或简单支付验证SPV请求,所述请求中包含所述交易的摘要哈希;
任一节点接收所述请求,确定所述客户端是自身节点用户还是其它节点用户;
当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理;
客户端基于多个节点分别返回的请求结果的一致程度,验证包含所述交易信息的联盟链的可信度。
进一步地,在所述系统中,客户端随机获取联盟链中的多个节点地址,发送请求至联盟链中的所述多个节点;或者,客户端获取联盟链中包含所述对接节点地址的多个节点地址,发送请求至联盟链中的所述多个节点。
进一步地,在所述系统中,所述节点随机转移所述请求至另一其它节点,所述另一其它节点不包括所述客户端的对接节点。
进一步地,在所述系统中,在客户端发送请求至联盟链中的多个节点之前,任一节点确定自身节点的白名单用户,所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户,所述合法用户包括自身节点用户或者其它节点用户;发送白名单至联盟链中的其它节点,以便其它节点接收并存储所述白名单。
进一步地,在所述系统中,在确定自身节点对于其它节点用户的请求的第一处理次数之前,任一节点接收到请求时,根据白名单判断所述客户端是否为合法用户,若否,不对请求执行处理。
进一步地,在所述系统中,客户端针对所述多个节点中的任一节点,判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求。
与第二方面对应的,本说明书实施例还提供一种联盟链的可信度验证装置,在用户生成交易,并通过对接节点将所述交易上链存证后,如图5所示,图5为本说明书实施例所提供的一种联盟链的可信度验证装置的结构示意图,所述装置包括:
获取模块501,获取联盟链中的多个节点地址以发送请求;
判断模块503,在发送请求前,针对所述多个节点中的任一节点,判断对该节点的请求的发送次数是否到达阈值,若是,对该节点延迟发送请求;当然,如果没有达到阈值,则正常发送请求;
接收模块505,接收所述多个节点地址返回的请求结果;
验证模块507,根据所述多个请求结果的一致程度,验证所述联盟链的可信度;
其中,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希。
进一步地,所述获取模块501,随机获取联盟链中的多个节点地址;或者,获取联盟链中包含所述对接节点地址的多个节点地址。
与第三方面对应的,本说明书实施例还提供一种联盟链中的请求处理装置,位于所述联盟链中的节点上,在用户生成交易,并通过对接节点将所述交易上链存证后,如图6所示,图6为本说明书实施例所提供的一种请求处理装置的结构示意图,所述装置包括:
接收模块601,接收客户端所发送的请求,所述请求包括交易位置查询请求或者简单支付验证SPV请求,所述请求中包含目标交易的摘要哈希;
身份确定模块603,确定所述客户端是自身节点用户还是其它节点用户;
处理次数确定模块605,当所述客户端为其它节点用户时,确定自身节点对于其它节点用户的请求的第一处理次数,以及,确认其它节点对于自身节点用户请求的第二处理次数;
判断模块607,根据所述第一处理次数和第二处理次数,执行对请求的处理,所述处理包括:延迟处理所述客户端所发送的请求,或者,转移所述请求至其它节点处理。
发送模块609,任一节点在处理完之后,即将发送结果至所述客户端。
进一步地,所述装置还包括白名单标记模块611,确定自身节点的白名单用户,所述所述白名单用于确认所述客户端的用户类型为非法用户或者合法用户,所述合法用户包括自身节点用户或者其它节点用户;发送模块609,发送白名单至联盟链中的其它节点,以便其它节点接收并存储所述白名单。
进一步地,所述判断模块607还用于,接收到请求时,根据白名单判断所述客户端是否为合法用户,若否,不对请求执行处理。
进一步地,所述发送模块还用于,随机转移所述请求至另一其它节点,所述另一其它节点不包括所述客户端的对接节点。
本说明书实施例还提供一种计算机设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现图3所示的联盟链的可信度验证方法。
本说明书实施例还提供一种计算机设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现图4所示的联盟链中的请求处理方法。
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图,该设备可以包括:处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器1020中,并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路,在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本说明书实施例方案所必需的组件,而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现图3所示的联盟链的可信度验证方法。
本说明书实施例还提供另一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现图4所示的联盟链中的请求处理方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于方法实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本说明书实施例原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本说明书实施例的保护范围。