具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
如前所述,在现有的联盟链中,交易的共识过程和业务校验过程是分开执行的,因此导致了一系列不协同的问题发生。比如,联盟链的共识主节点在共识备份节点对交易进行业务校验前发起了共识提议,如果共识备份节点在共识达成前未来得及进行业务校验,则可能导致业务逻辑不合法的交易被上传至联盟链中。再比如,共识备份节点在共识主节点发起共识提议前已经完成对交易的业务校验,如果这个交易在共识主节点上通过业务校验,但在共识备份节点上未通过,则共识主节点还是会发起该交易的共识提议,导致共识备份节点在共识阶段依然会对这个交易执行共识逻辑,并二次拒绝,造成不必要的资源浪费。
针对这一问题,本说明书旨在提供一种可以协调联盟链的共识过程和业务校验过程的技术方案。一方面,防止业务逻辑不合法的交易被上传至联盟链;另一方面,避免共识备份节点消耗不必要的资源对未通过自身业务校验的交易执行共识逻辑。
图1是本说明书实施例联盟链的业务校验方法的流程图。图1所示的方法可以由下文相对应的装置执行,包括:
步骤S102,联盟链的共识主节点对自身交易池中的交易进行业务校验,其中,联盟链中的各共识节点对客户端发起的交易进行账户合法性校验,并将通过账户合法性校验的交易同步至各自的交易池中。
具体地,联盟链的客户端会连接中的一个节点,并通过这个节点发起交易请求。之后,这个节点将交易请求转发给其他节点,以对交易请求中的交易进行同步。在同步过程中,各共识节点需要对交易请求中的交易进行账户合法性校验,比如对交易请求中的网络签名信息、账户信息等固定内容项进行校验。由于固定内容的校验不会呈现多样性的校验结果,因此一般情况下,客户端发起的交易请求中的交易如果通过某一节点的账户合法性校验,则表示这个交易最终也会同步至其他节点的交易池中。
在本说明书实施例的方法中,共识主节点只对共识主节点的交易池中的交易发起共识提议。这就意味着,共识备份节点能够从共识备份节点的交易池中,调取到待共识的交易的信息,从而保证共识过程能够正确执行。
应理解,这里所述的账户合法性校验不同于业务校验。业务校验顾名思义,就是对交易进行业务层面上的校验,比如:对交易的风险校验和/或数据格式校验等。
步骤S104,共识主节点对通过自身业务校验的交易发起共识提议,其中,共识提议包含至少一个通过共识主节点业务校验的交易,联盟链中至少两个共识节点具有不同的业务校验规则。
应理解,本步骤中,共识主节点只对自身业务层面上认可的交易发起共识提议。
其中,业务校验规则是机构的机密内容。一帮情况下,各共识节点之间不会进行共享。因此,不同的共识节点可能会对应有不同的业务校验规则。也就是说,同一交易即便通过共识主节点的业务校验,并不能表示也能够通过共识备份节点的业务校验。
步骤S106,联盟链的共识备份节点在共识过程中,基于自身的业务校验规则,对共识提议的至少一个交易进行业务校验,并对通过自身业务校验的交易执行共识逻辑。
为了避免共识主节点作恶的情况发生,共识备份节点也需要基于自身业务校验规则对共识提议中的交易进行校验。
其中,如果共识提议的目标交易未能通过共识备份节点的业务校验,则共识备份节点不执行针对该目标交易的共识逻辑,或者,直接将共识提议中的所有交易全部打回。
基于图1所示的业务校验方法可以知道:本说明书实施例的方案中,联盟链的共识主节点发起交易的共识提议后,共识备份节点在共识阶段基于自身的业务校验规则对该交易进行业务校验,并在交易通过业务校验后再进一步执行共识逻辑。一方面,可以确保共识备份节点在交易达成共识前完成业务校验,防止业务逻辑不合法的交易达成共识后被上传至联盟链中;另一方面,共识备份节点不需要再浪费资源对未通过自身业务校验的交易执行共识逻辑,从而有效减少联盟链的共识开销。
在上述基础之上,共识备份节点可以将交易池中未通过自身业务校验的交易直接移除,以避免在后续共识轮次中,花费不必要的开销,对之前未通过自身业务校验的交易再次进行业务校验。或者,共识备份节点也可以对自身交易池中未通过自身业务校验的交易进行标记,以便后续的共识阶段只对自身交易池中未标记的交易执行业务校验。
此外,现有的一部分联盟链的共识规则要求是共识提议中只要有交易未通过共识节点的业务校验,则该共识提议包含的所有交易在共识阶段需要被全部打回。针对这类联盟链,为了保证同一共识轮次中业务层面上合法的交易不受到非法交易的影响而导致无法上链,在共识提议被驳回后,共识主节点可以根据共识备份节点的共识提议反馈,重新发起共识提议。应理解,重新发起的共识提议不包含未通过共识备份节点的业务校验的交易,从而保证本次重新发起的共识提议能够将上次共识提议被打回的在业务层面上合法的交易上传至联盟链中。
进一步地,本说明书实施例的方法可以通过智能合约来控制共识备份节点执行业务校验。智能合约是一种计算机协议,当一个预先编好的条件被触发时,智能合约执行相应的合同条款。
在实际应用中,可以预先在联盟链中部署指定智能合约,指定智能合约用于指示共识备份节点在共识过程中的指定阶段,对共识提议的交易进行业务校验。其中,共识主节点可以将调用该指定智能合约的请求通过共识提议发送给共识备份节点,从而使共识备份节点按照智能合约,在共识过程中的指定阶段完成业务校验。
图2为创建智能合约和调用智能合约的示意图。其中,联盟链要创建一个智能合约需要经过编写智能合约、变成字节码、部署到联盟链等过程。智能合约创建后,会拥有一个特定的地址,共识备份节点基于这个地址即可进行调用。
应理解,在共识过程中的哪个阶段执行业务校验需要根据联盟链所采用的共识机制来进行灵活设置。目前主流的共识机制包括:工作量证明(POW,Proof of Work)、股权证明(POS,Proof of Stake)、委任权益证明(DPOS,Delegated Proof of Stake)、实用拜占庭容错(PBFT,Practical Byzantine Fault Tolerance)算法等。
下面PBFT算法的共识提议为例,对本说明书实施例的方法在共识过程中执行业务校验的实现方式进行示例介绍。
实现方式一:
在实现方式一中,指定智能合约要求共识备份节点在共识过程中的预准备pre-prepare阶段执行业务校验,业务校验方法对应的流程包括:
步骤S201,联盟链的Client(客户端)发起交易。
步骤S202,联盟链的每个replica节点(副本,也称为copy,构建分布式系统的节点,包含共识主节点和共识备份节点)针对Client发起的交易进行账户合法性校验,并将通过账户合法性校验的交易同步至各自的交易池中。
步骤S203,联盟链的共识主节点对通过自身业务校验的交易发起PBFT算法的共识提议。
其中,共识过程如图3所示(图3中的共识备份节点数量仅用于示例),包括:
pre-prepare阶段:
共识主节点收到来自Client的一个请求,并分配一个编号给这个请求,然后共识主节点会广播一条pre-prepare消息给共识备份节点,这个pre-prepare消息包含该请求的编号、所在的视图(view)和共识主节点的摘要(digest),同时还有调用指定智能合约的请求,这个请求指示智能合约的地址。
每一个共识备份节点在接收到pre-prepare消息后,确定同不同意共识主节点分配给该请求的这个编号n,即,确认是否接受这条pre-prepare消息。
各共识备份节点如果接受了这条pre-prepare消息,调用指定智能合约,按照指定智能合约的逻辑,基于自身的业务校验规则,对请求中的所有交易进行业务校验。若业务校验通过,则进入prepare阶段。若有交易未通过业务校验,则不执行针对该交易请求的共识逻辑,甚至直接打回对本次共识提议。
prepare阶段:
所有参与共识的共识备份节点中的每一个在接收到pre-prepare消息后,检查pre-prepare消息是否合法。如果pre-prepare消息合法,那么该请求在replica上的状态被确定为prepared,共识备份节点将该pre-prepare消息添加到本地Log中,并发送prepare消息给其他参与共识的共识备份节点。
commit阶段:
所有replica节点中的每一个在进入prepared状态后,发送commit消息给其他replica节点,并将自己发送的commit消息添加到本地Log中(代表自己的认可)。当一个replica节点发现有一个quorum(quorum是为了能够确保所有replica数据一致性要求和容错要求需要的一定数量replica的集合)同意编号分配时,它就会广播一条commit消息给其它所有节点。与此同时也会陆续收到来自其他节点的commit消息,如果每个节点收到了2f+1(f是联盟链中作恶节点的数量)条commit消息(包括自身的一条,这些来自不同节点的commit携带相同的编号n和view v),就说名该replica节点拥有了一个名为committedcertificate的证书,请求在这个replica节点上达到了committed状态。此时只通过这一个replica节点,就能断定该请求已经在一个quorum中到达了prepared状态,即同一个quorum的所有replica节点都同意了编号n的分配。当Client发起的请求到达commited状态后,说明已经达成全网共识。
实现方式二:
在实现方式二中,指定智能合约要求共识备份节点在共识过程中的预准备prepare阶段执行业务校验,业务校验方法对应的流程包括:
步骤S301,联盟链的Client发起交易。
步骤S302,联盟链的每个replica节点针对Client发起的交易进行账户合法性校验,并将通过账户合法性校验的交易同步至各自的交易池中。
步骤S303,联盟链的共识主节点对通过自身业务校验的交易发起基于拜占庭容错算法的共识提议。
其中,共识过程如图4所示(图4中的共识备份节点数量仅用于示例),包括:
pre-prepare阶段:
共识主节点收到来自Client的一个请求,并分配一个编号给这个请求,然后共识主节点会广播一条pre-prepare消息给共识备份节点,这个pre-prepare消息包含该请求的编号、所在的视图(view)和共识主节点的摘要(digest)。
每一个共识备份节点在接收到pre-prepare消息后,确定同不同意共识主节点分配给该交易请求的这个编号n,即,确认是否接受这条pre-prepare消息。各共识备份节点如果接受了这条pre-prepare消息,则进入prepare阶段。
prepare阶段:
所有参与共识的共识备份节点中的每一个在接收到pre-prepare消息后,调用预先在联盟链部署的指定智能合约,按照指定智能合约的逻辑,基于自身的业务校验规则,对共识提议的至少一个交易进行业务校验。
若有交易未通过业务校验,则不执行针对该交易的共识逻辑,甚至直接打回对本次共识提议。
若业务校验通过,再检查pre-prepare消息是否合法。如果pre-prepare消息合法,那么该请求在replica上的状态被确定为prepared,共识备份节点将该pre-prepare消息添加到本地Log中,并发送prepare消息给其他共识备份节点。
commit阶段:
所有replica节点中的每一个在进入prepared状态后,发送commit消息给其他replica节点,并将自己发送的commit消息添加到本地Log中。当一个replica节点发现有一个quorum同意编号分配时,它就会广播一条commit消息给其它所有节点。与此同时也会陆续收到来自其他节点的commit消息,如果每个节点收到了2f+1条commit消息,就说名该replica节点拥有了一个名为committed certificate的证书,请求在这个replica节点上达到了committed状态。此时只通过这一个replica节点,就能断定该请求已经在一个quorum中到达了prepared状态,即同一个quorum的所有replica节点都同意了编号n的分配。当Client发起的请求到达commited状态后,说明已经达成全网共识。
显然,通过上述实现方式一和实现方式二可以知道,在传统的PBFT算法的共识过程中,共识备份节点在pre-prepare阶段开始执行共识逻辑,即共识备份节点在pre-prepare阶段检查共识主节点发送的pre-prepare消息是否合法。因此,共识备份节点业务校验的步骤可以在检查pre-prepare消息之前执行,一旦交易未能通过共识备份节点的业务校验,则拒绝执行后续的共识逻辑,从而避免造成不必要的资源开销。
以上是对本说明书实施例的方法的介绍。应理解,在不脱离本文上述原理基础之上,还可以进行适当的变化,这些变化也应视为本说明书实施例的保护范围。
与上述方法相对应地,如图5所示,本说明书实施例还提供一种联盟链系统500,包括:多个共识节点;其中,
所述多个共识节点中的共识主节点510,对自身交易池中的交易进行业务校验,并对通过自身业务校验的交易发起共识提议,其中,各共识节点对客户端发起的交易进行账户合法性校验,并将通过账户合法性校验的交易同步至各自的交易池中,所述多个共识节点中,至少两个共识节点具有不同的业务校验规则;
所述多个共识节点中的共识备份节点520,基于自身的业务校验规则,对所述共识提议的至少一个交易进行业务校验,并对通过自身业务校验的交易执行共识逻辑。
基于图5所示的联盟链系统可以知道:本说明书实施例的方案中,联盟链的共识主节点发起交易的共识提议后,共识备份节点在共识阶段基于自身的业务校验规则对该交易进行业务校验,并在交易通过业务校验后再进一步执行共识逻辑。一方面,可以确保共识备份节点在交易达成共识前完成业务校验,防止业务逻辑不合法的交易达成共识后被上传至联盟链中;另一方面,共识备份节点不需要再浪费资源对未通过自身业务校验的交易执行共识逻辑,从而有效减少联盟链的共识开销。
可选地,所述共识提议携带有调用指定智能合约的请求,所述指定智能合约用于指示所述共识备份节点在共识过程中的指定阶段,对共识提议的交易进行业务校验。
应理解,在共识过程中的哪个阶段执行业务校验需要根据联盟链所采用的共识机制来进行灵活设置。目前主流的共识机制包括:工作量证明(POW,Proof of Work)、股权证明(POS,Proof of Stake)、委任权益证明(DPOS,Delegated Proof of Stake)、实用拜占庭容错(PBFT,Practical Byzantine Fault Tolerance)算法等。
以PBFT算法的共识提议为例,则所述指定智能合约中的指定阶段可以是共识过程的pre-prepare阶段或准备prepare阶段。
其中,若所述指定阶段为prepare阶段,则所述共识备份节点在所述共识提议的至少一个交易通过自身业务校验后,再执行prepare阶段需要对pre-prepare消息进行签名校验的流程;其中,所述pre-prepare消息是所述共识主节点基于所述拜占庭容错算法,需要在pre-prepare阶段向联盟链的共识备份节点发送的消息。
此外,在上述基础之上,共识备份节点520可以将交易池中未通过自身业务校验的交易直接移除,以避免在后续共识轮次中,花费不必要的开销,对之前未通过自身业务校验的交易再次进行业务校验。或者,共识备份节点520也可以对自身交易池中未通过自身业务校验的交易进行标记,以便后续的共识阶段只对自身交易池中未标记的交易执行业务校验。
此外,现有的一部分联盟链的共识规则要求是共识提议中只要有交易未通过共识节点的业务校验,则该共识提议包含的所有交易在共识阶段需要被全部打回。针对这类联盟链,为了保证同一共识轮次中业务层面上合法的交易不受到非法交易的影响而导致无法上链,在共识提议被驳回后,共识主节点510可以根据共识备份节点520的共识提议反馈,重新发起共识提议。应理解,重新发起的共识提议不包含未通过共识备份节点的业务校验的交易,从而保证本次重新发起的共识提议能够将上次共识提议被打回的在业务层面上合法的交易上传至联盟链中。
显然,本说明书实施例的联盟链系统可以作为上述图1所示的业务校验方法的执行主体,因此能够实现该业务校验方法在图1至图4所实现的功能。由于原理相同,本文不再赘述。
本领域技术人员应明白,本说明书的实施例可提供为方法、系统或计算机程序产品。因此,本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
以上仅为本说明书的实施例而已,并不用于限制本说明书。对于本领域技术人员来说,本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应属于本文件的保护范围之内。