Consensus method, device, storage medium and equipment of blockchain

Abstract

This application discloses a consensus method, apparatus, storage medium, and device for blockchain, applied to blockchain consensus scenarios. The method includes: in response to a temporary consensus transaction initiation, initiating a temporary consensus state, wherein the temporary consensus transaction initiation is a multi-signature transaction generated through joint signatures of all normal nodes; in the temporary consensus state, jointly performing temporary consensus operations with all normal nodes to provide transaction services externally through the temporary consensus; recording temporary consensus transaction data generated during the temporary consensus process; and performing consensus verification processing on the temporary consensus transaction data through all normal nodes, submitting the consensus-verified temporary consensus transaction data to the blockchain, thereby improving the availability of the blockchain system.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a consensus method, apparatus, storage medium, and device for blockchain. Background Technology

[0002] With the rapid development of blockchain technology, more and more business systems are adopting it to enhance data security and transparency. A blockchain system is a distributed system, typically consisting of consensus nodes and synchronization nodes. Consensus nodes are responsible for participating in the consensus process, ensuring the consistency and correctness of transactions; synchronization nodes obtain data from the consensus nodes to keep the data synchronized.

[0003] Depending on the application scenario, blockchain systems can be divided into public chains, consortium chains, and private chains. Among them, public chains have the largest number of nodes, often spread across the entire Internet globally; consortium chains are relatively compact blockchain systems, consisting of nodes from a single business or a group of mutually recognized organizations; private chains are blockchain systems composed of privately owned clusters, which are strictly confidential, and are a more compact form of consortium chains.

[0004] Consortium blockchains consist of multiple different organizations, each deploying consensus nodes in different data centers, which gives them high flexibility and security.

[0005] However, consortium blockchains also face some challenges. In particular, when an unpredictable disaster (such as a flood or earthquake) occurs at a data center, the damage can be so severe that the data center cannot be restored quickly, potentially leading to a large number of nodes malfunctioning. In such cases, if the number of malfunctioning nodes exceeds the fault tolerance range allowed by the blockchain system, the entire blockchain system will be unable to continue providing services and must wait for a sufficient number of consensus nodes to recover. This not only affects business continuity but also causes economic losses.

[0006] Current technology lacks an effective handling mechanism when faced with node anomalies exceeding the fault tolerance range. It must wait for enough consensus nodes to recover before services can be resumed, resulting in poor availability of the blockchain system. Summary of the Invention

[0007] This application provides a consensus method, apparatus, storage medium, and device for blockchain. By introducing a temporary consensus mechanism, it ensures that the blockchain system continues to provide transaction services when an abnormal event occurs in a node, significantly improving the availability and stability of the blockchain system.

[0008] On the one hand, embodiments of this application provide a consensus method for blockchain.

[0009] The blockchain includes at least one normal node and at least one abnormal node, the method is executed by any normal node, and the method includes:

[0010] In response to the temporary consensus to initiate a transaction, a temporary consensus state is initiated. The temporary consensus to initiate a transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormal event in the blockchain.

[0011] In the aforementioned temporary consensus state, all normal nodes jointly perform temporary consensus operations so that all normal nodes can provide transaction services to the outside world through the temporary consensus.

[0012] Record temporary consensus transaction data generated during the temporary consensus process;

[0013] The temporary consensus transaction data is verified by all normal nodes, and the verified temporary consensus transaction data is submitted to the blockchain.

[0014] On the other hand, embodiments of this application provide a consensus method for a blockchain, wherein the blockchain includes at least one recovery node and at least one normal node, the recovery node being a recovery node after an abnormal node corresponding to a node abnormal event has recovered to normal, and the normal node being a normal node in the blockchain at the time the node abnormal event occurred, the method being executed by any one of the recovery nodes, and the method including:

[0015] The first request to obtain a temporary consensus block is broadcast to the entire blockchain network.

[0016] The system receives temporary consensus blocks sent by normal nodes. These temporary consensus blocks are obtained by the normal node upon receiving the first request, retrieving them from the temporary consensus transaction data, serializing them, and then sending them to the recovery node. The temporary consensus transaction data is obtained by the normal node in response to a temporary consensus transaction, activating a temporary consensus state, and, in this state, collaborating with all normal nodes to perform temporary consensus operations. This allows all normal nodes to provide transaction services externally and records the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus transaction activation is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain.

[0017] The temporary consensus block undergoes consensus verification processing, and the temporary consensus block that passes the consensus verification is submitted to the database of the blockchain.

[0018] On the other hand, embodiments of this application provide a consensus device for a blockchain, wherein the blockchain includes at least one normal node and at least one abnormal node, and the device is mounted on any one of the normal nodes. The device includes:

[0019] The activation unit is used to activate a transaction in response to a temporary consensus and to activate a temporary consensus state. The temporary consensus transaction is a multi-signature transaction generated by joint signatures of all normal nodes in the event of a node abnormal event in the blockchain.

[0020] The consensus unit is used to unite all normal nodes to perform temporary consensus operations in the temporary consensus state, so as to provide transaction services to the outside world through all normal nodes of the temporary consensus.

[0021] The recording unit is used to record temporary consensus transaction data generated during the temporary consensus process.

[0022] The first processing unit is used to perform consensus verification processing on the temporary consensus transaction data through all normal nodes, and submit the temporary consensus transaction data that has passed the consensus verification to the blockchain.

[0023] In some embodiments, the first processing unit is configured to: receive, through each of all normal nodes, a first request from a recovery node broadcast to the entire blockchain network to obtain a temporary consensus block, wherein the recovery node is any recovery node after the abnormal node corresponding to the node abnormal event has recovered; obtain a temporary consensus block from the temporary consensus transaction data according to the first request, and serialize the temporary consensus block and send it to the recovery node, so that the recovery node performs consensus verification processing on the temporary consensus block and submits the temporarily consensus block that has passed consensus verification to the database of the blockchain.

[0024] In some embodiments, when the first processing unit obtains a temporary consensus block from the temporary consensus transaction data according to the first request, serializes the temporary consensus block, and sends it to the recovery node so that the recovery node performs consensus verification processing on the temporary consensus block and submits the temporarily consensus block that has passed consensus verification to the database of the blockchain, the processing unit is configured to: obtain a temporary consensus block from the temporary consensus transaction data according to the first request, serialize the temporary consensus block, and send it to the recovery node so that the recovery node receives the temporary consensus block within a first specified time and verifies that the temporary consensus block has legality. When the number of first votes carrying the block hash of the temporary consensus block received by a recovery node reaches a first vote threshold, the recovery node adds the content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the database of the blockchain. Similarly, when a normal node receives the first vote carrying the block hash of the temporary consensus block and reaches the first vote threshold, it adds the content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the database of the blockchain.

[0025] In some embodiments, the first processing unit is further configured to: receive a second request from the recovery node to the entire blockchain network to obtain the next temporary consensus block; obtain the next temporary consensus block from the temporary consensus transaction data according to the second request, and serialize the next temporary consensus block and send it to the recovery node, so that the recovery node performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the database of the blockchain.

[0026] In some embodiments, when the first processing unit retrieves the next temporary consensus block from the temporary consensus transaction data according to the second request, serializes the next temporary consensus block, and sends it to the recovery node so that the recovery node performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the blockchain database, the first processing unit is configured to: retrieve the next temporary consensus block from the temporary consensus transaction data according to the second request, serialize the next temporary consensus block, and send it to the recovery node so that the recovery node, when verifying the legality of the next temporary consensus block, submits it to the blockchain database. The network broadcasts a second vote on the block hash of the next temporary consensus block, so that when the number of second votes carrying the block hash of the next temporary consensus block received by the recovery node reaches a second vote threshold, the voting content of the second vote is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the blockchain database; and when the number of second votes carrying the block hash of the next temporary consensus block received by the normal node reaches a second vote threshold, the voting content of the second vote is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the blockchain database.

[0027] In some embodiments, the first processing unit is further configured to: receive a third request broadcast by the recovery node to the entire blockchain network to obtain all remaining transactions of the temporary consensus, the third request being generated by the recovery node when verifying that the next temporary consensus block is not legitimate; obtain all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data according to the third request, to obtain a first target transaction set; serialize the first target transaction set and send it to the recovery node, so that the recovery node adds the first target transaction set to the local transaction pool of the recovery node and performs the normal consensus process.

[0028] In some embodiments, the first processing unit is further configured to: receive a fourth request broadcast by the recovery node to the entire blockchain network to obtain all transactions within the temporary consensus range, wherein the fourth request is generated when the recovery node does not receive the temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time; obtain all transactions within the temporary consensus range from the temporary consensus transaction data according to the fourth request to obtain a second target transaction set; serialize the second target transaction set and send it to the recovery node so that the recovery node adds the second target transaction set to the recovery node's local transaction pool and performs the normal consensus process.

[0029] In some embodiments, the activation unit is configured to: receive a temporary consensus activation transaction sent by any one of the normal nodes; and after the temporary consensus activation transaction is processed, reach a consensus within the scope of the temporary consensus nodes, and then adjust the local consensus state of the normal nodes to temporary consensus to activate the temporary consensus state.

[0030] In some embodiments, when the activation unit performs consensus after initiating the temporary consensus transaction to reach an agreement within the scope of temporary consensus nodes, it adjusts the local consensus state of normal nodes to "in temporary consensus" to activate the temporary consensus state. This is done by: obtaining the local consensus state of normal nodes; if the local consensus state is "in temporary consensus" and is closed, obtaining the signature list set and the set of recognized nodes in the temporary consensus activation transaction, wherein the set of recognized nodes consists of temporary consensus nodes; and, if the signature list set and the set of recognized nodes are consistent, adjusting the local consensus state to "in temporary consensus" to activate the temporary consensus state.

[0031] On the other hand, embodiments of this application provide a consensus device for a blockchain, wherein the blockchain includes at least one recovery node and at least one normal node, the recovery node being a recovery node after an abnormal node corresponding to a node abnormal event has recovered to normal, and the normal node being a normal node in the blockchain at the time the node abnormal event occurred, the device being mounted on any one of the recovery nodes, and the device comprising:

[0032] The broadcast unit is used to broadcast the first request to obtain a temporary consensus block to the entire blockchain network;

[0033] The receiving unit is used to receive temporary consensus blocks sent by normal nodes. These temporary consensus blocks are obtained by the normal node upon receiving the first request, retrieving them from the temporary consensus transaction data, serializing them, and then sending them to the recovery node. The temporary consensus transaction data is obtained by the normal node in response to a temporary consensus transaction, initiating a temporary consensus state, and, in this state, collaborating with all normal nodes to perform temporary consensus operations. This allows all normal nodes to provide transaction services externally, and records the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus transaction initiation is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain.

[0034] The second processing unit is used to perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed the consensus verification to the database of the blockchain.

[0035] In some embodiments, the second processing unit is configured to: upon receiving the temporary consensus block within a first specified time and verifying the legality of the temporary consensus block, broadcast a first vote for the block hash of the temporary consensus block to the entire blockchain network, so that when the number of first votes carrying the block hash of the temporary consensus block received by the normal node reaches a first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the database of the blockchain; and when the number of first votes carrying the block hash of the temporary consensus block received by the recovery node reaches the first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the database of the blockchain.

[0036] In some embodiments, the second processing unit is further configured to: broadcast a second request to the entire blockchain network to obtain the next temporary consensus block; receive the next temporary consensus block sent by the normal node, wherein the next temporary consensus block is obtained by the normal node from the temporary consensus transaction data according to the second request, and serializes the next temporary consensus block before sending it to the recovery node; perform consensus verification processing on the next temporary consensus block, and submit the next temporary consensus block that has passed consensus verification to the database of the blockchain.

[0037] In some embodiments, when the second processing unit performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the blockchain database, it is configured to: when verifying the legitimacy of the next temporary consensus block, broadcast a second vote for the block hash of the next temporary consensus block to the entire blockchain network, so that when the normal node receives the number of second votes carrying the block hash of the next temporary consensus block and reaches a second vote threshold, add the voting content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database; and when the recovery node receives the number of second votes carrying the block hash of the next temporary consensus block and reaches a second vote threshold, add the voting content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database.

[0038] In some embodiments, the second processing unit is further configured to: after submitting the next temporary consensus block to the database of the blockchain, determine whether the next temporary consensus block is a block where temporary consensus is closed; if the next temporary consensus block is determined to be a block where temporary consensus is closed, then proceed with the normal consensus process; or if the next temporary consensus block is determined not to be a block where temporary consensus is closed, then return to the step of executing the second request to obtain the next temporary consensus block broadcast to the entire blockchain network.

[0039] In some embodiments, the second processing unit is further configured to: broadcast a third request to the entire blockchain to obtain all remaining transactions of the temporary consensus, the third request being generated by the recovery node; receive a first target transaction set sent by the normal node, the first target transaction set being obtained by the normal node according to the third request, which obtains all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data, and serializes the first target transaction set before sending it to the recovery node; add the first target transaction set to the local transaction pool of the recovery node and perform the normal consensus process.

[0040] In some embodiments, the second processing unit is further configured to: broadcast a fourth request to the entire blockchain to obtain all transactions within the temporary consensus range, the fourth request being generated when the recovery node does not receive the temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed; receive a second target transaction set sent by the normal node, the second target transaction set being obtained by the normal node from all transactions within the temporary consensus range obtained from the temporary consensus transaction data according to the fourth request, serializing the second target transaction set and sending it to the recovery node; add the second target transaction set to the local transaction pool of the recovery node and perform the normal consensus process.

[0041] On the other hand, this application embodiment provides a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the blockchain consensus method as described in any of the above embodiments.

[0042] On the other hand, an embodiment of this application provides a computer device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the blockchain consensus method as described in any of the above embodiments by calling the computer program stored in the memory.

[0043] On the other hand, an embodiment of this application provides a computer program product, including computer instructions that, when executed by a processor, implement the blockchain consensus method as described in any of the above embodiments.

[0044] This application embodiment initiates a transaction through a temporary consensus mechanism, where any normal node in the blockchain responds to a temporary consensus. This temporary consensus state is achieved by generating a multi-signature transaction through joint signatures of all normal nodes in the event of a node anomaly. In the temporary consensus state, all normal nodes jointly perform a temporary consensus operation to provide transaction services to external parties. The temporary consensus transaction data generated during the process is recorded. All normal nodes then perform consensus verification on the temporary consensus transaction data, and the verified temporary consensus transaction data is submitted to the blockchain. By introducing a temporary consensus mechanism, this application embodiment ensures that the blockchain system continues to provide transaction services even when a node anomaly occurs, significantly improving the availability and stability of the blockchain system. In this process, when an abnormal event occurs on a blockchain node, a temporary consensus state is initiated through normal nodes, allowing the system to continue providing transaction services. During the temporary consensus state, all normal nodes work together to reach a temporary consensus, enabling all normal nodes to provide transaction services. The temporary consensus transaction data generated during the temporary consensus process is recorded and verified. Only temporary consensus transaction data that passes the consensus verification is submitted to the blockchain, ensuring data security and consistency and avoiding data loss or inconsistency issues caused by abnormal events. Attached Figure Description

[0045] Figure 1 This is an optional structural diagram of the blockchain system provided in an embodiment of this application.

[0046] Figure 2 An optional schematic diagram of the block structure provided in the embodiments of this application.

[0047] Figure 3 This is a schematic diagram of the functional architecture of the blockchain system provided in the embodiments of this application.

[0048] Figure 4 This is a first flowchart illustrating the consensus method for blockchain provided in an embodiment of this application.

[0049] Figure 5 This is a second flowchart illustrating the consensus method for blockchain provided in an embodiment of this application.

[0050] Figure 6 This is a first interactive schematic diagram of the blockchain consensus method provided in the embodiments of this application.

[0051] Figure 7 This is a second interactive schematic diagram of the blockchain consensus method provided in the embodiments of this application.

[0052] Figure 8A schematic diagram of a first application scenario of the blockchain consensus method provided in this application embodiment.

[0053] Figure 9 A schematic diagram of a second application scenario of the blockchain consensus method provided in the embodiments of this application.

[0054] Figure 10 This is a schematic diagram of a third application scenario of the blockchain consensus method provided in the embodiments of this application.

[0055] Figure 11 This is a schematic diagram of a fourth application scenario of the blockchain consensus method provided in the embodiments of this application.

[0056] Figure 12 This is a schematic diagram of the fifth application scenario of the blockchain consensus method provided in the embodiments of this application.

[0057] Figure 13 A first structural schematic diagram of a blockchain consensus device provided in an embodiment of this application.

[0058] Figure 14 A first structural schematic diagram of a blockchain consensus device provided in an embodiment of this application.

[0059] Figure 15 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] This application provides a consensus method, apparatus, storage medium, and device for blockchain. Exemplarily, the blockchain consensus method of this application can be executed by a computer device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, desktop computer, smart TV, smart speaker, wearable smart device, personal computer (PC), smart vehicle terminal, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this application. This application can be applied to scenarios such as internet and blockchain consensus.

[0062] First, some of the nouns or terms that appear in the description of the embodiments of this application are explained as follows:

[0063] Blockchain system: A distributed database system that generates and updates data through consensus algorithms, uses cryptography to ensure the security of data transmission and access, and uses smart contracts to program and manipulate data. This system is characterized by decentralization, information transparency, and high security, representing a novel distributed infrastructure and computing paradigm.

[0064] A node is a connection point, representing a redistribution point or a communication endpoint (sometimes a terminal device). The definition of a node depends on the network and protocol layers mentioned. A physical network node is an active electronic device connected to a network, capable of sending, receiving, or forwarding information through a communication channel.

[0065] Consensus: In a blockchain system, nodes verify the correctness of messages sent by other nodes. If verification is successful, a confirmation is sent to the node that sent the message, and the message is persistently stored to support subsequent message retrieval. Mechanisms for achieving consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DPoS), and Proof of Elapsed Time (PoET).

[0066] For example, in a blockchain system, a node verifies the validity of a new block submitted by another node. If the verification is successful, it sends a confirmation to the node that submitted the new block and adds the new block to the tail of the blockchain stored by the corresponding node.

[0067] Byzantine Fault Tolerance (BFT) consensus algorithm is a consensus algorithm derived from the Byzantine Generals Problem. There are three versions of the Byzantine Fault Tolerance consensus algorithm: Practical Byzantine Fault Tolerance (PBFT), Federated Byzantine Agreement (FBA), and Delegated Byzantine Fault Tolerance (dBFT).

[0068] A consortium blockchain is a blockchain that uses members of a specific group and a limited number of third parties as access parties and provides services. Within a consortium blockchain, multiple pre-selected nodes are designated as nodes that run the consensus algorithm and the blockchain. The generation of each block is jointly determined by all the pre-selected nodes. Other access nodes may not participate in the consensus and storage process of the blockchain. Other third parties can perform limited queries on the blockchain through the blockchain's open application programming interface (API).

[0069] Voting: The verification process of proposals by node devices. The Byzantine consensus algorithm assigns an incremental index or height to each block. Only one valid block exists at a certain height. The blockchain starts from the genesis block at height 0, and multiple node devices, acting as validators, vote to produce the next block. Each node device acting as a validator has its own public key identifier.

[0070] The solutions provided in this application involve technologies such as blockchain consensus, which are specifically illustrated in the following embodiments. These embodiments are described in detail below. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0071] The blockchain system involved in this application embodiment can be a distributed system formed by connecting clients and multiple nodes (any form of computing device in the network, such as servers and user terminals) through network communication.

[0072] Taking a distributed system as an example, see blockchain system. Figure 1 , Figure 1This is an optional structural diagram of the blockchain system 10 provided in this application embodiment. It consists of multiple nodes 11 (any form of computing device in the network, such as servers or user terminals) and clients 12. The nodes 11 form a peer-to-peer network, and the peer-to-peer network protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the blockchain system 10, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0073] See Figure 1 The functions of each node 11 in the blockchain system 10 shown include:

[0074] 1) Routing: A basic function of nodes used to support communication between nodes.

[0075] In addition to routing capabilities, nodes can also have the following functions:

[0076] 2) Applications, deployed within the blockchain, implement specific business functions based on actual business needs. They record data related to these functions, forming record data. This record data carries a digital signature to indicate the source of the task data. The record data is then sent to other nodes in the blockchain system. Upon successful verification of the record data's source and integrity, other nodes add the record data to a temporary block. For example, the business functions implemented by the application include:

[0077] 2.1) A wallet is used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0078] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0079] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0080] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0081] See Figure 2 , Figure 2 This is an optional schematic diagram of the block structure provided in this application embodiment. The header of each block can include the hash values ​​of all transactions in the block, as well as the hash values ​​of all transactions in the previous block. Newly generated transaction records are filled into the block and, after consensus among nodes in the blockchain network, are appended to the end of the blockchain, forming a chain-like growth. This chain-like structure based on hash values ​​ensures the tamper-proof and forgery-proof nature of transactions within the block. Additionally, the block may also include information such as a timestamp when the block was generated.

[0082] The following describes an exemplary functional architecture of the blockchain network provided in the embodiments of this application. See also... Figure 3 , Figure 3 The functional architecture diagram of the blockchain system 10 provided in this application embodiment includes an application layer 101, a consensus layer 102, a network layer 103, a data layer 104, and a resource layer 105, which will be described below.

[0083] Resource layer 105 encapsulates the computing resources, storage resources, and communication resources of each node 10 in the blockchain system 10, such as computing resources, storage resources, and communication resources in computers, servers / clusters, and the cloud, abstracts them, and provides a unified interface to data layer 204 to shield the differences in the underlying hardware implementing resource layer 205.

[0084] Computing resources include various forms of processors, such as central processing units (CPUs), application-specific integrated circuits (ASICs), application-specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs).

[0085] Storage resources include various types of storage media, such as volatile memory and non-volatile memory.

[0086] Communication resources include various links for communication between nodes 210 in the blockchain network and between the blockchain network 200 and business entities. The data layer 104 encapsulates various data structures for implementing the ledger, including a blockchain implemented as files in a file system, a key-value state database, and proof of existence (e.g., a hash tree of transactions in a block). The network layer 103 encapsulates the functions of peer-to-peer network protocols, data propagation mechanisms, data verification mechanisms, access authentication mechanisms, and business entity identity management. Specifically, the peer-to-peer network protocol enables communication between nodes 10 in the blockchain system 10; the data propagation mechanism ensures the propagation of transactions within the blockchain system 10; the data verification mechanism uses cryptographic methods (e.g., digital certificates, digital signatures, public / private key pairs) to ensure the reliability of data transmission between nodes 10; the access authentication mechanism authenticates the identity of business entities joining the blockchain system 10 based on actual business scenarios and grants them access permissions when authentication is successful; and business entity identity management stores the identities and permissions (e.g., the types of transactions that can be initiated) of business entities allowed to access the blockchain system 10. The consensus layer 102 encapsulates the mechanisms (i.e., consensus mechanisms) for nodes 10 in the blockchain system 10 to reach consensus on blocks, as well as the functions of transaction management and ledger management. The consensus mechanisms include consensus algorithms such as POS, POW, and DPOS, and support pluggable consensus algorithms. Transaction management verifies the digital signatures carried in transactions received by node 10, verifies the identity information of the business entity, and determines whether it has the authority to conduct transactions based on the identity information (reading relevant information from the business entity identity management). For business entities authorized to access the blockchain system 10, they all possess digital certificates issued by the certification authority. Business entities use the private key in their digital certificates to sign submitted transactions, thereby declaring their legitimate identity. Ledger management maintains the blockchain and the state database. For blocks that have reached consensus, they are appended to the end of the blockchain; transactions in consensus-reaching blocks are executed. When a transaction includes an update operation, the key-value pairs in the state database are updated; when a transaction includes a query operation, the key-value pairs in the state database are queried, and the query results are returned to the client nodes of the business entity. It supports multi-dimensional query operations on the state database, including: querying blocks by block vector number (e.g., transaction hash value); querying blocks by block hash value; querying blocks by transaction vector number; querying transactions by transaction vector number; querying account data of a business entity by its account (vector number); and querying the blockchain within a channel by channel name. Application layer 101 encapsulates various business functions that the blockchain network can implement, including transaction tracing, notarization, and verification.

[0087] Please see Figure 4 , Figure 4 This is a first flowchart illustrating a consensus method for a blockchain provided in this application. The blockchain includes at least one normal node and at least one abnormal node. The method is executed by any one of the normal nodes and may include the following steps:

[0088] Step 110: In response to the temporary consensus to initiate a transaction, the temporary consensus state is initiated. The temporary consensus to initiate a transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormal event in the blockchain.

[0089] When the blockchain system detects an abnormal node event, it triggers a temporary consensus initiation process. Surviving, normal nodes generate a temporary consensus initiation transaction via their clients. This transaction is a multi-signature transaction, requiring joint signatures from all normal nodes.

[0090] For example, when any normal node receives a transaction to initiate a temporary consensus, it will respond by verifying the legality of the transaction and the validity of the signature. If the transaction is legal and the signature is valid, the normal node will adjust its local consensus state to the temporary consensus state to initiate the temporary consensus state and notify other normal nodes to update their states.

[0091] The activation of the temporary consensus state means that the blockchain system has entered a special consensus mode, where only surviving normal nodes need to participate in the consensus to ensure that the blockchain system can continue to provide services to the outside world.

[0092] In some embodiments, in response to a temporary consensus initiation transaction, initiating a temporary consensus state includes: receiving a temporary consensus initiation transaction sent by any normal node; and after reaching consensus on the temporary consensus initiation transaction, adjusting the local consensus state of the normal node to temporary consensus state after reaching an agreement within the scope of the temporary consensus nodes, thereby initiating the temporary consensus state.

[0093] This process involves receiving a temporary consensus initiation transaction sent by any normal node. For example, when the blockchain system detects an abnormal event among the nodes and the number of normal nodes in the blockchain is insufficient to meet the requirements of the normal consensus rules, a normal node (which can be a pre-designated node or a randomly selected node) will initiate a temporary consensus initiation process. This temporary consensus initiation transaction is a multi-signature transaction, requiring joint signatures from all normal nodes. The transaction contains instructions to initiate a temporary consensus state and necessary metadata information. Once the temporary consensus initiation transaction is generated, it is broadcast to all normal nodes in the blockchain. Each normal node receives and processes this temporary consensus initiation transaction. For example, the normal consensus rules can be Byzantine Fault Tolerance (BFT) rules. For instance, for BFT-type consensus, a maximum of f nodes are allowed to be abnormal in the blockchain. When the data center is damaged, the remaining nodes in the blockchain must satisfy the 3f+1 (or 2f+1) rule of BFT consensus.

[0094] The process involves initiating a temporary consensus transaction and then reaching consensus within the temporary consensus node scope. Once this consensus is achieved, the local consensus state of the normal nodes is adjusted to "in the temporary consensus state," thus initiating the temporary consensus state. For example, upon receiving a temporary consensus initiation transaction, each normal node in the blockchain verifies and reaches consensus on the transaction. If consensus is reached within the temporary consensus node scope, each normal node adjusts its local consensus state to "in the temporary consensus state." This signifies that the blockchain system has officially entered the temporary consensus state. After the state adjustment is complete, each normal node broadcasts its state change information to other normal nodes in the blockchain. This ensures that all normal nodes are synchronously updated to the same consensus state, thereby maintaining consistency.

[0095] In some embodiments, after a transaction is initiated for temporary consensus, consensus is reached so that after reaching an agreement within the scope of temporary consensus nodes, the local consensus state of normal nodes is adjusted to be in temporary consensus to initiate temporary consensus. This includes: obtaining the local consensus state of normal nodes; if the local consensus state is closed in temporary consensus, obtaining the signature list set and the set of recognized nodes in the transaction for initiating temporary consensus, wherein the set of recognized nodes consists of temporary consensus nodes; and if the signature list set and the set of recognized nodes are consistent, adjusting the local consensus state to be in temporary consensus to initiate temporary consensus.

[0096] For example, upon receiving a temporary consensus initiation transaction, each normal node will perform consensus processing on that transaction. This process includes the following steps:

[0097] 1) Obtaining the local consensus state of normal nodes: After receiving the temporary consensus to initiate a transaction, each normal node will first obtain its own local consensus state. This is to ensure that the node processes the transaction in the correct state.

[0098] 2) Check the local consensus status: If the local consensus status is "Closed in temporary consensus," it means the node has already experienced a temporary consensus state and closed it normally. In this case, the node needs to further check the validity of the temporary consensus initiation transaction, that is, the node needs to further check the set of signatures and the set of recognized nodes in the temporary consensus initiation transaction. If the local consensus status is not "Closed in temporary consensus," but another status (such as normal consensus state, in temporary consensus, or initiated in temporary consensus), the node may need to take different actions depending on the specific situation. For example, if the node is currently in a normal consensus state, it can continue with the subsequent verification steps; if the node is already in temporary consensus, it may need to ignore this new initiation transaction.

[0099] 3) Verifying the Signature List and the Set of Recognized Nodes: A temporary consensus initiation transaction involves two key pieces of information: a signature list and a set of recognized nodes. The signature list consists of the signatures of all legitimate nodes that agree to initiate the temporary consensus, while the set of recognized nodes comprises these signing nodes, which will collectively participate in the temporary consensus. When processing a temporary consensus initiation transaction, nodes must verify that these two sets are consistent. That is, nodes need to confirm that the signatures in the signature list indeed belong to nodes in the set of recognized nodes, and that no other unrecognized nodes are involved. This verification process ensures that only authorized nodes can participate in the temporary consensus, guaranteeing the legality and validity of the temporary consensus initiation transaction and preventing malicious nodes from forging or tampering with the transaction. For example, the number of nodes in the signature list and the set of recognized nodes must be consistent, and the node identities must correspond one-to-one. If the verification passes, the temporary consensus initiation transaction is valid and can continue processing; if the verification fails, the transaction is rejected.

[0100] 4) Adjusting the local consensus state of normal nodes to "Temporary Consensus": When the set of verified signatures matches the set of recognized nodes, normal nodes will adjust their local consensus state to "Temporary Consensus" to officially initiate the temporary consensus state. This state adjustment signifies that the node has begun participating in the temporary consensus process and is ready to receive and process transactions generated during the temporary consensus period.

[0101] For example, when a blockchain enters a temporary consensus state, the values ​​stored in its state database are shown in Table 1 below:

[0102] Table 1

[0103] Temporary consensus key Temporary consensus identifier List of nodes participating in this temporary consensus TMPC 1

Node1, Node2, Node3...

[0104] After the state adjustment is complete, the currently functioning node will broadcast its local consensus state change information to other functioning nodes in the blockchain to ensure that all functioning nodes can be synchronized to the same consensus state. This guarantees the consistency and stability of the entire blockchain system.

[0105] Step 120: Under the temporary consensus state, all normal nodes jointly perform temporary consensus operations so that all normal nodes can provide transaction services to the outside world through the temporary consensus.

[0106] Once the temporary consensus state is activated, all normal nodes in the blockchain will enter temporary consensus mode. In this mode, all normal nodes will collaborate to perform temporary consensus operations, ensuring the consistency and correctness of transactions. These normal nodes that have reached temporary consensus will continue to provide transaction services, receiving transaction requests from clients and processing them within the temporary consensus mode. The purpose of temporary consensus is to ensure the blockchain system continues to operate normally and provide necessary services even if some nodes experience anomalies.

[0107] For example, when performing a temporary consensus operation, each normal node in the blockchain checks whether its local consensus state is in temporary consensus. If it is found that the local consensus state is in temporary consensus, then each normal node in the blockchain reaches consensus within the set of consensus nodes corresponding to the temporary consensus. If it is found that the local consensus state is not in temporary consensus, then each normal node in the blockchain reaches consensus within the set of consensus nodes corresponding to all normal consensuses in the blockchain.

[0108] Step 130: Record the temporary consensus transaction data generated during the temporary consensus process.

[0109] During the temporary consensus phase, all normal nodes in the blockchain record all temporary consensus transaction data generated during the process. This temporary consensus transaction data is stored in a temporary transaction pool for further processing after the blockchain system recovers. The recorded temporary consensus transaction data includes, but is not limited to, information such as the transaction initiator, transaction content, and transaction timestamp, ensuring data integrity and traceability. Recording temporary consensus transaction data is crucial for accurately reconstructing the transaction situation during the temporary consensus phase after the blockchain system recovers, ensuring data consistency and security.

[0110] For example, in a blockchain system, provisional consensus is a crucial mechanism for ensuring a certain level of consistency and trust among nodes under abnormal circumstances. However, due to various possible reasons, such as network latency, node failure, or malicious attacks, provisional consensus may fail to be reached. In a provisional consensus state, although consensus may not be reached, normal nodes in the blockchain will still record transaction data generated when some nodes have reached provisional consensus. This transaction data is stored in a temporary transaction pool for further processing and verification after the blockchain system recovers. This verification verifies the validity of the transaction data and, based on the blockchain's rules and consensus algorithm, determines whether to include this transaction data in the official blockchain record.

[0111] In some embodiments, the method further includes: closing the temporary consensus state in response to the temporary consensus closing transaction, wherein the temporary consensus closing transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the blockchain when the node abnormal event occurred, after the abnormal node corresponding to the node abnormal event has recovered to normal.

[0112] Specifically, once the abnormal node corresponding to the node anomaly event recovers, the blockchain system can trigger a temporary consensus shutdown process. Any normal node will generate a temporary consensus shutdown transaction through its client. This temporary consensus shutdown transaction is also a multi-signature transaction, requiring the joint signatures of all normal nodes in the blockchain at the time of the node anomaly event.

[0113] For example, upon receiving a temporary consensus closing transaction, any normal node will respond by verifying the transaction's legality and the signature's validity. If the transaction is legal and the signature is valid, the normal node will adjust its local consensus state to "closed" in the temporary consensus, thus closing the temporary consensus state and notifying other normal nodes to update their states. Closing the temporary consensus state signifies that the blockchain system has returned to normal consensus mode. If all abnormal nodes recover, all nodes will re-participate in consensus, ensuring the normal operation of the blockchain system. If only some abnormal nodes recover, these recovered nodes, along with the current normal nodes, will participate in consensus first, while the remaining abnormal nodes will gradually join the consensus process after recovering, until the entire blockchain system is fully restored to a normal state.

[0114] In some embodiments, in response to a temporary consensus closure transaction, closing the temporary consensus state includes: receiving a temporary consensus closure transaction sent by any normal node; and after reaching consensus on the temporary consensus closure transaction, adjusting the local consensus state of the normal node to "closed in temporary consensus" after reaching a consensus across all consensus nodes, thereby closing the temporary consensus state.

[0115] Specifically, it receives a temporary consensus shutdown transaction sent via a client by any normal node in the blockchain when a node anomaly event occurs. For example, when the blockchain system detects that the nodes in the data center have recovered and there are a sufficient number of consensus nodes to re-perform full consensus, any normal node sends a temporary consensus shutdown transaction via a client. This transaction contains instructions to close the temporary consensus state and the necessary signature information.

[0116] The process involves reaching consensus after a temporary consensus closure transaction is received. For example, upon receiving a temporary consensus closure transaction, each normal node processes it for consensus. This process occurs across all nodes in the consensus network to ensure that all participating nodes agree to close the temporary consensus state. The temporary consensus closure transaction is first broadcast to the entire blockchain network by the sending node, and then received by other normal nodes. Each normal node verifies the received temporary consensus closure transaction, including verifying its format, signature, and whether its content conforms to predefined rules. Within the scope of all nodes in the consensus network, all normal nodes vote and reach consensus on the temporary consensus closure transaction. Only when a sufficient number of nodes (meeting the requirement of a full consensus network) agree to close the temporary consensus state is the transaction considered valid.

[0117] Once consensus is reached among all nodes in the full consensus framework, the local consensus state of a normal node is adjusted to "temporary consensus is closed," effectively shutting down the temporary consensus state. This state adjustment signifies that the node has ceased participating in the temporary consensus process and is preparing to revert to the normal full consensus mode. The normal node updates its consensus state in its local state database, recording that the temporary consensus state has been closed. The normal node broadcasts its state change information to other nodes in the blockchain to ensure that all normal nodes are synchronized to the same consensus state, guaranteeing the consistency and stability of the entire blockchain system. After closing the temporary consensus state, the normal node begins receiving and processing new transactions, performing consensus and verification according to the requirements of full consensus. The blockchain system then returns to its normal operating state.

[0118] For example, when the blockchain closes its temporary consensus state, the values ​​stored in its state database are shown in Table 2 below:

[0119] Table 2

[0120] Temporary consensus key Temporary consensus identifier TMPC 0

[0121] Through the above steps, the blockchain system can safely and effectively shut down the temporary consensus state, ensuring that it can smoothly return to the normal full consensus mode after the node recovers, thereby maintaining the stability and availability of the blockchain system.

[0122] Step 140: Perform consensus verification on the temporary consensus transaction data through all normal nodes, and submit the temporarily consensus transaction data that has passed the consensus verification to the blockchain.

[0123] Once the temporary consensus state is closed, all normal nodes will perform consensus verification on the temporary consensus transaction data generated during the temporary consensus process. The verification process may include checking the legality, consistency, and completeness of the temporary consensus transaction data.

[0124] For example, verified temporary consensus transaction data will be submitted to the blockchain, becoming part of it and ensuring the data's immutability and permanence. Conversely, for temporary consensus transaction data that fails verification, the blockchain system will take appropriate actions, such as recording anomalies or rolling back transactions, to ensure the security and stability of the blockchain system. Through this process, the blockchain system can continue to maintain normal service after recovery, while ensuring that transaction data during the temporary consensus period is correctly processed and recorded.

[0125] In some embodiments, the temporary consensus transaction data is processed for consensus verification by all normal nodes, and the temporarily consensus transaction data that has passed consensus verification is submitted to the blockchain. This includes: each normal node receiving a first request from a recovery node broadcast to the entire blockchain network to obtain a temporary consensus block, where the recovery node is any recovery node after the abnormal node corresponding to the node abnormal event has recovered; obtaining a temporary consensus block from the temporary consensus transaction data according to the first request, serializing the temporary consensus block and sending it to the recovery node, so that the recovery node can process the consensus verification of the temporary consensus block and submit the temporarily consensus block that has passed consensus verification to the blockchain database.

[0126] In this process, each of the normal nodes receives the first request for obtaining a temporary consensus block, broadcast across the entire blockchain by the recovery node. For example, a recovery node is any recovery node that has recovered from an abnormal node event. Any recovery node will broadcast its first request for obtaining a temporary consensus block across the entire blockchain network. This first request may include the recovery node's identity and relevant information about the temporary consensus block it needs to obtain (such as block height and hash value).

[0127] In this process, a temporary consensus block is retrieved from the temporary consensus transaction data based on the first request. For example, each normal node among all normal nodes, upon receiving the first request from the recovery node, will extract the corresponding temporary consensus block from the temporary consensus transaction data. This temporary consensus transaction data is typically stored in the blockchain system's temporary storage area or log to record all transactions generated during the temporary consensus period.

[0128] The process involves serializing temporary consensus blocks and sending them to recovery nodes. These recovery nodes then perform consensus verification on the temporary consensus blocks and submit the verified blocks to the blockchain database. For example, to ensure data integrity and transmissibility, temporary consensus blocks are serialized. Serialization is the process of converting data structures or object states into a format that can be stored or transmitted. The serialized temporary consensus blocks are then sent to recovery nodes, which can be done through communication protocols within the blockchain network, ensuring accurate data transmission to the target node. Upon receiving the serialized temporary consensus blocks, the recovery nodes perform consensus verification, which may include verifying the legality of the blocks, the validity of transactions, and the linking relationships between blocks. If the temporary consensus block passes the consensus verification, the recovery node submits it to the blockchain database. This process permanently stores the block's data on the blockchain, making it part of the blockchain. For example, recovery nodes can also update their local state to record that the temporary consensus block has been successfully submitted to the blockchain, helping to maintain the consistency and integrity of the blockchain system.

[0129] Through the above steps, the blockchain system can ensure the validity and consistency of temporary consensus transaction data, and submit the temporary consensus transaction data that has passed consensus verification to the blockchain after the node recovers, thereby maintaining the stability and reliability of the blockchain system.

[0130] In some embodiments, obtaining a temporary consensus block from temporary consensus transaction data according to a first request, serializing the temporary consensus block, and sending it to a recovery node so that the recovery node can perform consensus verification processing on the temporary consensus block and submit the temporarily consensus block that has passed consensus verification to the blockchain database includes: obtaining a temporary consensus block from temporary consensus transaction data according to a first request, serializing the temporary consensus block, and sending it to a recovery node so that the recovery node receives the temporary consensus block within a first specified time and verifies that the temporary consensus block is legitimate, broadcasting a first vote on the block hash of the temporary consensus block to the entire blockchain network, so that when the number of first votes carrying the block hash of the temporary consensus block received by the recovery node reaches a first vote threshold, adding the voting content of the first vote to the additional data of the temporary consensus block and submitting the temporary consensus block to the blockchain database; and when the number of first votes carrying the block hash of the temporary consensus block received by a normal node reaches the first vote threshold, adding the voting content of the first vote to the additional data of the temporary consensus block and submitting the temporary consensus block to the blockchain database.

[0131] Specifically, a temporary consensus block is retrieved from the temporary consensus transaction data based on a first request. For example, a recovering node (i.e., a node that was shut down due to an abnormal event and subsequently restored to normal) broadcasts a first request to the entire blockchain network to retrieve a temporary consensus block. Upon receiving this first request, a normal node in the blockchain system (i.e., a node unaffected by the abnormal event) extracts the corresponding temporary consensus block from the temporary consensus transaction data based on the information in the first request.

[0132] The temporary consensus block is serialized and then sent to the recovery node. Before being transmitted in the network, the temporary consensus block needs to be serialized, which converts the block's data structure into a format that is easy to transmit and store. This ensures data compatibility and efficient transmission between different nodes. The serialized temporary consensus block is then sent to the recovery node in the blockchain network.

[0133] Then, consensus verification and voting by the recovery nodes are performed. For example, after receiving a temporary consensus block, the recovery node will verify the block's legitimacy (e.g., whether the number of signatures is sufficient) within a preset first specified time period (this first specified time is usually preset based on factors such as the performance of the blockchain system and network latency). If the temporary consensus block passes the legitimacy verification (e.g., the number of signatures is sufficient), the recovery node will broadcast a first vote on the block hash for that block to the entire blockchain network. This vote is essentially an endorsement of the block's legitimacy and includes the block's hash value as a unique identifier for the vote content. The recovery node continuously monitors the voting situation in the blockchain system. When the number of first votes carrying the block hash of the temporary consensus block reaches a first vote threshold (this first vote threshold is usually set based on the number of nodes and consensus mechanism of the blockchain system), the recovery node adds the content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the blockchain database. Meanwhile, normal nodes are also monitoring the voting situation in the blockchain system. When they receive a sufficient number of first votes (reaching the first vote threshold), they will also perform the same operation, that is, add the voting content to the additional data of the temporary consensus block and submit the block to the database.

[0134] During the voting process, if a new vote arrives, both recovering and normal nodes will update the additional data of the temporary consensus block in real time to reflect the latest voting results. When the additional data of the temporary consensus block contains a sufficient number of valid votes, the block is considered to have been confirmed by the blockchain system (or blockchain network) and officially added to the blockchain's on-chain database.

[0135] Through the above process, the blockchain system can efficiently handle node recovery and synchronization issues while ensuring data consistency and security, thus ensuring the stable operation of the entire network.

[0136] In some embodiments, the method further includes: receiving a second request from the recovery node to the entire blockchain network to obtain the next temporary consensus block; obtaining the next temporary consensus block from the temporary consensus transaction data according to the second request, serializing the next temporary consensus block and sending it to the recovery node, so that the recovery node performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the blockchain database.

[0137] In some embodiments, the process of obtaining the next temporary consensus block from the temporary consensus transaction data according to the second request, serializing the next temporary consensus block, and sending it to the recovery node allows the recovery node to perform consensus verification on the next temporary consensus block and submit the verified next temporary consensus block to the blockchain database. This includes: obtaining the next temporary consensus block from the temporary consensus transaction data according to the second request, serializing the next temporary consensus block, and sending it to the recovery node, so that when the recovery node verifies the legitimacy of the next temporary consensus block, it broadcasts the verification to the entire blockchain network. The second vote on the block hash of a temporary consensus block is used to enable a recovering node to add the content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database when the number of second votes carrying the block hash of the next temporary consensus block received by the recovering node reaches the second vote threshold; and when a normal node receives the second vote to add the content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database.

[0138] For example, after successfully receiving and processing the first temporary consensus block, a recovering node will broadcast a second request to the entire blockchain network to obtain the next temporary consensus block. Upon receiving the second request, normal nodes in the blockchain network will prepare to proceed with the next block extraction and sending operation.

[0139] For example, based on the information in the second request, a normal node locates and extracts the next temporary consensus block from the temporary consensus transaction data. Similar to the processing flow of the first temporary consensus block, the normal node serializes the extracted next temporary consensus block and sends it to the recovery node.

[0140] For example, upon receiving the next temporary consensus block, the recovery node first performs a validity check. If the check passes, it broadcasts a second vote on the block hash of the next temporary consensus block to the entire blockchain network. This vote indicates that the recovery node approves the validity of the next temporary consensus block. The recovery node continuously monitors and counts the number of received second votes. When the number of votes reaches a preset threshold, the recovery node adds the content of the second vote to the appendix data of the next temporary consensus block and submits the block to the blockchain database.

[0141] Normal nodes are also counting the number of second votes received. When the number of votes reaches the second vote threshold, normal nodes will also add the content of the second vote to the appendix data of the next temporary consensus block and submit the block to the blockchain database.

[0142] Through the above steps, the recovery node can continuously and orderly receive and process temporary consensus blocks after the anomaly is resolved, ultimately ensuring that the temporary consensus blocks can be safely and reliably submitted to the blockchain database, thereby maintaining the integrity and stability of the blockchain system.

[0143] In some embodiments, the method further includes: receiving a third request broadcast by the recovery node to the entire blockchain network to obtain all remaining transactions of the temporary consensus, wherein the third request is generated by the recovery node when verifying that the next temporary consensus block is not legitimate; obtaining all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data according to the third request, to obtain a first target transaction set; serializing the first target transaction set and sending it to the recovery node, so that the recovery node adds the first target transaction set to the recovery node's local transaction pool and performs the normal consensus process.

[0144] When a recovery node verifies the next temporary consensus block, if it finds that a temporary consensus block lacks legitimacy (e.g., insufficient signatures, corrupted block data, signature verification failure), the recovery node will generate a third request. This third request retrieves all transactions from the target block height (i.e., the height of the last successfully synchronized block) to the point where the temporary consensus stops. The recovery node broadcasts this third request to the entire blockchain network, requesting all normal nodes to provide this transaction data.

[0145] For example, after receiving the third request, a normal node (or consensus node) in the blockchain system will retrieve all transactions from the temporary consensus transaction data, starting from the target block height and ending at the temporary consensus point, based on the target block height in the third request. These transactions are collected to form the first target transaction set. The normal node serializes the first target transaction set to ensure data integrity and readability during transmission. The serialized first target transaction set is then sent to the recovery node.

[0146] For example, after receiving the first set of target transactions, the recovery node adds these first target transactions to its local transaction pool. Subsequently, the recovery node initiates the normal consensus process to process and reach consensus on these first target transactions. Since the temporary consensus state is now closed or no longer needed, the recovery node will proceed with consensus according to the normal consensus rules of the blockchain, ensuring the legality of the transactions and the integrity of the blockchain.

[0147] For example, the normal consensus rule can be the Byzantine Fault Tolerance (BFT) consensus rule. For example, for BFT consensus, a maximum of f nodes are allowed to be abnormal in the blockchain. When the data center is damaged, the remaining nodes in the blockchain must meet the 3f+1 (or 2f+1) rule in the BFT consensus.

[0148] This processing mechanism provides a clear recovery path for recovery nodes when an invalid temporary consensus block occurs. By acquiring and processing all transactions from the target block height to the temporary consensus halt, recovery nodes can seamlessly transition to the normal consensus process, thus preventing the entire blockchain system from stalling due to the invalidity of a single temporary consensus block.

[0149] In some embodiments, the method further includes: receiving a fourth request broadcast by the recovery node to the entire blockchain network to obtain all transactions within the temporary consensus range, wherein the fourth request is generated when the recovery node does not receive a temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed; obtaining all transactions within the temporary consensus range from the temporary consensus transaction data according to the fourth request to obtain a second target transaction set; serializing the second target transaction set and sending it to the recovery node so that the recovery node adds the second target transaction set to the recovery node's local transaction pool and performs the normal consensus process.

[0150] To address situations where a recovery node fails to receive a temporary consensus block within the first specified time, or receives a temporary consensus initiation request after the second specified time, the method further provides a processing mechanism. This mechanism ensures that the recovery node can successfully join the normal consensus process of the blockchain by receiving a fourth request from the recovery node and sending all transactions within the temporary consensus range. The second specified time is longer than the first specified time.

[0151] For example, if a recovery node does not receive any temporary consensus blocks within the first specified time, it may assume that it has missed some important block data. Therefore, it will generate a fourth request to retrieve all transactions from the start of the temporary consensus to the current time range.

[0152] For example, if a recovery node suddenly receives a request to initiate temporary consensus after the second specified time has elapsed, it may mean that it has been disconnected from the blockchain network or failed to synchronize data in a timely manner during a previous period. In this case, the recovery node will also generate a fourth request to obtain all transactions within the full scope of the temporary consensus.

[0153] In either case, the recovering node will broadcast the generated fourth request to the entire blockchain network, requesting all normal nodes to provide all transactions within the scope of temporary consensus.

[0154] For example, after receiving the fourth request, a normal node will extract all transactions within the temporary consensus range from the temporary consensus transaction data to form a second target transaction set. This second target transaction set contains all transactions from the start of the temporary consensus to the current time (or the time specified in the request). The normal node then serializes the second target transaction set and sends it to the recovery node.

[0155] For example, after receiving the second set of target transactions, the recovery node adds these transactions to its local transaction pool. Then, the recovery node initiates the normal consensus process to process and reach consensus on these second target transactions. Since the recovery node has now acquired the complete transaction data within the temporary consensus scope, it can seamlessly integrate into the blockchain's normal consensus process, ensuring the integrity and consistency of the blockchain.

[0156] This processing mechanism effectively addresses the potential problems faced by recovery nodes when they do not receive a temporary consensus block or receive a temporary consensus activation request after a specific time. It ensures that recovery nodes can obtain all necessary transaction data and smoothly transition to the normal consensus process, thereby improving the stability and reliability of the blockchain system.

[0157] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0158] This application embodiment initiates a transaction through a temporary consensus mechanism, where any normal node in the blockchain responds to a temporary consensus. This temporary consensus state is achieved by generating a multi-signature transaction through joint signatures of all normal nodes in the event of a node anomaly. In the temporary consensus state, all normal nodes jointly perform a temporary consensus operation to provide transaction services to external parties. The temporary consensus transaction data generated during the process is recorded. All normal nodes then perform consensus verification on the temporary consensus transaction data, and the verified temporary consensus transaction data is submitted to the blockchain. By introducing a temporary consensus mechanism, this application embodiment ensures that the blockchain system continues to provide transaction services even when a node anomaly occurs, significantly improving the availability and stability of the blockchain system. In this process, when an abnormal event occurs on a blockchain node, a temporary consensus state is initiated through normal nodes, allowing the system to continue providing transaction services. During the temporary consensus state, all normal nodes work together to reach a temporary consensus, enabling all normal nodes to provide transaction services. The temporary consensus transaction data generated during the temporary consensus process is recorded and verified. Only temporary consensus transaction data that passes the consensus verification is submitted to the blockchain, ensuring data security and consistency and avoiding data loss or inconsistency issues caused by abnormal events.

[0159] Please see Figure 5 , Figure 5 This is a second flowchart illustrating the consensus method for a blockchain provided in this application. The blockchain includes at least one recovery node and at least one normal node. The recovery node is the node that recovers from an abnormal node following a node anomaly event, and the normal node is the normal node in the blockchain at the time of the node anomaly event. The method is executed by any one of the recovery nodes and may include the following steps:

[0160] Step 210: Broadcast the first request to obtain the temporary consensus block to the entire blockchain network.

[0161] For example, after an abnormal node recovers from a node anomaly, a recovered node is created. Once recovered, these nodes need to acquire the temporary consensus blocks generated by the normal nodes during the anomaly period to synchronize with the latest blockchain state. Therefore, any recovered node in the blockchain will broadcast a first request to the entire network, requesting to acquire these temporary consensus blocks. This first request might include the recovered node's identity and information about the temporary consensus blocks it needs to acquire (such as block height and hash value).

[0162] Step 220: Receive the temporary consensus block sent by the normal node. The temporary consensus block is obtained by the normal node upon receiving the first request, retrieving the temporary consensus block from the temporary consensus transaction data according to the first request, serializing the temporary consensus block, and sending it to the recovery node. The temporary consensus transaction data is obtained by the normal node responding to the temporary consensus to start a transaction, initiating the temporary consensus state, and, in the temporary consensus state, collaborating with all normal nodes to perform temporary consensus operations, so as to provide transaction services to the outside world through all normal nodes in the temporary consensus, and recording the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus to start a transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormal event in the blockchain.

[0163] For example, after receiving the first request, a normal node will obtain the corresponding temporary consensus block from the temporary consensus transaction data based on the information in the first request, and then serialize the temporary consensus block and send it to the recovery node.

[0164] Among them, temporary consensus transaction data is the transaction data generated by a normal node after responding to the temporary consensus to start a transaction, starting a temporary consensus state, and conducting temporary consensus in this temporary consensus state.

[0165] Among them, the temporary consensus initiation transaction is a multi-signature transaction generated by all normal nodes jointly signing when a node abnormal event occurs in the blockchain, which is used to initiate a temporary consensus state.

[0166] In the temporary consensus state, all normal nodes jointly perform temporary consensus operations, packaging the transactions generated during the temporary consensus process into blocks, namely temporary consensus blocks.

[0167] Step 230: Perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed the consensus verification to the blockchain database.

[0168] For example, after receiving a temporary consensus block, a recovery node in a blockchain needs to perform consensus verification to ensure the block's legitimacy and correctness. Only verified temporary consensus blocks can be submitted to the blockchain's database, thereby synchronizing the blockchain state. For example, the verification process includes, but is not limited to, the block's hash value, transaction validity, timestamp, and signature. The recovery node uses its own algorithms and rules to verify the received temporary consensus blocks, ensuring they conform to the blockchain's consensus protocol and rules. For example, if a temporary consensus block passes the consensus verification process, the recovery node submits it to the blockchain's database, thus updating and synchronizing the blockchain state. For example, if a temporary consensus block fails the consensus verification process, the recovery node can discard it.

[0169] In some embodiments, consensus verification processing is performed on the temporary consensus block, and the temporarily consensus block that has passed consensus verification is submitted to the blockchain database. This includes: when a temporary consensus block is received within a first specified time and its legality is verified, a first vote for the block hash of the temporary consensus block is broadcast to the entire blockchain network, so that when the number of first votes carrying the block hash of the temporary consensus block received by normal nodes reaches a first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the blockchain database; and when the number of first votes carrying the block hash of the temporary consensus block received by a recovery node reaches the first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the blockchain database.

[0170] For example, after receiving a temporary consensus block, a recovery node will verify its legitimacy within a pre-defined first specified time. If the temporary consensus block passes the legitimacy verification, the recovery node will broadcast a first vote on the block hash to the entire blockchain network. This vote is essentially an endorsement of the block's legitimacy and includes the block's hash value as a unique identifier for the vote. The recovery node continuously monitors the voting situation in the blockchain system. When the number of first votes carrying the block hash of the temporary consensus block reaches a first vote threshold (this first vote threshold is usually set based on the number of nodes and consensus mechanism in the blockchain system), the recovery node adds the first vote's content to the additional data of the temporary consensus block and submits the temporary consensus block to the blockchain database. Simultaneously, normal nodes also monitor the voting situation in the blockchain system. When they receive a sufficient number of first votes (reaching the first vote threshold), they will also perform the same operation, adding the vote's content to the additional data of the temporary consensus block and submitting the block to the database.

[0171] During the voting process, if a new vote arrives, both recovering and normal nodes will update the additional data of the temporary consensus block in real time to reflect the latest voting results. When the additional data of the temporary consensus block contains a sufficient number of valid votes, the block is considered to have been confirmed by the blockchain system (or blockchain network) and officially added to the blockchain's on-chain database.

[0172] Through the above process, the blockchain system can efficiently handle node recovery and synchronization issues while ensuring data consistency and security, thus ensuring the stable operation of the entire network.

[0173] In some embodiments, the method further includes: broadcasting a second request to the entire blockchain network to obtain the next temporary consensus block; receiving the next temporary consensus block sent by a normal node, wherein the next temporary consensus block is obtained by the normal node from the temporary consensus transaction data according to the second request, and serializing the next temporary consensus block before sending it to the recovery node; performing consensus verification processing on the next temporary consensus block, and submitting the next temporary consensus block that has passed consensus verification to the blockchain database.

[0174] In some embodiments, consensus verification processing is performed on the next temporary consensus block, and the next temporary consensus block that passes consensus verification is submitted to the blockchain database. This includes: when verifying the legitimacy of the next temporary consensus block, broadcasting a second vote for the block hash of the next temporary consensus block to the entire blockchain network, so that when normal nodes receive the number of second votes carrying the block hash of the next temporary consensus block, they add the voting content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database; and when a recovery node receives the number of second votes carrying the block hash of the next temporary consensus block, it adds the voting content of the second vote to the additional data of the next temporary consensus block and submits the next temporary consensus block to the blockchain database.

[0175] For example, after successfully receiving and processing the first temporary consensus block, a recovering node will broadcast a second request to the entire blockchain network to obtain the next temporary consensus block. Upon receiving the second request, normal nodes in the blockchain network will prepare to proceed with the next block extraction and sending operation.

[0176] For example, based on the information in the second request, a normal node locates and extracts the next temporary consensus block from the temporary consensus transaction data. Similar to the processing flow of the first temporary consensus block, the normal node serializes the extracted next temporary consensus block and sends it to the recovery node.

[0177] For example, upon receiving the next temporary consensus block, the recovery node first performs a validity check. If the check passes, it broadcasts a second vote on the block hash of the next temporary consensus block to the entire blockchain network. This vote indicates that the recovery node approves the validity of the next temporary consensus block. The recovery node continuously monitors and counts the number of received second votes. When the number of votes reaches a preset threshold, the recovery node adds the content of the second vote to the appendix data of the next temporary consensus block and submits the block to the blockchain database.

[0178] Meanwhile, normal nodes are also counting the number of second votes received. When the number of votes reaches the second vote threshold, normal nodes will also add the content of the second vote to the appendix data of the next temporary consensus block and submit the block to the blockchain database.

[0179] Through the above steps, the recovery node can continuously and orderly receive and process temporary consensus blocks after the anomaly is resolved, ultimately ensuring that the temporary consensus blocks can be safely and reliably submitted to the blockchain database, thereby maintaining the integrity and stability of the blockchain system.

[0180] In some embodiments, the method further includes: after submitting the next temporary consensus block to the blockchain's database, determining whether the next temporary consensus block is a block where temporary consensus is closed; if the next temporary consensus block is determined to be a block where temporary consensus is closed, then proceeding with the normal consensus process; or if the next temporary consensus block is determined not to be a block where temporary consensus is closed, then returning to the step of executing a second request to obtain the next temporary consensus block broadcast to the entire blockchain network.

[0181] After submitting the next temporary consensus block, the recovery node needs to determine whether the block is a temporary consensus closure block. This is to determine whether the temporary consensus state should be ended and the normal consensus process resumed.

[0182] For example, a recovery node can determine whether the next temporary consensus block is a temporarily closed block based on specific markers or data in the block. For instance, the next temporary consensus block might contain a special field or identifier indicating that it is a temporarily closed block. If the recovery node determines that the next temporary consensus block is a temporarily closed block, it means the temporary consensus state has ended, and the blockchain system should revert to the normal consensus process. At this point, the recovery node will stop broadcasting requests to retrieve temporary consensus blocks and participate in the normal consensus process. This means that all nodes will reach a consensus according to the normal consensus rules of the blockchain system and submit blocks to the database.

[0183] For example, if the recovery node determines that the next temporary consensus block is not the block that closes the temporary consensus, it means that the temporary consensus state needs to continue. In this case, the recovery node will return to the step of executing the second request to broadcast to the entire blockchain network to obtain the next temporary consensus block. This means that the recovery node will continue to request the next temporary consensus block and repeat the consensus verification and processing flow described above until it receives the block that closes the temporary consensus.

[0184] Through the above processing steps, the recovery node can ensure that the blockchain system can correctly switch between the temporary consensus state and the normal consensus state. This helps to quickly restore and continue operating the blockchain system when it encounters failures or abnormal situations through the temporary consensus mechanism, while ensuring that it can seamlessly return to the normal consensus process after it is restored to normal.

[0185] In some embodiments, the method further includes: broadcasting a third request to the entire blockchain network to obtain all remaining transactions of the temporary consensus, the third request being generated by the recovery node; receiving a first target transaction set sent by a normal node, the first target transaction set being obtained by the normal node according to the third request, which obtains all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data, serializes the first target transaction set, and sends it to the recovery node; adding the first target transaction set to the local transaction pool of the recovery node, and performing the normal consensus process.

[0186] When a recovery node verifies the next temporary consensus block, if it finds that a temporary consensus block lacks legitimacy (e.g., corrupted block data, failed signature verification), the recovery node generates a third request. This third request retrieves all transactions from the target block height (i.e., the height of the last successfully synchronized block) to the point where the temporary consensus stops. The recovery node broadcasts this third request to the entire blockchain network, requesting all normal nodes to provide this transaction data.

[0187] For example, after receiving the third request, a normal node (or consensus node) in the blockchain system will retrieve all transactions from the temporary consensus transaction data, starting from the target block height and ending at the temporary consensus point, based on the target block height in the third request. These transactions are collected to form the first target transaction set. The normal node serializes the first target transaction set to ensure data integrity and readability during transmission. The serialized first target transaction set is then sent to the recovery node.

[0188] For example, after receiving the first set of target transactions, the recovery node adds these transactions to its local transaction pool. Then, the recovery node initiates the normal consensus process to process and reach consensus on these first-target transactions. Since the temporary consensus state is now closed or no longer needed, the recovery node will proceed with consensus according to the normal rules of the blockchain, ensuring the legality of the transactions and the integrity of the blockchain.

[0189] This processing mechanism provides a clear recovery path for recovery nodes when an invalid temporary consensus block occurs. By acquiring and processing all transactions from the target block height to the temporary consensus halt, recovery nodes can seamlessly transition to the normal consensus process, thus preventing the entire blockchain system from stalling due to the invalidity of a single temporary consensus block.

[0190] In some embodiments, the method further includes: broadcasting a fourth request to the entire blockchain to obtain all transactions within the temporary consensus range, the fourth request being generated when the recovery node does not receive a temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time; receiving a second target transaction set sent by a normal node, the second target transaction set being obtained by the normal node from all transactions within the temporary consensus range obtained from the temporary consensus transaction data according to the fourth request, serializing the second target transaction set and sending it to the recovery node; adding the second target transaction set to the local transaction pool of the recovery node and performing the normal consensus process.

[0191] To address situations where a recovery node fails to receive a temporary consensus block within the first specified time, or receives a temporary consensus initiation request after the second specified time, the method further provides a processing mechanism. This mechanism ensures that the recovery node can successfully join the normal consensus process of the blockchain by receiving a fourth request from the recovery node and sending all transactions within the temporary consensus range. The second specified time is longer than the first specified time.

[0192] For example, if a recovery node does not receive any temporary consensus blocks within the first specified time, it may assume that it has missed some important block data. Therefore, it will generate a fourth request to retrieve all transactions from the start of the temporary consensus to the current time range.

[0193] For example, if a recovery node suddenly receives a request to initiate temporary consensus after the second specified time has elapsed, it may mean that it has been disconnected from the blockchain network or failed to synchronize data in a timely manner during a previous period. In this case, the recovery node will also generate a fourth request to obtain all transactions within the full scope of the temporary consensus.

[0194] In either case, the recovering node will broadcast the generated fourth request to the entire blockchain network, requesting all normal nodes to provide all transactions within the scope of temporary consensus.

[0195] For example, after receiving the fourth request, a normal node will extract all transactions within the temporary consensus range from the temporary consensus transaction data to form a second target transaction set. This second target transaction set contains all transactions from the start of the temporary consensus to the current time (or the time specified in the request). The normal node then serializes the second target transaction set and sends it to the recovery node.

[0196] For example, after receiving the second set of target transactions, the recovery node adds these transactions to its local transaction pool. Then, the recovery node initiates the normal consensus process to process and reach consensus on these second target transactions. Since the recovery node has now acquired the complete transaction data within the temporary consensus scope, it can seamlessly integrate into the blockchain's normal consensus process, ensuring the integrity and consistency of the blockchain.

[0197] This processing mechanism effectively addresses the potential problems faced by recovery nodes when they do not receive a temporary consensus block or receive a temporary consensus activation request after a specific time. It ensures that recovery nodes can obtain all necessary transaction data and smoothly transition to the normal consensus process, thereby improving the stability and reliability of the blockchain system.

[0198] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0199] This application embodiment involves a recovery node broadcasting a first request to the entire blockchain network to obtain a temporary consensus block; receiving temporary consensus blocks sent by normal nodes, whereby normal nodes, upon receiving the first request, retrieve the temporary consensus block from the temporary consensus transaction data, serialize the temporary consensus block, and send it to the recovery node; the temporary consensus transaction data is obtained by normal nodes responding to the temporary consensus to initiate a transaction, activating a temporary consensus state, and, in this state, collaborating with all normal nodes to perform temporary consensus operations to provide transaction services externally through all normal nodes in the temporary consensus process, as well as recording the temporary consensus transaction data generated during the temporary consensus process; the temporary consensus to initiate a transaction is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain; and consensus verification processing is performed on the temporary consensus block, and the temporarily consensus block that passes consensus verification is submitted to the blockchain database. This application embodiment, by introducing a temporary consensus mechanism, ensures that the blockchain system continues to provide transaction services externally when a node anomaly occurs, significantly improving the availability and stability of the blockchain system.

[0200] The consensus method for blockchain provided in the embodiments of this application will be described below. Please refer to [link / reference]. Figure 6 , Figure 6 This is a first interaction diagram illustrating a blockchain consensus method provided in an embodiment of this application, wherein... Figure 6 It mainly includes the process of starting temporary consensus, the process during temporary consensus, and the process of closing temporary consensus.

[0201] The process of initiating temporary consensus includes the following steps:

[0202] S1. After a node malfunctions, the client generates a temporary consensus activation transaction based on a manually triggered temporary consensus activation request. This temporary consensus activation transaction is a multi-signature transaction generated by all normal nodes jointly signing in the event of a node malfunction in the blockchain.

[0203] S2. After the client serializes the temporary consensus transaction, it sends it to each normal node;

[0204] S3. After a normal node receives a temporary consensus to initiate a transaction, it reaches a consensus on the temporary consensus to initiate the transaction.

[0205] S4. After reaching a consensus within the scope of the temporary consensus nodes, the normal nodes will adjust their local consensus state to temporary consensus to enable the temporary consensus state.

[0206] The process in the temporary consensus includes the following steps:

[0207] S5. Each normal node checks whether its local consensus status is in a temporary consensus; if yes, proceed to step S6; if no, proceed to step S7.

[0208] S6. If the local consensus state is found to be in a temporary consensus state, then all normal nodes reach a consensus within the consensus node set corresponding to the temporary consensus state; then proceed to step S8.

[0209] S7. If it is found that the local consensus state is not in the temporary consensus state, then each normal node reaches consensus within the set of consensus nodes corresponding to all normal consensus states in the blockchain.

[0210] S8. In the temporary consensus state, all normal nodes work together to perform temporary consensus operations so that all normal nodes can provide transaction services to the outside world through the temporary consensus.

[0211] S9. Each normal node records the temporary consensus transaction data generated during the temporary consensus process.

[0212] The process for closing temporary consensus:

[0213] S10. After the node recovers, the client generates a temporary consensus shutdown transaction based on the manually triggered temporary consensus shutdown request. This temporary consensus shutdown transaction is a multi-signature transaction generated by all normal nodes in the blockchain that were present when the node abnormal event occurred, after the abnormal node corresponding to the node abnormal event has recovered to normal.

[0214] S11. After the client serializes the temporary consensus closing transaction, it sends it to each normal node;

[0215] S12. After receiving the temporary consensus closing transaction, the normal node reaches a consensus on the temporary consensus closing transaction and achieves agreement;

[0216] S13. Normal nodes will adjust their local consensus status to "closed in temporary consensus"; subsequent transactions will require participation from all consensus nodes.

[0217] The consensus method for blockchain provided in the embodiments of this application will be described below. Please refer to [link / reference]. Figure 7 , Figure 7 This is a second interactive schematic diagram of a blockchain consensus method provided in an embodiment of this application, wherein, Figure 7 This mainly includes the consensus verification process after an abnormal node recovers, comprising the following steps:

[0218] S14. Any recovery node broadcasts its first request to the entire network to obtain a temporary consensus block;

[0219] S15. Each normal node serializes the temporary consensus block according to the first request and sends it to the recovery node;

[0220] S16. Does the recovery node receive a response within the specified time? If yes, proceed to step S17. If no (i.e., the recovery node does not receive a response within the specified time), it indicates that the temporary consensus operation was not performed or there was a timeout or other reason. Then proceed to step S42 to carry out the normal consensus process.

[0221] S17. If the recovery node receives a response within the specified time, it further verifies the legality of the temporary consensus block; if it is not legal, it executes step S18; if it is legal, it executes step S19; for example, verifying legality means verifying whether the number of signatures corresponding to the temporary consensus block is sufficient. If the number of signatures is sufficient, it is legal; if the number of signatures is insufficient, it is not legal.

[0222] S18. If the temporary consensus block is invalid, the recovery node discards the temporary consensus block;

[0223] S19. If the temporary consensus block is valid, the restoring nodes vote on the block hash of the temporary consensus block and broadcast the first vote on the block hash of the temporary consensus block to the entire network;

[0224] S20. The normal node receives enough votes for the temporary consensus block, that is, the number of first votes received by the normal node carrying the block hash of the temporary consensus block reaches the first vote threshold.

[0225] S21. Normal nodes add the voting content of the first vote to the additional data of the temporary consensus block and submit the temporary consensus block; where "submit the temporary consensus block" means that the temporary consensus block is officially recognized, that is, written to the database;

[0226] S22. The recovery node receives enough votes for the temporary consensus block, that is, the number of first votes received by the recovery node carrying the block hash of the temporary consensus block reaches the first vote threshold.

[0227] S23. The recovering node adds the voting content of the first vote to the additional data of the temporary consensus block and commits the temporary consensus block;

[0228] S24. The recovery node broadcasts its second request to the entire network to obtain the next temporary consensus block;

[0229] S25. The normal node serializes the next temporary consensus block according to the second request and sends it to the recovery node;

[0230] S26. The recovery node executes the transactions in the next temporary consensus block and generates the corresponding block hash.

[0231] S27. The recovery node verifies the legality of the next temporary consensus block; if legal, proceed to step S28; if not legal, proceed to step S35.

[0232] S28. If the next temporary consensus block is valid, the recovery node votes on the block hash of the next temporary consensus block and broadcasts the second vote on the block hash of the next temporary consensus block to the entire network; then execute steps S29 and S31.

[0233] S29. When a normal node receives enough votes for the next temporary consensus block, that is, when the number of second votes received by a normal node carrying the block hash of the next temporary consensus block reaches the second vote threshold, it means that the next temporary consensus block is officially recognized.

[0234] S30. Normal nodes add the voting content of the second vote to the additional data of the next temporary consensus block and commit the next temporary consensus block;

[0235] S31. The recovery node receives enough votes for the next temporary consensus block, that is, the number of second votes received by the recovery node carrying the block hash of the next temporary consensus block reaches the second vote threshold;

[0236] S32. The recovery node adds the voting content of the second vote to the AdditionalData of the next temporary consensus block and commits the next temporary consensus block;

[0237] S33. The recovery node determines whether the next temporary consensus block is a block where temporary consensus is closed; if yes, proceed to step S42; if no, return to step S24, and the recovery node broadcasts a second request to the entire network to obtain the next temporary consensus block.

[0238] S34. If the next temporary consensus block is invalid, the recovery node generates a third request to obtain all remaining transactions for the temporary consensus and broadcasts it across the network;

[0239] S35. The normal node obtains all transactions from the target block height to the end of the temporary consensus based on the third request, thus obtaining the first target transaction set;

[0240] S36. The normal node serializes the first target transaction set and sends it to the recovery node (i.e., the requesting node);

[0241] S37. The recovery node (i.e., the requesting node) adds the serialized first target transaction set to the local transaction pool; then it executes step S42 to proceed with the normal consensus process;

[0242] S38. If the recovery node does not receive the temporary consensus block within the first specified time, or receives the temporary consensus start request after the second specified time, it generates a fourth request to obtain all transactions within the scope of the temporary consensus and broadcasts it across the network.

[0243] S39. The normal node obtains all transactions within the temporary consensus range from the temporary consensus transaction data according to the fourth request, and obtains the second target transaction set;

[0244] S40. The normal node serializes the second target transaction set and sends it to the recovery node (i.e., the requesting node);

[0245] S41. The recovery node (i.e., the requesting node) adds the received serialized second target transaction set to the local transaction pool;

[0246] S42. Resume the node to proceed with the normal consensus process.

[0247] The specific implementation methods corresponding to each step in the above-described interactive process in this application embodiment can be found in the embodiments corresponding to the first and second flowcharts described above. For the sake of brevity, they will not be repeated here.

[0248] The consensus method for blockchain provided in the embodiments of this application will be described below. Please refer to [link / reference]. Figures 8 to 12 , Figures 8 to 12 These are all schematic diagrams illustrating application scenarios of the blockchain consensus method provided in the embodiments of this application.

[0249] like Figure 8 The diagram shown illustrates the consensus processing flow of two data center rooms (Data Center 1 and Data Center 2) in a blockchain system under specific conditions. The blockchain system consists of multiple nodes (Node 1 to Node 8), which communicate and exchange information through a series of blocks (Block(0) to Block(100)).

[0250] Data Center 1 comprises four nodes (Node1 to Node4), and Data Center 2 comprises four nodes (Node5 to Node8). Under normal circumstances, both Data Center 1 and Data Center 2 operate normally, and their nodes participate in the consensus process of the blockchain system. Nodes update and synchronize the blockchain state by sending and receiving data blocks.

[0251] For example, if all services in Data Center 1 become abnormal due to special reasons (such as a system outage), it means that all services in Data Center 1 are temporarily suspended. In this case, because the required number of nodes for normal consensus cannot be met (e.g., for 8 nodes, at least 6 nodes are needed to participate in the consensus), the nodes in Data Center 1 cannot continue to participate in the consensus process of the blockchain system and cannot provide external services. Although Data Center 1 is abnormal, Data Center 2 can still operate normally.

[0252] For example, in order to maintain the operation of the blockchain system and provide external services, using the consensus method described in the embodiments of this application, all organizations in Data Center 2 jointly submitted a multi-signature transaction (i.e., a temporary consensus initiation transaction) to indicate the initiation of temporary consensus.

[0253] For example, in a temporary consensus state, all organizations (Nodes 5 through 8) in Data Center 2 will unite to reach a consensus in order to continue processing transactions and generating blocks. In this temporary consensus state, the generated blocks are marked as "temporary consensus blocks" (i.e., temporary consensus blocks), such as Block(101) through Block(200). These "temporary consensus blocks" exist as temporary records (i.e., temporary consensus transaction data) until Data Center 1 resumes service, ensuring the continuity and availability of the blockchain system.

[0254] For example, when the service in Data Center 1 is restored, all organizations (Node5 to Node8) in Data Center 2 jointly submit another multisignature transaction (i.e., a temporary consensus closure transaction) to indicate the closure of the temporary consensus.

[0255] At this point, the blockchain system will resume its normal consensus process. After the temporary consensus is restored and shut down in Data Center 1, the generated blocks are marked as "final consensus blocks," such as Block(0) to Block(201). Block(101) is a special block indicating the activation of temporary consensus, recording the start time of handling the anomaly and related states; Block(201) is a special block indicating the closure of temporary consensus, recording the state of node recovery and consensus achievement. These "final consensus blocks" represent the transactions and states jointly recognized by all nodes during and after the anomaly in Data Center 1.

[0256] like Figure 9 The diagram illustrating the second application scenario demonstrates the first abnormal scenario in a blockchain system. The diagram shows a blockchain system containing a certain number of nodes. These nodes play a crucial role in the blockchain system, collectively maintaining its integrity and consistency.

[0257] Under normal circumstances, all nodes operate according to the rules and participate in the consensus process. However, in some cases, abnormal nodes may appear, which may be unable to participate in the consensus process normally due to various reasons (such as anomalies, network failures, etc.).

[0258] In a blockchain system, reaching consensus requires the participation of a sufficient number of legitimate nodes. For example... Figure 9The first abnormal scenario shown involves a relatively small number of abnormal nodes, but the remaining nodes are indeed unable to satisfy the BFT consensus rules (such as 3f+1 or 2f+1). For example, taking the 2f+1 consensus rule as an example, when the number of abnormal nodes is less than 2f+1 (where f=2), the abnormal nodes cannot affect the consensus of the entire system. For instance, if the total number of blockchain nodes is 8 and f=2, then a maximum of 2 abnormal nodes are allowed, while 4 abnormal nodes cannot satisfy the consensus requirement of 2f+1=5. In this case, the blockchain system will not be able to reach a consensus normally. Similarly, the number of abnormal nodes also cannot meet the condition. For example, the following could occur: Figure 9 The following situation is shown:

[0259] When an abnormal node is detected in the blockchain system, the remaining normal nodes will start the abnormal handling process; the normal nodes will temporarily reach a consensus and generate a special block Block(101) to mark the start of the processing; this special block Block(101) plays the role of a "marker" in the blockchain, which records the start time of the abnormal handling and related states.

[0260] As other nodes recover, the blockchain system will continue to generate new special blocks Block(201); under the identifier of the new special block Block(201), the newly generated Block(201) will record the state of node recovery and consensus.

[0261] Once all nodes in the blockchain system have recovered and reached a consensus again, the blockchain environment will return to normal. At this point, the blockchain system will continue to operate according to its normal consensus mechanism.

[0262] like Figure 10 The diagram shown in the third application scenario illustrates the application of... Figure 9The first abnormal scenario illustrated presents a possible outcome. When an abnormal node appears in the blockchain system, if the number of abnormal nodes is insufficient to meet the consensus requirements, the system will quickly activate the abnormal node mechanism (i.e., the temporary consensus mechanism). This temporarily removes these abnormal nodes from the blockchain system to ensure that the surviving normal nodes can continue to operate stably and maintain the integrity of the blockchain. At this time, the surviving nodes will activate the temporary consensus mechanism to continue processing transactions even without enough nodes participating in the formal consensus. During the abnormal node's abnormal period, the system will attempt to restore the normal functionality of these abnormal nodes. During the recovery process, the system will strictly check the integrity and consistency of the blockchain. If the recovery is successful, and these recovered nodes (the successfully recovered abnormal nodes) restart, they will attempt to rejoin the blockchain system. However, since the surviving normal nodes have already been running based on the temporary consensus for some time, the restarted recovered nodes will not directly reach consensus with other restarted nodes, but will rely on the temporary consensus transaction data of the currently surviving normal nodes.

[0263] If the provisional consensus state is correct, meaning there are no data issues or errors, the entire blockchain system will use blocks generated based on this provisional consensus, thus continuing the provisional consensus. This means the blockchain will accept and apply these transactions and blocks generated by surviving, healthy nodes during the period when the abnormal node was active. However, if potential problems or errors are discovered during the recovery process or when verifying the provisional consensus transaction data, the system will take immediate action. This may include isolating the problematic node, rolling back to a previous safe state, or restarting the consensus process. The system will overturn the original provisional consensus and reach a new consensus to ensure the security and stability of the entire blockchain system remain unaffected.

[0264] Regarding the first abnormal scenario, after the actual blockchain system recovers, the following will occur: Figure 10 The two possible processing results are shown below:

[0265] Ultimately, the entire blockchain cluster agrees that if the temporary consensus transaction data is without problems, or if the problems are properly resolved, the restarted recovery node will successfully return to the blockchain system, and the entire blockchain cluster will recognize and continue to operate based on this temporary consensus transaction data.

[0266] Ultimately, the entire blockchain cluster may not recognize (or may only recognize a portion of) the data: If the temporary consensus transaction data has serious problems and cannot be accepted by the system, or if the restarted recovery node encounters irreconcilable disagreements when rejoining the blockchain system, then the entire blockchain cluster may not be able to fully recognize the data brought by the temporary consensus block, for example, an error is found in Block(106).

[0267] Therefore, in response to Figure 9 and Figure 10 The first abnormal scenario that occurs and the possible handling results can be described as follows: Figure 7 The consensus verification process shown is used to process temporary consensus transaction data after the abnormal node recovers to normal, so as to re-verify or re-reach consensus on the temporary consensus transaction data. Only when the requirements of the original algorithm are met can a true consensus be reached.

[0268] like Figure 11 The diagram illustrating the fourth application scenario demonstrates a second abnormal scenario in a blockchain system. In this second abnormal scenario, there are a large number of abnormal blockchain nodes, so many that they might reach a consensus. In this case, it is necessary to consider whether these recoverable nodes (abnormal nodes that have recovered to normal) will be the first to reach a consensus after restarting. In this embodiment, it is required that after these recoverable nodes start up, they first need to broadcast to the entire network to obtain a temporary consensus state. However, this does not exclude the possibility that they may not receive the message due to special reasons, or that malicious nodes may deliberately pretend that they have not received the proposal.

[0269] For example, if the total number of blockchain nodes is 8 and f = 2, then a maximum of 2 nodes are allowed to be abnormal. If the current number of abnormal nodes is 5, then 5 abnormal nodes cannot satisfy the consensus requirement of 2f + 1 = 5. In this case, the abnormal nodes may reach a consensus. Therefore, an inclusion relationship may form, such as... Figure 11 The new consensus shown includes transactions from the temporary consensus, such as a block generated by a recovering node containing transactions from the original Block (103), but with inconsistent block hashes. Regarding... Figure 11 As shown, the system needs to ensure that this inclusion relationship is handled correctly when merging consensus, so as to avoid transaction duplication or omission.

[0270] like Figure 12 The diagram shown in the fifth application scenario illustrates the application of... Figure 11 The second abnormal scenario shown is the possible handling result.

[0271] Regarding the second abnormal scenario, after the actual blockchain system recovers, the following will occur: Figure 11 The two possible processing results are shown below:

[0272] (1) The entire blockchain cluster eventually recognizes: for example, the transactions in the block are consistent, but the block hashes are different, and Block(102) will contain the contents of temporary Block(101) and Block(102).

[0273] (2) The entire blockchain cluster does not recognize it: for example, Block(102) will contain the contents of temporary Block(101) and Block(102), and an error is found in Block(103).

[0274] Therefore, in response to Figure 11 and Figure 12 The second abnormal scenario and its possible handling results can be addressed using methods such as... Figure 7 The consensus verification process shown is used to process temporary consensus transaction data after the abnormal node recovers to normal, so as to re-verify or re-reach consensus on the temporary consensus transaction data. Only when the requirements of the original algorithm are met can a true consensus be reached.

[0275] To facilitate better implementation of the blockchain consensus method of this application embodiment, this application embodiment also provides a blockchain consensus apparatus. Please refer to... Figure 13 , Figure 13 This is a first structural schematic diagram of a blockchain consensus device provided in an embodiment of this application. The blockchain includes at least one normal node and at least one abnormal node. The blockchain consensus device 300 is mounted on any one of the normal nodes. The blockchain consensus device 300 may include:

[0276] The activation unit 310 is used to respond to the temporary consensus to activate the transaction and activate the temporary consensus state. The temporary consensus to activate the transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormal event in the blockchain.

[0277] Consensus Unit 320 is used to unite all normal nodes to perform temporary consensus operations in the temporary consensus state, so as to provide transaction services to the outside world through all normal nodes of temporary consensus;

[0278] Recording unit 330 is used to record temporary consensus transaction data generated during the temporary consensus process;

[0279] The first processing unit 340 is used to perform consensus verification processing on the temporary consensus transaction data through all normal nodes, and submit the temporary consensus transaction data that has passed the consensus verification to the blockchain.

[0280] In some embodiments, the first processing unit 340 is configured to: receive, through each of all normal nodes, a first request from a recovery node broadcast to the entire blockchain network to obtain a temporary consensus block, wherein the recovery node is any recovery node after the abnormal node corresponding to the node abnormal event has recovered to normal; obtain a temporary consensus block from the temporary consensus transaction data according to the first request, and serialize the temporary consensus block and send it to the recovery node so that the recovery node can perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed consensus verification to the blockchain database.

[0281] In some embodiments, when the first processing unit 340 obtains a temporary consensus block from the temporary consensus transaction data according to the first request, serializes the temporary consensus block, and sends it to the recovery node so that the recovery node performs consensus verification processing on the temporary consensus block and submits the temporarily consensus block that has passed consensus verification to the blockchain database, the unit 340 is configured to: obtain a temporary consensus block from the temporary consensus transaction data according to the first request, serialize the temporary consensus block, and send it to the recovery node so that the recovery node receives the temporary consensus block within a first specified time and verifies that the temporary consensus block has legality. At that time, the first vote for the block hash of the temporary consensus block is broadcast to the entire blockchain network, so that when the number of first votes carrying the block hash of the temporary consensus block received by the recovery node reaches the first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block and the temporary consensus block is submitted to the blockchain database; and when the number of first votes carrying the block hash of the temporary consensus block received by the normal node reaches the first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block and the temporary consensus block is submitted to the blockchain database.

[0282] In some embodiments, the first processing unit 340 is further configured to: receive a second request from the recovery node to the entire blockchain network to obtain the next temporary consensus block; obtain the next temporary consensus block from the temporary consensus transaction data according to the second request, and serialize the next temporary consensus block and send it to the recovery node so that the recovery node can perform consensus verification processing on the next temporary consensus block and submit the next temporary consensus block that has passed consensus verification to the blockchain database.

[0283] In some embodiments, when the first processing unit 340 obtains the next temporary consensus block from the temporary consensus transaction data according to the second request, serializes the next temporary consensus block, and sends it to the recovery node so that the recovery node performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the blockchain database, the first processing unit 340 is used to: obtain the next temporary consensus block from the temporary consensus transaction data according to the second request, serialize the next temporary consensus block, and send it to the recovery node so that the recovery node, when verifying the legality of the next temporary consensus block, submits it to the entire blockchain network. Broadcast a second vote on the block hash of the next temporary consensus block so that when a recovering node receives a second vote carrying the block hash of the next temporary consensus block and reaches a second vote threshold, it adds the content of the second vote to the additional data of the next temporary consensus block and submits the next temporary consensus block to the blockchain database; and when a normal node receives a second vote carrying the block hash of the next temporary consensus block and reaches a second vote threshold, it adds the content of the second vote to the additional data of the next temporary consensus block and submits the next temporary consensus block to the blockchain database.

[0284] In some embodiments, the first processing unit 340 is further configured to: receive a third request broadcast by the recovery node to the entire blockchain network to obtain all remaining transactions of the temporary consensus, wherein the third request is generated by the recovery node when verifying that the next temporary consensus block is not legitimate; obtain all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data according to the third request, to obtain a first target transaction set; serialize the first target transaction set and send it to the recovery node, so that the recovery node adds the first target transaction set to the local transaction pool of the recovery node and performs the normal consensus process.

[0285] In some embodiments, the first processing unit 340 is further configured to: receive a fourth request broadcast by the recovery node to the entire blockchain network to obtain all transactions within the temporary consensus range, wherein the fourth request is generated when the recovery node does not receive a temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed; obtain all transactions within the temporary consensus range from the temporary consensus transaction data according to the fourth request to obtain a second target transaction set; and serialize the second target transaction set and send it to the recovery node so that the recovery node adds the second target transaction set to the recovery node's local transaction pool and performs the normal consensus process.

[0286] In some embodiments, the activation unit 310 is configured to: receive a temporary consensus activation transaction sent by any normal node; and after the temporary consensus activation transaction is completed, reach a consensus within the scope of the temporary consensus nodes, and then adjust the local consensus state of the normal node to the temporary consensus state to activate the temporary consensus state.

[0287] In some embodiments, the activation unit 310 performs consensus after initiating a temporary consensus transaction, and after reaching a consensus within the scope of temporary consensus nodes, adjusts the local consensus state of normal nodes to "in temporary consensus" to activate the temporary consensus state. This is done by: obtaining the local consensus state of normal nodes; if the local consensus state is "in temporary consensus" and is closed, obtaining the signature list set and the set of recognized nodes in the temporary consensus initiation transaction, where the set of recognized nodes consists of temporary consensus nodes; and adjusting the local consensus state to "in temporary consensus" to activate the temporary consensus state if the signature list set and the set of recognized nodes are consistent.

[0288] Please see Figure 14 , Figure 14 This is a second structural schematic diagram of a blockchain consensus device provided in an embodiment of this application. The blockchain includes at least one recovery node and at least one normal node. The recovery node is the node that recovers from an abnormal node following a node anomaly event. The normal node is the normal node in the blockchain when the node anomaly event occurred. The blockchain consensus device 400 is mounted on any one of the recovery nodes. The blockchain consensus device 400 may include:

[0289] Broadcast unit 410 is used to broadcast the first request to obtain a temporary consensus block to the entire blockchain network;

[0290] The receiving unit 420 is used to receive temporary consensus blocks sent by normal nodes. These temporary consensus blocks are obtained by normal nodes upon receiving a first request, retrieving them from the temporary consensus transaction data, serializing them, and then sending them to the recovery node. The temporary consensus transaction data is generated when normal nodes respond to a temporary consensus transaction, initiate a temporary consensus state, and, in this state, collaborate with all normal nodes to perform temporary consensus operations, providing transaction services to the outside world through all normal nodes in the temporary consensus process, and recording the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus transaction initiation is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain.

[0291] The second processing unit 430 is used to perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed the consensus verification to the blockchain database.

[0292] In some embodiments, the second processing unit 430 is configured to: upon receiving a temporary consensus block within a first specified time and verifying the legality of the temporary consensus block, broadcast a first vote on the block hash of the temporary consensus block to the entire blockchain network, so that when normal nodes receive the first vote carrying the block hash of the temporary consensus block and reach a first vote threshold, they add the voting content of the first vote to the additional data of the temporary consensus block and submit the temporary consensus block to the blockchain database; and when a recovery node receives the first vote carrying the block hash of the temporary consensus block and reaches a first vote threshold, it adds the voting content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the blockchain database.

[0293] In some embodiments, the second processing unit 430 is further configured to: broadcast a second request to the entire blockchain network to obtain the next temporary consensus block; receive the next temporary consensus block sent by a normal node, wherein the next temporary consensus block is obtained by the normal node from the temporary consensus transaction data according to the second request, and serializes the next temporary consensus block before sending it to the recovery node; perform consensus verification processing on the next temporary consensus block, and submit the next temporary consensus block that has passed consensus verification to the blockchain database.

[0294] In some embodiments, when the second processing unit 430 performs consensus verification processing on the next temporary consensus block and submits the next temporary consensus block that has passed consensus verification to the blockchain database, it is configured to: when verifying the legitimacy of the next temporary consensus block, broadcast a second vote for the block hash of the next temporary consensus block to the entire blockchain network, so that when normal nodes receive the number of second votes carrying the block hash of the next temporary consensus block, they add the voting content of the second vote to the additional data of the next temporary consensus block and submit the next temporary consensus block to the blockchain database; and when a recovery node receives the number of second votes carrying the block hash of the next temporary consensus block, it adds the voting content of the second vote to the additional data of the next temporary consensus block and submits the next temporary consensus block to the blockchain database.

[0295] In some embodiments, the second processing unit 430 is further configured to: after submitting the next temporary consensus block to the blockchain database, determine whether the next temporary consensus block is a block where temporary consensus is closed; if the next temporary consensus block is determined to be a block where temporary consensus is closed, then proceed with the normal consensus process; or if the next temporary consensus block is determined not to be a block where temporary consensus is closed, then return to the step of executing the second request to obtain the next temporary consensus block broadcast to the entire blockchain network.

[0296] In some embodiments, the second processing unit 430 is further configured to: broadcast a third request to the entire blockchain network to obtain all remaining transactions of the temporary consensus, the third request being generated by the recovery node; receive a first target transaction set sent by a normal node, the first target transaction set being obtained by the normal node according to the third request, which obtains all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data, and serializes the first target transaction set before sending it to the recovery node; add the first target transaction set to the local transaction pool of the recovery node, and perform the normal consensus process.

[0297] In some embodiments, the second processing unit 430 is further configured to: broadcast a fourth request to the entire blockchain to obtain all transactions within the temporary consensus range, wherein the fourth request is generated when the recovery node does not receive a temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed; receive a second target transaction set sent by a normal node, wherein the second target transaction set is obtained by the normal node from the temporary consensus transaction data to obtain all transactions within the temporary consensus range according to the fourth request, and serializes the second target transaction set before sending it to the recovery node; add the second target transaction set to the local transaction pool of the recovery node and perform the normal consensus process.

[0298] It should be noted that the functions of each module in the blockchain consensus device in this application embodiment can be referred to the specific implementation of any embodiment in the above method embodiments, and will not be repeated here.

[0299] Each unit in the above-described device can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each unit.

[0300] For example, the consensus device 300 or the consensus device 400 of the blockchain can be integrated into a terminal or server that has storage and a processor and thus computing power, or the consensus device 300 or the consensus device 400 of the blockchain can be a terminal or server.

[0301] In some embodiments, this application 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 steps in the above-described method embodiments.

[0302] Figure 15 A schematic structural diagram of the computer device provided in the embodiments of this application, such as Figure 15 As shown, the computer device 500 may include: a communication interface 501, a memory 502, a processor 503, and a communication bus 504. The communication interface 501, memory 502, and processor 503 communicate with each other via the communication bus 504. The communication interface 501 is used for data communication between the device 500 and external devices. The memory 502 can be used to store software programs and modules, and the processor 503 runs the software programs and modules stored in the memory 502, such as the software programs for the corresponding operations in the aforementioned method embodiments.

[0303] In some embodiments, the processor 503 may invoke software programs and modules stored in the memory 502 to perform the following operations: in response to a temporary consensus transaction, initiate a temporary consensus state, wherein the temporary consensus transaction is a multi-signature transaction generated by joint signatures of all normal nodes in the event of a node anomaly in the blockchain; in the temporary consensus state, jointly perform temporary consensus operations with all normal nodes to provide transaction services to the outside world through all normal nodes of the temporary consensus; record the temporary consensus transaction data generated during the temporary consensus process; perform consensus verification processing on the temporary consensus transaction data through all normal nodes, and submit the temporarily consensus transaction data that has passed consensus verification to the blockchain.

[0304] In some embodiments, the processor 503 may invoke software programs and modules stored in the memory 502 to perform the following operations: broadcasting a first request to the entire blockchain network to obtain a temporary consensus block; receiving a temporary consensus block sent by a normal node, wherein the temporary consensus block is obtained by a normal node upon receiving the first request, retrieving the temporary consensus block from the temporary consensus transaction data according to the first request, serializing the temporary consensus block, and sending it to the recovery node; the temporary consensus transaction data is obtained by a normal node in response to a temporary consensus transaction, initiating a temporary consensus state, and, in the temporary consensus state, collaborating with all normal nodes to perform temporary consensus operations, so as to provide transaction services to the outside world through all normal nodes in the temporary consensus, and recording the temporary consensus transaction data generated during the temporary consensus process; the temporary consensus transaction initiation is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormality event in the blockchain; performing consensus verification processing on the temporary consensus block, and submitting the temporarily consensus block that has passed consensus verification to the blockchain database.

[0305] In some embodiments, the computer device 500 may be integrated into a terminal or server that has storage and a processor and thus computing power, or the computer device 500 may be the terminal or server.

[0306] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the methods described above in the embodiments of this application; for brevity, further details are omitted here.

[0307] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.

[0308] This application also provides a computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.

[0309] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps 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 described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located 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. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0310] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can 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. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0311] 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 application.

[0312] Those skilled in the art will 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 foregoing method embodiments, and will not be repeated here.

[0313] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0314] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0315] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A consensus method for blockchain, characterized in that, The blockchain includes at least one normal node and at least one abnormal node, the method is executed by any normal node, and the method includes: In response to the temporary consensus to initiate a transaction, a temporary consensus state is initiated. The temporary consensus to initiate a transaction is a multi-signature transaction generated by the joint signature of all normal nodes in the event of a node abnormal event in the blockchain. In the aforementioned temporary consensus state, all normal nodes jointly perform temporary consensus operations so that all normal nodes can provide transaction services to the outside world through the temporary consensus. Record temporary consensus transaction data generated during the temporary consensus process; The temporary consensus transaction data is verified by all normal nodes, and the verified temporary consensus transaction data is submitted to the blockchain.

2. The consensus method for blockchain as described in claim 1, characterized in that, The step of performing consensus verification processing on the temporary consensus transaction data through all normal nodes, and submitting the temporarily consensus transaction data that has passed consensus verification to the blockchain, includes: Each of the normal nodes receives the first request for obtaining a temporary consensus block broadcast to the entire blockchain by the recovery node, wherein the recovery node is any recovery node after the abnormal node corresponding to the abnormal node event has recovered to normal. According to the first request, a temporary consensus block is obtained from the temporary consensus transaction data, and the temporary consensus block is serialized and sent to the recovery node so that the recovery node can perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed the consensus verification to the database of the blockchain.

3. The consensus method for blockchain as described in claim 2, characterized in that, The step of obtaining a temporary consensus block from the temporary consensus transaction data according to the first request, serializing the temporary consensus block, and sending it to the recovery node so that the recovery node can perform consensus verification processing on the temporary consensus block and submit the temporarily consensus block that has passed consensus verification to the database of the blockchain includes: According to the first request, a temporary consensus block is obtained from the temporary consensus transaction data, and the temporary consensus block is serialized and sent to the recovery node so that the recovery node receives the temporary consensus block within a first specified time. When the recovery node verifies the legality of the temporary consensus block, it broadcasts a first vote on the block hash of the temporary consensus block to the entire blockchain network. When the number of first votes carrying the block hash of the temporary consensus block received by the recovery node reaches a first vote threshold, the recovery node adds the voting content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the blockchain database. When the number of first votes received by normal nodes carrying the block hash of the temporary consensus block reaches a first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the database of the blockchain.

4. The consensus method for blockchain as described in claim 2, characterized in that, The method further includes: Receive the second request from the recovery node, broadcast across the entire blockchain, to obtain the next temporary consensus block; According to the second request, the next temporary consensus block is obtained from the temporary consensus transaction data, and the next temporary consensus block is serialized and sent to the recovery node so that the recovery node can perform consensus verification processing on the next temporary consensus block and submit the next temporary consensus block that has passed the consensus verification to the database of the blockchain.

5. The consensus method for blockchain as described in claim 4, characterized in that, The step of obtaining the next temporary consensus block from the temporary consensus transaction data according to the second request, serializing the next temporary consensus block, and sending it to the recovery node so that the recovery node can perform consensus verification processing on the next temporary consensus block and submit the next temporary consensus block that has passed consensus verification to the blockchain database includes: According to the second request, the next temporary consensus block is obtained from the temporary consensus transaction data, and the next temporary consensus block is serialized and sent to the recovery node. This allows the recovery node to broadcast a second vote on the block hash of the next temporary consensus block to the entire blockchain network when verifying its legitimacy. When the number of second votes carrying the block hash of the next temporary consensus block received by the recovery node reaches a second vote threshold, the second vote content is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the blockchain database. When the number of second votes received by a normal node carrying the block hash of the next temporary consensus block reaches the second vote threshold, the voting content of the second vote is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the database of the blockchain.

6. The blockchain consensus method as described in claim 5, characterized in that, The method further includes: The recovery node receives a third request broadcast across the entire blockchain to obtain all remaining transactions of the temporary consensus, the third request being generated by the recovery node when verifying that the next temporary consensus block is not valid; According to the third request, obtain all transactions from the target block height to the end of the temporary consensus from the temporary consensus transaction data to obtain the first target transaction set; The first target transaction set is serialized and sent to the recovery node so that the recovery node adds the first target transaction set to the local transaction pool of the recovery node and performs the normal consensus process.

7. The consensus method for blockchain as described in claim 3, characterized in that, The method further includes: The recovery node receives a fourth request broadcast across the entire blockchain to obtain all transactions within the temporary consensus range. This fourth request is generated when the recovery node does not receive the temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed. Based on the fourth request, obtain all transactions within the temporary consensus range obtained from the temporary consensus transaction data to obtain the second target transaction set; The second target transaction set is serialized and sent to the recovery node so that the recovery node adds the second target transaction set to the local transaction pool of the recovery node and performs the normal consensus process.

8. The consensus method for blockchain as described in any one of claims 1-7, characterized in that, The response to initiate a transaction in response to temporary consensus, and the initiation of a temporary consensus state, include: Receive temporary consensus sent by any normal node to initiate a transaction; After the transaction is initiated for the temporary consensus, consensus is reached. Once an agreement is reached within the scope of the temporary consensus nodes, the local consensus state of the normal nodes is adjusted to the temporary consensus state to initiate the temporary consensus state.

9. The consensus method for blockchain as described in claim 8, characterized in that, The process of initiating a transaction for the temporary consensus and then reaching consensus within the scope of the temporary consensus nodes, followed by adjusting the local consensus state of the normal nodes to the temporary consensus state to initiate the temporary consensus state, includes: Obtain the local consensus status of a normal node; If the local consensus status is closed in the temporary consensus, then obtain the signature list set and the recognition node set in the temporary consensus open transaction, wherein the recognition node set is composed of temporary consensus nodes; If the signature list set is consistent with the recognized node set, the local consensus state is adjusted to temporary consensus to enable the temporary consensus state.

10. A consensus method for blockchain, characterized in that, The blockchain includes at least one recovery node and at least one normal node. The recovery node is the node that recovers from an abnormal node corresponding to a node anomaly event. The normal node is the normal node in the blockchain at the time the node anomaly event occurred. The method is executed by any one of the recovery nodes. The method includes: The first request to obtain a temporary consensus block is broadcast to the entire blockchain network. The system receives temporary consensus blocks sent by normal nodes. These temporary consensus blocks are obtained by the normal node upon receiving the first request, retrieving them from the temporary consensus transaction data, serializing them, and then sending them to the recovery node. The temporary consensus transaction data is obtained by the normal node in response to a temporary consensus transaction, activating a temporary consensus state, and, in this state, collaborating with all normal nodes to perform temporary consensus operations. This allows all normal nodes to provide transaction services externally and records the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus transaction activation is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain. The temporary consensus block undergoes consensus verification processing, and the temporary consensus block that passes the consensus verification is submitted to the database of the blockchain.

11. The consensus method for blockchain as described in claim 10, characterized in that, The step of performing consensus verification processing on the temporary consensus block and submitting the temporarily consensus block that has passed consensus verification to the database of the blockchain includes: Upon receiving the temporary consensus block within a first specified time and verifying its legitimacy, the system broadcasts a first vote on the block hash of the temporary consensus block to the entire blockchain network. This ensures that when the number of first votes carrying the block hash of the temporary consensus block received by normal nodes reaches a first vote threshold, the system adds the content of the first vote to the additional data of the temporary consensus block and submits the temporary consensus block to the blockchain database. When the number of first votes received by the recovery node carrying the block hash of the temporary consensus block reaches a first vote threshold, the voting content of the first vote is added to the additional data of the temporary consensus block, and the temporary consensus block is submitted to the database of the blockchain.

12. The consensus method for blockchain as described in claim 11, characterized in that, The method further includes: A second request to obtain the next temporary consensus block is broadcast to the entire blockchain network. The normal node receives the next temporary consensus block sent by the normal node. The next temporary consensus block is obtained by the normal node from the temporary consensus transaction data according to the second request, and then serializing the next temporary consensus block and sending it to the recovery node. The next temporary consensus block undergoes consensus verification processing, and the next temporary consensus block that passes the consensus verification is submitted to the database of the blockchain.

13. The consensus method for blockchain as described in claim 12, characterized in that, The step of performing consensus verification processing on the next temporary consensus block and submitting the next temporary consensus block that has passed consensus verification to the blockchain database includes: When verifying the legitimacy of the next temporary consensus block, a second vote for the block hash of the next temporary consensus block is broadcast to the entire blockchain network. This ensures that when a normal node receives a second vote carrying the block hash of the next temporary consensus block, reaching a second vote threshold, the second vote is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the blockchain database. When the number of second votes received by the recovery node carrying the block hash of the next temporary consensus block reaches the second vote threshold, the voting content of the second vote is added to the additional data of the next temporary consensus block, and the next temporary consensus block is submitted to the database of the blockchain.

14. The consensus method for blockchain as described in claim 13, characterized in that, The method further includes: After submitting the next temporary consensus block to the blockchain database, it is determined whether the next temporary consensus block is a block where temporary consensus is closed. If the next temporary consensus block is determined to be a block where temporary consensus is closed, then the normal consensus process proceeds; or If it is determined that the next temporary consensus block is not a block where temporary consensus is closed, then the process returns to the step of executing the second request to obtain the next temporary consensus block, which is broadcast to the entire blockchain network.

15. The consensus method for blockchain as described in claim 13, characterized in that, The method further includes: A third request, generated by the recovery node, is broadcast to the entire blockchain network to obtain a temporary consensus on all remaining transactions. The normal node receives a first target transaction set sent by the normal node. The first target transaction set is obtained by the normal node according to the third request, which obtains all transactions from the target block height to the end of the temporary consensus transaction data, and serializes the first target transaction set before sending it to the recovery node. The first target transaction set is added to the local transaction pool of the recovery node, and the normal consensus process is carried out.

16. The consensus method for blockchain as described in claim 11, characterized in that, The method further includes: A fourth request is broadcast to the entire blockchain to obtain all transactions within the temporary consensus range. This fourth request is generated when the recovery node does not receive the temporary consensus block within a first specified time, or when the recovery node receives a temporary consensus start request after a second specified time has elapsed. The normal node receives a second target transaction set sent by the normal node. The second target transaction set is obtained by the normal node from all transactions that obtain the temporary consensus range from the temporary consensus transaction data according to the fourth request, and then serializes the second target transaction set and sends it to the recovery node. The second target transaction set is added to the local transaction pool of the recovery node, and the normal consensus process is carried out.

17. A consensus device for blockchain, characterized in that, The blockchain includes at least one normal node and at least one abnormal node, and the device is mounted on any one of the normal nodes. The device includes: The activation unit is used to activate a transaction in response to a temporary consensus and to activate a temporary consensus state. The temporary consensus transaction is a multi-signature transaction generated by joint signatures of all normal nodes in the event of a node abnormal event in the blockchain. The consensus unit is used to unite all normal nodes to perform temporary consensus operations in the temporary consensus state, so as to provide transaction services to the outside world through all normal nodes of the temporary consensus. The recording unit is used to record temporary consensus transaction data generated during the temporary consensus process. The first processing unit is used to perform consensus verification processing on the temporary consensus transaction data through all normal nodes, and submit the temporary consensus transaction data that has passed the consensus verification to the blockchain.

18. A consensus device for blockchain, characterized in that, The blockchain includes at least one recovery node and at least one normal node. The recovery node is the node that recovers from an abnormal node corresponding to a node anomaly event. The normal node is the normal node in the blockchain at the time the node anomaly event occurred. The device is mounted on any one of the recovery nodes. The device includes: The broadcast unit is used to broadcast the first request to obtain a temporary consensus block to the entire blockchain network; The receiving unit is used to receive temporary consensus blocks sent by normal nodes. These temporary consensus blocks are obtained by the normal node upon receiving the first request, retrieving them from the temporary consensus transaction data, serializing them, and then sending them to the recovery node. The temporary consensus transaction data is obtained by the normal node in response to a temporary consensus transaction, initiating a temporary consensus state, and, in this state, collaborating with all normal nodes to perform temporary consensus operations. This allows all normal nodes to provide transaction services externally, and records the temporary consensus transaction data generated during the temporary consensus process. The temporary consensus transaction initiation is a multi-signature transaction generated through joint signatures of all normal nodes in the event of a node anomaly in the blockchain. The second processing unit is used to perform consensus verification processing on the temporary consensus block and submit the temporary consensus block that has passed the consensus verification to the database of the blockchain.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to execute the consensus method of the blockchain as described in any one of claims 1-16.

20. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the consensus method of the blockchain as described in any one of claims 1-16 by calling the computer program stored in the memory.

Images