Consensus timeout response method and device in alliance chain

Abstract

The application discloses a consensus timeout response method and device in a consortium chain. One master copy node participating in consensus processing and a plurality of slave copy nodes with consensus states are determined, and the master copy node and the plurality of slave copy nodes are located in the same view. A challenge message of the master copy node responding to the consensus request timeout broadcast by the slave copy node in the view is collected, and the number of the slave copy nodes broadcasting the challenge message is counted. All the challenge messages are spliced into a challenge proof in the order of the serial identification codes of the slave copy nodes broadcasting the challenge messages. A confirmation message generated by responding to the challenge message broadcast by the slave copy node in the view is collected, and the number of the slave copy nodes broadcasting the confirmation message is counted. All the confirmation messages are spliced into a confirmation proof in the order of the serial identification codes of the slave copy nodes broadcasting the confirmation messages. Whether the master copy node is actually responding to the consensus request timeout is quickly judged according to the challenge proof and the confirmation proof.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of alliance chain, in particular to a consensus timeout response method and device in an alliance chain. 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 system is stored in a copy on the disk of each alliance chain node, which requires a mechanism for consensus processing to coordinate the actions of the nodes in the alliance chain system to reach an agreement on the block and ensure the consistency of the data of the nodes.

[0003] However, in the consensus process, one node acts as a primary replica node, and all other nodes act as secondary replica nodes. When the primary replica node has a consensus timeout, the consensus will collapse.

[0004] Therefore, how to determine whether the primary replica node has a consensus timeout becomes a technical problem to be solved. SUMMARY

[0005] To solve the above problems, the present application provides a consensus timeout response method and device in an alliance chain and an electronic device.

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

[0007] According to the first aspect of the present application, a consensus timeout response method in an alliance chain is provided, comprising:

[0008] determining a primary replica node participating in consensus processing and a plurality of secondary replica nodes having a consensus state, the primary replica node and the plurality of secondary replica nodes being in the same view;

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

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

[0011] According to the challenge proof and the confirmation proof, it is determined whether the primary replica node is actually responding to the consensus request timeout.

[0012] Optionally, the determining the plurality of slave nodes with the consensus state comprises: obtaining the consensus state recorded in the consensus state machine in the consortium chain, determining the plurality of slave nodes with the same consensus state based on the consensus state; determining the consensus timestamp of each slave node in the plurality of slave nodes with the same consensus state; generating a random number based on the consensus timestamp, and assigning the random number to the slave node as the sequence identification code.

[0013] Optionally, the method further comprises: if there is a delay in receiving the consensus construction message broadcast by the other slave nodes by at least two slave nodes, the at least two slave nodes broadcast the challenge message in response to the timeout of the consensus request of the master node.

[0014] Optionally, the method further comprises: generating a challenge message digest for each challenge message and combining the sequence identification of the slave node broadcasting the challenge message into a key-value pair; and splicing all challenge messages into a challenge proof in the order of the sequence identification code of the slave node broadcasting the challenge message based on the key-value.

[0015] Optionally, the method further comprises: establishing a challenge message broadcast queue based on the sequence identification of the slave 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.

[0016] Optionally, the method further comprises: generating a confirmation message digest for each confirmation message and combining the sequence identification of the slave node broadcasting the confirmation message into a key-value pair; and splicing all confirmation messages into a confirmation proof in the order of the sequence identification code of the slave node broadcasting the confirmation message based on the key-value.

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

[0018] Optionally, the challenge message carries the identity identification code of the master node, so that when all challenge messages are spliced into a challenge proof in the order of the sequence identification code of the slave node broadcasting the challenge message, the identity identification code included in the challenge message is separated and processed, so that the challenge proof includes an identity identification code.

[0019] Optionally, judging whether the master copy node is actually timed out in responding to the consensus request according to the challenge proof and the confirmation proof comprises: loading the challenge proof and the confirmation proof into a first container and a second container respectively, wherein volumes of the first container and the second container are dynamically adjustable; and judging whether the master copy node is actually timed out in responding to the consensus request based on a volume ratio of the first container to the second container.

[0020] Optionally, judging whether the master copy node is actually timed out in responding to the consensus request based on the volume ratio of the first container to the second container comprises: determining that the master copy node is actually timed out in responding to the consensus request in response to the volume ratio of the first container to the second container being between 0.7 and 1.

[0021] Optionally, the method further comprises: switching the master copy node that is timed out in responding to the consensus request to a new slave copy node and adding the new slave copy node to the view.

[0022] According to a second aspect of the embodiments of the present application, a consensus timeout handling device in a consortium chain is provided, comprising:

[0023] a first program unit configured to determine a master copy node participating in consensus processing and determine a plurality of slave copy nodes having consensus states, wherein the master copy node and the plurality of slave copy nodes are located in a same view;

[0024] a second program unit configured to collect challenge messages of the master copy node timed out in responding to a consensus request broadcast by the slave copy nodes in the view, count a number of the slave copy nodes broadcasting the challenge messages, and splice all the challenge messages into a challenge proof in sequence of serial identification codes of the slave copy nodes broadcasting the challenge messages;

[0025] a third program unit configured to collect confirmation messages generated in response to the challenge messages broadcast by the slave copy nodes in the view, count a number of the slave copy nodes broadcasting the confirmation messages, and splice all the confirmation messages into a confirmation proof in sequence of serial identification codes of the slave copy nodes broadcasting the confirmation messages;

[0026] a fourth program unit configured to judge whether the master copy node is actually timed out in responding to the consensus request according to the challenge proof and the confirmation proof.

[0027] Optionally, the first program unit is further configured to: acquire a consensus state recorded in the consensus state machine in the alliance chain, determine a plurality of slave replica nodes having the same consensus state based on the consensus state; determine a consensus timestamp of each slave replica node in the plurality of slave replica nodes having the same consensus state; generate a random number based on the consensus timestamp, and assign the random number to the slave replica node as the sequence identification code.

[0028] Optionally, the device further comprises a delay judgment unit configured to, if there is a delay in receiving, by at least two slave replica nodes, the consensus construction message broadcast by other slave replica nodes, broadcast, by the at least two slave replica nodes, the challenge message in response to the timeout of the consensus request of the primary replica node.

[0029] Optionally, the device further comprises a first digest generation unit configured to generate a challenge message digest for each challenge message, and combine the sequence identification of the slave replica node broadcasting the challenge message into a key-value pair; and the second program unit is further configured to: based on the key-value, splice all the challenge messages into a challenge proof in the order of the sequence identification code of the slave replica node broadcasting the challenge message.

[0030] Optionally, the device further comprises a first queue establishment unit configured to establish a challenge message broadcast queue based on the sequence identification 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.

[0031] Optionally, the device further comprises a second digest generation unit configured to generate a confirmation message digest for each confirmation message, and combine the sequence identification of the slave replica node broadcasting the confirmation message into a key-value pair; and the third program unit is further configured to: based on the key-value, splice all the confirmation messages into a confirmation proof in the order of the sequence identification code of the slave replica node broadcasting the confirmation message.

[0032] Optionally, the device further comprises a second queue establishment unit configured to establish a confirmation message broadcast queue based on the sequence identification of the slave replica node broadcasting the confirmation message, and project the key-value pair onto the confirmation message broadcast queue to dynamically maintain the confirmation message broadcast queue according to the key-value pair.

[0033] Optionally, the challenge message carries an identity identification code of the primary replica node, so that, when the second program unit splices all the challenge messages into a challenge proof in the order of the sequence identification code of the slave replica node broadcasting the challenge message, the identity identification code included in the challenge message is separated and processed, so that the challenge proof includes an identity identification code.

[0034] Optionally, the fourth program unit is further configured to: load the challenge proof and the confirmation proof into a first container and a second container respectively, wherein the volume of the first container and the second container can be dynamically adjusted; and determine whether the primary replica node has actually timed out in response to the consensus request based on the volume ratio of the first container and the second container.

[0035] Optionally, the apparatus further includes: a determination generation unit, configured to determine that the primary replica node is actually responding to a consensus request timeout if the ratio of the volumes of the first container and the second container is between 0.7 and 1.

[0036] Optionally, the determination generation unit is further configured to: switch the primary replica node that has experienced the consensus request timeout to a new secondary replica node and add it to the view.

[0037] According to a third aspect of the embodiments of this application, an electronic device is provided, characterized in that it 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:

[0038] A primary replica node is identified to participate in the consensus process, and several secondary replica nodes with a consensus state are identified. The primary replica node and the several secondary replica nodes are located in the same view.

[0039] Collect the challenge messages broadcast by the slave replica nodes in the view that the primary replica node responded to the consensus request timeout, and count the number of slave replica nodes that broadcast the challenge messages. All challenge messages are concatenated into a challenge proof according to the sequence identifier code of the slave replica node that broadcast them.

[0040] Collect the confirmation messages generated by the response to the challenge message broadcast by the replica node in the view, and count the number of replica nodes that broadcast the confirmation messages. All confirmation messages are concatenated into a confirmation certificate according to the sequence identifier code of the replica node that broadcast them.

[0041] Based on the challenged proof and the confirmed proof, determine whether the primary replica node actually timed out in response to the consensus request.

[0042] In the technical solution of the embodiment of the application, one master copy node participating in consensus processing is determined, and a plurality of slave copy nodes having consensus states are determined, the master copy node and the plurality of slave copy nodes are located in the same view; a challenge message of a master copy node response consensus request timeout broadcast by the slave copy node in the view is collected, and the number of slave copy nodes broadcasting the challenge message is counted, and all challenge messages are spliced into a challenge proof in the order of the sequence identification codes of the slave copy nodes broadcasting the challenge messages; a confirmation message generated by responding to the challenge message broadcast by the slave copy node in the view is collected, and the number of slave copy nodes broadcasting the confirmation message is counted, and all confirmation messages are spliced into a confirmation proof in the order of the sequence identification codes of the slave copy nodes broadcasting the confirmation messages; whether the master copy node is actually responding to the consensus request timeout is determined according to the challenge proof and the confirmation proof, so that whether the master copy node has a consensus timeout is quickly determined. BRIEF DESCRIPTION OF DRAWINGS

[0043] 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.

[0044] Figure 1 A flowchart of a consensus timeout handling method in a consortium chain according to an embodiment of the application;

[0045] Figure 2 A structural diagram of a consensus timeout handling device in a consortium chain according to an embodiment of the application;

[0046] Figure 3 Another structural diagram of a consensus timeout handling device in a consortium chain according to an embodiment of the application;

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

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

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

[0050] In the following, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with 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 effort belong to the scope of protection of the present application.

[0051] In the technical solutions of the embodiments of the present application, one master replica node participating in consensus processing and a plurality of slave replica nodes having consensus status are determined, and the master replica node and the plurality of slave replica nodes are located in the same view; a challenge message of the master replica node responding to a consensus request timeout broadcast by the slave replica node in the view is collected, and the number of slave replica nodes broadcasting the challenge message is counted, and all the challenge messages are spliced into a challenge proof in the order of the sequence identification codes of the slave replica nodes broadcasting the challenge messages; a confirmation message generated by responding to the challenge message broadcast by the slave replica node in the view is collected, and the number of slave replica nodes broadcasting the confirmation message is counted, and all the confirmation messages are spliced into a confirmation proof in the order of the sequence identification codes of the slave replica nodes broadcasting the confirmation messages; whether the master replica node is actually responding to the consensus request timeout is determined according to the challenge proof and the confirmation proof, so that whether the master replica node has a consensus timeout is quickly determined.

[0052] Figure 1 A flowchart of a consensus timeout response method in an alliance chain according to an embodiment of the present application is shown in FIG. 1. Figure 1 As shown in FIG. 1, the method comprises the following steps.

[0053] S101, determining one master replica node participating in consensus processing and a plurality of slave replica nodes having consensus status, the master replica node and the plurality of slave replica nodes being located in the same view;

[0054] In this embodiment, the master replica node and the slave replica node in step S101 can be a functional role successfully allocated in the alliance chain when the last consensus processing is completed.

[0055] The master replica node and the slave replica node are not fixed.

[0056] S102, collecting a challenge message of the master replica node responding to a consensus request timeout broadcast by the slave replica node in the view, and counting the number of slave replica nodes broadcasting the challenge message, and splicing all the challenge messages into a challenge proof in the order of the sequence identification codes of the slave replica nodes broadcasting the challenge messages;

[0057] In this embodiment, the main copy node response consensus request timeout challenge message broadcast by the slave copy node in the view can be collected by setting a buried point, and the number of slave copy nodes broadcasting the challenge message is counted.

[0058] S103, collect the confirmation message generated by the slave copy node in the view in response to the challenge message, and count the number of slave copy nodes broadcasting the confirmation message, and all confirmation messages are spliced into a confirmation proof in sequence according to the sequence identification code of the slave copy node broadcasting it.

[0059] Specifically, in this embodiment, the confirmation message generated by the slave copy node in the view in response to the challenge message can be collected by setting a buried point, and the number of slave copy nodes broadcasting the confirmation message is counted.

[0060] S104, according to the challenge proof and the confirmation proof, judge whether the main copy node is actually responding to the consensus request timeout.

[0061] In this embodiment, since it is for a consortium chain, a timeout determination node can be set in the consortium chain to perform the above steps S101-S104.

[0062] Optionally, the determination of the plurality of slave copy nodes with consensus state comprises: obtaining the consensus state recorded in the consensus state machine in the consortium chain, determining a plurality of slave copy nodes with the same consensus state based on the consensus state; for each of the plurality of slave copy nodes with the same consensus state, determining its consensus timestamp; based on the consensus timestamp, generate a random number, and assign the random number to the slave copy node as the sequence identification code.

[0063] In this embodiment, based on the consensus state, the slave copy nodes with consistent consensus state can be accurately determined, thereby ensuring the authenticity of the challenge proof from the perspective of consensus synchronization, and further improving the accuracy of the judgment of whether the subsequent consensus request timeout is timeout.

[0064] Optionally, the method further comprises: if there are at least two slave copy nodes receiving other slave copy nodes broadcasted consensus construction messages appear delay, the main copy node response consensus request timeout challenge message broadcasted by the at least two slave copy nodes.

[0065] In this embodiment, by the condition that there are at least two slave copy nodes receiving other slave copy nodes broadcasted consensus construction messages appear delay, the accuracy of the challenge message can be ensured.

[0066] Optionally, the method further comprises: generating a challenge message digest for each challenge message, and combining the challenge message digest with the sequence identifier of the slave copy node broadcasting the challenge message to form a key-value pair; and concatenating all challenge messages into a challenge proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the challenge messages, including: based on the key-value, concatenating all challenge messages into a challenge proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the challenge messages.

[0067] In this embodiment, the challenge message digest ensures the security of the challenge message, and the key-value pair further reduces the space requirement of data storage, ensures the transmission efficiency, and concatenates multiple challenge messages into a challenge proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the challenge messages, thereby ensuring the order of the challenge messages, and the multiple challenge messages form a challenge proof as a whole, thereby ensuring the security of the challenge messages and preventing tampering.

[0068] Optionally, the method further comprises: establishing a challenge message broadcast queue based on the sequence identifiers of the slave copy nodes broadcasting the challenge messages, and projecting the key-value pairs onto the challenge message broadcast queue to dynamically maintain the challenge message broadcast queue according to the key-value pairs.

[0069] In this embodiment, the message broadcast queue is established, and the key-value pairs are projected onto the challenge message broadcast queue, thereby facilitating the maintenance of the challenge messages in the form of key-value pairs.

[0070] In this embodiment, the mapping relationship between the key-value pairs and each queue node in the challenge message broadcast queue is established, thereby achieving the projection of the key-value pairs onto the challenge message broadcast queue.

[0071] The maintenance may include dynamic addition, dynamic deletion, etc.

[0072] Optionally, the method further comprises: generating a confirmation message digest for each confirmation message, and combining the confirmation message digest with the sequence identifier of the slave copy node broadcasting the confirmation message to form a key-value pair; and concatenating all confirmation messages into a confirmation proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the confirmation messages, including: based on the key-value, concatenating all confirmation messages into a confirmation proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the confirmation messages.

[0073] In this embodiment, the confirmation message digest ensures the security of the confirmation message, and the key-value pair further reduces the space requirement of data storage, ensures the transmission efficiency, and concatenates multiple confirmation messages into a confirmation proof in sequence of the sequence identifiers of the slave copy nodes broadcasting the confirmation messages, thereby ensuring the order of the confirmation messages, and the multiple confirmation messages form a confirmation proof as a whole, thereby ensuring the security of the confirmation messages and preventing tampering.

[0074] Optionally, a confirmation message broadcast queue is established based on the sequence identifier of the slave node broadcasting the confirmation message, and the key-value pair is projected onto the confirmation message broadcast queue, so as to dynamically maintain the confirmation message broadcast queue according to the key-value pair, such as dynamically increasing, dynamically deleting, etc.

[0075] Optionally, the identity identification code of the master copy node is carried in the challenge message, so that when all challenge messages are spliced into a challenge proof according to the sequence identifier of the slave node broadcasting the challenge message, the identity identification code included in the challenge message is separated and processed, so that the challenge proof includes an identity identification code.

[0076] Through the above separation processing, redundant identity identification is removed, and the requirement for storage space is reduced.

[0077] Optionally, the judgment of whether the master copy node is actually responding to the consensus request timeout according to the challenge proof and the confirmation proof includes: loading the challenge proof and the confirmation proof into a first container and a second container respectively, the volume of the first container and the second container can be dynamically adjusted; judging whether the master copy node is actually responding to the consensus request timeout based on the volume ratio of the first container and the second container.

[0078] In this embodiment, based on the volume comparison of the container, the judgment of whether the master copy node is actually responding to the consensus request timeout can be quickly realized, and the efficiency of algorithm execution is improved.

[0079] Optionally, the judgment of whether the master copy node is actually responding to the consensus request timeout based on the volume ratio of the first container and the second container includes: in response to the ratio of the volume of the first container and the second container being between 0.7-1, it is determined that the master copy node is actually responding to the consensus request timeout.

[0080] In this embodiment, based on the ratio of the volume of the first container and the second container being between 0.7-1, the judgment of whether the master copy node is actually responding to the consensus request timeout can be quickly and directly realized.

[0081] Optionally, it also includes: switching the master copy node that appears the response consensus request timeout to a new slave node and adding it to the view.

[0082] In this embodiment, by switching the master replica node that appears the response consensus request timeout to a new slave replica node, the new master replica node is determined, and the view is increased. At the same time, the master replica node that appears the response consensus request timeout can be switched to a slave replica node, so as to ensure the overall balanced performance and stability of the nodes in the alliance chain.

[0083] Figure 2 A structural schematic diagram of an alliance chain consensus timeout coping device according to an embodiment of the present application is shown in FIG. 1. As shown in the figure, the device includes: Figure 2

[0084] A first program unit 201 is configured to determine a master replica node participating in consensus processing and determine a plurality of slave replica nodes having a consensus state. The master replica node and the plurality of slave replica nodes are located in the same view.

[0085] A second program unit 202 is configured to collect a challenge message broadcast by the slave replica node in the view in response to the consensus request timeout of the master replica node, and count the number of slave replica nodes broadcasting the challenge message. All challenge messages are spliced into a challenge proof in the order of the sequence identification codes of the slave replica nodes broadcasting the challenge messages.

[0086] A third program unit 203 is configured to collect a confirmation message broadcast by the slave replica node in the view in response to the challenge message, and count the number of slave replica nodes broadcasting the confirmation message. All confirmation messages are spliced into a confirmation proof in the order of the sequence identification codes of the slave replica nodes broadcasting the confirmation messages.

[0087] A fourth program unit 204 is configured to determine whether the master replica node is actually in response to the consensus request timeout according to the challenge proof and the confirmation proof.

[0088] Optionally, the first program unit 201 is further configured to: obtain a consensus state recorded in a consensus state machine in the alliance chain, determine a plurality of slave replica nodes having the same consensus state based on the consensus state, determine a consensus timestamp of each slave replica node in the plurality of slave replica nodes having the same consensus state, generate a random number based on the consensus timestamp, and assign the random number to the slave replica node as the sequence identification code.

[0089] Figure 3 Another structural schematic diagram of an alliance chain consensus timeout coping device according to an embodiment of the present application is shown in FIG. 2. Based on the above-mentioned structural schematic diagram, the alliance chain consensus timeout coping device further includes: Figure 2

[0090] ​​The delay judgment unit 205 is configured to, if there is at least two slave nodes receiving the consensus construction message broadcast by other slave nodes, the at least two slave nodes broadcast the challenge message of the master copy node responding to the consensus request timeout.

[0091] The first abstract generation unit 206 is configured to generate a challenge message abstract for each challenge message, and combine the sequence identifier of the slave node broadcasting the challenge message into a key-value pair; and the second program unit 202 is further configured to: based on the key-value, splice all the challenge messages into a challenge proof in sequence according to the sequence identifier of the slave node broadcasting the challenge message.

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

[0093] The second abstract generation unit 208 is configured to generate a confirmation message abstract for each confirmation message, and combine the sequence identifier of the slave node broadcasting the confirmation message into a key-value pair; and the third program unit 203 is further configured to: based on the key-value, splice all the confirmation messages into a confirmation proof in sequence according to the sequence identifier of the slave node broadcasting the confirmation message.

[0094] The second queue establishment unit 209 is configured to establish a confirmation message broadcast queue based on the sequence identifier of the slave node broadcasting the confirmation message, and project the key-value pair onto the confirmation message broadcast queue, so as to dynamically maintain the confirmation message broadcast queue according to the key-value pair.

[0095] Optionally, the challenge message carries the identity code of the master copy node, so that when the second program unit 202 splices all the challenge messages into a challenge proof in sequence according to the sequence identifier of the slave node broadcasting the challenge message, the identity code included in the challenge message is separated and processed, so that the challenge proof includes an identity code.

[0096] Optionally, the fourth program unit 204 is further configured to: load the challenge proof and the confirmation proof into a first container and a second container respectively, and the volume of the first container and the second container can be dynamically adjusted; and judge whether the master copy node is actually responding to the consensus request timeout based on the volume ratio of the first container and the second container.

[0097] Optionally, the apparatus further comprises a determination generating unit 210 configured to determine that the primary replica node is actually in response consensus request timeout, in response to a ratio of volumes of the first container and the second container being between 0.7 and 1.

[0098] Optionally, the determination generating unit 210 is further configured to switch the primary replica node in the response consensus request timeout to a new secondary replica node and add the new secondary replica node to the view.

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

[0100] determining a primary replica node participating in consensus processing and determining a plurality of secondary replica nodes having consensus states, the primary replica node and the plurality of secondary replica nodes being located in a same view;

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

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

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

[0104] Figure 5 FIG. 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 in FIG. 2, 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 to 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.

[0105] 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.

[0106] 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.

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

[0108] (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.

[0109] (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.

[0110] (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.

[0111] (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 the general computer architecture, but since it needs to provide high reliable service, therefore, in the processing capacity, stability, reliability, security, scalability, manageability, etc. The requirements are high.

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

[0113] 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 to 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.

[0114] 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 method for handling consensus timeouts in a consortium blockchain, characterized in that, include: A primary replica node is identified to participate in the consensus process, and several secondary replica nodes with a consensus state are identified, wherein the primary replica node and the several secondary replica nodes are located in the same view; Collect the challenge messages broadcast by the slave replica nodes in the view that the primary replica node responded to the consensus request timeout, and count the number of slave replica nodes that broadcast the challenge messages. All challenge messages are concatenated into a challenge proof according to the sequence identifier code of the slave replica node that broadcast them. Collect the confirmation messages generated by the response to the challenge message broadcast by the replica node in the view, and count the number of replica nodes that broadcast the confirmation messages. All confirmation messages are concatenated into a confirmation certificate according to the sequence identifier code of the replica node that broadcast them. Based on the challenged proof and the confirmed proof, determine whether the primary replica node actually timed out in response to the consensus request; The method further includes: generating a challenge message digest for each challenge message and combining it with the sequence identifier of the slave replica node broadcasting the challenge message to form a key-value pair; concatenating all challenge messages into a challenge proof according to the sequence identifier code of the slave replica node broadcasting it, including: based on the key value, concatenating all challenge messages into a challenge proof according to the sequence identifier code of the slave replica node broadcasting it. The method further includes: generating a confirmation message digest for each confirmation message and combining it with the sequence identifier of the slave replica node broadcasting the confirmation message to form a key-value pair; concatenating all confirmation messages into a confirmation certificate according to the sequence identifier code of the slave replica node broadcasting it, including: based on the key value, concatenating all confirmation messages into a confirmation certificate according to the sequence identifier code of the slave replica node broadcasting it.

2. The method according to claim 1, characterized in that, The step of determining a plurality of replica nodes with a consensus state includes: obtaining the consensus state recorded in the consensus state machine of the consortium blockchain; determining a plurality of replica nodes with the same consensus state based on the consensus state; determining the consensus timestamp for each replica node among the plurality of replica nodes with the same consensus state; generating a random number based on the consensus timestamp; and assigning the random number to the replica node as the sequence identifier.

3. The method according to claim 1, characterized in that, The method further includes: if there is a delay in at least two replica nodes receiving consensus building messages broadcast by other replica nodes, then the primary replica node responds to the consensus request timeout challenge message broadcast by the at least two replica nodes.

4. The method according to claim 1, characterized in that, The method further includes: establishing a challenge message broadcast queue based on the sequence identifier of the 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.

5. The method according to claim 1, characterized in that, The method further includes: establishing an acknowledgment message broadcast queue based on the sequence identifier of the replica node broadcasting the acknowledgment message, and projecting the key-value pair onto the acknowledgment message broadcast queue to dynamically maintain the acknowledgment message broadcast queue according to the key-value pair.

6. The method according to claim 1, characterized in that, The challenge message carries the identity identifier of the primary replica node. When all challenge messages are concatenated into a challenge proof according to the sequence identifier of their broadcast replica nodes, the identity identifier included in the challenge message is separated, so that the challenge proof includes one of the identity identifiers.

7. The method according to claim 1, characterized in that, The step of determining whether the primary replica node has actually timed out in response to the consensus request based on the challenge proof and the confirmation proof includes: loading the challenge proof and the confirmation proof into a first container and a second container respectively, wherein the volume of the first container and the second container can be dynamically adjusted; and determining whether the primary replica node has actually timed out in response to the consensus request based on the volume ratio of the first container and the second container.

8. A consensus timeout handling device in a consortium blockchain, characterized in that, include: The first program unit is used to determine a primary replica node participating in the consensus process and several secondary replica nodes with a consensus state, wherein the primary replica node and the several secondary replica nodes are located in the same view. The second program unit is used to collect the challenge messages broadcast by the slave replica nodes in the view, indicating that the primary replica node's response to the consensus request has timed out, and to count the number of slave replica nodes that broadcast the challenge messages. All challenge messages are concatenated into a challenge proof according to the sequence identifier code of the slave replica node that broadcast them. The third program unit is used to collect the confirmation messages generated by the response to the challenge message broadcast by the replica nodes in the view, and to count the number of replica nodes that broadcast the confirmation messages. All the confirmation messages are concatenated into a confirmation certificate according to the sequence identifier code of the replica node that broadcast them. The fourth program unit is used to determine, based on the challenge proof and the confirmation proof, whether the primary replica node has actually timed out in response to the consensus request. The apparatus further includes: a first digest generation unit, configured to generate a digest for each of the challenge messages and combine it with the sequence identifier of the slave replica node broadcasting the challenge message to form a key-value pair; the second program unit is further configured to: based on the key-value pair, concatenate all the challenge messages into a challenge proof in the order of the sequence identifier codes of the slave replica node broadcasting them. The apparatus further includes: a second digest generation unit, configured to generate a digest for each of the acknowledgment messages and combine it with the sequence identifier of the slave replica node broadcasting the acknowledgment message to form a key-value pair; the third program unit is further configured to: based on the key-value pair, concatenate all the acknowledgment messages into an acknowledgment certificate in the order of the sequence identifier codes of the slave replica node broadcasting them.

9. The apparatus according to claim 8, characterized in that, The first program unit is further configured to: obtain the consensus state recorded in the consensus state machine of the consortium blockchain; determine a number of slave replica nodes with the same consensus state based on the consensus state; and determine the consensus timestamp for each slave replica node among the number of slave replica nodes with the same consensus state. Based on the consensus timestamp, a random number is generated and assigned to the replica node as the sequence identifier.

10. The apparatus according to claim 8, characterized in that, The device further includes: a delay judgment unit, used to determine if there is a delay in at least two replica nodes receiving consensus building messages broadcast by other replica nodes, and then the at least two replica nodes broadcast a challenge message indicating that the primary replica node's response to the consensus request has timed out.

11. The apparatus according to claim 8, characterized in that, The apparatus further includes: a first queue establishment unit, configured to establish a challenge message broadcast queue based on the sequence identifier of the 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.

12. The apparatus according to claim 8, characterized in that, The apparatus further includes: a second queue establishment unit, configured to establish an acknowledgment message broadcast queue based on the sequence identifier of the replica node broadcasting the acknowledgment message, and project the key-value pair onto the acknowledgment message broadcast queue to dynamically maintain the acknowledgment message broadcast queue according to the key-value pair.

13. The apparatus according to claim 8, characterized in that, The challenge message carries the identity code of the primary replica node. When all the challenge messages of the second program unit are concatenated into a challenge proof according to the sequence identity codes of their broadcast replica nodes, the identity code included in the challenge message is separated so that the challenge proof includes one of the identity codes.

14. The apparatus according to claim 8, characterized in that, The fourth program unit is further configured to: load the challenge proof and the confirmation proof into a first container and a second container respectively, wherein the volume of the first container and the second container can be dynamically adjusted; and determine whether the primary replica node has actually timed out in response to the consensus request based on the volume ratio of the first container and the second container.

15. The apparatus according to claim 14, characterized in that, The device further includes a determination generation unit, configured to determine that the primary replica node is actually responding to a consensus request timeout if the ratio of the volumes of the first container and the second container is between 0.7 and 1.

16. The apparatus according to claim 15, characterized in that, The determination generation unit is further used to: switch the primary replica node that has experienced the consensus request timeout to a new secondary replica node and add it to the view.

17. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores an executable program, and the processor executes the following steps when running the executable program: A primary replica node is identified to participate in the consensus process, and several secondary replica nodes with a consensus state are identified, wherein the primary replica node and the several secondary replica nodes are located in the same view; Collect the challenge messages broadcast by the slave replica nodes in the view that the primary replica node responded to the consensus request timeout, and count the number of slave replica nodes that broadcast the challenge messages. All challenge messages are concatenated into a challenge proof according to the sequence identifier code of the slave replica node that broadcast them. Collect the confirmation messages generated by the response to the challenge message broadcast by the replica node in the view, and count the number of replica nodes that broadcast the confirmation messages. All confirmation messages are concatenated into a confirmation certificate according to the sequence identifier code of the replica node that broadcast them. Based on the challenged proof and the confirmed proof, determine whether the primary replica node actually timed out in response to the consensus request; For each of the challenge messages, a challenge message digest is generated and combined with the sequence identifier of the replica node that broadcast the challenge message into a key-value pair; All challenge messages are concatenated into a challenge proof in the order of the sequence identifiers of the broadcast replica nodes, including: based on the key value, all challenge messages are concatenated into a challenge proof in the order of the sequence identifiers of the broadcast replica nodes; For each acknowledgment message, a acknowledgment message digest is generated and combined with the sequence identifier of the slave replica node broadcasting the acknowledgment message to form a key-value pair; all acknowledgment messages are concatenated into an acknowledgment certificate in the order of the sequence identifier codes of the slave replica nodes broadcasting them, including: based on the key value, all acknowledgment messages are concatenated into an acknowledgment certificate in the order of the sequence identifier codes of the slave replica nodes broadcasting them.

Images