View verification method, device and electronic device in alliance chain consensus

Abstract

Provided are a view verification method, device, and electronic device in a consortium chain consensus. The method comprises the following steps: determining whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast view verification messages are identical; sorting the view verification messages broadcast by the slave replica nodes participating in the current consensus process so as to sequentially add them to the local consensus logs of the slave replica nodes that broadcast the view verification messages; parsing the view verification messages broadcast by the slave replica nodes that have participated in historical consensus processes, obtaining first message request identification codes of the slave replica nodes that have participated in historical consensus processes, and generating a first message request identification code set; obtaining second message request identification codes of the slave replica nodes that have participated in the current consensus process, and generating a second message request identification code set; and accurately determining whether the view currently participating in the consensus is consistent with the view that has participated in the historical consensus based on the first message request identification code set and the second message request identification code set.

Description

Technical Field

[0001] The present application relates to the field of alliance chain technology, and in particular to a view verification method, device and electronic device in alliance chain consensus. Background Art

[0002] Consortium blockchain technology doesn't have a central, authoritative node that manages data uniformly within the system. Each consortium chain node stores a copy of its data on disk, requiring a consensus mechanism to coordinate actions among the nodes in the consortium chain and reach agreement on blocks, ensuring consistent data across all nodes.

[0003] However, during the consensus process, one node will serve as the master replica node, and all other nodes will serve as slave replica nodes. The master replica node and the slave replica nodes are managed as views in the blockchain. During the consensus process, if the view currently participating in the consensus is inconsistent with the view of the historical consensus, there will be a huge data security risk. Summary of the Invention

[0004] Based on the above problems, the embodiments of the present application provide a view verification method, device and electronic device in alliance chain consensus.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] A view verification method in a consortium chain consensus, comprising:

[0007] Obtaining a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0008] In response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sorting the view verification messages broadcasted by the slave replica nodes participating in the current consensus process so as to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0009] Obtaining a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parsing the view verification message broadcasted by the slave replica node that has participated in the historical consensus process, and obtaining a first message request identification code of the slave replica node that has participated in the historical consensus process to generate a first message request identification code set;

[0010] Accessing the local consensus log to obtain the view verification message, so as to obtain the second message request identification code of the slave replica node participating in the current consensus process, so as to generate a second message request identification code set;

[0011] Based on the first message request identification code set and the second message request identification code set, consistency verification is performed on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing.

[0012] Furthermore, the consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing is performed based on the first message request identification code set and the second message request identification code set, including: determining the intersection of the first message request identification code set and the second message request identification code set identification code, and if the size of the intersection meets the set view Figure 1 If the consistency judgment threshold is met, it is determined that the first view of the slave replica node participating in the current consensus processing is consistent with the second view broadcast by the slave replica node that participated in the historical consensus processing. Figure 1 To.

[0013] Furthermore, determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph including a plurality of first key-value pairs, the first key-value pairs corresponding one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification code; taking out one second message request identification code from the second message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph; if they are the same, adding the second message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the second message request identification code set identification code.

[0014] Furthermore, determining the intersection of the first message request identification code set and the second message request identification code set includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes a plurality of first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification code; mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes a plurality of second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification code; determining the key-value pair intersection of the first key-value pair data graph and the second key-value pair data graph as the identification code intersection of the first message request identification code set and the second message request identification code.

[0015] Furthermore, determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph including a plurality of second key-value pairs, the second key-value pairs corresponding one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification code; taking out one first message request identification code from the first message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph, and if they are the same, adding the first message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the first message request identification code set identification code.

[0016] Furthermore, the obtaining of view verification messages broadcasted by the slave replica nodes participating in the current consensus processing in the alliance chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification messages are the same previously included: in response to the slave replica nodes participating in the current consensus processing in the alliance chain broadcasting their corresponding view verification messages, triggering the blockchain state machine to track the blockchain states of the slave replica nodes participating in the current consensus processing to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification messages are the same; the obtaining of view verification messages broadcasted by the slave replica nodes participating in historical consensus processing in the alliance chain, and parsing the view verification messages broadcasted by the slave replica nodes participating in historical consensus processing, obtaining the first message request identification code of the slave replica nodes participating in historical consensus processing to generate a first message request identification code set previously included: the blockchain states broadcasted by the slave replica nodes participating in historical consensus processing are recorded locally in the blockchain state machine.

[0017] Furthermore, the method also includes: performing a hash operation on the view verification message broadcasted from the replica node in the consortium chain that has participated in historical consensus processing according to a set first hash function to obtain a first hash value, performing a hash operation on the blockchain state broadcasted from the replica node that has participated in historical consensus processing according to a set second hash function to obtain a second hash value, and storing the first hash value and the second hash value locally in the blockchain state machine; the method also includes: performing a hash operation on the view verification message corresponding to the replica node in the consortium chain that has participated in current consensus processing according to the set first hash function to obtain a third hash value, performing a hash operation on the blockchain state of the replica node in the consortium chain that has participated in current consensus processing according to the set second hash function to obtain a fourth hash value, and storing the third hash value and the fourth hash value locally in the blockchain state machine.

[0018] Furthermore, the obtaining of the view verification message broadcasted by the slave replica nodes participating in the current consensus processing in the consortium chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same includes: locally obtaining from the blockchain state machine a second hash value corresponding to the view verification message broadcasted by the slave replica nodes participating in the current consensus processing in the consortium chain, and determining, based on the second hash value, whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same.

[0019] Furthermore, the sorting processing of the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add it in sequence to the local consensus log of the slave replica node that broadcasts the view verification message includes: sorting the first hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add the first hash value corresponding to the broadcast view verification message to the local consensus log of the slave replica node in sequence.

[0020] Furthermore, the method obtains the view verification message broadcasted by the slave replica node that has participated in the historical consensus processing in the alliance chain, and parses the view verification message broadcasted by the slave replica node that has participated in the historical consensus processing, and obtains the first message request identification code of the slave replica node that has participated in the historical consensus processing to generate a first message request identification code set, including: obtaining the third hash value corresponding to the view verification message broadcasted by the slave replica node that has participated in the current consensus processing in the alliance chain, and equating the third hash value to the first message request identification code of the corresponding slave replica node to generate a first message request identification code set.

[0021] Furthermore, the method also includes: comparing the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing with the fourth hash value corresponding to the blockchain state of the slave replica node participating in the current consensus processing in the alliance chain, and reviewing the verification conclusion data obtained by consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0022] Furthermore, the first hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the historical consensus process in the alliance chain is used as the key of the third key-value pair, and the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus process is used as the value of the third key-value pair, and the third key-value pair is stored locally in the blockchain state machine; the third hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the current consensus process in the alliance chain is used as the key of the fourth key-value pair, and the fourth hash value corresponding to the blockchain state of the slave replica node that has participated in the current consensus process in the alliance chain is used as the value of the fourth key-value pair, and the fourth key-value pair is stored locally in the blockchain state machine.

[0023] A view verification device in a consortium chain consensus, comprising:

[0024] The first program unit is configured to obtain a view verification message broadcasted by a slave replica node participating in a current consensus process in the consortium chain, to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0025] a second program unit configured to, in response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sort the view verification messages broadcasted by the slave replica nodes participating in the current consensus process, so as to sequentially add the view verification messages to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0026] A third program unit is configured to obtain view verification messages broadcasted by slave replica nodes that have participated in historical consensus processing in the consortium chain, parse the view verification messages broadcasted by the slave replica nodes that have participated in historical consensus processing, and obtain the first message request identification codes of the slave replica nodes that have participated in historical consensus processing to generate a first message request identification code set;

[0027] a fourth program unit, configured to access the local consensus log to obtain the view verification message, so as to obtain therefrom the second message request identification code of the slave replica node participating in the current consensus processing, so as to generate a second message request identification code set;

[0028] The fifth program unit is used to verify the consistency of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0029] Furthermore, the fifth program unit is further used to: determine the intersection of the first message request identification code set and the second message request identification code set identification code, if the size of the intersection meets the set view Figure 1 If the consistency judgment threshold is met, it is determined that the first view of the slave replica node participating in the current consensus processing is consistent with the second view broadcast by the slave replica node that participated in the historical consensus processing. Figure 1 To.

[0030] Furthermore, the fifth program unit is further used to: map the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes several first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification code, and the key and value in the first key-value pairs both correspond to the first message request identification code; take out one second message request identification code from the second message request identification code set one by one to compare with the key and value of each first key-value pair on the first key-value pair data graph, if they are the same, then add the second message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the second message request identification code set identification code.

[0031] Furthermore, the fifth program unit is further used to: map the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes several first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification codes, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification codes; map the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes several second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification codes, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification codes; determine the key-value pair intersection of the first key-value pair data graph and the second key-value pair data graph as the identification code intersection of the first message request identification code set and the second message request identification code.

[0032] Furthermore, the fifth program unit is further used to: map the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes a plurality of second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification codes, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification codes; take out one first message request identification code from the first message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph, and if they are the same, add the first message request identification code to the intersection graph as a constituent element of the first message request identification code set and the intersection of the first message request identification code set identification codes.

[0033] Furthermore, the first program unit is further used to: in response to the slave replica node participating in the current consensus process in the alliance chain broadcasting its corresponding view verification message, trigger the blockchain state machine to track the blockchain state of the slave replica node participating in the current consensus process, so as to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same; the third program unit is further used to: record the blockchain state broadcast by the slave replica node that has participated in the historical consensus process locally in the blockchain state machine.

[0034] Furthermore, the device also includes: a first consensus processing unit, which is used to perform a hash operation on the view verification message broadcasted by the slave replica node that has participated in the historical consensus processing in the alliance chain according to a set first hash function to obtain a first hash value, and perform a hash operation on the blockchain state broadcasted by the slave replica node that has participated in the historical consensus processing according to a set second hash function to obtain a second hash value, and store the first hash value and the second hash value locally in the blockchain state machine; the device also includes: a second consensus processing unit, which is used to perform a hash operation on the view verification message corresponding to the slave replica node that has participated in the current consensus processing in the alliance chain according to the set first hash function to obtain a third hash value, and perform a hash operation on the blockchain state of the slave replica node that has participated in the current consensus processing in the alliance chain according to the set second hash function to obtain a fourth hash value, and store the third hash value and the fourth hash value locally in the blockchain state machine.

[0035] Furthermore, the first program unit is further used to: obtain from the blockchain state machine locally a second hash value corresponding to the view verification message broadcast by the slave replica node participating in the current consensus processing in the alliance chain, and based on the second hash value, determine whether the blockchain states of all slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same.

[0036] Furthermore, the second program unit is further used to: sort the first hash values ​​corresponding to the view verification messages broadcast by the slave replica nodes participating in the current consensus processing, so as to add the first hash values ​​corresponding to the broadcast view verification messages to the local consensus log of the slave replica nodes in sequence.

[0037] Furthermore, the third program unit is further used to: obtain a third hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing in the alliance chain, and equate the third hash value to the first message request identification code of the corresponding slave replica node to generate a first message request identification code set.

[0038] Furthermore, the device also includes: a third consensus processing unit, which is used to compare the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing with the fourth hash value corresponding to the blockchain state of the slave replica node participating in the current consensus processing in the alliance chain, and review the verification conclusion data obtained by consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0039] Furthermore, the first consensus processing unit is further used to: use the first hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the historical consensus processing in the alliance chain as the key of the third key-value pair, and the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing as the value of the third key-value pair, and store the third key-value pair locally in the blockchain state machine; the second consensus processing unit is further used to: use the third hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the current consensus processing in the alliance chain as the key of the fourth key-value pair, and the fourth hash value corresponding to the blockchain state of the slave replica node that has participated in the current consensus processing in the alliance chain as the value of the fourth key-value pair, and store the fourth key-value pair locally in the blockchain state machine.

[0040] An electronic device includes a memory and a processor, wherein the memory stores an executable program, and the processor performs the following steps when running the executable program:

[0041] Obtaining a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0042] In response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sorting the view verification messages broadcasted by the slave replica nodes participating in the current consensus process so as to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0043] Obtaining a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parsing the view verification message broadcasted by the slave replica node that has participated in the historical consensus process, and obtaining a first message request identification code of the slave replica node that has participated in the historical consensus process to generate a first message request identification code set;

[0044] Accessing the local consensus log to obtain the view verification message, so as to obtain the second message request identification code of the slave replica node participating in the current consensus process, so as to generate a second message request identification code set;

[0045] Based on the first message request identification code set and the second message request identification code set, consistency verification is performed on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing.

[0046] In the technical solution of the embodiment of the present application, by obtaining the view verification message broadcasted by the slave replica node participating in the current consensus process in the alliance chain, it is determined whether the blockchain states of all the slave replica nodes participating in the current consensus process that broadcast the view verification message are the same; in response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, the view verification messages broadcasted by the slave replica nodes participating in the current consensus process are sorted and added in sequence to the local consensus log of the slave replica node that broadcasts the view verification message; the view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus process in the alliance chain are obtained, and the view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus process are sorted. Perform parsing to obtain the first message request identification code of the slave replica node that has participated in the historical consensus processing to generate a first message request identification code set; access the local consensus log to obtain the view verification message to obtain the second message request identification code of the slave replica node participating in the current consensus processing to generate a second message request identification code set; based on the first message request identification code set and the second message request identification code set, perform consistency verification on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing, accurately judge whether the view currently participating in the consensus is consistent with the view historically participating in the consensus, so as to avoid data security risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0048] Figure 1 This is a flowchart of a view verification method in a consortium chain consensus according to an embodiment of the present application;

[0049] Figure 2 This is a structural diagram of a view verification device in a consortium chain consensus according to an embodiment of the present application;

[0050] Figure 3 This is a structural diagram of a view verification device in a consortium chain consensus according to an embodiment of the present application;

[0051] Figure 4 This is a schematic diagram of the structure of an electronic device in an embodiment of the present application;

[0052] Figure 5 Schematic diagram of the hardware structure of the electronic device in the embodiment of the present application. DETAILED DESCRIPTION

[0053] The implementation of any technical solution in the embodiments of the present application does not necessarily require achieving all of the above advantages at the same time.

[0054] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0055] In the technical solution of the embodiment of the present application, by obtaining the view verification message broadcasted by the slave replica node participating in the current consensus process in the alliance chain, it is determined whether the blockchain states of all the slave replica nodes participating in the current consensus process that broadcast the view verification message are the same; in response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, the view verification messages broadcasted by the slave replica nodes participating in the current consensus process are sorted and added in sequence to the local consensus log of the slave replica node that broadcasts the view verification message; the view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus process in the alliance chain are obtained, and the view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus process are sorted. Perform parsing to obtain the first message request identification code of the slave replica node that has participated in the historical consensus processing to generate a first message request identification code set; access the local consensus log to obtain the view verification message to obtain the second message request identification code of the slave replica node participating in the current consensus processing to generate a second message request identification code set; based on the first message request identification code set and the second message request identification code set, perform consistency verification on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing, accurately judge whether the view currently participating in the consensus is consistent with the view historically participating in the consensus, so as to avoid data security risks.

[0056] Figure 1 This is a flow chart of a view verification method in a consortium chain consensus according to an embodiment of the present application; Figure 1 As shown, it includes:

[0057] S101: Obtain a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0058] S102: In response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sorting the view verification messages broadcasted by the slave replica nodes participating in the current consensus process to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0059] S103: Obtain a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parse the view verification message broadcasted by the slave replica node that has participated in the historical consensus process, and obtain a first message request identification code of the slave replica node that has participated in the historical consensus process to generate a first message request identification code set;

[0060] S104: Access the local consensus log to obtain the view verification message, so as to obtain the second message request identification code of the slave replica node participating in the current consensus process, so as to generate a second message request identification code set;

[0061] S105. Perform consistency verification on the first view of the slave replica node participating in the current consensus process and the second view broadcast by the slave replica node that participated in the historical consensus process based on the first message request identification code set and the second message request identification code set.

[0062] Optionally, the consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that participated in the historical consensus processing is performed based on the first message request identification code set and the second message request identification code set, including: determining the intersection of the first message request identification code set and the second message request identification code set identification code, and if the size of the intersection meets the set view Figure 1 If the consistency judgment threshold is met, it is determined that the first view of the slave replica node participating in the current consensus processing is consistent with the second view broadcast by the slave replica node that participated in the historical consensus processing. Figure 1 This avoids the noise influence of other interference factors on the judgment and ensures the accuracy of the judgment.

[0063] Optionally, determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph including a plurality of first key-value pairs, the first key-value pairs corresponding one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification code; taking out the second message request identification code one by one from the second message request identification code set to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph; if they are the same, adding the second message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the second message request identification code set identification code.

[0064] By using the first key-value pair, the simplicity of the algorithm design is ensured, so as to quickly determine the intersection of the first message request identification code set and the second message request identification code set.

[0065] Optionally, determining the intersection of the first message request identification code set and the second message request identification code set includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes a plurality of first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification code; mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes a plurality of second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification code; determining the key-value pair intersection of the first key-value pair data graph and the second key-value pair data graph as the identification code intersection of the first message request identification code set and the second message request identification code.

[0066] By mapping the second message request identification code set to the second key-value pair data graph, the efficiency of determining the intersection of the first message request identification code set and the second message request identification code set is improved, while the accuracy of the intersection is ensured.

[0067] Optionally, determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph including a plurality of second key-value pairs, the second key-value pairs corresponding one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification code; taking out one first message request identification code from the first message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph, and if they are the same, adding the first message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the first message request identification code set identification code.

[0068] The first message request identification code is saved in the manner of the above-mentioned graph, which facilitates the efficiency of data calling when the algorithm is executed, and avoids possible errors in data calling.

[0069] Optionally, the obtaining of view verification messages broadcasted by the slave replica nodes participating in the current consensus processing in the alliance chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification messages are the same previously includes: in response to the slave replica nodes participating in the current consensus processing in the alliance chain broadcasting their corresponding view verification messages, triggering the blockchain state machine to track the blockchain states of the slave replica nodes participating in the current consensus processing to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification messages are the same; the obtaining of view verification messages broadcasted by the slave replica nodes participating in historical consensus processing in the alliance chain, and parsing the view verification messages broadcasted by the slave replica nodes participating in historical consensus processing to obtain the first message request identification code of the slave replica nodes participating in historical consensus processing to generate a first message request identification code set previously includes: the blockchain states broadcasted by the slave replica nodes participating in historical consensus processing are recorded locally in the blockchain state machine.

[0070] In this embodiment, the blockchain state machine can track the blockchain state of the slave replica nodes participating in the current consensus process in real time, thereby avoiding errors in determining whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same due to omission of the blockchain state.

[0071] Optionally, the method also includes: performing a hash operation on the view verification message broadcasted from the replica node in the consortium chain that has participated in historical consensus processing according to a set first hash function to obtain a first hash value, performing a hash operation on the blockchain state broadcasted from the replica node that has participated in historical consensus processing according to a set second hash function to obtain a second hash value, and storing the first hash value and the second hash value locally in the blockchain state machine; the method also includes: performing a hash operation on the view verification message corresponding to the replica node in the consortium chain that has participated in current consensus processing according to the set first hash function to obtain a third hash value, performing a hash operation on the blockchain state of the replica node in the consortium chain that has participated in current consensus processing according to the set second hash function to obtain a fourth hash value, and storing the third hash value and the fourth hash value locally in the blockchain state machine.

[0072] In this embodiment, the above hash operation is used to ensure data security.

[0073] Preferably, the first hash function and the second hash function are different hash functions to further enhance data security.

[0074] Optionally, obtaining the view verification message broadcasted by the slave replica node participating in the current consensus processing in the consortium chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same includes: locally obtaining from the blockchain state machine a second hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing in the consortium chain, and judging, based on the second hash value, whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same.

[0075] In this embodiment, the second hash value is obtained locally, which improves the efficiency of data interaction and ensures data security.

[0076] Optionally, the sorting processing of the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add it in sequence to the local consensus log of the slave replica node that broadcasts the view verification message includes: sorting the first hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add the first hash value corresponding to the broadcast view verification message in sequence to the local consensus log of the slave replica node.

[0077] In this embodiment, the first Hash values ​​are sorted to ensure orderliness of the first Hash values ​​and avoid data processing conflicts.

[0078] Optionally, the obtaining of view verification messages broadcasted by the slave replica nodes that have participated in historical consensus processing in the alliance chain, and parsing of the view verification messages broadcasted by the slave replica nodes that have participated in historical consensus processing, and obtaining therefrom the first message request identification code of the slave replica nodes that have participated in historical consensus processing to generate a first message request identification code set, includes: obtaining a third hash value corresponding to the view verification message broadcasted by the slave replica nodes that have participated in current consensus processing in the alliance chain, and equating the third hash value to the first message request identification code of the corresponding slave replica node to generate a first message request identification code set.

[0079] In this embodiment, the security of data processing is guaranteed by the third hash value.

[0080] Optionally, the method also includes: comparing the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing with the fourth hash value corresponding to the blockchain state of the slave replica node participating in the current consensus processing in the alliance chain, and reviewing the verification conclusion data obtained by consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0081] In this embodiment, by comparing hash values, the security of data processing is ensured while the efficiency of data processing is ensured.

[0082] Optionally, the first hash value corresponding to the view verification message broadcasted by the slave replica node that has participated in historical consensus processing in the alliance chain is used as the key of the third key-value pair, and the second hash value corresponding to the blockchain state broadcasted by the slave replica node that has participated in historical consensus processing is used as the value of the third key-value pair, and the third key-value pair is stored locally in the blockchain state machine; the third hash value corresponding to the view verification message broadcasted by the slave replica node that has participated in the current consensus processing in the alliance chain is used as the key of the fourth key-value pair, and the fourth hash value corresponding to the blockchain state of the slave replica node that has participated in the current consensus processing in the alliance chain is used as the value of the fourth key-value pair, and the fourth key-value pair is stored locally in the blockchain state machine.

[0083] In this embodiment, the key-value pair method is used to reduce the space requirement for data storage while ensuring the efficiency of comparison.

[0084] Figure 2 This is a structural diagram of a view verification device in a consortium chain consensus according to an embodiment of the present application; Figure 2 As shown, it includes:

[0085] The first program unit 201 is configured to obtain a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain, to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0086] The second program unit 202 is configured to, in response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sort the view verification messages broadcasted by the slave replica nodes participating in the current consensus process, so as to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0087] The third program unit 203 is configured to obtain a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parse the view verification message broadcasted by the slave replica node that has participated in a historical consensus process, and obtain a first message request identification code of the slave replica node that has participated in a historical consensus process to generate a first message request identification code set;

[0088] The fourth program unit 204 is configured to access the local consensus log to obtain the view verification message, thereby obtaining the second message request identification code of the slave replica node participating in the current consensus process, and generating a second message request identification code set;

[0089] The fifth program unit 205 is used to verify the consistency of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0090] Optionally, the fifth program unit 205 is further configured to: determine the intersection of the first message request identification code set and the second message request identification code set, and if the size of the intersection meets the set visual Figure 1 If the consistency judgment threshold is met, it is determined that the first view of the slave replica node participating in the current consensus processing is consistent with the second view broadcast by the slave replica node that participated in the historical consensus processing. Figure 1 To.

[0091] Optionally, the fifth program unit 205 is further used to: map the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph including a plurality of first key-value pairs, the first key-value pairs corresponding one-to-one to the first message request identification code, and the key and value in the first key-value pairs both correspond to the first message request identification code; take out one second message request identification code from the second message request identification code set one by one to compare with the key and value of each first key-value pair on the first key-value pair data graph; if they are the same, add the second message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the second message request identification code set identification code.

[0092] Optionally, the fifth program unit 205 is further used to: map the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes several first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification codes, and the keys and values ​​in the first key-value pairs both correspond to the first message request identification codes; map the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes several second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification codes, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification codes; determine the key-value pair intersection of the first key-value pair data graph and the second key-value pair data graph as the identification code intersection of the first message request identification code set and the second message request identification code.

[0093] Optionally, the fifth program unit 205 is further used to: map the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes a plurality of second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification codes, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification codes; take out one first message request identification code from the first message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph; if they are the same, add the first message request identification code to the intersection graph as a constituent element of the first message request identification code set and the intersection of the first message request identification code set identification codes.

[0094] Optionally, the first program unit 201 is further used to: in response to the slave replica node participating in the current consensus process in the alliance chain broadcasting its corresponding view verification message, trigger the blockchain state machine to track the blockchain state of the slave replica node participating in the current consensus process, so as to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same; the third program unit 203 is further used to: record the blockchain state broadcast by the slave replica node that has participated in the historical consensus process locally in the blockchain state machine.

[0095] Figure 3 This is a structural diagram of a view verification device in a consortium chain consensus according to an embodiment of the present application; Figure 3 As shown in the above Figure 2 Based on the embodiment, it also has the following characteristics:

[0096] Optionally, the device also includes: a first consensus processing unit 206, which is used to perform a hash operation on the view verification message broadcasted by the replica node in the alliance chain that has participated in historical consensus processing according to a set first hash function to obtain a first hash value, and perform a hash operation on the blockchain state broadcasted by the replica node that has participated in historical consensus processing according to a set second hash function to obtain a second hash value, and store the first hash value and the second hash value locally in the blockchain state machine; the device also includes: a second consensus processing unit 207, which is used to perform a hash operation on the view verification message corresponding to the replica node in the alliance chain that has participated in current consensus processing according to the set first hash function to obtain a third hash value, and perform a hash operation on the blockchain state of the replica node in the alliance chain that has participated in current consensus processing according to the set second hash function to obtain a fourth hash value, and store the third hash value and the fourth hash value locally in the blockchain state machine.

[0097] Optionally, the first program unit 201 is further used to: obtain from the blockchain state machine locally a second hash value corresponding to the view verification message broadcast by the slave replica node participating in the current consensus process in the consortium chain, and determine, based on the second hash value, whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same.

[0098] Optionally, the second program unit 202 is further used to: sort the first hash values ​​corresponding to the view verification messages broadcast by the slave replica nodes participating in the current consensus processing, so as to add the first hash values ​​corresponding to the broadcast view verification messages to the local consensus log of the slave replica nodes in sequence.

[0099] Optionally, the third program unit 203 is further used to: obtain a third hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing in the alliance chain, and equate the third hash value to the first message request identification code of the corresponding slave replica node to generate a first message request identification code set.

[0100] Optionally, the device also includes: a third consensus processing unit 208, which is used to compare the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing with the fourth hash value corresponding to the blockchain state of the slave replica node participating in the current consensus processing in the alliance chain, and review the verification conclusion data obtained by consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing based on the first message request identification code set and the second message request identification code set.

[0101] Optionally, the first consensus processing unit 206 is further used to: use the first hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the historical consensus processing in the alliance chain as the key of a third key-value pair, and the second hash value corresponding to the blockchain state broadcast by the slave replica node that has participated in the historical consensus processing as the value of the third key-value pair, and store the third key-value pair locally in the blockchain state machine; the second consensus processing unit 207 is further used to: use the third hash value corresponding to the view verification message broadcast by the slave replica node that has participated in the current consensus processing in the alliance chain as the key of a fourth key-value pair, and the fourth hash value corresponding to the blockchain state of the slave replica node that has participated in the current consensus processing in the alliance chain as the value of the fourth key-value pair, and store the fourth key-value pair locally in the blockchain state machine.

[0102] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application; Figure 4 As shown, it includes a memory 301 and a processor 302. The memory stores an executable program. When the processor runs the executable program, the following steps are performed:

[0103] Obtaining a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same;

[0104] In response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sorting the view verification messages broadcasted by the slave replica nodes participating in the current consensus process so as to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages;

[0105] Obtaining a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parsing the view verification message broadcasted by the slave replica node that has participated in the historical consensus process, and obtaining a first message request identification code of the slave replica node that has participated in the historical consensus process to generate a first message request identification code set;

[0106] Access the local consensus log to obtain the view verification message, so as to obtain the second message request identification code of the slave replica node participating in the current consensus process, so as to generate a second message request identification code set

[0107] Based on the first message request identification code set and the second message request identification code set, consistency verification is performed on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing.

[0108] Figure 5 Schematic diagram of the hardware structure of the electronic device in the embodiment of the present application; Figure 5 As shown, the hardware structure of the electronic device may include: the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. Various programs and data required for the operation of the device 400 can also be stored in the RAM 403. The computing unit 401, ROM 402, and RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0109] Multiple components within electronic device 400 are connected to I / O interface 405, including an input unit 406, an output unit 407, a storage unit 408, and a communication unit 409. Input unit 406 can be any type of device capable of inputting information into electronic device 400. Input unit 406 can receive input numeric or character information and generate key input signals related to user settings and / or function control of the electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. Storage unit 408 may include, but is not limited to, a magnetic disk or an optical disk. Communication unit 409 allows electronic device 400 to exchange information / data with other devices via computer networks such as the Internet and / or various telecommunication networks and may include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver and / or a chipset, such as a Bluetooth™ device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0110] The computing unit 401 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 401 performs the various methods and processes described above. For example, in some embodiments, the above steps may be implemented as a computer software program that is tangibly included in a machine-readable medium, such as a storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 400 via the ROM 402 and / or the communication unit 409. In some embodiments, the computing unit 401 may be configured to perform the above steps in any other appropriate manner (e.g., by means of firmware).

[0111] The electronic devices of the embodiments of the present application exist in various forms, including but not limited to:

[0112] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and are primarily designed to provide voice and data communications. These terminals include smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones.

[0113] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0114] (3) Portable entertainment devices: These devices can display and play multimedia content. These devices include audio and video players (such as iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0115] (4) Server: A device that provides computing services. The server consists of a processor 410, a hard disk, memory, a system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0116] (5) Other electronic devices with data interaction functions.

[0117] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, wherein the modules described as separate components may or may not be physically separated, and the components indicated as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0118] The above is merely one specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A view verification method in alliance chain consensus, characterized by: include: Obtaining a view verification message broadcasted by a slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all slave replica nodes participating in the current consensus process that broadcast the view verification message are the same; In response to the blockchain states of all the slave replica nodes participating in the current consensus process being the same, sorting the view verification messages broadcasted by the slave replica nodes participating in the current consensus process so as to sequentially add them to the local consensus logs of the slave replica nodes broadcasting the view verification messages; Obtaining a view verification message broadcasted by a slave replica node that has participated in a historical consensus process in the consortium chain, parsing the view verification message broadcasted by the slave replica node that has participated in the historical consensus process, and obtaining a first message request identification code of the slave replica node that has participated in the historical consensus process to generate a first message request identification code set; Accessing the local consensus log to obtain the view verification message, so as to obtain the second message request identification code of the slave replica node participating in the current consensus process, so as to generate a second message request identification code set; Based on the first message request identification code set and the second message request identification code set, consistency verification is performed on the first view where the slave replica node participating in the current consensus processing is located and the second view broadcast by the slave replica node that has participated in the historical consensus processing.

2. The view verification method in the alliance chain consensus according to claim 1 is characterized in that: The consistency verification of the first view of the slave replica node participating in the current consensus processing and the second view broadcast by the slave replica node that has participated in the historical consensus processing is performed based on the first message request identification code set and the second message request identification code set, including: determining the intersection of the first message request identification code set and the second message request identification code set identification code, if the size of the intersection meets the set view consistency judgment threshold, then determining that the first view of the slave replica node participating in the current consensus processing is consistent with the second view broadcast by the slave replica node that has participated in the historical consensus processing.

3. The view verification method in the alliance chain consensus according to claim 2 is characterized in that: The method of determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph including a plurality of first key-value pairs, the first key-value pairs corresponding one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs all correspond to the first message request identification code; taking out one second message request identification code from the second message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph, and if they are the same, adding the second message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the second message request identification code set identification code.

4. The view verification method in the alliance chain consensus according to claim 2 is characterized in that: The determining of the intersection of the first message request identification code set and the second message request identification code set includes: mapping the first message request identification code set to a first key-value pair data graph, the first key-value pair data graph includes a plurality of first key-value pairs, the first key-value pairs correspond one-to-one to the first message request identification code, and the keys and values ​​in the first key-value pairs all correspond to the first message request identification code; mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph includes a plurality of second key-value pairs, the second key-value pairs correspond one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs all correspond to the second message request identification code; determining the key-value pair intersection of the first key-value pair data graph and the second key-value pair data graph as the identification code intersection of the first message request identification code set and the second message request identification code.

5. The view verification method in the alliance chain consensus according to claim 2 is characterized in that: The method of determining the intersection of the first message request identification code set and the second message request identification code set identification code includes: mapping the second message request identification code set to a second key-value pair data graph, the second key-value pair data graph including a plurality of second key-value pairs, the second key-value pairs corresponding one-to-one to the second message request identification code, and the keys and values ​​in the second key-value pairs both correspond to the second message request identification code; taking out one first message request identification code from the first message request identification code set one by one to compare with the keys and values ​​of each first key-value pair on the first key-value pair data graph, and if they are the same, adding the first message request identification code to the intersection graph as a constituent element of the intersection of the first message request identification code set and the first message request identification code set identification code.

6. The view verification method in the alliance chain consensus according to claim 1 is characterized in that: The method of obtaining the view verification message broadcasted by the slave replica node participating in the current consensus processing in the alliance chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same previously includes: in response to the slave replica node participating in the current consensus processing in the alliance chain broadcasting its corresponding view verification message, triggering the blockchain state machine to track the blockchain state of the slave replica node participating in the current consensus processing to determine whether the blockchain states of all the slave replica nodes participating in the current consensus processing that broadcast the view verification message are the same; the method of obtaining the view verification message broadcasted by the slave replica node participating in the historical consensus processing in the alliance chain, and parsing the view verification message broadcasted by the slave replica node participating in the historical consensus processing to obtain the first message request identification code of the slave replica node participating in the historical consensus processing to generate a first message request identification code set previously includes: the blockchain state broadcasted by the slave replica node participating in the historical consensus processing is recorded locally in the blockchain state machine.

7. The view verification method in the alliance chain consensus according to claim 6 is characterized in that: The method also includes: performing a hash operation on the view verification message broadcasted by the slave replica node in the consortium chain that has participated in the historical consensus process according to a set first hash function to obtain a first hash value, performing a hash operation on the blockchain state broadcasted by the slave replica node that has participated in the historical consensus process according to a set second hash function to obtain a second hash value, and storing the first hash value and the second hash value locally in the blockchain state machine; the method also includes: performing a hash operation on the view verification message corresponding to the slave replica node in the consortium chain that has participated in the current consensus process according to the set first hash function to obtain a third hash value, performing a hash operation on the blockchain state of the slave replica node in the consortium chain that has participated in the current consensus process according to the set second hash function to obtain a fourth hash value, and storing the third hash value and the fourth hash value locally in the blockchain state machine.

8. The view verification method in the alliance chain consensus according to claim 7 is characterized in that: The obtaining of the view verification message broadcasted by the slave replica node participating in the current consensus process in the consortium chain to determine whether the blockchain states of all the slave replica nodes participating in the current consensus process that broadcast the view verification message are the same includes: locally obtaining from the blockchain state machine a second hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus process in the consortium chain, and determining, based on the second hash value, whether the blockchain states of all the slave replica nodes participating in the current consensus process that broadcast the view verification message are the same.

9. The view verification method in the alliance chain consensus according to claim 7 is characterized in that: The sorting processing of the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add it in sequence to the local consensus log of the slave replica node that broadcasts the view verification message includes: sorting the first hash value corresponding to the view verification message broadcasted by the slave replica node participating in the current consensus processing so as to add it in sequence to the local consensus log of the slave replica node that broadcasts the view verification message.

10. The view verification method in the alliance chain consensus according to claim 7 is characterized in that: The obtaining of view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus processing in the alliance chain, and parsing of the view verification messages broadcasted by the slave replica nodes that have participated in the historical consensus processing, and obtaining the first message request identification code of the slave replica nodes that have participated in the historical consensus processing to generate a first message request identification code set, includes: obtaining a third hash value corresponding to the view verification message broadcasted by the slave replica nodes that have participated in the current consensus processing in the alliance chain, and equating the third hash value to the first message request identification code of the corresponding slave replica node to generate a first message request identification code set.

Images