一种区块链业务受理及业务共识方法及装置
技术领域
本申请涉及信息技术领域,尤其涉及一种区块链业务受理及业务共识方法及装置。
背景技术
随着信息技术的发展,区块链技术作为新兴技术,由于具有的开放性、不可篡改性、去中心化等优点,已成为人们重点关注的技术。
在现有区块链技术中,区块链网络中的每个共识节点,均可受理客户端发送的业务请求。以一个共识节点为例进行说明,当共识节点接收到业务请求后,可先根据该业务请求,确定对应的业务数据。之后共识节点可将业务数据广播给其他共识节点。当共识节点接收到其他共识节点发送的预处理块后,还可对该预处理快进行共识校验,并可在校验通过后存储该预处理块。
其中,共识节点在受理业务请求后,通常将业务请求对应的业务数据存储在该共识节点的缓存中。在后续对业务数据进行共识校验通过后,从缓存中释放该业务数据。类似的,对于其他共识节点发送的业务数据,也可同样存储在缓存中,并在通过共识校验后释放。
对于共识节点来说,未存储在区块链中的数据通常均暂存在共识节点的缓存中,导致进行共识校验时,可校验的业务数据的数量受该共识节点缓存容量的限制,使得共识校验的效率受限。并且,当共识节点的缓存空间不足时,共识节点也难以对接收到的业务请求进行处理。
发明内容
本申请实施例提供一种区块链业务受理及业务共识方法,用于解决在现有区块链技术中业务执行效率低的问题。
本申请实施例提供一种区块链业务受理及业务共识装置,用于解决在现有区块链技术中业务执行效率低的问题。
本申请实施例采用下述技术方案:
一种区块链业务受理方法,共识节点中包括第一应用、第二应用以及数据库,包括:
所述第一应用接收客户端发送的业务请求,并根据该业务请求确定对应的待发送的业务数据;
所述第一应用将所述待发送的业务数据存储在所述数据库中;
当满足预设条件时,所述第二应用或者所述第一应用,从所述数据库中捞取待发送的业务数据发送至其他共识节点存储。
一种区块链业务共识方法,第一共识节点中包括第一应用、第二应用以及第一数据库,包括:
所述第一应用接收共识数据,并存储在所述第一数据库中;
所述第二应用从所述第一数据库中捞取所述共识数据,进行共识校验;
所述第二应用将校验结果添加到所述共识数据中并存储至所述第一数据库,并将所述校验结果发送至其他共识节点继续进行共识校验。
一种区块链业务受理装置,共识节点中包括所述装置,第二应用以及数据库,所述装置包括:
接收模块,接收客户端发送的业务请求,并根据该业务请求确定对应的待发送的业务数据;
存储模块,将所述待发送的业务数据存储在所述数据库中;
当满足预设条件时,所述第二应用或者发送模块,从所述数据库中捞取待发送的业务数据发送至其他共识节点存储。
一种区块链业务共识装置,第一共识节点中包括接收模块、处理发送模块以及第一数据库,所述装置包括:
所述接收模块,接收共识数据,并存储在所述第一数据库中;
所述处理发送模块,从所述第一数据库中捞取所述共识数据,进行共识校验;
所述处理发送模块,将校验结果添加到所述共识数据中并存储至所述第一数据库,并将所述校验结果发送至其他共识节点继续进行共识校验。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
共识节点中存在第一应用、第二应用以及数据库。该数据库用于存储由第一应用以及第二应用处理后的业务数据,以便减少共识节点的缓存压力。可见,通过本申请实施例提供的方法,由于共识节点只要确定业务请求对应的业务数据,便可将该业务数据存储在数据库中,等待发送给其他共识节点,所以共识节点的缓存的占用率较低。使得共识节点在单位时间内可处理的业务的数量增加,从而提高了共识节点进行共识校验以及对业务请求进行处理的效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的一种区块链业务受理过程;
图2为本申请实施例提供的一种区块链业务共识过程;
图3为本申请实施例提供的一种区块链业务受理装置的结构示意图;
图4为本申请实施例提供的一种区块链业务共识装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为本申请实施例提供的一种区块链共识过程,其中,共识节点中包括第一应用、第二应用以及数据库,具体可包括以下步骤:
S101:所述第一应用接收客户端发送的业务请求,并根据业务请求确定对应的待发送的业务数据。
在本申请实施例中,对于区块链网络中的各共识节点,共识节点中可以包含一个或者多个区块链应用以及数据库。其中,区块链应用可受理业务请求并对预处理块进行共识校验,数据库用于存储区块链应用确定的业务数据(如,进行共识校验过程中产生的数据、受理业务请求后产生的数据等等)。
进一步地,用户通常需要通过客户端发送指令或者请求。后续,共识节点可接收客户端发送的业务请求,并根据业务请求执行后续的步骤。
其中,共识节点可接收多个客户端发送的业务请求,并根据各业务请求进行业务处理。该共识节点可以是终端,例如,手机、平板电脑、个人电脑等设备。该共识节点也可以是服务器,并且该服务器可以是单独的一台设备,也可以是由多台设备组成的系统,例如,分布式服务器。本申请对共识节点具体为何种设备不做具体限定。
具体的,在共识节点接收业务请求时,可以是共识节点中安装的第一应用接收业务请求。并且在后续步骤中,由第一应用根据业务请求确定对应的业务逻辑,并分配线程执行业务。当然,在共识节点中安装的应用程序还可以有多个(如,第二应用),则各应用程序可分别接收不同客户端发送的业务请求,并分别进行后续操作。为方便描述,在本申请实施例中,仅以共识节点中包含第一应用以及第二应用为例进行说明,但并不限制共识节点中存在更多的应用。
进一步地,共识节点也可以由多台设备组成的系统,并且每台设备对应安装区块链应用,则各设备可通过安装的区块链应用分别接收不同客户端发送的业务请求,并独立的进行后续操作。
另外,无论共识节点中安装多个应用程序还是由多个设备组成,该共识节点在区块链网络中可视为是一个受理业务请求并可发起共识的节点。具体的共识节点如何构成,可由根据需要进行配置。例如,当共识节点的运行压力较大,经常有业务请求排队等待处理时,可为共识节点配置更多的应用或者配置更多的设备。
更进一步地,在本申请实施例中,第一应用在对接收的业务请求进行业务处理后,可将业务处理结果作为业务数据。并且,由于该业务数据尚未发送至其他共识节点,所以第一应用还可以确定该业务数据的状态为待发送状态。并将该业务数据及其对应的待发送状态存储在数据库中。
或者,第一应用可以在确定业务数据之后,为该业务数据添加待发送标识。再将添加了待发送标识的业务数据,作为待发送的业务数据存储在数据库中。则第二应用可以根据待发送标识确定该业务数据为待发送的业务数据。
本申请并不限定共识节点确定业务数据的状态的方式,只要共识节点中的各应用或者各设备,在访问数据库时可以确定存储的业务数据的状态即可。
例如,若用户要进行交易业务,用户发送的业务请求中可携带有交易双方的身份信息、交易金额、支出方的账号信息等数据。共识节点的第一应用可以根据业务请求中携带的数据,确定并创建对应的交易业务。第一应用在确定业务数据之后,为该业务数据添加待发送的标识。
其中,待发送标识也可作为业务数据中的一种业务属性被添加在业务数据中,例如,表1所示的业务数据的结构示意。
表1
在表1所示的业务数据的结构示意中的状态标识,可以是由共识节点的第一应用添加在业务数据中的。通过状态标识,共识节点中的任一应用可以确定该业务数据当前的状态为待发送状态。则下一步在对业务数据进行操作时,根据该状态标识可确定需要将该业务数据发送至其他共识节点。
当然,在本申请实施例中业务数据具体包括哪些内容,以及业务属性中具体包括哪些属性本申请并不做具体限定。
S102:所述第一应用将所述待发送的业务数据存储在所述数据库中。
在本申请实施例中,步骤S101中确定的待发送的业务数据过程依赖于共识节点的缓存,所以该业务数据也存储在缓存中。于是,第一应用还可将该业务数据转存至该在共识节点的数据库中,以释放缓存空间用于执行其他业务。
具体的,数据库可以是共识节点用于存储数据的存储设备,并且可以是采用非易失性存储器的存储设备。当然,数据库与共识节点可以位于同一台设备内(如,数据库可以位于个人电脑的硬盘中),也可以位于不同的设备内(如,外接移动硬盘),本申请对此并不做具体限定。
另外,当共识节点中安装有多个区块链应用时,各应用可分别接收不同客户端发送的业务请求。并将各自分别确定的业务数据存储在数据库中。则数据库可视为是各应用共用的数据库,各应用均可具有访问数据库的权限。也就是说,第二应用也可确定待发送的业务数据并存储在数据库中。
进一步地,由于在步骤S101中所述的,共识节点可以是由多台设备组成的系统,所以当共识节点为多台设备组成的系统时,共识节点的各设备均可访问数据库,该数据库在共识节点内可视为是各设备共享的存储设备。
于是,共识节点的第一应用通过将待发送的业务数据存储在数据库中,释放业务数据占用的缓存空间,用于执行其他业务。使得在不增加共识节点的硬件配置的情况下,该共识节点可以受理更多的业务请求。
S103:当满足预设条件时,所述第二应用或者所述第一应用,从所述数据库中捞取待发送的业务数据发送至其他共识节点存储。
在本申请实施例中,共识节点的第一应用在将待发送的业务数据存储在数据库中后,共识节点的第一应用可继续接收其他客户端发送的业务请求。并执行如步骤S101以及步骤S102相同的操作(同理共识节点的第二应用也可以同步执行步骤S101以及步骤S102相同的操作)。于是,共识节点对应的数据库中可存储若干待发送的业务数据。为了使其他共识节点正常进行共识校验,该共识节点的数据库中存储的业务数据还需要发送至其他共识节点中进行存储。
于是,在本申请实施例中,当满足预先条件时,还可由共识节点的第一或者第二应用从数据库中,捞取待发送的业务数据发送至其他共识节点存储,以便其他共识节点后续进行共识校验。并且,针对每个待发送的业务数据,当待发送的业务数据被发送之后,还可更新待发送的业务数据为已发送的业务数据。
具体的,共识节点中的第一应用或者第二应用中的至少一个,可以根据该共识节点当前的状态,判断是否已经满足预设的条件。若是,则第一应用和/或第二应用捞取各待发送的业务数据并发送,若否,则不捞取。
其中,当共识节点的数据库中存储的待发送的业务数据的数量达到预设阈值时,确定共识节点当前的状态满足预设的条件。或者,根据共识节点的发送周期,当指定时刻到达时确定满足预设的条件,即,周期性的捞取数据中的各待发送的业务数据,等等。
当然,预设的条件也可根据实际需要进行设置。如,预设的条件也可以随着时间因素以及业务量的变化而变化,当时间为夜间时(如,24点至4点)增加捞取业务数据的间隔时间,当业务量增加时减少捞取的业务数据的时间间隔等等,本申请对此不做具体限定。
另外,当第一应用或者第二应用在捞取各待发送的业务数据时,可以将共识节点对应的数据库中的各待发送的业务数据全部捞取并发送。也可以捞取指定数量的待发送的业务数据,本申请不做具体限定。并且,上述条件可以择一使用,或者任意组合使用。
进一步地,第一应用或者第二应用在从数据库中捞取待发送的业务数据时,可以根据各待发送的业务数据的生成时间先后顺序,捞取各待发送的业务数据。并将捞取的各待发送的业务数据按照捞取的先后顺序发送至其他共识节点。具体的,共识节点可以逐一捞取并发送各待发送的业务数据,也可将捞取各待发送的业务数据并打包之后,再一并发送至其他共识节点。
更进一步地,第一应用或者第二应用还可将发送后的各待发送的业务数据,更新为各已发送的业务数据。
例如,第一应用从数据库中捞取业务数据F并发送后,可以将数据库中业务数据F对应的状态更新为已发送状态。或者,将业务数据F的业务属性中的状态标识,更新为已发送的标识。也就是说,第一应用可以在调用业务数据F时,便更新业务数据F的状态标识。
当然,由于网络延时或者设备故障等问题,所以可能出现业务数据发送失败的情况。于是,在本申请实施例中,第一应用或者第二应用也可以在接收到其他共识节点返回的针对发送的业务数据的响应信息时,再根据响应信息更新该业务数据的状态标识。具体采用何种方法本申请对此不做具体限定。
基于图1所示的区块链业务受理方法,可见共识节点中可包括第一应用、第二应用以及数据库。该数据库用于存储第一应用以及第二应用进行业务处理后的业务数据,以便减少共识节点的缓存压力。共识节点即使在等待共识阶段也可以持续接收业务请求以及受理业务,而不会因为缓存空间不足而造成业务等待。同时,由于业务数据均存储在数据库中,所以共识节点可以根据需要扩展安装的应用数量。使得共识节点可以同时接收处理更多的业务请求,提高共识节点的工作效率。并且,当满足预设条件时,可由共识节点中第一或者第二应用,捞取数据库中存储的待发送的业务数据,并发送至其他共识节点存储。可见,通过本申请提供的方法,共识节点的运行效率不再受限于缓存大小。并且,由于共识节点中各应用都可以受理业务请求、发送业务数据,使得共识节点可以通过部分应用发送待发送的业务数据,同时另一部分应用受理业务请求,提高共识节点进行共识校验以及对业务请求进行处理的效率。
另外,在本申请实施例中,该第一或第二应用在发送待发送的业务数据时,可以先将该业务数据的状态更新为已发送状态,使得其他共识节点接收并存储的业务数据处于已发送状态。以使得其他共识节点在根据业务数据进行共识校验时,不会遗漏该第一或第二应用发送的业务数据。
进一步地,在本申请实施例中,第一应用在接收到其他共识节点发送的业务数据之后,也可根据业务数据的哈希值以及业务数据的具体内容,对待发送的业务数据进行校验。并且在校验通过后,再将业务数据作为存储在数据库。
更进一步的,在本申请步骤S101中,与现有技术相同,共识节点在确定业务请求时,可对业务请求中携带的进行业务处理所需的数据进行校验。并且,在校验通过之后,继续进行后续创建业务、进行业务处理等操作。具体的,校验过程以及实施细节可与现有技术中一致,本申请不再赘述。
另外,在本申请实施例中,共识节点在确定待发送的业务数据之后,便可向客户端返回对应于业务请求的响应信息,以使得客户端确定共识节点已经受理了业务请求。需要说明的是,当共识节点根据业务请求确定了业务数据时,便可视为共识节点受理了业务请求。
需要说明的是,本申请实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤S101和步骤S102的执行主体可以为设备1,步骤S103的执行主体可以为设备2;又比如,步骤S101的执行主体可以为设备1,步骤S102和步骤S103的执行主体可以为设备2;等等。
基于图1所示区块链业务受理方法,本申请实施例还对应提供一种区块链业务共识的方法,如图2所示。
图2为本申请实施例提供的一种区块链业务共识的过程,其中,第一共识节点中包括第一应用、第二应用以及第一数据库,具体包括以下步骤:
S201:所述第一应用接收共识数据,并存储在所述第一数据库中。
在本申请实施例中,与图1所示的区块链业务受理过程中所述的共识节点类似,第一共识节点包括第一应用、第二应用以及第一数据库。并且,第一共识节点中也可包含更多的应用,本申请对此不做限定。但为方便后续描述,在本申请实施例中以第一应用、第二应用为例进行说明。
通常,区块链网络中的各共识节点可以根据区块链的共识机制,确定发起共识的共识节点。于是,第一共识节点的第一应用可接收共识数据,并将共识数据存储在第一数据库中。
另外,在某些共识算法中,共识节点可根据其他共识节点的校验结果,确定是否存储共识数据。例如,在一些共识算法中,对每个共识节点来说,该共识节点需要判断全网的共识节点中是否有超过50%的共识节点校验结果为通过,若是,则该共识节点存储预处理块,若否,则不存储。
于是,校验结果也可以视为是一种共识数据,则本申请中共识数据可以包括:需要进行共识校验的数据(通常为预处理快)以及对应的校验结果。
当然,无论第一应用接收到何种形式的共识数据,第一应用均可将共识数据存储在第一数据库中。
S202:所述第二应用从所述第一数据库中捞取所述共识数据,进行共识校验。
在本申请实施例中,第二应用可从第一数据库中,捞取共识数据并对共识数据进行校验,以进行后续操作。
具体的,第二应用可以从第一数据库中捞取共识数据(具体可以是预处理块)以及第一数据库中的已发送状态的业务数据,根据已发送状态的业务数据,对共识数据进行共识校验,并确定校验结果。
S203:所述第二应用将校验结果添加到所述共识数据中并存储至所述第一数据库,并将所述校验结果发送至其他共识节点继续进行共识校验。
在本申请实施例中,当第二应用确定了校验结果之后,便可将校验结果存储在第一数据库中,并发送至其他共识节点继续进行共识校验。其中,第二应用存储校及发送校验数据的先后顺序本申请并不限定。
另外,在本申请实施例步骤S201~步骤S203中,区块链的共识机制可以是实用拜占庭容错算法(Practical Byzantine Fault Tolerance,PBFT),则区块链网络中的各共识节点可以根据公式:View ID/M,确定各共识节点中的主节点,并且由主节点发起共识。针对每个共识节点,共识节点可先确定共识节点当前所处的周期(即,View),View ID表示共识节点确定的当期周期的标识。通常周期的标识为0至M-1之间的数字,M表示在区块链网络中的共识节点的总个数。
具体的,以第二共识节点为主节点并发起共识,第一共识节点为从节点进行共识校验为例进行说明。其中,第二共识节点中包括第三应用、第四应用以及第二数据库。第三应用根据第二数据库中已发送状态的业务数据创建预处理块,并将预处理块存储在第二数据库中。第四应用从第二数据库中捞取预处理块,并发送至除第二共识节点以外的各共识节点。
首先,第二共识节点的第三应用通过当前所处的View ID,可确定该第二共识节点为主节点。则第三应用可根据预先设置的共识条件,从第二数据库中捞取需要进行共识的各已发送的业务数据。其中,预设的共识条件可以是根据需求设置的,本申请对此不做具体限定。例如,按照时间顺序选择进行共识的业务数据,或者按照预处理块的容量,选择满足容量的各已发送的业务数据,等等。
其次,第三应用可根据捞取的各已发送的业务数据,创建对应的预处理块。如,确定预处理块中各已发送的业务数据的排列顺序,通过梅克尔数(Merkle trees)确定预处理块的头哈希值,等等。具体的,在本申请实施例中,预处理块的创建过程可以采用与现有技术相同的方法,本申请对此不做具体限定。
再次,第三应用可以根据PBFT的三阶段协议中的第一阶段,采用与现有技术相同的方式,确定预处理块对应的预准备(Per-Perpared)信息,其中,Per-Perpared信息的格式可为<Per-Perpared,v,n,d>,其中v表示当前View ID的数字,n表示预处理块的标识,d为预处理块的摘要。第三应用可对Per-Perpared信息进行签名后,将Per-Perpared信息以及预处理块存储在第二数据库中。
从次,第四应用可从数据库中捞取Per-Perpared信息以及预处理块,并发送至除第二共识节点以外的各共识节点。以使得其他共识节点对Per-Perpared信息进项校验。则如在步骤S201中所述的,第一应用可接收Per-Perpared信息以及预处理块作为共识数据,并存储在第一数据库中。
再后,如在步骤S202中所述的,第二应用可以从第一数据库中捞取共识数据(如,第二应用可以捞取Per-Perpared信息以及预处理块),并进行共识校验。具体的,第二应用可以对Per-Perpared信息的签名进行校验,确定Per-Perpared信息是由第二共识节点发送的。还根据预处理块中的业务数据,对Per-Perpared信息的摘要进行校验,确定预处理块以及Per-Perpared信息中的摘要对应。同时也可对Per-Perpared信息中的n进行判断确定是否符合预设的水位值(water mark),Per-Perpared信息中的v是否与第一共识节点当前所处的v一致。
由于在PBFT中确定Per-Perpared信息校验通过的共识节点,将自动执行下一阶段(即,第二阶段),所以当第二应用对Per-Perpared信息校验通过后可以将Per-Perpared信息、预处理块以及接收到的响应信息,存储在第一数据库中,并创建准备信息(Perpared信息)作为校验结果。Perpared信息的格式可为<Perpared,v,n,d,i>,其中i为创建Perpared信息的共识节点的标识。于是,第二应用还可将Perpared信息也存储在第一数据库中。
然后,第二应用可将Perpared信息发送至其他共识节点继续进行共识校验。并且,其他通过对Per-Perpared信息校验的共识节点也可将自身创建的Perpared信息签名后进行广播。于是,在区块链网络中的各共识节点,均可接收到通过对Per-Perpared信息校验的共识节点发送的Perpared信息,并且,针对每个共识节点,该共识节点可将接收到的其他共识节点发送的Perpared信息存储在自身的数据库中。
于是,在本申请实施例中,第一共识节点的第一应用可再次接收其他共识节点发送的校验结果(即,其他共识节点发送的Perpared信息),并存储在第一数据库中。第二应用可对第一数据库中存储的各Perpared信息的v、n、签名以及摘要进行校验。当第二应用判断第一数据库中存储的通过校验的各Perpared信息的数量大于等于预设的数量时,自动执行下一阶段(即,第三阶段)。其中,预设的数量与现有技术相同,为共识节点通过PBFT计算确定的,本申请不再赘述。
之后,在三阶段协议的第三阶段,当第二应用确定进行第三阶段时,可创建确认信息(Commit信息),并向其他共识节点发送Commit信息。同理,第二共识节点的第三或者第四应用,在确定进行第三阶段时,也可发送Commit信息。第一应用可接收其他共识节点发送的Commit信息并存储在第一数据库中。其中,Commit信息格式可为<Commit,v,n,D,i>,其中D为共识节点创建的预处理块的摘要。
最后,第二应用可对第一数据库中存储的其他共识节点发送的Commit信息的v、n、签名以及摘要进行校验,当确定通过校验的Commit信息大于等于预设的数量时,确定预处理块通过共识校验。
其中,针对区块链网络中的每个共识节点,该共识节点在三阶段协议的每个阶段中,在接收到其他共识节点的信息、创建信息等进行共识校验时产生的数据,均可存储在该共识节点对应的数据库中。
当然,需要说明的是本申请实施例中,上述由第二应用执行的步骤均可以由第一应用执行,反之亦然。同理,由该第三应用执行的步骤也均可由第四应用执行,反之亦然。
另外,针对每个共识节点,由于在三阶段协议执行过程中,各共识节点都需要发送和接收其他共识节点的信息,而信息在通过网络传输时,可能出现网络延时,所以在三阶段协议的每个阶段,各共识节点都可等待一段时间以接收信息。于是,在执行三阶段协议过程中,共识节点可将创建的以及接收的信息先存储在数据库中。并在每个阶段的等待时间结束时,再根据数据库中存储的信息,确定是否进行下一阶段。
进一步地,在本申请实施例中,在三阶段协议的第一阶段(也就是Per-Perpared的阶段),发起共识的第二共识节点(即,主节点)可将预处理块,以及预处理块中各业务数据的哈希值一并发送至出第二共识节点的各共识节点,而接收到Per-Perpared信息的各共识节点,可以根据各业务数据的哈希值,创建一个预处理块,并与主节点发送的预处理块进行对比校验。
更进一步地,在本申请实施例中,针对每个共识节点,该共识节点在进行共识校验时,与现有技术一致各共识节点还可以根据共识条件,以及共识节点进行校验,即,判断是否主节点发送各业务数据是可进行共识校验的业务数据,若是,则继续后续共识校验,若否,则停止共识校验。
基于图2所示的区块链业务共识方法,第一共识节点中包括第一应用、第二应用以及第一数据库,在进行共识时,第一应用接收共识数据,并存储在第一数据库中,第二应用从第一数据库中捞取共识数据,进行共识校验,第二应用将校验结果添加到共识数据中并存储至第一数据库,并将校验结果发送至其他共识节点继续进行共识校验。其中,发起共识的第二共识节点的第三应用根据第二数据库中存储的已发送的业务数据,创建预处理块作为共识数据存储在第二数据中,第四应用从第二数据库中捞取共识数据并发送至出第二共识节点以外的各共识节点。可见,由于在本申请实施例中,共识节点可以采用PBFT的三阶段协议进行共识,并且将每一阶段产生的数据存储在数据库中,减少共识校验时对缓存占用率,提高缓存利用率。从而提高了共识节点进行共识校验以及对业务请求进行处理的效率。
需要说明的是,本申请实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤S201和步骤S202的执行主体可以为设备1,步骤S203的执行主体可以为设备2;又比如,步骤S201的执行主体可以为设备1,步骤S202和步骤S203的执行主体可以为设备2;等等。
基于图1所示区块链业务受理方法,本申请实施例还对应提供一种区块链业务受理装置,如图3所示。
图3为本申请实施例提供的一种区块链业务受理装置的结构示意图,共识节点中包括所述装置,第二应用以及数据库,所述装置包括:
接收模块301,接收客户端发送的业务请求,并根据该业务请求确定对应的待发送的业务数据;
存储模块302,将所述待发送的业务数据存储在所述数据库中;
当满足预设条件时,所述第二应用或者发送模块303,从所述数据库中捞取待发送的业务数据发送至其他共识节点存储。
所述存储模块302,确定所述待发送的业务数据的状态为待发送状态,将所述业务数据及其对应的待发送状态存储在所述存储模块中。
当指定时刻到达时,确定满足预设的条件。
所述发送模块303,从所述数据库中捞取指定数量的待发送的业务数据。
所述装置还包括:
更新模块304,将所述数据库中已发送的业务数据的状态更新为已发送状态。
具体的,该区块链业务受理装置可位于共识节点中,该共识节点可以是终端。如,手机、平板电脑、个人电脑等设备。或者,该共识节点也可以是服务器。如,单独一台服务器,或者由多台服务器组成的系统。
基于图2所示区块链业务共识方法,本申请实施例还对应提供一种区块链业务共识装置,如图4所示。
图4为本申请实施例提供的一种区块链业务共识装置的结构示意图,第一共识节点中包括第一应用、所述装置以及第一数据库,所述装置包括:
接收模块401,接收共识数据,并存储在所述第一数据库中;
校验模块402,从所述第一数据库中捞取所述共识数据,进行共识校验;
存储发送模块403,将校验结果添加到所述共识数据中并存储至所述第一数据库,并将所述校验结果发送至其他共识节点继续进行共识校验。
所述接收模块401,接收其他共识节点发送的共识数据,或者,接收其他共识节点发送的校验结果,作为共识数据。
所述校验模块402,从所述第一数据库中捞取所述共识数据以及所述第一数据库中已发送状态的业务数据,根据所述已发送状态的业务数据对所述共识数据进行共识校验,并确定校验结果。
第二共识节点中包括第三应用、第四应用以及第二数据库,所述接收模块401接收共识数据之前,所述第三应用根据所述第二数据库中已发送状态的业务数据,确定共识数据,并存储在所述第二数据库中,所述第四应用从所述第二数据库中捞取所述共识数据,并发送至除所述第二共识节点以外的各共识节点。
所述共识校验采用拜占庭容错算法PBFT。
具体的,如图4所示的一种区块链业务受理装置可位于共识节点中,该共识节点可以是终端。如,手机、平板电脑、个人电脑等设备。或者,该共识节点也可以是服务器。如,单独一台服务器,或者由多台服务器组成的系统。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。