CN109586949B - Block generation method and computer storage medium - Google Patents
Block generation method and computer storage medium Download PDFInfo
- Publication number
- CN109586949B CN109586949B CN201811206993.2A CN201811206993A CN109586949B CN 109586949 B CN109586949 B CN 109586949B CN 201811206993 A CN201811206993 A CN 201811206993A CN 109586949 B CN109586949 B CN 109586949B
- Authority
- CN
- China
- Prior art keywords
- new block
- block
- new
- state
- checking
- 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
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/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
An embodiment of the present invention provides a block generation method and a computer storage medium, where the block generation method is applied to a federated block chain, where the federated block chain does not have a master node, and the method includes: receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content; verifying the number of the new block, verifying the block content information corresponding to the successfully verified number of the new block, and pre-generating a new block after the verification is successful; checking the number of the new block again, and sending confirmation messages to all nodes in the alliance block chain after the checking is successful; and judging whether all the nodes agree with the confirmation message, if so, generating a new block of the node initiating the new block generation request according to the pre-generated new block.
Description
Technical Field
The embodiment of the invention relates to the technical field of computers, in particular to a block generation method and a computer storage medium.
Background
The blockchain is a novel application mode which utilizes computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The block chains are divided into three categories, which are: a public blockchain, a federation blockchain (also referred to as a federation blockchain, an industry blockchain), and a private blockchain.
In the current block chain of the alliance, in order to quickly and correctly agree on a value of a certain data within the block chain, a consensus mechanism, such as PBFT (physical Byzantine Fault Tolerance) algorithm, is used as the consensus mechanism. In such a consensus mechanism, all nodes in the block chain of the federation need to select a master node, and when a new block needs to be generated, the master node is responsible for generating the new block.
However, in the existing manner of generating new blocks in the block chain of the federation, in some cases, such as when a failure occurs in the master node or when a master node elects, a new block cannot be generated. This further results in no guarantee that data consistency is achieved within the federation blockchain.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a block generation method and a computer storage medium, so as to solve the above problems.
The embodiment of the invention provides a block generation method, which is applied to an alliance block chain, wherein the alliance block chain does not have a main node, and the method comprises the following steps: receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content; verifying the number of the new block, verifying the block content information corresponding to the successfully verified number of the new block, and pre-generating a new block after the verification is successful; checking the number of the new block again, and sending confirmation messages to all nodes in the alliance block chain after the checking is successful; and judging whether all the nodes agree with the confirmation message, if so, generating a new block of the node initiating the new block generation request according to the pre-generated new block.
An embodiment of the present invention further provides a computer-readable medium, where the computer-readable medium stores a readable program, where the readable program is applied to a federated blockchain, where the federated blockchain does not have a master node, and the readable program includes: the instruction is used for receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content; instructions for verifying the number of the new block, verifying information of the block content corresponding to the successfully verified number of the new block, and pre-generating the new block after the successful verification; an instruction for checking the number of the new block again and sending a confirmation message to all nodes in the alliance block chain after the checking is successful; and instructions for determining whether all the nodes agree with the acknowledgment message, and if yes, generating a new block of the node that initiates the new block generation request according to the pre-generated new block.
As can be seen from the above technical solutions, in the block generation scheme provided in the embodiments of the present invention, a master node is no longer used in an alliance block chain, and in order to ensure that a block is normally generated without a master node, the scheme provided in the embodiments of the present invention uses a number verification mechanism, and after receiving a new block generation request, the number of the block to be generated (i.e., the new block) is verified, so as to determine the order of the blocks to be generated according to the number, thereby avoiding block chain branching; furthermore, after a new block is pre-generated, the number of the block to be generated is checked again to ensure that the block is the newest block to be generated in the processing stage. Therefore, under the condition that no main node exists, the block chain of the alliance can also ensure the generation sequence and uniqueness of the new blocks, and the problem that in the process of generating the new blocks by the existing block chain of the alliance, when the main node fails or elects the main node, the new blocks cannot be generated, and further the data consistency inside the block chain of the alliance cannot be ensured is solved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present invention, and it is also possible for a person skilled in the art to obtain other drawings based on the drawings.
Fig. 1 is a flowchart illustrating steps of a block generation method according to a first embodiment of the present invention;
fig. 2 is a flowchart illustrating steps of a block generation method according to a second embodiment of the present invention.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be described clearly and completely with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments of the present invention shall fall within the scope of the protection of the embodiments of the present invention.
The following further describes specific implementation of the embodiments of the present invention with reference to the drawings.
Example one
Referring to fig. 1, a flowchart illustrating steps of a block generation method according to a first embodiment of the present invention is shown.
The block generation method of this embodiment is applied to an alliance block chain, and is different from a conventional alliance block chain in that the alliance block chain in this embodiment does not have a master node, and when a new block is generated, a new block number verification mode is adopted in order to achieve data consistency and maintain the order of the alliance block chain.
Specifically, the block generating method of the present embodiment includes the following steps:
step S102: a new block generation request initiated by a node in the federation block chain is received.
The new block generation request carries the number of the requested new block and the information of the corresponding block content.
Any node in the federation blockchain may issue a new block generation request, as needed, to request generation of a new block. The new block generation request is broadcasted to the whole network, that is, the new block generation request is sent to all nodes in the federation block chain, including the self node.
In this embodiment, a block generation method is described from the perspective of one node in a federation block chain, but it should be understood by those skilled in the art that the node may be any node in the federation block chain, or it may be said that processing of a new block generation request by all nodes in the federation block chain may be implemented with reference to an embodiment of the present invention.
The new block generation request carries the number of the block to be generated, i.e. the number of the requested new block and the information of the block content corresponding to the new block. In practical application, a person skilled in the art can adopt any appropriate number which meets the specification of the block chain, and can uniquely identify the block and represent the position of the block in the block. For the information of the block content, those skilled in the art may also implement the information in any suitable manner according to actual needs, for example, summary information of the block content of the new block, and the like, which is not limited in this embodiment of the present invention.
Step S104: and checking the number of the new block, checking the information of the block content corresponding to the successfully checked number of the new block, and pre-generating the new block after the successful check.
In this step, by checking the number of the new block, the verification of the sequence of the numbers can be realized, and the block chain of the federation can be prevented from branching. When checking the number of the new block, the checking may be performed according to a relationship between the number of the new block and a number of a latest block that already exists locally. After the serial number is successfully checked, further, checking the information of the block content is performed to determine whether the content requirement of the generated block is met.
If both the number check and the content check are successful, a new block may be pre-generated. And after the verification is successful, a new block is generated in advance, so that the generation efficiency of the new block can be effectively improved, and a new block generation program is saved. The specific implementation of the new block generation may refer to the generation of the block in the related block chain and the specification implementation thereof, which are not described herein again.
Step S106: and checking the number of the new block again, and sending a confirmation message to all nodes in the block chain of the alliance after the checking is successful.
In the block chain, each node can perform a request and operation for generating a new block at any time, and in order to ensure the accuracy of generating a certain new block, in this step, after the new block is pre-generated, the number of the new block is checked again to ensure that the block is still the newest block to be generated in the processing stage.
After the verification is successful again, the current node sends a confirmation message to all nodes (including the self node) in the alliance block chain to indicate that the current node is ready for generating a new block.
Step S108: and judging whether all nodes of the alliance block chain achieve consensus on the confirmation message, if so, generating a new block of the node initiating the new block generation request according to the pre-generated new block.
The blockchain is an advanced distributed system, and the problem of transmitting trusted information on an untrusted channel is solved. In the block chain, because higher network latency exists in the peer-to-peer network, the sequence of the transaction (specifically, new block generation) observed by each node has a certain difference, so a set of mechanism is also required in the block chain to achieve consensus on the sequence of the transaction occurring within a certain time, which is a consensus mechanism.
The consensus mechanism plays a role in determining who is responsible for generating a new block and maintaining the uniformity of the block chain in the block chain, and the current consensus mechanism is evolved based on the Paxos algorithm. The Paxos algorithm is a consistency algorithm based on a message passing model, and can ensure that all nodes can finally obtain a consistent state if the initial states of the nodes are consistent and each node executes the same operation sequence in a distributed database system. The common recognition mechanism of the current blockchain can be roughly classified into PoW (workload certification), PoS (equity certification), PBFT (practical byzantine fault-tolerant algorithm), and the like.
In this step, after it is determined that all nodes have achieved consensus on the acknowledgment message through a consensus mechanism of the federation block chain, a new block may be generated, and specifically, a new block generation operation may be directly performed by using a previously pre-generated new block.
By the embodiment, a master node is not used in an alliance block chain any more, a number checking mechanism is used for ensuring that a block is normally generated under the condition of no master node, after a new block generation request is received, the number of the block to be generated (namely, the new block) is checked, so that the sequence of the block to be generated is determined according to the number, and block chain bifurcation is avoided; furthermore, after a new block is pre-generated, the number of the block to be generated is checked again to ensure that the block is the newest block to be generated in the processing stage. Therefore, under the condition that no main node exists, the block chain of the alliance can also ensure the generation sequence and uniqueness of the new blocks, and the problem that in the process of generating the new blocks by the existing block chain of the alliance, when the main node fails or elects the main node, the new blocks cannot be generated, and further the data consistency inside the block chain of the alliance cannot be ensured is solved.
The block generation method of the present embodiment may be executed by any suitable electronic device with data processing capability, including but not limited to: servers, mobile terminals (such as tablet computers, mobile phones and the like), PCs and the like.
Example two
Referring to fig. 2, a flowchart illustrating steps of a block generation method according to a second embodiment of the present invention is shown.
In this embodiment, the block generation method provided in this embodiment is described in a specific example, and similar to the embodiment, the block generation method of this embodiment is also applied to a federation block chain in which a PBFT algorithm is used to implement a consensus mechanism, and the federation block chain does not have a master node.
Similar to the conventional PBFT, the PBFT algorithm is also adopted in this embodiment, and the generation of the new block is logically divided into five stages, which are: request phase, pre-prepare phase, commit phase, execute and reply phase.
Based on the above scenario, the block generation method of the present embodiment includes the following steps:
step S202: a new block generation request initiated by a node in the federation block chain is received.
The new block generation request carries the number of the requested new block and the information of the corresponding block content.
In one possible approach, specifically to the stages of the PBFT, this step may be implemented as: receiving a new block generation request initiated by a node in the alliance block chain in the first stage and a first state message generated according to the new block generation request in the second stage of block generation processing; the first state message is used for indicating that the new block is in a first state, and the first state is used for indicating that the new block is in a state to be subjected to pre-generation processing. By setting the state and the state information, the method can keep the same with the PBFT algorithm to the maximum extent, reduce the complexity of the algorithm and save the generation cost of a new block. The first stage is a request stage, the first state is a pre-prepare state, and the first state message is a pre-prepare state message; the second stage is the pre-preparation stage.
In a specific application scenario of this embodiment, for example, in a request phase, a certain node a in the federation Block chain initiates a request for building a new Block (i.e., a new Block generation request), and the node a sets the state of the new Block to a pre-prepare state (i.e., a first state), and broadcasts the state message (i.e., a first state message) to the whole network.
For other nodes in the alliance Block chain, the message is received in the initial period of the pre-prepare phase, and taking one of the nodes, for example, the node B, as the other node, the node B receives the request for constructing the new Block initiated by the node a, where the request carries information of the number and the Block content of the new Block. It should be noted that the above description takes other nodes than the node a that issues the request for building the new Block as an example, but it should be clear to those skilled in the art that the above node B may be any node in the federation Block chain, including the node a itself. It can be seen that in a specific application scenario, this step occurs during the initial phase of the pre-prepare phase.
Step S204: checking whether the new block generation request is a repeat request; if so, not processing the new block generation request; if not, go to step S206.
In combination with the specific application scenario of this embodiment, for example, in the pre-prepare stage, the node B receives a Block request for constructing a new Block, and checks whether a repeat request is received; if the received request is a repeated request, refusing to process the request; if the request is not a repeat request, i.e., a new request, the process proceeds to step S206. It can be seen that in a particular application scenario, this step occurs in an intermediate phase following the pre-preparation phase initiation phase.
Step S206: and checking the number of the new block, checking the information of the block content corresponding to the successfully checked number of the new block, and pre-generating the new block after the successful check.
In one possible approach, this step can be implemented as: the number of the new block is checked, and if the number check fails, the new block generation request is not processed any more; if the number is successfully checked, checking the information of the block content of the new block, pre-generating the new block, and if the pre-newly generated block fails, not processing the new block generation request; and if the pre-generated block is successful, adding the new block into a preparation queue. By the method, the block chain can be prevented from falling into a dead loop due to an unexpected condition in the new block generation process, and further the whole block chain is abnormal or crashed.
Optionally, checking the number of the new block may include: traversing all voting information of the new block based on the hash value corresponding to the new block, and if the traversal result indicates that the new block has voted, the number verification fails; if the number of the new block is less than or equal to the number of the current block, the number verification fails; and if the number of the new block is greater than that of the current block, the number verification is successful. By the method, whether the new block generation request is valid can be effectively determined.
The hash value (hash value) of the block chain can accurately and uniquely identify and identify a block, and any node in the block chain can obtain the hash value of the block through simple hash calculation. If the block corresponding to the hash value is subjected to voting operation once, the block is established, the request is not processed again, and the number check fails.
In the block chain, the blocks are sequentially numbered and generated, the current block is the latest block which is successfully established, the corresponding number of the current block is also the latest number, if the number of the new block requested to be generated is smaller than or equal to the number of the current block, the new block is indicated to be the block which is already generated (smaller than the number of the current block) or the new block generation request is a repeat request (equal to the number of the current block), the number verification fails, and otherwise, the number verification succeeds.
The checking of the information of the block content may be implemented by those skilled in the art in any appropriate manner according to actual needs, such as check code, redundancy check, and the like, which is not limited in this embodiment of the present invention.
After the number check and the information check of the block content are both successful, a new block may be pre-generated, where a specific implementation of pre-generating the new block may be implemented by a person skilled in the art by referring to a generation manner of the new block in the existing block chain, or may also be implemented in any other appropriate manner, which is not limited in this embodiment of the present invention.
In addition, optionally, after the number verification and the information verification of the block content are both successful and the new block is pre-generated, that is, after this step, the block state of the new block may also be set to a second state, and a corresponding second state message may be sent to all nodes in the alliance block chain, where the second state is used to indicate that the new block is in a state to be subjected to the confirmation processing. By setting the state and the state information, the method can keep the same with the PBFT algorithm to the maximum extent, reduce the complexity of the algorithm and save the generation cost of a new block.
Specifically to each stage of PBFT, this step can be implemented as: and checking the number of the new block at the second stage, checking the information of the block content corresponding to the successfully checked number of the new block, pre-generating the new block after the successful check, setting the block state of the new block to be in a second state, and sending a corresponding second state message to all nodes in the alliance block chain, wherein the second state is used for indicating that the new block is in a state to be confirmed. Wherein the second stage is a pre-prepare stage, the second state is a prepare state, and the second state message is a prepare state message.
In combination with the specific application scenario of this embodiment, for example, in the pre-prepare stage, the node B checks the number of the Block requested; if the voting for authenticating the Block number already occurs in the current stage later than the prefix stage, the number check fails, and a new Block building request initiated by the node A is not processed; if the serial number is successfully checked, checking the information of the Block content, if the information check fails, not processing a request for constructing a new Block initiated by the node A, and if the information check is successful, pre-generating the new Block; and if the operation of pre-generating the new Block fails, not processing the request for constructing the new Block, and if the operation of pre-generating the new Block succeeds, adding the pre-generated new Block into a prepare queue, setting the state of the new Block to be a prepare state (namely a second state), and broadcasting the state message (namely the second state message) to the whole network. It can be seen that in a particular application scenario, this step occurs after the middle of the pre-preparation phase, which can be considered to be the later stage of the pre-preparation phase.
In addition, the above described numbering check is performed according to the presence or absence of the voting information in the block, but as described above, the numbering check is not limited to this type of numbering check, and in the case of the numbering check, the number check may be performed by: 1, traversing all voting information in the new block state stage, and if the blocks corresponding to the hash value of the new block are voted, the number verification fails; 2, if the number of the block to be voted is less than or equal to the number of the current block, the number verification fails; and 3, if the number of the block to be voted is greater than the number of the current block, successfully verifying the number. Through number verification, block chain bifurcation can be effectively prevented, block number sequence verification is realized, and the correctness and the effectiveness of new block generation are ensured.
Step S208: and checking the number of the new block again, and sending a confirmation message to all nodes in the block chain of the alliance after the checking is successful.
The way of checking the new block number again is the same as that in step S206, and is not described herein again.
In specific implementation, the number of the new block may be checked again, and if the number check fails, the new block generation request is not processed any more; and if the number is successfully checked, sending a submission message to all nodes in the alliance block chain so as to ensure the effectiveness and the robustness of the alliance block chain.
In one possible approach, the sending acknowledgement messages to all nodes in the federation blockchain after the verification is successful includes: and after the verification is successful, setting the block state of the new block to be a third state, and sending a corresponding third state message serving as a confirmation message to all nodes in a block chain of the alliance, wherein the third state is used for indicating that the new block is in a state to be submitted. By setting the state and the state information, the method can keep the same with the PBFT algorithm to the maximum extent, reduce the complexity of the algorithm and save the generation cost of a new block.
Specifically to each stage of PBFT, this step can be implemented as: and checking the number of the new block again in the third stage of the block generation processing, setting the block state of the new block to be a third state after the checking is successful, and sending a corresponding third state message to all nodes in the alliance block chain as a confirmation message, wherein the third state is used for indicating that the new block is in a state to be submitted. The third stage is a prepare stage, the third state is a commit state, and the third status message is a commit status message.
In combination with the specific application scenario of this embodiment, for example, in the prepare stage, the node B performs number check on the Block number again; if the number is not successfully checked, the new Block building request is not processed; if the number is successfully checked, the Block state is set to the commit state (namely, the third state), and the state message (namely, the third state message) is broadcasted to the whole network. It can be seen that in a specific application scenario, this step occurs in the preamble phase.
Step S210: judging whether all nodes of the alliance block chain achieve consensus on the confirmation message, if so, generating a new block of the node initiating a new block generation request according to the pre-generated new block; if not, the new block generation processing is not performed.
In the blockchain, when all nodes respond to the new block generation request, such as a feedback confirmation message, all nodes are considered to have consensus. For each node in the blockchain, its acknowledgement message will be sent to all nodes in the blockchain (including its own node).
For the current node, it may determine whether all nodes in the federation blockchain agree upon a consensus by determining whether acknowledgement messages for all nodes in the federation blockchain are received.
In one possible approach, when the acknowledgment message is a commit status message, the determining whether all nodes agree on the acknowledgment message may include: judging whether the submission state information of all nodes in the alliance block chain is received or not; if yes, determining that all the nodes achieve consensus; otherwise, it is determined that consensus is not achieved.
When a new block of a node initiating the new block generation request is generated according to the pre-generated new block, whether the new block is generated locally by a current node can be checked; if yes, no generation is performed; if not, acquiring metadata information and content data from the pre-generated new block, writing the metadata information into a alliance block chain, and locally storing the content data.
In addition, optionally, when a new block of the node that initiates the new block generation request is generated according to the pre-generated new block, the block status of the new block may be set to a fourth status, and a new block of the node that initiates the new block generation request is generated according to the fourth status and the pre-generated new block, where the fourth status is used to indicate that the new block is in a status that the commit process has been performed. By setting the state and the state information, the method can keep the same with the PBFT algorithm to the maximum extent, reduce the complexity of the algorithm and save the generation cost of a new block.
Specifically to each stage of PBFT, this step can be implemented as: judging whether all the nodes agree with the confirmation message at a fourth stage of the block generation processing, if so, setting the block state of the new block to be a fourth state, generating a new block of a node initiating the new block generation request according to the fourth state and the pre-generated new block, and sending information of the generated new block to all the nodes, wherein the fourth state is used for indicating that the new block is in a state of being subjected to submission processing; and in the fifth stage of the block generation processing, receiving the information of the new block, checking whether the new block is generated locally or not according to the information of the new block, and processing the new block generation request according to a check result. The fourth stage is a commit stage, the fourth state is a committed state, the fourth status message is a committed state message, and the fifth stage is an execution and reply stage.
In combination with the specific application scenario of this embodiment, for example, in the commit stage, each node performs count accumulation after receiving the commit status message; since the PBFT algorithm can tolerate one third of the nodes at most, that is, the PBFT requires at least two thirds of the nodes' acknowledgement messages to achieve consensus, if each node receives a commit status message of more than 2f +1 (where f represents the number of problem nodes in all nodes, 0< ═ f < ═ N-1)/3, and N is the number of all nodes) different nodes (including its own node), it considers that the processing of the new block is already agreed in the whole network (i.e., all nodes of the federation block chain), enters a committed status (i.e., the fourth state), writes the metadata information of the new block into the federation block chain, and stores the entire content of the new block in a local, e.g., local, relational database, such as sqlite database.
Further, in the execution and reply phase, the current node, such as node B, broadcasts the message that the new block has been generated to the whole network (i.e. all nodes of the federation block chain); after each node in the alliance block chain receives the message generated by the new block, whether the block is generated locally or not is checked, and if the block is generated, the message is ignored; if not, the new block is generated locally, that is, the metadata information of the new block is written into the federation block chain, and the entire content of the new block is stored locally, for example, in a local relational database, for example, in an sql ite database.
It can be seen that, in a specific application scenario, the step of determining whether all nodes of the federation blockchain agree with the confirmation message occurs at a commit stage; in this step, the new block of the node which initiates the new block generation request is generated according to the pre-generated new block, and the commit stage, the execution stage and the reply stage are processed.
As can be seen, according to the embodiment, for the federation block chain, there is no need to select a master node (Leader) from the nodes in the whole network to generate a new block, and any node can construct a block-based whole network broadcast. In order to ensure that the block is normally generated under the condition without the main node, a number checking mechanism is used, after a new block generation request is received, the number of the block to be generated (namely the new block) is checked, so that the sequence of the block to be generated is determined according to the number, and block chain branching is avoided; furthermore, after a new block is pre-generated, the number of the block to be generated is checked again to ensure that the block is the newest block to be generated in the processing stage. Therefore, under the condition that no main node exists, the block chain of the alliance can also ensure the generation sequence and uniqueness of the new blocks, and the problem that in the process of generating the new blocks by the existing block chain of the alliance, when the main node fails or elects the main node, the new blocks cannot be generated, and further the data consistency inside the block chain of the alliance cannot be ensured is solved.
The block generation method of the present embodiment may be executed by any suitable electronic device with data processing capability, including but not limited to: servers, mobile terminals (such as tablet computers, mobile phones and the like), PCs and the like.
EXAMPLE III
An embodiment of the present invention further provides a computer-readable medium, where the computer-readable medium stores a readable program, where the readable program is applied to a federated blockchain, where the federated blockchain does not have a master node, and the readable program includes: the instruction is used for receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content; instructions for verifying the number of the new block, verifying information of the block content corresponding to the successfully verified number of the new block, and pre-generating the new block after the successful verification; an instruction for checking the number of the new block again and sending a confirmation message to all nodes in the alliance block chain after the checking is successful; and instructions for determining whether all the nodes agree with the acknowledgment message, and if yes, generating a new block of the node that initiates the new block generation request according to the pre-generated new block.
Optionally, the instruction for checking the number of the new block includes: instructions for traversing all voting information of the new block based on the hash value corresponding to the new block, and if the traversal result indicates that the new block has voted, numbering and checking fail; instructions for verifying the number if the number of the new block is less than or equal to the number of the current block; and if the number of the new block is greater than the number of the current block, successfully verifying the number.
Optionally, the readable program further comprises: instructions for verifying whether the new block generation request is a repeat request before the instructions for verifying the new block number; if yes, not processing the new block generation request; and if not, executing the instruction for checking the number of the new block.
Optionally, the instruction, configured to verify the number of the new block, verify information of a block content corresponding to the number of the new block that is successfully verified, and pre-generate the new block after successful verification, includes: a command for checking the serial number of the new block, and if the serial number check fails, stopping processing the new block generation request; if the number is successfully checked, checking the information of the block content of the new block, pre-generating the new block, and if the pre-generated block fails, not processing the new block generation request; instructions for adding the new block to a ready queue if pre-generating the block is successful.
Optionally, the instructions for checking the number of the new block again and sending a confirmation message to all nodes in the federation block chain after the checking is successful include: a command for checking the number of the new block again, and if the number check fails, stopping processing the new block generation request; and sending a confirmation message to all nodes in the federation blockchain if the number is successfully checked.
Optionally, the confirmation message is a commit status message; the instructions for determining whether all nodes agree to the acknowledgement message comprise: instructions for determining whether a commit status message for all nodes in the federation blockchain is received; instructions for determining that all of the nodes agree upon if so; and instructions for otherwise determining that consensus is not achieved.
Optionally, the instruction for generating a new block of a node initiating the new block generation request according to the pre-generated new block includes: instructions for verifying whether the new chunk has been generated locally; instructions for not generating if so; and if not, acquiring metadata information and content data from the pre-generated new block, writing the metadata information into the alliance block chain, and locally storing the content data.
Optionally, the instructions for receiving a new block generation request initiated by a node in the federation block chain include: instructions for receiving, at a second stage of block generation processing, a new block generation request initiated by a node in the federation block chain at the first stage and a first status message generated in accordance with the new block generation request; the first state message is used for indicating that the new block is in a first state, and the first state is used for indicating that the new block is in a state to be subjected to pre-generation processing;
the instruction for verifying the number of the new block, verifying the block content information corresponding to the successfully verified number of the new block, and pre-generating the new block after the successful verification includes: the instruction is used for verifying the number of the new block in the second stage, verifying information of the block content corresponding to the successfully verified number of the new block, pre-generating the new block after the successful verification, setting the block state of the new block to be in a second state, and sending a corresponding second state message to all nodes in the alliance block chain, wherein the second state is used for indicating that the new block is in a state to be subjected to confirmation processing;
the instruction for checking the number of the new block again and sending a confirmation message to all nodes in the federation block chain after the checking is successful comprises: an instruction, configured to check the number of the new block again in the third stage of the block generation processing, and set the block state of the new block to a third state after the check is successful, where the instruction is configured to send a corresponding third state message to all nodes in the federation block chain as an acknowledgement message, where the third state is used to indicate that the new block is in a state to be subjected to commit processing;
the instruction for determining whether the confirmation message is agreed by all the nodes, and if so, generating a new block of the node initiating the new block generation request according to the pre-generated new block includes: an instruction for determining whether the acknowledgement message is agreed by all nodes at a fourth stage of the block generation processing, if so, setting the block state of the new block to a fourth state, generating a new block of a node initiating the new block generation request according to the fourth state and the pre-generated new block, and sending information of the generated new block to all nodes, wherein the fourth state is used for indicating that the new block is in a state of being subjected to commit processing; and an instruction for receiving the information of the new block, verifying whether the new block is generated locally according to the information of the new block, and processing the new block generation request according to a verification result in a fifth stage of the block generation processing.
Optionally, the first stage is a request stage, and the first status message is a pre-prepare status message; the second stage is a pre-prepare stage, and the second state message is a prepare state message; the third stage is a prepare stage, and the third status message is a commit status message; the fourth stage is a commit stage, and the fourth status message is a committed status message; the fifth phase is the execute and replay phase.
By the computer-readable medium of the embodiment, a master node is not used in an alliance block chain any more, and in order to ensure that a block is normally generated without the master node, the scheme provided by the embodiment of the invention uses a number checking mechanism, and after a new block generation request is received, the number of the block to be generated (i.e. the new block) is checked, so that the sequence of the block to be generated is determined according to the number, and block chain branching is avoided; furthermore, after a new block is pre-generated, the number of the block to be generated is checked again to ensure that the block is the newest block to be generated in the processing stage. Therefore, under the condition that no main node exists, the block chain of the alliance can also ensure the generation sequence and uniqueness of the new blocks, and the problem that in the process of generating the new blocks by the existing block chain of the alliance, when the main node fails or elects the main node, the new blocks cannot be generated, and further the data consistency inside the block chain of the alliance cannot be ensured is solved.
It should be noted that, according to the implementation requirement, each component/step described in the embodiment of the present invention may be divided into more components/steps, and two or more components/steps or partial operations of the components/steps may also be combined into a new component/step to achieve the purpose of the embodiment of the present invention.
The above-described method according to an embodiment of the present invention may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, a RAM, a floppy disk, a hard disk, or a magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein may be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware such as an ASIC or FPGA. It will be appreciated that the computer, processor, microprocessor controller or programmable hardware includes memory components (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor or hardware, implements the block generation methods described herein. Further, when a general-purpose computer accesses code for implementing the tile generation method illustrated herein, execution of the code transforms the general-purpose computer into a special-purpose computer for performing the tile generation method illustrated herein.
Those of ordinary skill in the art will appreciate that the various illustrative elements and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.
The above embodiments are only for illustrating the embodiments of the present invention and not for limiting the embodiments of the present invention, and those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of the present invention, so that all equivalent technical solutions also belong to the scope of the embodiments of the present invention, and the scope of patent protection of the embodiments of the present invention should be defined by the claims.
Claims (9)
1. A block generation method applied to a federated block chain, wherein the federated block chain has no master node, the method comprising:
receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content;
verifying the number of the new block, verifying the information of the block content corresponding to the successfully verified number of the new block, and pre-generating the new block after the successful verification, including: traversing all voting information of the new block based on the hash value corresponding to the new block, and if the traversal result indicates that the new block has voted, the number verification fails; if the number of the new block is less than or equal to the number of the current block, the number verification fails; if the number of the new block is larger than that of the current block, the number verification is successful;
checking the number of the new block again, and sending confirmation messages to all nodes in the alliance block chain after the checking is successful;
and judging whether all the nodes agree with the confirmation message, if so, generating a new block of the node initiating the new block generation request according to the pre-generated new block.
2. The method of claim 1, wherein prior to said checking the number of the new block, the method further comprises:
checking whether the new block generation request is a repeat request; if so, not processing the new block generation request; and if not, executing the step of checking the number of the new block.
3. The method according to claim 2, wherein checking the number of the new block, checking information of the block content corresponding to the number of the new block that is successfully checked, and pre-generating the new block after the successful check comprises:
the number of the new block is checked, and if the number check fails, the new block generation request is not processed any more;
if the number is successfully checked, checking the information of the block content of the new block, pre-generating the new block, and if the pre-generation of the new block fails, not processing the new block generation request;
and if the pre-generation of the new block is successful, adding the new block into a preparation queue.
4. The method of claim 1, wherein checking the number of the new block again and sending an acknowledgement message to all nodes in the federation blockchain after the checking is successful comprises:
the number of the new block is checked again, and if the number check fails, the new block generation request is not processed any more;
and if the number is successfully checked, sending a confirmation message to all nodes in the alliance block chain.
5. The method of claim 1, wherein the acknowledgement message is a commit status message;
the determining whether all nodes agree with the acknowledgment message includes: judging whether the submission state information of all the nodes in the alliance block chain is received or not; if yes, determining that all the nodes achieve consensus; otherwise, it is determined that consensus is not achieved.
6. The method according to claim 1, wherein said generating a new block of a node initiating the new block generation request according to the pre-generated new block comprises:
checking whether the new block is generated locally;
if yes, no generation is performed;
if not, acquiring metadata information and content data from the pre-generated new block, writing the metadata information into the alliance block chain, and locally storing the content data.
7. The method according to any one of claims 1 to 6,
the receiving a new block generation request initiated by a node in the federation block chain includes: receiving a new block generation request initiated by a node in the alliance block chain in the first stage and a first state message generated according to the new block generation request in the second stage of block generation processing; the first state message is used for indicating that the new block is in a first state, and the first state is used for indicating that the new block is in a state to be subjected to pre-generation processing;
the verifying the number of the new block, verifying the information of the block content corresponding to the successfully verified number of the new block, and pre-generating the new block after the successfully verified number comprises: checking the number of the new block at the second stage, checking the information of the block content corresponding to the successfully checked number of the new block, pre-generating the new block after the checking is successful, setting the block state of the new block to be a second state, and sending a corresponding second state message to all nodes in the alliance block chain, wherein the second state is used for indicating that the new block is in a state to be confirmed;
the checking the number of the new block again, and sending a confirmation message to all nodes in the alliance block chain after the checking is successful comprises: in the third stage of the block generation processing, the number of the new block is checked again, and after the check is successful, the block state of the new block is set to a third state, and a corresponding third state message is used as a confirmation message and is sent to all nodes in the alliance block chain, wherein the third state is used for indicating that the new block is in a state to be submitted;
the determining whether all the nodes agree with the acknowledgment message, if yes, generating a new block of the node initiating the new block generation request according to the pre-generated new block includes: judging whether all the nodes agree with the confirmation message at a fourth stage of the block generation processing, if so, setting the block state of the new block to be a fourth state, generating a new block of a node initiating the new block generation request according to the fourth state and the pre-generated new block, and sending information of the generated new block to all the nodes, wherein the fourth state is used for indicating that the new block is in a state of being subjected to submission processing; and in the fifth stage of the block generation processing, receiving the information of the new block, checking whether the new block is generated locally or not according to the information of the new block, and processing the new block generation request according to a check result.
8. The method of claim 7, wherein the first phase is a request phase, and wherein the first status message is a pre-prepare status message; the second stage is a pre-prepare stage, and the second state message is a prepare state message; the third stage is a prepare stage, and the third status message is a commit status message; the fourth stage is a commit stage, and the fourth status message is a committed status message; the fifth phase is the execute and replay phase.
9. A computer-readable medium, wherein the computer storage medium stores a readable program, the readable program being applied to a federated blockchain, the federated blockchain having no master nodes, the readable program comprising:
the instruction is used for receiving a new block generation request initiated by a node in the alliance block chain, wherein the new block generation request carries the number of the requested new block and the information of the corresponding block content;
the number of the new block is checked, all voting information of the new block is traversed based on a hash value corresponding to the new block, and if the traversal result indicates that the new block has voted, the number checking fails; if the number of the new block is less than or equal to the number of the current block, the number verification fails; if the number of the new block is larger than that of the current block, the number verification is successful; checking the information of the block content corresponding to the serial number of the new block which is successfully checked, and pre-generating an instruction of the new block after the checking is successful;
an instruction for checking the number of the new block again and sending a confirmation message to all nodes in the alliance block chain after the checking is successful;
and instructions for determining whether all the nodes agree with the acknowledgment message, and if yes, generating a new block of the node that initiates the new block generation request according to the pre-generated new block.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811206993.2A CN109586949B (en) | 2018-10-17 | 2018-10-17 | Block generation method and computer storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811206993.2A CN109586949B (en) | 2018-10-17 | 2018-10-17 | Block generation method and computer storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109586949A CN109586949A (en) | 2019-04-05 |
| CN109586949B true CN109586949B (en) | 2021-04-09 |
Family
ID=65920536
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811206993.2A Active CN109586949B (en) | 2018-10-17 | 2018-10-17 | Block generation method and computer storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109586949B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110099127A (en) * | 2019-05-13 | 2019-08-06 | 西安华域网络文化发展有限公司 | A kind of block chain method of data synchronization, device, medium and electronic equipment |
| EP3701701A4 (en) * | 2019-06-05 | 2020-12-30 | Alibaba Group Holding Limited | Consensus system and method |
| CN110519287B (en) * | 2019-08-30 | 2022-08-12 | 腾讯科技（深圳）有限公司 | Information management method and related equipment |
| CN111541756B (en) * | 2020-04-17 | 2021-10-15 | 腾讯科技（深圳）有限公司 | Block generation method, block generation device, node equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106453636A (en) * | 2016-11-22 | 2017-02-22 | 深圳银链科技有限公司 | Credible block generation method and system |
| CN107146087A (en) * | 2017-04-11 | 2017-09-08 | 广东网金控股股份有限公司 | A kind of quick common recognition bookkeeping methods and system based on block chain alliance chain |
| CN107807951A (en) * | 2017-09-18 | 2018-03-16 | 联动优势科技有限公司 | A kind of block chain generation method, data verification method, node and system |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9876646B2 (en) * | 2015-05-05 | 2018-01-23 | ShoCard, Inc. | User identification management system and method |
| US11941588B2 (en) * | 2015-11-06 | 2024-03-26 | Cable Television Laboratories, Inc. | Systems and methods for blockchain virtualization and scalability |
-
2018
- 2018-10-17 CN CN201811206993.2A patent/CN109586949B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106453636A (en) * | 2016-11-22 | 2017-02-22 | 深圳银链科技有限公司 | Credible block generation method and system |
| CN107146087A (en) * | 2017-04-11 | 2017-09-08 | 广东网金控股股份有限公司 | A kind of quick common recognition bookkeeping methods and system based on block chain alliance chain |
| CN107807951A (en) * | 2017-09-18 | 2018-03-16 | 联动优势科技有限公司 | A kind of block chain generation method, data verification method, node and system |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109586949A (en) | 2019-04-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109586949B (en) | Block generation method and computer storage medium | |
| CN109361740B (en) | Block generation method, device, equipment and medium of block chain | |
| KR102019211B1 (en) | Method for generating block chain capable of overcoming byzantine fault | |
| CN109542888B (en) | Data modification and synchronization method, device, equipment and storage medium of block chain | |
| CN111163182B (en) | Block chain-based device registration method and apparatus, electronic device, and storage medium | |
| CN110943838A (en) | Method, apparatus and storage medium for determining consensus of blocks in a blockchain network | |
| US20190130190A1 (en) | Media authentication using distributed ledger | |
| CN111342971B (en) | Bayesian and preemptive consensus method and system | |
| CN110690974B (en) | Block chain based data verification method, device, equipment and readable storage medium | |
| CN110941859A (en) | Method, apparatus, computer-readable storage medium, and computer program product for block chain formation consensus | |
| CN108696356B (en) | Block chain-based digital certificate deleting method, device and system | |
| CN108989052B (en) | Transaction request processing method and system | |
| CN109194493B (en) | Information management system, method and device | |
| CN110309160B (en) | Data in-link transaction processing method, device, computer equipment and storage medium | |
| CN114338715B (en) | Data synchronization method, blockchain system, terminal equipment and storage medium | |
| CN111582843A (en) | Block chain privacy transaction method based on aggregated signature | |
| CN112182113B (en) | Block chain consensus method, system, electronic equipment and storage medium | |
| CN113127569A (en) | Consensus method and device for block chain system, electronic equipment and storage medium | |
| CN111209343A (en) | Node data synchronization method, device, equipment and storage medium | |
| CN111523899A (en) | Consensus method of alliance chain, data verification method, device and system | |
| CN115225639B (en) | Changing method and device for consensus trusted cluster, computer equipment and medium | |
| CN111555858B (en) | Practical Byzantine fault-tolerant consensus method based on block chain type storage | |
| CN112398949A (en) | Transaction confirmation method, system, device and computer equipment | |
| CN103024015A (en) | Flex based cross-platform method for uploading files after message digest 5 (md5) value is checked at browser end | |
| CN114936253A (en) | Block chain consensus method and device, electronic equipment and storage medium |
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 |