CN111683118B

CN111683118B - Block chain-based consensus method and device, master node equipment and slave node equipment

Info

Publication number: CN111683118B
Application number: CN202010416733.9A
Authority: CN
Inventors: 陈志明; 姜鹏; 潘清雪
Original assignee: China Citic Bank Corp Ltd
Current assignee: China Citic Bank Corp Ltd
Priority date: 2020-05-16
Filing date: 2020-05-16
Publication date: 2023-07-11
Anticipated expiration: 2040-05-16
Also published as: CN111683118A

Abstract

The application is applicable to the field of blockchain, and provides a blockchain-based consensus method, a blockchain-based consensus device, a master node device and a slave node device, wherein the method comprises the following steps: and generating a configuration transaction block according to the configuration transaction request sent by the client. The configured transaction block is sent to each slave node. If the number of the voting results returned by each slave node is smaller than the preset threshold value in the first preset period, the voting results returned by each slave node are continuously received until the second preset period is finished. And if the number of the voting results returned by each slave node is received to be greater than or equal to a preset threshold value in a second preset period, sending out block information to the slave node. Responding to the configuration transaction request of the client and configuring the configuration transaction on the master node. So that there is more time to receive the voting results when the network performance is poor. Therefore, consensus failure caused by poor network performance and insufficient voting result collection is reduced, and the stability of the system is improved.

Description

Block chain-based consensus method and device, master node equipment and slave node equipment

Technical Field

The application belongs to the field of blockchains, and particularly relates to a blockchain-based consensus method, a blockchain-based consensus device, master node equipment and slave node equipment.

Background

Today, blockchain networks are often used when conducting configuration transactions. When the blockchain network is applied, consensus is needed through a consensus algorithm to ensure that the data packets of each node in the blockchain can be sufficiently synchronized.

The consensus may typically be performed using a master node based consensus algorithm. A master node is selected from the plurality of nodes, such as by a consensus algorithm, and is configured to perform block packing in a next round of consensus.

In the prior art, when the consensus failure occurs, the problem of the consensus failure is solved by switching the master node. However, failure of consensus may be due to synchronization problems caused by network performance. At this time, the problem of failure of consensus cannot be properly solved by merely switching the master node.

Disclosure of Invention

The embodiment of the application provides a block chain-based consensus method, a block chain-based consensus device, a master node device and a slave node device, which can solve the problem of consensus failure caused by network performance.

In a first aspect, an embodiment of the present application provides a blockchain-based consensus method, applied to a master node, including: and generating a configuration transaction block according to the configuration transaction request sent by the client. The configured transaction block is sent to each slave node. If the number of the voting results returned by each slave node is smaller than the preset threshold value in the first preset period, continuing to receive the voting results returned by each slave node until the second preset period is finished, wherein the voting results are used for indicating the slave node to accept the configuration transaction request in the configuration transaction block. And if the number of the voting results returned by each slave node is received to be greater than or equal to a preset threshold value in a second preset period, sending out block information to the slave node. Responding to the configuration transaction request of the client and configuring the configuration transaction on the master node.

Compared with the prior art, the embodiment of the application has the beneficial effects that: by continuously receiving the voting results transmitted from the nodes for the first preset period and the second preset period, more time can be available to receive the voting results when the network performance is poor. Therefore, consensus failure caused by poor network performance and insufficient voting result collection is reduced, and the stability of the system is improved.

In a second aspect, embodiments of the present application further provide a blockchain-based consensus method applied to a slave node, including: and receiving a configuration transaction block sent by the master node, wherein the configuration transaction block is generated by the master node according to a configuration transaction request sent by the client. And checking the validity of the configuration transaction block, and if the validity is legal, receiving a configuration transaction request in the configuration transaction block. And sending a voting result to the master node, wherein the voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block. If the block-out information sent by the master node is received, the configuration transaction is configured on the slave node.

In some embodiments, after sending the voting result to the master node, further comprising: if the block outlet information sent by the master node is not received in the third preset period, the block outlet information is continuously received until the fourth preset period is finished. And if the block-out information is not received in the fourth preset period, sending a master node switching request to each slave node except the current slave node.

In some embodiments, the method further comprises: a master node switch request is received. And if the block-out information is received, ignoring the main node switching request. If the block information is not received within the fourth preset period, determining one slave node as the master node from a plurality of slave nodes according to the master node switching request.

In a third aspect, an embodiment of the present application further provides a blockchain-based consensus device, applied to a master node, including: and the generating module is used for generating a configuration transaction block according to the configuration transaction request sent by the client. And the first sending module is used for sending the configuration transaction block to each slave node. And the consensus module is used for continuously receiving the voting results returned by each slave node until the second preset period is finished if the number of the voting results returned by each slave node is smaller than the preset threshold value in the first preset period, wherein the voting results are used for indicating the slave node to accept the configuration transaction request in the configuration transaction block. And the consensus module is further used for sending out block information to the slave nodes if the number of the voting results returned by each slave node is received to be greater than or equal to a preset threshold value in a second preset period. And the response module is used for responding to the configuration transaction request of the client and configuring the configuration transaction on the master node.

In a fourth aspect, embodiments of the present application further provide a blockchain-based consensus device applied to a slave node, including: and the receiving module is used for receiving the configuration transaction block sent by the master node, wherein the configuration transaction block is generated by the master node according to the configuration transaction request sent by the client. And the verification module is used for verifying the validity of the configuration transaction block, and if the validity is met, the configuration transaction request in the configuration transaction block is accepted. And the second sending module is used for sending a voting result to the master node, wherein the voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block. And the receiving module is also used for configuring the configuration transaction on the slave node if the block-out information sent by the master node is received.

In some embodiments, the receiving module is further configured to, if the block outgoing information sent by the master node is not received within the third preset period, continue to receive the block outgoing information until the fourth preset period ends. The second sending module is further configured to send a master node switching request to each slave node except the current slave node if no block-out information is received within a fourth preset period.

In some embodiments, the receiving module is further configured to receive a master node handover request. The device also comprises a switching module, which is used for ignoring the switching request of the master node if the block-out information is received. And the switching module is further used for determining one slave node from the plurality of slave nodes as the master node according to the master node switching request if the block-out information is not received within a fourth preset period.

In a fifth aspect, embodiments of the present application provide a master node device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method provided in the first aspect when executing the computer program.

In a sixth aspect, embodiments of the present application provide a slave node device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method provided in the second aspect when executing the computer program.

In a seventh aspect, embodiments of the present application provide a computer readable storage medium storing a computer program, which when executed by a processor implements a method provided by the first aspect.

In an eighth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program, where the computer program when executed by a processor implements a method provided by the second aspect.

In a ninth aspect, embodiments of the present application provide a computer program product for causing a terminal device to perform the method provided in the first aspect above when the computer program product is run on the terminal device.

In a ninth aspect, embodiments of the present application provide a computer program product for, when run on a terminal device, causing the terminal device to perform the method provided in the second aspect above.

It will be appreciated that the advantages of the second to tenth aspects may be found in the relevant description of the first aspect and are not described here again.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required for the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic illustration of an application scenario of a blockchain-based consensus method;

FIG. 2 is a signaling diagram of a blockchain-based consensus method;

FIG. 3 is a flow chart of a consensus method provided in an embodiment of the present application;

FIG. 4 is a flow chart of a consensus method provided in another embodiment of the present application;

FIG. 5 is a signaling diagram of a consensus method provided by an embodiment of the present application;

FIG. 6 is a flow chart of a consensus method provided in another embodiment of the present application;

FIG. 7 is a flow chart of a consensus method provided in another embodiment of the present application;

FIG. 8 is a signaling diagram of a consensus method provided by another embodiment of the present application;

FIG. 9 is a schematic diagram of a block chain based consensus device according to an embodiment of the present application;

FIG. 10 is a schematic block chain based consensus device according to an embodiment of the present application;

FIG. 11 is a schematic block chain based consensus device according to another embodiment of the present application;

fig. 12 is a schematic structural diagram of a master node device according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a slave node device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in this specification and the appended claims, the term "if" may be construed as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if determined" may be interpreted as meaning "upon determination" or "in response to determination" depending on the context.

In addition, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise.

Fig. 1 is a schematic diagram of an application scenario of a blockchain-based consensus method.

Referring to fig. 1, the scenario includes: a plurality of clients 11, a master node 12, a plurality of slave nodes 13. Wherein the client 11 may be communicatively connected to the master node and/or the slave node via a network, each node being communicatively connected to the other nodes, respectively. The client 11 may be a terminal device, a mobile device, a server, etc. For example, the system can be a desktop computer, a mobile phone and a cloud server, and is not limited herein.

In this scenario, consensus is made by using the bayer fault tolerance system (Practical Byzantine Fault Tolerance, PBFT). Referring to fig. 2, in the consensus algorithm, it includes:

(1) The client sends a request to the master node.

(2) In the pre-preparation phase, the master node packages the blocks, broadcasts the blocks and shares the same throughout the network.

(3) In the preparation stage, the master node collects voting information of the whole network.

(4) After the master node collects the voting results and exceeds 2f identical results, the confirmation block can be output, and the master node directly responds.

(5) The master node responds to the client.

However, in the existing flow, when the network performance is poor, the master node cannot receive the voting result in time, so that the slave node cannot receive the block and times out, and the master node is triggered to be switched. However, switching the master node does not improve the timeout due to poor network performance, but rather can put stress on the system.

For this reason, the present application provides a blockchain-based consensus method to solve the problem of consensus failure caused by network performance.

Fig. 3 shows a schematic flow chart of a blockchain-based consensus method provided herein, which may be applied, by way of example and not limitation, in the master node described above. The method comprises the following steps:

s21, generating a configuration transaction block according to the configuration transaction request sent by the client.

In some embodiments, transactions are allocated at fixed locations in each block, and when there are allocated transactions within a block, the block is an allocated transaction block.

Preferably, the 1 st transaction in the transaction set may be regarded as a configuration transaction (index 0). When no transaction is configured, the transaction information therein is "Null". Otherwise, it is { configure sequence number (number), multi-level time threshold { t0, t1, t2, … }, transaction initiator, signature, transaction time }. Wherein the index in the transaction set is used to indicate the type of transaction, for example, an index of 0 indicates that the transaction is a configuration transaction, including configuration data. If the index is not 0, the transaction is a common transaction, and transaction data is contained.

The configuration data may be as shown in the following table:

the configuration data for the configuration transaction may be: {11, {5, 10, 15}, zhangsan, electronic signature, 20200316}.

It should be noted that, the configuration transaction information may be directly sent to the master node by the client, or may be sent to the slave node by the client first, and then forwarded to the master node by the slave node, which is not limited herein.

S22, sending the configuration transaction block to each slave node.

Wherein the transaction block is sent to each slave node for broadcasting a consensus request to nodes of the whole network. The consensus request refers to requesting each node of the whole network to perform consensus on the received blocks, and if the consensus voting result accords with a preset threshold value, successful consensus is confirmed.

And S23, if the number of the voting results returned by each slave node is smaller than the preset threshold value in the first preset period, continuing to receive the voting results returned by each slave node until the second preset period is finished.

The voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block.

In some embodiments, the first preset period may have a plurality of periods. For example, if the first preset time period is 5 seconds, and the number of the first preset time periods is 3, three first preset time periods of 5 seconds may be obtained by using 3 timers. If the first timer counts 5 seconds, the second timer counts 10 seconds, and the third timer counts 15 seconds. There is no limitation in this regard.

In some embodiments, the second preset period may be the same as the first preset period. The second preset period of time may also be implemented using a timer. For example, if the second preset period is also 5 seconds, a fourth timer may be used to set the timing for 20 seconds. The fourth timer counts while the first timer starts counting.

And S24, if the number of the voting results returned by each slave node is received to be greater than or equal to a preset threshold value in a second preset period, sending out block information to the slave node.

In some embodiments, if the number of voting results received is greater than or equal to a preset threshold, then the success of the whole network consensus is confirmed, i.e. all nodes should accept the configuration transaction.

At this point, the timer in S23 may be incremented and then block information may be sent out to each slave node indicating that each slave node is to configure the configuration transaction.

S25, responding to the configuration transaction request of the client, and configuring corresponding configuration transactions on the master node.

In this embodiment, by continuously receiving the voting result transmitted from the node in the first preset period and the second preset period, more time can be allowed to receive the voting result when the network performance is poor. Therefore, consensus failure caused by poor network performance and insufficient voting result collection is reduced, and the stability of the system is improved.

Accordingly, FIG. 4 shows a schematic flow chart of a blockchain-based consensus method provided herein, which may be applied to the slave nodes described above by way of example and not limitation. The method comprises the following steps:

s31, receiving a configuration transaction block sent by the master node, wherein the configuration transaction block is generated by the master node according to a configuration transaction request sent by the client.

S32, verifying the validity of the configuration transaction block, and if the validity is met, receiving a configuration transaction request in the configuration transaction block.

In some embodiments, the received configuration transaction block is a block to be agreed, and the block includes a configuration sequence number and a multi-stage time configuration, referring to S21. If the received configuration serial number of the configuration transaction block is greater than the configuration serial number of the current node and the multi-stage time is configured to be increased, determining that the configuration transaction block is legal. For example, the received configuration information is configuration information {11, {5, 10}, zhangsan, electronic signature, 20200316}, where the configuration sequence number is 11 and the multi-level time is configured {5, 10}. The multi-stage time is configured to increment, and if the configuration serial number of the current system is 10, the configuration transaction block is confirmed to be legal.

And S33, sending a voting result to the master node, wherein the voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block.

If the configuration transaction block is legal, the slave node receives the configuration transaction request.

And S34, if the block-out information sent by the master node is received, configuring the transaction on the slave node.

Wherein configuring the transaction request includes updating the multi-level time configuration of the slave node, deleting other transactions having configuration sequence numbers less than the configuration transaction configuration sequence number.

Referring to fig. 5, fig. 5 shows a signaling diagram when PBFT is utilized for consensus. Wherein the multi-level time is configured as {5, 10}.

In fig. 5, due to network congestion, extended delays are required to accommodate the network conditions. In fig. 5, the steps of consensus include:

(1) In the consensus confirmation stage, the master node collects voting results and starts a timing module.

(2) In this case, most slave nodes of the whole network timeout due to network performance and the like, and most slave nodes determine the next parameter threshold value 10s, that is, wait for 5s again.

(3) If the master node receives enough consensus information within the second parameter threshold 10s, the acknowledgement block may be blocked and the timer stops counting. And is responded directly by the master node.

(4) The master node responds to the client.

(5) All slave nodes continue to operate normally.

Fig. 6 is a schematic flow chart of a consensus method according to another embodiment of the present application.

And S41, if the block outlet information sent by the main node is not received in the third preset period, continuing to receive the block outlet information until the fourth preset period is finished.

And S42, if the block information is not received within a fourth preset period, sending a master node switching request to each slave node except the current slave node.

The third preset period in S41 is set in the same manner as the first preset period in S23. The fourth preset period in S41 is set in the same manner as the second preset period in S23. And will not be described in detail herein.

Fig. 7 is a schematic flow chart of a consensus method according to another embodiment of the present application.

S43, receiving a master node switching request.

In some embodiments, since there are a plurality of slave nodes, each slave node may receive a master node switch request sent by another slave node. When a master node switch request is received, there are two possibilities, the first is that the current master node is in error and fails to send out block information. Or, the slave node sending the master node switching request is in error, and cannot receive the block-out information.

S44, if the block information is received, the main node switching request is ignored.

In some embodiments, if the current slave node receives the block information when receiving the master node switching request, it indicates that the master node is not in error, and determines that the master node is in error as the slave node that sends the master node switching request. Thus, the master node switch request is ignored.

S45, if the block information is not received within a fourth preset period, determining one slave node from a plurality of slave nodes as a master node according to the master node switching request

In some embodiments, if the block out information is not received within the fourth preset period, it indicates that the master node fails to send the block out information, and the master node makes an error. At this time, one master node may be newly determined from among the plurality of slave nodes.

Referring to fig. 8, fig. 8 shows a signaling diagram when PBFT is utilized for consensus. Wherein the multi-level time is configured as {5, 10}.

In fig. 8, the master node fails, resulting in failure to send out the block information, and then includes the following steps:

(1) In the consensus confirming stage, the master node collects voting results and confirms that the block is out of block.

(2) The slave node starts a timing module which comprises two timers, the first timer is set to be 5s timeout and the second timer is set to be 10s timeout.

(3) The slave node will not go out of block due to the failure of the master node within the first timer 5 s; and after overtime, entering the next threshold value for judgment.

(4) The slave node still does not receive blocks in the second timer 10s due to the failure of the master node; after timeout, the slave node stops all timers and triggers the final timeout signal.

(5) The system calls a view change method to switch the master node.

(6) Since most nodes in the whole network switch the master nodes, a new master node is inevitably generated, and finally the new master node responds to the client, and the client retransmits the transaction.

In yet another embodiment, the processing step includes if the slave node fails.

(2) The slave node currently starts a timing module, which comprises two timers, wherein the first timer is set to be 5s overtime, and the second timer is set to be 10s overtime.

(3) The current slave node does not receive the block due to the fault within the first timer 5 s; and after overtime, entering the next threshold value for judgment.

(4) The current slave node still does not receive blocks due to failure within the second timer 10 s; and still overtime, i.e. the complete timer is counted.

(5) The current slave node calls a view change method and switches the master node.

(6) Because other nodes of the whole network work normally, the switching of the master node is not performed, so that the switching of the master node of the node fails, and the current node can be determined to be a fault of the current node.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.

Corresponding to the blockchain-based consensus method applied to the master node described in the above embodiments, fig. 9 shows a block diagram of a blockchain-based consensus device applied to the master node provided in the embodiments of the present application, and for convenience of explanation, only a portion relevant to the embodiments of the present application is shown. Referring to fig. 9, the apparatus includes:

the generating module 61 is configured to generate a configuration transaction block according to the configuration transaction request sent by the client.

A first transmitting module 62 is configured to transmit the configured transaction block to each slave node. And the consensus module is used for continuously receiving the voting results returned by each slave node until the second preset period is finished if the number of the voting results returned by each slave node is smaller than the preset threshold value in the first preset period, wherein the voting results are used for indicating the slave node to accept the configuration transaction request in the configuration transaction block.

The consensus module 63 is further configured to send out block information to the slave node if the number of voting results returned by each slave node is received to be greater than or equal to a preset threshold value within a second preset period.

The response module 64 is configured to respond to the configuration transaction request of the client and configure the configuration transaction on the master node.

Corresponding to the blockchain-based consensus method applied to the master node described in the above embodiments, fig. 10 shows a block diagram of a blockchain-based consensus device applied to the slave node provided in the embodiment of the present application, and for convenience of explanation, only a portion relevant to the embodiment of the present application is shown. Referring to fig. 10, the apparatus includes:

the receiving module 71 is configured to receive a configuration transaction block sent by the master node, where the configuration transaction block is generated by the master node according to a configuration transaction request sent by the client.

The verification module 72 is configured to verify the validity of the configured transaction block, and if the validity is verified, accept the configured transaction request in the configured transaction block.

A second sending module 73, configured to send a voting result to the master node, where the voting result is used to instruct the slave node to accept the configuration transaction request in the configuration transaction block.

The receiving module 71 is further configured to configure the configuration transaction on the slave node if the outbound information sent by the master node is received.

In some embodiments, the receiving module 71 is further configured to, if the outgoing block information sent by the master node is not received within the third preset period, continue to receive the outgoing block information until the fourth preset period ends. The second sending module 73 is further configured to send a master node switching request to each slave node except the current slave node if no block information is received within the fourth preset period.

In some embodiments, the receiving module 71 is further configured to receive a master node handover request. Referring to fig. 11, the apparatus further includes a switching module 74 for ignoring the master node switching request if the out-block information is received. The switching module 74 is further configured to determine, if the block out information is not received within the fourth preset period, one slave node from the plurality of slave nodes as the master node according to the master node switching request.

It should be noted that, because the content of information interaction and execution process between the modules is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and details are not repeated herein.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

The embodiment of the application provides a master node device, which comprises a memory, a processor, a camera and a computer program stored in the memory and capable of running on the processor, wherein the processor realizes the block chain-based consensus method applied to the master node device when executing the computer program.

Fig. 12 is a schematic structural diagram of a master node device according to an embodiment of the present application. As shown in fig. 12, the master node device 8 includes: at least one processor 81 (only one shown in fig. 12), a memory 82, and a computer program 83 stored in the memory 82 and executable on the at least one processor 81, the steps of the master node device-based attendance method applied to the master node device described above being implemented when the processor 81 executes the computer program 83.

The master node device 8 may be a server, desktop computer, mobile terminal, or the like capable of running blockchain clients. The master node device 8 may include, but is not limited to, a processor 81, a memory 82. It will be appreciated by those skilled in the art that fig. 12 is merely an example of the master node device 8 and is not meant to be limiting as to the master node device 8, and may include more or fewer components than shown, or may combine certain components, or may include different components, such as input-output devices, network access devices, etc.

The processor 81 may be a central processing unit (Central Processing Unit, CPU), the processor 81 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 82 may in some embodiments be an internal storage unit of the master node device 8, such as a hard disk or memory of the master node device 8. The memory 82 may also be an external storage device of the host node device 8 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the host node device 8. Further, the memory 82 may also include both an internal storage unit and an external storage device of the master node device 8. The memory 82 is used to store an operating system, application programs, boot loader (BootLoader), data, and other programs, etc., such as program code for a computer program, etc. The memory 82 may also be used to temporarily store data that has been output or is to be output.

Fig. 13 is a schematic structural diagram of a slave node device according to an embodiment of the present application. As shown in fig. 13, the slave node device 9 includes: at least one processor 91 (only one shown in fig. 13), a memory 92, and a computer program 93 stored in the memory 92 and executable on the at least one processor 91, the processor 91 executing the computer program 93 implementing the steps of the blockchain based consensus method as described above as applied to slave node devices.

The slave node device 9 may be a slave node device such as a tower slave node device, a cloud slave node device, a virtual slave node device, or the like. Slave node device 9 may include, but is not limited to, a processor 91, a memory 92. It will be appreciated by those skilled in the art that fig. 13 is merely an example of the slave node device 9 and is not meant to be limiting of the slave node device 9, and may include more or fewer components than shown, or may combine certain components, or may include different components, such as input-output devices, network access devices, etc.

The processor 91 may be a central processing unit (Central Processing Unit, CPU), the processor 91 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 92 may in some embodiments be an internal storage unit of the slave node device 9, such as a hard disk or a memory of the slave node device 9. The memory 92 may also be an external storage device of the slave node device 9 in other embodiments, for example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the slave node device 9. Further, the memory 92 may also include both an internal storage unit of the slave node device 9 and an external storage device. The memory 92 is used to store an operating system, application programs, boot loader (BootLoader), data, and other programs, etc., such as program code of a computer program, etc. The memory 92 may also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor implements the above-mentioned consensus method applied to a master node.

Another embodiment of the present application further provides a computer readable storage medium storing a computer program, which when executed by a processor, implements the above consensus method applied to a slave node.

An embodiment of the present application provides a computer program product which, when run on a terminal device, causes the terminal device to perform the above-described consensus method for a master node.

Another embodiment of the present application also provides a computer program product which, when run on a terminal device, causes the terminal device to perform the above-described consensus method applied to a slave node.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application implements all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a master node or a slave node, a recording medium, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the above-described embodiments of methods, apparatus, master nodes and slave nodes are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. A blockchain-based consensus method, comprising: the master node performs the following steps:

generating a configuration transaction block according to a configuration transaction request sent by a client;

transmitting the configured transaction block to each slave node;

if the number of the voting results returned by each slave node is smaller than a preset threshold value in a first preset period, continuing to receive the voting results returned by each slave node until a second preset period is finished, wherein the voting results are used for indicating the slave node to accept the configuration transaction request in the configuration transaction block;

if the number of voting results returned by each slave node is received to be greater than or equal to the preset threshold value in a second preset period, block information is sent out to the slave node;

responding to the configuration transaction request of the client and configuring the configuration transaction on a master node;

the slave node performs the following steps:

receiving a configuration transaction block sent by a master node, wherein the configuration transaction block is generated by the master node according to a configuration transaction request sent by a client;

verifying the validity of the configuration transaction block, and if the validity is legal, receiving a configuration transaction request in the configuration transaction block;

sending a voting result to the master node, wherein the voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block;

and if the block outlet information sent by the master node is received, configuring the configuration transaction on the slave node.

2. The method of claim 1, further comprising, after sending the voting results to the master node:

if the block outlet information sent by the master node is not received in the third preset period, continuing to receive the block outlet information until the fourth preset period is finished;

and if the block-out information is not received within the fourth preset period, sending a master node switching request to each slave node except the current slave node.

3. The method according to claim 2, wherein the method further comprises:

receiving the master node switching request;

if the block-out information is received, ignoring the master node switching request;

and if the block-out information is not received in the fourth preset period, determining one slave node from a plurality of slave nodes as the master node according to the master node switching request.

4. A blockchain-based consensus system comprising a master node and a slave node, the master node comprising the following modules:

the generation module is used for generating a configuration transaction block according to a configuration transaction request sent by the client;

the first sending module is used for sending the configuration transaction block to each slave node;

the consensus module is used for continuously receiving the voting results returned by each slave node until the second preset time period is over if the number of the voting results returned by each slave node is smaller than a preset threshold value in the first preset time period, wherein the voting results are used for indicating the slave node to accept the configuration transaction request in the configuration transaction block;

the consensus module is further configured to send block information to the slave nodes if the number of voting results returned by each slave node is received to be greater than or equal to the preset threshold value in a second preset period;

the response module is used for responding to the configuration transaction request of the client and configuring the configuration transaction on the master node;

the slave node comprises the following modules:

the receiving module is used for receiving a configuration transaction block sent by the master node, wherein the configuration transaction block is generated by the master node according to a configuration transaction request sent by the client;

the verification module is used for verifying the validity of the configuration transaction block, and if the validity is legal, the configuration transaction request in the configuration transaction block is accepted;

the second sending module is used for sending a voting result to the master node, wherein the voting result is used for indicating the slave node to accept the configuration transaction request in the configuration transaction block;

the receiving module is further configured to configure the configuration transaction on the slave node if the block-out information sent by the master node is received.

5. The system of claim 4, wherein the receiving module is further configured to, if the outbound information sent by the master node is not received within a third preset period of time, continue to receive the outbound information until a fourth preset period of time ends;

the second sending module is further configured to send a master node switching request to each slave node except the current slave node if the block-out information is not received within a fourth preset period.

6. The system of claim 5, wherein the receiving module is further configured to receive the master node switch request;

the device also comprises a switching module, which is used for ignoring the switching request of the master node if the block-out information is received;

and the switching module is further configured to determine, if the block-out information is not received within a fourth preset period, one slave node from among a plurality of slave nodes as the master node according to the master node switching request.

7. A node device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of claim 1 when executing the computer program.