发明内容
本申请提供一种数据处理方法、装置、区块链节点及存储介质,以解决现有技术具有中心化风险、可信度较差等缺陷。
本申请第一个方面提供一种数据处理方法,包括:
接收客户端发送的第一交易数据;
将所述第一交易数据发送到消息队列,以使所述消息队列对接收到的各Peer节点发送的交易数据进行排序并将排序结果广播给各Peer节点;
接收所述消息队列广播的排序结果;
根据所述排序结果进行相应的处理。
可选地,所述根据所述排序结果进行相应的处理,包括:
若所述排序结果中的包括普通类型的交易数据,则将普通类型的交易数据进行缓存,并判断当前是否满足预设结块条件;
若满足预设结块条件,则根据当前已缓存的交易数据生成结块交易消息发送至所述消息队列,以使所述消息队列将所述结块交易消息广播给各Peer节点,所述结块交易消息包括最新区块高度、交易ID列表及结块条件。
可选地,所述若满足预设结块条件,则根据当前已缓存的交易数据生成结块交易消息发送至所述消息队列,包括:
若当前已缓存的交易数量满足预设数量条件,则基于当前已缓存的交易数据生成结块交易消息发送至所述消息队列,所述结块条件包括结块的交易数量。
可选地,若当前已缓存的交易数量不满足预设数量条件,但当前时间满足预设时间条件,则基于当前已缓存的交易数据生成结块交易消息发送至所述消息队列,所述结块条件包括结块起始时间和生成结块交易消息的时间。
可选地,所述根据所述排序结果进行相应的处理,包括:
若所述排序结果中包括结块交易消息,则获取所述结块交易消息中的最新区块高度、交易ID列表和结块条件;
根据所述交易ID列表,从缓存中获取对应的交易数据生成区块并写入账本。
可选地,在所述根据所述交易ID列表,从缓存中获取对应的交易数据生成区块之前,还包括:
判断所述最新区块高度是否已处理;
若未处理,则判断所述结块条件是否与所述交易ID列表匹配;
相应的,所述根据所述交易ID列表,从缓存中获取对应的交易数据生成区块,包括:
若所述结块条件与所述交易ID列表匹配,则根据所述交易ID列表,从缓存中获取对应的交易数据生成区块。
可选地,所述根据所述交易ID列表,从缓存中获取对应的交易数据生成区块,包括:
判断所述缓存中是否能获取到所述交易ID列表对应的全部交易数据;
若从缓存中只获取到所述交易ID列表对应的部分交易数据,则等待预设时间后再从缓存中获取所述交易ID列表对应的剩余交易数据;
在获取到所述交易ID列表对应的全部交易数据之后,根据所述交易ID列表对应的全部交易数据生成区块;
若在等待预设时间后仍不能从缓存中获取所述交易ID列表对应的剩余交易数据,则标记异常,不写入账本。
可选地,所述方法还包括:
获取当前之前预设时间段内的结块交易分布信息,所述结块交易分布信息包括Peer节点信息及各Peer节点每次的结块条件;
根据所述结块交易分布信息判断各Peer节点是否存在结块交易分布异常;
若存在,则将结块交易分布异常的Peer节点信息及预定区块高度打包为分布异常消息;
对所述分布异常消息进行签名后发送至所述消息队列,以使所述消息队列将所述分布异常消息广播给各Peer节点。
可选地,所述方法还包括:
接收所述消息队列广播的分布异常消息;
若所述分布异常消息中包括自己的签名,则判断所述分布异常消息中包括的签名数量是否满足预设签名条件,若满足,则将所述分布异常消息中的分布异常的Peer节点信息及预定区块高度进行记录;
当执行到所述预定区块高度时,屏蔽所述分布异常的Peer节点信息对应的Peer节点提交的结块交易消息;
若所述分布异常消息中不包括自己的签名,则判断所述分布异常消息中包括的分布异常的Peer节点信息与自己判断获得的分布异常的Peer节点信息是否一致,若一致,则对所述分布异常消息进行签名后发送至所述消息队列,以使所述消息队列再次进行广播。
可选地,在接收客户端发送的第一交易数据之后,所述方法还包括:
对所述第一交易数据进行验证;
若验证通过,则对所述第一交易数据进行签名,获得第二交易数据;
相应的,将所述第一交易数据发送到消息队列,包括:
将所述第二交易数据发送到消息队列。
本申请第二个方面提供一种数据处理装置,包括:
第一接收模块,用于接收客户端发送的第一交易数据;
发送模块,用于将所述第一交易数据发送到消息队列,以使所述消息队列对接收到的各Peer节点发送的交易数据进行排序并将排序结果广播给各Peer节点;
第二接收模块,用于接收所述消息队列广播的排序结果;
处理模块,用于根据所述排序结果进行相应的处理。
可选地,所述处理模块,具体用于:
若所述排序结果中的包括普通类型的交易数据,则将普通类型的交易数据进行缓存,并判断当前是否满足预设结块条件;
若满足预设结块条件,则根据当前已缓存的交易数据生成结块交易消息发送至所述消息队列,以使所述消息队列将所述结块交易消息广播给各Peer节点,所述结块交易消息包括最新区块高度、交易ID列表及结块条件。
可选地,所述处理模块,具体用于:
若当前已缓存的交易数量满足预设数量条件,则基于当前已缓存的交易数据生成结块交易消息发送至所述消息队列,所述结块条件包括结块的交易数量。
可选地,所述处理模块,具体用于:
若当前已缓存的交易数量不满足预设数量条件,但当前时间满足预设时间条件,则基于当前已缓存的交易数据生成结块交易消息发送至所述消息队列,所述结块条件包括结块起始时间和生成结块交易消息的时间。
可选地,所述处理模块,具体用于:
若所述排序结果中包括结块交易消息,则获取所述结块交易消息中的最新区块高度、交易ID列表和结块条件;
根据所述交易ID列表,从缓存中获取对应的交易数据生成区块并写入账本。
可选地,所述处理模块,还用于:
判断所述最新区块高度是否已处理;
若未处理,则判断所述结块条件是否与所述交易ID列表匹配;
相应的,所述处理模块,具体用于:
若所述结块条件与所述交易ID列表匹配,则根据所述交易ID列表,从缓存中获取对应的交易数据生成区块。
可选地,所述处理模块,具体用于:
判断所述缓存中是否能获取到所述交易ID列表对应的全部交易数据;
若从缓存中只获取到所述交易ID列表对应的部分交易数据,则等待预设时间后再从缓存中获取所述交易ID列表对应的剩余交易数据;
在获取到所述交易ID列表对应的全部交易数据之后,根据所述交易ID列表对应的全部交易数据生成区块;
若在等待预设时间后仍不能从缓存中获取所述交易ID列表对应的剩余交易数据,则标记异常,不写入账本。
可选地,所述处理模块,还用于:
获取当前之前预设时间段内的结块交易分布信息,所述结块交易分布信息包括Peer节点信息及各Peer节点每次的结块条件;
根据所述结块交易分布信息判断各Peer节点是否存在结块交易分布异常;
若存在,则将结块交易分布异常的Peer节点信息及预定区块高度打包为分布异常消息;
对所述分布异常消息进行签名后发送至所述消息队列,以使所述消息队列将所述分布异常消息广播给各Peer节点。
可选地,所述第二接收模块,还用于接收所述消息队列广播的分布异常消息;
所述处理模块,还用于:
若所述分布异常消息中包括自己的签名,则判断所述分布异常消息中包括的签名数量是否满足预设签名条件,若满足,则将所述分布异常消息中的分布异常的Peer节点信息及预定区块高度进行记录;
当执行到所述预定区块高度时,屏蔽所述分布异常的Peer节点信息对应的Peer节点提交的结块交易消息;
若所述分布异常消息中不包括自己的签名,则判断所述分布异常消息中包括的分布异常的Peer节点信息与自己判断获得的分布异常的Peer节点信息是否一致,若一致,则对所述分布异常消息进行签名后发送至所述消息队列,以使所述消息队列再次进行广播。
可选地,所述处理模块,还用于对所述第一交易数据进行验证,若验证通过,则对所述第一交易数据进行签名,获得第二交易数据;
相应的,所述发送模块,具体用于:将所述第二交易数据发送到消息队列。
本申请第三个方面提供一种区块链节点,包括:至少一个处理器和存储器;
所述存储器用于存储所述处理器可执行指令,以使所述至少一个处理器执行所述处理器可执行指令实现第一个方面提供的方法。
本申请第四个方面提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,所述计算机执行指令被处理器执行时用于实现第一个方面提供的方法。
本申请提供的数据处理方法、装置、区块链节点及存储介质,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
首先对本申请所涉及的名词进行解释:
Fabric:是指超级账本Hyperledger Fabric,Fabric架构(或者Fabric区块链***)主要包括客户端、Peer节点及排序服务节点(Orderer节点)。如图1所示,为Fabric区块链***的结构示意图;如图2所示,为Fabric区块链***的处理流程示意图。其中,客户端向Orderer节点发送交易数据,Orderer节点将交易数据发送到消息队列(MQ)进行排序,消息队列向各Orderer节点发送排序后消息,Orderer节点持续接收消息队列发送的排序后消息,并判断是否接收到结块消息,若接收到结块消息,则进行结块,若未接收到结块消息,则判断当前是否满足数量条件,若满足,则直接结块,若不满足,则判断时间是否满足,若时间满足,则Orderer节点向消息队列发送结块消息,并向Peer节点广播整个区块信息,Peer节点将区块信息写入账本。但是,现有的基于消息队列的共识机制,整个共识流程主要是Orderer节点判断结块,Peer节点记账,Orderer节点数量较少,本身具有中心化的风险,可信性较差。且数量结块条件没有结块标识,完全依赖于MQ的稳定性,若某个Orderer节点接收数据异常,则会直接导致后续所有的结块处理全部失败;并且处理性能较低,因为Orderer节点结块后需要将整个区块的信息广播至周围的Peer节点,整个区块的信息包括了这个区块中所有的内容,这样既存在网络阻塞的问题,同时也导致整个区块不宜过大(即每个区块含有交易数量较少),从而导致其性能受限。其中,应答1和应答2仅仅是状态应答,非实际结果应答,实际应答结果为Peer节点的应答的信息。
针对以上问题,本申请实施例提供的数据处理方法,适用于以下的区块链***:
如图3所示,为本申请实施例基于的区块链***的结构示意图。该区块链***包括:客户端和Peer节点,所有Peer节点都接入消息队列,每个Peer节点都是交易的消费者和共识的生产者,每个Peer节点监听两个Topic(包括交易Topic和共识Topic),对其进行不同的处理。具体来说,客户端向其对应的Peer节点发送交易数据,该交易数据可以是经客户端签名的交易数据,Peer节点接收到客户端发送的交易数据后,进行签名验证,验证通过后,Peer节点对交易数据进行签名后发送至消息队列进行排序,消息队列将排序结果广播给各Peer节点,各Peer节点根据排序结果来生成区块写入账本。当Peer节点接收到的是普通类型的交易数据时,将交易数据进行缓存,并判断当前已缓存的交易数据是否满足预设结块条件,若满足,则将当前已缓存的交易数据生成结块交易消息发送至消息队列进行排序,由消息队列广播给各Peer节点,当Peer节点接收到消息队列广播的结块交易消息,则根据结块交易消息从缓存中获取对应的交易数据进行结块,写入账本。本申请实施例提供的数据处理方法,所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。该区块链***中,Peer节点既是消息的生产者,也是消息的消费者,并且节点与节点之间都是完全一样的,不存在角色的区别。
此外,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中,“多个”的含义是两个以上,除非另有明确具体的限定。
下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本发明的实施例进行描述。
实施例一
本实施例提供一种数据处理方法,用于区块链网络的数据处理。本实施例的执行主体为数据处理装置,该装置可以设置在区块链节点中,具体可以设置在Peer节点中。
如图4所示,为本实施例提供的数据处理方法的流程示意图,该数据处理方法包括:
步骤101,接收客户端发送的第一交易数据。
客户端生成交易后,对交易进行签名,并将签名后的交易数据(即第一交易数据)发送至某个Peer节点(为了区分可以称为第一Peer节点)。该第一Peer节点即可接收到客户端发送的第一交易数据。
步骤102,将第一交易数据发送到消息队列,以使消息队列对接收到的各Peer节点发送的交易数据进行排序并将排序结果广播给各Peer节点。
第一Peer节点接收到客户端发送的第一交易数据后,将第一交易数据发送到消息队列,区块链***中各Peer节点(包括上述的第一Peer节点)均可以接收与其通信的客户端发送的交易数据,并发送到消息队列。
消息队列具有整体排序功能,所有接收到的消息都会进行排序,消息队列对接收到的各Peer节点发送的交易数据(包括上述的第一交易数据)进行排序,并将排序结果广播给各Peer节点。
排序结果包括排序后的各交易数据,排序结果还可以包括各Peer节点发送的结块交易消息,具体来说,各Peer节点在接收到消息队列广播的普通类型的交易数据后,将普通类型的交易数据进行缓存,并判断当前已缓存的交易数据是否满足预设结块条件,当满足预设结块条件时,则生成结块交易消息发送到消息队列进行排序,消息队列广播的排序结果则包括了结块交易消息。结块交易消息可以包括最新区块高度、交易ID列表及结块条件。结块交易消息表示交易ID列表中的交易ID对应的交易数据可以进行结块。
可选地,第一Peer节点接收到客户端发送的第一交易数据后,还可以对第一交易数据进行验证,可以是验证第一交易数据中客户端的签名是否正确,保证交易数据的安全性。
可选地,第一Peer节点接收到客户端发送的第一交易数据后,还可以对第一交易数据进行签名后再发送给消息队列,提高交易数据的安全性。
可选地,消息队列可以采用RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等任意可实施的方式来实现,本实施例不做限定。
步骤103,接收消息队列广播的排序结果。
各Peer节点自启动后悔持续监听消息队列发送的消息,消息队列广播排序结果后,第一Peer节点接收消息队列广播的排序结果,当然其他Peer节点也接收消息队列广播的排序结果。
步骤104,根据排序结果进行相应的处理。
第一Peer节点接收到排序结果后,可以对排序结果进行相应的处理。
示例性的,当接收到的排序结果包括结块交易消息时,表示可以根据结块交易消息进行结块,具体来说,可以从结块交易消息中获取最新区块高度、交易ID列表及结块条件,根据交易ID列表从缓存中获取各交易ID对应的交易数据,生成区块。
示例性的,若接收到的是普通类型的交易数据(即源于客户端发送的交易数据),则将普通类型的交易数据进行缓存,并判断当前已缓存的交易数据是否符合预设结块条件,若符合预设结块条件,则生成结块交易消息,发送至消息队列进行排序,消息队列将排序结果发送至各Peer节点,则排序结果中包括了结块交易消息,各Peer节点接收到结块交易消息后,则根据结块交易消息进行结块,写入账本。其中,预设结块条件可以包括交易数量条件(即预设数量条件)和区块生成时间条件(即预设时间条件)。当满足其中任一条件时,即可表示满足了预设结块条件,可以进行结块。比如当前已缓存的交易数量达到预设数量条件时,则将当前已缓存的交易数据生成结块交易消息发送至消息队列进行排序。
可选地,第一Peer节点接收到消息队列发送的排序结果后,还可以对排序结果进行验证,验证排序结果中的签名是否正确。在验证通过后,再进行后续处理。
本实施例提供的数据处理方法,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。
实施例二
本实施例对实施例一提供的方法做进一步补充说明。
如图5所示,为本实施例提供的一种数据处理方法的流程示意图。
作为一种可实施的方式,在上述实施例的基础上,可选地,步骤104具体包括:
步骤1041,若排序结果中的包括普通类型的交易数据,则将普通类型的交易数据进行缓存,并判断当前是否满足预设结块条件。
第一Peer节点接收到排序结果后,可以分析排序结果包括的消息类型,若排序结果包括普通类型的交易数据,则将普通类型的交易数据进行缓存,并判断当前是否满足预设结块条件。
步骤1042,若满足预设结块条件,则根据当前已缓存的交易数据生成结块交易消息发送至消息队列,以使消息队列将结块交易消息广播给各Peer节点,结块交易消息包括最新区块高度、交易ID列表及结块条件。
若符合预设结块条件,则生成结块交易消息,发送至消息队列进行排序,消息队列将排序结果发送至各Peer节点,则排序结果中包括了结块交易消息。其中,预设结块条件可以包括交易数量条件(即预设数量条件)和区块生成时间条件(即预设时间条件)。当满足其中任一条件时,即可表示满足了预设结块条件,可以进行结块。比如当前已缓存的交易数量达到预设数量条件时,则将当前已缓存的交易数据生成结块交易消息发送至消息队列进行排序。
可选地,在生成结块交易消息后,第一Peer节点还可以对结块交易消息进行签名后发送到消息队列进行排序。
可选地,步骤1042具体可以包括:
步骤2011,若当前已缓存的交易数量满足预设数量条件,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,结块条件包括结块的交易数量。
具体的,若当前已缓存的交易数量满足预设数量条件,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,这种情况下,结块交易消息中包括的结块条件包括结块的交易数量。
步骤2012,若当前已缓存的交易数量不满足预设数量条件,但当前时间满足预设时间条件,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,结块条件包括结块起始时间和生成结块交易消息的时间。
具体的,若当前已缓存的交易数量不满足预设数量条件,但当前时间满足预设时间条件,即已到达区块生成时间,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,这种情况下,结块条件包括结块起始时间和生成结块交易消息的时间。
作为另一种可实施的方式,在上述实施例的基础上,可选地,步骤104具体包括:
步骤2021,若排序结果中包括结块交易消息,则获取结块交易消息中的最新区块高度、交易ID列表和结块条件。
具体的,若第一Peer节点接收到结块交易消息,则表示需要进行结块,则可以获取结块交易消息中的最新区块高度、交易ID列表和结块条件。
步骤2022,根据交易ID列表,从缓存中获取对应的交易数据生成区块。
在获取到结块交易消息中的最新区块高度、交易ID列表和结块条件后,则可以根据交易ID列表,从缓存中获取对应的交易数据生成区块。交易ID列表中包括了可以进行结块的所有交易ID,也即,结块交易消息中包括的是交易ID,而不需要包括具体的交易数据,提高数据传输效率。
可选地,在根据交易ID列表,从缓存中获取对应的交易数据生成区块之前,还包括:
步骤2031,判断最新区块高度是否已处理。
具体的,由于各Peer节点都在进行相同的工作,在第一Peer节点接收到结块交易消息进行结块时,可能其他Peer节点已经处理,所以需要首先判断结块交易消息中包括的该最新区块高度是否处理过,若已处理,则直接放弃,若未处理则继续处理。
步骤2032,若未处理,则判断结块条件是否与交易ID列表匹配。
具体的,若判断最新区块高度未处理,则可以判断结块交易消息中包括的结块条件是否与交易ID列表匹配,例如,按照交易数量条件结块的情况下,交易ID列表中的交易ID数量必须要和结块条件中的交易数量一致。在一致时才可以进行结块,以保证数据的正确性。
相应的,根据交易ID列表,从缓存中获取对应的交易数据生成区块,包括:
步骤20221,若结块条件与交易ID列表匹配,则根据交易ID列表,从缓存中获取对应的交易数据生成区块。
具体的,若结块条件与交易ID列表匹配,则可以根据交易ID列表从缓存中获取各交易ID对应的交易数据生成区块,写入账本。
可选地,根据交易ID列表,从缓存中获取对应的交易数据生成区块,包括:
步骤2041,判断缓存中是否能获取到交易ID列表对应的全部交易数据。
步骤2042,若从缓存中只获取到交易ID列表对应的部分交易数据,则等待预设时间后再从缓存中获取交易ID列表对应的剩余交易数据。
步骤2043,在获取到交易ID列表对应的全部交易数据之后,根据交易ID列表对应的全部交易数据生成区块。
步骤2044,若在等待预设时间后仍不能从缓存中获取交易ID列表对应的剩余交易数据,则标记异常,不写入账本。
具体的,在生成区块时,需要根据交易ID列表从缓存中获取交易ID列表中所有交易ID对应的交易数据后才能进行结块,以进一步保证数据的准确性。
若在获取时,从缓存中只获取到交易ID列表对应的部分交易数据,则等待预设时间后再从缓存中获取交易ID列表对应的剩余交易数据,在获取到交易ID列表对应的全部交易数据之后,根据交易ID列表对应的全部交易数据生成区块。
可选地,在生成区块后,需要标记最新区块,即更新最新区块高度,还需要重置区块生成时间,比如下一次生成区块的等待时间,以为下一次结块判断做准备。
若在预设时间内始终没有获取到交易ID列表对应的所有交易数据,则不将交易写入账本,可以标记本区块数据异常,但无论如何都需要标记最新区块,重置结块时间(即重置区块生成时间)。对于本次没有写入账本的区块则可以后续通过其他方式进行同步处理,比如通过数据状态同步等等。
示例性的,如图6所示,为本实施例提供的数据处理方法中共识流程示意图。这里只以第一Peer节点Peer1为例,在实际应用中,所有的Peer节点均会做相同的操作,具体与第一Peer节点操作一致,在此不再一一赘述。其中,交易类型即是指排序结果包括的消息类型,也即是普通类型的交易数据还是结块交易消息。验签是指验证签名。将交易数据放入缓冲区即进行缓存。具体过程如下:
1、客户端生成交易数据后,对交易数据进行签名,然后发送至某个Peer节点;
2、Peer节点验签通过后,会附加自己的签名,并将消息发送至消息队列;
3、Peer节点自启动后会持续监听消息队列发送的消息;
4、消息队列具有整体排序的功能,所有接收到的消息(所有Peer节点发送)都会进行排序,并推送(广播)至所有的Peer节点;
5、Peer节点接收到消息队列发送的消息(排序结果)后,首先对消息进行验签,然后判断消息中包含交易的类型,交易类型分为两类,一种是普通交易(即由客户端发送的交易),第二种为结块交易(即结块交易消息),结块交易消息是判断是否结块的标准;
6、假若收到的消息是普通交易,则将该交易数据放入缓冲区(内存),然后判断当前缓冲区中含有的交易数量是否满足结块条件,假设满足则将所有交易数据的交易ID按序取出,生成结块交易消息(包含最新的区块高度、所有的交易ID列表和结块条件),然后将结块交易消息签名后发送至消息队列,其中结块条件仅仅是一个标识,它存在两种情况:
1)按照数量结块:该种情况下结块条件中存放的是结块的数量;
2)按照时间结块:该种情况下存放的是两个时间,结块起始时间和当前时间(产生结块交易消息的时间);
7、假若数量尚不满足条件,则判断当前时间是否满足条件,若满足则将所有交易的交易ID按序取出,生成结块交易消息(包含最新的区块高度、所有的交易ID列表和结块条件),然后将结块交易消息签名后发送至消息队列;
8、假若收到的消息是结块交易消息,则获取该结块交易消息中的内容,包括最新区块高度、所有的交易ID列表和结块条件,首先判断该区块高度是否处理过,若已处理则直接放弃,若未处理则判断结块条件与交易ID列表是否匹配(例如按照数量条件结块的情况下,交易ID列表的数量必须要和该值完全一致),在一致的情况下从缓冲区中根据交易ID列表获取所有的交易数据,然后判断是否所有的交易ID均获取到交易数据,假设获取到则将交易数据写入账本,生成新的区块,然后标记最新区块,重置结块时间(即区块生成时间);假设没有则等待指定的时间,再判断刚刚剩余的交易ID是否可以获取到,若可以获取到则将交易数据写入账本,否则则不将交易数据写入账本(标记本区块数据异常),但无论如何都需要标记最新区块,重置结块时间。对于本次没有写入账本的区块则需要后续通过其他方式(如数据状态同步等)进行同步处理。
如图7所示,为本实施例提供的另一种数据处理方法的流程示意图。
作为另一种可实施的方式,在上述实施例的基础上,可选地,该方法还包括:
步骤2051,获取当前之前预设时间段内的结块交易分布信息,结块交易分布信息包括Peer节点信息及各Peer节点每次的结块条件。
步骤2052,根据结块交易分布信息判断各Peer节点是否存在结块交易分布异常。
步骤2053,若存在,则将结块交易分布异常的Peer节点信息及预定区块高度打包为分布异常消息。
步骤2054,对分布异常消息进行签名后发送至消息队列,以使消息队列将分布异常消息广播给各Peer节点。
可选地,该方法还可以包括:
步骤2055,接收消息队列广播的分布异常消息。
步骤2056,若分布异常消息中包括自己的签名,则判断分布异常消息中包括的签名数量是否满足预设签名条件,若满足,则将分布异常消息中的分布异常的Peer节点信息及预定区块高度进行记录。
步骤2057,当执行到预定区块高度时,屏蔽分布异常的Peer节点信息对应的Peer节点提交的结块交易消息。
步骤2058,若分布异常消息中不包括自己的签名,则判断分布异常消息中包括的分布异常的Peer节点信息与自己判断获得的分布异常的Peer节点信息是否一致,若一致,则对分布异常消息进行签名后发送至消息队列,以使消息队列再次进行广播。
其中步骤2055至2058也可以是在步骤2051-2054之前或之间的任意时刻执行,由于各Peer节点均可能提交分布异常消息,由消息队列进行广播,所以对于一个Peer节点来说,可能自己还未提交分布异常消息即接收到消息队列广播的分布异常消息,上述只是一种示例性的实施方式,并非对具体执行步骤顺序的限定。
具体的,上述的共识流程中会存在一种恶意的情况,即某些Peer节点会频繁提交结块交易消息,例如,某些Peer节点仅仅将自己的消息打包成结块交易消息(无论是否满足预设结块条件),发送至消息队列,对于这种情况,提供一种恶意结块监控机制,具体来说,各Peer节点(以第一Peer节点为例)都可以定时或实时统计最近一段时间内结块分布情况(即结块交易分布信息),结块分布情况主要可以包括:结块节点信息(即提交结块交易消息的Peer节点信息)及每次的结块条件。根据统计的结块分布情况,判断结块是否存在分布异常,如果存在分布异常,则可以将结块交易分布异常的Peer节点信息提取出,并约定一个处理的区块高度(即预定区块高度),约定的处理的区块高度通常可以为当前最新区块高度+N,N为自定义值,可以根据实际需求设置,比如当前最新区块高度为80,N为10,则预定区块高度未90。第一Peer节点将结块交易分布异常的Peer节点和预定区块高度打包为一个消息(可以称为分布异常消息),对该消息签名后发送至消息队列,消息队列会将分布异常消息广播给所有Peer节点,每个Peer节点(包括第一Peer节点)都会受到该分布异常消息,受到该消息后,首先判断该分布异常消息中的签名是否包括该Peer节点自己的签名,若包括,则表明该Peer节点本身是认可的,则再判断包括的签名数量是否满足预设条件,预设条件可以根据实际需求设置,比如3f+1规则等,若满足预设条件,则将该异常分布消息中的结块交易分布异常的Peer节点信息及预定区块高度添加到共识模块,当共识模块执行到预定区块高度时,可以屏蔽分布异常的Peer节点信息对应的Peer节点提交的结块交易信息,实现恶意结块监控,减少因为增加结块消息而导致处理性能低下的问题。
若Peer节点接收到的分布异常消息中不包括该Peer节点自己的签名,则可以判断分布异常消息中包括的分布异常的Peer节点信息与自己统计分析获得的分布异常的Peer节点信息是否一致,如果一致,则可以对该分布异常消息进行签名后发送至消息队列,消息队列再进行广播,各Peer节点再进行判断,以此类推,直至该Peer节点接收到的分布异常消息包括自己的签名且签名数量满足预设条件,该Peer节点则记录该分布异常消息中的分布异常的Peer节点信息及预定区块高度,当该节点执行到预定区块高度时,屏蔽分布异常的Peer节点信息对应的Peer节点提交的结块交易消息。
示例性的,如图8所示,为本实施例提供的数据处理方法中异常监控的流程示意图。这里只以第一Peer节点Peer1为例,在实际应用中,所有的Peer节点均会做相同的操作,具体与第一Peer节点操作一致,在此不再一一赘述。
作为另一种可实施的方式,在上述实施例的基础上,可选地,在接收客户端发送的第一交易数据之后,该方法还包括:
步骤2061,对第一交易数据进行验证。
步骤2062,若验证通过,则对第一交易数据进行签名,获得第二交易数据。
相应的,将第一交易数据发送到消息队列,包括:
步骤2063,将第二交易数据发送到消息队列。
具体的,第一Peer节点接收到客户端发送的第一交易数据后,可以对第一交易数据进行签名验证,验证通过后,第一Peer节点可以再对第一交易数据增加自己的签名,获得第二交易数据,将第二交易数据发送至消息队列进行排序。
本申请实施例提供的数据处理方法,Peer节点直接参与共识过程,只利用消息队列本身整体排序的功能,不再需要单独的Orderer节点,每个Peer节点都具有判断结块提交区块的能力。在某个Peer节点因为MQ传输异常的情况下,仍然能够运行正常,消息传递过程中通过交易ID进行消息传递,不再完整传输整个消息,同时结合缓存和LRU((Leastrecently used,最近最少使用)算法,有效降低了传输过程中的消息量,提高了性能。
需要说明的是,本实施例中各可实施的方式可以单独实施,也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
本实施例提供的数据处理方法,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块写入账本,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。且结块的判断均依赖于结块交易消息,而非Peer节点自身的判断,保证了结块的可靠性。还增加了恶意结块监控机制,对于恶意提交结块交易消息的Peer节点可以进行有效的屏蔽,减少因增加结块交易消息而导致处理性能低下的问题。并且,消息传递过程中没有直接使用交易数据本身,而是使用交易ID和缓存结合的方式,可以有效提高消息传输效率,进一步提高结块的处理性能。
实施例三
本实施例提供一种数据处理装置,用于执行上述实施例的方法。
如图9所示,为本实施例提供的数据处理装置的结构示意图。该数据处理装置30包括第一接收模块31、发送模块32、第二接收模块33和处理模块34。
其中,第一接收模块,用于接收客户端发送的第一交易数据;发送模块,用于将第一交易数据发送到消息队列,以使消息队列对接收到的各Peer节点发送的交易数据进行排序并将排序结果广播给各Peer节点;第二接收模块,用于接收消息队列广播的排序结果;处理模块,用于根据排序结果进行相应的处理。
关于本实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
根据本实施例提供的数据处理装置,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块写入账本,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。
实施例四
本实施例对上述实施例提供的装置做进一步补充说明。
作为一种可实施的方式,在上述实施例的基础上,可选地,处理模块,具体用于:
若排序结果中的包括普通类型的交易数据,则将普通类型的交易数据进行缓存,并判断当前是否满足预设结块条件;若满足预设结块条件,则根据当前已缓存的交易数据生成结块交易消息发送至消息队列,以使消息队列将结块交易消息广播给各Peer节点,结块交易消息包括最新区块高度、交易ID列表及结块条件。
可选地,处理模块,具体用于:
若当前已缓存的交易数量满足预设数量条件,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,结块条件包括结块的交易数量。
可选地,处理模块,具体用于:
若当前已缓存的交易数量不满足预设数量条件,但当前时间满足预设时间条件,则基于当前已缓存的交易数据生成结块交易消息发送至消息队列,结块条件包括结块起始时间和生成结块交易消息的时间。
作为另一种可实施的方式,在上述实施例的基础上,可选地,处理模块,具体用于:
若排序结果中包括结块交易消息,则获取结块交易消息中的最新区块高度、交易ID列表和结块条件;根据交易ID列表,从缓存中获取对应的交易数据生成区块并写入账本。
可选地,处理模块,还用于:判断最新区块高度是否已处理;若未处理,则判断结块条件是否与交易ID列表匹配。
相应的,处理模块,具体用于:若结块条件与交易ID列表匹配,则根据交易ID列表,从缓存中获取对应的交易数据生成区块。
可选地,处理模块,具体用于:
判断缓存中是否能获取到交易ID列表对应的全部交易数据;若从缓存中只获取到交易ID列表对应的部分交易数据,则等待预设时间后再从缓存中获取交易ID列表对应的剩余交易数据;在获取到交易ID列表对应的全部交易数据之后,根据交易ID列表对应的全部交易数据生成区块;若在等待预设时间后仍不能从缓存中获取交易ID列表对应的剩余交易数据,则标记异常,不写入账本。
作为另一种可实施的方式,在上述实施例的基础上,可选地,处理模块,还用于:
获取当前之前预设时间段内的结块交易分布信息,结块交易分布信息包括Peer节点信息及各Peer节点每次的结块条件;根据结块交易分布信息判断各Peer节点是否存在结块交易分布异常;若存在,则将结块交易分布异常的Peer节点信息及预定区块高度打包为分布异常消息;对分布异常消息进行签名后发送至消息队列,以使消息队列将分布异常消息广播给各Peer节点。
可选地,第二接收模块,还用于接收消息队列广播的分布异常消息;
处理模块,还用于:若分布异常消息中包括自己的签名,则判断分布异常消息中包括的签名数量是否满足预设签名条件,若满足,则将分布异常消息中的分布异常的Peer节点信息及预定区块高度进行记录;当执行到预定区块高度时,屏蔽分布异常的Peer节点信息对应的Peer节点提交的结块交易消息;若分布异常消息中不包括自己的签名,则判断分布异常消息中包括的分布异常的Peer节点信息与自己判断获得的分布异常的Peer节点信息是否一致,若一致,则对分布异常消息进行签名后发送至消息队列,以使消息队列再次进行广播。
作为另一种可实施的方式,在上述实施例的基础上,可选地,处理模块,还用于对第一交易数据进行验证,若验证通过,则对第一交易数据进行签名,获得第二交易数据。
相应的,发送模块,具体用于:将第二交易数据发送到消息队列。
关于本实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
需要说明的是,本实施例中各可实施的方式可以单独实施,也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
根据本实施例的数据处理装置,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块写入账本,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。且结块的判断均依赖于结块交易消息,而非Peer节点自身的判断,保证了结块的可靠性。还增加了恶意结块监控机制,对于恶意提交结块交易消息的Peer节点可以进行有效的屏蔽,减少因增加结块交易消息而导致处理性能低下的问题。并且,消息传递过程中没有直接使用交易数据本身,而是使用交易ID和缓存结合的方式,可以有效提高消息传输效率,进一步提高结块的处理性能。
实施例五
本实施例提供一种区块链节点,用于执行上述实施例提供的方法。该区块链节点具体可以是区块链***中的任一Peer节点。
如图10所示,为本实施例提供的区块链节点的结构示意图。该区块链节点50包括:至少一个处理器51和存储器52;
存储器用于存储处理器可执行指令,以使至少一个处理器执行计算机可执行指令实现上述实施例提供的方法。
根据本实施例的区块链节点,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块写入账本,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。且结块的判断均依赖于结块交易消息,而非Peer节点自身的判断,保证了结块的可靠性。还增加了恶意结块监控机制,对于恶意提交结块交易消息的Peer节点可以进行有效的屏蔽,减少因增加结块交易消息而导致处理性能低下的问题。并且,消息传递过程中没有直接使用交易数据本身,而是使用交易ID和缓存结合的方式,可以有效提高消息传输效率,进一步提高结块的处理性能。
实施例六
本实施例提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,计算机执行指令被处理器执行时用于实现上述任一实施例提供的方法。
根据本实施例的计算机可读存储介质,通过Peer节点接收客户端发送的交易数据,将交易数据发送到消息队列,并根据消息队列广播的排序结果进行结块写入账本,使得所有接入消息队列的Peer节点参与共识,屏蔽到了Orderer节点中心化的风险,提高区块链***的可信度。且结块的判断均依赖于结块交易消息,而非Peer节点自身的判断,保证了结块的可靠性。还增加了恶意结块监控机制,对于恶意提交结块交易消息的Peer节点可以进行有效的屏蔽,减少因增加结块交易消息而导致处理性能低下的问题。并且,消息传递过程中没有直接使用交易数据本身,而是使用交易ID和缓存结合的方式,可以有效提高消息传输效率,进一步提高结块的处理性能。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。