Blockchain node control method and apparatus, computer device, and storage medium

Abstract

The embodiments of the present specification provide a consortium chain node control method and device, computer equipment and a storage medium. The method comprises: in the case where the new master node detects that a specified delay time is reached, obtaining node state information of a non-new master node in a blockchain network; in the case where it is determined that a specified condition is met based on the obtained node state information, if the new master node has a target block, broadcasting the target block to the non-new master node in the blockchain network, so that at least part of the nodes in the blockchain network are rolled back or the target block is recorded to the maintained ledger; wherein the target block is packaged by the new master node after receiving a transaction. In this way, the stability of the consortium chain can be improved.

Description

Technical Field

[0001] The embodiments described in this specification relate to the field of blockchain technology, specifically to a consortium blockchain node control method, apparatus, computer equipment, and storage medium. Background Technology

[0002] A consortium blockchain is a distributed ledger system based on blockchain technology. It is a blockchain network composed of multiple nodes, including master nodes and slave nodes. Multiple nodes maintain the same ledger data locally through a consensus mechanism to ensure the consistency and security of the ledger data.

[0003] However, due to network jitter or node uncertainty, the entire blockchain network may split into multiple parts, a phenomenon known as network partitioning. This can cause some nodes in a consortium blockchain to be unable to communicate with other nodes or reach consensus, resulting in ineffective synchronization between nodes. Related technologies typically involve manual intervention after resolving network partitioning to enable synchronization between nodes; however, this approach is inefficient.

[0004] Therefore, there is an urgent need to provide a method for controlling consortium blockchain nodes to promptly restore synchronization between nodes after a network partition occurs, thereby improving the stability of the consortium blockchain. Summary of the Invention

[0005] In view of this, various embodiments of this specification aim to provide a consortium blockchain node control method, apparatus, computer device, and storage medium to improve the stability of the consortium blockchain.

[0006] This specification provides a consortium blockchain node control method, the method comprising: when a new master node detects that a specified delay time has been reached, acquiring node status information of non-new master nodes in the blockchain network; wherein, the specified delay time is a specified duration for the new master node to become a master node; and, if a specified condition is met based on the acquired node status information, if the new master node has a target block, broadcasting the target block to the non-new master nodes in the blockchain network, so that at least some nodes in the blockchain network may roll back or record the target block in the maintained ledger; wherein, the target block is obtained by the new master node after receiving transactions and packaging them.

[0007] Further, the node status information includes the block height corresponding to the non-new master node, the block pool status, and the number of nodes of the non-new master node; the specified conditions are determined by the following methods: the number of non-new master nodes obtained by the new master node exceeds a specified number; the block height of the non-new master node obtained by the new master node is less than or equal to the block height of the new master node; wherein, the block height is the block number corresponding to the latest block in the node; and the block pool status of the non-new master node obtained by the new master node is idle.

[0008] Furthermore, the method further includes: if the previous block hash in the target block is not equal to the current hash of the latest current block in the non-new master node when the non-new master node receives the target block, then if the latest current block is obtained by the non-new master node, the non-new master node rolls back the latest current block.

[0009] Furthermore, the method further includes: if the latest current block is not packaged by the non-new master node, and if there are a specified number of nodes with the same block in the blockchain network, the non-new master node will not roll back; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

[0010] Furthermore, the method also includes: if there are no specified number of nodes with the same block in the blockchain network, the non-new master node rolls back the latest current block.

[0011] Furthermore, the method further includes: upon receiving the target block, if the previous block hash in the target block is equal to the current hash of the latest current block in the non-new master node, then the non-new master node records the target block to the maintained ledger; wherein the non-new master node is an old master node or a slave node.

[0012] This specification provides a consortium blockchain node control method, the method comprising: upon detecting that the current node has been converted from a slave node to a master node, if a specified delay time has been reached, acquiring node status information of non-current nodes in the blockchain network; wherein the specified delay time is a specified duration for the current node to become the master node; and if, based on the acquired node status information, it is determined that specified conditions are met, if a target block exists, broadcasting the target block to non-current nodes in the blockchain network, so that at least some nodes in the blockchain network may roll back or record the target block in the maintained ledger; wherein the target block is obtained by the current node after receiving a transaction.

[0013] This specification provides a consortium blockchain node control method, the method comprising: upon receiving a target block, if the hash of the previous block in the target block is not equal to the current hash of the latest current block in the current node, then if the latest current block is obtained by the current node, the latest current block is rolled back.

[0014] This specification provides a consortium blockchain node control device, comprising: a node status acquisition module, configured to acquire node status information of non-current nodes in the blockchain network when a current node is detected to have transitioned from a slave node to a master node, provided that a specified delay time has elapsed; wherein the specified delay time is a specified duration for the current node to become the master node; and a target block sending module, configured to broadcast a target block to non-current nodes in the blockchain network if a target block exists, provided that a specified condition is met based on the acquired node status information, so that at least some nodes in the blockchain network may roll back or record the target block in the maintained ledger; wherein the target block is obtained by the current node after receiving a transaction.

[0015] This specification provides a consortium blockchain node control device, the device comprising: a target block receiving module, configured to, upon receiving the target block, if the hash of the previous block in the target block is not equal to the current hash of the latest current block in the current node, then roll back the latest current block if the latest current block was obtained by the current node.

[0016] This specification provides a computer device including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the consortium blockchain node control method described in any of the above embodiments.

[0017] This specification provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the consortium blockchain node control method described in any of the above embodiments.

[0018] This specification provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the consortium blockchain node control method described in any of the above embodiments.

[0019] In several implementations provided in this specification, when a new master node detects that the time it has been in power as a master node has reached a specified delay, the node status information of non-new master nodes in the blockchain network is obtained. Based on the obtained node status information, if the specified conditions are met, and if the new master node has a target block, the target block is broadcast to the non-new master nodes in the blockchain network. This allows at least some nodes in the blockchain network to roll back or record the target block in the maintained ledger, thereby improving the stability of the consortium blockchain. Attached Figure Description

[0020] Figure 1 A schematic diagram illustrating the application scenario of the consortium blockchain node control method provided in the embodiments of this specification;

[0021] Figure 2 A flowchart illustrating the consortium blockchain node control method provided in the embodiments of this specification;

[0022] Figure 3 A schematic diagram illustrating the determination of the block pool status provided for the implementation of this specification;

[0023] Figure 4 A flowchart illustrating the consortium blockchain node control method provided in the embodiments of this specification;

[0024] Figure 5 A schematic diagram of a consortium blockchain node control device provided for an embodiment of this specification;

[0025] Figure 6 A schematic diagram of a computer device provided for an embodiment of this specification. Detailed Implementation

[0026] To enable those skilled in the art to better understand the solutions described in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all non-current embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0027] A consortium blockchain can refer to a blockchain network consisting of multiple nodes, including master nodes and slave nodes. Multiple nodes maintain the same ledger data locally through the RAFT consensus algorithm, thereby ensuring the consistency and security of the ledger data.

[0028] Due to network jitter or node uncertainty, the entire blockchain network may experience network partitioning, also known as split-brain. When this occurs, nodes may elect multiple master nodes in different partitions, resulting in multiple master nodes simultaneously producing blocks and broadcasting blocks with the same block number to the entire blockchain network, causing a blockchain fork. Once the network recovers or the partitioning event ends, some slave nodes may be unable to effectively synchronize with blocks produced by certain master nodes, leading to node stagnation and other problems that severely impact the correctness and security of the consortium blockchain.

[0029] In related technologies, the usual approach is to manually assess and process the situation after the network is restored, but manual intervention is inefficient, prone to errors, and difficult to restore normal synchronization between nodes in a timely manner, thus failing to meet actual needs.

[0030] Therefore, it is necessary to provide a consortium blockchain node control method. First, when the new master node detects that a specified delay time has been reached, it obtains the node status information of non-new master nodes in the blockchain network, where the specified delay time is the specified duration for the new master node to become the master node. Next, based on the obtained node status information, if it is determined that specified conditions are met, and if the new master node has a target block, it broadcasts the target block to the non-new master nodes in the blockchain network, so that at least some nodes in the blockchain network can roll back or record the target block to the ledger they are maintaining. The target block is obtained by the new master node after receiving transactions and packaging them. In this way, synchronization between nodes can be restored in a timely manner after a network partition occurs, improving the stability of the consortium blockchain.

[0031] Please see Figure 1 This specification provides an example application scenario for a consortium blockchain node control method. This example application scenario can be a consortium blockchain node control system, which may include multiple peer nodes in a blockchain network and ledgers maintained by each node. Any of the multiple nodes can be a master node or a slave node. The master node is also called the leader node, and the slave node is also called the follower node.

[0032] Specifically, in a consortium blockchain node control system, slave nodes in the blockchain network can broadcast transactions received within the network. This allows the master node to package the received transactions into a corresponding block and then broadcast the block back to the blockchain network for consensus verification. The master node can also package transactions received from external sources or from slave nodes broadcasting transactions into a block and broadcast it back to the blockchain network for consensus verification. After consensus verification, the block is recorded in the ledgers maintained by each node in the blockchain network, or it allows some nodes in the blockchain network to determine whether a rollback is necessary based on the block.

[0033] For example, nodes in a blockchain network can have block pools, enabling block management based on these pools. For instance, a block pool can receive blocks broadcast by other nodes in the blockchain network for consensus verification, can roll back a block number when a block rollback is needed, and can monitor and prepare to receive new blocks in real time.

[0034] For example, nodes in a blockchain network can have transaction pools, enabling transaction management based on these pools. For instance, a node can receive external transactions from the pool, periodically package transactions from the pool to obtain corresponding blocks, broadcast transactions from the pool to the blockchain network, and reclaim transactions from a block after a block rollback. As an example, a master node can receive external transactions from the pool, periodically package transactions from the pool to obtain corresponding blocks, and reclaim transactions from a block after a block rollback. Similarly, a slave node can receive external transactions from the pool and broadcast transactions from the pool to the blockchain network.

[0035] This specification provides a method for controlling consortium blockchain nodes. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a consortium blockchain node control method provided in this embodiment. This embodiment provides the method operation steps shown in the flowchart, but based on conventional or non-creative labor, it may include more or fewer operation steps. The order of steps listed in this embodiment is merely one possible execution order among many, and does not represent the only possible execution order. In actual system or server products, the method can be executed sequentially as shown in the embodiment or in parallel (e.g., in a parallel processor or multi-threaded processing environment). This consortium blockchain node control method can be applied to consortium blockchain node control systems, specifically as follows... Figure 2 As shown, the consortium blockchain node control method may include the following steps.

[0036] Step S210: If the new master node detects that the specified delay time has been reached, obtain the node status information of non-new master nodes in the blockchain network; wherein, the specified delay time is the specified duration for the new master node to become the master node.

[0037] In some cases, when a blockchain network experiences a split-brain event due to network instability or node uncertainty, a change of leadership occurs. During this process, multiple master nodes may emerge, which can be categorized as old and new master nodes. Typically, blockchain networks do not experience frequent changes of leadership. After a split-brain event, the old master node's block pool may still contain blocks that are being executed but have not yet been broadcast to the network. Therefore, the new master node can delay block synchronization for a period of time. This allows the new master node to reduce the number of unbroadcast blocks remaining in the old master node's block pool before synchronization, increasing the likelihood that the new master node will synchronize blocks after the split-brain event recovers within a shorter period, thus reducing the probability of a block fork.

[0038] Specifically, when a node in the blockchain network is detected to have changed from a slave node to a master node, the node can be identified as the new master node. The new master node can keep track of the duration of its master status and continuously determine whether the duration of its master status has reached a specified delay time. If the new master node detects that the duration of its master status has reached the specified delay time, it can obtain the node status information of non-new master nodes in the blockchain network.

[0039] Among them, the node status information of non-new master nodes can be used to determine whether the synchronization time has been reached.

[0040] Specifically, a non-new master node can be a slave node and / or an old master node. That is to say, when the new master node detects that a specified delay time has been reached, the new master node can obtain the node status information of slave nodes in the blockchain network, the node status information of old master nodes in the blockchain network, and the node status information of both slave nodes and old master nodes in the blockchain network.

[0041] Step S220: If the new master node has a target block, and the specified conditions are met based on the obtained node status information, the target block is broadcast to the non-new master nodes in the blockchain network so that at least some nodes in the blockchain network can roll back or record the target block to the maintained ledger; wherein, the target block is obtained by the new master node after receiving the transaction.

[0042] The specified conditions can be used to determine whether the synchronization timing has been reached by combining the node status information of the non-new master node. If the node status information of the non-new master node meets the specified conditions, it means that the new master node has reached the synchronization timing; otherwise, it means that the new master node has not reached the synchronization timing.

[0043] In some cases, the block pool in a new master node can store a target block, which can be packaged by the new master node after receiving a transaction.

[0044] Block rollback, also known as block rollback, can refer to restoring the ledger maintained by a node to a specific point in time in order to correct errors or restore it to a normal state.

[0045] Based on the obtained node status information and the determination that specified conditions are met, the new master node can decide that the synchronization time has been reached. This reduces the possibility of multiple block spikes in the blockchain network during block synchronization by the new master node. Simultaneously, it can detect whether the target block exists in the new master node's block pool. If the target block exists, it can be broadcast to non-new master nodes in the blockchain network. These non-new master nodes can then determine whether to roll back or record the target block in their maintained ledger. Thus, after the new master node broadcasts the target block to the blockchain network, one or more non-new master nodes can either roll back the block or write it to their maintained ledger.

[0046] In the above implementation, the new master node, upon detecting a specified delay time, obtains the node status information of the non-new master nodes. When the node status information meets specified conditions, it broadcasts the target block to the non-new master nodes in the blockchain network. This enables the nodes in the blockchain network to perform rollback self-healing or record the target block to the ledger they maintain. In this way, after a network partition phenomenon generates multiple master nodes, the probability of block forks can be reduced, effective synchronization between nodes can be restored in a timely manner, the split-brain self-healing of the consortium blockchain can be achieved, and the stability of the consortium blockchain can be improved.

[0047] In some implementations, node status information may include the block height corresponding to the non-new master node, the block pool status, and the number of non-new master nodes. Specifically, the following methods can be used to determine if specified conditions are met:

[0048] (1) The number of non-new master nodes acquired by the new master node exceeds the specified number.

[0049] The specified quantity can refer to a specified proportion of the number of nodes in the blockchain network. For example, this specified proportion could be 50%, two-thirds, or any other proportion depending on the actual situation.

[0050] (2) The block height of the non-new master node obtained by the new master node is less than or equal to the block height of the new master node.

[0051] The block height can be the block number corresponding to the latest block in the node. For example, any node can maintain a corresponding ledger, and the block number corresponding to a block can refer to the page number of that block in the ledger.

[0052] (3) The block pool status of the new master node obtained from the non-new master node is idle.

[0053] The block pool status can include idle and busy states. For example, please refer to... Figure 3 , Figure 3 This diagram illustrates the determination of the block pool status. The idle state of the block pool can mean that there are no blocks being executed or waiting to be executed in the block pool, while the busy state can mean that there are blocks being executed or waiting to be executed in the block pool.

[0054] In the above implementation, the new master node can quickly and automatically identify the block synchronization time after a specified delay time by acquiring the number of nodes, the block height of each node, and the block pool status of each node, combined with preset specified conditions, thereby reducing the probability of block forks.

[0055] In some implementations, the consortium blockchain node control method may further include: upon receiving a target block, if the hash of the previous block in the target block is equal to the current hash of the latest current block in the non-new master node, then the non-new master node records the target block to the ledger it maintains; wherein the non-new master node is an old master node or a slave node.

[0056] Specifically, please refer to Figure 4 When a slave node or the old master node receives a target block broadcast by the new master node, it can compare the previous block hash in the target block with the current hash of the latest current block in its own node. If the previous block hash in the target block is equal to the current hash of the latest current block in its own node, then the node can write the target block into the ledger it maintains.

[0057] In some implementations, the consortium blockchain node control method may further include: if a non-new master node receives a target block, and if the hash of the previous block in the target block is not equal to the current hash of the latest current block in the non-new master node, then if the latest current block was obtained by the non-new master node, the non-new master node shall roll back the latest current block.

[0058] For details, please continue reading Figure 4 If a non-new master node detects that the current node is a slave node and receives the target block broadcast by the new master node, it can compare the hash of the previous block in the target block with the current hash of the current node's latest current block. If they are not equal, it can further determine whether the current node's latest current block was generated by the current node itself. If it was generated by the current node, the current node's latest current block can be rolled back by one block. For example, by determining whether the current node's latest current block was generated by the current node itself, it can indirectly determine whether the current node is the old master node or a slave node. If the current node's latest current block was generated by the current node itself, it means that the current node is the old master node; if the current node's latest current block was not generated by the current node itself, it means that the current node is a slave node.

[0059] In some implementations, the consortium blockchain node control method may further include: if the latest current block is not packaged by a non-new master node, and there are a specified number of nodes with the same block in the blockchain network, the non-new master node will not roll back; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

[0060] In this context, the existence of a specified number of nodes sharing the same block in the blockchain network means that the current hash of the latest current block of this node is equal to the current hash of a specified block of the majority of nodes sharing the same block in the blockchain network. In other words, it can be determined that the latest current block of this node is correct.

[0061] For details, please continue reading Figure 4 If a non-new master node receives a target block broadcast by a new master node, and the hash of the previous block in the target block is not equal to the current hash of the latest current block of this node, and if the latest current block of this node is not obtained by this node, it can continue to determine whether there are a specified number of nodes with the same block in the blockchain network. If they exist, it can not roll back and discard the target block.

[0062] In some implementations, please refer to [the relevant documentation]. Figure 4 The consortium blockchain node control method may also include: if a specified number of nodes sharing the same block do not exist in the blockchain network, the non-new master node will roll back the latest current block. Specifically, one block can be rolled back.

[0063] This specification provides a consortium blockchain node control method, which can be applied to a new master node in a consortium blockchain node control system. Please continue reading. Figure 4The consortium blockchain node control method may include the following steps.

[0064] Step S501: If the current node is detected to have changed from a slave node to a master node, and a specified delay time is reached, obtain the node status information of non-current nodes in the blockchain network; wherein, the specified delay time is the specified duration for the current node to become a master node.

[0065] Step S503: If a target block exists, and the specified conditions are met based on the obtained node state information, the target block is broadcast to non-current nodes in the blockchain network so that at least some nodes in the blockchain network can roll back or record the target block to the maintained ledger; wherein, the target block is obtained by the current node after receiving the transaction.

[0066] Specifically, the node status information includes the block height corresponding to the non-new master node, the block pool status, and the number of non-new master nodes. The following conditions are used to determine whether the following conditions are met: the number of non-new master nodes acquired by the new master node exceeds a specified number; the block height of the non-new master nodes acquired by the new master node is less than or equal to the block height of the new master node; where the block height is the block number corresponding to the latest block in the node; and the block pool status of the non-new master nodes acquired by the new master node is idle.

[0067] This specification provides a consortium blockchain node control method, which can be applied to non-new master nodes in a consortium blockchain node control system. Please continue reading. Figure 4 The consortium blockchain node control method may include the following steps.

[0068] Step S505: Upon receiving a target block, if the hash of the previous block in the target block is equal to the current hash of the latest current block in this node, then this node records the target block to the ledger it maintains; wherein, this node is either the old master node or the slave node.

[0069] Step S507: If the hash of the previous block in the target block is not equal to the current hash of the latest current block in this node, then if the latest current block is obtained by packaging the current node, the latest current block will be rolled back.

[0070] Step S509: If the latest current block is not packaged by this node, and there are a specified number of nodes with the same block in the blockchain network, this node will not roll back and will discard the target block; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

[0071] Step S511: If there are no specified number of nodes with the same block in the blockchain network, this node will roll back the latest current block by one block.

[0072] This specification provides a consortium blockchain node control device, which can be applied to a new master node in a consortium blockchain node control system. Please refer to... Figure 5 The consortium blockchain node control device may include a node status acquisition module 510 and a target block sending module 520.

[0073] The node status acquisition module 510 is used to acquire the node status information of non-current nodes in the blockchain network when it is detected that the current node has been converted from a slave node to a master node, if a specified delay time has been reached; wherein, the specified delay time is the specified duration for the current node to become a master node;

[0074] The target block sending module 520 is used to broadcast the target block to non-current nodes in the blockchain network if a target block exists, based on the obtained node status information and the determination that specified conditions are met, so that at least some nodes in the blockchain network can roll back or record the target block to the maintained ledger; wherein, the target block is obtained by the current node after receiving the transaction.

[0075] This specification provides a consortium blockchain node control device, which can be applied to non-new master nodes in a consortium blockchain node control system. The device may include a target block receiving module. Specifically, the target block receiving module, upon receiving a target block, if the hash of the previous block in the target block is not equal to the current hash of the latest current block in the current node, then, if the latest current block was obtained by packaging the current node, it will roll back the latest current block.

[0076] In some implementations, the target block receiving module is further configured to: if the previous block hash in the target block is not equal to the current hash of the latest current block in the current node, then if the current node is detected as the master node, not to perform a rollback and to discard the target block.

[0077] In some implementations, the target block receiving module is further configured to: upon receiving a target block, if the hash of the previous block in the target block is not equal to the current hash of the latest current block in the current node, then, if the latest current block is obtained by packaging the current node, roll back the latest current block.

[0078] In some implementations, the target block receiving module is further configured to: if the latest current block is not packaged by this node, and if there are a specified number of nodes with the same block in the blockchain network, this node will not roll back and will discard the target block; wherein, the nodes with the same block have specified blocks, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

[0079] In some implementations, the target block receiving module is also used to: if there are no specified number of nodes with the same block in the blockchain network, this node will roll back the latest current block by one block.

[0080] For details regarding the specific functions and effects of the consortium blockchain node control device, please refer to the explanations provided in this specification for embodiments other than the current implementation; these details will not be repeated here. Each module in the consortium blockchain node control device can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in hardware or independently of the processor in a computer device, or it can be stored in software in the memory of a computer device, so that the processor can call and execute the operations corresponding to each module.

[0081] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, causes the computer to perform the consortium blockchain node control method in any of the above embodiments.

[0082] This specification also provides a computer program product containing computer programs / instructions, which, when executed by a processor, implement the consortium blockchain node control method in any of the above embodiments.

[0083] This specification also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the consortium blockchain node control method described above.

[0084] In some implementations, please refer to Figure 6 The computer device can be a terminal, and its internal structure diagram can be as follows: Figure 6As shown, the computer device includes a processor, memory, and a communication interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other non-current technologies. When the computer program is executed by the processor, it implements a consortium blockchain node control method.

[0085] It is understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments described herein, and are not intended to limit the scope of the invention.

[0086] It is understood that in the various embodiments described in this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments described in this specification.

[0087] It is understood that the various implementation methods described in this specification can be implemented individually or in combination, and the implementation methods in this specification are not limited in this respect.

[0088] Unless otherwise stated, all technical and scientific terms used in the embodiments of this specification have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this specification. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0089] It is understood that the processor in the embodiments of this specification can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a non-current programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this specification can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0090] It is understood that the memory in the embodiments of this specification may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0091] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0092] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0093] The above description is merely a specific embodiment of this specification, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this specification should be included within the scope of protection of this specification. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A method for controlling consortium blockchain nodes, characterized in that, The method includes: If the new master node detects that a specified delay time has been reached, the node status information of non-new master nodes in the blockchain network is obtained; wherein, the specified delay time is the specified duration for which the new master node has become the master node; If, based on the obtained node status information, the specified conditions are met, and if the new master node has a target block, the target block is broadcast to the non-new master nodes in the blockchain network, so that at least some nodes in the blockchain network can roll back or record the target block in the maintained ledger; wherein, the target block is obtained by the new master node after receiving the transaction and packaging it. If the non-new master node receives the target block, and the hash of the previous block in the target block is not equal to the current hash of the latest current block in the non-new master node, then if the latest current block was obtained by the non-new master node, the non-new master node will roll back the latest current block. If the latest current block is not packaged by the non-new master node, and there are a specified number of nodes with the same block in the blockchain network, the non-new master node will not roll back; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

2. The method according to claim 1, characterized in that, The node status information includes the block height, block pool status, and number of nodes corresponding to the non-new master node; The specified conditions are determined to be met using the following methods: The number of non-new master nodes acquired by the new master node exceeds a specified number; The block height of the non-new master node obtained by the new master node is less than or equal to the block height of the new master node; wherein, the block height is the block number corresponding to the latest block in the node; The new master node obtains the block pool status of the non-new master node as an idle state.

3. The method according to claim 1, characterized in that, The method further includes: If there are no specified number of nodes with the same block in the blockchain network, the non-new master node will roll back the latest current block.

4. The method according to claim 1, characterized in that, The method further includes: Upon receiving the target block, if the hash of the previous block in the target block is equal to the current hash of the latest current block in the non-new master node, then the non-new master node records the target block in the ledger it maintains; wherein, the non-new master node is an old master node or a slave node.

5. A method for controlling consortium blockchain nodes, characterized in that, The method includes: If the current node is detected to have been converted from a slave node to a master node, and a specified delay time is reached, the node status information of non-current nodes in the blockchain network is obtained; wherein, the specified delay time is the specified duration for which the current node becomes the master node; If a target block exists, and the specified conditions are met based on the obtained node status information, the target block is broadcast to non-current nodes in the blockchain network so that at least some nodes in the blockchain network can roll back or record the target block in the maintained ledger; wherein, the target block is obtained by the current node after receiving the transaction; If a non-new master node receives the target block, and the hash of the previous block in the target block is not equal to the current hash of the latest current block in the non-new master node, then if the latest current block was obtained by the non-new master node, the non-new master node will roll back the latest current block. If the latest current block is not packaged by the non-new master node, and there are a specified number of nodes with the same block in the blockchain network, the non-new master node will not roll back; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

6. A consortium blockchain node control device, characterized in that, The device includes: The node status acquisition module is used to acquire the node status information of non-current nodes in the blockchain network when it is detected that the current node has been converted from a slave node to a master node, if a specified delay time has been reached; wherein, the specified delay time is the specified duration for which the current node has become the master node; The target block sending module is used to broadcast the target block to non-current nodes in the blockchain network if a target block exists, based on the obtained node status information and the determination that specified conditions are met, so that at least some nodes in the blockchain network can roll back or record the target block to the maintained ledger; wherein the target block is obtained by the current node after receiving the transaction; If a non-new master node receives the target block, and the hash of the previous block in the target block is not equal to the current hash of the latest current block in the non-new master node, then if the latest current block was obtained by the non-new master node, the non-new master node will roll back the latest current block. If the latest current block is not packaged by the non-new master node, and there are a specified number of nodes with the same block in the blockchain network, the non-new master node will not roll back; wherein, the nodes with the same block have a specified block, the block number corresponding to the specified block is the same as the block number corresponding to the latest current block of the non-new master node, and the current hash of the specified block is the same as the current hash of the latest current block.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

9. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method of any one of claims 1 to 5.

Images