CN108108967B - 面向复杂数字资产的多阶段pbft共识系统及方法 - Google Patents

Abstract

本发明提供了一种面向复杂数字资产的多阶段PBFT共识系统及方法，其中，面向复杂数字资产的多阶段PBFT共识系统，包括：交易检验器，在Commit阶段完成与交易相关的一致性、安全性校验；主节点自检器，在ViewChange消息处理过程中进行处理；交易批量共识器，负责将多笔交易批量处理；View轮转器，用于完成在ViewChange协议过程中的主节点的选择、新一轮view的更新以及记录上一个view信息确保新view的延续；共识消息处理器，通过不同阶段的共识过程实现消息在全局的一致性；区块构建器，能够完成与区块相关的交易提交、排序以及区块的构建、区块校验、区块防分叉保证等操作。

Description

面向复杂数字资产的多阶段PBFT共识系统及方法

技术领域

本发明涉及区块链技术领域，具体而言涉及一种面向复杂数字资产的多阶段PBFT共识系统及方法。

背景技术

数字资产是以电子数据形式存在的各种资产，如数字货币、数字音乐等。目前数字资产管理平台如电子商务平台、物流平台等，采用单一中心化机制，所有数据(数字资产)和相关服务均集中在单一中心化平台上。由于数字资产管理平台是中心化运行的，一旦中心化服务器出现问题，就会对整个市场灾难性的后果，同时增加数据的维护成本。当单一中心化平台遭受攻击或者平台内部人员私自篡改数据时，由于数据只保存在单一中心化平台上，不与其他平台进行数据交叉验证，被篡改的数据也会被作为真实数据，故单一中心化平台提供的数据的可信性难以保证。区块链具有不可篡改、全网共享数据等特性，可保证数据不可篡改，实现数据高可信，故可基于区块链重构高可信的数字资产交易环境。

共识机制保障了区块链技术在分布式场景下能够达成一致性，并且使用去中心化的思想解决节点之间的信任问题，使众多节点达到一种较为平衡的状态。在传统的比特币等货币型区块链的共识方法大多存在浪费能源、效率低下、无法达到最终一致性等问题，PoW工作量证明机制依赖机器算力来获得记账权，资源消耗巨大；PoS权益证明机制根据节点所占代币的比例进而相应比例地降低挖矿难度，从而获得记账权，其方法在一定程度上缩短了共识的时间，但是本质上仍需要挖矿。DpoS与PoS原理相同，DpoS通过持币者持币比例确定投票影响力，持币者投票选举出一定数量的节点，由选举出的代理节点完成验证和记账，该方法极大减少了验证和记账节点的数量，但是整个共识机制依赖于代币。Fabric使用的拜占庭容错算法(PBFT：Practical Byzantine Fault Tolerance)提供了(n-1)/3的容错性，该容错算法将共识阶段分为Request、Pre-prepare、Prepare、Commit、Reply五个阶段，实现了基于余额的交易一致性保证，但是，对于形式多样的数字资产来说，其状态并非一个简单的余额可以表示，为了适应更多种类的数字资产，需要进一步对该算法进行扩充。

发明内容

为此，本发明的主要目的在于提供一种面向复杂数字资产的多阶段PBFT共识系统及方法，以达到如下目的：解决区块链技术在分布式场景下的高效共识，提供了一种多阶段PBFT共识系统及方法。多阶段PBFT共识系统在PBFT容错算法共识五阶段的基础上加入了交易批量共识器、交易校验器、主节点自检器、区块构建器等部分，完成了多阶段的消息处理和校验处理，实现了消息的高效传输，从而为数字资产状态一致性和数字资产多状态安全转换提供了保障。多阶段PBFT共识系统及方法，实现了更少的错误率，保证了高效的共识流程和健壮的共识结构。

为实现上述目的，本发明提供如下技术方案：

本发明的一样态，一种面向复杂数字资产的多阶段PBFT共识系统，包括：交易检验器100，在Commit阶段完成与交易相关的一致性、安全性校验；主节点自检器200，在ViewChange消息处理过程中进行处理；交易批量共识器300，负责将多笔交易批量处理；View轮转器400，用于完成在ViewChange协议过程中的主节点的选择、新一轮view的更新以及记录上一个view信息确保新view的延续；共识消息处理器500，通过不同阶段的共识过程实现消息在全局的一致性；区块构建器600，能够完成与区块相关的交易提交、排序以及区块的构建、区块校验、区块防分叉保证等操作。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述交易校验器包括：交易一致性校验部件101，校验交易的最新资产状态、交易时间戳；交易Hash校验部件102，校验构建新交易的内容，保障内容未经篡改。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述主节点自检器包括：共识消息超时处理部件，负责判断消息在共识时，是否发生超时现象并且进行处理；主节点超时处理部件，负责判断主节点在进行广播消息时，是否发生超时现象并且进行处理，若发生超时现象，将触发后续的ViewChange协议。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述交易批量共识器包括：Request批量封装部件，负责将客户端发送的多条请求进行封装处理；已处理Request检测部件，负责检测发送的请求是否有重复请求情况并且进行重复请求删除处理。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述View轮转器包括：主节点选举部件，能够通过轮转的方式选举一个副本节点作为主节点；旧共识消息处理部件，负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求；View更新部件，负责更新新一轮的View，包括处理上一轮view的请求信息和更新时段来的新请求。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述共识消息处理器，包括：Request消息处理部件，用于将客户端发送来的请求加上时间戳，为后面的请求处理做准备；Pre-Prepare消息处理部件，使主节点将Pre-Prepare信息广播给副本节点，副本节点对收到的消息进行处理操作；Prepare消息处理部件,使进入prepare阶段的副本节点发送prepare信息给其他所有节点，所有节点综合信息进行消息处理；Commit消息处理部件,使节点广播commit信息给其他所有节点，并且根据收到的消息进行状态判断处理；Block消息处理部件,将节点构建的区块广播给网络中的其他节点；CheckPoint消息处理部件,负责将之前的请求信息删除，使得最后达到一种stableCheckPoint状态；ViewChange消息处理部件,能够根据主节点自检器处理情况，按照一个view一个block的原则进行view的轮转；NewView消息处理部件,能够通过轮转的方式产生新的view，进入下一个view阶段。

优选地，所述的面向复杂数字资产的多阶段PBFT共识系统，其中所述区块构建器，包括：共识交易处理部件，按照交易的Nonce值提交完成共识的交易；账户交易排序部件，按照账户编码进行交易排序；区块Hash值生成部件，通过密码学方法计算区块的hash值；OneViewOneBlock部件，按照一个view一个block的生成效率进行区块的构建；区块校验部件，进行区块hash值的正确性验证、主节点签名校验、区块状态校验操作；区块防分叉部件，在每一个view中，只判定一个区块的合法性，从而防止多个区块判定产生的分叉问题。

本发明的二样态，一种面向复杂数字资产的多阶段PBFT共识方法，其中，根据本发明的一样态所述的面向复杂数字资产的多阶段PBFT共识系统的共识消息处理流程为：步骤A01，主节点选举，由View轮转器进行主节点(primary)选举，在一个View里，有一个主节点，其余的副本(replica)都叫做副本节点(backups)；步骤A02，主节点批量封装Request，主节点负责将来自客户端的Request批量封装处理；步骤A03，已处理Request检测其正确性，判断是否存在重复提交的Request，若否，进入步骤A05；步骤A04，检测到存在重复的request，将重复的request删除；步骤A05，Request消息处理，将这些批量封装好的Request按照序列发送给副本节点们，如果其他副本验证了Request，就将其写入自己的记录中；步骤A06，Pre-prepare消息处理，具体操作是主节点为Request分配了一个编号，主节点广播一条Pre-Prepare信息给副本节点，直到消息达到每一个副本节点，当副本节点接受了这条Pre-Prepare消息，该节点进入prepare阶段；若副本节点在此之前接收了一条在同一view下编号相同的request，则副本节点会不认可该request消息；当大于1/3数量的节点不认可该消息，那么对该消息的处理到此结束；否则，进入下一阶段处理流程继续处理；步骤A07，prepare消息处理，副本节点会将prepare信息广播给主节点和其他副本节点，直到信息抵达，此时该副本节点也会收到来自其他副本节点的prepare信息，该节点综合比较自身和收到的prepare信息，若满足拜占庭容错标准，即获得2f+1条确认信息(包括自己的prepare信息)，则该request在这个副本节点上的状态是prepared，这个副本节点就拥有了preparedcertificate；步骤A08，交易hash校验，新交易的内容等信息校验，若校验结果正确，进入步骤A10；步骤A09，交易hash校验错误，验证不通过，消息作废，流程终止；步骤A10，交易一致性校验，交易的最新资产状态、交易时间戳等信息校验，若校验结果正确，进入步骤A12；步骤A11，交易一致性校验错误，验证不通过，消息作废，流程终止；步骤A12，commit消息处理，节点会广播一条commit信息给其他所有节点来说明自己已经有preparecertificate了，发送commit信息的节点若收到2f+1条来自其他节点的commit信息，我们称该节点拥有了committedcertificate，则称该Request在这个副本节点上的状态是committed；步骤A13，共识消息处理，主要将交易按照Nonce值顺序进行提交；步骤A14，账户交易排序，将提交的交易根据账户编码进行排序；步骤A15，区块hash值生成，也即计算区块hash值；步骤A16，区块防分叉处理，在一个view中只进行一次区块的判定；步骤A17，OneViewOneChange，在一个view中只产生一个block；步骤A18，区块校验正确性判定，包括区块merkel根构建的正确性、状态树构建的正确性等方面，若校验结果正确，则进入步骤20；步骤A19，若区块校验结果不正确，那么该区块不被验证通过，则区块作废，该view的流程终止；步骤A20，Block消息处理，将节点构建的区块广播给网络中的其他节点；步骤A21，CheckPoint消息处理，将关于该Request的记录进行清除，为了避免删除可用信息和提高删除的效率，每隔执行K条request之后，进行一次全网广播，若返回信息显示其他副本也已执行完毕，则可清除这K条信息，判断可清除的条件是能够得到2f+1条清除信息，也就是除了节点本身外，该节点还会得到2k个清除这k条信息的同意消息，清除完成后就达到stablecheckpoint的状态；步骤A22，共识消息超时判断，当出现超时等异常情况时，主节点会自动触发viewchange协议来选举新的主节点，进入步骤A24；若没有发生超时等状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；步骤A23，主节点超时判断，当出现超时等异常情况时，主节点会自动触发viewchange协议来选举新的主节点，进入步骤A24；若没有发生超时等状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；步骤A22与步骤A23同时进行判断，判断结果超时或者不超时，都将进入步骤A24；步骤A24，ViewChange消息处理，触发viewchange，进入下一个view；步骤A25，NewView消息处理，通过轮转的方式产生新的view，进入下一个view阶段；步骤A26，旧共识消息处理，存在一个旧共识消息处理部件专门负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求，以便在新的view中能够延续上一个view的信息；步骤A27，View更新，NewView消息处理和旧共识消息处理汇总后，更新新一轮的View，包括处理上一轮view的请求信息以及更新过程中接受到的新请求，从而完成view更新处理。

根据本发明的面向复杂数字资产的多阶段PBFT共识系统及方法，具有以下有益效果：1.多阶段PBFT共识系统及方法，实现Request批量封装处理，大大提高了交易处理的效率；2.交易校验器的加入实现了交易一致性的校验，主要完成交易最新资产状态和交易时间戳的验证，为数字资产状态转换过程中的状态一致性提供了保障；3.加入了交易校验器、区块构建器、主节点自检器等实现了交易状态的一致性，同时加入View Change条件的判断和处理，降低了共识消息处理过程的复杂性，在一定程度上制止了意外和蓄意破坏等情况的发生；4.在PBFT的基础上进行了扩展和丰富，通过多阶段的共识系统及方法，实现更高的共识效率、更高频的实时交易处理速率；5.多阶段、分模块处理的共识系统及方法更加突显了共识系统的健壮性、安全性、可靠性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还能根据这些附图获得其他的附图。

图1是根据本发明构思的示例性实施例的面向复杂数字资产的多阶段PBFT共识系统的结构框图；

图2是根据本发明构思的示例性实施例的面向复杂数字资产的多阶段PBFT共识系统的各部件处理的任务内容构成的共识消息处理流程图。

【附图标记说明】

1000：面向复杂数字资产的多阶段PBFT共识系统

100：交易校验器

101：交易一致性校验部件 102：交易hash校验部件

200：主节点自检器 201：共识消息超时处理部件

202：主节点超时处理部件 300：交易批量共识器

301：Request批量封装部件 302：已处理Request检测部件

400：View轮转器 401：主节点选举部件

402：旧共识消息处理部件 403：View更新部件

500：共识消息处理器 501：Request消息处理部件

505：Block消息处理部件 502：Pre-prepare消息处理部件

506：CheckPoint消息处理部件 503：Prepare消息处理部件

507：ViewChange消息处理部件 504：Commit消息处理部件

508：NewView消息处理部件 600：区块构建器

601：共识交易处理部件 604：OneViewOneBlock部件

602：账户交易排序部件 605：区块校验部件

603：区块Hash值生成部件 606：区块防分叉部件

具体实施方式

关于本发明创造的详细内容及技术说明，现以实施例来作进一步说明，但应了解的是，这些实施例仅为用于示例说明，而不应被解释为本发明创造实施的限制。

参照图1，本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中包括：交易检验器100，在Commit阶段完成与交易相关的一致性、安全性校验；主节点自检器200，在ViewChange消息处理过程中进行处理；交易批量共识器300，负责将多笔交易批量处理；View轮转器400，用于完成在ViewChange协议过程中的主节点的选择、新一轮view的更新以及记录上一个view信息确保新view的延续；共识消息处理器500，通过不同阶段的共识过程实现消息在全局的一致性；区块构建器600，能够完成与区块相关的交易提交、排序以及区块的构建、区块校验、区块防分叉保证等操作。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述交易校验器100包括：交易一致性校验部件101，校验交易的最新资产状态、交易时间戳；交易Hash校验部件102，校验构建新交易的内容，保障内容未经篡改。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述主节点自检器200包括：共识消息超时处理部件201，负责判断消息在共识时，是否发生超时现象并且进行处理；主节点超时处理部件202，负责判断主节点在进行广播消息时，是否发生超时现象并且进行处理，若发生超时现象，将触发后续的ViewChange协议。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述交易批量共识器300包括：Request批量封装部件301，负责将客户端发送的多条请求进行封装处理；已处理Request检测部件302，负责检测发送的请求是否有重复请求情况并且进行重复请求删除处理。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述View轮转器400包括：主节点选举部件401，能够通过轮转的方式选举一个副本节点作为主节点；旧共识消息处理部件402，负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求；View更新部件403，负责更新新一轮的View，包括处理上一轮view的请求信息和更新时段来的新请求。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述共识消息处理器500，包括：Request消息处理部件501，用于将客户端发送来的请求加上时间戳，为后面的请求处理做准备；Pre-Prepare消息处理部件502，使主节点将Pre-Prepare信息广播给副本节点，副本节点对收到的消息进行处理操作；Prepare消息处理部件503,使进入prepare阶段的副本节点发送prepare信息给其他所有节点，所有节点综合信息进行消息处理；Commit消息处理部件504,使节点广播commit信息给其他所有节点，并且根据收到的消息进行状态判断处理；Block消息处理部件505,将节点构建的区块广播给网络中的其他节点；CheckPoint消息处理部件506,负责将之前的请求信息删除，使得最后达到一种stableCheckPoint状态；ViewChange消息处理部件507,能够根据主节点自检器处理情况，按照一个view一个block的原则进行view的轮转；NewView消息处理部件508,能够通过轮转的方式产生新的view，进入下一个view阶段。

本发明实施例提供的面向复杂数字资产的多阶段PBFT共识系统，其中所述区块构建器600，包括：共识交易处理部件601，按照交易的Nonce值提交完成共识的交易；账户交易排序部件602，按照账户编码进行交易排序；区块Hash值生成部件603，通过密码学方法计算区块的hash值；OneViewOneBlock部件604，按照一个view一个block的生成效率进行区块的构建；区块校验部件605，进行区块hash值的正确性验证、主节点签名校验、区块状态校验操作；区块防分叉部件606，在每一个view中，只判定一个区块的合法性，从而防止多个区块判定产生的分叉问题。

参照图2，本发明实施例提供的面向复杂数字资产的多阶段PBFT共识方法，其中，面向复杂数字资产的多阶段PBFT共识系统的各部件处理的任务内容构成的共识消息处理流程为：

步骤A01，主节点选举，由View轮转器进行主节点(primary)选举，在一个View里，有一个主节点，其余的副本(replica)都叫做副本节点(backups)；

步骤A02，主节点批量封装Request，主节点负责将来自客户端的Request批量封装处理；

步骤A03，已处理Request检测其正确性，判断是否存在重复提交的Request，若否，进入步骤A05；

步骤A04，检测到存在重复的request，将重复的request删除；

步骤A05，Request消息处理，将这些批量封装好的Request按照序列发送给副本节点们，如果其他副本验证了Request，就将其写入自己的记录中；

步骤A06，Pre-prepare消息处理，具体操作是主节点为Request分配了一个编号，主节点广播一条Pre-Prepare信息给副本节点，直到消息达到每一个副本节点，当副本节点接受了这条Pre-Prepare消息，该节点进入prepare阶段；若副本节点在此之前接收了一条在同一view下编号相同的request，则副本节点会不认可该request消息；当大于1/3数量的节点不认可该消息，那么对该消息的处理到此结束；否则，进入下一阶段处理流程继续处理；

步骤A07，prepare消息处理，副本节点会将prepare信息广播给主节点和其他副本节点，直到信息抵达，此时该副本节点也会收到来自其他副本节点的prepare信息，该节点综合比较自身和收到的prepare信息，若满足拜占庭容错标准，即获得2f+1条确认信息(包括自己的prepare信息)，则该request在这个副本节点上的状态是prepared，这个副本节点就拥有了prepared certificate；

步骤A08，交易hash校验，新交易的内容等信息校验，若校验结果正确，进入步骤A10；

步骤A09，交易hash校验错误，验证不通过，消息作废，流程终止；

步骤A10，交易一致性校验，交易的最新资产状态、交易时间戳等信息校验，若校验结果正确，进入步骤A12；

步骤A11，交易一致性校验错误，验证不通过，消息作废，流程终止；

步骤A12，commit消息处理，节点会广播一条commit信息给其他所有节点来说明自己已经有prepare certificate了，发送commit信息的节点若收到2f+1条来自其他节点的commit信息，我们称该节点拥有了committed certificate，则称该Request在这个副本节点上的状态是committed；

步骤A13，共识消息处理，主要将交易按照Nonce值顺序进行提交；

步骤A14，账户交易排序，将提交的交易根据账户编码进行排序；

步骤A15，区块hash值生成，也即计算区块hash值；

步骤A16，区块防分叉处理，在一个view中只进行一次区块的判定；

步骤A17，OneViewOneChange，在一个view中只产生一个block；

步骤A18，区块校验正确性判定，包括区块merkel根构建的正确性、状态树构建的正确性等方面，若校验结果正确，则进入步骤20；

步骤A19，若区块校验结果不正确，那么该区块不被验证通过，则区块作废，该view的流程终止；

步骤A20，Block消息处理，将节点构建的区块广播给网络中的其他节点；

步骤A21，CheckPoint消息处理，将关于该Request的记录进行清除，为了避免删除可用信息和提高删除的效率，每隔执行K条request之后，进行一次全网广播，若返回信息显示其他副本也已执行完毕，则可清除这K条信息，判断可清除的条件是能够得到2f+1条清除信息，也就是除了节点本身外，该节点还会得到2k个清除这k条信息的同意消息，清除完成后就达到stable checkpoint的状态；

步骤A22，共识消息超时判断，当出现超时等异常情况时，主节点会自动触发viewchange协议来选举新的主节点，进入步骤A24；若没有发生超时等状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；

步骤A23，主节点超时判断，当出现超时等异常情况时，主节点会自动触发viewchange协议来选举新的主节点，进入步骤A24；若没有发生超时等状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；

步骤A22与步骤A23同时进行判断，判断结果超时或者不超时，都将进入步骤A24；

步骤A24，ViewChange消息处理，触发viewchange，进入下一个view；

步骤A25，NewView消息处理，通过轮转的方式产生新的view，进入下一个view阶段；

步骤A26，旧共识消息处理，存在一个旧共识消息处理部件专门负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求，以便在新的view中能够延续上一个view的信息；

步骤A27，View更新，NewView消息处理和旧共识消息处理汇总后，更新新一轮的View，包括处理上一轮view的请求信息以及更新过程中接受到的新请求，从而完成view更新处理。

根据本发明的面向复杂数字资产的多阶段PBFT共识系统及方法，具有以下有益效果：1.多阶段PBFT共识系统及方法，实现Request批量封装处理，大大提高了交易处理的效率；2.交易校验器的加入实现了交易一致性的校验，主要完成交易最新资产状态和交易时间戳的验证，为数字资产状态转换过程中的状态一致性提供了保障；3.加入了交易校验器、区块构建器、主节点自检器等实现了交易状态的一致性，同时加入View Change条件的判断和处理，降低了共识消息处理过程的复杂性，在一定程度上制止了意外和蓄意破坏等情况的发生；4.在PBFT的基础上进行了扩展和丰富，通过多阶段的共识系统及方法，实现更高的共识效率、更高频的实时交易处理速率；5.多阶段、分模块处理的共识系统及方法更加突显了共识系统的健壮性、安全性、可靠性。

上述内容仅为本发明创造的较佳实施例而已，不能以此限定本发明创造的实施范围，即凡是依本发明创造权利要求及发明创造说明内容所做出的简单的等效变化与修饰，皆仍属于本发明创造涵盖的范围。

Claims (7)

1.一种面向复杂数字资产的多阶段PBFT共识系统，其特征在于包括：

交易检验器100，在Commit阶段完成与交易相关的一致性、安全性校验；

主节点自检器200，在ViewChange消息处理过程中进行处理；

交易批量共识器300，负责将多笔交易批量处理；

View轮转器400，用于完成在ViewChange协议过程中的主节点的选择、新一轮view的更新以及记录上一个view信息确保新view的延续；

共识消息处理器500，通过不同阶段的共识过程实现消息在全局的一致性；

区块构建器600，能够完成与区块相关的交易提交、排序以及区块的构建、区块校验、区块防分叉保证操作；

所述共识消息处理器，包括：

Request消息处理部件，用于将客户端发送来的请求加上时间戳，为后面的请求处理做准备；

Pre-Prepare消息处理部件，使主节点将Pre-Prepare信息广播给副本节点，副本节点对收到的消息进行处理操作；Pre-prepare消息处理的具体操作是主节点为Request分配了一个编号，主节点广播一条Pre-Prepare信息给副本节点，直到消息达到每一个副本节点，当副本节点接受了这条Pre-Prepare消息，该节点进入prepare阶段；若副本节点在此之前接收了一条在同一view下编号相同的request，则副本节点会不认可该request消息；当大于1/3数量的节点不认可该消息，那么对该消息的处理到此结束；

Prepare消息处理部件,使进入prepare阶段的副本节点发送prepare信息给其他所有节点，所有节点综合信息进行消息处理；prepare消息处理的具体操作是副本节点会将prepare信息广播给主节点和其他副本节点，直到信息抵达，此时该副本节点也会收到来自其他副本节点的prepare信息，该节点综合比较自身和收到的prepare信息，若满足拜占庭容错标准，即获得2f+1条确认信息，则该request在这个副本节点上的状态是prepared，这个副本节点就拥有了prepared certificate；

Commit消息处理部件,使节点广播commit信息给其他所有节点，并且根据收到的消息进行状态判断处理；

Block消息处理部件,将节点构建的区块广播给网络中的其他节点；

CheckPoint消息处理部件,负责将之前的请求信息删除，使得最后达到一种stableCheckPoint状态；

ViewChange消息处理部件,能够根据主节点自检器处理情况，按照一个view一个block的原则进行view的轮转；

NewView消息处理部件,能够通过轮转的方式产生新的view，进入下一个view阶段。

2.根据权利要求1所述的面向复杂数字资产的多阶段PBFT共识系统，其特征在于所述交易校验器包括：

交易一致性校验部件101，校验交易的最新资产状态、交易时间戳；

交易Hash校验部件102，校验构建新交易的内容，保障内容未经篡改。

3.根据权利要求1所述的面向复杂数字资产的多阶段PBFT共识系统，其特征在于所述主节点自检器包括：

共识消息超时处理部件，负责判断消息在共识时，是否发生超时现象并且进行处理；

主节点超时处理部件，负责判断主节点在进行广播消息时，是否发生超时现象并且进行处理，若发生超时现象，将触发后续的ViewChange协议。

4.根据权利要求1所述的面向复杂数字资产的多阶段PBFT共识系统，其特征在于所述交易批量共识器包括：

Request批量封装部件，负责将客户端发送的多条请求进行封装处理；

已处理Request检测部件，负责检测发送的请求是否有重复请求情况并且进行重复请求删除处理。

5.根据权利要求1所述的面向复杂数字资产的多阶段PBFT共识系统，其特征在于所述View轮转器包括：

主节点选举部件，能够通过轮转的方式选举一个副本节点作为主节点；

旧共识消息处理部件，负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求；

View更新部件，负责更新新一轮的View，包括处理上一轮view的请求信息和更新时段来的新请求。

6.根据权利要求1所述的面向复杂数字资产的多阶段PBFT共识系统，其特征在于所述区块构建器，包括：

共识交易处理部件，按照交易的Nonce值提交完成共识的交易；

账户交易排序部件，按照账户编码进行交易排序；

区块Hash值生成部件，通过密码学方法计算区块的hash值；

OneViewOneBlock部件，按照一个view一个block的生成效率进行区块的构建；

区块校验部件，进行区块hash值的正确性验证、主节点签名校验、区块状态校验操作；

区块防分叉部件，在每一个view中，只判定一个区块的合法性，从而防止多个区块判定产生的分叉问题。

7.一种面向复杂数字资产的多阶段PBFT共识方法，其特征在于，根据权利要求1至6的任一项所述的面向复杂数字资产的多阶段PBFT共识系统的共识消息处理流程为：

步骤A01，主节点选举，由View轮转器进行主节点(primary)选举，在一个View里，有一个主节点，其余的副本(replica)都叫做副本节点(backups)；

步骤A02，主节点批量封装Request，主节点负责将来自客户端的Request批量封装处理；

步骤A03，已处理Request检测其正确性，判断是否存在重复提交的Request，若否，进入步骤A05；

步骤A04，检测到存在重复的request，将重复的request删除；

步骤A05，Request消息处理，将这些批量封装好的Request按照序列发送给副本节点们，如果其他副本验证了Request，就将其写入自己的记录中；

步骤A06，Pre-prepare消息处理，具体操作是主节点为Request分配了一个编号，主节点广播一条Pre-Prepare信息给副本节点，直到消息达到每一个副本节点，当副本节点接受了这条Pre-Prepare消息，该节点进入prepare阶段；若副本节点在此之前接收了一条在同一view下编号相同的request，则副本节点会不认可该request消息；当大于1/3数量的节点不认可该消息，那么对该消息的处理到此结束；否则，进入下一阶段处理流程继续处理；

步骤A07，prepare消息处理，副本节点会将prepare信息广播给主节点和其他副本节点，直到信息抵达，此时该副本节点也会收到来自其他副本节点的prepare信息，该节点综合比较自身和收到的prepare信息，若满足拜占庭容错标准，即获得2f+1条确认信息，则该request在这个副本节点上的状态是prepared，这个副本节点就拥有了preparedcertificate；

步骤A08，交易hash校验，新交易的内容信息校验，若校验结果正确，进入步骤A10；

步骤A09，交易hash校验错误，验证不通过，消息作废，流程终止；

步骤A10，交易一致性校验，交易的最新资产状态、交易时间戳信息校验，若校验结果正确，进入步骤A12；

步骤A11，交易一致性校验错误，验证不通过，消息作废，流程终止；

步骤A12，commit消息处理，节点会广播一条commit信息给其他所有节点来说明自己已经有prepare certificate了，发送commit信息的节点若收到2f+1条来自其他节点的commit信息，我们称该节点拥有了committed certificate，则称该Request在这个副本节点上的状态是committed；

步骤A13，共识消息处理，主要将交易按照Nonce值顺序进行提交；

步骤A14，账户交易排序，将提交的交易根据账户编码进行排序；

步骤A15，区块hash值生成，也即计算区块hash值；

步骤A16，区块防分叉处理，在一个view中只进行一次区块的判定；

步骤A17，OneViewOneChange，在一个view中只产生一个block；

步骤A18，区块校验正确性判定，包括区块merkel根构建的正确性、状态树构建的正确性方面，若校验结果正确，则进入步骤20；

步骤A19，若区块校验结果不正确，那么该区块不被验证通过，则区块作废，该view的流程终止；

步骤A20，Block消息处理，将节点构建的区块广播给网络中的其他节点；

步骤A21，CheckPoint消息处理，将关于该Request的记录进行清除，为了避免删除可用信息和提高删除的效率，每隔执行K条request之后，进行一次全网广播，若返回信息显示其他副本也已执行完毕，则可清除这K条信息，判断可清除的条件是能够得到2f+1条清除信息，也就是除了节点本身外，该节点还会得到2k个清除这k条信息的同意消息，清除完成后就达到stable checkpoint的状态；

步骤A22，共识消息超时判断，当出现超时异常情况时，主节点会自动触发view change协议来选举新的主节点，进入步骤A24；若没有发生超时状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；

步骤A23，主节点超时判断，当出现超时异常情况时，主节点会自动触发view change协议来选举新的主节点，进入步骤A24；若没有发生超时状态，根据一个View一个Block的原则同样触发ViewChange协议，进入步骤A24；

步骤A22与步骤A23同时进行判断，判断结果超时或者不超时，都将进入步骤A24；

步骤A24，ViewChange消息处理，触发viewchange，进入下一个view；

步骤A25，NewView消息处理，通过轮转的方式产生新的view，进入下一个view阶段；

步骤A26，旧共识消息处理，存在一个旧共识消息处理部件专门负责记录上一个view信息，处理上一个view还没来得及完全处理好的请求，以便在新的view中能够延续上一个view的信息；

步骤A27，View更新，NewView消息处理和旧共识消息处理汇总后，更新新一轮的View，包括处理上一轮view的请求信息以及更新过程中接受到的新请求，从而完成view更新处理。

Images