CN114070733B - Consensus method, device and system based on block chain network - Google Patents

Consensus method, device and system based on block chain network Download PDF

Info

Publication number
CN114070733B
CN114070733B CN202210046656.1A CN202210046656A CN114070733B CN 114070733 B CN114070733 B CN 114070733B CN 202210046656 A CN202210046656 A CN 202210046656A CN 114070733 B CN114070733 B CN 114070733B
Authority
CN
China
Prior art keywords
instruction
system configuration
node
consensus
blockchain network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210046656.1A
Other languages
Chinese (zh)
Other versions
CN114070733A (en
Inventor
段斯斯
张海滨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shandong Blockchain Research Institute
Tsinghua University
Original Assignee
Shandong Blockchain Research Institute
Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shandong Blockchain Research Institute, Tsinghua University filed Critical Shandong Blockchain Research Institute
Priority to CN202210046656.1A priority Critical patent/CN114070733B/en
Publication of CN114070733A publication Critical patent/CN114070733A/en
Priority to PCT/CN2022/111013 priority patent/WO2023134159A1/en
Application granted granted Critical
Publication of CN114070733B publication Critical patent/CN114070733B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application provides a consensus method based on a block chain network, wherein any consensus node in the block chain network locally maintains system configuration information, the system configuration information comprises a member node set, and the method comprises the following steps: the instruction initiating node broadcasts an instruction to the blockchain network so that the blockchain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal; after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network updates locally maintained system configuration information according to the member configuration instruction if the consensus proposal comprises the member configuration instruction. By adopting the mode, the member node in the block chain network recognizes the member configuration instruction and the conventional instruction together as a recognition proposal, namely, the member configuration process can be executed without stopping the recognition process, thereby greatly improving the recognition efficiency of the block chain network.

Description

Consensus method, device and system based on block chain network
Technical Field
The present application relates to the field of computer technologies, and in particular, to a block chain network-based consensus method, apparatus, and system.
Background
In order to ensure the consistency of data, each consensus node in the blockchain network generally needs to perform consensus through various consensus methods, and when the 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, the consensus process of the blockchain network is usually stopped, the node joining or exiting process is started, and the consensus process is continued until the corresponding node joins or exits, so that the consensus efficiency of the blockchain network is greatly reduced.
Disclosure of Invention
According to a first aspect of the embodiments of the present application, an consensus method based on a blockchain network is provided in the embodiments of the present application, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a member node set and a system configuration number used for identifying system configuration; the method comprises the following steps:
the instruction initiating node broadcasts an instruction to at least part of member nodes in the blockchain network, so that the blockchain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the block chain network;
after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network updates locally maintained system configuration information according to the member configuration instruction if the consensus proposal comprises the member configuration instruction.
According to a second aspect of the embodiments of the present application, in the embodiments of the present application, there is provided a consensus system based on a blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a set of member nodes of the blockchain network and a system configuration number for identifying system configuration; the system comprises:
the instruction initiating node is used for broadcasting an instruction to at least part of member nodes in the blockchain network so that the blockchain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the block chain network;
and any member node in the blockchain network is used for updating the locally maintained system configuration information according to the member configuration instruction if the consensus proposal comprises the member configuration instruction after the consensus proposal is determined to reach the consensus.
According to a third aspect of the embodiments of the present application, in the embodiments of the present application, there is provided a consensus device based on a blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a member node set and a system configuration number used for identifying system configuration; the device comprises:
the acquisition module is used for acquiring system configuration information;
the broadcast module is used for updating the local system configuration information according to the acquired system configuration information and broadcasting an instruction to at least part of member nodes in the blockchain network according to the updated system configuration information so as to enable the blockchain network to generate a consensus proposal comprising the instruction and perform consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the blockchain network.
According to a fourth aspect of the embodiments of the present application, in the embodiments of the present application, there is provided a consensus device based on a blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a member node set and a system configuration number used for identifying system configuration; the device comprises:
the forwarding module is used for forwarding the instruction after receiving the instruction sent by the instruction initiating node; wherein the instructions comprise member configuration instructions or regular instructions;
a consensus module for performing consensus processing for a consensus proposal comprising the instruction;
and the updating module is used for updating the locally maintained system configuration information according to the member configuration instruction if the consensus proposal comprises the member configuration instruction after the consensus proposal reaches consensus.
According to a fifth aspect of the embodiments of the present application, in the embodiments of the present application, there is provided a consensus device based on a blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a member node set and a system configuration number used for identifying system configuration; the device comprises:
the consensus module is used for coordinating other nodes to perform consensus processing on the consensus suggestions after receiving the instructions sent by the instruction initiating node and generating the consensus suggestions comprising the instructions; wherein the instructions comprise member configuration instructions or regular instructions;
and the updating module is used for updating the locally maintained system configuration information according to the member configuration instruction if the consensus proposal comprises the member configuration instruction after the consensus proposal reaches consensus.
By adopting the consensus method provided in the embodiment of the application, the node which needs to join or quit the blockchain network can broadcast the member configuration instruction to the blockchain network after acquiring the system configuration information of the current blockchain network, the instruction is used for indicating that the node is added to or removed from the blockchain network, the member node in the blockchain network can perform consensus on the member configuration instruction and the conventional instruction as a consensus proposal together, each consensus node can execute the member configuration instruction after achieving consensus based on the consensus proposal, and the member configuration process can be executed without respectively processing the member configuration instruction and the conventional instruction, namely without stopping the consensus process, so that the consensus efficiency of the blockchain network is greatly improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic diagram of a network architecture topology according to an embodiment of the present disclosure;
fig. 2 is a flowchart illustrating a block chain network-based consensus method according to an embodiment of the present disclosure;
fig. 3 is a schematic diagram illustrating adding a node to a blockchain network according to an embodiment of the present disclosure;
fig. 4 is a schematic diagram of a block chain network-based consensus method according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of system configuration history information according to an embodiment of the present disclosure;
fig. 6 is a diagram illustrating view switching message forwarding according to an embodiment of the present disclosure;
fig. 7 is a diagram illustrating another view switch message forwarding according to an embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of a block chain network-based consensus device according to an embodiment of the present disclosure;
fig. 9 is a schematic structural diagram of another block chain network-based consensus device according to an embodiment of the present disclosure;
fig. 10 is a schematic structural diagram of another block chain network-based consensus device according to an embodiment of the present disclosure;
fig. 11 is a schematic structural diagram of an apparatus for configuring a device according to an embodiment of the present disclosure.
Detailed Description
The block chain network is used as a distributed data storage network, each node in the block chain network needs to ensure the consistency of data, and each node needs to perform consensus through various consensus methods, wherein the consensus refers to a process that each node achieves 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, the consensus process of the blockchain network is usually stopped, the process of joining or exiting the node is started, and the consensus process is continued until the corresponding node joins or exits, so that the consensus efficiency of the blockchain network is greatly reduced. Wherein, the consensus process generally refers to the consensus of the conventional instruction.
In view of the foregoing problems, an embodiment of the present application provides a consensus method based on a blockchain network, where when a node needs to join or leave the blockchain network, a member configuration instruction may be broadcast to the blockchain network, where the instruction is used to instruct the node to join or leave the blockchain network, a consensus node in the blockchain network identifies the member configuration instruction and a conventional instruction together as a consensus proposal, and after reaching consensus based on the consensus proposal, each consensus node may execute the member configuration instruction without separately processing the member configuration instruction and the conventional instruction, that is, without stopping the consensus process for the conventional instruction, so that the consensus efficiency of the blockchain network is greatly improved.
The solution in the embodiment of the present application may be implemented by using various computer languages, for example, object-oriented programming language Java and transliteration scripting language JavaScript, etc.
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further detailed description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that, in the present application, the embodiments and features of the embodiments may be combined with each other without conflict.
In order to make the present solution more clear to those skilled in the art, the following explains some of the names appearing in the present specification:
in this specification, a node in a blockchain network includes 1 master node for generating a consensus proposal and initiating consensus in a consensus process and N slave nodes participating in the consensus process.
The consensus proposal is a preset number of instructions that the master node gets from the local instruction pool.
In this specification, a member node of a blockchain refers to a consensus node participating in consensus in a blockchain network, that is, a master node and a slave node are both referred to as member nodes, each member node maintains system configuration information, and the system configuration information specifically refers to a member node set of the blockchain network and a system configuration number used for identifying system configuration, where the system configuration number is updated when a member node exits from the blockchain network or other nodes join the blockchain network to become a member node, and a specific implementation manner may be to increment the system configuration number by using 1 as a step length.
As shown in table 1, a specific example of system configuration information is shown.
Figure 292281DEST_PATH_IMAGE001
TABLE 1
Wherein the system configuration number is incremented by 1, for example, when node P 5 After joining the blockchain network, the member nodes in each blockchain network update the local configuration information to the information shown in table 2.
Figure 953201DEST_PATH_IMAGE002
TABLE 2
In this specification, a block chain network is specifically a block chain network that follows BFT (Byzantine Fault Tolerance), that is, the block chain network includes M consensus nodes, where f malicious nodes are allowed to exist at most, and M ≧ 3f +1, f and M are integers greater than 0.
As shown in FIG. 1, a schematic structural diagram of a network topology is proposed for the present specification, in which a node P is shown 1 - P 4 Forming a block chain network, P 5 Refers to other nodes that want to join the blockchain network, which need to go to node P 1 - P 4 The block chain network sends member configuration instructions to join the block chain network, and in addition, if any node in the block chain network wants to exit the block chain network, the member configuration instructions need to be broadcasted to the block chain network to exit from the block chain network.
In this specification, the conventional instruction refers to an instruction that does not involve changing a member node of the blockchain network, such as performing addition, deletion, change and check on data, and the member configuration instruction refers to an instruction that is sent by an instruction initiating node and is used for instructing to join or leave the blockchain network.
In this specification, each node may be a hardware device having a processing function, such as a server or a mobile terminal, and this specification does not limit this.
As shown in fig. 2, based on the above description, the present specification proposes a block chain-based consensus method, where any consensus node in the block chain network locally maintains system configuration information, where the system configuration information includes a set of member nodes in the block chain network and a system configuration number for identifying system configuration; the method comprises the following steps:
s201, an instruction initiating node broadcasts an instruction to at least part of member nodes in a block chain network, so that the block chain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the block chain network;
based on the network topology shown in fig. 1, it can be understood that the instruction initiating node may be any node in the blockchain network or another node not in the blockchain network, and may send an instruction to the blockchain network, where the instruction may also be referred to as a transaction, which is not limited in this specification.
Specifically, when the instruction initiating node is a node other than the blockchain network, the instruction initiating node may send a conventional instruction and a member configuration instruction for instructing to add itself to the blockchain network;
when the instruction initiating node is a member node in the blockchain network, it may send a regular instruction as well as a member configuration instruction for instructing to exit itself from the blockchain network.
If the instruction initiating node is a node outside the blockchain network, the instruction initiating node can acquire system configuration information of the blockchain network in advance through a corresponding channel and a corresponding mode, and further can determine member nodes in the blockchain network according to the configuration information, and further can send instructions to the member nodes. Specific contents of the system configuration information may refer to the following description, and will not be described in detail first.
The member nodes in the blockchain network, upon receiving the instruction, can generate a consensus proposal including the instruction and perform consensus processing based on the consensus proposal.
S202, after any member node in the block chain network achieves consensus aiming at the consensus proposal, if the consensus proposal comprises a member configuration instruction, updating the locally maintained system configuration information according to the member configuration instruction.
After reaching the consensus for the consensus proposal, the consensus node in the blockchain network may execute the consensus proposal, wherein if the consensus proposal includes a member configuration instruction, the locally maintained system configuration information is updated according to the member configuration instruction to synchronize the system configuration information in each consensus node, that is, the member node set in the locally maintained system configuration information may be updated according to the member configuration instruction, and the system configuration number may be updated. The operations of table 1 were changed to table 2 as described above.
By adopting the scheme, the member configuration instruction and the conventional instruction are packed together to be the consensus proposal for consensus, each consensus node can execute the member configuration instruction after achieving consensus based on the consensus proposal, the member configuration instruction and the conventional instruction do not need to be processed respectively, namely the member configuration process can be processed without stopping the consensus process, and therefore the consensus efficiency of the blockchain network is greatly improved.
Before executing the above S201, if the instruction initiating node is a node other than the blockchain network, it needs to acquire system configuration information of the blockchain network, and then may know information of member nodes in the blockchain network according to the system configuration information, and further may broadcast an instruction to the member nodes in the blockchain network, where a manner that the instruction initiating node acquires the system configuration information of the blockchain network is described below.
In one embodiment, since the instruction initiating node is usually a server or a client with processing capability, it can obtain the system configuration information directly based on the input of the administrator, that is, the administrator directly configures the system configuration information in the instruction initiating node.
In another embodiment, the instruction initiating node may further send a system configuration acquisition request to the information storage node; after receiving the system configuration acquisition request, the information storage node may return system configuration information to the instruction initiating node, and the instruction initiating node updates local system configuration information according to the system configuration information, and may further broadcast an instruction to the blockchain network according to the updated system configuration information.
In this embodiment, because all member nodes in the blockchain network maintain system configuration information, all member nodes in the blockchain network may serve as information storage nodes, and any member node may return system configuration information to the instruction initiating node after receiving the system configuration acquisition request.
In addition, on one hand, considering that the member nodes in the blockchain network change at any time, as the nodes outside the blockchain network, it is impossible and unnecessary to know the member nodes currently included in the blockchain network, and therefore, it is necessary to broadcast system configuration acquisition requests to all the possible member nodes in the blockchain network, which undoubtedly increases the consumption of network bandwidth; on the other hand, the member nodes in the blockchain network are all in the consensus process at any time, and if the member nodes also all need to respond to the system configuration acquisition request initiated by the instruction initiating node, the burden of the member nodes in the blockchain network is undoubtedly increased.
Thus, in one embodiment, a designated node may also be predefined, which is dedicated to responding to system configuration acquisition requests initiated by the instruction initiating node.
For example, the information storage node comprises any designated node in the blockchain network or outside the blockchain network; when the instruction initiating node outside the blockchain network needs to acquire the system configuration information of the blockchain network, it may send a system configuration acquisition request to the designated node, and the designated node returns the system configuration information to the instruction initiating node. In addition, when the designated information storage node is a node other than the blockchain network, the designated information storage node can receive the information sent by the member node when the member node in the blockchain network synchronously updates the system configuration information, and further synchronously updates the local system configuration information. By adopting the mode, the instruction initiating node only needs to know the communication address of one node of the information storage node, and meanwhile, the instruction initiating node does not need to broadcast the system configuration acquisition request, so that the consumption of network bandwidth is reduced, and the burden of member nodes and the instruction initiating node in the block chain network is also reduced.
In an embodiment, when the instruction initiating node is a node in a blockchain network, there may be a case that local system configuration information is not updated due to a network reason, and therefore, when it needs to initiate an instruction to the blockchain network, it may also send a configuration information obtaining request to the information storage node, which is not limited in this specification.
In addition, in some special predefined network environments, for example, in a network environment in which some nodes are few and all the node identities are public, the instruction initiating node may directly use all the nodes in the predefined network as members of the blockchain network, that is, use a set composed of all the nodes in the predefined network as a set of member nodes in the system configuration information, and use a predefined value as the system configuration number, where the predefined value may be any predefined value that is not the actual system number, for example, the predefined value is set to a nail.
In order to ensure the credibility of the system configuration information, when returning the system configuration information to the instruction initiating node, the information storage node can send the system configuration history information to the instruction initiating node, and further, after receiving the acquisition request response message, the instruction initiating node can verify the system configuration information according to the system configuration history information, and when the verification is passed and the system configuration number in the system configuration information is larger than the locally maintained system configuration number, the local system configuration is updated according to the system configuration information.
It can be understood that, if the instruction initiating node establishes a contact with the blockchain network for the first time, and may not store any system configuration information locally, the system configuration information may be stored locally directly after the verification is passed, that is, the number of the local system configuration information may be regarded as 0, and the received system configuration information is greater than the number of the local system configuration information anyway. In addition, the instruction initiating node may be a node that previously exits from the blockchain network, or a node that has sent an instruction to the blockchain network, and therefore the instruction initiating node locally stores the system configuration information, and therefore, after receiving the system configuration information, if the received system configuration number is greater than the local system configuration number, it indicates that the local system configuration information is not updated, and after the received system configuration information passes verification, the local system configuration may be updated according to the received system configuration information.
For example, the information storage node may return a message < CONF, c ', mc ', chip ' >, to the instruction initiating node, where the CONF identifies a message type, c ' is a system configuration number, mc ' is a set of member nodes corresponding to the system configuration number, that is, c ' and Mc ' are system configuration information, chip ' is system configuration history information, specific content of chip ', and a manner of verifying the system configuration information by using the system configuration history information may be referred to below, which is not described in detail herein.
It is to be understood that the above-mentioned manner of acquiring the system configuration information may be applied not only to the consensus method provided in this specification, but also to other consensus methods that require the use of the system configuration information, or other technologies that require the use of the system configuration information.
According to the above, the instruction initiating node obtains the system configuration information, so in the above S201, the instruction initiated by the instruction initiating node may carry a system configuration number, which is used to identify a system configuration version to which the instruction is directed; for example, it may send an instruction in the form of < SUBMIT, c, < JOIN, pk > > where SUBMIT is the instruction type identifier, c is the system configuration number, pk is its public key, and JOIN indicates that the instruction is used to instruct the initiating node of the instruction to JOIN the blockchain network. Or it may send a message in the form of < SUBMIT, c, < LEAVE, i > >, where i is the member node number of the instruction initiating node in the blockchain network, LEAVE represents the instruction for instructing the instruction initiating node to remove the blockchain network, and in general, the instruction initiating node may initiate the instruction based on the local current system configuration number.
As can be seen from the above, since the information storage node may 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 does not update the local system configuration information in time, the number of nodes returned to the instruction initiating node may also be less than all member nodes currently owned by the blockchain network. Therefore, in the above S201, the instruction initiating node may broadcast the instruction to at least some member nodes in the current blockchain network according to the updated system configuration information, and after the broadcast, any slave node in the blockchain network may forward the instruction after receiving the instruction, that is, after receiving the instruction sent by the instruction initiating node, the slave node in the blockchain network may forward the instruction to other nodes in the blockchain network, and simultaneously store the instruction in the local instruction pool. After the master node in the block chain network receives the instruction and generates a consensus proposal comprising the instruction, coordinating other nodes to perform consensus processing on the consensus proposal.
After receiving the instruction, any slave node in the blockchain network forwards the instruction, specifically, under the condition that the instruction is not executed locally, if it is determined that the system configuration number is the same as a locally stored system configuration number, forwarding the member configuration instruction to the master node; if the system configuration number is smaller than the locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set;
after any slave node receives the instruction, if the slave node determines that the instruction is not executed locally, it indicates that no consensus is achieved for the instruction, and further, if the system configuration number is determined to be the same as the locally stored system configuration number, it indicates that the system configuration number of the instruction initiating node is the same as the local system configuration number, and the instruction is directly forwarded to the master node.
If the system configuration number is determined to be smaller than the locally stored system configuration number, it indicates that the system configuration of the instruction initiating node is not updated, and the member node broadcasted by the instruction initiating node is not the latest member node, so that the instruction broadcasted by the instruction initiating node needs to be forwarded to all the member nodes corresponding to the local system configuration. For example, the instruction sent by the instruction initiating node carries a system configuration number 1, and the corresponding member node set includes P 1 、P 2 、P 3 、P 4 And four nodes. The local system configuration number is 2, and the corresponding member node set comprises P 1 、P 2 、P 3 、P 4 、P 5 Five nodes, and thus can be directed to P 1 、P 2 、P 3 、P 4、 P 5 The five nodes forward the instruction so that P 5 The instruction may also be received.
When the system configuration number carried in the instruction initiated by the instruction initiating node is a predefined value, each slave node may regard it as a value the same as the local system configuration number, or regard it as a value smaller than the local system configuration number, and further trigger corresponding forwarding processing, which is not limited in this specification.
In addition, due to network delay and the like, a node receives an instruction sent by an instruction initiating node later, and at this time, the node may already have received the instruction because other nodes in the blockchain network already have received the instruction, so that consensus processing on the instruction is already completed, and the instruction is already executed. Thus, the execution result and the configuration history message may be returned to the instruction initiating node. For example, a < REPLY, c, re, chist > message may be sent to the instruction initiating node. Wherein, REPLY refers to message type identification, c refers to system configuration number, re refers to execution result, and test refers to configuration history message. The description of the best is not provided here, and specific contents can be referred to below.
In the above S201, after receiving the instruction, the master node in the blockchain network may store the instruction in a local instruction pool, and after a preset consensus period is reached or a preset number of instructions are stored in the instruction pool, a certain number of instructions may be obtained from the instruction pool and packaged into a consensus offer, and the master node packages both the member configuration instruction and the conventional instruction into the consensus offer to process the consensus offer.
After the main node obtains a preset number of instructions from the instruction pool, configuring an instruction for any member in the preset number of instructions, if the member configuration instruction is determined to be used for indicating that an instruction initiating node initiating the instruction is added into the block chain network, allocating a member node serial number to the instruction initiating node, and combining the member node serial number and the member configuration instruction into a member adding instruction. For example, if the serial number of the member node allocated to the instruction initiating node is j and the member configuration instruction is m, 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 for indicating that the instruction initiating node initiating the instruction exits from the blockchain network, the member node serial number of the instruction initiating node and the member configuration instruction are combined into a member exiting instruction. Since the instruction initiating node is a node in the blockchain network, it has a member node sequence number, for example, if the member node sequence number is i and the instruction is m, the combined member exit instruction is < REMOVE, i, m >, where REMOVE refers to the type identifier of the member exit instruction.
After the main node processes the member configuration instructions in the obtained preset number of instructions, the obtained member adding instructions, member quitting instructions and unprocessed conventional instructions can be packaged into a consensus proposal. For example, the master node acquires 10 instructions from the instruction pool, wherein the 1 st and 10 th instructions are member configuration instructions, and the other instructions are conventional instructions, and after the 1 st and 10 th instructions are modified into member adding instructions or member quitting instructions, the master node packs the modified 1 st and 10 th instructions and the other conventional instructions into a consensus proposal.
In addition, after the master node allocates the member serial number to the instruction initiating node, the master node can add the instruction initiating node into the temporary member set. The temporary member set may be understood as a node that receives the consensus message in the blockchain network, but does not participate in the consensus process.
As shown in fig. 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 a member node number E to the node PE and then adds E to the temporary member set TM, where M in the diagram represents a member node set corresponding to the current system configuration, and configuration c represents a system configuration c, and if the instruction is agreed and executed for the member configuration instruction (corresponding to the delivery branch of the Deliver in the diagram), the E is added to the member node set, and if the instruction is not agreed and executed for the member configuration instruction (corresponding to the delivery branch of the FailDeliver in the diagram), the E is removed from the temporary member node set.
After the instruction initiating node is added into the temporary member set and the consensus suggestion is packaged, the main node can coordinate other nodes to perform consensus processing on the consensus suggestion, and can broadcast a pre-preparation message to the member nodes in the temporary member set based on the consensus suggestion, namely broadcast the pre-preparation message carrying the consensus suggestion to the member nodes in the temporary member set, so that all the nodes in the temporary member set can receive the pre-preparation message; wherein, the pre-prepared message carries the signature of the main node. The PREPARE message may be a message in the form of < PRE-PREPARE, v, c, s, batch >, where PRE-PREPARE identifies the message type, v denotes the current view, c identifies the system configuration number stored by the master node, s is the number of the current consensus proposal, and batch is the consensus proposal.
After receiving a pre-preparation message, adding a member node serial number in a member adding instruction into a local temporary member set according to the member adding instruction in the consensus proposal, and broadcasting a preparation message aiming at the consensus proposal to nodes in the local temporary member set; the signature of the slave node is carried in the PREPARE message, and the PREPARE message may be a message in the form of < PREPARE, v, c, s, h (batch) >, where PREPARE is a message type identifier and h (batch) is a hash value proposed for consensus.
It will be appreciated that all slave nodes of the blockchain network will perform the above-described operation, i.e. all slave nodes will issue a prepare message for the consensus proposal after receiving the prepare message.
Any node comprises a master node or a slave node, and after receiving a preparation message broadcast by 2/3 member nodes in a member node set configured by a local system, the signature of the received preparation message is stored as the proof of the consensus proposal, and a commitment message aiming at the consensus proposal is broadcast; the commitment message carries the signature of the node, wherein the commitment message may be a message in the form of < COMMIT, v, c, s, δ >, wherein COMMIT identifies for a message type, and δ also represents a hash value for a consensus proposal.
Since in this specification, a malicious node in the blockchain network is smaller than all nodes by 1/3, after the preparation message for the consensus proposal broadcast by the 2/3 member nodes, the malicious node can be regarded as the preparation message sent by the correct node, so that the commitment message for the consensus proposal can be broadcast, the signature information of the malicious node can be stored in the commitment message, and the signature of the received preparation message can be stored as the proof of the consensus proposal.
In addition, any slave node may not receive the preparation message for the consensus proposal broadcast by 2/3 member nodes due to network delay and the like, but receives the commitment message for the consensus proposal broadcast by 1/3 member nodes in the member node set configured in the local system, which also indicates that the commitment message is broadcast by nodes exceeding the number of malicious nodes, and the commitment message can be considered to be sent by the correct node, so that the slave node can also send the commitment message for the consensus proposal.
After receiving the promise message of more than 2/3 member nodes in the current configuration, the slave node determines to reach consensus for the consensus proposal and executes the consensus proposal.
In addition, when the information storage node is a designated node outside the blockchain network, after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network sends a consensus message to the information storage node, so that the information storage node updates local system configuration information and system configuration history information.
Specifically, after each consensus is completed, a member node in the block chain network additionally sends a commitment message to the information storage node, and the information storage node updates the locally maintained configuration information and updates the system configuration history information according to the received commitment message, wherein the information storage node may also update the locally maintained configuration information and update the system configuration history information after receiving the commitment message sent by 2/3 of the member nodes.
As shown in fig. 4, for a schematic diagram of the consensus process for a conventional instruction proposed in this specification, c in the diagram is a node that is not in the blockchain network, i.e., an instruction initiating node, which broadcasts an instruction to at least some member nodes in the blockchain network, e.g., in fig. 4, which sends an instruction to the member node 0, the member node 0 is a master node, which sends a pre-prepare message (prepare message) to other member nodes, i.e., nodes 1, 2, and 3, the node 3 in the diagram is a malicious node, and the nodes 0, 1, and 2 are correct nodes, so that the node 3 does not send a prepare message (prepare message) after receiving the message, the nodes 1 and 2 broadcast the prepare message to other nodes in the blockchain network, and the nodes 0, 1, and 2 send a commit message (commit message) after receiving a sufficient number of prepare messages, and determine that a consensus is reached for the consensus proposing to return an execution result, i.e., a commit message to the instruction initiating node.
It is to be understood that fig. 4 illustrates a schematic diagram of consensus for a conventional instruction, and the part of the consensus process for the member configuration instruction is shown in fig. 4, and specific differences can be referred to below.
In an embodiment, after receiving the pre-preparation message sent by the master node, any slave node adds the member node serial number to the temporary member group for the member joining instruction in the consensus offer, and may send local system configuration information and system configuration history information to the instruction initiating node corresponding to the member node serial number in the case that the system configuration number carried in the member joining instruction is smaller than the local system configuration number. For example, it may send a message to the instruction initiating node, in the form of < CONF, c, mc, chip >, where c and Mc are current system configuration information, chip is system configuration history information, and CONF is a message type identifier.
That is, if the system configuration number carried in the member joining instruction is smaller than the local system configuration number, it indicates that the system configuration number of the instruction initiating node is not updated, and therefore, it is necessary to send the configuration history information to the member node serial number, that is, the instruction initiating node.
After receiving the system configuration information and the system configuration history information, the instruction initiating node may update the local system configuration information according to the configuration information. In consideration of the security and the credibility of the system configuration information, the instruction initiating node can verify the system configuration information, and after the verification is passed, the local system configuration information is updated according to the system configuration information. Specifically, the system configuration information may be verified according to system configuration history information, where the system configuration history information is a set of target consensus suggestions, and the target consensus suggestions are consensus suggestions including a member join instruction or a member quit instruction. That is, all member joining instructions or member exiting instructions are recorded in the system configuration history information. In addition, since each node stores the proof of the consensus proposal in 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, the instruction initiating node verifies each target proposal based on each proof in the system configuration history information, and determines that the system configuration history information is correct and safe when all target proposals are verified, and since the system configuration information is evolved based on the system configuration history information, the system configuration information can be determined to pass the verification.
As shown in fig. 5, a schematic structure diagram of system configuration history information proposed for this specification, where the system configuration history information includes three target consensus proposals, namely consensus proposal 1, consensus proposal 3, and consensus proposal 7, each target consensus proposal includes a member join instruction or a member withdraw instruction, and since the blockchain network updates the system configuration number after performing consensus and processing based on the target consensus proposals, the system configuration number corresponding to each target proposal is incremented, for example, consensus proposal 1 corresponds to system configuration number 1, consensus proposal 3 corresponds to system configuration number 2, and consensus proposal 7 corresponds to system configuration number 3, and after verifying each target consensus proposal in the system configuration history information based on the certificate corresponding to each target consensus proposal, the instruction initiating node may determine 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 information is the current system configuration, and the member node in the current system configuration information is the set of the system configuration information, so that the system configuration history information can be verified based on the system configuration information, and the system configuration history information can be obtained by verifying the system configuration information.
The local system configuration information may then be updated based on the system configuration information.
With reference to the above description, in S202, specifically, after reaching consensus for the consensus proposal, any node in the blockchain network may add a member node sequence number in the node access instruction to a member node set in locally maintained system configuration information for any member in the consensus proposal; removing the member node sequence number in the member exit instruction from a member node set in locally maintained system configuration information aiming at any member exit instruction in the consensus proposal; and updating the system configuration number, such as adding 1 to the system configuration number.
Further, after S202, in the case that the consensus suggestion includes a member joining instruction or a member quitting instruction, the consensus suggestion needs to be added to the system configuration history information to update the system configuration history information. And after the consensus is completed for all consensus suggestions with numbers lower than the suggestion, returning a member configuration processing result to the instruction initiating node corresponding to the member joining instruction included in the consensus suggestion, namely returning the member configuration processing result to the instruction initiating node of the member configuration instruction.
After receiving the configuration processing result sent by the 2/3 member node, the initiating node of the instruction can determine that the instruction is executed completely and determine that the initiating node locally joins the blockchain network.
For example, when a consensus proposal is agreed upon by each member node and the consensus proposal includes a member joining instruction, after consensus is completed on all consensus proposals with numbers lower than the proposal, a message in the shape of < HISTORY, s, h, C, P > is returned to the instruction initiating node, wherein HISTORY is a message type identifier, s is the number of the consensus proposal, h is a hash value of the consensus proposal, C is a local latest check point, and P is a locally stored certificate with a sequence number higher than all consensus proposals in C.
And for the instruction initiating node, after receiving the message of < HISTORY, s, h, C, P > sent by the 2/3 member nodes, the instruction initiating node determines to locally join the block chain network and participate in the subsequent consensus process of the block chain network.
In addition, in order to improve the efficiency of the instruction initiating node joining the blockchain network, the instruction initiating node can join the blockchain network and participate in consensus voting under the condition that the consensus proposal comprising the locally sent member joining instruction is determined to be agreed upon, but the consensus proposal is not received enough, namely the configuration processing result of the 2/3 member node is not received.
After storing the proof of the consensus proposal for the instruction initiating node of any member configuration instruction, if the member configuration instruction is included in the consensus proposal and the member configuration instruction is used for indicating to quit the instruction initiating node from the blockchain network, the instruction initiating node is determined to locally quit from the blockchain network.
That is, if the member configuration instruction sent by the member originating node is used to exit the instruction originating node from the blockchain network, it may be determined that the consensus proposal has been received by most nodes if a proof of the consensus proposal is collected during the consensus process and the member configuration instruction sent locally is in the consensus proposal, and thus may exit from the blockchain network, no longer participate in the consensus process, or receive a consensus message.
In view of security issues, the member node may also exit the blockchain network after completing the consensus process for the consensus proposal and after executing the consensus proposal.
Namely an instruction initiating node of any member configuration instruction, when determining that a consensus proposal is executed and the member configuration instruction is included in the consensus proposal, wherein the member configuration instruction is used for indicating that the instruction initiating node is exited from the blockchain network, and then determining that the instruction initiating node is locally exited from the blockchain network.
After S202, if it is determined that the system configuration number in the instruction is the same as the local system configuration number after the local execution is completed for any conventional instruction in the consensus proposal, the any node returns a processing result to the instruction initiating node of the instruction, and as shown in fig. 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 completely executed.
And if the system configuration number in the instruction is smaller than the local system configuration number, returning a processing result and system configuration information to an instruction initiating node of the instruction, and the instruction initiating node receives the processing result sent by the 2/3 member node in the updated system configuration to determine that the instruction is completely executed 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 may also be returned to the instruction initiating node, and the instruction initiating node verifies the system configuration information based on the system configuration history information.
In one embodiment, the master node switching, i.e., view switching, is required to take into account that in the event that a master node goes down or badly, the master node does not initiate a proposal, or initiates an incorrect proposal, which may result in the failure of the nodes to agree.
Therefore, any slave node can broadcast a view switching instruction to the member nodes in the locally maintained member node set under the condition that the view switching condition is detected to be met; the view switching message carries a target system configuration number. Wherein the view switching condition may be that a heartbeat of the master node is not detected for a sufficiently long time or that the consensus process is not completed within a specified time. This is not limited in the present specification, and the PBFT consensus method can be referred to for relevant content.
After receiving the view switching message broadcast by other nodes, any slave node forwards the view switching message according to the configuration number of the target system;
the method specifically comprises the following steps: after any slave node receives the view switching message broadcasted by other nodes, if the target system configuration number in the view switching message is determined to be smaller than the local system configuration number and the member nodes corresponding to the local system configuration number are more 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 comprises a node in the set of member nodes of the local system configuration but not in the set of member nodes of the target system configuration;
as shown in FIG. 6, for example, the target system configuration is numbered M C’ The local system configuration number is Mc, and thisAnd the member nodes corresponding to the configuration numbers of the ground system are A, B, C, D, E, F and G. And the member nodes corresponding to the configuration numbers of the target system are A, B, C and D, and then the view switching message is forwarded to E, F and G, so that the E, F and G which do not receive the view switching message can also receive the view switching message to enter a view switching state.
If the target system configuration number in the view switching message is determined to be greater than the local system configuration number, updating the local system configuration to the system configuration corresponding to the target system configuration number, and forwarding the view switching message to a second node under the condition that the view switching message is sent in the local round, wherein the second node is a node which is included in the member node set of the target system configuration but not in the member node set of the local system configuration;
and under the condition that the view switching message is not sent locally, forwarding the view switching message to a node corresponding to the target system configuration number.
As shown in FIG. 7, for example, the target system configuration is numbered M C’ Local system configuration number M C And the member nodes corresponding to the configuration numbers of the target system are A, B, C, D, E, F and G. And if the view switching message aiming at the current main node is sent, the view switching message is sent to E, F and G, so that the E, F and G can also receive the view switching message.
And under the condition of receiving a view switching message sent by 2/3 of nodes in the member node set in the locally maintained system configuration, the main node broadcasts a new view message to all the member nodes in the locally maintained system configuration so as to enable the nodes in the member node set of the system configuration to enter a new view. It should be understood that the primary node here refers to the screened new primary node rather than the original primary node, and for example, the nodes may be sorted, the primary nodes are switched in sequence, and if node 1 in the previous view is the primary node, node 2 is currently the new primary node.
That is, the master node broadcasts a new view message to the member nodes after receiving more than enough view switching messages broadcast by the member nodes. Of course, in order to determine the validity of the new view message, each slave node needs to verify the new view message, and the specific verification process may refer to the PBFT consensus method, which is not described in detail herein.
In one embodiment, the view switching condition may further include: after consensus is reached for a consensus proposal, and a member configuration instruction is included in the consensus proposal. Namely, every time each consensus node updates the local system configuration information, view switching is performed. When the method is adopted, the reselected main node returns a new view message to each node in the new view, wherein the new view message carries new system configuration information, and each node can update local system configuration information according to the system configuration information sent by the main node, so that in the consensus process, after each member node determines to achieve consensus on the consensus proposal, the main node can not return a system configuration history message to the newly-added node updated at this time, but sends the history message to the node in the new view after view switching is performed, and meanwhile, as the view switching is performed when the number of the members is increased or decreased, a temporary member group does not need to be set, namely the consensus message does not need to be sent to the temporary members, the consensus process of member configuration instructions is further simplified, and the consensus efficiency is improved.
In one embodiment, in the consensus process, if it is determined that the view switching condition is met, any slave node acquires system configuration information. The manner of acquiring the system configuration message from the node may refer to the content described above, that is, the system configuration message may be acquired from the information storage node, which is not limited in this specification.
And further comparing the system configuration number in the acquired system configuration information with the locally maintained system configuration number, and if the acquired system configuration number is the same as the locally maintained system configuration number, executing a view switching process, namely broadcasting a view switching instruction to the member nodes in the locally maintained member node set. If the acquired system configuration number is greater than the locally maintained system configuration number, further broadcasting a historical data acquisition message < UPDATE, s, c, i > 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 c of the node.
After any member node in the member node set receives the historical data acquisition message, if the system configuration number carried in the historical data acquisition message is determined to be smaller than the local system configuration number and the node sending the historical data acquisition message is a node in the locally maintained member node set, a response message < RESULT, hist > for the historical data acquisition message is returned to the node, wherein the response message carries all consensus suggestions hist executed by the member node, namely RESULT in the message is a message type identifier, hist is an execution history of the member node, namely all consensus suggestions executed by the member node.
When the slave node receives the response messages returned by 1/3 member nodes in the member node set and the information carried in the response messages is the same, the slave node updates the local data according to the response messages, and the consensus proposal in the response messages can be executed.
In this embodiment, if it is determined that the view switching condition is satisfied, first, it is determined whether the current node is a cause of the network failure of the current node and is not a problem of another node, and therefore, the current node needs to acquire system configuration information. If the acquired system configuration number is higher than the local system configuration number, it indicates that the local data of the node falls behind other nodes in the system, historical data is acquired from other nodes in the system to update the local data, and the local data can continue to participate in the consensus process after the update.
In the current general consensus methods, under the condition that the member nodes dynamically change, it cannot be guaranteed that each node can successfully achieve consensus on the consensus proposal in the consensus stage (because the member nodes in the current network maintained by each node cannot achieve agreement, the consensus messages meeting the quantity requirements cannot be received), and similarly, it cannot be guaranteed that the view switching can be successfully completed in the view switching stage, that is, the activities of the consensus stage and the view switching stage cannot be guaranteed.
In this specification, system configuration information and system configuration history information are introduced, so that each node can acquire the latest member node information in the current block chain network, and it can be ensured that all correct nodes in the system configuration have a consistent state in the consensus process, and therefore, the activity of the view switching stage and the consensus stage can be ensured when the member nodes dynamically change.
If a correct node submits instruction m, the correct node can verify the current system configuration according to the effective system configuration history, thereby judging whether enough consensus nodes receive m and whether the consensus on m is achieved.
The combination of the two ensures that the correct node can obtain the correct reply with respect to m. Therefore, the protocol can realize consistent reception (consistency delivery), and ensure the safety and activity of the view switching stage and the consensus stage when the member nodes dynamically change. Where consistent receipt (consistency delivery) means that if a correct node submits an instruction m, then this node must receive a reply about m that is consistent with the reply generated in the system configuration in which m was processed. For example, a node sends an instruction m in the blockchain network with the system configuration number c, and the reply returned by the node with the system configuration number c' is identical to the reply returned by the node with the system configuration number c.
For a clearer understanding of the present solution, the following describes the consensus method proposed in the present specification from a single-side perspective, and for the instruction initiating node, the main tasks performed by the instruction initiating node are as follows:
acquiring system configuration information;
updating local system configuration information according to the acquired system configuration information, and broadcasting an instruction to at least part of member nodes in the blockchain network according to the updated system configuration information so that the blockchain network generates a consensus proposal comprising the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the blockchain network.
For a master node in a blockchain network, the main tasks to be performed by the master node include:
after receiving an instruction sent by an instruction initiating node and generating a consensus proposal comprising the instruction, coordinating other nodes to perform consensus processing on the consensus proposal; wherein the instructions comprise member configuration instructions or regular instructions;
after reaching consensus for the consensus proposal, if the consensus proposal comprises member configuration instructions, updating the locally maintained system configuration information according to the member configuration instructions.
For a slave node in a blockchain network, the tasks mainly performed by the slave node include:
after receiving an instruction sent by an instruction initiating node, forwarding the instruction; wherein the instructions comprise member configuration instructions or regular instructions;
performing consensus processing for consensus offers that include the instruction;
after reaching consensus for the consensus proposal, if the consensus proposal comprises member configuration instructions, updating the locally maintained system configuration information according to the member configuration instructions.
In the following, from the perspective of pseudo code implementation, the consensus method proposed in this specification will be described, and the consensus method is named dynamic BFT consensus method Dyno in this specification.
In the following pseudo code, each character represents the following meaning:
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 sequence number, s: sequence number of consensus proposal, P: the locally stored certificates of all packets with sequence numbers higher than the latest instruction in the C, wherein the certificates of the consensus proposal are processed or newly proposed instructions, and the certificates of the consensus proposal for a certain instruction packet are specifically possible in two ways: (1) Message signatures for more than 2/3 nodes < PREPARE, v, c, s, h (batch) > in a certain system configuration; (2) Message signatures δ = h (batch) for more than 1/3 node pairs < COMMIT, v, c, s, δ > in a certain system configuration. PP: member relation instruction set, ts: time stamp, o: instructing the initiating node to propose an operation, re: instruction execution result, V: viewchange message set, O: instruction set, h (batch), hash value of batch (consensus proposal), sometimes abbreviated as δ, Π: all possible consensus nodes in the consensus system (including the consensus nodes which have not been added or have been withdrawn), chist: a system configuration history. Chist is defined as a group of batchs containing the membership instructions arranged in the ascending order of the system configuration. Specifically, chist is a subset of the total consensus batch set, containing only those batches that contain at least one membership instruction. The system configuration for each batch in Chist is incremented and the interval is 1. Each replica (consensus node) stores a corresponding certificate for each batch in the chip and is included in the chip. The validity of a Chist can be verified by any known copy of the initial state of the system or by the client.
Deliver (< TYPE >) that a membership instruction is delivered. In the BFT protocol, this event represents a copy that has completed a round of consensus, local commit, the instruction.
FailToDeliever (< TYPE >): delivery of a certain membership instruction fails. In the BFT protocol, this event represents a view switch in the consensus system before the instruction is delivered.
For the instruction initiating node, the pseudo code when it acquires the system configuration information is as follows:
one way of obtaining is as follows:
1 Initialization
2 c {current configuration}
3 Mc {membership}
4 Chist {configuration history}
5 as a client/new replica
6 func ObtainConfig()
7 broadcast <DISCOVER, c> to Π
8 start a timer ∆
9 upon <CONF, c’, Mc’, chist’>
10 if chist’ is valid and c’ > c
11 chist ← chist’
12 c ← c’
13 Mc ← Mc’
14 upon timeout(∆)
15 return c, Mc
16 as a replica
17 upon <DISCOVER, c’>
reply with <CONF, c, Mc, chist>
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, c being the latest system configuration known to Pi. Then pi sets a timer, and continues to wait for the timer time.
If pi receives a < CONF, c ', mc ', chist ' > message, where chist ' is a valid system configuration history, and c ' > c, pi updates its local configuration history chist, system configuration c, and configuration member set Mc.
And when the timer is ended, returning the current system configuration c and the configuration member set Mc.
And the consensus node pi receives the message of < DISCOVER, c' > and returns the message of < CONF, c, mc, chist > to the message sender.
Another way to obtain system configuration information is as follows:
1 Initialization
2 c {current configuration}
3 Mc {membership}
4 Chist {configuration history}
5 as a client/new replica
6 func ObtainConfig()
7 return nil, Π
in the above pseudo code, the occurrence conditions and specific operations are as follows:
node pi runs the ObtainConfig () function, which returns nil, Π. Wherein nil is empty, and Π is all nodes in the network environment.
Yet another way to obtain system configuration information is as follows:
1 Initialization
2 c {current configuration}
3 Mc {membership}
4 Chist {configuration history}
5 as a client/new replica
6 func ObtainConfig()
7 send <QUERY, cid> to cMaster
8 start a timer ∆
9 upon <CONF, c’, Mc’, chist’>
10 if chist’ is valid and c’ > c
11 chist ← chist’
12 c ← c’
13 Mc ← Mc’
14 return c, Mc
15 upon timeout(∆)
16 return ObtainConfig()
17 as a configuration master
18 upon <QUERY, j>
19 send <CONF, c, Mc, chist> to cid
20 upon M = 2fc + 1< COMMIT, v, c, s, h(batch)>
21 chist ← chist ∪ M
update c and Mc
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 for the timer time.
b) If pi receives a < CONF, c ', mc ', chist ' > message, where chist ' is a valid system configuration history, and c ' > c, pi updates its local configuration history chist, system configuration c, and configuration member set Mc, and the function returns c, mc.
c) Pi times out, the ObtainConfig () function is run again.
2) When the cMaster receives the < QUERY, j > message, the cMaster returns a < CONF, c, mc, chip > message to the message sender.
3) The cMaster receives 2/3 < COMMIT, v, c, s, h (batch) > messages, and let test ← test £ M, update the system configurations c and Mc according to the membership instructions (if any) contained in batch.
For the instruction initiating node, the pseudo code of the processing mode after the instruction initiating node sends the instruction and receives the member node return message is as follows:
1 Initialization
2 c {current configuration}
3 func submit()
4 to join {new replica}
5 c,Mc←ObtainConfig（）
6 broadcast <SUBMIT, c, <JOIN, pk>> to Mc
7 start timer ∆
8 upon receiving <CONF,c’, Mc’ , chist’> {configuration notification}
9 if chist’ is valid and c’ > c
10 c ← c’
11 Mc ← Mc’
12 upon receiving 2fc + 1 <HISTORY, s, h, C, P>
13 stop ∆, complete the request
14 to leave {existing replica}
15 broadcast <SUBMIT, c, <LEAVE, i>> to Mc
16 start timer ∆
17 upon deliver(batch) where <REMOVE, j, m> ∈ batch
18 stop ∆, complete the request
19 to submit a regular request {client}
20 c, Mc ← ObtainConfig()
21 broadcast <SUBMIT, c, <REQUEST, cid, o, ts>> to Mc
22 start timer ∆
23 upon fc + 1 matching <REPLY, c, re> from Mc
24 stop ∆, complete the request
25 upon fc’ + 1 matching <REPLY, c’, re, chist’> from pj ∈ Mc’
26 stop ∆, complete the request
27 upon timeout(∆)
repeat submit()
after the instruction initiating node initiates an instruction, the subsequent processes are divided into the following 3 types according to the difference of the instructions sent by the instruction initiating node:
1) Adding an instruction: the instruction initiating node pi obtains the current up-to-date system configuration via the ObtainConfig () function (ObtainConfig () is black box implemented, the specific function is not certain here, it can simply be set to output (0, Π)), broadcasts the < SUBMIT, c, < JOIN, pk > instructions of its signature to all nodes in the system configuration and sets a timer. pi continues to wait for the timer time, there are three cases:
a) pi receives < CONF, c ', mc ', chist ' >, c < c ' and chist ' is valid, then pi updates its system configuration. The CONF identifies the type of the instruction, c ' is a system configuration number of a sender of the instruction, mc ' is a system configuration member node set of the sender of the instruction, and past ' is system configuration history information of the sender of the instruction.
b) And the instruction initiating node receives the message of < HISTORY, s, h, C, P > which exceeds 2/3 of the common identification nodes in the current configuration, and the state transmission is completed. The client joins the current system configuration to become a consensus node. The timer is ended.
Wherein, the < store, s, h, C, P > message is the member configuration processing result. HISTORY, which identifies the type of the instruction, s is used for identifying the consensus proposal, h is the hash value of the consensus proposal, C is the latest local check point, P is the certificate of all proposals with sequence numbers higher than the latest consensus proposal in C, wherein the certificate is the certification of the consensus proposal.
c) And when the time is out, the process is initialized and operated.
2) A leave instruction: instructing initiating node pi to broadcast signed < SUBMIT, c, < LEAVE, i > > instructions to all nodes in the current system configuration and setting a timer, and continuously waiting for the timer, there are two cases:
a) The instruction initiating node Pi collects the certificate of some instruction set consensus proposal batch, and < REMOVE, i, m > is equal to batch, then Pi leaves the consensus system, and the timer ends.
b) And when the time is out, the process is initialized and operated.
3) The conventional instructions are as follows: the instruction initiating node pi obtains the current latest system configuration through the ObtainConfig () function (ObtainConfig () is implemented by a black box, the specific function is uncertain. Here, it can be simply set to output (0, Π); instruction m = < SUBMIT, c, < REQUEST, cid, o, ts > >, cid is the user id, o is the operation, ts is the timestamp, which broadcasts its signature to all nodes in the system configuration, and sets a timer.
a) And pi receives < REPLY, c, re > returned by 1/3 node in the local system configuration, and then determines that the instruction execution is finished. Where REPLY identifies the message type and re is the execution result.
b) And pi receives < REPLY, c ', re, chist' >, returned by the 1/3 node in the local system configuration, and determines that the instruction execution is finished. Wherein, the test' is system configuration history information sent by an instruction initiator.
For a member node in a blockchain network, the pseudo code executed by the member node is as follows:
the user instruction processing process comprises the following steps:
Initialization
C {configuration number}
M {members in the current configuration}
TM {temporary members in the consensus oracle}
chist {confiugration history}
1 events
2 upon receiving m = <SUBMIT, c’, <REQUEST, cid, o, ts>>
3 if m has been delivered
4 send <REPLY, c, re, chist> to client cid
5 else
6 if c = c’, forward m to leader
7 else if c > c’, forward m to Mc
8 add m to queue
9 as a leader
10 upon non-empty queue
11 batch ← regular requsts in queue
12 for each m = <SUBMIT, c’, <JOIN, pk>> in the queue
13 j ← AssignID()
14 batch ← batch ∪ <ADD, j, m>
15 TM ← TM ∪ {pj}
16 for each m = <SUBMIT, c’, <LEAVE, j>> in the queue
17 batch ← batch ∪ <REMOVE, j, m>
18 broadcast <PRE-PREPARE, v, c, s, batch> to TM
in the pseudo code, after receiving a SUBMIT message m = < SUBMIT, c', < REQUEST, cid, o, ts > > containing a user cid instruction, any node pi in the block chain starts to execute the following operations. There are three cases at this time:
1) m has been delivered by pi i.e. processed: then pi sends a < REPLY, c, re, cost > message containing the current status to the user cid, re being the latest execution result.
2) m is not delivered by pi, c = c'; pi sends m to the current master node leader and stores m in the instruction queue, i.e. 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 instruction queue.
If pi is leader, pi needs to additionally pack the user command in the queue into batch, and broadcasts a PREPARE message < PRE-PREPARE, v, c, s, batch > to all members in the temporary membership group TM, v being the current view number.
a) For any regular instruction in the queue, the common identification proposal batch is directly stored.
b) For an adding instruction m = < SUBMIT, c', < JOIN, pk > > in any queue, a member serial number j is distributed to a node of pk for which the public key is used, a member adding instruction < ADD, j, m > is generated and stored in the batch, and a client j is stored in the TM.
c) For add instruction m = < SUBMIT, c', < LEAVE, j > > in any queue, node REMOVE instruction < REMOVE, j, m > is generated and stored in the batch.
A consensus process:
Initialization
v {view number}
c {current configuration}
M {membership}
TM {temporary membership}
1 events
2 upon receiving a valid m =<PRE-PREPARE, v’, c’, s, batch>
3 if <ADD, j, m> ∈ batch
4 TM ← TM ∪ {pj}
5 if c > c’
6 send <CONF, c, Mc, chist> to pj
7 broadcast <PREPARE, v, c, s, h(batch)> to TM
8 upon receiving 2fc + 1 matching <PREPARE, v, c, s, δ>
9 store the certificate
10 broadcast <COMMIT, v, c, s, δ> to TM
11 upon receiving fc + 1 matching <COMMIT, v, c, s, δ>
12 store the certificate
13 broadcast <COMMIT, v, c, s, δ> to TM
14 upon receiving 2fc + 1 matching <COMMIT, v, c, s, δ>
15 deliver(batch) where h(batch) = δ
in the above pseudo-code, node pi in the blockchain receives a valid PRE-PREPARE message m = < PRE-PREPARE, v, c, s, batch >. Then the consensus process is run, pi then follows:
1) For an < ADD, j, m '> instruction in any batch, pi stores pj into TM, and if c > c', sends a < CONF, c, mc, chist > message to pj.
2) Broadcast < PREPARE, v, c, s, h (batch) > message to TM and continue waiting. There are three cases:
a) pi receives < PREPARE, v, c, s, h (batch) > messages of more than 2/3 consensus nodes in the current configuration, stores the message signatures as the certificates of m, and broadcasts < commit, v, c, s, delta > to TM, wherein delta is the hash value of the consensus proposal.
b) pi receives the messages of < COMMIT, v, c, s, delta > of more than 1/3 of the common identification nodes in the current configuration, stores the message signatures as the certificates of the batch, and broadcasts the < COMMIT, v, c, s, delta > to the TM
c) pi receives the message of < COMMIT, v, c, s, delta > of more than 2/3 consensus nodes in the current configuration, runs the deliverer (batch).
In an embodiment, if it is determined that the time is out, any slave node in the above consensus process performs the consensus method named Dyno-a in this specification, and performs pseudo code as follows:
1 upon timeout
2 c, Mc ← ObtainConfig()
3 if c’ = c
4 view-change()
5 else
6 broadcast <UPDATE, s, c, i> to Mc
7 start timer ∆
8 upon fc’ + 1 matching <RESULT, hist>
9 deliver requests in hist
10 upon <UPDATE, s, c’, j>
11 if pj ∈ Mc’ and c > c’
12 send <RESULT, hist> to pj {execution history greater than s}
in the pseudo code, if node pi in the blockchain times out, an ObtainConfig () function is first run to obtain the current latest system configuration c ', mc'. (ObtainConfig () is black box implemented, the specific function is not certain.
a) c' = c, when pi runs viewchange ()
b) Otherwise, pi sends Mc' < UPDATE, s, c, i > message and waits, if 1/3 of the same < RESULT, hist > is received in the timer time, the timer is ended, and the deliverer function is operated to all the instructions in the hist.
And if the pi is overtime, the protocol in the overtime is operated again.
If the member node receives the message of < UPDATE, s, c ', j >, if pj belongs to Mc ' and c > c ', pi sends a message of < RESULT, hist > to pj.
And the instruction execution process comprises the following steps:
1 func deliver(batch)
2 for m = <SUBMIT, c’, <REQUEST, cid, o, ts>> in batch
3 if c > c’, send <REPLY, c, re, chist> to cid
4 else, send <REPLY, c, re> to cid
5 if there are membership requests
6 c ← c + 1
7 for <ADD, j, m> in batch
8 M ← M ∪ pj
9 for <REMOVE, j, m> in batch
10 M ← M – pj
11 send <HISTORY, s, h, C, P> to Mc/Mc−1
chist ← chist ∪ batch
in the above process, the copy pi runs the instruction execution protocol, starting with its run deliverer (batch). pi is then operated as follows:
1) For instruction m, m ' = m = < SUBMIT, c ', < REQUEST, cid, o, ts > >, if c > c ', send a < REPLY, c, re, chip > message to cid, otherwise send a < REPLY, c, re > message to cid.
2) If the batch has the member relation instruction, updating pi local system configuration c to be c +1, and performing the following operations:
a) For ADD instruction m = < ADD, j, m > in any queue, let Mc = Mc + pj
b) For leave instruction m = < REMOVE, j, m > in any queue, let Mc = Mc-pj
c) Updating the chist to be the chist U notch
d) Sending < HISTORY, s, h, C, P > messages to all nodes in Mc-Mc-1, where C is the latest fixed checkpoint; p is stored for pi and has a sequence number higher than the certificate of the latest packet in C, i.e., all packets of the consensus proposal. Here, the History message is sent requiring that the copy pi send a commit for all instruction blocks with sequence numbers below the batch.
The view switching process is as follows:
Initialization
v {view number}
c {configuration number}
1 as a replica
2 func view-change()
3 v ← v + 1
4 broadcast m’ = <VIEW-CHANGE, v, c, C, P, PP, i>
5 upon receiving m = <VIEW-CHANGE, v, c’, C, P, PP, j>
6 if c’ < c
7 send m to Mc/Mc’
8 if c’ > c and Verify(PP, P)
9 Mc ← Mc’
10 send <VIEW-CHANGE, v, c, C, P, PP, i> to Mc’/Mc
11 as the new leader
12 upon receiving Qc <VIEW-CHANGE, v, c’,C,P,j>
broadcast <NEW-VIEW,v,c,V,O>
there are three situations in the node pi operation view switching process in the blockchain network:
1) pi triggers a view switch instruction when a timeout occurs (i.e. it does not deliver a new message for a sufficiently long time) or when a valid view switch message sent by at least 1/3 of the nodes is received.
At this point, pi updates its VIEW v = v +1 and broadcasts m = m' = < VIEW-CHANGE, v, C, P, PP, i > to Mc, where PP is the set of membership instructions.
2) Pi receives m' = < VIEW-CHANGE, v, C, P, PP, j > message:
if c '< c, pi forwards this message to all copies in Mc-Mc'.
If c' > c, pi updates its system configuration c and M, followed by two cases: and if pi sends the view switching message in the current round, additionally sending the view switching message to all nodes in Mc-Mc', or if pi does not send the view switching message, sending the view switching message to all nodes in Mc.
3) Pi receives more than 2/3 < VIEW-CHANGE, V, C', C, P, j > messages in the current system configuration, and Pi is the leader in the latest system configuration of these messages, then Pi will send < NEW-VIEW, V, C, V, O > messages to all copies of Mc and enter the NEW VIEW.
It is understood that the above consensus method can be applied not only to the blockchain network, but also to other application scenarios, such as a system with a fixed number of server nodes for system recovery and reconfiguration, and when some servers in the system are dead, faulty or under attack, or the system needs maintenance, it can be implemented by creating a new node or removing an old node.
The above method can also be used when active recovery is needed, for example, when a plurality of nodes in the system cannot be removed due to the influence of viruses, a new node can be introduced in the above method, because the new node is a new operating system and environment and is not infected by viruses, and some old nodes can be removed in the above method.
In the alliance chain network, when each alliance member needs to be dynamically changed, such as company A quits, company B joins can also adopt the above consensus method, and also can adopt the above consensus method in a mixed chain.
Corresponding to the above consensus method based on the blockchain network, the present specification further provides a consensus system based on the blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a member node set of the blockchain network and a system configuration number for identifying system configuration; the system comprises:
the instruction initiating node is used for acquiring system configuration information;
the instruction initiating node is further configured to update local system configuration information according to the acquired system configuration information, and broadcast an instruction to at least part of member nodes in the blockchain network according to the updated system configuration information, so that the blockchain network generates a consensus proposal including the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the block chain network;
block chain networkAny member node, configured to determine that a consensus is achieved for the consensus proposal, if the consensus proposal includes a member configuration instruction，Updating the locally maintained system configuration information according to the member configuration instruction.
In one embodiment, an instruction initiating node for sending a system configuration acquisition request to an information storage node;
and the information storage node is used for returning the system configuration information to the instruction initiating node.
In one embodiment, the information storage node comprises a member node in a blockchain network;
the instruction initiating node is specifically configured to broadcast a system configuration acquisition request to a node set including at least one member node of the blockchain network.
In one embodiment, the information storage node comprises a designated node in or outside a blockchain network; the instruction initiating node is specifically configured to send a system configuration information obtaining request to the designated node.
In an embodiment, the information storage node is configured to return an acquisition request response message to the instruction initiating node, where the response message carries system configuration information and system configuration history information.
In this embodiment, the instruction initiating node is configured to verify the acquired system configuration information according to the system configuration history information, and update the local system configuration according to the acquired system configuration information when the verification is passed and the system configuration number in the acquired system configuration information is greater than the locally maintained system configuration number.
In one embodiment, the instruction initiating node takes a set formed by all nodes in the predefined network as a member node set in the system configuration information and takes a predefined value as a system configuration number.
In one embodiment, any slave node in the blockchain network is configured to forward the instruction after receiving the instruction;
and the main node in the block chain network is used for coordinating other nodes to perform consensus processing on the consensus proposal after receiving the instruction and generating the consensus proposal comprising the instruction.
In one embodiment, the instruction carries a system configuration number, which is used to identify the system configuration to which the instruction is directed; any slave node in the block chain network is used for forwarding the member configuration instruction to the master node if the system configuration number is determined to be the same as the locally stored system configuration number under the condition that the instruction is not executed locally; if the system configuration number is determined to be smaller than a locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set; and returning an execution result and system configuration history information to the instruction initiating node under the condition that the instruction is executed locally.
In one embodiment, the master node is further configured to store the instruction in a local instruction pool after receiving the instruction; acquiring a preset number of instructions from a local instruction pool; configuring an instruction for any member in the preset number of instructions, if the member configuration instruction is used for indicating that an instruction initiating node initiating the instruction is added into a block chain network, allocating a member node serial number to the instruction initiating node, and combining the member node serial number and the member configuration instruction into a member adding instruction; if the member configuration instruction is used for indicating that an instruction initiating node initiating the instruction exits from the blockchain network, combining a member node serial number of the instruction initiating node and the member configuration instruction into a member exiting instruction; and packing the member adding instruction, the member quitting instruction and the conventional instruction into a consensus proposal aiming at the preset number of instructions.
In one embodiment, the master node is further configured to add the instruction initiating node to the temporary member set after assigning the member serial number to the instruction initiating node; the temporary member set comprises all member nodes in the local system configuration; broadcasting a pre-preparation message to nodes in a temporary member set based on the consensus proposal;
any slave node is used for adding a member node serial number in a member adding instruction into a local temporary member set aiming at the member adding instruction in the consensus proposal after receiving a valid pre-preparation message, and broadcasting a preparation message aiming at the consensus proposal to the nodes in the local temporary member set; the preparation message carries the signature of the slave node;
any member node, configured to, after receiving a prepare message for the consensus proposal broadcast by 2/3 member nodes in the member node set configured by the local system, store a signature of the received prepare message as a proof of the consensus proposal and broadcast a commit message for the consensus proposal, or, after receiving a commit message for the consensus proposal broadcast by 1/3 member nodes in the member node set configured by the local system, store a signature of the received commit message as a proof of the consensus proposal and broadcast a commit message for the consensus proposal; wherein the commitment message carries a signature of the node; after receiving a promise message for the consensus proposal broadcasted by 2/3 member nodes in the member node set configured by the local system, determining to achieve consensus for the consensus proposal, and executing the consensus proposal.
In one embodiment, any slave node is further configured to, after the member node serial number in the member join instruction is joined to the temporary member group, send the local system configuration information and the system configuration history information to the instruction initiating node corresponding to the member node serial number when the system configuration number carried in the member join instruction is smaller than the local system configuration number;
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 update the local system configuration information according to the received system configuration history information after the verification is passed; the system configuration history information is a set of target consensus suggestions, wherein the target consensus suggestions are consensus suggestions comprising a member joining instruction or a member quitting instruction.
In one embodiment, the system configuration history information includes a certification of each target consensus proposal;
the instruction initiating node is specifically configured to verify the target offer based on the proof in the system configuration history information, and determine that the system configuration history information and the system configuration information pass verification when all target offers pass verification.
In one embodiment, any node in the blockchain network is configured to add, to any member joining instruction in the consensus proposal, a member node sequence number in the member joining instruction to a member node set in locally maintained system configuration information after reaching consensus for the consensus proposal; removing the member node sequence number in the member exit instruction from a member node set in locally maintained system configuration information aiming at any member exit instruction in the consensus proposal; and updating the system configuration number.
In one embodiment, any node in the blockchain network is further configured to add the consensus proposal to system configuration history information; returning a member configuration processing result to an initiating node corresponding to the member configuration instruction included in the consensus proposal; the member configuration instruction is used for indicating an instruction initiating node of the instruction to be added into a blockchain network;
and the instruction initiating node of any member configuration instruction is further used for determining that the instruction is executed completely and determining that the local node is added into the block chain network after receiving the configuration processing result sent by the 2/3 member node.
In one embodiment, the instruction initiating node of any member configuration instruction is further configured to determine to locally exit from the blockchain network if the member configuration instruction is included in the consensus proposal after storing the proof of the consensus proposal in the consensus process, wherein the member configuration instruction is used for instructing to exit the instruction initiating node from the blockchain network.
In one embodiment, the instruction initiating node of any member configuration instruction is further configured to determine that the instruction initiating node is locally exited from the blockchain network if a consensus proposal is determined to be executed and the member configuration instruction is included in the consensus proposal.
In an embodiment, any node in the blockchain network is further configured to, for any conventional instruction in the consensus offer, after local execution is completed, if it is determined that a system configuration number in the instruction is the same as a local system configuration number, return a processing result to an instruction initiating node of the instruction; and if the system configuration number in the instruction is determined to be smaller than the local system configuration number, returning a processing result and system configuration history information to the instruction initiating node of the instruction.
In one embodiment, any slave node is further configured to, in a case that it is detected that the view switching condition is satisfied, acquire system configuration information; if the acquired system configuration number is the same as the locally maintained system configuration number, broadcasting a view switching instruction to member nodes in a locally maintained member node set; if the acquired system configuration number is larger than the locally maintained system configuration number, broadcasting a historical data acquisition message to member nodes in a member node set corresponding to the acquired system configuration number; wherein, the historical data acquisition message carries a system configuration number of local maintenance;
any member node in the member node set is further configured to, after receiving the historical data acquisition message, if it is determined that the system configuration number carried in the historical data acquisition message is smaller than the local system configuration number and the node sending the historical data acquisition message is a node in the member node set maintained locally, return a response message for the historical data acquisition message to the node; wherein, the response message carries all consensus proposals executed by the member node;
and the slave node is also used for updating the local data according to the response message when receiving the response message returned by 1/3 member nodes in the member node set 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 a member node in the locally maintained set of member nodes if it is detected that the view switching condition is satisfied; the view switching message carries a target system configuration number; after receiving the view switching message broadcast by other nodes, forwarding the view switching message according to the configuration number of the target system;
and the master node is further used for broadcasting a new view message to all the member nodes of the locally maintained system configuration under the condition of receiving a view switching message sent by 2/3 of the nodes in the member node set of the locally maintained system configuration, so that the nodes in the member node set of the system configuration enter a new view.
In an embodiment, any slave node is further configured to, after receiving a view switching message broadcast by another node, forward the view switching message to the first node if it is determined that a target system configuration number in the view switching message is smaller than a local system configuration number and a member node corresponding to the local system configuration number is more than a member node corresponding to the target system configuration number; wherein the first node comprises a node in the set of member nodes of the local system configuration but not in the set of member nodes of the target system configuration; if the target system configuration number in the view switching message is determined to be greater than the local system configuration number, updating the local system configuration to the system configuration corresponding to the target system configuration number, and forwarding the view switching message to a second node under the condition that the view switching message is sent in the local round, wherein the second node is a node which is included in the member node set of the target system configuration but not in the member node set of the local system configuration; and under the condition that the view switching message is not sent in the local round, forwarding the view switching message to all nodes corresponding to the configuration number of the target system.
In one embodiment, the view switch condition comprises upon reaching consensus for a consensus proposal, and the consensus proposal comprises member configuration instructions.
As shown in fig. 8, corresponding to the aforementioned consensus method based on the blockchain network, the present specification further provides a consensus device based on the blockchain network, which is applied to an instruction initiating node, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a set of member nodes of the blockchain network and a system configuration number for identifying system configuration; the device comprises:
an obtaining module 810, configured to obtain system configuration information;
a broadcasting module 820, which updates the local system configuration information according to the acquired system configuration information, and broadcasts an instruction to at least part of member nodes in the blockchain network according to the updated system configuration information, so that the blockchain network generates a consensus proposal including the instruction and performs consensus processing on the consensus proposal; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or withdrawn from the blockchain network.
As shown in fig. 9, corresponding to the aforementioned consensus method based on the blockchain network, the present specification further provides a consensus device based on the blockchain network, which is applied to a slave node in the blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a set of member nodes of the blockchain network and a system configuration number for identifying a system configuration; the device comprises:
a forwarding module 910, configured to forward, after receiving an instruction sent by an instruction initiating node, the instruction; wherein the instructions comprise member configuration instructions or regular instructions;
a consensus module 920 for performing consensus processing for a consensus proposal including the instruction;
an updating module 930, configured to update the locally maintained system configuration information according to the member configuration instruction if the consensus suggestion includes the member configuration instruction after consensus is achieved for the consensus suggestion.
As shown in fig. 10, corresponding to the aforementioned consensus method based on the blockchain network, the present specification further provides a consensus device based on the blockchain network, which is applied to a master node in the blockchain network, where any consensus node in the blockchain network locally maintains system configuration information, where the system configuration information includes a set of member nodes of the blockchain network and a system configuration number for identifying a system configuration; the device comprises:
a consensus module 1110, configured to coordinate other nodes to perform consensus processing on a consensus proposal after receiving an instruction sent by an instruction initiating node and generating the consensus proposal including the instruction; wherein the instructions comprise member configuration instructions or regular instructions;
an updating module 1120, configured to update the locally maintained system configuration information according to the member configuration instruction if the consensus suggestion includes the member configuration instruction after consensus is achieved for the consensus suggestion.
The implementation processes of the functions and actions of the components in the device are specifically described in the implementation processes of the corresponding steps in the method, and are not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described apparatus embodiments are merely illustrative. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
Embodiments of the present specification also provide a computer device, which at least includes a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the aforementioned method when executing the program. The method at least comprises the method executed by the instruction initiating node, the slave node in the blockchain network or the master node in the blockchain network.
Fig. 11 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (CeNtral ProcessiNg UNit), a microprocessor, an ApplicatioN Specific INtegrated Circuit (ASIC), or one or more INtegrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present specification.
The Memory 1020 may be implemented in a ROM (Read ONly Memory), a RAM (RaNdom Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and the output devices may include a display, speaker, vibrator, indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, bluetooth and the like).
The bus 1050 includes a path to transfer information between various components of the device, such as the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, which when executed by a processor implements the foregoing method. The method at least comprises the method executed by the instruction initiating node, the slave node in the block chain network or the master node in the block chain network.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a traNsitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present disclosure. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.

Claims (19)

1. A consensus method based on a blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the method comprises the following steps:
the instruction initiating node broadcasts an instruction carrying a system configuration number to at least part of member nodes in the block chain network; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or removed from the blockchain network;
under the condition that any slave node in the block chain network does not execute the instruction locally, if the system configuration number is determined to be the same as the locally stored system configuration number, forwarding the member configuration instruction to the master node; if the system configuration number is determined to be smaller than a locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set; after receiving the instruction and generating a consensus proposal comprising the instruction, a main node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal according to local system configuration information; the consensus proposal comprises a member configuration instruction and/or a conventional instruction;
after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network updates a locally maintained member node set and a system configuration number according to the member configuration instruction if the consensus proposal comprises the member configuration instruction, and adds or removes an instruction initiating node corresponding to the member configuration instruction to the blockchain network, so that the addition or removal of the member node is completed without performing view switching, namely, without interrupting a conventional instruction consensus process.
2. The method of claim 1, further comprising:
after receiving the instruction, the main node stores the instruction in a local instruction pool;
the generating a consensus proposal including the instruction includes:
acquiring a preset number of instructions from a local instruction pool;
configuring an instruction for any member in the preset number of instructions, if the member configuration instruction is used for indicating that an instruction initiating node initiating the instruction is added into a block chain network, allocating a member node serial number to the instruction initiating node, and combining the member node serial number and the member configuration instruction into a member adding instruction; if the member configuration instruction is used for indicating that an instruction initiating node initiating the instruction exits from the blockchain network, combining a member node serial number of the instruction initiating node and the member configuration instruction into a member exiting instruction;
and packaging the member adding instruction, the member quitting instruction and the conventional instruction into a consensus proposal aiming at the preset number of instructions.
3. The method of claim 2, further comprising:
after distributing member serial numbers to the instruction initiating nodes, adding the instruction initiating nodes into a temporary member set; the temporary member set comprises all member nodes in the local system configuration;
the other coordinated nodes perform consensus processing on the consensus proposal according to local system configuration information, and the consensus processing comprises the following steps:
broadcasting a prepare message to nodes in a temporary member set based on the consensus proposal;
any slave node, after receiving the effective pre-preparation message, adding the member node serial number in the member adding instruction into the local temporary member set aiming at the member adding instruction in the consensus proposal, and broadcasting the preparation message aiming at the consensus proposal to the nodes in the local temporary member set; the preparation message carries the signature of the slave node;
any member node, after receiving the preparation message for the consensus proposal broadcasted by 2/3 member nodes in the member node set configured by the local system, storing the signature of the received preparation message as the proof of the consensus proposal and broadcasting the commitment message for the consensus proposal, or after receiving the commitment message for the consensus proposal broadcasted by 1/3 member nodes in the member node set configured by the local system, storing the signature of the received commitment message as the proof of the consensus proposal and broadcasting the commitment message for the consensus proposal; wherein the commitment message carries a signature of the node;
after receiving a promise message for the consensus proposal broadcasted by 2/3 member nodes in the member node set configured by the local system, determining to achieve consensus for the consensus proposal, and executing the consensus proposal.
4. The method of claim 3, further comprising:
any slave node adds the member node serial number in the member adding instruction into the temporary member group, and sends local system configuration information and system configuration history information to an instruction initiating node corresponding to the member node serial number under the condition that the system configuration number carried in the member adding instruction is smaller than the local system configuration number;
after receiving the system configuration information and the system configuration historical information, the instruction initiating node verifies the received system configuration information according to the system configuration historical information, and updates the local system configuration information according to the received system configuration historical information after the verification is passed; the system configuration history information is a set of target consensus suggestions, wherein the target consensus suggestions are consensus suggestions comprising a member joining instruction or a member quitting instruction.
5. The method of claim 4, wherein the system configuration history information includes a certification of each target consensus proposal;
the verifying the received system configuration information according to the system configuration history information comprises:
and verifying the target proposal based on the proof in the system configuration history information, and determining that the system configuration history information and the system configuration information are verified if all target proposals are verified.
6. The method of claim 2, wherein updating the locally maintained member node set and the system configuration number according to the member configuration instruction comprises:
after reaching consensus for the consensus proposal, any node in the block chain network adds the member node serial number in the member adding instruction to the member node set in the locally maintained system configuration information aiming at any member adding instruction in the consensus proposal;
removing the member node sequence number in the member exit instruction from a member node set in locally maintained system configuration information aiming at any member exit instruction in the consensus proposal;
and updating the system configuration number.
7. The method of claim 6, further comprising:
any node in the block chain network adds the consensus proposal into system configuration history information;
returning a member configuration processing result to an initiating node corresponding to the member configuration instruction included in the consensus proposal; the member configuration instruction is used for indicating an instruction initiating node of the instruction to be added into a blockchain network;
after receiving the configuration processing result sent by the 2/3 member node, the instruction initiating node of any member configuration instruction can determine that the instruction is executed completely, and determine that the instruction is locally added into the block chain network.
8. The method of claim 7, further comprising:
and after storing the certification of the consensus proposal in the consensus process, if the member configuration instruction is contained in the consensus proposal, wherein the member configuration instruction is used for indicating that the instruction initiating node is withdrawn from the blockchain network, and determining that the instruction initiating node is locally withdrawn from the blockchain network.
9. The method of claim 7, further comprising:
and the instruction initiating node of any member configuration instruction determines to locally exit from the blockchain network when determining that a consensus proposal is executed and the member configuration instruction is contained in the consensus proposal, wherein the member configuration instruction is used for indicating that the instruction initiating node exits from the blockchain network.
10. The method according to any one of claims 8 or 9, further comprising:
after local execution is completed for any conventional instruction in the consensus proposal, if the system configuration number in the instruction is determined to be the same as the local system configuration number, returning a processing result to the instruction initiating node of the instruction;
and if the system configuration number in the instruction is determined to be smaller than the local system configuration number, returning a processing result and system configuration history information to the instruction initiating node of the instruction.
11. A consensus method based on a blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set of the blockchain network and a system configuration number for identifying the member node set; under the condition that the member node set is updated, the system configuration number is increased by taking 1 as a step length; the method comprises the following steps: broadcasting an instruction carrying a system configuration number to at least part of member nodes in the blockchain network, so that under the condition that any slave node in the blockchain network does not execute the instruction locally, if the system configuration number is determined to be the same as the locally stored system configuration number, the member configuration instruction is forwarded to a master node; if the system configuration number is determined to be smaller than a locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set; after receiving the instruction and generating a consensus proposal comprising the instruction, a main node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal according to local system configuration information; the consensus proposal comprises a member configuration instruction and/or a conventional instruction; after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network updates a locally maintained member node set and a system configuration number according to the member configuration instruction if the consensus proposal comprises the member configuration instruction, and adds or removes an instruction initiating node corresponding to the member configuration instruction to the blockchain network, so that the addition or removal of the member node is completed without performing view switching, namely, without interrupting a conventional instruction consensus process.
12. The consensus method based on the blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the method comprises the following steps:
after receiving an instruction sent by an instruction initiating node, under the condition that the instruction is not executed locally, if the system configuration number is determined to be the same as a locally stored system configuration number, forwarding a member configuration instruction to a main node; if the system configuration number is smaller than the locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set;
performing consensus processing according to local system configuration information for the consensus proposal comprising the instruction; the consensus proposal comprises member configuration instructions and/or conventional instructions;
after the consensus is achieved for the consensus proposal, if the consensus proposal comprises a member configuration instruction, the member node set maintained locally is updated according to the member configuration instruction and the system configuration number, and the instruction initiating node corresponding to the member configuration instruction is added or removed to the block chain network, so that the addition or removal of the member node is completed without executing view switching, namely under the condition of not interrupting the conventional instruction consensus process.
13. A consensus method based on a blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the method comprises the following steps:
after receiving an instruction sent by an instruction initiating node and generating a consensus proposal comprising the instruction, coordinating other nodes to perform consensus processing on the consensus proposal according to local system configuration information; wherein the instructions comprise member configuration instructions or regular instructions; the consensus proposal comprises a member configuration instruction and/or a conventional instruction;
after consensus is achieved for the consensus proposal, if the consensus proposal comprises member configuration instructions, updating a locally maintained member node set and a system configuration number according to the member configuration instructions to add or remove the instruction initiating node corresponding to the member configuration instructions into the block chain network, so as to complete the addition or removal of the member nodes without executing view switching, namely under the condition of not interrupting the conventional instruction consensus process.
14. A consensus system based on a blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the system comprises:
the instruction initiating node is used for broadcasting an instruction carrying a system configuration number to at least part of member nodes in the block chain network; the instruction comprises a member configuration instruction or a conventional instruction, and the member configuration instruction is used for indicating that the instruction initiating node is added to or removed from the blockchain network;
under the condition that the instruction is not executed locally, if the system configuration number is determined to be the same as the locally stored system configuration number, any slave node in the block chain network forwards the member configuration instruction to the master node; if the system configuration number is smaller than the locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set;
the main node in the blockchain network is used for coordinating other nodes to perform consensus processing on the consensus suggestions according to local system configuration information after receiving the instructions and generating the consensus suggestions comprising the instructions; the consensus proposal comprises member configuration instructions and/or conventional instructions;
and any node in the blockchain network is used for updating a locally maintained member node set and a system configuration number according to the member configuration instruction and adding or removing an instruction initiating node corresponding to the member configuration instruction into or from the blockchain network if the consensus proposal comprises the member configuration instruction after the consensus proposal is determined to reach the consensus, so that the addition or removal of the member node is completed without executing view switching, namely without interrupting the conventional instruction consensus process.
15. The consensus device based on the blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition that the member node set is updated, the system configuration number is increased by taking 1 as a step length; the device comprises:
the acquisition module is used for acquiring system configuration information;
the broadcasting module is used for updating the local system configuration information according to the acquired system configuration information and broadcasting an instruction carrying a system configuration number to at least part of member nodes in the blockchain network according to the updated system configuration information so that the member configuration instruction is forwarded to the main node if the system configuration number is determined to be the same as the locally stored system configuration number under the condition that any slave node in the blockchain network does not execute the instruction locally; if the system configuration number is determined to be smaller than a locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set; after receiving the instruction and generating a consensus proposal comprising the instruction, a main node in the blockchain network coordinates other nodes to perform consensus processing on the consensus proposal according to local system configuration information; the consensus proposal comprises a member configuration instruction and/or a conventional instruction; after determining that consensus is achieved for the consensus proposal, any member node in the blockchain network updates a locally maintained member node set and a system configuration number according to the member configuration instruction if the consensus proposal comprises the member configuration instruction, and adds or removes an instruction initiating node corresponding to the member configuration instruction to the blockchain network, so that the addition or removal of the member node is completed without performing view switching, namely, without interrupting a conventional instruction consensus process.
16. The consensus device based on the blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the device comprises:
the forwarding module is used for forwarding the member configuration instruction to the main node if the system configuration number is determined to be the same as a locally stored system configuration number under the condition that the instruction is not locally executed after the instruction sent by the instruction initiating node is received; if the system configuration number is determined to be smaller than the locally stored system configuration number, forwarding the instruction to a member node in a locally maintained member node set; wherein the instructions comprise member configuration instructions or regular instructions;
a consensus module for performing consensus processing according to local system configuration information for a consensus proposal including the instruction; the consensus proposal comprises a member configuration instruction and/or a conventional instruction;
and the updating module is used for updating a locally maintained member node set and a system configuration number according to the member configuration instruction and adding or removing an instruction initiating node corresponding to the member configuration instruction into the block chain network if the consensus proposal comprises the member configuration instruction after the consensus proposal reaches the consensus, so that the addition or removal of the member node is completed without executing view switching, namely without interrupting the conventional instruction consensus process.
17. The consensus device based on the blockchain network is characterized in that any consensus node in the blockchain network locally maintains system configuration information, wherein the system configuration information comprises a member node set and a system configuration number used for identifying the member node set; under the condition of updating the member node set, the system configuration number is increased by taking 1 as a step length; the device comprises:
the consensus module is used for coordinating other nodes to perform consensus processing on the consensus suggestions according to local system configuration information after receiving the instruction sent by the instruction initiating node and generating the consensus suggestions comprising the instruction; wherein the instructions comprise member configuration instructions or regular instructions; the consensus proposal comprises a member configuration instruction and/or a conventional instruction;
and the updating module is used for updating a locally maintained member node set and a system configuration number according to the member configuration instruction and adding or removing an instruction initiating node corresponding to the member configuration instruction into the block chain network if the consensus proposal comprises the member configuration instruction after the consensus proposal reaches the consensus, so that the addition or removal of the member node is completed without executing view switching, namely without interrupting the conventional instruction consensus process.
18. A computer device comprising a memory, a processor, a communication interface and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 11 to 13 when executing the program.
19. A computer-readable storage medium, characterized in that a computer program is stored thereon which, when being executed by a processor, carries out the method of any one of claims 11 to 13.
CN202210046656.1A 2022-01-17 2022-01-17 Consensus method, device and system based on block chain network Active CN114070733B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210046656.1A CN114070733B (en) 2022-01-17 2022-01-17 Consensus method, device and system based on block chain network
PCT/CN2022/111013 WO2023134159A1 (en) 2022-01-17 2022-08-09 Consensus method and apparatus based on blockchain network, electronic device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210046656.1A CN114070733B (en) 2022-01-17 2022-01-17 Consensus method, device and system based on block chain network

Publications (2)

Publication Number Publication Date
CN114070733A CN114070733A (en) 2022-02-18
CN114070733B true CN114070733B (en) 2023-01-31

Family

ID=80231020

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210046656.1A Active CN114070733B (en) 2022-01-17 2022-01-17 Consensus method, device and system based on block chain network

Country Status (2)

Country Link
CN (1) CN114070733B (en)
WO (1) WO2023134159A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114070733B (en) * 2022-01-17 2023-01-31 清华大学 Consensus method, device and system based on block chain network
CN114625802A (en) * 2022-03-15 2022-06-14 北京广元科技有限公司 High-concurrency transaction optimization method and system based on energy source block chain
WO2024011373A1 (en) * 2022-07-11 2024-01-18 Huawei Cloud Computing Technologies Co., Ltd. Membership service for microsecond applications

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110727731A (en) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 Method for adding node in block chain network and block chain system
CN110730204A (en) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 Method for deleting nodes in block chain network and block chain system
CN110768798A (en) * 2019-10-24 2020-02-07 中国人民解放军国防科技大学 Lightweight block chain consensus method, system and medium for Internet of things
CN111865608A (en) * 2020-07-02 2020-10-30 南京邮电大学 Consensus mechanism operation method applied to alliance chain
CN113821569A (en) * 2021-09-30 2021-12-21 广州智链未来科技有限公司 Block chain consensus method and block chain

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113888168A (en) * 2020-07-03 2022-01-04 支付宝(杭州)信息技术有限公司 Consensus method of alliance chain, data verification method, device and system
CN114070733B (en) * 2022-01-17 2023-01-31 清华大学 Consensus method, device and system based on block chain network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110727731A (en) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 Method for adding node in block chain network and block chain system
CN110730204A (en) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 Method for deleting nodes in block chain network and block chain system
CN110768798A (en) * 2019-10-24 2020-02-07 中国人民解放军国防科技大学 Lightweight block chain consensus method, system and medium for Internet of things
CN111865608A (en) * 2020-07-02 2020-10-30 南京邮电大学 Consensus mechanism operation method applied to alliance chain
CN113821569A (en) * 2021-09-30 2021-12-21 广州智链未来科技有限公司 Block chain consensus method and block chain

Also Published As

Publication number Publication date
WO2023134159A1 (en) 2023-07-20
CN114070733A (en) 2022-02-18

Similar Documents

Publication Publication Date Title
CN114070733B (en) Consensus method, device and system based on block chain network
CN107888562B (en) Data verification and transceiving method, node and system for parallel link access to interconnection chain
WO2023016428A1 (en) Byzantine fault tolerance method and apparatus, and electronic device and storage medium
CN102118263A (en) Method and system for distribution of configuration information
US20230037932A1 (en) Data processing method and apparatus based on blockchain network, and computer device
CN113794694B (en) Binary consensus method and device based on reliable broadcast
CN109173270B (en) Game service system and implementation method
CN113810465B (en) Asynchronous binary consensus method and device
WO2023024885A1 (en) Reliable broadcast-based re-votable binary consensus method and apparatus, electronic device, and storage medium
CN111163173A (en) Cluster configuration method and device, server and readable storage medium
CN114760198B (en) Consensus method, device and system based on block chain network
CN113794576B (en) Re-voting binary consensus method and device
CN111401904A (en) Consensus method and system in alliance chain
CN113259326B (en) Consensus optimization method and device based on alliance chain network and computer equipment
CN114374699A (en) Cross-chain interaction method and cross-chain interaction auditing method
CN113157450A (en) Method and apparatus for performing blocks in a blockchain system
CN107306289B (en) Load balancing method and device based on cloud computing
CN111064813A (en) Method and device for synchronizing processing messages during block chain consensus processing
CN109936609B (en) Terminal chain type upgrading method and device and upgrading management server
WO2017000256A1 (en) Positioning method and corresponding apparatus
CN113794566A (en) Re-voting binary consensus method and device
CN111340491B (en) Loose-coupling block chain autonomous transaction method, device and system
CN113783946A (en) Re-voting binary consensus method and device based on threshold signature
CN113765671A (en) Block chain link point hot restart method and device
WO2020037607A1 (en) Data transmission method and apparatus

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant