View processing method and apparatus in consortium chain, and electronic device

Abstract

The application discloses a view processing method and device in a consortium chain and electronic equipment. In response to a main replica node participating in consensus processing in the consortium chain being in a state of responding to a consensus request timeout, each slave replica node participating in consensus processing in the consortium chain generates a view switching request and broadcasts the view switching request in the consortium chain. A replica node not participating in consensus processing in the consortium chain receives the view switching request broadcast by each slave replica node participating in consensus processing to generate a view switching message, and multiple other replica nodes not participating in consensus processing generate view switching messages to form a view switching opening proof. The main replica node participating in consensus processing in the consortium chain verifies the legitimacy of the view switching opening proof, and in response to the view switching opening proof being legitimate, sends the view switching opening proof to a new main replica node, so that the new main replica node replaces the main replica node in the state of responding to the consensus request timeout to perform view switching, so that the new main replica node and the replica nodes participating in consensus processing are located in the same view.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of alliance chain, in particular to a view processing method and device in an alliance chain and an electronic device. BACKGROUND

[0002] There is no authoritative central node in the alliance chain technology to uniformly manage the data in the system. The data in the alliance chain is stored in a copy on the disk of each alliance chain node, which requires a mechanism to coordinate the actions of the nodes in the alliance chain through consensus processing to reach an agreement on the block and ensure the consistency of the data of each node.

[0003] However, in the consensus process, one node acts as a primary replica node, and all other nodes act as secondary replica nodes. The primary replica node and the secondary replica node are managed as a view in the blockchain. When the primary replica node has a consensus timeout, a view error occurs. SUMMARY

[0004] To solve the above problems, the present application provides a view processing method, device and electronic device in an alliance chain.

[0005] The present application discloses the following technical solutions:

[0006] A view processing method in an alliance chain, comprising:

[0007] In response to a primary replica node participating in consensus processing in the alliance chain responding to a consensus request timeout, each secondary replica node participating in consensus processing in the alliance chain generates a view switching request and broadcasts it in the alliance chain;

[0008] Each secondary replica node participating in consensus processing in the alliance chain receives the view switching request broadcast by the secondary replica node to generate a view switching message, and the view switching messages generated by multiple other secondary replica nodes participating in consensus processing are assembled to form a view switching opening proof;

[0009] The primary replica node participating in consensus processing in the alliance chain verifies the legitimacy of the view switching opening proof, and in response to the view switching opening proof being legitimate, sends the view switching opening proof to a new primary replica node, so that the new primary replica node replaces the primary replica node that responds to the consensus request timeout to perform view switching, so that the new primary replica node and the secondary replica node participating in consensus processing are in the same view.

[0010] Optionally, before the responding to the timeout of the primary replica node in the consortium chain participating in the consensus processing, the method further comprises: determining the timeout of the primary replica node in the consortium chain participating in the consensus processing according to the response consensus request timeout challenge proof generated by the secondary replica node in the consortium chain participating in the consensus processing and the response consensus request stability proof generated by the secondary replica node in the consortium chain not participating in the consensus processing.

[0011] Optionally, before the responding to the timeout of the primary replica node in the consortium chain participating in the consensus processing, the method further comprises: polling the challenge messages of the timeout of the primary replica node responding to the consensus request sent by the secondary replica node in the view participating in the consensus processing, each secondary replica node sending the challenge message has a first sequence identifier, and all the challenge messages are spliced into a response consensus request timeout challenge proof in the order of the first sequence identifier of the corresponding secondary replica node.

[0012] Optionally, before the responding to the timeout of the primary replica node in the consortium chain participating in the consensus processing, the method further comprises: polling the stability messages of the primary replica node responding to the consensus request sent by the secondary replica node in the view not participating in the consensus processing, each secondary replica node sending the stability message has a second sequence identifier, and all the stability messages are spliced into a response consensus request stability proof in the order of the second sequence identifier of the corresponding secondary replica node.

[0013] Optionally, before the responding to the timeout of the primary replica node in the consortium chain participating in the consensus processing, the method further comprises: obtaining the consensus state recorded in the consensus state machine in the consortium chain, and determining a plurality of secondary replica nodes with the same consensus state as the secondary replica nodes participating in the consensus processing based on the consensus state.

[0014] Optionally, the first sequence identifier is generated in the following manner: for each secondary replica node of the plurality of secondary replica nodes with the same consensus state, determining its consensus timestamp; based on the consensus timestamp, generating a first random number and assigning the first random number to the secondary replica node as the sequence identifier.

[0015] Optionally, the method further comprises: generating a challenge message digest for each challenge message and combining the sequence identifier of the secondary replica node sending the challenge message into a key-value pair; and splicing all the challenge messages into a response consensus request timeout challenge proof in the order of the first sequence identifier of the corresponding secondary replica node, which comprises: based on the key-value, splicing all the challenge messages into a response consensus request timeout challenge proof in the order of the sequence identifier of the secondary replica node sending the challenge message.

[0016] Optionally, a challenge message broadcast queue is established based on the sequence identifier of the slave copy node broadcasting the challenge message, and the key-value pair is projected onto the challenge message broadcast queue, so as to dynamically maintain the challenge message broadcast queue according to the key-value pair.

[0017] Optionally, the method further comprises: generating an acknowledgement message digest for each of the acknowledgement messages, and combining the acknowledgement message digest with the sequence identifier of the slave copy node broadcasting the acknowledgement message into a key-value pair; and splicing all the stability messages into a response consensus request stability proof in the order of the second sequence identifier of the corresponding slave copy node, including: based on the key-value, splicing all the stability messages into a stability proof in the order of the second sequence identifier of the slave copy node sending the stability message.

[0018] Optionally, the method further comprises: establishing a stability message broadcast queue based on the sequence identifier of the slave copy node sending the acknowledgement message, and projecting the key-value pair onto the stability message broadcast queue, so as to dynamically maintain the stability message broadcast queue according to the key-value pair.

[0019] Optionally, the challenge message carries an identity code of the primary copy node, so that when all the challenge messages are spliced into a response consensus request timeout challenge proof in the order of the sequence identifier of the slave copy node sending the challenge message, the identity code included in the challenge message is separated and processed, so that the response consensus request timeout challenge proof includes an identity code.

[0020] Optionally, judging that the primary copy node in the alliance chain participating in the consensus processing is actually in response consensus request timeout based on the response consensus request timeout challenge proof generated by the slave copy node participating in the consensus processing in the alliance chain and the response consensus request stability proof generated by the copy node not participating in the consensus processing in the alliance chain, including: loading the challenge proof and the stability proof into two containers with dynamically adjustable volume sizes, respectively; and judging whether the primary copy node is actually in response consensus request timeout based on the volume ratio of the two containers.

[0021] Optionally, judging whether the primary copy node is actually in response consensus request timeout based on the volume ratio of the two containers, including: in response to the volume of the two containers satisfying: S1 represents the volume size of the challenge proof, S2 represents the volume size of the stability proof, and k represents the size of the alliance chain, then it is determined that the primary copy node is actually in response consensus request timeout.

[0022] Optionally, the new master replica node replaces the master replica node that appears to respond to the consensus request timeout, comprising: determining whether all the replica nodes participating in the consensus processing have generated a snapshot confirmation message, and if so, the new master replica node replaces the master replica node that appears to respond to the consensus request timeout.

[0023] A view processing apparatus in a consortium chain, comprising:

[0024] A first program unit for, in response to the master replica node participating in the consensus processing in the consortium chain appearing to respond to the consensus request timeout, each slave replica node participating in the consensus processing in the consortium chain generates a snapshot request and broadcasts within the consortium chain;

[0025] A second program unit for the replica nodes not participating in the consensus processing in the consortium chain receiving the view switching request broadcast by each slave replica node participating in the consensus processing to generate a snapshot message, and the snapshot messages generated by a plurality of other replica nodes not participating in the consensus processing are assembled to form a snapshot opening proof;

[0026] A third program unit for the master replica node participating in the consensus processing in the consortium chain verifying the legitimacy of the snapshot opening proof, and in response to the snapshot opening proof being legitimate, sending the snapshot opening proof to a new master replica node, so that the new master replica node replaces the master replica node that appears to respond to the consensus request timeout to perform view switching, so that the new master replica node and the replica nodes participating in the consensus processing are in the same view.

[0027] Optionally, the first program unit is further configured to determine that the master replica node participating in the consensus processing in the consortium chain appears to respond to the consensus request timeout according to the response consensus request timeout challenge proof generated by the slave replica node participating in the consensus processing in the consortium chain and the response consensus request stability proof generated by the replica node not participating in the consensus processing in the consortium chain.

[0028] Optionally, the first program unit is further configured to poll the challenge message of the master replica node responding to the consensus request timeout sent by the slave replica node participating in the consensus processing in the view, each slave replica node sending the challenge message has a first sequence identifier, and all the challenge messages are spliced into a response consensus request timeout challenge proof in the order of the first sequence identifier of the corresponding slave replica node.

[0029] Optionally, the first program unit is further configured to: poll the primary replica node for a stability message of the response to the consensus request sent by the replica node in the view that does not participate in the consensus processing, each slave replica node sending the stability message having a second sequence identifier, and all the stability messages being spliced into a stability proof of the response to the consensus request in order of the second sequence identifier of the corresponding slave replica node.

[0030] Optionally, the first program unit is further configured to: obtain a consensus state recorded in a consensus state machine in the consortium chain, and determine, based on the consensus state, a number of slave replica nodes having the same consensus state as the replica nodes participating in the consensus processing.

[0031] Optionally, the first sequence identifier is generated in such a way that the first program unit determines, for each of the number of slave replica nodes having the same consensus state, a consensus timestamp thereof, generates a first random number based on the consensus timestamp, and assigns the first random number to the slave replica node as the sequence identifier.

[0032] Optionally, a first digest generation unit is configured to generate a challenge message digest for each of the challenge messages and combine the challenge message digest with the sequence identifier of the slave replica node sending the challenge message into a key-value pair; and the first program unit is further configured to: based on the key-value, splice all the challenge messages into a timeout challenge proof of the response to the consensus request in order of the sequence identifier of the slave replica node sending the challenge message.

[0033] Optionally, a first queue establishment unit is configured to establish a challenge message broadcast queue based on the sequence identifier of the slave replica node broadcasting the challenge message, and project the key-value pair onto the challenge message broadcast queue to dynamically maintain the challenge message broadcast queue according to the key-value pair.

[0034] Optionally, a second digest generation unit is configured to generate a confirmation message digest for each of the confirmation messages and combine the confirmation message digest with the sequence identifier of the slave replica node broadcasting the confirmation message into a key-value pair; and the first program unit is further configured to: based on the key-value, splice all the stability messages into a stability proof in order of the second sequence identifier of the slave replica node sending the stability message.

[0035] Optionally, the apparatus further includes a second queue establishment unit configured to establish a stability message broadcast queue based on the sequence identifier of the slave replica node sending the confirmation message, and project the key-value pair onto the stability message broadcast queue to dynamically maintain the stability message broadcast queue according to the key-value pair.

[0036] Optionally, the identity code of the primary copy node is carried in the challenge message, so that when the challenge messages of the first digest generation unit are spliced into a response consensus request timeout challenge proof in the order of the sequence identity codes of the slave copy nodes sending the challenge messages, the identity code included in the challenge message is separated, so that the response consensus request timeout challenge proof includes the identity code.

[0037] Optionally, the first program unit is further configured to: load the challenge proof and the stability proof into two containers with dynamically adjustable volume sizes; and determine whether the primary copy node is actually responding to the consensus request timeout based on the volume ratio of the two containers.

[0038] Optionally, the first program unit is further configured to: in response to the volumes of the two containers satisfying: Within a set range, S1 represents the volume size of the challenge proof, S2 represents the volume size of the stability proof, and k represents the size of the consortium chain, so that it is determined that the primary copy node is actually responding to the consensus request timeout.

[0039] Optionally, the third program unit is further configured to: determine whether all the copy nodes participating in the consensus processing have generated the cut picture confirmation message, and if so, replace the primary copy node that is responding to the consensus request timeout with the new primary copy node.

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

[0041] In response to the primary copy node participating in the consensus processing in the consortium chain responding to the consensus request timeout, each slave copy node participating in the consensus processing in the consortium chain generates a cut picture request and broadcasts it in the consortium chain;

[0042] The copy nodes not participating in the consensus processing in the consortium chain receive the view switching request broadcast by each slave copy node participating in the consensus processing to generate a cut picture message, and the cut picture messages generated by a plurality of other copy nodes not participating in the consensus processing are spliced to form a cut picture opening proof;

[0043] The primary copy node participating in the consensus processing in the consortium chain verifies the legitimacy of the cut picture opening proof, and in response to the legitimacy of the cut picture opening proof, sends the cut picture opening proof to a new primary copy node, replaces the primary copy node responding to the consensus request timeout with the new primary copy node, performs view switching, and makes the new primary copy node and the copy nodes participating in the consensus processing in the same view.

[0044] In the technical solution of the embodiment of the application, in response to the fact that the primary replica node participating in the consensus processing in the alliance chain appears a timeout in responding to a consensus request, each slave replica node participating in the consensus processing in the alliance chain generates a view switching request and broadcasts the view switching request in the alliance chain; the replica node not participating in the consensus processing in the alliance chain receives the view switching request broadcast by each slave replica node participating in the consensus processing to generate a view switching message, and the view switching messages generated by a plurality of other replica nodes not participating in the consensus processing are spliced to form a view switching opening proof; the primary replica node participating in the consensus processing in the alliance chain verifies the legitimacy of the view switching opening proof, and in response to the fact that the view switching opening proof is legitimate, sends the view switching opening proof to a new primary replica node, so that the new primary replica node replaces the primary replica node appearing a timeout in responding to a consensus request to perform view switching, so that the new primary replica node and the replica node participating in the consensus processing are in the same view, thereby avoiding the case that the primary replica node appears a consensus timeout, and the case that a view error occurs. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor under the premise of the drawings.

[0046] Figure 1 A flowchart of a view processing method in an alliance chain according to an embodiment of the application;

[0047] Figure 2 A structural diagram of a view processing device in an alliance chain according to an embodiment of the application;

[0048] Figure 3 A structural diagram of a view processing device in an alliance chain according to an embodiment of the application;

[0049] Figure 4 A structural diagram of an electronic device according to an embodiment of the application;

[0050] Figure 5 A hardware structural diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0051] Implementing any of the technical solutions of the embodiments of the application does not necessarily need to achieve all the advantages above at the same time.

[0052] In the following, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0053] In the technical solutions of the embodiments of the present application, in response to the master replica node participating in consensus processing in the consortium chain appearing response consensus request timeout, each slave replica node participating in consensus processing in the consortium chain generates a view switching request and broadcasts it within the consortium chain; the replica node not participating in consensus processing in the consortium chain receives the view switching request broadcast by each slave replica node participating in consensus processing to generate a view switching message, and the view switching messages generated by multiple other replica nodes not participating in consensus processing are spliced to form a view switching opening proof; the master replica node participating in consensus processing in the consortium chain verifies the legitimacy of the view switching opening proof, and in response to the view switching opening proof being legitimate, sends the view switching opening proof to a new master replica node, so that the new master replica node replaces the master replica node appearing response consensus request timeout to perform view switching, so that the new master replica node and the replica node participating in consensus processing are in the same view, thereby avoiding the case of consensus timeout of the master replica node and the situation of view error.

[0054] Figure 1 The flowchart of a view processing method in a consortium chain according to an embodiment of the present application is shown in FIG. 1, which includes the following steps. Figure 1

[0055] S101, in response to the master replica node participating in consensus processing in the consortium chain appearing response consensus request timeout, each slave replica node participating in consensus processing in the consortium chain generates a view switching request and broadcasts it within the consortium chain;

[0056] S102, the replica node not participating in consensus processing in the consortium chain receives the view switching request broadcast by each slave replica node participating in consensus processing to generate a view switching message, and the view switching messages generated by multiple other replica nodes not participating in consensus processing are spliced to form a view switching opening proof;

[0057] ​S103, the primary replica node participating in the consensus processing in the alliance chain verifies the legality of the view opening proof, and in response to the legal view opening proof, sends the view opening proof to the new primary replica node, so that the new primary replica node replaces the primary replica node that appears to respond to the consensus request timeout to perform view switching, so that the new primary replica node and the replica node participating in the consensus processing are in the same view.

[0058] Optionally, before the primary replica node participating in the consensus processing in the alliance chain appears to respond to the consensus request timeout, it includes: according to the response consensus request timeout challenge proof generated by the slave replica node participating in the consensus processing in the alliance chain and the response consensus request stability proof generated by the replica node not participating in the consensus processing in the alliance chain, judging that the primary replica node participating in the consensus processing in the alliance chain appears to respond to the consensus request timeout, so as to accurately determine that the primary replica node participating in the consensus processing in the alliance chain appears to respond to the consensus request timeout.

[0059] Optionally, before the primary replica node participating in the consensus processing in the alliance chain appears to respond to the consensus request timeout, it includes: polling the challenge message of the primary replica node responding to the consensus request timeout sent by the slave replica node participating in the consensus processing in the view, each slave replica node sending the challenge message has a first sequence identifier, and all challenge messages are spliced into a response consensus request timeout challenge proof according to the first sequence identifier of the corresponding slave replica node in order, so as to ensure the timing between challenge messages, and at the same time, these challenge messages are spliced to form a challenge proof.

[0060] Optionally, before the primary replica node participating in the consensus processing in the alliance chain appears to respond to the consensus request timeout, it includes: polling the stability message of the primary replica node responding to the consensus request sent by the replica node not participating in the consensus processing in the view, each slave replica node sending the stability message has a second sequence identifier, and all stability messages are spliced into a response consensus request stability proof according to the second sequence identifier of the corresponding slave replica node in order. By polling the stability message of the primary replica node responding to the consensus request sent by the replica node not participating in the consensus processing in the view, the conflict in the data processing process of the algorithm is ensured.

[0061] Optionally, before the responding to the primary replica node in the consortium chain participating in the consensus processing in response to the consensus request timeout, the method further comprises: obtaining a consensus state recorded in a consensus state machine in the consortium chain, and determining a plurality of secondary replica nodes with the same consensus state as the replica nodes participating in the consensus processing based on the consensus state, so that the primary replica node that appears in response to the consensus request timeout can be accurately determined.

[0062] Optionally, the first sequence identification code is generated in the following manner: for each of the plurality of secondary replica nodes with the same consensus state, determining a consensus timestamp thereof; and generating a first random number based on the consensus timestamp, and assigning the first random number to the secondary replica node as the sequence identification code, so that the sequence identification code represents the timing of the secondary replica node participating in the consensus processing, and the privacy of the sequence identification code is increased, thereby ensuring the security of the algorithm.

[0063] Optionally, the method further comprises: generating a challenge message digest for each of the challenge messages, and combining the challenge message digest with the sequence identification of the secondary replica node sending the challenge message into a key-value pair; and splicing all the challenge messages into a response consensus request timeout challenge proof in the order of the first sequence identification code of the corresponding secondary replica node, including: based on the key-value pair, so that all the challenge messages are spliced into a response consensus request timeout challenge proof in the order of the sequence identification code of the secondary replica node sending the challenge message.

[0064] In this embodiment, the security of the challenge message is ensured based on the challenge message digest, and the space requirement for data storage is further reduced based on the key-value pair, ensuring the transmission efficiency. At the same time, a plurality of challenge messages are spliced into a challenge proof in the order of the sequence identification code of the secondary replica node broadcasting the challenge message, thereby ensuring the orderliness of the challenge messages, and the plurality of challenge messages form a challenge proof as a whole, ensuring the security of the challenge messages and preventing tampering.

[0065] Optionally, the method further comprises: establishing a challenge message broadcast queue based on the sequence identification of the secondary replica node broadcasting the challenge message, and projecting the key-value pair onto the challenge message broadcast queue to dynamically maintain the challenge message broadcast queue according to the key-value pair.

[0066] Optionally, the method further comprises: generating an acknowledgement message digest for each of the acknowledgement messages, and combining the acknowledgement message digest with the sequence identifier of the slave copy node broadcasting the acknowledgement message to form a key-value pair; and splicing all the stability messages in sequence according to the second sequence identifier of the slave copy node sending the stability message to form a stability proof in response to the consensus request, including: based on the key-value, splicing all the stability messages in sequence according to the second sequence identifier of the slave copy node sending the stability message to form a stability proof.

[0067] In this embodiment, the security of the acknowledgement message is ensured based on the acknowledgement message digest, and the space requirement of data storage is further reduced based on the key-value pair, ensuring the transmission efficiency. Meanwhile, multiple acknowledgement messages are spliced in sequence according to the sequence identifier of the slave copy node broadcasting the acknowledgement message to form an acknowledgement proof, thereby ensuring the orderliness of the acknowledgement messages, and the security of the acknowledgement messages is ensured as a whole of the multiple acknowledgement messages forms an acknowledgement proof, which cannot be tampered with.

[0068] Optionally, the method further comprises: based on the sequence identifier of the slave copy node sending the acknowledgement message, establishing a stability message broadcast queue, and projecting the key-value pair onto the stability message broadcast queue to dynamically maintain the stability message broadcast queue according to the key-value pair.

[0069] In this embodiment, by establishing the message broadcast queue and projecting the key-value pair onto the challenge message broadcast queue, the challenge message is maintained in the form of the key-value pair.

[0070] In this embodiment, the mapping relationship between the key-value pair and each queue node in the challenge message broadcast queue is established, so that the key-value pair is projected onto the challenge message broadcast queue.

[0071] Optionally, the identity identifier of the primary copy node is carried in the challenge message, so that when all the challenge messages are spliced in sequence according to the sequence identifier of the slave copy node sending the challenge message to form a timeout challenge proof in response to the consensus request, the identity identifier included in the challenge message is separated and processed, so that the identity identifier is included in the timeout challenge proof in response to the consensus request.

[0072] Optionally, the timeout challenge proof in response to the consensus request generated according to the slave copy node participating in the consensus processing in the alliance chain and the stability proof in response to the consensus request generated by the copy node not participating in the consensus processing in the alliance chain are used to determine that the primary copy node participating in the consensus processing in the alliance chain is in timeout in response to the consensus request, including: loading the challenge proof and the stability proof into two containers with dynamically adjustable volumes, respectively; and determining whether the primary copy node is actually in timeout in response to the consensus request based on the volume ratio of the two containers.

[0073] In this embodiment, based on the volume comparison of the containers, it can be quickly determined whether the primary replica node is actually responding to the consensus request timeout, thereby improving the efficiency of algorithm execution.

[0074] Optionally, determining whether the primary replica node is actually responding to the consensus request timeout based on the volume ratio of the two containers comprises: in response to the volume of the two containers satisfying: Within a set range, S1 represents the volume size of the challenge proof, S2 represents the volume size of the stability proof, and k represents the size of the alliance chain, and then it is determined that the primary replica node is actually responding to the consensus request timeout.

[0075] Optionally, the new primary replica node replaces the primary replica node that appears to be responding to the consensus request timeout, comprising: determining whether all the replica nodes participating in the consensus processing have generated a cut picture confirmation message, and if so, the new primary replica node replaces the primary replica node that appears to be responding to the consensus request timeout.

[0076] Figure 2 FIG. 1 is a structural schematic diagram of a view processing device in an alliance chain according to an embodiment of the present application; as Figure 2 It comprises:

[0077] The first program unit 201 is configured to, in response to the primary replica node participating in consensus processing in the alliance chain appearing to be responding to the consensus request timeout, each slave replica node participating in consensus processing in the alliance chain generates a cut picture request and broadcasts it within the alliance chain.

[0078] The second program unit 202 is configured to receive the view switching request broadcast by each slave replica node participating in consensus processing to generate a cut picture message, and the cut picture messages generated by a plurality of other replica nodes not participating in consensus processing are spliced to form a cut picture opening proof.

[0079] The third program unit 203 is configured to verify the legitimacy of the cut picture opening proof by the primary replica node participating in consensus processing in the alliance chain, and in response to the cut picture opening proof being legitimate, send the cut picture opening proof to a new primary replica node, so that the new primary replica node replaces the primary replica node that appears to be responding to the consensus request timeout, to perform view switching, so that the new primary replica node and the replica nodes participating in consensus processing are in the same view.

[0080] Optionally, the first program unit 201 is further configured to: determine that a master replica node in the consortium chain is responding to a consensus request timeout according to a response consensus request timeout challenge proof generated by a slave replica node participating in consensus processing in the view and a response consensus request stability proof generated by a slave replica node not participating in consensus processing in the consortium chain.

[0081] Optionally, the first program unit 201 is further configured to: poll the challenge messages of the master replica node responding to the consensus request timeout sent by the slave replica nodes participating in consensus processing in the view, each slave replica node sending the challenge message has a first sequence identifier, and all the challenge messages are spliced into a response consensus request timeout challenge proof in order of the first sequence identifier of the corresponding slave replica node.

[0082] Optionally, the first program unit 201 is further configured to: poll the stability messages of the master replica node responding to the consensus request sent by the slave replica nodes not participating in consensus processing in the view, each slave replica node sending the stability message has a second sequence identifier, and all the stability messages are spliced into a response consensus request stability proof in order of the second sequence identifier of the corresponding slave replica node.

[0083] Optionally, the first program unit 201 is further configured to: obtain a consensus state recorded in a consensus state machine in the consortium chain, and determine a plurality of slave replica nodes having the same consensus state as the slave replica nodes participating in consensus processing based on the consensus state.

[0084] Optionally, the first sequence identifier is generated in such a way that: for each slave replica node of the plurality of slave replica nodes having the same consensus state, the first program unit 201 determines a consensus timestamp thereof; based on the consensus timestamp, a first random number is generated and assigned to the slave replica node as the sequence identifier.

[0085] Figure 3 A structural schematic diagram of a view processing apparatus in a consortium chain according to an embodiment of the present application is shown in FIG. 1. Figure 3 Compared with the above Figure 2 , the following is added:

[0086] Optionally, the apparatus further comprises a first digest generation unit 204 configured to generate a challenge message digest for each of the challenge messages and combine the sequence identifier of the slave replica node sending the challenge message into a key-value pair; and the first program unit 201 is further configured to: based on the key-value, splice all the challenge messages into a response consensus request timeout challenge proof in order of the sequence identifier of the slave replica node sending the challenge message.

[0087] Optionally, the apparatus further comprises a first queue establishing unit 205 configured to establish a challenge message broadcast queue based on the sequence identifier of the slave copy node broadcasting the challenge message, and project the key-value pair onto the challenge message broadcast queue to dynamically maintain the challenge message broadcast queue according to the key-value pair.

[0088] Optionally, the apparatus further comprises a second summary generating unit 206 configured to generate a challenge message summary for each of the challenge messages, and combine the challenge message summary with the sequence identifier of the slave copy node broadcasting the challenge message into a key-value pair; the first program unit 201 is further configured to, based on the key-value, cause all the stability messages to be sequentially spliced into a stability proof according to the second sequence identifier code of the slave copy node sending the stability messages.

[0089] Optionally, the apparatus further comprises a second queue establishing unit 207 configured to establish a stability message broadcast queue based on the sequence identifier of the slave copy node sending the challenge message, and project the key-value pair onto the stability message broadcast queue to dynamically maintain the stability message broadcast queue according to the key-value pair.

[0090] Optionally, the challenge message carries an identity code of the master copy node, so that when the first summary generating unit 204 causes all the challenge messages to be sequentially spliced into a response consensus request timeout challenge proof according to the sequence identifier code of the slave copy node sending the challenge messages, the identity code included in the challenge message is separated for processing, so that the response consensus request timeout challenge proof includes an identity code.

[0091] Optionally, the first program unit 201 is further configured to load the challenge proof and the stability proof into two containers respectively, the volume of which can be dynamically adjusted; and determine whether the master copy node is actually responding to the consensus request timeout based on the volume ratio of the two containers.

[0092] Optionally, the first program unit 201 is further configured to, in response to the volume of the two containers satisfying: S_1 / (e^k 〖Mod(S〗_2^k)) being within a set range, S_1 representing the volume size of the challenge proof, S_2 representing the volume size of the stability proof, and k representing the size of the alliance chain, determine that the master copy node is actually responding to the consensus request timeout.

[0093] Optionally, the third program unit 203 is further configured to determine whether all the copy nodes participating in the consensus processing have generated a cut confirmation message, and if so, cause the new master copy node to replace the master copy node appearing to respond to the consensus request timeout.

[0094] Figure 4 Figure 1 is a schematic diagram of an electronic device according to an embodiment of the present application; Figure 4 As shown, the electronic device includes a memory 301 and a processor 302, the memory stores an executable program, and the processor executes the executable program to perform the following steps:

[0095] determining one primary replica node participating in the consensus process and determining a plurality of secondary replica nodes having consensus states, the primary replica node and the plurality of secondary replica nodes being in the same view;

[0096] collecting challenge messages broadcast by the secondary replica nodes in the view in response to a consensus request timeout of the primary replica node, and counting the number of secondary replica nodes broadcasting the challenge messages, all the challenge messages being spliced into a challenge proof in order of the sequence identification codes of the secondary replica nodes broadcasting the challenge messages;

[0097] collecting confirmation messages broadcast by the secondary replica nodes in the view in response to the challenge messages, and counting the number of secondary replica nodes broadcasting the confirmation messages, all the confirmation messages being spliced into a confirmation proof in order of the sequence identification codes of the secondary replica nodes broadcasting the confirmation messages;

[0098] judging whether the primary replica node is actually in response to a consensus request timeout according to the challenge proof and the confirmation proof.

[0099] Figure 5 Figure 2 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application; Figure 5 As shown, the hardware structure of the electronic device can 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 406 into a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the device 400 can also be stored. The computing unit 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0100] The plurality of components in the electronic device 400 are connected to the I / O interface 405, including: an input unit 406, an output unit 407, a storage unit 408, and a communication unit 409. The input unit 406 can be any type of device capable of inputting information to the electronic device 400, which can receive inputted digital or character information, and generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 407 can be any type of device capable of presenting information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 404 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 409 allows the electronic device 400 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can 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.

[0101] The computing unit 401 can be various general and / or special-purpose 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 special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 401 performs various methods and processes described above. For example, in some embodiments, the above-described steps can be implemented as a computer software program, which is tangibly embodied in a machine-readable medium, such as the storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 400 via the ROM 402 and / or the communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the above-described steps by any other appropriate means, such as by means of firmware.

[0102] The electronic device of the embodiments of the present application exists in various forms, including but not limited to:

[0103] (1) Mobile communication device: This type of device is characterized by having mobile communication functions, and is mainly targeted at providing voice and data communication. This type of terminal includes: smart phones (such as iPhone), multimedia phones, functional phones, and low-end phones, etc.

[0104] (2) Ultra-mobile personal computer device: This type of device belongs to the category of personal computers, has computing and processing functions, and generally also has the feature of mobile Internet. This type of terminal includes: PDA, MID, and UMPC devices, such as iPad.

[0105] (3) Portable entertainment device: This kind of device can display and play multimedia content. This kind of device includes: audio and video player (such as iPod), palm game machine, electronic book, and smart toy and portable car navigation device.

[0106] (4) Server: A device providing computing service, the server is composed of processor 410, hard disk, memory, system bus, etc., the server is similar to general computer architecture, but due to the need to provide high reliable service, therefore, in the processing capacity, stability, reliability, security, scalability, manageability, etc. The requirements are high.

[0107] (5) Other electronic devices with data interaction function.

[0108] It should be noted that each of the embodiments in the specification is described in a progressive manner, and the same and similar parts between each embodiment can be referred to each other, and each embodiment focuses on the difference from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, they are described more simply, and the relevant parts can be referred to the part of the method embodiment. The above described device and system embodiments are only illustrative, and the modules described as separate components can be or can not be physically separated, and the components prompted as modules can be or can not be physical modules, that is, they can be located in one place, or can be distributed on multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment. Those skilled in the art can understand and implement without creative labor.

[0109] The above is only one specific embodiment of the present application, but the protection scope of the present application is not limited to this. Any skilled person in the art can easily think of changes or replacements within the technical range disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A view processing method in a consortium chain, characterized in that, The method comprises: In response to the primary replica node participating in the consensus processing in the alliance chain being out of response to the consensus request, each slave replica node participating in the consensus processing in the alliance chain generates a snapshot request and broadcasts the snapshot request in the alliance chain; Other replica nodes not participating in the consensus processing in the alliance chain receive the snapshot request broadcast by each slave replica node participating in the consensus processing to generate a snapshot message, and a plurality of snapshot messages generated by the other replica nodes not participating in the consensus processing are spliced to form a snapshot opening proof; The primary replica node participating in the consensus processing in the alliance chain verifies the legality of the snapshot opening proof, and in response to the snapshot opening proof being legal, sends the snapshot opening proof to a new primary replica node, so that the new primary replica node replaces the primary replica node out of response to the consensus request to perform view switching, so that the new primary replica node and the replica nodes participating in the consensus processing are in the same view. The new primary replica node replacing the primary replica node out of response to the consensus request comprises: judging whether all the replica nodes participating in the consensus processing have generated snapshot confirmation messages, and if so, replacing the primary replica node out of response to the consensus request with the new primary replica node.

2. The method of claim 1, wherein, Before the primary replica node participating in the consensus processing in the alliance chain is out of response to the consensus request, the method comprises: judging that the primary replica node participating in the consensus processing in the alliance chain is out of response to the consensus request according to the response to the consensus request timeout challenge proof generated by the slave replica node participating in the consensus processing in the alliance chain and the response to the consensus request stability proof generated by the other replica node not participating in the consensus processing in the alliance chain.

3. The method of claim 2, wherein, The method comprises: Polling the challenge messages of the primary replica node out of response to the consensus request sent by the slave replica nodes participating in the consensus processing in the view, each slave replica node sending the challenge messages having a first sequence identifier, and all the challenge messages being spliced into a response to the consensus request timeout challenge proof in the order of the first sequence identifiers of the corresponding slave replica nodes.

4. The method of claim 2, wherein, The method comprises: Polling the stability messages of the primary replica node out of response to the consensus request sent by the replica nodes not participating in the consensus processing in the view, each slave replica node sending the stability messages having a second sequence identifier, and all the stability messages being spliced into a response to the consensus request stability proof in the order of the second sequence identifiers of the corresponding slave replica nodes.

5. The method of claim 2, wherein, Before the primary replica node participating in the consensus processing in the alliance chain is out of response to the consensus request, the method comprises: obtaining a consensus state recorded in a consensus state machine in the alliance chain, and determining a plurality of slave replica nodes having the same consensus state as the replica nodes participating in the consensus processing based on the consensus state.

6. The method of claim 3, wherein, The first sequence identifier is generated in the following manner: for each slave replica node of the plurality of slave replica nodes having the same consensus state, determining a consensus timestamp of the slave replica node; Based on the consensus timestamp, a first random number is generated, and the first random number is assigned to the slave replica node as the sequence identifier.

7. The method of claim 3, wherein, The method further comprises: generating a challenge message digest for each challenge message and combining the sequence identifier of the slave copy node sending the challenge message into a key-value pair; and splicing all challenge messages into a response consensus request timeout challenge proof according to the first sequence identifier of the corresponding slave copy node, including: based on the key value, splicing all challenge messages into a response consensus request timeout challenge proof according to the sequence identifier of the slave copy node sending the challenge message.

8. The method of claim 4, wherein, The method further comprises: generating a stability message digest for each stability message and combining the sequence identifier of the slave copy node broadcasting the stability message into a key-value pair; and splicing all stability messages into a response consensus request stability proof according to the second sequence identifier of the corresponding slave copy node, including: based on the key value, splicing all stability messages into a stability proof according to the second sequence identifier of the slave copy node sending the stability message.

9. The method of claim 7, wherein, The challenge message carries the identity code of the main copy node, so that when all challenge messages are spliced into a response consensus request timeout challenge proof according to the sequence identifier of the slave copy node sending the challenge message, the identity code included in the challenge message is separated and processed, so that the response consensus request timeout challenge proof includes an identity code.

10. The method of claim 2, wherein, The response consensus request timeout challenge proof generated by the slave copy node participating in the consensus processing in the alliance chain and the response consensus request stability proof generated by the copy node not participating in the consensus processing in the alliance chain are used to determine whether the main copy node participating in the consensus processing in the alliance chain is actually responding to the consensus request timeout, including: loading the challenge proof and the stability proof into two containers with dynamically adjustable volumes; and determining whether the main copy node is actually responding to the consensus request timeout based on the volume ratio of the two containers.

Images