WO2023134159A1 - Consensus method and apparatus based on blockchain network, electronic device and storage medium - Google Patents

Abstract

The present application provides a consensus method based on a blockchain network. Any consensus node in the blockchain network locally maintains system configuration information, the system configuration information comprising a member node set. The method comprises: an instruction initiating node broadcasting an instruction to the blockchain network, such that the blockchain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal, wherein the instruction comprises a member configuration instruction; and after any member node in the blockchain network determines that a consensus is reached for the consensus proposal, if the consensus proposal comprises the member configuration instruction, updating the locally-maintained system configuration information according to the member configuration instruction. By means of adoption of the described method, the member node in the blockchain network takes the member configuration instruction and a conventional instruction as a consensus proposal for consensus, namely, the member configuration process can be executed without stopping the consensus process, so that the consensus efficiency of the blockchain network is greatly improved.

Description

A consensus method, device, electronic equipment and storage medium based on blockchain network

Cross References to Related Applications

This application is based on a Chinese patent application with application number 202210046656.1 and a filing date of January 17, 2022, and claims the priority of this Chinese patent application. The entire content of this Chinese patent application is hereby incorporated by reference into this application.

technical field

The present application relates to the field of computer technology, in particular, to a blockchain network-based consensus method, device, electronic equipment, and storage medium.

Background technique

In order to ensure data consistency, each consensus node in the blockchain network usually needs to achieve consensus through various consensus methods. When the consensus node in the blockchain network wants to withdraw from the blockchain network, or When a node wants to join the blockchain network, usually the consensus process of the blockchain network will be stopped, and the node joining or exiting process will be started, and the consensus process will not continue until the corresponding node joins or exits, which greatly reduces the blockchain The consensus efficiency of the network.

Contents of the invention

The embodiment of the present application provides a blockchain network-based consensus method, device, electronic equipment, and storage medium to solve the problem of low consensus efficiency in the prior art.

In order to achieve the above object, the application provides the following technical solutions:

According to the first aspect of the embodiment of the present application, a consensus method based on a blockchain network is provided. Any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the method comprising:

The instruction initiating node broadcasts an instruction carrying a system configuration number to at least some member nodes in the blockchain network; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to instruct the instruction initiating node to join or remove remove said blockchain network;

Any slave node in the blockchain network forwards the instruction according to the system configuration number carried in the instruction and the locally maintained system configuration number;

After receiving the instruction and generating a consensus proposal including the instruction, the master node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal according to the local system configuration number; the consensus proposal includes membership configuration directives and/or general directives;

After any member node in the blockchain network determines that a consensus has been reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, then update the locally maintained system configuration information according to the member configuration instruction.

In the above solution, the system configuration number carried in the instruction is used to identify the system configuration targeted by the instruction;

Any slave node in the blockchain network forwards the instruction according to the system configuration number carried in the instruction and the locally maintained system configuration number, including:

If the instruction is not executed locally, if it is determined that the system configuration number is the same as the locally stored system configuration number, then forward the member configuration instruction to the master node; if it is determined that the system configuration number is smaller than the locally stored system configuration number , forward the instruction to the member nodes in the locally maintained member node set;

When the instruction is executed locally, the execution result and system configuration history information are returned to the instruction originating node.

In the above scheme, the method also includes:

After the master node receives the instruction, it stores the instruction in the local instruction pool;

Said generating a consensus proposal comprising said instructions, comprising:

Obtain a preset number of instructions from the local instruction pool;

For any member configuration instruction in the preset number of instructions, if the member configuration instruction is used to indicate that the instruction originating node that will initiate the instruction joins the blockchain network, assign a member node serial number to the instruction originating node , combining the member node serial number and the member configuration instruction into a member joining instruction; if the member configuration instruction is used to indicate that the instruction originating node that will initiate the instruction withdraws from the blockchain network, then the instruction originating node The combination of the member node serial number and the member configuration instruction is a member exit instruction;

For the preset number of instructions, the member join instruction, member exit instruction and regular instructions are packaged into a consensus proposal.

In the above scheme, the method also includes:

After assigning a member sequence number to the instruction initiating node, adding the instruction initiating node to a temporary member set; the temporary member set includes all member nodes in the local system configuration;

The coordinating other nodes to perform consensus processing on the consensus proposal, including:

broadcasting a pre-preparation message to nodes in the temporary membership set based on the consensus proposal;

Any slave node, after receiving a valid pre-preparation message, for the member joining instruction in the consensus proposal, adds the member node serial number in the member joining instruction to the local temporary member set, and sends the local temporary member The nodes in the set broadcast a preparation message for the consensus proposal; the preparation message carries the signature of the slave node;

Any member node, after receiving the preparation message for the consensus proposal broadcast by 2/3 member nodes in the member node set configured by the local system, stores the signature of the received preparation message as the proof of the consensus proposal, And broadcast the commitment message for the consensus proposal, or, after receiving the commitment message for the consensus proposal broadcast by 1/3 member nodes in the set of member nodes configured by the local system, use the signature of the received commitment message as Store the proof of the consensus proposal, and broadcast a commitment message for the consensus proposal; wherein, the commitment message carries the signature of the node;

After receiving the commitment message for the consensus proposal broadcast by 2/3 member nodes in the set of member nodes configured by the local system, it is determined that a consensus is reached for the consensus proposal, and the consensus proposal is executed.

In the above scheme, the method also includes:

Any slave node, after adding the member node serial number in the member joining command to the temporary member group, in the case that the system configuration number carried in the member joining command is smaller than the local system configuration number, send the node to the command corresponding to the member node serial number Send local system configuration information and system configuration history information;

After the instruction initiating node receives the system configuration information and the system configuration history information, it verifies the received system configuration information according to the system configuration history information, and after the verification is passed, it verifies the system configuration information according to the received system configuration history information. The local system configuration information is updated; the system configuration history information is a set of target consensus proposals, wherein the target consensus proposals are consensus proposals including member joining instructions or member exit instructions.

In the above scheme, the system configuration history information includes the proof of each target consensus proposal;

The verification of the received system configuration information according to the system configuration history information includes:

The target proposal is verified based on the proof in the system configuration history information, and when all target proposals pass the verification, it is determined that the system configuration history information and the system configuration information pass the verification.

In the above solution, updating the locally maintained system configuration information according to the member configuration instruction includes:

After reaching a consensus on the consensus proposal, any node in the blockchain network will add the member node serial number in the member joining instruction to the locally maintained system configuration information for any member joining instruction in the consensus proposal In the set of member nodes in ;

For any member exit instruction in the consensus proposal, remove the member node serial number in the member exit instruction from the member node set in the locally maintained system configuration information;

Update the system configuration number.

In the above scheme, the method also includes:

Any node in the blockchain network adds the consensus proposal to the system configuration history information;

Return the member configuration processing result to the initiating node corresponding to the member configuration instruction included in the consensus proposal; wherein, the member configuration instruction is used to indicate that the instruction initiating node of the instruction is added to the blockchain network;

After receiving the configuration processing results sent by 2/3 member nodes, the instruction originating node of any member configuration instruction can determine that the instruction has been executed, and determine to join the blockchain network locally.

In the above scheme, the method also includes:

The instruction initiating node of any member configuration instruction, after storing the proof of the consensus proposal during the consensus process, if the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to indicate that the If the initiating node is instructed to withdraw from the blockchain network, it is determined to withdraw locally from the blockchain network.

In the above scheme, the method also includes:

The instruction initiating node of any member configuration instruction determines that the consensus proposal is executed, and the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to instruct the instruction initiating node from the If the block chain network exits, it is determined that the local exits from the block chain network.

In the above scheme, the method also includes:

Any node in the blockchain network for any conventional command in the consensus proposal, after the local execution is completed, if it is determined that the system configuration number in the command is the same as the local system configuration number, it will initiate a The node returns the processing result;

If it is determined that the system configuration number in the command is smaller than the local system configuration number, the processing result and system configuration history information will be returned to the command originating node of the command.

In the above scheme, the method also includes:

Any slave node obtains system configuration information when it detects that the view switching condition is met;

If the obtained system configuration number is the same as the locally maintained system configuration number, broadcast the view switching command to the member nodes in the locally maintained member node set;

If the obtained system configuration number is greater than the locally maintained system configuration number, broadcast a historical data acquisition message to the member nodes in the member node set corresponding to the acquired system configuration number; wherein, the historical data acquisition message carries the locally maintained system configuration number;

Any member node in the member node set, after receiving the historical data acquisition message, if it is determined that the system configuration number carried in it is smaller than the local system configuration number, and the node sending the historical data acquisition message is a locally maintained member node A node in the set returns a response message to the node for the historical data acquisition message; wherein, the response message carries all the consensus proposals executed by the member node;

When the slave node receives the response message returned by 1/3 of the member nodes in the member node set, and the information carried in the response message is the same, it updates the local data according to the response message.

In the above scheme, the method also includes:

Any slave node, when it detects that the view switching condition is met, broadcasts a view switching instruction to the member nodes in the locally maintained member node set; the view switching message carries the target system configuration number;

Any slave node forwards the view switching message according to the target system configuration number after receiving the view switching message broadcast by other nodes;

When the master node receives the view switching message sent by 2/3 nodes in the locally maintained system configuration member node set, it broadcasts a new view message to all member nodes of the locally maintained system configuration, so that the system configuration The nodes in the member node collection of the enter into the new view.

In the above solution, the forwarding of the view switching message according to the target system configuration number includes:

After any slave node receives the view switching message broadcast by other nodes, if it determines that the target system configuration number in the view switching message is smaller than the local system configuration number, and the member nodes corresponding to the local system configuration number are more than the target system configuration number The corresponding member node forwards the view switching message to the first node; wherein the first node includes nodes in the member node set configured by the local system but not in the member node set configured by the target system;

If it is determined that the target system configuration number in the view switching message is greater than the local system configuration number, then the local system configuration is updated to the system configuration corresponding to the target system configuration number. Forward the view switch message to a second node, which is a node included in the member node set configured by the target system but not in the member node set configured by the local system; no view switch has been sent locally in this round In the case of a message, the view switching message is forwarded to all nodes corresponding to the target system configuration number.

In the above solution, the view switching conditions include:

After a consensus is reached on the consensus proposal, and the consensus proposal includes a member configuration instruction.

According to the second aspect of the embodiment of the present application, a consensus method based on a blockchain network is provided, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes the The set of member nodes of the block chain network and the system configuration number used to identify the system configuration; the method includes:

Broadcast an instruction carrying a system configuration number to at least some member nodes in the blockchain network, so that the blockchain network generates a consensus proposal including the instruction and performs consensus processing on the consensus proposal according to the system configuration number; wherein, the The instructions include member configuration instructions or general instructions, and the member configuration instructions are used to instruct the instruction originating node to join or remove from the blockchain network.

According to the third aspect of the embodiment of the present application, a consensus method based on a blockchain network is provided, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the method comprising:

After receiving the instruction sent by the instruction originating node, the instruction is forwarded according to the system configuration number carried in the instruction and the locally maintained system configuration number; wherein the instruction includes a member configuration instruction or a regular instruction;

Consensus processing is performed on the consensus proposal including the instructions; the consensus proposal includes member configuration instructions and/or general instructions;

After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.

According to the fourth aspect of the embodiment of the present application, a consensus method based on a block chain network is provided, any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the method comprising:

After receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction, coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number; wherein the instruction includes member configuration instructions or regular instructions ; The consensus proposal includes member configuration instructions and/or general instructions;

After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.

According to the fifth aspect of the embodiment of the present application, a blockchain network-based consensus system is provided, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes member A collection of nodes and a system configuration number identifying a system configuration; the system includes:

The instruction originating node is used to broadcast the instruction carrying the system configuration number to at least some member nodes in the blockchain network; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to instruct the instruction originating node to join or leave said blockchain network;

Any slave node in the blockchain network is used to forward the instruction according to the system configuration number carried in the instruction and the system configuration number maintained locally;

The master node in the blockchain network is used to coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number after receiving the instruction and generating a consensus proposal including the instruction; the consensus Proposals include membership directives and/or general directives;

Any node in the blockchain network is configured to update locally maintained system configuration information according to the member configuration instruction after determining that a consensus has been reached on the consensus proposal, if the consensus proposal includes a member configuration instruction.

According to the sixth aspect of the embodiment of the present application, a consensus device based on a block chain network is provided, any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the means include:

The obtaining module is used to obtain system configuration information;

The broadcast module updates the local system configuration information according to the acquired system configuration information, and broadcasts instructions carrying system configuration numbers to at least some member nodes in the blockchain network according to the updated system configuration information, so that the blockchain network Generate a consensus proposal including the instruction and perform consensus processing on the consensus proposal according to the system configuration number; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to indicate that the instruction originating node joins or withdraws from the blockchain network.

According to the seventh aspect of the embodiments of the present application, a consensus device based on a blockchain network is provided, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the means include:

The forwarding module is configured to forward the instruction according to the system configuration number carried in the instruction and the locally maintained system configuration number after receiving the instruction sent by the instruction initiating node; wherein the instruction includes a member configuration instruction or general order;

A consensus module, configured to perform consensus processing on the consensus proposal including the instructions; the consensus proposal includes member configuration instructions and/or regular instructions;

An update module, configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.

According to an eighth aspect of the embodiments of the present application, a consensus device based on a blockchain network is provided, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes member A set of nodes and a system configuration number for identifying the system configuration; the means include:

The consensus module is used to coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number after receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction; wherein the instruction includes Member configuration instructions or regular instructions; the consensus proposal includes member configuration instructions and/or regular instructions;

An update module, configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.

According to a ninth aspect of the embodiments of the present application, there is provided a computer device, including a memory, a processor, a communication interface, and a computer program stored in the memory and operable on the processor, wherein the processor executes the When the program is described above, the method described in any one of the second to fourth aspects above is realized.

According to a tenth aspect of the embodiments of the present application, there is provided a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, any one of the above-mentioned second to fourth aspects can be realized. method described in the aspect.

Using the consensus method provided in the embodiment of this application, nodes that need to join or exit the blockchain network can broadcast member configuration instructions to the blockchain network after obtaining the system configuration information of the current blockchain network. It is used to indicate that the node is added or removed from the blockchain network. The member nodes in the blockchain network use the member configuration instructions together with regular instructions as a consensus proposal for consensus. After each consensus node reaches a consensus based on the consensus proposal, that is, The member configuration command can be executed without processing the member configuration command separately from the regular command, that is, the member configuration process can be executed without stopping the consensus process, thus greatly improving the consensus efficiency of the blockchain network.

Description of drawings

The drawings described here are used to provide a further understanding of the application and constitute a part of the application. The schematic embodiments and descriptions of the application are used to explain the application and do not constitute an improper limitation to the application. In the attached picture:

FIG. 1 is a schematic diagram of a network architecture topology according to an embodiment of the specification;

FIG. 2 is a schematic flow diagram of a consensus method based on a blockchain network according to an embodiment of this specification;

FIG. 3 is a schematic diagram of adding a node to a blockchain network according to an embodiment of this specification;

FIG. 4 is a schematic diagram of a consensus method based on a blockchain network according to an embodiment of this specification;

FIG. 5 is a schematic structural diagram of system configuration history information according to an embodiment of this specification;

FIG. 6 is a schematic diagram of view switching message forwarding according to an embodiment of this specification;

FIG. 7 is a schematic diagram of another view switching message forwarding according to the embodiment of this specification;

FIG. 8 is a schematic structural diagram of a consensus device based on a blockchain network according to an embodiment of this specification;

FIG. 9 is a schematic structural diagram of another consensus device based on a blockchain network according to an embodiment of this specification;

FIG. 10 is a schematic structural diagram of another consensus device based on a blockchain network according to an embodiment of this specification;

Fig. 11 is a schematic structural diagram of a device for configuring the device of the embodiment of this specification.

Detailed ways

The blockchain network is a distributed data storage network. Each node in the blockchain network needs to ensure data consistency. Each node needs to achieve consensus through various consensus methods. Consensus refers to the process by which each node reaches data consistency.

When a consensus node in the blockchain network wants to exit the blockchain network, or a node outside the blockchain network wants to join the blockchain network, usually the consensus process of the blockchain network will be stopped and execution will start In the process of node joining or exiting, the consensus process will not continue until the corresponding node joins or exits, which greatly reduces the consensus efficiency of the blockchain network. Among them, the consensus process usually refers to the consensus on regular instructions.

In view of the above problems, the embodiment of this application provides a consensus method based on the blockchain network. When a node needs to join or withdraw from the blockchain network, it can broadcast member configuration instructions to the blockchain network. The instructions are used to indicate The node joins or exits the blockchain network, and the consensus node in the blockchain network uses the member configuration instructions together with regular instructions as a consensus proposal for consensus. After each consensus node reaches a consensus based on the consensus proposal, it can execute the member configuration instruction. Configuration instructions do not need to process member configuration instructions and regular instructions separately, that is, the member configuration process can be processed without stopping the consensus process for regular instructions, thus greatly improving the consensus efficiency of the blockchain network.

The solutions in the embodiments of the present application can be realized by using various computer languages, for example, the object-oriented programming language Java and the literal translation scripting language JavaScript.

In order to make the technical solutions and advantages in the embodiments of the present application clearer, the exemplary embodiments of the present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, and Not an exhaustive list of all embodiments. It should be noted that, in the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

In order for those skilled in the art to understand this solution more clearly, some names appearing in this manual are explained below:

In this specification, the nodes in the blockchain network include 1 master node and N slave nodes. The master node is used to generate consensus proposals and initiate consensus during the consensus process, and the slave nodes participate in the consensus process.

The consensus proposal is a preset number of instructions that the master node obtains from the local instruction pool.

In this specification, the member nodes of the blockchain refer to the consensus nodes participating in the consensus in the blockchain network, that is, both the master node and the slave nodes are called member nodes, each member node maintains system configuration information, and the system configuration information is specific Refers to the set of member nodes of the blockchain network and the system configuration number used to identify the system configuration, where a member node withdraws from the blockchain network, or other nodes join the blockchain network to become a member node , to update the system configuration number. A specific implementation manner may be to increment the system configuration number with a step size of 1.

As shown in Table 1, it is a specific embodiment of system configuration information.

system configuration number	set of member nodes
1	P1, P2, P3, P4

Table 1

Among them, the system configuration number is incremented by 1. For example, when node P5 joins the blockchain network, the member nodes in each blockchain network update the local configuration information to the information shown in Table 2.

system configuration number	set of member nodes
2	P1, P2, P3, P4, P5

Table 2

In this manual, the blockchain network is specifically a blockchain network that follows the BFT (Byzantine Fault Tolerance) Byzantine fault tolerance, that is, the blockchain network includes M consensus nodes, of which f malicious nodes are allowed at most, and M≥3f+ 1, f and M are all integers greater than 0.

As shown in Figure 1, a structural diagram of a network topology is proposed for this specification. In the figure, nodes P1-P4 form a blockchain network, and P5 refers to other nodes that want to join the blockchain network. It needs to send data to nodes P1-P4 The formed blockchain network sends member configuration instructions to join the blockchain network. In addition, if any node in the blockchain network wants to exit the blockchain network, it needs to broadcast member configuration instructions to the blockchain network to start from The blockchain network exits.

In this specification, regular instructions refer to instructions that do not involve changes to member nodes of the blockchain network, such as adding, deleting, modifying, and querying data. Instructions to exit the blockchain network.

In this specification, each node may be a hardware device with processing functions such as a server and a mobile terminal, which is not limited in this specification.

As shown in Figure 2, based on the above description, a blockchain-based consensus method proposed in this specification, any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes the block A set of member nodes in the block chain network and a system configuration number used to identify the system configuration; the method includes:

S201, the instruction initiating node broadcasts instructions to at least some member nodes in the blockchain network, so that the blockchain network generates consensus proposals including the instructions and performs consensus processing on the consensus proposals; wherein, the instructions include member Configuration instructions or general instructions, the member configuration instruction is used to instruct the instruction originating node to join or exit the blockchain network;

Based on the network topology diagram shown in Figure 1, it can be understood that the instruction originating node can be any node in the blockchain network or other nodes not in the blockchain network, which can send instructions to the blockchain network, In a blockchain network, an instruction can also be called a transaction, which is not limited in this manual.

Specifically, when the instruction initiating node is a node other than the blockchain network, it can send regular instructions, as well as member configuration instructions for instructing itself to join the blockchain network;

When the instruction initiating node is a member node in the blockchain network, it can send a general instruction and a member configuration instruction for instructing to withdraw itself from the blockchain network.

If the instruction originating node is a node other than the blockchain network, it can obtain the system configuration information of the blockchain network through corresponding channels and methods in advance, and then determine the member nodes in the blockchain network according to the configuration information, and then can Send instructions to member nodes. For the specific content of obtaining the system configuration information, reference may be made to the description below, and details will not be described here.

After receiving the instruction, the member nodes in the blockchain network can generate a consensus proposal including the instruction, and perform consensus processing based on the consensus proposal.

S202. After any member node in the blockchain network reaches a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction, update locally maintained system configuration information according to the member configuration instruction.

After the consensus nodes in the blockchain network reach a consensus on the consensus proposal, they can execute the consensus proposal. If the consensus proposal includes member configuration instructions, the locally maintained system configuration information will be updated according to the member configuration instructions. The system configuration information is synchronized among the nodes, that is, the member node set in the locally maintained system configuration information can be updated according to the member configuration instruction, and the system configuration number can be updated. Change Table 1 to Table 2 as above.

Using the above scheme, the member configuration instructions and regular instructions are packaged together into a consensus proposal for consensus, and each consensus node can execute the member configuration instruction after reaching a consensus based on the consensus proposal, and there is no need to process the member configuration instructions and regular instructions separately, that is The member configuration process can be processed without stopping the consensus process, thus greatly improving the consensus efficiency of the blockchain network.

As mentioned above, before executing the above S201, if the instruction initiating node is a node other than the blockchain network, it also needs to obtain the system configuration information of the blockchain network, and then can know the members of the blockchain network according to the system configuration information Node information can further broadcast instructions to member nodes in the blockchain network. The following describes how the instruction initiator node obtains the system configuration information of the blockchain network.

In one embodiment, since the instruction initiating node is usually a server or client with processing capability, it can directly obtain the system configuration information based on the input of the administrator, that is, the administrator directly stores the system configuration information in the instruction initiating node to configure.

In another embodiment, the instruction initiating node can also send a system configuration acquisition request to the information storage node; after receiving the system configuration acquisition request, the information storage node can return the system configuration information to the instruction initiating node, and the instruction initiating node according to the system The configuration information updates the local system configuration information, and then can broadcast instructions to the blockchain network according to the updated system configuration information.

In this embodiment, since all member nodes in the blockchain network maintain system configuration information, all member nodes in the blockchain network can be used as information storage nodes, and any member node receives the system configuration acquisition After the request, the system configuration information can be returned to the instruction initiating node. In addition, since the instruction initiating node does not know the member nodes in the blockchain network, it needs to send information to all nodes in the blockchain network. Broadcast the system configuration acquisition request to obtain the system configuration request. Specifically, it needs to broadcast the system configuration acquisition request to a node set including at least one blockchain network member node in order to obtain the corresponding system configuration information, which can be understood as an instruction here The initiating node broadcasts a system configuration acquisition request to all nodes in the network environment it knows about.

In addition, on the one hand, considering that the member nodes in the blockchain network are changing at any time, as a node outside the blockchain network, it is impossible and unnecessary to know the current member nodes included in the blockchain network. Therefore, it needs to report to all possible Configure the acquisition request for the broadcast system of the member nodes of the blockchain network, which undoubtedly increases the consumption of network bandwidth; on the other hand, the member nodes in the blockchain network are in the consensus process at any time. The system configuration acquisition request initiated by the initiating node undoubtedly increases the burden on the member nodes in the blockchain network.

Therefore, in an embodiment, a designated node may also be pre-specified, and the designated node is dedicated to responding to the system configuration acquisition request initiated by the instruction initiating node.

For example, the information storage node includes any designated node in the blockchain network or outside the blockchain network; when an instruction initiation node outside the blockchain network needs to obtain the system configuration information of the blockchain network, it can send the designated node The node sends a system configuration acquisition request, and the designated node returns the system configuration information to the instruction originating node. In addition, when the designated information storage node is a node other than the blockchain network, it can also receive the information sent by the member nodes when the member nodes in the blockchain network update the system configuration information synchronously, and then update the local System configuration information. In this way, the instruction initiating node only needs to know the communication address of one node of the information storage node, and at the same time, the instruction initiating node does not need to broadcast the system configuration acquisition request. Therefore, it not only reduces the consumption of network bandwidth, but also reduces the number of blocks The burden of member nodes and instruction originating nodes in the chain network.

In one embodiment, when the instruction initiating node is a node in the blockchain network, due to network reasons, it may also have the situation that the local system configuration information has not been updated, so when it needs to initiate an instruction to the blockchain network, It may also send a configuration information acquisition request to the information storage node, which is not limited in this description.

In addition, in some special predefined network environments, for example, in some network environments where there are few nodes and the identities of all nodes are disclosed, the instruction originating node can directly use all nodes in the predefined network as members of the blockchain network , that is, the set of all nodes in the predefined network is used as the set of member nodes in the system configuration information, and the predefined value is used as the system configuration number. The predefined value can be any predefined value that is not the actual system number, for example The predefined value is set to nail.

In order to ensure the credibility of the system configuration information, when the information storage node returns the system configuration information to the command initiating node, it can send the system configuration history information to the command initiating node together, and then, the command initiating node receives the request response message Afterwards, the system configuration information can be verified according to the system configuration history information. After the verification is passed, and the system configuration number in the system configuration information is greater than the system configuration number maintained locally, the local system configuration can be performed according to the system configuration information. renew.

It is understandable that if the instruction initiating node establishes contact with the blockchain network for the first time, there may not be any system configuration information stored locally, and the system configuration information can be stored locally after the verification is passed, which can be regarded as If the local system configuration information number is 0, the received system configuration information is greater than the local system configuration information number anyway. In addition, the instruction initiating node may be a node that has exited from the blockchain network before, or a node that has sent instructions to the blockchain network, so it stores system configuration information locally. Therefore, the instruction initiating node receives the system configuration information Finally, if the received system configuration number is greater than the local system configuration number, it means that the local system configuration information has not been updated. After the received system configuration information is verified, the local system configuration can be performed according to the received system configuration information. renew.

For example, the information storage node can return the message <CONF,c',Mc',chist'> to the instruction originating node, where CONF identifies the message type, c' is the system configuration number, and Mc' is the set of member nodes corresponding to the system configuration number , that is, c' and Mc' are system configuration information, and chist' is system configuration history information. The specific content of chist' and the method of using system configuration history information to verify system configuration information can be referred to below, and will not be described in detail here.

It can be understood that the above method of obtaining system configuration information can not only be applied to the consensus method proposed in this specification, but also can be applied to other consensus methods that need to use system configuration information, or other technologies that need to use system configuration information.

According to the above content, the command initiating node has obtained the system configuration information, so in the above S201, the command initiated by the command initiating node may carry the system configuration number, which is used to identify the system configuration version targeted by the command; for example, its You can send a command in the form of <SUBMIT,c,<JOIN,pk>>, where SUBMIT is the command type identifier, c is the system configuration number, pk is its public key, and JOIN means that the command is used to instruct the node that initiated the command to join blockchain network. Alternatively, it can send a message in the form of <SUBMIT,c,<LEAVE,i>>, where i is the member node number of the instruction originating node in the blockchain network, and LEAVE indicates that the instruction is used to instruct the instruction originating node Remove the blockchain network, under normal circumstances, the instruction originating node can initiate the instruction based on the local current system configuration number.

According to the above content, since the information storage node can be a designated node or a member node in the blockchain network, when the information storage node is a member node or a designated node in the blockchain network, since the node The update of the local system configuration information is not timely, so the nodes returned to the instruction originating node may be less than all the member nodes currently owned by the blockchain network. Therefore, in the above S201, the instruction initiating node can broadcast the instruction to at least some member nodes in the current blockchain network according to the updated system configuration information. After the broadcast, any slave node in the blockchain network receives the instruction After the instruction, the instruction can be forwarded, that is, the slave node in the blockchain network can forward the instruction to other nodes in the blockchain network after receiving the instruction sent by the instruction originating node, and at the same time, the instruction Stored in the local instruction pool. After receiving the instruction and generating a consensus proposal including the instruction, the master node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal.

After any slave node in the blockchain network receives the instruction, it forwards the instruction. Specifically, if the instruction is not executed locally, if the system configuration number and the locally stored system configuration number are determined If they are the same, forward the member configuration instruction to the master node; if it is determined that the system configuration number is smaller than the locally stored system configuration number, then forward the instruction to the member nodes in the locally maintained member node set;

After any slave node receives an instruction, if it is determined that the instruction has not been executed locally, it means that no consensus has been reached on the instruction. Further, if it is determined that the system configuration number is the same as the system configuration number stored locally, it means that the node that initiated the instruction If the system configuration number is the same as the local system configuration number, the command is directly forwarded to the master node.

If it is determined that the system configuration number is smaller than the system configuration number stored locally, it means that the system configuration of the command initiating node has not been updated, and the member node broadcast by the command initiating node is not the latest member node, so it is necessary to The command is forwarded to all member nodes corresponding to the local system configuration. For example, the instruction sent by the instruction originating node carries a system configuration number of 1, and the corresponding member node set includes four nodes P1, P2, P3, and P4. The local system configuration number is 2, and the corresponding member node set includes five nodes P1, P2, P3, P4, and P5. Therefore, the command can be forwarded to five nodes P1, P2, P3, P4, and P5, so that P5 This command can also be received.

When the system configuration number carried in the command initiated by the command initiating node is a predefined value, each slave node can regard it as the same value as the local system configuration number, or as a value smaller than the local system configuration number , and then trigger the corresponding forwarding process, which is not limited in this specification.

In addition, due to network delays and other reasons, it will be late for a node to receive the instruction sent by the instruction originating node. At this time, the node may have already completed the instruction because other nodes in the blockchain network have already received the instruction. Consensus processing, and the instruction has been executed. Therefore, the execution result and configuration history information can be returned to the instruction originating node. For example, a <REPLY,c,re,chist> message may be sent to the instruction originating node. Among them, REPLY refers to the message type identifier, c refers to the system configuration number, re refers to the execution result, and chist refers to the configuration history message. Here we will not explain the Chist, the specific content can refer to the following.

In the above S201, after the master node in the blockchain network receives the instruction, it can store the instruction in the local instruction pool, and after reaching the preset consensus cycle or storing a preset number of instructions in the instruction pool, it can Obtain a certain number of instructions from the instruction pool and package them into consensus proposals. The master node will package member configuration instructions and regular instructions into consensus proposals for processing. This manual does not limit the trigger mechanism and packaging method of master node packaging consensus proposals.

After the master node acquires a preset number of instructions from the instruction pool, it configures instructions for any member of the preset number of instructions. If it is determined that the member configuration instruction is an instruction that will initiate the instruction, the master node joins In the blockchain network, assign the member node serial number to the instruction originating node, and combine the member node serial number and the member configuration instruction into a member joining instruction. For example, if the member node serial number assigned to the instruction initiating node is j, and the member configuration instruction is m, then the combined member joining instruction is <ADD,j,m>, where ADD refers to the type identifier of the member joining instruction.

In addition, if the member configuration instruction is used to indicate that the instruction initiating node that will initiate the instruction withdraws from the blockchain network, the member node serial number of the instruction initiating node and the member configuration instruction are combined into a member exit instruction. Since the initiating node of this command is a node in the blockchain network, it has a member node serial number, for example, its member node serial number is i, and the command is m, then the combined member exit command is <REMOVE,i,m>, Wherein, REMOVE refers to the type identifier of the member exit instruction.

After processing the member configuration instructions in the preset number of instructions obtained, the master node can package the obtained member joining instructions, member exit instructions, and unprocessed regular instructions into consensus proposals. For example, the master node has obtained a total of 10 instructions from the instruction pool, of which the 1st and 10th are member configuration instructions, and the other instructions are regular instructions. The master node is transforming the 1st and 10th instructions into member joining instructions or member exit instructions Finally, the transformed 1st and 10th instructions and other regular instructions are packaged into consensus proposals.

In addition, after the master node assigns a member sequence number to the instruction originating node, it can also add the instruction originating node to the temporary member set. The set of temporary members can be understood as nodes that receive consensus messages in the blockchain network but do not participate in the consensus process.

As shown in Figure 3, in the system configuration maintained by the master node, there are four nodes PA, PB, PC, and PD. The node PE wants to join the blockchain network. The master node assigns the member node number E to the node PE and adds E In the temporary member set TM, M in the figure represents the member node set corresponding to the current system configuration, configuration c represents the system configuration c, if a consensus is reached on the member configuration command and the command is executed (corresponding to the Deliver delivery branch in the figure), then Add E to the member node set, and if no consensus is reached on the member configuration command (corresponding to the FailToDeliver branch in the figure), then E is removed from the temporary member node set.

After the instruction originating node is added to the temporary member set and the consensus proposal is packaged, the master node can coordinate other nodes to perform consensus processing on the consensus proposal, and it can broadcast the pre-preparation to the member nodes in the temporary member set based on the consensus proposal message, that is, to broadcast the pre-preparation message carrying the consensus proposal to the member nodes in the temporary member set, so that all nodes in the temporary member set can receive the pre-preparation message; wherein, the pre-preparation message carries the signature of the master node. The pre-preparation message can be a message in the form of <PRE-PREPARE,v,c,s, batch>, where PRE-PREPARE is the message type identifier, v indicates the current view, c indicates the system configuration number stored by the master node, and s is The number and batch of the current consensus proposal are consensus proposals.

The slave nodes in the blockchain network, that is, the nodes other than the master node in the set of member nodes in the system configuration maintained by the master node, after receiving the pre-preparation message, will add instructions to the members in the consensus proposal. The member node sequence number in the member joining instruction is added to the local temporary member set, and broadcasts the preparation message for the consensus proposal to the nodes in the local temporary member set; wherein, the preparation message carries the signature of the slave node, and prepares The message can be a message in the form of <PREPARE, v, c, s, h(batch)>, where PREPARE is the message type identifier, and h(batch) is the hash value proposed for the consensus.

It can be understood that all slave nodes of the blockchain network will perform the above operations, that is, all slave nodes will send a preparation message for the consensus proposal after receiving the pre-preparation message.

Any node, including the master node or slave node, after receiving the preparation message broadcast by 2/3 member nodes in the member node set configured by the local system, stores the signature of the received preparation message as the proof of the consensus proposal, and Broadcast a commitment message for the consensus proposal; the commitment message carries the signature of the node, where the commitment message can be a message in the form of <COMMIT, v, c, s, δ>, where COMMIT is the message type The logo and δ also represent the hash value of the consensus proposal.

Since in this specification, the malicious nodes in the blockchain network are less than 1/3 of all nodes, therefore, after the preparation message for the consensus proposal broadcast by 2/3 member nodes, it can be considered as the preparation message sent by the correct node , so it is possible to broadcast a commitment message for the consensus proposal, store its own signature information in the commitment message, and store the signature of the received preparation message as a proof of the consensus proposal.

In addition, any slave node may not have received the preparation message for the consensus proposal broadcast by 2/3 of the member nodes due to network delays, etc., but has received the message for the consensus proposal broadcast by 1/3 of the member nodes set configured by the local system. The commitment message of the consensus proposal also indicates that the number of nodes exceeding the number of malicious nodes has broadcast the commitment message, and it can be considered that the commitment message is sent by the correct node, so the slave node can also send the commitment message for the consensus proposal.

After receiving the commitment message of more than 2/3 member nodes in the current configuration, the slave node determines to reach a consensus on the consensus proposal, and executes the consensus proposal.

In addition, when the information storage node is a designated node outside the blockchain network, any member node in the blockchain network will send a consensus message to the information storage node after determining that a consensus has been reached on the consensus proposal, so that all The information storage node updates the local system configuration information and system configuration history information.

Specifically, after each consensus is completed, the member nodes in the blockchain network will additionally send a commitment message to the information storage node, and the information storage node will update the locally maintained configuration information according to the received commitment message. And update the system configuration history information, wherein the information storage node can also update the locally maintained configuration information after receiving the commitment message sent by 2/3 member nodes, and update the system configuration history information at the same time.

As shown in Figure 4, it is a schematic diagram of the consensus process for conventional instructions proposed in this specification. In the figure, c is a node that is not in the blockchain network, that is, the instruction originating node, which sends instructions to at least some members of the blockchain network. Node broadcasts instructions, as shown in Figure 4, it sends instructions to member node 0, member node 0 is the master node, and it sends pre-prepare messages (pre-preparation messages) to other member nodes, namely nodes 1, 2 and 3, as shown in the figure Node 3 is a malicious node, and nodes 0, 1, and 2 are correct nodes, so node 3 does not send a prepare message (preparation message) after receiving the message, and nodes 1 and 2 broadcast prepare messages to other nodes in the blockchain network. Node 0, Node 1, and Node 2 send a commit message (commitment message) after receiving a sufficient number of prepare messages. After receiving a sufficient number of commit messages, they determine to reach a consensus on the consensus proposal and return the execution result to the instruction originating node , that is, the reply message.

It can be understood that what is described in Figure 4 is a schematic diagram of consensus for conventional instructions, and the consensus process for member configuration instructions is shown in Figure 4, and the specific differences can be referred to below.

In one embodiment, any slave node, after receiving the pre-preparation message sent by the master node, according to the member joining instruction in the consensus proposal, after adding the member node serial number to the temporary member group, carries in the member joining instruction If the system configuration number of the member node is smaller than the local system configuration number, the local system configuration information and system configuration history information can be sent to the instruction originating node corresponding to the member node serial number. For example, it can send a command in the form of <CONF,c,Mc,chist> to the command initiating node, where c and Mc are the current system configuration information, chist is the system configuration history information, and CONF is the message type identifier.

That is, if the system configuration number carried in the member joining command is smaller than the local system configuration number, it means that the system configuration number of the node initiating the command has not been updated, so the configuration history information needs to be sent to the serial number of the member node, that is, the node initiating the command.

After the instruction initiating node receives the system configuration information and system configuration history information, it can update the local system configuration information according to the configuration information. Considering the security and credibility of the system configuration information, the instruction originating node can verify the system configuration information, and then update the local system configuration information according to the system configuration information after the verification is passed. Specifically, the system configuration information can be verified according to the system configuration history information, wherein the system configuration history information is a set of target consensus proposals, and the target consensus proposals are consensus proposals including member joining instructions or member exit instructions. That is, all member joining instructions or member exit instructions are recorded in the system configuration history information. In addition, since each node stores the proof of the consensus proposal during the consensus process, the proof of the target consensus proposal can be directly sent to the instruction initiating node as part of the system configuration history information, and the instruction initiating node is based on the system configuration history information Each proof in each target proposal is verified. In the case of passing the verification of all target proposals, it is determined that the system configuration history information is correct and safe, and because the system configuration information evolves based on the system configuration history information , so it can be determined that the system configuration information has passed the verification.

As shown in Figure 5, it is a schematic structural diagram of a system configuration history information proposed in this manual, wherein the system configuration history information includes three target consensus proposals, namely, consensus proposal 1, consensus proposal 3, and consensus proposal 7, each Each target consensus proposal contains member joining instructions or member exit instructions, and since the blockchain network will update the system configuration number after consensus and processing based on the target consensus proposal, the system configuration number corresponding to each target proposal is Incremental, for example, consensus proposal 1 corresponds to system configuration number 1, consensus proposal 3 corresponds to system configuration number 2, consensus proposal 7 corresponds to system configuration number 3, and the instruction initiating node is based on the proof corresponding to each target consensus proposal. After the verification of each target consensus proposal in the configuration history information, it can be determined that the system configuration history information is correct, and the system configuration number 3 of the latest consensus proposal 7 recorded in the system configuration history is the current system configuration number, the current The set of member nodes in the system configuration information is also evolved based on the target consensus proposal in the system configuration history information. Therefore, when it is determined that the system configuration history information has passed the verification, it can be determined that the obtained system configuration information has passed verify.

Furthermore, the local system configuration information can be updated based on the system configuration information.

In combination with the content described above, in the above S202, any node in the blockchain network may specifically add instructions to any member of the consensus proposal after reaching a consensus on the consensus proposal, and connect the node to The member node serial number in the entry command is added to the member node set in the locally maintained system configuration information; for any member withdrawal command in the consensus proposal, the member node serial number in the member withdrawal command is transferred from to the local Remove from the set of member nodes in the maintained system configuration information; update the system configuration number, for example, add 1 to the system configuration number.

In addition, after the above S202, if the consensus proposal includes a member joining instruction or a member exit instruction, the consensus proposal needs to be added to the system configuration history information to update the system configuration history information. And it is also necessary to return the member configuration processing result to the instruction originating node corresponding to the member joining instruction included in the consensus proposal after completing the consensus on all consensus proposals whose number is lower than this proposal, that is, to the instruction originating node of the member configuration instruction Returns the member configuration processing result.

After receiving the configuration processing results sent by 2/3 member nodes, the initiating node of the instruction can confirm that the instruction has been executed and join the blockchain network locally.

For example, each member node can reach a consensus on a consensus proposal, and the consensus proposal includes a member joining instruction, and after completing the consensus on all consensus proposals with numbers lower than the proposal, return the instruction to the node initiating the form <HISTORY ,s,h,C,P>, where HISTORY is the message type identifier, s is the number of the consensus proposal, h is the hash value of the consensus proposal, C is the latest local checkpoint, and P is the serial number of the local storage higher than Proofs of all consensus proposals in C.

For the instruction originating node, after receiving the <HISTORY, s, h, C, P> message sent by 2/3 member nodes, it determines to join the blockchain network locally and participate in the subsequent consensus process of the blockchain network.

In addition, in order to improve the efficiency of the instruction originating node to join the blockchain network, it can also confirm that the consensus proposal including the member joining instruction sent locally has reached a consensus, but has not received enough, that is, has not received it. In the case of the configuration processing result of the /3 member node, it joins the blockchain network and participates in consensus voting.

For the instruction initiating node of any member configuration instruction, after storing the proof of the consensus proposal, if the member configuration instruction is included in the consensus proposal, and the member configuration instruction is used to instruct the instruction initiating node from If the blockchain network exits, it is determined that the local exits from the blockchain network.

That is, if the member configuration instruction sent by the member initiating node is used to withdraw the instruction initiating node from the blockchain network, if it collects the proof of the consensus proposal during the consensus process, and the member configuration instruction sent locally is in the In the consensus proposal, it can be determined that the consensus proposal has been accepted by most nodes, so it can withdraw from the blockchain network, no longer participate in the consensus process, or receive consensus messages.

Considering security issues, the member node can also withdraw from the blockchain network after completing the consensus processing of the consensus proposal and executing the consensus proposal.

That is, the instruction initiating node of any member configuration instruction determines that the consensus proposal is executed, and the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to instruct the instruction initiating node to If the block chain network exits, it is determined that the local exits from the block chain network.

In addition, after the above S202, any node, after local execution of any conventional command in the consensus proposal, if it is determined that the system configuration number in the command is the same as the local system configuration number, initiate The node returns the processing result, as shown in Figure 4, the instruction initiating node receives the processing result sent by the member node corresponding to the 2/3 local system configuration and determines that the instruction is executed.

If it is determined that the system configuration number in the instruction is smaller than the local system configuration number, then return the processing result and system configuration information to the instruction originating node of the instruction, and the instruction originating node receives 2/3 of the member nodes in the updated system configuration The sent processing result determines that the execution of the instruction is completed, and updates the local system configuration information according to the system configuration information. Similarly, in order to determine the credibility of the system configuration information, the system configuration history information can also be returned to the instruction originating node, and the instruction originating node verifies the system configuration information based on the system configuration history information.

In one embodiment, considering that when the master node is down or doing evil, the master node does not initiate a proposal, or initiates a wrong proposal, which will cause the nodes to fail to reach a consensus. Therefore, it is necessary to switch the master node, that is, view switching.

Therefore, when any slave node detects that the view switching condition is met, it can broadcast a view switching instruction to the member nodes in the locally maintained member node set; the view switching message carries the target system configuration number. Among them, the view switching condition can be that the heartbeat of the master node is not detected for a long enough time, or the consensus process is not completed within the specified time. This manual does not limit this, and the relevant content can refer to the PBFT consensus method.

Any slave node forwards the view switching message according to the target system configuration number after receiving the view switching message broadcast by other nodes;

Specifically, if any slave node receives the view switching message broadcast by other nodes, if it determines that the target system configuration number in the view switching message is smaller than the local system configuration number, and the local system configuration number corresponds to more member nodes than the The member node corresponding to the target system configuration number forwards the view switching message to the first node; wherein the first node is included in the member node set of the local system configuration, but not in the node of the target system configuration member node set ;

As shown in Figure 6, for example, the target system configuration number is MC', the local system configuration number is Mc, and the member nodes corresponding to the local system configuration numbers are A, B, C, D, E, F, G. The member nodes corresponding to the target system configuration numbers are A, B, C, and D, then forward the view switch message to E, F, and G, so that E, F, and G that have not received the view switch message can also receive the view switch message. view switching message to enter the view switching state.

If it is determined that the target system configuration number in the view switching message is greater than the local system configuration number, then the local system configuration is updated to the system configuration corresponding to the target system configuration number. Forwarding the view switching message to a second node, the second node being a node included in the set of member nodes configured by the target system but not in the set of member nodes configured by the local system;

If the view switching message has not been sent locally, the view switching message is forwarded to the node corresponding to the target system configuration number.

As shown in Figure 7, for example, the target system configuration number is MC', the local system configuration number is MC, and the member nodes corresponding to the target system configuration number are A, B, C, D, E, F, G. The member nodes corresponding to the local system configuration number are A, B, C, and D. After updating the local system configuration, if no message for the current master node’s view switch has been sent locally, send the message to A, B, C, D, E, F, and G send view switching messages. If they have sent a view switching message for the current master node, they will send a view switching message to E, F, and G, so that E, F, and G can also receive the view switching message .

When the master node receives the view switching message sent by 2/3 nodes in the set of member nodes in the locally maintained system configuration, it broadcasts a new view message to all member nodes in the locally maintained system configuration, so that the system Nodes in the configured set of member nodes enter the new view. It can be understood that the master node here refers to the new master node selected instead of the original master node. For example, it can sort each node and switch the master node in order. If node 1 in the previous view is the master node, Then node 2 is currently used as the new primary node.

That is, the master node broadcasts a new view message to the member nodes after receiving the view switch message broadcast by more than enough member nodes. Of course, in order to determine the legitimacy of the new view message, each slave node needs to verify the new view message. The specific verification process can also refer to the PBFT consensus method, which will not be described in detail here.

In an embodiment, the view switching condition may further include: after a consensus is reached on the consensus proposal, and the consensus proposal includes a member configuration instruction. That is, whenever each consensus node updates the local system configuration information, it switches views. While using this method, since the re-selected master node will return a new view message to each node in the new view, which carries new system configuration information, each node can update the local system configuration according to the system configuration information sent by the master node Therefore, in the above consensus process, each member node may not return the system configuration history message to the newly added node in this update after it is determined to reach a consensus on the consensus proposal, but wait until the view is switched, and the master node sends the new The nodes in the view send historical messages, and since the view is switched every time there is a member increase or decrease, there is no need to set up a temporary member group, that is, there is no need to send consensus messages to the temporary members.

In one embodiment, during the consensus process, any slave node acquires system configuration information if it determines that the view switching condition is met. Wherein, the manner of obtaining the system configuration message from the slave node may refer to the content described above, that is, it may be obtained from the information storage node, which is not limited in this specification.

Further compare the system configuration number in the obtained system configuration information with the locally maintained system configuration number, if the obtained system configuration number is the same as the locally maintained system configuration number, perform the view switching process, that is, the member nodes that are locally maintained can be aggregated The member nodes in broadcast the view switching command. If the obtained system configuration number is greater than the locally maintained system configuration number, further broadcast the historical data acquisition message <UPDATE, s, c, i> to the member nodes in the member node set corresponding to the obtained system configuration number, and the historical data acquisition The message carries the system configuration number c maintained locally by the node.

Any member node in the member node set, after receiving the historical data acquisition message, if it is determined that the system configuration number carried in it is smaller than the local system configuration number, and the node sending the historical data acquisition message is a locally maintained member node set , then return to the node a response message <RESULT, hist> for the historical data acquisition message, where the response message carries all the consensus proposal hist executed by the member node, that is, the RESULT in the message is the message type identifier, hist is the execution history of the member node, that is, all consensus proposals executed by the member node.

When the slave node receives the response message returned by 1/3 of the member nodes in the member node set, and the information carried in the response message is the same, it will update the local data according to the response message, that is, the consensus in the response message can be implemented proposal.

In this embodiment, if any slave node is determined to meet the view switching condition, first of all, it is necessary to judge whether it is the cause of its own network failure rather than other nodes, so it needs to obtain system configuration information. If the local system configuration information is consistent with If the obtained system configuration information is consistent, it means that it is not a problem with itself, and the view switching process starts directly. If the obtained system configuration number is higher than the local system configuration number, it means that your local data has lagged behind other nodes in the system, and you can obtain historical data from other nodes in the system to update the local data, and you can continue to participate after the update In the consensus process, the above method can enhance the data consistency of each node, and can also effectively reduce the number of view switching, thereby saving network bandwidth.

In the various consensus methods currently in use, in the case of dynamic changes in member nodes, it is impossible to guarantee that each node can successfully reach a consensus on the consensus proposal during the consensus stage (because the member nodes in the current network maintained by each node cannot reach a consensus, nor It is impossible to receive consensus messages that meet the quantity requirements), and similarly, there is no guarantee that the view switch can be successfully completed during the view switching phase, that is, the activity of the consensus phase and the view switching phase cannot be guaranteed.

In this manual, the introduction of system configuration information and system configuration history information enables each node to know the latest member node information in the current blockchain network. During the consensus process, it can ensure that the correct nodes in the system configuration have a consistent state, so , which can ensure the activity of the view switching phase and the consensus phase when the member nodes change dynamically.

If a correct node submits the command m, the correct node can verify the current system configuration based on the effective system configuration history, so as to determine whether there are enough consensus nodes to receive m, and whether the consensus on m is reached.

The combination of the above two ensures that the correct node can obtain the correct reply about m. Therefore, the protocol can achieve consistent delivery, and ensure the security and activity of the view switching phase and the consensus phase when the member nodes change dynamically. Among them, consistent delivery means that if a correct node submits a command m, then this node will definitely receive a reply about m, and the reply is consistent with the reply generated in the system configuration where m is processed. For example, if a node sends command m in the blockchain network with system configuration number c, the reply returned by the node in system configuration number c' is consistent with the reply returned by the node in system configuration number c .

In order to understand this solution more clearly, the consensus method proposed in this specification is described below from a one-sided perspective. For the instruction originating node, its main tasks are as follows:

Obtain system configuration information;

Update the local system configuration information according to the obtained system configuration information, and broadcast instructions to at least some member nodes in the blockchain network according to the updated system configuration information, so that the blockchain network generates a consensus proposal including the instructions And carry out consensus processing on the consensus proposal; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to instruct the node originating the instruction to join or withdraw from the blockchain network.

For the master node in the blockchain network, its main tasks include:

After receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction, coordinate other nodes to perform consensus processing on the consensus proposal; wherein the instruction includes a member configuration instruction or a regular instruction;

After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.

For the slave nodes in the blockchain network, their main tasks include:

After receiving the instruction sent by the instruction originating node, the instruction is forwarded; wherein the instruction includes a member configuration instruction or a general instruction;

Consensus processing is performed on consensus proposals including said instructions;

After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.

From the perspective of pseudo-code implementation, the consensus method proposed in this manual is described below. In this manual, the above-mentioned consensus method is named as the dynamic BFT consensus method Dyno.

In the following pseudo-code, the meanings of each character are as follows:

pk: copy public key, c: system configuration number, fc: 1/3 nodes in the current system, MC: system configuration member node set, TM: temporary member node set, C: local latest fixed checkpoint, v: current view Serial number, s: the serial number of the consensus proposal, P: the certificate of all packages stored locally with a serial number higher than the latest instruction in C, certificate: a valid proof that a consensus proposal has been processed or a valid proof of a newly proposed instruction, among which, for There are two possibilities for a certain instruction package, namely the certificate of the consensus proposal: (1) More than 2/3 nodes in a certain system configuration sign the message of <PREPARE (preparation), v, c, s, h (batch)>; ( 2) In a certain system configuration, more than 1/3 nodes sign the message δ=h(batch) for <COMMIT (guarantee), v, c, s, δ>. PP: membership instruction set, ts: timestamp, o: operation proposed by the instruction originating node, re: instruction execution result, V: viewchange message set, O: instruction set, h(batch): batch (consensus proposal) hash Value, sometimes abbreviated as δ, Π: all possible consensus nodes in the consensus system (including consensus nodes that have not yet joined or exited), Chist: system configuration history. Chist is defined as a group of batches containing membership instructions arranged in increasing order of system configuration. Specifically, Chist is a subset of the set of all consensus batches, including only those batches that contain at least one membership directive. The system configuration corresponding to each batch in Chist is incremental, and the interval is 1. Each replica (consensus node) stores a corresponding certificate for each batch in the chist and includes it in the chist. Thus the validity of a Chist can be verified by any replica or client of the known initial state of the system. Deliver(<TYPE>): A membership command is delivered. In the BFT protocol, this event represents that a copy has completed a round of consensus, and the instruction is committed locally. FailToDeliever(<TYPE>): Failed to deliver a certain membership order. In the BFT protocol, this event represents a view switch in the consensus system before the instruction was delivered.

For the command initiating node, the pseudo code for obtaining system configuration information is as follows:

One way to get it is as follows:

In the above pseudo code, the occurrence conditions and specific operations are as follows:

1) Node pi runs the ObtainConfig() function, then:

a) Pi broadcasts a <DISCOVER, c> message to all possible consensus nodes, where c is the latest system configuration known to pi. Then pi sets a timer and waits continuously within the timer time.

b) If pi receives <CONF,c',Mc',chist'> message, where chist' is a valid system configuration history, and c'>c, then pi updates its local configuration history chist, system configuration c and configuration Member set Mc.

c) When the timer ends, return the current system configuration c and configuration member set Mc.

2) Consensus node pi receives <DISCOVER, c’> message, and returns <CONF, c, Mc,chist> message to the message sender.

Another way to obtain system configuration information is as follows:

In the above pseudo code, the occurrence conditions and specific operations are as follows:

Node pi runs the ObtainConfig() function, and the function returns nil, Π. Among them, nil is empty, and Π is all nodes in the network environment.

Another way to obtain system configuration information is as follows:

In the above pseudo code, the occurrence conditions and specific operations are as follows:

1) The consensus node pi runs the ObtainConfig() function, then:

a) Pi sends a <QUERY, cid> message to the configuration manager cMaster, then pi sets a timer and waits continuously within the timer time.

b) If pi receives <CONF,c',Mc',chist'> message, where chist' is a valid system configuration history, and c'>c, then pi updates its local configuration history chist, system configuration c and configuration Member set Mc, the function returns c,Mc.

c) If Pi timeout occurs, run the ObtainConfig() function again.

2) cMaster receives <QUERY, j> message, then returns <CONF, c, Mc, Chist> message to the message sender.

3) cMaster receives 2/3 <COMMIT, v, c, s, h(batch)> messages, then order chist←chist∪M to update the system configuration c and Mc.

For the instruction initiating node, the pseudocode of the processing method after sending the instruction and receiving the message returned by the member node is as follows:

After the instruction originating node initiates the instruction, the follow-up process is divided into the following three types according to the instructions issued by the instruction originating node:

1) Adding instructions: the instruction originating node pi obtains the latest system configuration through the ObtainConfig() function (ObtainConfig() is implemented by a black box, and the specific function is uncertain. Here it can be simply set as the output (0, Π)), to the All nodes in the system configuration broadcast their signed <SUBMIT,c,<JOIN,pk>>command and set a timer. pi continues to wait within the timer time, there are three situations as follows:

a) pi receives <CONF,c’,Mc’,chist’>, if c<c’ and chist’ is valid, then pi updates its system configuration. Among them, CONF identifies the command type, c' is the system configuration number of the sender of the command, Mc' is the system configuration member node set of the sender of the command, and chist' is the system configuration history information of the sender of the command.

b) The instruction initiating node receives <HISTORY, s, h, C, P> messages from more than 2/3 of the consensus nodes in the current configuration, and the state transmission is completed. The client joins the current system configuration and becomes a consensus node. The timer ends.

Among them, the <HISTORY, s, h, C, P> message is the member configuration processing result. HISTORY, identifies the type of the instruction, s is used to identify the consensus proposal, h is the hash value of the consensus proposal, C is the latest local fixed checkpoint, P is the local storage, and the sequence number is higher than all proposals of the latest consensus proposal in C certificate, where certificate is the proof of the consensus proposal.

c) Timeout, initialize and run the above process.

2) Leaving command: The command initiating node pi broadcasts the signed <SUBMIT,c,<LEAVE,i>>command to all nodes in the current system configuration and sets a timer, and waits continuously within the timer time. There are the following two situations:

a) The instruction originating node Pi collects the certificate of a certain instruction set consensus proposal batch, and <REMOVE,i,m>∈batch, then pi leaves the consensus system and the timer ends.

b) timeout, initialize and run the above process.

3) General instructions: the instruction originating node pi obtains the current latest system configuration through the ObtainConfig() function (ObtainConfig() is implemented by a black box, and the specific function is uncertain. Here it can be simply set as the output (0, Π); to the system In the configuration, all nodes broadcast their signature command m=<SUBMIT,c,<REQUEST,cid,o,ts>>, cid is the user id, o is the operation, ts is the timestamp; and set the timer. pi is in the timer There are three situations as follows:

a) When pi receives <REPLY, c, re> returned by 1/3 nodes in the local system configuration, it determines that the execution of the command is complete. Among them, REPLY identifies the message type, and re is the execution result.

b) When pi receives the <REPLY, c’, re,chist’> returned by 1/3 nodes in the local system configuration, it determines that the execution of the command is over. Among them, chist' is the system configuration history information sent by the command initiator.

For the member nodes in the blockchain network, the pseudo-code executed is as follows:

User command processing process:

In the above pseudo-code, any node pi in the blockchain receives the submit message m=<SUBMIT,c’,<REQUEST,cid,o,ts>> that contains the user’s cid command and starts to perform the following operations. There are three situations at this point:

1) m has been delivered and processed by pi: then pi sends a <REPLY, c, re,chist> message containing the current state to user cid, and re is the latest execution result.

2) m is not delivered by pi, c=c'; then pi sends m to the current master node leader, and stores m in the instruction queue queue, that is, the instruction pool.

3) m is not delivered by pi, c>c': then pi sends m to all members in the current system configuration, and stores m in the command queue queue.

If pi is the leader, pi needs to pack user commands in the queue into batches, and broadcast a pre-preparation message <PRE-PREPARE,v,c,s,batch> to all members of the temporary member group TM, where v is the current view number.

a) For regular instructions in any queue, directly store them in the consensus proposal batch.

b) For the join command m=<SUBMIT,c',<JOIN,pk>> in any queue, assign member number j to the node whose public key is pk, generate member join command <ADD,j,m>, and send it Deposit into batch, and deposit customer j into TM.

c) For the join command m=<SUBMIT,c’,<LEAVE,j>> in any queue, generate a node removal command <REMOVE,j,m>, and store it in the batch.

Consensus process:

In the above pseudo-code, the node pi in the blockchain receives a valid pre-prepare message m=<PRE-PREPARE,v,c,s,batch>. After starting to run the consensus process, pi then performs the following operations:

1) For the <ADD, j, m’> instruction in any batch, pi stores pj in TM, and if c>c’, sends <CONF, c, Mc,chist> message to pj.

2) Broadcast <PREPARE, v, c, s, h(batch)> message to TM and keep waiting. There are three situations:

a) pi receives <PREPARE, v, c, s, h (batch)> messages from more than 2/3 consensus nodes in the current configuration, stores these message signatures as the certificate of m, and broadcasts <commit, v, c, s, δ> Among them, δ is the hash value of the consensus proposal.

b) pi receives <COMMIT, v, c, s, δ> messages from more than 1/3 consensus nodes in the current configuration, stores these message signatures as batch certificates, and broadcasts <COMMIT, v, c, s to TM ,δ>

c) pi receives <COMMIT, v, c, s, δ> messages from more than 2/3 consensus nodes in the current configuration, and runs deliver(batch).

In one embodiment, if any slave node in the above consensus process is determined to be timed out, the consensus method executed in this specification is named Dyno-A, and the pseudo-code executed is as follows:

In the above pseudo-code, if node pi in the blockchain times out, first run the ObtainConfig() function to obtain the current latest system configuration c’, Mc’. (ObtainConfig() is implemented in a black box, and the specific function is uncertain. Then pi sets the timer and waits continuously, there are the following three situations:

a) c'=c, at this time pi runs viewchange()

b) Otherwise, pi sends a message to Mc'<UPDATE, s, c, i> and waits. If 1/3 of the same <RESULT, hist> is received within the timer time, the timer ends, and all The command runs the deliver function.

c) If pi times out, re-run the protocol at the time of timeout.

If the member node receives <UPDATE, s, c’, j> message, if pj∈Mc’ and c>c’, pi sends <RESULT, hist> message to pj.

Instruction execution process:

In the above process, the replica pi runs the instruction execution protocol starting from its running deliver(batch). pi then proceeds as follows:

1) For instruction m in any batch, m'=m=<SUBMIT,c',<REQUEST,cid,o,ts>>, if c>c', send <REPLY,c,re,chist> to cid message, otherwise send a <REPLY,c,re> message to cid.

2) If there is a membership instruction in the batch, update the pi local system configuration c to c+1, and perform the following operations:

a) For the adding instruction m=<ADD,j,m> in any queue, let Mc=Mc+pj

b) For the leaving command m=<REMOVE,j,m> in any queue, let Mc=Mc-pj

c) Update Chist to Chist∪batch

d) Send <HISTORY, s, h, C, P> messages to all nodes in Mc-Mc-1, where C is the latest fixed checkpoint; P is stored by pi, and the sequence number is higher than the latest package in C, which is the consensus proposal The certificate of all packages. Here, the replica pi is required to commit all command blocks with sequence numbers lower than the batch before sending the History message.

The view switching process is as follows:

There are three situations in which the node pi runs the view switching process in the blockchain network:

1) pi triggers a view switching instruction when a timeout occurs (i.e. it has not delivered a new message for a long enough time) or when it receives valid view switching messages sent by at least 1/3 nodes.

At this point, pi updates its view v=v+1, and broadcasts m=m'=<VIEW-CHANGE,v,c,C,P,PP,i> to Mc where PP

A collection of membership directives.

2) Pi receives m'=<VIEW-CHANGE,v,c',C,P,PP,j> message:

If c'<c, pi forwards the message to all replicas in Mc-Mc'.

If c'>c, pi updates its system configuration c and M, then there are two situations: if pi has sent a view switching message in the current round, it will additionally send its view switching message to all nodes in Mc-Mc', or , if pi has not sent a view switching message, it will send a view switching message to all nodes in Mc.

3) Pi receives more than 2/3 of the <VIEW-CHANGE, v, c', C, P, j> messages in the current system configuration, and pi is the leader in the latest system configuration in these messages, then pi will send All replicas of Mc send <NEW-VIEW, v, c, V, O> messages and enter the new view.

It is understandable that the above consensus method can be applied not only to the blockchain network, but also to other application scenarios, for example, in a system with a fixed number of server nodes, it is used for system recovery and reconfiguration. When some servers crash, have errors or are attacked, or when the system needs maintenance, it can be achieved by creating a new node or removing an old node.

When active recovery is required, the above method can also be used. For example, when multiple nodes in the system are affected by viruses and cannot be removed, the above method can be used to introduce new nodes, because the new nodes are all new operating systems and If the environment is not infected by viruses, you can also use the above method to remove some old nodes.

In the consortium chain network, when each consortium member needs to change dynamically, such as company A withdrawing and company B joining, the above consensus method can also be used, and the above consensus method can also be used in the hybrid chain.

Corresponding to the aforementioned consensus method based on a blockchain network, this specification also provides a consensus system based on a blockchain network, where any consensus node in the blockchain network maintains system configuration information locally, The system configuration information includes a set of member nodes of the blockchain network and a system configuration number used to identify the system configuration; the system includes:

The instruction originating node is used to obtain system configuration information;

The instruction initiating node is also used to update the local system configuration information according to the acquired system configuration information, and broadcast instructions to at least some member nodes in the block chain network according to the updated system configuration information, so that the block chain The network generates a consensus proposal including the instruction and performs consensus processing on the consensus proposal; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to indicate that the instruction originating node joins or withdraws from the blockchain network;

Any member node in the blockchain network is configured to update locally maintained system configuration information according to the member configuration instruction after determining that a consensus has been reached on the consensus proposal, if the consensus proposal includes a member configuration instruction.

In one embodiment, the instruction initiating node is configured to send a system configuration acquisition request to the information storage node;

The information storage node is used to return the system configuration information to the instruction originating node.

In one embodiment, the information storage node includes a member node in the blockchain network;

The instruction initiating node is specifically configured to broadcast a system configuration acquisition request to a node set including at least one block chain network member node.

In one embodiment, the information storage node includes a designated node in or outside the blockchain network; the instruction initiating node is specifically configured to send a system configuration information acquisition request to the designated node.

In one embodiment, the information storage node is configured to return an acquisition request response message to the instruction initiating node, and the response message carries system configuration information and system configuration history information.

In this embodiment, the instruction initiating node is configured to verify the obtained system configuration information according to the system configuration history information, and if the verification passes, and the system configuration number in the obtained system configuration information is greater than the locally maintained system configuration number, the local system configuration is updated according to the obtained system configuration information.

In one embodiment, the instruction initiating node uses a set of all nodes in the predefined network as the member node set in the system configuration information, and uses a predefined value as the system configuration number.

In one embodiment, any slave node in the blockchain network is configured to forward the instruction after receiving the instruction;

The master node in the blockchain network is configured to coordinate other nodes to perform consensus processing on the consensus proposal after receiving the instruction and generating a consensus proposal including the instruction.

In one embodiment, the instruction carries a system configuration number, which is used to identify the system configuration targeted by the instruction; any slave node in the blockchain network is used to execute the instruction locally if the instruction is not executed locally. , if it is determined that the system configuration number is the same as the system configuration number stored locally, then forward the member configuration instruction to the master node; if it is determined that the system configuration number is smaller than the system configuration number stored locally, then forward the instruction to the local A member node in the maintained member node set; when the instruction is executed locally, the execution result and system configuration history information are returned to the instruction originating node.

In one embodiment, the master node is further configured to store the instructions in the local instruction pool after receiving the instructions; obtain a preset number of instructions from the local instruction pool; In any member configuration instruction, if the member configuration instruction is used to indicate that the instruction initiating node that initiates the instruction will join the blockchain network, then assign a member node serial number to the instruction initiating node, and assign the member node serial number and The member configuration instruction is combined into a member joining instruction; if the member configuration instruction is used to indicate that the instruction initiating node that will initiate the instruction withdraws from the blockchain network, the member node serial number of the instruction initiating node and the member node The configuration instructions are combined into a member exit instruction; for the preset number of instructions, the member join instruction, member exit instruction and regular instructions are packaged into a consensus proposal.

In one embodiment, the master node is further configured to add the instruction initiating node to the temporary member set after allocating the member serial number to the instruction initiating node; the temporary member set includes all Member nodes; broadcast a pre-preparation message to nodes in the temporary member set based on the consensus proposal;

Any slave node, after receiving a valid pre-preparation message, for the member joining instruction in the consensus proposal, add the member node serial number in the member joining instruction to the local temporary member set, and send the local Nodes in the temporary member set broadcast a preparation message for the consensus proposal; the preparation message carries the signature of the slave node;

Any member node, after receiving the preparation message for the consensus proposal broadcast by 2/3 member nodes in the member node set configured by the local system, take the signature of the received preparation message as the proof of the consensus proposal Store and broadcast the commitment message for the consensus proposal, or, after receiving the commitment message for the consensus proposal broadcast by 1/3 member nodes in the set of member nodes configured by the local system, the received commitment message The signature is stored as a proof of the consensus proposal, and a commitment message for the consensus proposal is broadcast; wherein, the commitment message carries the signature of the node; 2/3 of the member nodes in the set of member nodes that have received the local system configuration After the node broadcasts a commitment message for the consensus proposal, it is determined that a consensus is reached for the consensus proposal, and the consensus proposal is executed.

In one embodiment, any slave node is also used to, after adding the member node serial number in the member joining instruction to the temporary member group, if the system configuration number carried in the member joining instruction is smaller than the local system configuration number, send The instruction originating node corresponding to the member node serial number sends local system configuration information and system configuration history information;

The instruction initiating node is further configured to verify the received system configuration information according to the system configuration history information after receiving the system configuration information and the system configuration history information, and after the verification is passed, according to the received system configuration information The configuration history information updates the local system configuration information; the system configuration history information is a set of target consensus proposals, wherein the target consensus proposals are consensus proposals including member joining instructions or member exit instructions.

In one embodiment, the system configuration history information includes a proof of each target consensus proposal;

The instruction initiating node is specifically configured to verify the target proposal based on the proof in the system configuration history information, and determine that the system configuration history information and the system configuration information pass the verification if all target proposals pass the verification. verify.

In one embodiment, any node in the blockchain network is configured to, after reaching a consensus on the consensus proposal, add an instruction to any member in the consensus proposal, and add the member to the member node in the instruction The sequence number is added to the member node set in the locally maintained system configuration information; for any member exit instruction in the consensus proposal, the member node sequence number in the member exit instruction is added to the locally maintained system configuration information Removed from the set of member nodes; update the system configuration number.

In one embodiment, any node in the blockchain network is also used to add the consensus proposal to the system configuration history information; return the member configuration process to the initiating node corresponding to the member configuration instruction included in the consensus proposal Result; wherein, the member configuration instruction is used to indicate that the instruction originating node of the instruction is added to the block chain network;

The instruction originating node of any member configuration instruction is also used to determine that the instruction has been executed after receiving the configuration processing result sent by 2/3 member nodes, and determine to join the blockchain network locally.

In one embodiment, the instruction initiating node of any member configuration instruction is also used to store the proof of the consensus proposal during the consensus process, if the member configuration instruction is included in the consensus proposal, wherein the The member configuration instruction is used to instruct the instruction initiating node to withdraw from the blockchain network, and then it is determined to withdraw locally from the blockchain network.

In one embodiment, the instruction initiating node of any member configuration instruction is also used to determine that the consensus proposal is executed, and the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to indicate If the instruction initiating node is withdrawn from the blockchain network, it is determined to locally withdraw from the blockchain network.

In one embodiment, any node in the blockchain network is also used to determine that the system configuration number in the instruction is consistent with the local system configuration number after local execution of any conventional instruction in the consensus proposal If the numbers are the same, return the processing result to the instruction originating node of the instruction; if it is determined that the system configuration number in the instruction is smaller than the local system configuration number, then return the processing result and system configuration history information to the instruction originating node of the instruction.

In one embodiment, any slave node is also used to obtain system configuration information when it detects that the view switching condition is met; if the obtained system configuration number is the same as the locally maintained system The member nodes in the member node set broadcast the view switching instruction; if the obtained system configuration number is greater than the locally maintained system configuration number, broadcast the historical data acquisition message to the member nodes in the member node set corresponding to the obtained system configuration number; wherein, The system configuration number maintained locally is carried in the historical data acquisition message;

Any member node in the set of member nodes is further configured to, after receiving the historical data acquisition message, determine that the system configuration number carried in it is smaller than the local system configuration number, and the node sending the historical data acquisition message is a local maintenance node. A node in the set of member nodes returns to the node a response message for the historical data acquisition message; wherein, the response message carries all the consensus proposals executed by the member node;

The slave node is further configured to update local data according to the response message when receiving the response message returned by 1/3 of the member nodes in the set of member nodes and the information carried in the response message is the same.

In one embodiment, any slave node is further configured to broadcast a view switching instruction to the member nodes in the locally maintained member node set when it detects that the view switching condition is met; the view switching message carries the target system configuration number; after receiving the view switching message broadcast by other nodes, forwarding the view switching message according to the target system configuration number;

The master node is also used to broadcast a new view message to all member nodes of the locally maintained system configuration when receiving the view switching message sent by 2/3 of the locally maintained system configured member node sets, so that Nodes in the member node set of the system configuration enter a new view.

In one embodiment, any slave node is further configured to determine that the target system configuration number in the view switching message is smaller than the local system configuration number after receiving the view switching message broadcast by other nodes, and the local system configuration number corresponds to If there are more member nodes than the member nodes corresponding to the target system configuration number, the view switching message is forwarded to the first node; wherein the first node is included in the member node set of the local system configuration, but not in the target system configuration Nodes in the member node set; if it is determined that the target system configuration number in the view switching message is greater than the local system configuration number, then update the local system configuration to the system configuration corresponding to the target system configuration number, which has been sent locally in this round In the case of a view switch message, the view switch message is forwarded to a second node, and the second node is a node included in the set of member nodes configured by the target system but not in the set of member nodes configured by the local system; locally If no view switching message has been sent in this round, the view switching message is forwarded to all nodes corresponding to the target system configuration number.

In one embodiment, the view switching condition includes after a consensus is reached on the consensus proposal, and the consensus proposal includes a member configuration instruction.

As shown in Figure 8, corresponding to the aforementioned consensus method based on the blockchain network, this specification also provides a consensus device based on the blockchain network, which is applied to the instruction initiating node, and in the blockchain network Any consensus node of the system maintains system configuration information locally, and the system configuration information includes a set of member nodes of the blockchain network and a system configuration number used to identify the system configuration; the device includes:

An acquisition module 810, configured to acquire system configuration information;

The broadcast module 820 updates the local system configuration information according to the acquired system configuration information, and broadcasts instructions to at least some member nodes in the block chain network according to the updated system configuration information, so that the block chain network generates the Consensus proposal of the instruction and perform consensus processing on the consensus proposal; wherein, the instruction includes a member configuration instruction or a regular instruction, and the member configuration instruction is used to instruct the instruction originating node to join or withdraw from the blockchain network.

As shown in Figure 9, corresponding to the aforementioned consensus method based on the blockchain network, this specification also provides a consensus device based on the blockchain network, which is applied to the slave nodes in the blockchain network. Any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes a set of member nodes of the blockchain network and a system configuration number used to identify the system configuration; the device includes:

The forwarding module 910 is configured to forward the instruction after receiving the instruction sent by the instruction initiating node; wherein the instruction includes a member configuration instruction or a regular instruction;

A consensus module 920, configured to perform consensus processing on the consensus proposal including the instruction;

The update module 930 is configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.

As shown in Figure 10, corresponding to the aforementioned consensus method based on the blockchain network, this specification also provides a consensus device based on the blockchain network, which is applied to the master node in the blockchain network. Any consensus node in the blockchain network maintains system configuration information locally, and the system configuration information includes a set of member nodes of the blockchain network and a system configuration number used to identify the system configuration; the device includes:

The consensus module 1110 is configured to coordinate other nodes to perform consensus processing on the consensus proposal after receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction; wherein the instruction includes a member configuration instruction or a regular instruction;

The update module 1120 is configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.

For the implementation process of the functions and effects of each component in the above-mentioned device, please refer to the implementation process of the corresponding steps in the above-mentioned method for details, and details will not be repeated here.

As for the device embodiment, since it basically corresponds to the method embodiment, for related parts, please refer to the part description of the method embodiment. The device embodiments described above are illustrative only. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. It can be understood and implemented by those skilled in the art without creative effort.

The embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and operable on the processor, wherein the aforementioned method is implemented when the processor executes the program. The method at least includes the method executed by the above instruction originating node, the slave node in the block chain network or the master node in the block chain network.

FIG. 11 shows a schematic diagram of a more specific hardware structure of a computing device provided by the embodiment of this specification. The device may include: a processor 1010 , a memory 1020 , an input/output interface 1030 , a communication interface 1040 and a bus 1050 . The processor 1010 , the memory 1020 , the input/output interface 1030 and the communication interface 1040 are connected to each other within the device through the bus 1050 .

The processor 1010 can be implemented by a general-purpose CPU (Central ProcessiNg UNit, central processing unit), a microprocessor, an application-specific integrated circuit (ApplicationN Specific INtegrated Circuit, ASIC), or one or more integrated circuits, and is used to execute related programs to realize the technical solutions provided by the embodiments of this specification.

The memory 1020 can be implemented in the form of ROM (Read ONly Memory, read-only memory), RAM (RaNdom Access Memory, random access memory), static storage device, dynamic storage device, etc. The memory 1020 can store operating systems and other application programs. When implementing the technical solutions provided by the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and invoked by the processor 1010 for execution.

The input/output interface 1030 is used to connect the input/output module to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, and the like.

The communication interface 1040 is used to connect a communication module (not shown in the figure), so as to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), and can also realize communication through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

Bus 1050 includes a path that carries information between the various components of the device (eg, processor 1010, memory 1020, input/output interface 1030, and communication interface 1040).

It should be noted that although the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include other components. In addition, those skilled in the art can understand that the above-mentioned device may only include components necessary to implement the solutions of the embodiments of this specification, and does not necessarily include all the components shown in the figure.

The embodiment of the present specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the aforementioned method is implemented. The method at least includes the method executed by the above instruction originating node, the slave node in the blockchain network, or the master node in the blockchain network.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, A magnetic tape cartridge, disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (traNsitory media), such as modulated data signals and carrier waves.

It can be known from the above description of the implementation manners that those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the essence of the technical solutions of the embodiments of this specification or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products can be stored in storage media, such as ROM/RAM, A magnetic disk, an optical disk, etc., include several instructions to enable a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this specification.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, please refer to part of the description of the method embodiment. The device embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated, and the functions of each module may be integrated in the same or multiple software and/or hardware implementations. Part or all of the modules can also be selected according to actual needs to achieve the purpose of the solution of this embodiment. It can be understood and implemented by those skilled in the art without creative effort.

The above is only the specific implementation of the embodiment of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiment of this specification, some improvements and modifications can also be made. These Improvements and modifications should also be regarded as the scope of protection of the embodiments of this specification.

Claims (24)

1. A consensus method based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration system configuration number; the methods described include:

   The instruction initiating node broadcasts an instruction carrying a system configuration number to at least some member nodes in the blockchain network; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to instruct the instruction initiating node to join or remove remove said blockchain network;

   Any slave node in the blockchain network forwards the instruction according to the system configuration number carried in the instruction and the locally maintained system configuration number;

   After receiving the instruction and generating a consensus proposal including the instruction, the master node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal according to the local system configuration number; the consensus proposal includes membership configuration directives and/or general directives;

   After any member node in the blockchain network determines that a consensus has been reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, then update the locally maintained system configuration information according to the member configuration instruction.
2. The method according to claim 1, wherein the system configuration number carried in the instruction is used to identify the system configuration targeted by the instruction;

   Any slave node in the blockchain network forwards the instruction according to the system configuration number carried in the instruction and the system configuration number maintained locally, including:

   If the instruction is not executed locally, if it is determined that the system configuration number is the same as the locally stored system configuration number, then forward the member configuration instruction to the master node; if it is determined that the system configuration number is smaller than the locally stored system configuration number , forward the instruction to the member nodes in the locally maintained member node set;

   When the instruction is executed locally, the execution result and system configuration history information are returned to the instruction originating node.
3. The method according to claim 2, further comprising:

   After the master node receives the instruction, it stores the instruction in the local instruction pool;

   Said generating a consensus proposal comprising said instructions, comprising:

   Obtain a preset number of instructions from the local instruction pool;

   For any member configuration instruction in the preset number of instructions, if the member configuration instruction is used to indicate that the instruction originating node that will initiate the instruction joins the blockchain network, assign a member node serial number to the instruction originating node , combining the member node serial number and the member configuration instruction into a member joining instruction; if the member configuration instruction is used to indicate that the instruction originating node that will initiate the instruction withdraws from the blockchain network, then the instruction originating node The combination of the member node serial number and the member configuration instruction is a member exit instruction;

   For the preset number of instructions, the member join instruction, member exit instruction and regular instructions are packaged into a consensus proposal.
4. The method according to claim 3, further comprising:

   After assigning a member sequence number to the instruction initiating node, adding the instruction initiating node to a temporary member set; the temporary member set includes all member nodes in the local system configuration;

   The coordinating other nodes to perform consensus processing on the consensus proposal, including:

   broadcasting a pre-preparation message to nodes in the temporary membership set based on the consensus proposal;

   Any slave node, after receiving a valid pre-preparation message, for the member joining instruction in the consensus proposal, adds the member node serial number in the member joining instruction to the local temporary member set, and sends the local temporary member The nodes in the set broadcast a preparation message for the consensus proposal; the preparation message carries the signature of the slave node;

   Any member node, after receiving the preparation message for the consensus proposal broadcast by 2/3 member nodes in the member node set configured by the local system, stores the signature of the received preparation message as the proof of the consensus proposal, And broadcast the commitment message for the consensus proposal, or, after receiving the commitment message for the consensus proposal broadcast by 1/3 member nodes in the set of member nodes configured by the local system, use the signature of the received commitment message as Store the proof of the consensus proposal, and broadcast a commitment message for the consensus proposal; wherein, the commitment message carries the signature of the node;

   After receiving the commitment message for the consensus proposal broadcast by 2/3 member nodes in the set of member nodes configured by the local system, it is determined that a consensus is reached for the consensus proposal, and the consensus proposal is executed.
5. The method according to claim 4, characterized in that the method further comprises:

   Any slave node, after adding the member node serial number in the member joining command to the temporary member group, in the case that the system configuration number carried in the member joining command is smaller than the local system configuration number, send the node to the command corresponding to the member node serial number Send local system configuration information and system configuration history information;

   After the instruction initiating node receives the system configuration information and the system configuration history information, it verifies the received system configuration information according to the system configuration history information, and after the verification is passed, it verifies the system configuration information according to the received system configuration history information. The local system configuration information is updated; the system configuration history information is a set of target consensus proposals, wherein the target consensus proposals are consensus proposals including member joining instructions or member exit instructions.
6. The method according to claim 5, wherein the system configuration history information includes a proof of each target consensus proposal;

   The verification of the received system configuration information according to the system configuration history information includes:

   The target proposal is verified based on the proof in the system configuration history information, and when all target proposals pass the verification, it is determined that the system configuration history information and the system configuration information pass the verification.
7. The method according to claim 3, wherein updating the locally maintained system configuration information according to the member configuration instruction comprises:

   After reaching a consensus on the consensus proposal, any node in the blockchain network will add the member node serial number in the member joining instruction to the locally maintained system configuration information for any member joining instruction in the consensus proposal In the set of member nodes in ;

   For any member exit instruction in the consensus proposal, remove the member node serial number in the member exit instruction from the member node set in the locally maintained system configuration information;

   Update the system configuration number.
8. The method according to claim 7, wherein the method further comprises:

   Any node in the blockchain network adds the consensus proposal to the system configuration history information;

   Return the member configuration processing result to the initiating node corresponding to the member configuration instruction included in the consensus proposal; wherein, the member configuration instruction is used to indicate that the instruction initiating node of the instruction is added to the blockchain network;

   After receiving the configuration processing results sent by 2/3 member nodes, the instruction originating node of any member configuration instruction can determine that the instruction has been executed and determine to join the blockchain network locally.
9. The method according to claim 8, characterized in that the method further comprises:

   The instruction initiating node of any member configuration instruction, after storing the proof of the consensus proposal during the consensus process, if the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to indicate that the If the initiating node is instructed to withdraw from the blockchain network, it is determined to withdraw locally from the blockchain network.
10. The method according to claim 8, characterized in that the method further comprises:

    The instruction initiating node of any member configuration instruction determines that the consensus proposal is executed, and the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used to instruct the instruction initiating node from the If the block chain network exits, it is determined that the local exits from the block chain network.
11. The method according to any one of claims 9 or 10, further comprising:

    Any node in the blockchain network for any conventional command in the consensus proposal, after the local execution is completed, if it is determined that the system configuration number in the command is the same as the local system configuration number, it will initiate a The node returns the processing result;

    If it is determined that the system configuration number in the instruction is smaller than the local system configuration number, then return the processing result and system configuration history information to the instruction originating node of the instruction.
12. The method according to claim 11, characterized in that the method further comprises:

    Any slave node obtains system configuration information when it detects that the view switching condition is met;

    If the obtained system configuration number is the same as the locally maintained system configuration number, broadcast the view switching command to the member nodes in the locally maintained member node set;

    If the obtained system configuration number is greater than the locally maintained system configuration number, broadcast a historical data acquisition message to the member nodes in the member node set corresponding to the acquired system configuration number; wherein, the historical data acquisition message carries the locally maintained system configuration number;

    Any member node in the member node set, after receiving the historical data acquisition message, if it is determined that the system configuration number carried in it is smaller than the local system configuration number, and the node sending the historical data acquisition message is a locally maintained member node A node in the set returns a response message to the node for the historical data acquisition message; wherein, the response message carries all the consensus proposals executed by the member node;

    When the slave node receives the response message returned by 1/3 of the member nodes in the member node set, and the information carried in the response message is the same, it updates the local data according to the response message.
13. The method according to claim 11, characterized in that the method further comprises:

    Any slave node, when it detects that the view switching condition is met, broadcasts a view switching instruction to the member nodes in the locally maintained member node set; the view switching message carries the target system configuration number;

    Any slave node forwards the view switching message according to the target system configuration number after receiving the view switching message broadcast by other nodes;

    When the master node receives the view switching message sent by 2/3 nodes in the locally maintained system configuration member node set, it broadcasts a new view message to all member nodes of the locally maintained system configuration, so that the system configuration The nodes in the member node collection of the enter into the new view.
14. The method according to claim 13, wherein the forwarding of the view switching message according to the target system configuration number comprises:

    After any slave node receives the view switching message broadcast by other nodes, if it determines that the target system configuration number in the view switching message is smaller than the local system configuration number, and the member nodes corresponding to the local system configuration number are more than the target system configuration number The corresponding member node forwards the view switching message to the first node; wherein the first node includes nodes in the member node set configured by the local system but not in the member node set configured by the target system;

    If it is determined that the target system configuration number in the view switching message is greater than the local system configuration number, then the local system configuration is updated to the system configuration corresponding to the target system configuration number. Forward the view switch message to a second node, which is a node included in the member node set configured by the target system but not in the member node set configured by the local system; no view switch has been sent locally in this round In the case of a message, the view switching message is forwarded to all nodes corresponding to the target system configuration number.
15. The method according to claim 14, wherein the view switching condition comprises:

    After a consensus is reached on the consensus proposal, and the consensus proposal includes a member configuration instruction.
16. A consensus method based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes of the block chain network and a system configuration number for identifying the system configuration; said method comprising:

    Broadcast an instruction carrying a system configuration number to at least some member nodes in the blockchain network, so that the blockchain network generates a consensus proposal including the instruction and performs consensus processing on the consensus proposal according to the system configuration number; wherein, the The instructions include member configuration instructions or general instructions, and the member configuration instructions are used to instruct the instruction originating node to join or remove from the blockchain network.
17. A consensus method based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration system configuration number; the methods described include:

    After receiving the instruction sent by the instruction originating node, the instruction is forwarded according to the system configuration number carried in the instruction and the locally maintained system configuration number; wherein the instruction includes a member configuration instruction or a regular instruction;

    Consensus processing is performed on the consensus proposal including the instructions; the consensus proposal includes member configuration instructions and/or general instructions;

    After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.
18. A consensus method based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration system configuration number; the methods described include:

    After receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction, coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number; wherein the instruction includes member configuration instructions or regular instructions ; The consensus proposal includes member configuration instructions and/or general instructions;

    After a consensus is reached on the consensus proposal, if the consensus proposal includes a member configuration instruction, locally maintained system configuration information is updated according to the member configuration instruction.
19. A consensus system based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration System configuration number; said system includes:

    The instruction originating node is used to broadcast the instruction carrying the system configuration number to at least some member nodes in the blockchain network; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to instruct the instruction originating node to join or leave said blockchain network;

    Any slave node in the blockchain network is used to forward the instruction according to the system configuration number carried in the instruction and the system configuration number maintained locally;

    The master node in the blockchain network is used to coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number after receiving the instruction and generating a consensus proposal including the instruction; the consensus Proposals include membership directives and/or general directives;

    Any node in the blockchain network is configured to update locally maintained system configuration information according to the member configuration instruction after determining that a consensus has been reached on the consensus proposal, if the consensus proposal includes a member configuration instruction.
20. A consensus device based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration System configuration number; the unit described includes:

    The obtaining module is used to obtain system configuration information;

    The broadcast module updates the local system configuration information according to the acquired system configuration information, and broadcasts instructions carrying system configuration numbers to at least some member nodes in the blockchain network according to the updated system configuration information, so that the blockchain network Generate a consensus proposal including the instruction and perform consensus processing on the consensus proposal according to the system configuration number; wherein, the instruction includes a member configuration instruction or a general instruction, and the member configuration instruction is used to indicate that the instruction originating node joins or withdraws from the blockchain network.
21. A consensus device based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration System configuration number; the unit described includes:

    The forwarding module is configured to forward the instruction according to the system configuration number carried in the instruction and the locally maintained system configuration number after receiving the instruction sent by the instruction initiating node; wherein the instruction includes a member configuration instruction or general order;

    A consensus module, configured to perform consensus processing on the consensus proposal including the instructions; the consensus proposal includes member configuration instructions and/or regular instructions;

    An update module, configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.
22. A consensus device based on a block chain network, characterized in that any consensus node in the block chain network maintains system configuration information locally, and the system configuration information includes a set of member nodes and an ID for identifying system configuration System configuration number; the unit described includes:

    The consensus module is used to coordinate other nodes to perform consensus processing on the consensus proposal according to the local system configuration number after receiving the instruction sent by the instruction initiating node and generating a consensus proposal including the instruction; wherein the instruction includes Member configuration instructions or regular instructions; the consensus proposal includes member configuration instructions and/or regular instructions;

    An update module, configured to update the locally maintained system configuration information according to the member configuration instruction after reaching a consensus on the consensus proposal, if the consensus proposal includes a member configuration instruction.
23. A computer device, characterized by comprising a memory, a processor, a communication interface, and a computer program stored on the memory and operable on the processor, wherein, when the processor executes the program, it implements claims 16 to The method of any one of 18.
24. A computer-readable storage medium, characterized in that a computer program is stored thereon, and when the program is executed by a processor, the method according to any one of claims 16 to 18 is realized.

Images