一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

区块链系统中的交易处理方法、装置及区块链系统与流程

2023-02-02 01:26:11 来源:中国专利 TAG:


1.本说明书实施例属于区块链技术领域,尤其涉及一种区块链系统中的交易处理方法、装置及区块链系统。


背景技术:

2.区块链(blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性,区块链也受到人们越来越多的重视和应用。在区块链系统中,一般通过全节点作为参与共识的最小设施,全节点需要包括全量数据,以支持共识功能。


技术实现要素:

3.本发明的目的在于提供一种区块链系统中的交易处理方法、装置及区块链系统,能将区块链系统中的共识节点分为fvp类型共识节点,以及lvp类型共识节点,既可以降低区块链系统的存储成本,又可以保证网络活性。
4.本说明书第一方面提供一种区块链系统中的交易处理方法,所述区块链系统中的共识节点包括全共识节点fvp类型共识节点和轻共识节点lvp类型共识节点,所述fvp类型共识节点存储有状态数据,所述状态数据中包括多个状态,所述lvp类型共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述方法应用于所述区块链系统中的共识节点,包括:获取第一交易,所述第一交易用于新增目标节点,并且包括所述目标节点的类型;获取所述区块链系统的节点信息,所述节点信息包括所述区块链系统中各个共识节点各自的类型;在基于所述节点信息确定fvp数目在所述区块链系统未来新增所述目标节点后的实际值满足预设的fvp数目最小要求时,同意所述目标节点加入;所述fvp数目为所述区块链系统中fvp类型共识节点的数目。
5.本说明书第二方面提供一种区块链系统中的交易处理方法,所述区块链系统中的共识节点包括全共识节点fvp类型共识节点和轻共识节点lvp类型共识节点,所述fvp类型共识节点存储有状态数据,所述状态数据中包括多个状态,所述lvp类型共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述方法应用于所述区块链系统中的共识节点,包括:获取第一交易,所述第一交易用于删除目标节点;获取所述区块链系统的节点信息,所述节点信息包括所述区块链系统中各个共识节点各自的类型;在基于所述节点信息确定fvp数目的实际值满足预设的fvp数目最小要求时,同意所述目标节点退出;所述fvp数目为所述区块链系统中fvp类型共识节点的数目。
6.本说明书第三方面提供一种区块链系统中的交易处理装置,所述区块链系统中的共识节点包括全共识节点fvp类型共识节点和轻共识节点lvp类型共识节点,所述fvp类型共识节点存储有状态数据,所述状态数据中包括多个状态,所述lvp类型共识节点存储有验
证数据,所述验证数据与所述多个状态对应,所述装置应用于所述区块链系统中的共识节点,包括:交易获取单元,被配置成获取第一交易,所述第一交易用于新增目标节点,并且包括所述目标节点的类型;节点信息获取单元,被配置成获取所述区块链系统的节点信息,所述节点信息包括所述区块链系统中各个共识节点各自的类型;处理单元,被配置成在基于所述节点信息确定fvp数目在所述区块链系统未来新增所述目标节点后的实际值满足预设的fvp数目最小要求时,同意所述目标节点加入;所述fvp数目为所述区块链系统中fvp类型共识节点的数目。
7.本说明书第四方面提供一种区块链系统中的交易处理装置,所述区块链系统中的共识节点包括全共识节点fvp类型共识节点和轻共识节点lvp类型共识节点,所述fvp类型共识节点存储有状态数据,所述状态数据中包括多个状态,所述lvp类型共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述装置应用于所述区块链系统中的共识节点,包括:交易获取单元,被配置成获取第一交易,所述第一交易用于删除目标节点;节点信息获取单元,被配置成获取所述区块链系统的节点信息,所述节点信息包括所述区块链系统中各个共识节点各自的类型;处理单元,被配置成在基于所述节点信息确定fvp数目的实际值满足预设的fvp数目最小要求时,同意所述目标节点退出;所述fvp数目为所述区块链系统中fvp类型共识节点的数目。
8.本说明书第五方面提供一种区块链系统,所述区块链系统中的共识节点包括全共识节点fvp类型共识节点和轻共识节点lvp类型共识节点,所述fvp类型共识节点存储有状态数据,所述状态数据中包括多个状态,所述lvp类型共识节点存储有验证数据,所述验证数据与所述多个状态对应;所述区块链系统中的共识节点用于执行如第一方面和第二方面中任一实现方式描述的方法。
9.本说明书第六方面提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行如第一方面和第二方面中任一实现方式描述的方法。
10.本说明书第七方面提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现如第一方面和第二方面中任一实现方式描述的方法。
11.本说明书第八方面提供一种计算机程序,其中,当该计算机程序在计算机中执行时,令该计算机执行如第一方面和第二方面中任一实现方式描述的方法。
12.本说明书的上述实施例提供的方案,可以将区块链系统中的共识节点分为fvp类型共识节点和lvp类型共识节点,在lvp类型共识节点中只保存轻量存储。在该方案中,在区块链系统要新增或删除目标节点时,区块链系统中的共识节点可以基于节点新增场景或节点退出场景下的fvp数目最小要求,对区块链系统进行网络活性检测。由此,既可以降低区块链系统的存储成本,又可以保证网络活性。
附图说明
13.为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附
图获得其他的附图。
14.图1示出了一实施例中的区块链架构图;
15.图2是pbft共识算法中的共识过程示意图;
16.图3是相关技术中的共识节点的区块链数据存储的结构示意图;
17.图4是mpt树的结构示意图;
18.图5是本说明书实施例中的lvp中的状态哈希值树和存储哈希值树的示意图;
19.图6是本说明书实施例中的状态哈希值树的示意图;
20.图7是本说明书实施例中的共识方法的流程图;
21.图8是本说明书另一实施例中的共识方法的流程图;
22.图9是本说明书实施例中的交易处理方法的流程图;
23.图10是区块链系统的节点信息的一个示意图;
24.图11是更新的节点信息的一个示意图;
25.图12是本说明书实施例中的交易处理方法的流程图;
26.图13是本说明书实施例中的交易处理方法的流程图;
27.图14是区块链系统的节点信息的一个示意图;
28.图15是本说明书实施例中的交易处理装置的结构示意图;
29.图16是本说明书实施例中的交易处理装置的结构示意图。
具体实施方式
30.为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
31.图1示出了一实施例中的区块链架构图。在图1所示的区块链架构图中,区块链100中包括n个节点,图1中示意示出节点1-节点8。节点之间的连线示意性的表示p2p(peer to peer,点对点)连接,所述连接例如可以为tcp连接等,用于在节点之间传输数据。
32.区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(from)、接收字段(to)和数据字段(data)。其中,在交易为转账交易的情况中,from字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址,to字段表示接收该交易(即接收转账)的账户地址,data字段中包括转账金额。
33.区块链中可提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约,是发起一笔指向智能合约地址的交易,使得区块链中每个节点分布式地运行智能合约代码。
34.在部署合约的场景中,例如,bob将一个包含创建智能合约信息(即部署合约)的交易发送到如图1所示的区块链中,该交易的data字段包括待创建的合约的代码(如字节码或者机器码),交易的to字段为空,以表示该交易用于部署合约。节点间通过共识机制达成一致后,确定合约的合约地址“0x6f8ae93
…”
,各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户,分配与该合约账户对应的状态存储,并存储合约代码,将合约代
码的哈希值保存在该合约的状态存储中,从而合约创建成功。
35.在调用合约的场景中,例如,bob将一个用于调用智能合约的交易发送到如图1所示的区块链中,该交易的from字段是交易发起方(即bob)的账户的地址,to字段为上述“0x6f8ae93
…”
,即被调用的智能合约的地址,交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后,区块链中的各个节点可分别执行该交易,从而分别执行该合约,基于该合约的执行更新状态数据库。
36.区块链中的共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制,可以保证最新区块被准确添加至区块链。当前主流的共识机制包括:工作量证明(proof of work,pow)、股权证明(proof of stake,pos)、委任权益证明(delegated proof of stake,dpos)、实用拜占庭容错(practical byzantine fault tolerance,pbft)算法等。其中,在各种共识算法中,通常在预设数目的共识节点对待共识的数据(即共识提议)达成一致之后,从而确定对该共识提议的共识成功。具体是,在pbft算法中,对于n≥3f 1个共识节点,可容忍f个恶意节点,也就是说,当n个共识节点中2f 1个节点达成一致时,可确定共识成功。在相关技术中,为了实现共识功能,在共识节点上存储全量的账本,即存储全部区块和全部账户的状态。从而,区块链中的每个节点可通过执行相同的交易而产生区块链中的相同的状态,以使得区块链中的每个节点存储相同的状态数据库。
37.图2是pbft共识算法中的共识过程示意图。如图2所示,根据pbft共识算法,可将共识过程划分为请求(request)、预备(pre-prepare,pp)、准备(prepare,p)和提交(commit,c)四个阶段。假设一区块链中包括节点n1-节点n4四个共识节点,其中,节点n1例如为主节点,节点n2-节点n4例如为从节点,根据pbft算法,在节点n1-节点n4中可容忍f=1个恶意节点。具体是,在请求阶段,区块链的用户可通过其用户设备向节点n1发送请求,该请求例如为区块链交易的形式。在预备阶段,节点n1在从一个或多个用户设备接收到多个交易之后,可将该多个交易打包为共识提议,将该共识提议及节点n1对该共识提议的签名发送给其他共识节点(即节点n2-节点n4),以用于生成区块,该共识提议中可包括该多个交易的交易体和该多个交易的提交顺序等信息。在准备阶段,各个从节点可对共识提议进行签名并发送给其他各个节点。假设节点n4为恶意节点,节点n1、节点n2和节点n3在分别接收到2f=2个其他共识节点的对共识提议的签名之后,可确定准备阶段完成,可进入提交阶段。例如,如图2中所示,节点n1在接收到节点n2和节点n3的签名之后,验证节点n2和节点n3的签名都是正确的对共识提议的签名,则确定准备阶段完成,节点n2在接收到节点n3的签名和预备阶段节点n1的签名并验证通过之后,确定准备阶段完成。在提交阶段,各个共识节点对共识提议进行提交阶段的签名并发送给其他各个共识节点,各个共识节点在接收到2f=2个其他共识节点的提交阶段的签名之后,可确定提交阶段完成,共识成功。例如,节点n1在接收到节点n2和节点n3的提交阶段的签名并验证之后,确定提交阶段完成,从而,节点n1可根据共识提议执行所述多个交易,生成并存储包括所述多个交易的区块(例如区块n),根据多个交易的执行结果更新世界状态,并将多个交易的执行结果返回给用户设备。类似地,节点n2和节点n3在确定提交阶段完成之后,执行所述多个交易,根据多个交易的执行结果更新世界状态,并生成并存储区块n。通过上述过程,实现了节点n1、节点n2和节点n3的存储一致性。也就是说,节点n1-节点n4在存在一个恶意节点的情况下仍可以实现对共识提议的共识成功,完成对区块的执行。
38.图3是相关技术中的共识节点的区块链数据存储的结构示意图。在图3所示的区块链数据存储中,每一区块的区块头包括若干字段,例如上一区块哈希previous_hash(图中的prev hash),随机数nonce(在一些区块链系统中这个nonce不是随机数,或者在一些区块链系统中不启用区块头中的nonce),时间戳timestamp,区块号block num,状态树根哈希state_root,交易树根哈希transaction_root,收据树根哈希receipt_root等。其中,下一区块(如区块n 1)的区块头中的prev hash指向上一区块(如区块n),即为上一区块的区块hash值(即区块头的哈希值)。通过这种方式,区块链上通过区块头实现了下一区块对上一区块的锁定。特别的,如前所述,state_root是当前区块中所有账户的状态组成的状态树(state trie)的根的哈希值,该状态树例如为mpt树(merkle patricia tree)。
39.mpt树是结合了merkle tree(默克尔树)和patricia tree(压缩前缀树,一种更节省空间的trie树,字典树)的一种树形结构。merkle tree算法对每个叶子节点都计算一个hash(哈希)值,然后两两连接再次计算hash,一直到最顶层的merkle根。以太坊中采用改进的mpt树,mpt树例如是16叉树的结构。
40.状态树中包含以太坊网络中每个账户所对应的存储内容的键值对(key and value pair)。状态树中的“键”可以是一个160位的标识符(以太坊账户的地址),这个账户地址中包含的字符分布于从状态树的根节点到叶子节点的路径中的各个节点中。参考图3中所示,mpt状态树的叶子节点(例如节点t4和节点t5)还包括各个账户的value。其中,当账户为用户账户(又称为外部账户)时,例如图3中的账户a,账户的value中包括计数器(nonce)和余额(balance)。当账户为合约账户时,例如图3中的账户b,账户的value中包括计数器(nonce)、余额(balance)、合约代码哈希值(codehash)和存储树根哈希值(storage_root)。其中,所述计数器,对于外部账户代表从账户地址发送的交易数量;对于合约账户,是账户创建的合约数量。
41.状态树中的节点通过哈希进行连接,具体是,可以基于父节点的子节点中的数据生成哈希值,将该生成的哈希值存储在父节点中。图4是mpt树的结构示意图。假设图4中的标示“t2”的节点对应于图3中的状态树中的节点t2,标示“t4”的节点对应于图3中的状态树中的叶子节点t4。如图4所示,图4中的各个叶子节点中包括的状态分别表示为state1、state2、state3、state4,各个状态也即为各个账户的value。图4中各个节点中的左侧框中的字符用于对账户进行索引,叶子节点到根节点之间的路径中的各个节点中包括的字符拼接起来即为该叶子节点对应的账户地址。例如,state1所在叶子节点到根节点之间的各个节点包括字符“f”、“5”和“324”,从而可以得到state1对应的账户地址为“f5324”。
42.在图4中,包括“5”的节点的子节点中包括叶子节点,在计算该节点中包括的hash(324,74)时,可通过如下的公式(1)计算:
43.hash(324,74)=hash(hash(324,hash(state1)),hash(74,hash(a,c)))
ꢀꢀꢀ
(1)
44.也就是说,在计算图4中的叶子节点t4的哈希值hash(324,hash(state1)时,对节点t4中的“324”和state1的哈希值hash(state1)进行拼接,然后对拼接的数据计算哈希值,得到叶子节点的哈希值。在计算图4中的非叶子节点(例如包括“74”的节点)的哈希值hash(74,hash(a,c))时,对该节点中的数据直接拼接,然后对拼接得到的数据计算哈希值。可以理解,状态树中的节点的哈希值为基于节点的全部数据计算得到的哈希值,状态树中的非叶子节点、且非根节点的节点中包括的哈希值是对其全部子节点的哈希值拼接之后取哈希
得到的哈希值。
45.如此可在状态树中从下至上计算叶子节点与根节点之间的每个节点中包括的哈希值,从而最后可将计算得到的图3中的节点t2的哈希值与节点t3的哈希值拼接,并对拼接得到的数据取哈希,从而生成节点t1的哈希值。该节点t1的哈希值即为该状态树的状态根,记录在区块n的state_root字段中。
46.在mpt树的一种变型中,可以包括分支节点,分支节点可以连接多个子节点,且分支节点中包括其连接的每个子节点中的数据的哈希值,即,分支节点中包括与多个主节点分别对应的多个哈希值,叶子节点连接在分支节点之后。该变型中还包括扩展节点,扩展节点可连接于分支节点之前或之后,扩展节点具有一个子节点,扩展节点中包括与其连接的子节点中的全部数据的哈希值。在该mpt树变型中,同样地可基于各层节点递归得到根节点的哈希值。本说明书实施例方案也同样适用于该种mpt树变型。
47.智能合约在区块链上完成部署后,会产生一个对应的合约账户。这个合约账户一般会具有一些状态,这些状态由智能合约中的状态变量所定义、并在智能合约创建、执行时产生新的值。如图3所示,合约的相关状态保存在存储树(storage trie)中,图3中示意示出了账户b对应的合约的存储树。存储树根节点st1的hash值即存储于上述storage_root中,从而将该合约的所有状态通过根hash锁定到状态树中该合约账户的value(即账户状态)下。存储树也可以具有mpt树形结构,与图4所示状态树类似地,从根节点到叶子节点的路径中的每个节点可包括用于寻址变量名的字符,叶子节点中存储有变量的value,从而存储了变量名(也可以称为状态地址)到状态值的key-value映射。例如,参考图3中的存储树,该存储树的叶子节点st2、st3例如包括变量a的value、变量b的value等,以变量a为例,在存储树中的根节点到叶子节点st2的节点路径中的各个节点包括的字符构成变量a的变量名称,该变量名称可以类似地由16进制字符构成。
48.其中,对存储树中的各个节点的哈希值的计算可参考对状态树中的节点的哈希值计算方法。具体是,在计算存储树中的叶子节点的哈希值时,对该叶子节点中包括的部分key和叶子节点中的状态的哈希值进行拼接,然后对拼接的数据计算哈希值,得到叶子节点的哈希值。在计算存储树中的非叶子节点且非根节点的节点的哈希值时,对该节点中的数据直接拼接,然后对拼接得到的数据计算哈希值,得到该节点的哈希值。
49.概括地说,fvp节点中包括树状的状态数据,该状态数据的叶子节点中包括账户或合约变量的状态,状态数据中的从根节点到叶子节点的路径中的各个节点包括所述状态的key,所述状态数据中的父节点中包括基于其子节点中的数据计算得到的哈希值。
50.仍参考图3,区块链中的节点在执行完成区块n之后,进行对下一批交易的共识,并在共识通过之后执行区块n 1,从而与执行区块n类似地生成与区块n 1对应的状态数据,该状态数据包括状态树及各个合约对应的存储树。其中,区块n 1的状态数据与区块n的状态数据重复的数据可以引用区块n中的数据,而不需要重复存储。如此,在每个共识节点都存储完整的区块数据和状态数据的情况下,需要占用较大的存储空间。
51.本说明书实施例提供一种轻共识节点(light validating peer,lvp),lvp中仅保存部分状态数据,例如,保存状态树和存储树中的哈希值数据,而不保存状态树和存储树中的各个账户或变量的value(即各个状态),同时区块链中还包括与相关技术中的共识节点相同的全共识节点(full validating peer,fvp)。图5是本说明书实施例中的lvp中的状态
哈希值树和存储哈希值树的示意图。如图5所示,在lvp中的状态哈希值树和存储哈希值树中,与图3中的fvp中的状态树和存储树相比,将状态树和存储树中的叶子节点中的状态替换为了该状态的哈希值,例如,将状态树中的节点t4中的state1替换为状态哈希值树的节点t4中的hash(state1),将存储树中的节点st2中的state5替换为存储哈希值树中节点st2中的hash(state5)。图6是图5中的状态哈希值树的示意图。如图6中所示,在状态哈希值树中,叶子节点中包括账户地址的末尾字符、及状态树中的对应的叶子节点的状态哈希值。如,状态哈希值树中的叶子节点t4中包括状态树中的叶子节点t4中“state1”的hash(state1)。状态哈希值树中的除叶子节点和根节点之外的各个节点中包括的哈希值可使用与状态树中相同的计算方法生成。例如,图6中的包括“5”的节点中的hash(324,74)可通过上述公式(1)计算得到。存储哈希值树也可以具有与图6所示的结构类似的结构。通过如此,图5中的状态哈希值树和存储哈希值树中除了叶子节点以外的其他节点包括的数据与图3中的状态树和存储树中的对应节点是一致的,因此图5中的节点t1的根哈希值与图3中的节点t1的根哈希值一致。
52.图5和图6中所示的状态哈希值树和存储哈希值树可用于对从fvp接收的读集进行验证,因此,可将这些数据统称为验证数据。可以理解,验证数据不限于包括如图5或图6所示的结构,例如,为了对读集进行验证,验证数据中可至少包括状态树和存储树中各个叶子节点的状态的哈希值。对于上述mpt树变型,仅需要将mpt树变型中的叶子节点中的状态删除,即可以将经过该删除后的哈希值树用作为lvp节点中的验证数据。下文将以图3-图6所示的状态数据和验证数据作为示例描述本说明书实施例中的共识和交易执行方案。
53.在基于fvp和lvp的区块链系统中,通过本说明书实施例提供的共识方案,在轻共识节点中只保存状态验证数据,通过在共识提议中包括读集,使得轻共识节点可基于状态验证数据对读集进行验证,从而可参与共识过程,大大节省了数据存储的硬件成本和时间成本,提高了区块链系统的性能和效率。
54.图7是本说明书实施例中的共识方法的流程图。该方法可由区块链系统中的作为主节点的fvp(图7中以fvp示意示出)及一个或多个lvp执行,图7中示出一个lvp作为示例。其中,区块链系统中可包括至少一个fvp,该至少一个fvp可共同确定一个fvp作为主节点,区块链系统中的除主节点之外的节点为从节点。主节点可发起共识提议,以与从节点一起进行对该共识提议的共识。
55.如图7所示,首先,在步骤s701,fvp获取多个交易对应的读集。
56.假设区块链系统中的fvp1为主节点,下文中以fvp1作为示例进行描述。fvp1可以从用户客户端或者其他fvp接收用户发送的交易。该交易可以为转账交易,或者可以为调用合约的交易等。fvp1在接收到一定量的交易之后,可以在接收到的交易中选出多个交易进行共识,以用于生成新的区块。
57.fvp1在选出多个交易之后,获取该多个交易对应的读集。该读集包括根据该多个交易包括的读操作从状态数据中读取的账户和/或合约变量的状态,该读集也即为该多个交易在被执行时需要从状态数据中读取的账户和/或合约变量的状态,其中,状态数据例如包括图3中所示的状态树和存储树。
58.具体是,fvp1可以获取多个交易各自的读集,然后可以对各个交易的读集进行合并,也即从多个交易各自的读集中选取在首次读取各个变量(包括账户和合约变量)时从状
态数据中读取的该变量的键值对,从而得到多个交易对应的读集。假设所述多个交易中的一个交易包括对账户a的余额的更新(例如减少预设金额),该交易在执行时需要首先读取账户a的value(即包括nonce和balance),然后根据读取的账户a的value获取账户a的新的value,例如,根据该交易对nonce值加1,对balance值减少预设金额,得到账户a的更新的nonce值和balance值,其构成了账户a的更新的value。从而,该交易的读集包括读取的账户a的键值对,该交易的写集包括写入的账户a的键值对。则该多个交易的读集中包括从状态数据读取的账户a的key-value键值对,其中key为账户a的账户地址,value为账户a的状态,该状态中包括账户a对应的叶子节点中的nonce值和balance值。
59.假设该多个交易中的一个交易包括对账户b对应的合约中的变量a的更新操作,由于对变量a的写入会导致对账户b中的storage_root的更新,因此,该交易也包括对账户b的写入操作。为了对账户b和变量a进行写入,该交易的读集中需要包括账户b的key-value键值对和变量a的键值对。假设该交易对账户b和变量a的读取为首次从状态数据读取的情况,则多个交易的读集中也包括基于该交易从状态数据中读取的账户b的该键值对和变量a的键值对。其中,账户b的key-value键值对中的key为账户b的账户地址,value为账户b的状态,该状态中包括账户b对应的叶子节点中的nonce、balance、codehash和storage_root各个字段的值。变量a的key-value键值对中的key为变量a的变量名称,value为变量a的状态值。根据该多个交易的读集,当在执行该交易中对账户b进行写入时,可以根据变量a的更新的value计算更新的storage_root,并与读集中的账户b的nonce、balance、codehash合并,得到账户b的更新的value,该变量a的更新的value和账户b的更新的value将记录在该交易的写集中,以用于更新状态数据。
60.在一种实施方式中,fvp1可以对各个交易进行静态分析,分析交易的交易体以及交易中调用的合约的合约代码,从而确定各个交易在执行时需要读取的账户和/或变量名称,即key,通过所得到的key从状态数据中读取到key对应的value,从而生成该多个交易对应的读集。在另一种实施方式中,fvp1可预执行所述多个交易,fvp1可按照多个交易的预设的排列顺序预执行多个交易,或者fvp1可根据各个交易的接收顺序预执行多个交易,并根据各个交易的预执行顺序确定共识提议中的该多个交易的排列顺序。
61.fvp1在预执行多个交易时,当首次读取账户或合约变量的value时,从状态数据中进行读取,并根据该首次读取账户或合约变量的value生成该多个交易的读集。同时,fvp1缓存首次读取的账户或合约变量的value,当在预执行该多个交易中对这些首次读取账户或合约变量的value进行更新时,在缓存中更新这些账户或合约变量的value,当在预执行该多个交易中再次读取这些账户或合约变量的value时,则读取缓存中的这些账户或合约变量的value,其中,再次读取的这些账户或合约变量的value不需要写入该多个交易的读集中。
62.在步骤s703,fvp向lvp发送共识提议,该共识提议中包括所述多个交易的读集。
63.fvp1可生成共识提议,以用于对该多个交易的排列顺序进行共识。在一种实施方式中,该共识提议中可包括所述多个交易的交易列表,该交易列表中包括顺序排列的多个交易的交易体,另外,该共识提议中还包括上述获取的多个交易的读集。通过在共识提议中包括读集,参考图2所示的共识过程,可以在pp阶段就进行对读集的验证,即在pp阶段就确定fvp1是否作恶,如果在pp阶段确定fvp1作恶,可以提前结束共识过程,从而不需要进行后
续的准备阶段和提交阶段,节省了计算资源,提高了区块链中的系统效率。
64.在另一种实施方式中,在共识提议中可包括顺序排列的多个交易的交易标识(如各个交易的哈希值)及上述读集,同时,fvp1或者其他从用户设备接收交易的fvp可通过广播将多个交易各自的交易体广播给其他各个共识节点,从而使得减小了共识提议的数据量,节省了共识过程中用于签名的计算量。
65.在步骤s705,lvp基于验证数据验证读集是否正确。
66.在一种实施方式中,lvp中存储了图3中的状态树和存储树中的各个状态的哈希值、以及到该哈希值的索引数据(例如账户地址或变量名称)作为验证数据。lvp在从共识提议中获取读集之后,可使用各个状态的哈希值对读集中的各个状态进行验证。例如,读集中包括账户a的value,lvp可从验证数据中获取账户a的状态哈希值,使用该状态哈希值对账户a的value进行验证,即验证读集中的账户a的value与本地存储的账户a的状态哈希值是否对应,如果对应,则可确定读集中的账户a的value为正确的状态。在读集中包括账户b的value和变量a的value的情况下,lvp可从验证数据中获取账户b的状态哈希值和变量a的状态哈希值,以分别对读集中的账户b的value和变量a的value进行验证。
67.在另一种实施方式中,lvp中存储了如图5所示的状态哈希值树和存储哈希值树作为验证数据。lvp在从共识提议中获取读集之后,可基于状态哈希值树和存储哈希值树对读集中的各个状态进行简单支付验证(simplified payment verification,spv)。例如,读集中包括账户a的value,lvp可计算读集中的账户a的value的哈希值(例如hash1),基于状态哈希值树中的其他叶子节点的值(即状态哈希值)与hash1向上层层计算各个节点的哈希值,直到计算状态哈希值树的根哈希值(例如root1),确定root1与lvp中存储的状态哈希值树的根哈希值是否一致,如果一致,则认为该读集中的账户a的value为正确的。在读集中包括账户b的value和变量a的value的情况下,lvp可类似地基于状态哈希值树和存储哈希值树对账户b的value和变量a的value进行spv验证。
68.在一种实施方式中,在lvp中存储有与上述mpt树变型对应的验证数据时,由于该验证数据中类似地包括mpt树变型中的各个状态的哈希值,并且验证数据中的各层节点通过哈希进行连接,因此,可类似地基于该验证数据对读集进行验证,在此不再赘述。
69.除此之外,lvp中还可以存储有各个区块的区块头,如图3中所示,区块头中可以包括状态树的根哈希值、交易树的根哈希值和收据树的根哈希值,区块头可用于对交易、收据等数据进行spv验证,并可用于生成下一个区块的区块头。
70.在步骤s707,共识节点(包括fvp和lvp)完成对多个交易的共识过程。
71.lvp通过基于本地存储的验证数据对从fvp接收的读集进行验证,在验证通过的情况中,也即验证所述读集为正确的读集,使得lvp在后续可以基于该读集与fvp类似地执行节点功能,例如执行交易、生成区块等功能。lvp在验证通过之后可以完成对多个交易的共识过程,包括完成如图2所示的pp阶段、p阶段和c阶段。如果验证未通过,则可确定主节点存在作恶的可能,lvp可以尽早结束该共识过程,并开始更换主节点的流程,从而提高了区块链系统的效率。
72.在步骤s709,lvp根据读集执行多个交易。
73.在对共识提议共识成功之后,lvp可基于读集中的状态执行共识提议中的多个交易。具体是,lvp在执行交易的过程中需要读取账户或变量的状态时,如果是对该账户或变
量的首次读取,可从该读集中找到账户或变量的状态,基于该账户或变量的状态进行对该交易的执行,根据该交易中的对账户或合约变量的写操作,得到该交易的写集,该写集中包括账户的键值对或合约账户和合约变量的键值对,用于更新状态数据中的状态。lvp在从读集中读取账户或合约变量的状态之后,可以缓存该状态,并在执行对该账户或合约变量的写入时,在缓存中更新该账户或合约变量的状态,以用于后续在执行交易过程中的对该账户或合约变量的状态的读取。由于该读集中的账户或变量的状态已经经过验证,即为该账户或变量当前的正确状态,因此,基于读集中的状态执行交易得到的执行结果与fvp基于状态数据中的状态执行交易得到的执行结果一致。
74.具体是,假设如上文所述多个交易中的一个交易包括对账户a的余额的更新,lvp首先从多个交易的读集中读取账户a的value(假设读取的value为v1)并存储在缓存中,根据该交易对v1进行更新,从而得到账户a的更新的value(假设该value为v2),其中v2中包括更新的nonce值和更新的balance值,从而可在该交易的写集中写入账户a的更新的键值对,并更新缓存中的账户a的值。
75.假设如上文所述,多个交易中的一个交易包括对账户b对应的合约的变量a的写入,lvp首先从多个交易的读集中读取账户b的value(假设为v3)和变量a的value(假设为v4),根据该交易对v4进行处理,得到变量a的更新的value(假设为v5),计算v5的哈希值,代入图5中的存储哈希值树,计算根节点st1的哈希值,以根节点st1的哈希值作为账户b的更新的storage_root,结合该交易的读集中的账户b的nonce、balance和codehash,计算出账户b的更新的value(假设为v6),从而可在该交易的写集中包括账户b的更新的键值对和变量a的更新的键值对。
76.在lvp根据读集执行多个交易的同时,fvp1如果在先前已经预执行多个交易,由于如前文所述,fvp1预执行该多个交易的顺序与共识提议中的多个交易的排列顺序对应,因此fvp1在预执行多个交易时对状态的读取、更新和写入与执行多个交易时一致,从而,可以将预执行多个交易得到的写集用作为执行所述多个交易的写集,并根据该写集得到多个交易的收据。fvp1如果在先前未预执行多个交易,则可以根据所述读集、或者通过从状态数据中读取状态,而按照共识提议中的多个交易的排列顺序来执行该多个交易。上述两种方式中,fvp1中得到的多个交易的写集和收据与lvp执行多个交易的写集和收据是一致的。
77.在步骤s711,共识节点(包括fvp和lvp)对多个交易的执行结果进行共识。
78.共识节点可类似地通过图2所示的共识过程进行对多个交易的执行结果的共识。具体是,各个共识节点在执行多个交易得到各个交易的写集和收据之后,可根据多个交易的交易体、各个交易的写集和收据计算该多个交易对应的状态树根哈希值、交易树根哈希值和收据树根哈希值。基于该多个交易对应的状态树根哈希值、交易树根哈希值、收据树根哈希值、以及上一个区块的区块哈希(即区块头哈希值,如图3中的prev hash所示)计算该多个交易对应的区块(区块b1)的区块哈希(即区块b1的区块头哈希值)。fvp1可在pp阶段向其他共识节点发送共识提议,该共识提议中包括区块b1的区块哈希。lvp在接收到该共识提议之后,可比较从fvp1接收的区块哈希与自己计算的区块b1的区块哈希是否一致,如果一致,则对该区块哈希进行签名并发送给其他各个共识节点。如此在完成图2中的pp阶段、p阶段和c阶段之后,完成对区块哈希的共识。在共识节点完成对区块哈希的共识之后,从而可保证各个共识节点对多个交易的执行结果一致,从而各个节点可根据多个交易的执行结果
更新存储。
79.在步骤s713,lvp根据多个交易的写集更新验证数据。
80.具体是,lvp在得到各个交易的写集之后,根据各个交易的写集得到该多个交易对应的写集(例如wset1),该写集wset1中包括根据所述多个交易的写操作而将用于更新状态数据的账户的key-value对或合约账户和合约变量的key-value对。在对多个交易的执行结果成功共识之后,lvp可基于wset1中各个状态的哈希值更新lvp中的验证数据。
81.在一种实施方式中,lvp中的验证数据包括各个账户和各个合约变量的状态的哈希值。假设写集wset1中包括将写入的账户a的键值对,lvp可基于wset1中的账户a的key找到验证数据中该key对应的value哈希值的存储位置,将wset1中的key对应的状态的哈希值写入到所述存储位置处。
82.假设写集wset1中包括将写入的账户b的键值对和变量a的键值对,lvp首先根据变量a的更新的value,计算更新的状态哈希值,在验证数据中更新变量a的状态哈希值。之后,lvp根据账户b的更新value,计算更新的状态哈希值,在验证数据中更账户b的状态哈希值。
83.在另一种实施方式中,lvp中的验证数据包括如图5所示的状态哈希值树和存储哈希值树,lvp可首先如在上一种实施方式中所述更新状态哈希值树和存储哈希值树中的与写集中多个状态对应的叶子节点中的状态哈希值。然后可基于更新的叶子节点,向上更新状态哈希值树和存储哈希值树中的各层节点中包括的哈希值,直到更新状态哈希值树和存储哈希值树的根节点的哈希值。
84.另外,lvp在对区块哈希完成共识之后,可存储所生成的区块的区块头,以用于进行spv验证,以及用于进行对下一个区块的生成。
85.在lvp更新存储的同时,fvp1也根据多个交易的执行结果更新存储,具体是,fvp1根据多个交易的写集更新如图3所示的状态树和存储树,以及存储该多个交易对应的区块b1,该区块包括区块头和区块体,区块体中例如包括多个交易的交易体、收据等数据。在区块链系统中的lvp和fvp都根据多个交易的执行结果更新存储之后,lvp中的验证数据仍与fvp中的状态数据相对应,以用于继续对下一批多个交易进行共识。
86.本说明书实施例的方案,在lvp中只保存轻量存储,通过在共识提议中包括读集,使得lvp可基于验证数据对读集进行验证,从而可参与共识过程,大大节省了数据存储的硬件成本和时间成本,提高了区块链系统的性能和效率。
87.图8是本说明书另一实施例中的共识方法的流程图。在该实施例中,lvp可包括共识装置、存储装置和执行装置,所述共识装置、存储装置和执行装置可以为单个计算设备中的分离的单元,或者可以为多个分离的计算设备。其中,存储装置中存储有lvp中的验证数据和区块头等数据。
88.如图8所示,在步骤s801,fvp获取多个交易对应的读集。该步骤可参考上文对步骤s701的描述,在此不再赘述。
89.在步骤s803,fvp向lvp的共识装置发送共识提议,该共识提议中包括上述读集。
90.在步骤s805,共识装置将读集发送给存储装置。
91.在步骤s807,存储装置基于验证数据验证读集是否正确。该步骤中的验证过程可参考上文对步骤s705的描述,在此不再赘述。
92.在步骤s809,在验证通过的情况中,存储装置将验证通过的验证结果返回给共识
装置。
93.在步骤s811,共识装置将多个交易的交易列表和读集发送给执行装置,该交易列表中包括多个交易各自的交易体、以及多个交易的排列顺序。
94.在步骤s813,执行装置根据读集执行多个交易。
95.执行装置通过根据读集执行各个交易,可得到各个交易的执行结果,该执行结果例如包括各个交易的写集和收据。
96.在步骤s815,执行装置将多个交易的执行结果返回给共识装置。
97.在步骤s817,共识装置根据多个交易的执行结果,生成多个交易对应的区块哈希值。该步骤可参考上文对步骤s711的描述中的相关描述,在此不再赘述。
98.在步骤s819,共识节点(包括fvp和lvp)进行对区块哈希值的共识。也即各个共识节点的共识装置对区块哈希值进行共识。
99.在步骤s821,在对区块哈希值共识成功的情况下,共识装置将生成的区块头和更新的验证数据发送给存储装置。其中,更新的验证数据例如可包括图5所示的状态哈希值树和存储哈希值树中的更新的节点值。
100.在步骤s823,存储装置存储区块头,更新验证数据。
101.本说明书实施例还提供了交易处理方案。在基于fvp和lvp的区块链系统中,通过本说明书实施例提供的交易处理方案,既可以降低区块链系统的存储成本,又可以保证网络活性。需要说明,区块链系统中的轻共识节点是设置有lvp类型的共识节点,可称为lvp类型共识节点。区块链系统中的全共识节点是设置有fvp类型的共识节点,可称为fvp类型共识节点。为了便于清楚的描述交易处理方案,下文中将轻共识节点称为lvp类型共识节点,将全共识节点称为fvp类型共识节点。
102.在该交易处理方案中,区块链系统中的共识节点(如fvp类型共识节点、lvp类型共识节点)可以获取用于新增或删除目标节点的交易(可称为第一交易),并针对该第一交易进行处理。
103.下面,先以用于新增目标节点的第一交易为例,介绍本说明书实施例中的交易处理方案。
104.图9是本说明书实施例中的交易处理方法的流程图。区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应。具体地,该验证数据可以包括该多个状态各自的哈希值。该方法可由区块链系统中的共识节点(如fvp类型共识节点、lvp类型共识节点)执行。
105.如图9所示,首先,在步骤s901,获取第一交易,第一交易用于新增目标节点,并且包括目标节点的类型。
106.其中,当目标节点将要作为fvp类型共识节点加入区块链系统时,第一交易中包括的目标节点的类型,可以表示为“fvp”或者其他用于代表fvp的字符(如数字1等)。当目标节点将要作为lvp类型共识节点加入区块链系统时,第一交易中包括的目标节点的类型,可以表示为“lvp”或者其他用于代表lvp的字符(如数字0等)。应该理解,本说明书实施例不对节点类型的表示形式做具体限定。
107.需要说明,第一交易例如还可以包括目标节点的标识。第一交易可以是区块链系
统的管理员或者目标节点的拥有者通过用户设备发送至区块链系统的。例如,该管理员或者该拥有者可以通过用户设备将第一交易发送至区块链系统中的某个fvp类型共识节点。该某个fvp类型共识节点可以为区块链系统中的主节点。
108.当交易处理方法由lvp类型共识节点执行时,该lvp类型共识节点可以缓存有从fvp类型共识节点接收的待执行的多个交易,第一交易可以包含在该多个交易中。因而,该lvp类型共识节点可以从该多个交易中获取第一交易。
109.在步骤s903,获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型。
110.在节点信息中,fvp类型共识节点和lvp类型共识节点各自的类型的表示形式,可参考前文中的相关说明,在此不再赘述。可选地,节点信息还可以包括以下至少一项:节点标识、全部共识节点数目、fvp数目的实际值。其中,fvp数目为区块链系统中fvp类型共识节点的数目。
111.实践中,区块链系统的节点信息可以存储于不同的位置。
112.在一种实施方式中,fvp类型共识节点还存储有区块,lvp类型共识节点还存储有该区块的区块头,节点信息可以存储于区块头中。基于此,无论是fvp类型共识节点还是lvp类型共识节点,在执行交易处理方法时,都可以从区块头获取节点信息。例如,可以从当前最新的区块头开始查找节点信息,从而获取到节点信息。需要说明,当区块链系统中只有创世块一个区块时,节点信息可以存储于创世块的区块头中,可以从创世块的区块头中获取节点信息。
113.在另一种实施方式中,区块链系统中可以部署有智能合约,节点信息可以存储于该智能合约在fvp类型共识节点内的合约状态中。当交易处理方法由fvp类型共识节点执行时,该fvp类型共识节点可以从该合约状态中获取节点信息。当交易处理方法由lvp类型共识节点执行时,具体的执行过程可参考图12对应实施例中的相关说明。
114.在步骤s905,在基于节点信息确定fvp数目在区块链系统未来新增目标节点后的实际值满足预设的fvp数目最小要求时,同意目标节点加入。
115.举例来说,fvp数目最小要求可以包括用于表征fvp数目的期望下限值的表达式。在区块链系统采用pbft共识算法的情况下,该表达式例如可以为f 1。其中,f为恶意节点的数目。根据前文中对pbft共识算法的介绍,可以获知,区块链系统的全部共识节点数目n和恶意节点数目f满足以下约束:n≥3f 1。f可以基于该约束计算得出。具体地,当n=3f 1时,f=(n-1)/3。
116.由此,可以基于节点信息和用于表征fvp数目的期望下限值的表达式,确定fvp数目在区块链系统未来新增目标节点后的实际值和期望下限值。而后可以对该实际值和期望下限值进行大小比较。当该实际值大于等于该期望下限值时,可以同意目标节点加入。当该实际值小于该期望下限值时,可以拒绝目标节点加入。
117.参看图10,其是区块链系统的节点信息的一个示意图。如图10所示,该节点信息示出了区块链系统包括6个共识节点,即vp0-vp5。其中,vp0-vp2的类型均为fvp,vp3-vp5的类型均为lvp。基于该节点信息,可以获知,fvp数目当前的实际值为3,全部共识节点数目为6。
118.假设区块链系统采用pbft共识算法,用于表征fvp数目的期望下限值的表达式为f 1,第一交易中包括的目标节点的类型为lvp。基于图10中示出的节点信息,可以确定出区
块链系统未来新增目标节点后,全部共识节点数目n=7,fvp数目的实际值q2=3。将全部共识节点数目n=7代入公式f=(n-1)/3,可以计算出f=2。基于f=2和用于表征fvp数目的期望下限值的表达式f 1,可以计算出fvp数目在区块链系统未来新增目标节点后的期望下限值q1=2 1=3。通过对q1和q2进行大小比较,可以确定q2=q1,满足预设的fvp数目最小要求,从而可以同意目标节点加入。由此,可以确保fvp数目在区块链系统未来新增目标节点后的实际值大于恶意节点数目f,从而有效保证区块链系统的网络活性。例如,即使f个恶意节点均出现在fvp类型共识节点中,也能保证至少一个fvp类型共识节点能正常运行,从而保证区块链系统能正常运行。
119.在一种实施方式中,lvp类型共识节点中可以包括如前所述的共识装置。当交易处理方法由lvp类型共识节点执行时,该lvp类型共识节点中的该共识装置可以基于节点信息,确定fvp数目在区块链系统未来新增目标节点后的实际值是否满足预设的fvp数目最小要求,从而得到同意目标节点加入或拒绝目标节点加入的结果。
120.在一种实施方式中,在从区块头获取区块链系统的节点信息的情况下,还可以在将要生成的区块的区块头中存储更新的节点信息,该更新的节点信息中包括目标节点的信息。作为示例,在图10示出的节点信息的基础上,可以在该节点信息中将目标节点的信息写入vp5的信息的下方,目标节点的信息可以如图11中所示,示出目标节点的标识“vp6”和类型“lvp”。其中,图11是更新的节点信息的一个示意图。该标识“vp6”例如可以是通过执行第一交易而为目标节点分配的。
121.在一种实施方式中,在区块链系统中部署有智能合约,节点信息存储于该智能合约在fvp类型共识节点内的合约状态中的情况下,当交易处理方法由fvp类型共识节点执行时,该fvp类型共识节点还可以基于第一交易的执行结果,在该合约状态中的该节点信息中添加目标节点的信息。
122.在一种实施方式中,当交易处理方法由fvp类型共识节点执行时,该fvp类型共识节点还可以在接收到目标节点发送的数据同步请求时,向目标节点同步数据。具体地,可以基于目标节点的类型,确定需要向目标节点同步哪些数据,从而对目标节点进行数据同步。实践中,目标节点在成功加入区块链系统后,可以从fvp类型共识节点获取数据。例如,当目标节点为lvp类型共识节点时,可以从fvp类型共识节点获取数据;当目标节点为fvp类型共识节点时,可以从其他fvp类型共识节点获取数据。
123.图9对应的实施例提供的交易处理方案,可以将区块链系统中的共识节点分为fvp类型共识节点和lvp类型共识节点,在lvp类型共识节点中只保存轻量存储。在该方案中,在区块链系统要新增目标节点时,区块链系统中的共识节点可以基于节点新增场景下的fvp数目最小要求,对区块链系统进行网络活性检测。由此,既可以降低区块链系统的存储成本,又可以保证网络活性。
124.实践中,在区块链系统中部署有智能合约,节点信息存储于该智能合约在fvp类型共识节点内的合约状态中的情况下,当交易处理方法由lvp类型共识节点执行时,该lvp类型共识节点可以执行如图12所示的流程。其中,图12是本说明书实施例中的交易处理方法的流程图。
125.如图12所示,首先,在步骤s1201,lvp类型共识节点获取第一交易,第一交易用于新增目标节点,并且包括目标节点的类型。
126.lvp类型共识节点可以缓存有从fvp类型共识节点接收的待执行的多个交易,第一交易可以包含在该多个交易中。因而,lvp类型共识节点可以从该多个交易中获取第一交易。
127.在步骤s1203,lvp类型共识节点从所缓存的读集中获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型。
128.其中,该读集是从fvp类型共识节点接收的,包括根据第一交易从上述智能合约在fvp类型共识节点内的合约状态中读取的节点信息。需要说明,该读集可以对应于上述多个交易,可以包含在从fvp类型共识节点接收的与上述多个交易有关的共识提议中。
129.在一种实施方式中,lvp类型共识节点在从读集中获取区块链系统的节点信息之前,可以先基于存储的验证数据对读集进行验证。具体的验证过程可参考图7对应实施例中的相关说明,在此不再赘述。由此,lvp类型共识节点可以在读集通过验证的情况下,从读集中获取节点信息。
130.在步骤s1205,lvp类型共识节点在基于节点信息确定fvp数目在区块链系统未来新增目标节点后的实际值满足预设的fvp数目最小要求时,同意目标节点加入。该步骤可参考上文对步骤s905的描述,在此不再赘述。
131.在一种实施方式中,lvp类型共识节点还可以基于第一交易的执行结果,更新验证数据。这里,关于验证数据的更新过程,可参考图7对应实施例中的相关说明,在此不再赘述。
132.前文中以用于新增目标节点的第一交易为例,介绍了本说明书实施例中的交易处理方案。下面,以用于删除目标节点的第一交易为例,接着介绍本说明书实施例中的交易处理方案。
133.参看图13,其是本说明书实施例中的交易处理方法的流程图。区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应。具体地,该验证数据可以包括该多个状态各自的哈希值。该方法可由区块链系统中的共识节点(如fvp类型共识节点、lvp类型共识节点)执行。
134.如图13所示,首先,在步骤s1301,获取第一交易,第一交易用于删除目标节点。
135.其中,第一交易可以包括目标节点的标识。进一步地,第一交易还可以包括目标节点的类型。这里,关于第一交易的获取方式,可参考前文中的相关说明,在此不再赘述。
136.在步骤s1303,获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型。该步骤可参考上文对步骤s903的描述,在此不再赘述。
137.在步骤s1305,在基于节点信息确定fvp数目的实际值满足预设的fvp数目最小要求时,同意目标节点退出。
138.fvp数目最小要求例如可以包括用于表征fvp数目的期望下限值的表达式。在区块链系统采用pbft共识算法的情况下,该表达式例如可以为f 2。
139.基于此,可以基于节点信息和用于表征fvp数目的期望下限值的表达式,确定fvp数目的实际值和期望下限值。应该理解,该实际值和期望下限值,是fvp数目当前的实际值和期望下限值,也即fvp数目在区块链系统删除目标节点前的实际值和期望下限值。而后,可以对该实际值和期望下限值进行大小比较。当该实际值大于等于该期望下限值时,可以
同意目标节点退出。
140.参看图14,其是区块链系统的节点信息的一个示意图。如图14所示,该节点信息示出了区块链系统包括7个共识节点,即vp0-vp6。其中,vp0-vp3的类型均为fvp,vp4-vp6的类型均为lvp。基于该节点信息,可以获知,fvp数目当前的实际值为4,全部共识节点数目为7。
141.假设区块链系统采用pbft共识算法,用于表征fvp数目的期望下限值的表达式为f 2,第一交易具体用于删除vp6。基于该节点信息,可以确定出全部共识节点数目n=7,fvp数目的实际值q2=4。将全部共识节点数目n=7代入公式f=(n-1)/3,可以计算出f=2。基于f=2和用于表征fvp数目的期望下限值的表达式f 2,可以计算出fvp数目的期望下限值q1=2 2=4。通过对q1和q2进行大小比较,可以确定q2=q1,满足预设的fvp数目最小要求,从而可以同意目标节点退出。由此,可以确保fvp数目在区块链系统未来退出目标节点后的实际值大于恶意节点数目f,从而有效保证区块链系统的网络活性。
142.图13对应的实施例提供的交易处理方案,可以将区块链系统中的共识节点分为fvp类型共识节点和lvp类型共识节点,在lvp类型共识节点中只保存轻量存储。在该方案中,在区块链系统要退出目标节点时,区块链系统中的共识节点可以基于节点退出场景下的fvp数目最小要求,对区块链系统进行网络活性检测。由此,既可以降低区块链系统的存储成本,又可以保证网络活性。
143.图15是本说明书实施例中的交易处理装置的结构示意图。区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应。该装置可以应用于区块链系统中的共识节点(如fvp类型共识节点、lvp类型共识节点)。
144.如图15所示,本说明书实施例中的交易处理装置1500包括:交易获取单元1501、节点信息获取单元1502和处理单元1503。其中,交易获取单元1501被配置成获取第一交易,第一交易用于新增目标节点,并且包括目标节点的类型;节点信息获取单元1502被配置成获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型;处理单元1503被配置成在基于节点信息确定fvp数目在区块链系统未来新增目标节点后的实际值满足预设的fvp数目最小要求时,同意目标节点加入;fvp数目为区块链系统中fvp类型共识节点的数目。
145.在一些实施例中,fvp数目最小要求包括用于表征fvp数目的期望下限值的表达式;以及处理单元1503可以进一步被配置成:基于节点信息和该表达式,确定fvp数目在区块链系统未来新增目标节点后的实际值和期望下限值;在该实际值大于等于该期望下限值时,同意目标节点加入。
146.在一些实施例中,区块链系统中部署有智能合约,节点信息存储于该智能合约在fvp类型共识节点内的合约状态中;第一交易调用智能合约,当上述装置1500应用于fvp类型共识节点时,上述装置1500还可以包括:第一存储单元(图中未示出),被配置成基于第一交易的执行结果,在该合约状态中的该节点信息中添加目标节点的信息。
147.在一些实施例中,当上述装置1500应用于lvp类型共识节点时,该lvp类型共识节点缓存有从fvp类型共识节点接收的读集,该读集包括根据第一交易从上述合约状态读取的节点信息;以及节点信息获取单元1502可以进一步被配置成:从该读集中获取节点信息。
148.在一些实施例中,上述装置1500还可以包括:验证单元(图中未示出),被配置成基
于存储的验证数据对读集进行验证;节点信息获取单元1502可以进一步被配置成:在读集通过验证后,从读集中获取节点信息。
149.在一些实施例中,上述装置1500还可以包括:验证数据更新单元(图中未示出),被配置成基于第一交易的执行结果,更新验证数据。
150.在一些实施例中,fvp类型共识节点还存储有区块,lvp类型共识节点还存储有该区块的区块头,节点信息存储于区块头中;以及节点信息获取单元1502可以进一步被配置成:从区块头中获取节点信息;上述装置1500还可以包括:第二存储单元(图中未示出),被配置成在将要生成的区块的区块头中存储更新的节点信息,该更新的节点信息中包括目标节点的信息。
151.在一些实施例中,当上述装置1500应用于fvp类型共识节点时,上述装置1500还可以包括:数据同步单元(图中未示出),被配置成在接收到目标节点发送的数据同步请求时,向目标节点同步数据。
152.图16是本说明书实施例中的交易处理装置的结构示意图。区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应。该装置可以应用于区块链系统中的共识节点(如fvp类型共识节点、lvp类型共识节点)。
153.如图16所示,本说明书实施例中的交易处理装置1600包括:交易获取单元1601、节点信息获取单元1602和处理单元1603。其中,交易获取单元1601被配置成获取第一交易,第一交易用于删除目标节点;节点信息获取单元1602被配置成获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型;处理单元1603被配置成在基于节点信息确定fvp数目的实际值满足预设的fvp数目最小要求时,同意目标节点退出;fvp数目为所述区块链系统中fvp类型共识节点的数目。
154.在图15、16分别对应的装置实施例中,关于各单元的进一步解释,可参考前文中相关方法实施例的相关说明,在此不再赘述。
155.本说明书实施例还提供了一种区块链系统,区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应;区块链系统中的共识节点,用于获取第一交易,第一交易用于新增目标节点,并且包括目标节点的类型;获取区块链系统的节点信息,节点信息包括所述区块链系统中各个共识节点各自的类型;在基于节点信息确定fvp数目在区块链系统未来新增目标节点后的实际值满足预设的fvp数目最小要求时,同意目标节点加入;fvp数目为区块链系统中fvp类型共识节点的数目。
156.本说明书实施例还提供了一种区块链系统,区块链系统中的共识节点包括fvp类型共识节点和lvp类型共识节点,fvp类型共识节点存储有状态数据,该状态数据中包括多个状态,lvp类型共识节点存储有验证数据,该验证数据与该多个状态对应;区块链系统中的共识节点,用于获取第一交易,第一交易用于删除目标节点;获取区块链系统的节点信息,节点信息包括区块链系统中各个共识节点各自的类型;在基于节点信息确定fvp数目的实际值满足预设的fvp数目最小要求时,同意目标节点退出;fvp数目为区块链系统中fvp类型共识节点的数目。
157.本说明书实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,其
中,当该计算机程序在计算机中执行时,令计算机执行以上方法实施例描述的交易处理方法。
158.本说明书实施例还提供了一种计算设备,包括存储器和处理器,其中,该存储器中存储有可执行代码,该处理器执行该可执行代码时,实现以上方法实施例描述的交易处理方法。
159.本说明书实施例还提供了一种计算机程序,其中,当该计算机程序在计算机中执行时,令计算机执行以上方法实施例描述的交易处理方法。
160.在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array,fpga))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(hardware description language,hdl),而hdl也并非仅有一种,而是有许多种,如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等,目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
161.控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit,asic)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:arc 625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
162.上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然,本技术不排
除随着未来计算机技术的发展,实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
163.虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或终端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境,甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下,并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一,第二等词语用来表示名称,而并不表示任何特定的顺序。
164.为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现,也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
165.本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
166.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
167.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
168.在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
169.内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的
示例。
170.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
171.本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
172.本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
173.本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
174.以上所述仅为本说明书一个或多个实施例的实施例而已,并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说,本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在权利要求范围之内。
再多了解一些

本文用于创业者技术爱好者查询,仅供学习研究,如用于商业用途,请联系技术所有人。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献