CN116009940A - Method, device, computer equipment and medium for changing consensus cluster - Google Patents
Method, device, computer equipment and medium for changing consensus cluster Download PDFInfo
- Publication number
- CN116009940A CN116009940A CN202211603619.2A CN202211603619A CN116009940A CN 116009940 A CN116009940 A CN 116009940A CN 202211603619 A CN202211603619 A CN 202211603619A CN 116009940 A CN116009940 A CN 116009940A
- Authority
- CN
- China
- Prior art keywords
- cluster
- consensus
- block
- state
- configuration
- 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.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The embodiment of the application is suitable for the technical field of block chains, and provides a method, a device, computer equipment and a medium for changing a consensus cluster, wherein the method comprises the following steps: if the configuration block is submitted to be executed, generating a check point state, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed; discarding the consensus data of a target block, which is a void block after the allocation block, if the checkpointed state includes cluster change information; and changing the consensus cluster based on the checkpoint state. By the method, all blocks after the common identification cluster is changed can be identified by the changed common identification cluster.
Description
Technical Field
The application belongs to the technical field of blockchains, and particularly relates to a method, a device, computer equipment and a medium for changing a consensus cluster.
Background
In a blockchain system, data addition and state update are overlapped in a chained mode by taking a block as a unit, and a common recognition strategy in a pipeline form is a common mode capable of guaranteeing the security of the blockchain and improving the common recognition efficiency, but because of the non-immediate confirmatory of pipeline common recognition, the common recognition trusted cluster change of the blockchain is difficult to realize.
For example, for consecutive blocks B1, B2, and B3, execution of block B1 may not be committed until B3 voting consensus is complete due to the non-immediate confirmations of pipeline consensus. During B1 block execution, if a change in the consensus cluster is required, then after the consensus trusted cluster change, the consensus for blocks B2 and B3 is still based on the previous consensus trusted cluster. However, blocks B2 and B3 are actually blocks following the B1 block, and for the consensus of blocks B2 and B3, it should be expected that the consensus will be performed by the consensus trusted cluster after the change, which obviously cannot be achieved in the prior art.
Disclosure of Invention
In view of this, the embodiments of the present application provide a method, an apparatus, a computer device, and a medium for changing a consensus cluster, so as to improve consensus of all blocks after a block is configured by the consensus trusted cluster after the change.
A first aspect of an embodiment of the present application provides a method for changing a consensus cluster, applied to a node device of a blockchain, where the method includes:
if the configuration block is submitted to be executed, generating a check point state, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed;
Discarding the consensus data of a target block, which is a void block after the allocation block, if the checkpointed state includes cluster change information;
and changing the consensus cluster based on the checkpoint state.
A second aspect of an embodiment of the present application provides a changing apparatus of a consensus cluster, applied to a node device of a blockchain, the apparatus including:
the generation module is used for generating a check point state if the configuration block is submitted to be executed, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed;
the discarding module is configured to discard consensus data of a target block if the checkpointed state includes cluster change information, where the target block is a void block after the allocation block;
and the changing module is used for changing the consensus cluster based on the check point state.
A third aspect of embodiments of the present application provides a computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to the first aspect described above when executing the computer program.
A fourth aspect of the embodiments of the present application provides a computer readable storage medium storing a computer program which, when executed by a processor, implements a method as described in the first aspect above.
A fifth aspect of embodiments of the present application provides a computer program product, which when run on a computer device, causes the computer device to perform the method of the first aspect described above.
Compared with the prior art, the embodiment of the application has the following advantages:
by applying the method provided by the embodiment of the application, the configuration transaction for changing the consensus cluster can be packaged in the configuration block, and after the configuration block is submitted to be executed, the node device can generate a check point state for determining whether the consensus cluster is changed. If the check point state comprises cluster change information, determining that the consensus cluster is changed, and discarding the consensus information of the empty area blocks after the configuration block by the node equipment; the consensus cluster may then be altered based on the checkpointed state. Because the blocks after the blocks are allocated are empty blocks, the transaction after the blocks are allocated does not use the current consensus cluster for consensus before the blocks are allocated; the loss of consensus data of empty blocks after the allocation blocks does not affect the data in the blockchain. In the embodiment of the application, after the configuration block is submitted and executed, the configuration block can be continuously identified without waiting for the execution result of the configuration block, so that the execution and the identification decoupling of the configuration block are ensured; the block after the common identification cluster is changed can be used for common identification based on the empty block after the block is configured while the block is executed and the block common identification is decoupled.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings that are required to be used in the embodiments or the description of the prior art.
Fig. 1 is a schematic flow chart of steps of a method for changing a consensus cluster according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a consensus cluster generation checkpoint provided by an embodiment of the present application;
FIG. 3 is a schematic diagram of a consensus cluster change provided in an embodiment of the present application;
FIG. 4 is a schematic diagram of a failure of a common cluster change provided in an embodiment of the present application;
FIG. 5 is a flowchart illustrating a method for changing a consensus cluster according to another embodiment of the present disclosure;
fig. 6 is a schematic diagram of a device for changing a consensus cluster according to an embodiment of the present application;
fig. 7 is a schematic diagram of a computer device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
If the consensus cluster uses the chained bayer fault-tolerant hotspot algorithm, the consensus rule of three rounds of voting in a pipelined manner needs to be followed in the consensus cluster. That is, for any consecutive block B1, B2, B3, after voting on block B3 is successful, block B1 can be submitted, which is equivalent to determining that the block B1 is consistent after voting 3 times.
When the node receives the block B1 containing the executable cluster change transaction T, the block B1 needs to be executed to obtain the temporary state S1 of the block B1. At this time, the node may obtain the changed cluster information V2 from the temporary state S1; for the following blocks B2, B3 of B1, the node will verify the correctness of the proposal and the voting signature with the cluster information V1 before the change. Until the voting on B3 succeeds, the node may submit B1 and its state S1, and change the consensus cluster to the cluster information V2 in S1. For block proposal and voting after B3, the signature correctness is verified by using the new cluster information V2.
In the consensus cluster, the block needs to be pre-executed before not submitting the execution, the pre-execution can determine a temporary state, the temporary state can be submitted to a temporary state set, namely, after a node receives the block B1, the block B1 is firstly executed before voting, and the temporary state after the block B1 is executed is recorded as S1; after receiving the block B1', executing to obtain S1', wherein the B1' and the B1 have the same father block and are different branches; after receiving the blocks B2, B2', B3 (B1- > B2- > B3, B1' - > B2 '), the temporary states S2, S2', S3 (S1- > S2- > S3, S1' - > S2 ') are executed and obtained and voting is performed, and when the B3 voting is successful, the block B1 state S1 is submitted and the temporary state S1' is discarded.
In the cluster change process, two blocks after the block is configured still need to be identified by using the old identification cluster, which is obviously unexpected, and an ideal cluster change state is that all blocks after the block is configured are identified by using the new identification cluster. Based on this, the present embodiment proposes a method for changing the consensus cluster.
The technical scheme of the present application is described below by specific examples.
Referring to fig. 1, a step flow diagram of a method for changing a consensus cluster provided in an embodiment of the present application is shown, which may specifically include the following steps:
s101, if the configuration block is submitted to be executed, generating a check point state, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed.
The execution body of the embodiment may be a node in a consensus cluster, where the node may be a consensus node, and the consensus cluster may include a plurality of consensus nodes, where the plurality of consensus nodes are configured to vote on a proposal in the consensus cluster; a blockchain may be constructed based on the consensus cluster. The consensus node may be deployed on a corresponding node device, which may be a computer device, such as an electronic computer, a server, etc. Of course, other nodes may be included in the blockchain system in addition to the consensus node, and other nodes may not have voting rights. For example, when determining whether a proposal of a cluster change passes or not, the consensus node has a voting right, and when a preset number of consensus nodes vote to confirm that the change of the consensus cluster can be performed, the proposal can be determined to pass; and other nodes can directly accept the voting results of the consensus nodes.
The modification of the consensus cluster may include modification of a consensus node in the consensus cluster, modification of a consensus algorithm, and the like, and in this embodiment, the present application will be described using the modification of the consensus node of the consensus cluster as an example.
When a change needs to be made to a node in the consensus cluster, the administrator may initiate a configuration transaction that is received by the master node in the consensus cluster and then package the configuration transaction into a configuration block. In one possible implementation, a configuration transaction for a cluster change may have a corresponding target tag field, and when a master node receives a transaction, it may identify whether the transaction carries the target tag field; if the transaction carries a target mark field, indicating that the transaction is a configuration transaction; the master node packages the configuration transaction into a block, wherein the block is the configuration block; after the configured chunks are packaged, the master node may stop packaging transactions into chunks such that the chunks following the configured chunks are empty chunks that do not contain configured transactions. In one possible implementation, the configuration block may include a plurality of transactions, and the plurality of transactions may include one configuration transaction; in another possible implementation, only one configuration transaction may be included in the configuration transaction; in another possible implementation, when the configuration transaction is identified, the configuration transaction may be packed into a block, and then the transaction subsequent to the configuration transaction may not be packed, that is, the configuration transaction may be taken as the last transaction in the configuration block, based on which, if the configuration transaction causes a change in the consensus cluster, all transactions subsequent to the configuration transaction may be consensus using the changed consensus cluster.
The master node may broadcast the packaged blocks to each node in the blockchain, and after each node in the blockchain acquires a block, the block may be first consensus by voting. After the blocks agree on the completion of the consensus among the nodes, commit execution may be performed to update the on-chain state of the blockchain.
In one possible implementation, if the consistency validation principle of multi-round voting in a pipeline manner needs to be followed in the blockchain system, the configuration block and the subsequent blocks of the configuration block can be commonly identified, and the subsequent blocks of the configuration block can be empty blocks; when the consensus of the preset number of empty blocks is completed, the configuration blocks can be submitted for execution. Since the subsequent blocks of the allocation block are empty blocks, voting the allocation block again in the voting consensus process of the empty blocks is equivalent to that of voting the allocation block again, and since no transaction exists in the empty blocks, the consensus process of the empty blocks is equivalent to that of the transaction after the allocation block.
In one possible implementation, the configuration block may include identification information from which the node device may determine the block as a configuration block. If the node device identifies the configuration block, it indicates that the common cluster may change the cluster state. In order to ensure the cluster consistency of the blockchain system before and after the change of the cluster state, the node equipment can submit and execute the configuration area block after meeting the submitting and executing conditions of the configuration area block.
If the allocation block is committed to execute, a new consensus state may be reached in the blockchain. Checkpoint information may be generated based on the consensus status. Each node in the consensus cluster can generate checkpoint information, then each node can broadcast the generated checkpoint information to other nodes in the consensus cluster, and each node can count the number of other checkpoint information with the consensus state consistent with the checkpoint information of the node; if the number is greater than the preset value, it may be indicated that there are other nodes with preset numbers consistent with the current consensus state of the node. At this point, the cluster consistency check of the blockchain system may be considered to pass. The checkpointed state can be generated at this time, which is the cluster state of the consensus cluster after the completion of the execution of the configuration block. The checkpointed state may be saved on the chain so that the cluster state of the consensus cluster may be saved during the cluster change.
In one possible implementation, the checkpoint information may include a generation version number of the consensus cluster from which checkpoint information for other nodes of the consensus cluster in the same generation may be determined for the received checkpoint information. When the checkpoint information of other nodes in the consensus cluster of the same generation reaches a preset number, the checkpoint information can be determined to agree.
Generating the check point state is equivalent to performing a check on the previous block in the node device, and the block consensus process and the block execution process are not related to each other, that is, the executed state is commonly known without waiting for the block pre-execution in the node, but the block can be directly commonly known, and the check point state can be generated at intervals or after the configuration of the block occurs, so that the cluster state is commonly known.
FIG. 2 is a schematic diagram of a consensus cluster generation checkpoint provided in an embodiment of the present application, B in FIG. 2 k ，B k ' are all received blocks, B k And B is connected with k ' are different branches that have the same parent block. Referring to fig. 2, a node may receive block B 1 、B 1 ’、B 2 、B 2 ’、B 3 、B k 、B k ' etc. then after each block is received, the block may not be verified as block B k After successful generation of the check state, the final coherency path may be determined to be B 0 -B 1 -B 2 -...-B k The final state is S k B can be discarded at this time 1 ’、B 2 ’、B 2 "AND B 3 '. In other words, in the embodiment of the present application, checkpoints may be generated every preset number of blocks, so as to determine a corresponding reference state, and discard the erroneous blocks; when a configuration block is detected, a checkpointed state based on the configuration block needs to be generated, which is equivalent to confirming the cluster state in the node device.
S102, if the check point state comprises cluster change information, discarding the consensus data of a target block, wherein the target block is a blank block after the allocation block.
The execution of the configuration transaction may or may not be successful. If the configuration transaction is successfully performed, the cluster state information may be changed, e.g., cluster configuration data may be changed. The cluster configuration data may include the number of nodes of the consensus cluster, the node public key, the version of the consensus protocol, etc. After the configuration block is executed, if the cluster configuration data is updated, a status flag may be generated; by reading the status flag, the block height of the cluster configuration data update can be determined, and the status flag can be queried based on the current execution height, so that whether the cluster state is modified by the configuration block corresponding to the check point can be easily identified.
In one possible implementation, it may be determined whether the consensus cluster has changed by the number of nodes of the consensus cluster. The node device may determine whether the number of nodes in the checkpointed state is modified by the configuration block; if the number of nodes in the checkpointed state is modified by the configuration block, it may be determined that the checkpointed state includes cluster change information, that is, that the common cluster has changed after the execution of the configuration block is completed.
If the trusted cluster change is determined, the shared data of the target block after the allocated block may be discarded, and the target block may be an empty block after the allocated block that does not include the transaction. Since the consensus process and the execution process of the blocks are irrelevant, that is, during the execution process of the allocated blocks, the blocks after the allocated blocks are still consensus by using the old consensus cluster; since the blocks following the allocated blocks should be shared using the new shared clusters after the change, the shared data of the empty blocks following the allocated blocks can be deleted, which corresponds to the deletion of the shared data obtained using the old shared clusters after the allocation of the blocks.
S103, changing the consensus cluster based on the check point state.
The cluster change information can be acquired based on the check point state, the cluster change information can be carried in configuration transaction, the change information of the next generation of cluster can be determined based on the cluster change information, and after the configuration transaction is executed, the addition and deletion of the common nodes in the common trusted cluster can be realized according to the cluster change information. After the addition and deletion of the consensus nodes, the node equipment needs to synchronize the cluster state to finish cluster change.
After determining that the configuration block may change the consensus cluster, the checkpointed state may be taken as an initial state of the consensus cluster of the next generation, and the following consensus may be continued based on the initial state. For example, a common initial block may be established based on a checkpointed state, and the state on the chain corresponding to the common initial block is the checkpointed state confirmed after the execution of the configuration block is completed. The common identification initial block is used as the initial block of the common identification cluster of the next generation, so that the initial on-chain state corresponding to the next generation is the on-chain state after the execution of the configuration block is completed, and the consistency of the common identification state data and the data before the change is ensured after the cluster change and the data are not lost. Based on the initial block of consensus, the consensus of the transaction after the block is configured can be started, i.e. the transaction consensus can be continued using the cluster state after the change is completed.
The consensus cluster may have a generation version number that may be updated when the consensus cluster changes. For example, the generation version number of the consensus cluster is 1; when one consensus node is added in the consensus cluster, the consensus cluster is updated to the next generation, and the generation version number can be 2.
FIG. 3 is a schematic diagram of a common cluster modification according to an embodiment of the present application, as shown in FIG. 3, S 0 、S 1 、S c1 、S c1+1 、S c1+2 、S c2 、S c2+1 The consensus state, which is a consensus cluster, may be stored on a chain of blockchains. As shown in FIG. 3, S 1 For block B 1 Executing the consensus state of the consensus cluster of the first generation after completion, S c1 For block B c1 The consensus state of the consensus cluster of the first generation after completion is executed. The state on the chain of the blockchain cannot be changed and can be visible to the blockchain nodes, so that the agreed cluster state can be stored on the chain, and then the corresponding consensus state can be directly obtained from the chain after the consensus cluster is changed, so that the consensus state before the consensus cluster is changed can be ensured to be consistent after the consensus cluster is changed. For example, non-consensus nodes in a blockchain may acquire the latest cluster state directly from the chain, thereby keeping the nodes in the latest cluster state.
Epoch=1 in fig. 3, indicating that the consensus cluster is in the first generation, and B when the consensus cluster is in the first generation 0 Is a consensus initial block, and the corresponding state is S 0 The method comprises the steps of carrying out a first treatment on the surface of the In block B 1 Execution ofAfter that, the corresponding state S is obtained 1 . The node device may then acquire B 1 The following blocks are identified and executed. After the node device acquires the configuration block, the common cluster can be changed based on the configuration block. B in FIG. 3 c1 To configure a block, the node device may acquire two empty blocks B after the block is configured c1 '. Block B c1 And B c1 ' all adopt the first generation consensus cluster to carry out consensus, when two blocks B are c1 After' consensus is complete, node device may configure block B c1 Submitting an execution; if in the configuration block B c1 After execution is completed, the consensus cluster is changed to the second generation, and then the state S after execution of the configuration block is completed can be based on c1 Establishing an initial consensus block B of a second generation consensus cluster 0 After the cluster is changed, the consensus cluster of the next generation is subjected to the consensus of the subsequent blocks based on the final state of the consensus cluster of the previous generation. At this time, B after the block is allocated c1 ' consensus data can be discarded because its consensus is performed by the consensus cluster of the first generation, but in practice the consensus cluster has been changed to the second generation, while due to B c1 ' is a blank block, the consensus thereof does not relate to the consensus of the transaction, the consensus data is discarded, and the status error of the consensus cluster is not caused, therefore, B can be directly discarded c1 ' consensus data, and does not require the use of a consensus cluster pair B after a change c1 're-consensus'. B (B) c2 、B c2 ' all adopt the consensus cluster of the second generation to carry out consensus; if in the configuration block B c2 After execution is completed, the consensus cluster is changed to the third generation, and then the state S after execution of the configuration block is completed can be based on c2 Establishing an initial consensus region of a third generation consensus cluster, and configuring a void block B after the block c2 ' consensus data may be discarded.
If the checkpointed state does not include cluster change information, it may indicate that the configuration block is invalid, that is, the configuration block is not changed after execution, which may be caused by failure of execution of the configuration transaction, although other conditions may exist. In this case, the subsequent normal packaging process can be directly resumed, and the current consensus cluster is continuously used for consensus of the subsequent blocks.
Fig. 4 is a schematic diagram of a common cluster change failure according to an embodiment of the present application. As shown in FIG. 4, B c To arrange blocks B c And B c ' all adopt the first generation consensus cluster to carry out consensus, if the consensus cluster is failed to change, the following normal block B can be continued c+1 The first generation consensus cluster is adopted for consensus.
In this embodiment, after receiving the block, the node device does not need to perform execution verification, but after submitting the block, the execution module executes the transaction change therein, and generates a check point after execution is completed, so that only after configuring the block to execute, the check point result after execution needs to be waited, and the rest of time consensus and the execution flow are completely parallel. In addition, the blocks after the configuration blocks are empty blocks, and the normal packing flow is restored after the common-knowledge cluster is changed, so that after the configuration blocks are successfully executed to execute the change configuration, the next executed block containing the transaction is ensured to be commonly known by the new common-knowledge cluster.
Referring to fig. 5, a step flow diagram of a method for changing a consensus cluster provided in an embodiment of the present application is shown, which may specifically include the following steps:
s501, in the transaction packaging process, packaging configuration transactions containing a target mark field into the configuration block, wherein the target mark field is used for identifying and changing the consensus cluster.
The execution body in this embodiment is a master node of a consensus cluster, and the nodes of the consensus cluster may be computer devices, such as an electronic computer, a server, and the like, that deploy a blockchain network. A plurality of nodes may be included in the blockchain, and a master node may be included in the plurality of nodes.
The blockchain may resolve traffic by initiating and executing transactions, and a master node of the blockchain may receive transactions for traffic processing. The master node may package the received transactions into blocks, and batch processing of the transactions may be implemented based on the blocks.
When the block chain manager changes the consensus cluster, the configuration transaction can be sent to a master node in the block chain, and the configuration transaction can comprise the adding and deleting node information of the consensus cluster. After receiving the transaction sent by the blockchain manager, the master node may identify the transaction type of the transaction. If the master node identifies the transaction as a configuration transaction, after the configuration transaction is packed into a configuration block, the normal packing flow may be suspended such that the block following the configuration block is a null block. In one possible implementation, after the configuration block is packed, the master node may continue to pack, but no longer pack the transaction into the block, i.e., so that all blocks after the configuration block are empty blocks.
In another possible implementation, after the configuration blocks are packed, the master node may continue to pack the preset number of empty blocks, and after the preset number of empty blocks are packed, the packing process may be blocked, and the blocks are not packed any more. Illustratively, if the consistency validation principle of multi-round voting in a pipelined manner needs to be followed in a blockchain system, the number of empty blocks that need to be packed may be determined from the number of voting rounds. The number of empty blocks that need to be packed may be the number of voting rounds minus one. For example, if the consistency validation principle of three rounds of voting in a pipelined manner needs to be followed in a blockchain system, the master node may not package after packaging two empty blocks.
S502, broadcasting the configuration block to other node devices of the consensus cluster.
After the master node packages the blocks, the packaged blocks can be broadcast to all nodes in the consensus cluster, so that all nodes can receive corresponding transactions and execute the transactions in all nodes to solve the corresponding business. After the configuration blocks and the empty blocks are packed, the master node also broadcasts the configuration blocks and the empty blocks to all nodes of the consensus cluster.
The master node may broadcast the configuration block to other node devices in the consensus cluster, so that each node device may receive the configuration block, and perform consensus, commit, and the like on the configuration block. Each node device in the blockchain may acquire a block. The master node may obtain the self-packed blocks and the other nodes may receive the blocks from the master node. After obtaining the blocks, the node device may perform block consensus, and after completing configuring the blocks, may submit the configured blocks to execute. When the allocation block is submitted to be executed, the node device can continue to perform the consensus of the empty blocks after the allocation block, that is, the execution process and the consensus process of the block do not affect each other.
In one possible implementation, the blockchain may follow a consistency validation principle that performs multiple rounds of voting in a pipelined manner, that is, a preset number of blocks after the configuration block need to be voted to complete consistency validation before the configuration block is submitted for execution. The blocks received by each node in the consensus cluster are all packaged and sent by the master node. That is, each node receives the allocation block, and the received block is a null block. Each node may then, after completion of the consensus on the allocated block, consensus on a subsequent block, i.e., a null block, of the allocated block. If the consensus of the preset number of empty blocks after the configuration block is completed, the node may commit the configuration block.
Illustratively, the master node may package empty blocks after the configuration blocks are packaged, and commit execution may be performed on the configuration blocks after a preset number of empty blocks following the configuration blocks have been identified. In the process of configuring the block submission, the master node can continuously package the empty blocks, and each node can also continuously carry out the consensus of the empty blocks.
In another example, after the configuration blocks are packed, the master node may pack a preset number of empty blocks, and broadcast the preset number of empty blocks to other node devices, and then block the packing flow, i.e. neither pack empty blocks nor broadcast empty blocks to other nodes, but wait for whether the consensus cluster is changed and changed And if not, finishing. For example, if the execution of a block is committed to three rounds of voting, the master node may package two empty blocks after the completion of the configuration block packaging. After the two empty blocks are packed, the master node may block the packing process. The master node broadcasts two empty blocks into each node in the consensus cluster, which can consensus the received blocks. After the two empty blocks are commonly recognized by the nodes in the common recognition cluster, the execution can be submitted to the configuration block, and the execution result of the configuration block is waited. The consistency validation principle of three rounds of voting in a pipelined fashion may be followed in a blockchain system as shown in fig. 3. Thus, block B is configured c1 And may then include two empty blocks B c1 ' empty block, allocate block B c1 The consensus of (a) corresponds to a voting confirmation of the allocation block, and two empty blocks B after the allocation block c1 In the' consensus process, the configuration block is confirmed by voting twice again, and therefore, in the two empty blocks B c1 After' consensus is completed, it corresponds to the configuration block B c1 Consistency confirmation of three rounds of voting is completed, and the configuration block B can be subjected to c1 Commit execution is performed to make changes to the consensus cluster. Similarly, block B is configured c2 And may then include two empty blocks B c2 ' empty block, in two empty blocks B c2 After' consensus is complete, block B may be configured c2 Commit execution is performed to change the consensus cluster from the second generation to the third generation.
The consistency validation principle of three rounds of voting in a pipelined fashion may also be followed in the blockchain system of fig. 4. As shown in fig. 4, block B is configured c And may then include two empty blocks B c ' empty block, in two empty blocks B c ' configure block B may be performed c Is executed by the computer.
S503, if the configuration block is submitted to be executed, generating a check point state, wherein the configuration block comprises a configuration transaction for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed.
S504, if the check point state comprises cluster change information, discarding the consensus data of a target block, wherein the target block is a void block behind the allocation block.
S505, changing the consensus cluster based on the check point state.
S503 to S505 in this embodiment are similar to S101 to S103 in the previous embodiment, and reference is made to each other, which is not repeated here.
S506, if the check point state does not include the cluster change information or the consensus cluster change is completed, continuing to execute the transaction packaging process. After the execution of the configuration block is completed, the master node may continue to use the old consensus cluster or use the updated consensus cluster to perform the consensus of the block, at which time the master node may continue to execute the packaging transaction process and package a batch of transactions into one block. After packing the transactions into chunks, the master node may continue to broadcast the packed chunks to the nodes of the current consensus cluster to consensus and execute each transaction in the chunk in the consensus trusted cluster.
For example, if the checkpointed state does not include the cluster change information, it may indicate that the configuration block is invalid, for example, the configuration transaction fails to be executed or the configuration transaction does not include the cluster state change, at this time, the current consensus cluster may be used to continue the consensus of the transaction after the configuration block, at this time, the transaction packaging process may be resumed.
For example, if the consensus cluster change is complete, e.g., the configuration transaction includes a cluster state change and the configuration transaction is successfully performed, the consensus of the transaction after the configuration block may be performed using the consensus cluster after the change is complete, at which point the transaction packaging process may resume.
In addition, upon consensus cluster changes, cluster change proofs may be generated. If the check point state includes the cluster change information, a cluster change certificate is generated, and the cluster change certificate may include the changed cluster information corresponding to the configuration block and voting information for each node device to vote on the configuration block. For example, the cluster change certificate may include node information in the changed cluster, a consensus protocol, a public key of each node, and a plurality of node information for performing a confirmation vote on the change of the cluster at the time of the change. Based on the cluster change proving, the validity of the cluster change can be proving, which is equivalent to verifying whether the state after the change of the cluster is legal.
In one possible implementation, a cluster change certificate may be generated by the cluster at each change, and each cluster change certificate may form a certificate list, and each change of the cluster may be verified based on the certificate list to determine whether the current cluster state is correct.
Cluster change attestation may be used to perform cluster state synchronization. The node device may receive a cluster state synchronization request of other node devices, return current cluster state information and a cluster change proof of the consensus cluster to the other node devices, and the other node devices may verify whether the current cluster state information is legal according to the cluster change proof, and if the current cluster state is legal according to the cluster change proof, may synchronize the current cluster state.
In one possible implementation manner, the cluster change proof may be stored in association with a corresponding on-chain state, and when a newly added consensus node exists in the consensus cluster, the corresponding cluster state and the cluster change proof may be directly obtained from the chain, so that the cluster state is verified according to the cluster change proof, and after the verification is passed, the cluster state may be directly synchronized.
In one possible implementation, the newly added consensus node may receive a message sent by other consensus nodes in the consensus trusted cluster, where the message may carry a generation version number of the other consensus nodes. The newly added consensus node can determine the latest generation version number from the received message, and send a cluster generation synchronization request to the node corresponding to the latest generation version number. Then, the cluster state and cluster change evidence returned by the node can be received, and whether the cluster state is correct or not can be verified based on the cluster change evidence; when the cluster state is correct, the cluster state may be synchronized.
In one possible implementation, when the generation version number of the message received by the other node device is lower than the generation version number of the current generation, the current cluster state and cluster change proof may be returned to the other node device, so that the other node device may synchronize the cluster state according to the cluster state and the cluster change proof.
In one possible approach, other non-consensus nodes may be included in the blockchain in addition to the consensus nodes, and these nodes may directly pull the cluster state of the consensus nodes after the cluster change proof verification passes.
In this embodiment, after the package is performed to the configuration block, the normal transaction package flow may be suspended; after the common identification cluster is changed or the configuration block is determined not to change the common identification cluster, the packaging process can be continued, so that the block after the configuration block can be an empty block which does not contain transactions, and the common identification of the empty block does not involve the common identification of the transactions, so that after the common identification cluster is changed, all the blocks which contain transactions after the configuration block can be subjected to common identification by using the updated common identification cluster.
It should be noted that, the sequence number of each step in the above embodiment does not mean the sequence of execution sequence, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.
Referring to fig. 6, a schematic diagram of a modification apparatus of a consensus cluster provided in an embodiment of the present application is shown, where the apparatus may be applied to a node device, and specifically may include a generating module 61, a discarding module 62, and a modification module 63, where:
A generating module 61, configured to generate a checkpointed state if a configuration block is submitted to be executed, where the configuration block includes a configuration transaction for changing a consensus cluster, and the checkpointed state is a state of the consensus cluster after the configuration block is executed;
a discarding module 62, configured to discard consensus data of a target block, where the target block is a void block after the configuration block, if the checkpointed state includes cluster change information;
a changing module 63, configured to change the consensus cluster based on the checkpointed state.
In one possible implementation manner, the apparatus further includes:
a determining module for determining whether the number of nodes in the checkpointed state is modified by the configuration block;
and the judging module is used for determining that the check point state comprises the cluster change information if the number of the nodes is modified by the configuration block.
In one possible implementation manner, if the node device is a master node device, the apparatus further includes:
the configuration block packaging module is used for packaging configuration transactions containing target mark fields into the configuration block in the transaction packaging process, wherein the target mark fields are used for identifying and changing the consensus cluster;
And the broadcasting module is used for broadcasting the configuration block to other node devices of the consensus cluster, and the configuration block is submitted to be executed by the master node device and the other node devices respectively.
In one possible implementation manner, if the node device is a master node device, the apparatus further includes:
and the continuing packaging module is used for continuing to execute the transaction packaging process if the check point state does not comprise the cluster change information or the consensus cluster change is completed.
In one possible implementation manner, the apparatus may include:
the cluster change evidence generation module is used for generating a cluster change evidence, and the cluster change evidence comprises changed consensus cluster information and voting information for each node device to vote on the configuration block;
and the cluster state synchronization module is used for returning the current cluster state information of the common identification cluster and the cluster change evidence to other node equipment if a cluster state synchronization request of the other node equipment is received, and the other node equipment is used for verifying whether the current cluster state information is legal or not according to the cluster change evidence.
In one possible implementation manner, the changing module may include:
a common initial block establishing sub-module, configured to establish a common initial block according to the checkpointed state, where the common initial block corresponds to the on-chain state of the configured block after execution is completed;
an initial block determining sub-module, configured to use the consensus initial block as an initial block of a consensus cluster of a next generation;
and the consensus sub-module is used for adopting the initial block to start consensus of transactions in each block after the allocation block.
In one possible implementation manner, the apparatus further includes:
the consensus module is used for consensus the configuration block and the target block based on the current consensus cluster;
and the submitting module is used for submitting and executing the configuration blocks if the preset number of target blocks are commonly known.
For the device embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference should be made to the description of the method embodiments.
Fig. 7 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 7, the computer device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, the processor 70 implementing the steps in any of the various method embodiments described above when executing the computer program 72.
The computer device 7 may be a computing device such as a desktop computer, a notebook computer, a palm computer, a cloud computer, etc. The computer device may include, but is not limited to, a processor 70, a memory 71. It will be appreciated by those skilled in the art that fig. 7 is merely an example of the computer device 7 and is not limiting of the computer device 7, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.
The processor 70 may be a central processing unit (Central Processing Unit, CPU) and the processor 70 may be other general purpose processors, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 71 may in some embodiments be an internal storage unit of the computer device 7, such as a hard disk or a memory of the computer device 7. The memory 71 may in other embodiments also be an external storage device of the computer device 7, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which are provided on the computer device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the computer device 7. The memory 71 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs, etc., such as program codes of the computer program. The memory 71 may also be used for temporarily storing data that has been output or is to be output.
Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps that may implement the various method embodiments described above.
The present embodiments provide a computer program product which, when run on a computer device, causes the computer device to perform the steps that can be carried out in the various method embodiments described above.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting. Although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Claims (10)
1. A method of altering a consensus cluster, applied to a node device, the method comprising:
If the configuration block is submitted to be executed, generating a check point state, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed;
discarding the consensus data of a target block, which is a void block after the allocation block, if the checkpointed state includes cluster change information;
and changing the consensus cluster based on the checkpoint state.
2. The method of claim 1, wherein after generating a checkpointed state if the configuration block is committed to execute, the method further comprises:
determining whether the number of nodes in the checkpointed state is modified by the configuration block;
if the number of nodes is modified by the configuration block, determining that the checkpointed state includes the cluster change information.
3. The method of claim 1, wherein if the node device is a master node device, the method further comprises:
and in the transaction packaging process, packaging configuration transactions containing a target mark field into the configuration block, wherein the target mark field is used for identifying and changing the consensus cluster.
4. A method as claimed in claim 3, wherein the method further comprises:
and if the check point state does not comprise the cluster change information or the consensus cluster change is completed, continuing to execute the transaction packaging process.
5. The method of any one of claims 1-4, wherein the method further comprises:
generating a cluster change proof, wherein the cluster change proof comprises changed consensus cluster information and voting information of each node device for voting the configuration block;
and if a cluster state synchronization request of other node equipment is received, returning the current cluster state information of the consensus cluster and the cluster change evidence to the other node equipment, wherein the other node equipment is used for verifying whether the current cluster state information is legal or not according to the cluster change evidence.
6. A method according to any of claims 1-3, wherein said altering the consensus cluster based on the checkpointed state comprises:
establishing a consensus initial block according to the check point state;
taking the consensus initial block as an initial block of a consensus cluster of the next generation;
Based on the initial block, a consensus of transactions in blocks subsequent to the configured block is initiated.
7. The method of claim 1, wherein before the configuration block is committed to execution, the method further comprises:
based on the current consensus cluster, consensus is carried out on the configuration block and the target block;
and submitting and executing the configuration blocks if the preset number of target blocks are completed in consensus.
8. A changing apparatus of a consensus cluster, applied to a node device, the apparatus comprising:
the generation module is used for generating a check point state if the configuration block is submitted to be executed, wherein the configuration block comprises configuration transactions for changing the consensus cluster, and the check point state is the state of the consensus cluster after the configuration block is executed;
the discarding module is configured to discard consensus data of a target block if the checkpointed state includes cluster change information, where the target block is a void block after the allocation block;
and the changing module is used for changing the consensus cluster based on the check point state.
9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1-7 when executing the computer program.
10. A computer readable storage medium storing a computer program, which when executed by a processor implements the method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211603619.2A CN116009940A (en) | 2022-12-13 | 2022-12-13 | Method, device, computer equipment and medium for changing consensus cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211603619.2A CN116009940A (en) | 2022-12-13 | 2022-12-13 | Method, device, computer equipment and medium for changing consensus cluster |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116009940A true CN116009940A (en) | 2023-04-25 |
Family
ID=86027452
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211603619.2A Pending CN116009940A (en) | 2022-12-13 | 2022-12-13 | Method, device, computer equipment and medium for changing consensus cluster |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116009940A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116723200A (en) * | 2023-08-11 | 2023-09-08 | 杭州趣链科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
-
2022
- 2022-12-13 CN CN202211603619.2A patent/CN116009940A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116723200A (en) * | 2023-08-11 | 2023-09-08 | 杭州趣链科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
| CN116723200B (en) * | 2023-08-11 | 2023-11-10 | 武汉趣链数字科技有限公司 | Cluster changing method and device, electronic equipment and computer readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Dang et al. | Towards scaling blockchain systems via sharding | |
| US11249947B2 (en) | Distributed digital ledger transaction network for flexible, lazy deletion of data stored within an authenticated data structure | |
| US20230161756A1 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| US20230116348A1 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| CN108648078B (en) | Transaction preprocessing method and device and electronic equipment | |
| CN109815373B (en) | Data storage control method and device, server and readable storage medium | |
| US11405204B2 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| US20200394648A1 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| CN110808838A (en) | Alliance chain-oriented fragmentation method | |
| WO2023184881A1 (en) | Proposal consensus execution method, blockchain system, device and storage medium | |
| EP4071648A1 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| CN115225639B (en) | Changing method and device for consensus trusted cluster, computer equipment and medium | |
| US20200394177A1 (en) | Scalable, secure, efficient, and adaptable distributed digital ledger transaction network | |
| CN116009940A (en) | Method, device, computer equipment and medium for changing consensus cluster | |
| Blackshear et al. | Sui lutris: A blockchain combining broadcast and consensus | |
| WO2023040453A1 (en) | Transaction information processing method and apparatus | |
| CN116710919A (en) | Block chain machine network acceleration engine | |
| CN114119242A (en) | Alliance link performance optimization method and device based on self-adaptive window fragmentation | |
| CN115438053A (en) | Block storage method, block chain system, equipment and storage medium | |
| Arun | Scalable Byzantine State Machine Replication: Designs, Techniques, and Implementations | |
| Arun et al. | Revamping Byzantine Fault Tolerant State Machine Replication with Decentralization, Trusted Execution, and Practical Transformations | |
| CN112598518A (en) | Processing method for supporting cross-chain atomic transaction | |
| JP2023547817A (en) | Blockchain machine network acceleration engine | |
| CN112150286A (en) | Transaction processing method and device based on block chain, electronic equipment and storage medium | |
| Carr et al. | Towards Formal Verification of HotStuff-based Byzantine Fault Tolerant Consensus in Agda: Extended Version |
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 |