Data processing method based on block chain network and related equipment

Abstract

The embodiment of the invention provides a data processing method based on a block chain network and related equipment, the block chain network comprises a first consensus node and a second consensus node, the method is executed by the first consensus node, and the method comprises the following steps: receiving a target block message synchronized by the second consensus node; the current node state of the first consensus node is determined, and the current node state refers to the node state of the first consensus node at the moment when the target block message is received; if the target block message is judged to be a lead consensus message according to the current node state, caching the target block message in a local space; and after waiting for the first consensus node to reach a target node state required for performing consensus processing on the target block message, acquiring the target block message from the local space, and performing consensus processing on the target block message based on the target node state. Therefore, the communication traffic of the consensus nodes in the block chain network can be reduced, the network bandwidth is saved, and the consensus efficiency of the nodes can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain, and in particular to a data processing method and related equipment based on a blockchain network. Background Art

[0002] Each consensus node (i.e., node participating in consensus) in the blockchain network will continuously synchronize block messages (including blocks) to update the blockchain in each consensus node and promote the transformation of node status. In the blockchain network, each consensus node has different delay fluctuations in receiving messages, which leads to differences in the node status of each consensus node over a period of time, and then any consensus node may not be able to process the block message immediately when it receives a block message. At present, when a consensus node receives a block message and cannot process the block message immediately at the current moment, the consensus node usually chooses to discard the block message and request the block message from other nodes again for consensus processing after the node reaches the corresponding node state. However, it has been found in practice that this will cause a waste of network bandwidth of the blockchain network, and the consensus efficiency of the consensus node is relatively low. Summary of the invention

[0003] The embodiments of the present application provide a data processing method and related equipment based on a blockchain network, which can reduce the communication volume of consensus nodes in the blockchain network, thereby saving network bandwidth and improving the consensus efficiency of nodes.

[0004] On the one hand, an embodiment of the present application provides a data processing method based on a blockchain network, which is executed by a first consensus node in the blockchain network, including:

[0005] Receive a target block message synchronized by the second consensus node, where the target block message is a block message to be processed by consensus;

[0006] Determine a current node state of the first consensus node, where the current node state refers to: the node state of the first consensus node at the moment of receiving the target block message;

[0007] If the target block message is determined to be an advanced consensus message according to the current node state, the target block message is cached in the local space; the advanced consensus message refers to a block message that needs to be processed by consensus based on the node state that the first consensus node has not yet reached;

[0008] After waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, the target block message is obtained from the local space, and consensus processing is performed on the target block message based on the target node state.

[0009] On the one hand, an embodiment of the present application provides a data processing device based on a blockchain network, wherein the blockchain network includes a first consensus node and a second consensus node, and the device includes:

[0010] A transceiver unit, configured to receive a target block message synchronized by the second consensus node, wherein the target block message is a block message to be processed by consensus;

[0011] a processing unit, configured to determine a current node state of the first consensus node, wherein the current node state refers to a node state of the first consensus node at the moment of receiving the target block message;

[0012] The processing unit is further configured to cache the target block message in a local space if the target block message is determined to be an advanced consensus message according to the current node state; the advanced consensus message refers to a block message that needs to be processed by consensus based on a node state that has not yet been reached by the first consensus node;

[0013] The processing unit is further used to obtain the target block message from the local space after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, and perform consensus processing on the target block message based on the target node state.

[0014] In one aspect, an embodiment of the present application provides a computer device, the computer device comprising:

[0015] a processor suitable for executing a computer program;

[0016] A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium. When the computer program is executed by a processor, the data processing method based on the blockchain network as described above is implemented.

[0017] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program is loaded by a processor and executes the data processing method based on the blockchain network as described above.

[0018] On the one hand, an embodiment of the present application provides a computer program product, which includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, the above-mentioned data processing method based on the blockchain network is implemented.

[0019] In an embodiment of the present application, a first consensus node in a blockchain network may receive a target block message synchronized to it by a second consensus node in the blockchain network, where the target block message is a block message to be processed by consensus. The first consensus node may also determine its node state at the time of receiving the target block message, that is, the current node state, and determine whether the target block message is an advanced consensus message based on the current node state. In the case where the target block message is an advanced consensus message, since the advanced consensus message needs to be processed by consensus at a node state that has not yet been reached by the first consensus node, it may be cached in a local space, and while waiting for the node state of the first consensus node to reach the target node state required for consensus processing of the target block message, the target block message may be obtained from the local space for consensus processing. In this way, there is no need to discard the advanced consensus messages that cannot be processed at present. Instead, the advanced consensus messages are cached in the local space of the consensus node, so that they can be directly obtained from the local space when the target node state is reached that can process the target block message through consensus, without requesting the target block message from other nodes through the network, thereby reducing the communication volume of consensus nodes in the blockchain network, saving network bandwidth, and based on the relatively fast response speed of the local space, the consensus efficiency of the nodes can also be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1a is a schematic diagram of a data sharing system provided in an embodiment of the present application;

[0021] Figure 1b This is a schematic diagram of a blockchain structure provided by an embodiment of the present application;

[0022] Figure 1c This is a schematic diagram of a process of generating a new block provided by an embodiment of the present application;

[0023] Figure 1d This is a schematic diagram of the architecture of a data processing system based on a blockchain network provided in an embodiment of the present application;

[0024] Figure 2 It is a flowchart of a data processing method based on a blockchain network provided in an embodiment of the present application;

[0025] Figure 3a This is a schematic diagram of an advanced consensus message cache provided by an embodiment of the present application;

[0026] Figure 3b It is a schematic diagram of a processing flow of an advanced consensus message provided in an embodiment of the present application;

[0027] Figure 4 It is a flowchart of another data processing method based on a blockchain network provided in an embodiment of the present application;

[0028] Figure 5a This is a schematic diagram of a blockchain bifurcation provided by an embodiment of the present application;

[0029] Figure 5b It is a schematic diagram of link division provided in an embodiment of the present application;

[0030] Figure 6a This is a processing diagram before determining a forked consensus message provided by an embodiment of the present application;

[0031] Figure 6b This is a processing diagram before determining a forked consensus message provided by an embodiment of the present application;

[0032] Figure 7 This is another schematic diagram of a data processing flow based on a blockchain network provided in an embodiment of the present application;

[0033] Figure 8 This is a schematic diagram of processing when a blockchain forks in an embodiment of the present application;

[0034] Fig. 9 It is a structural schematic diagram of a data processing device based on a blockchain network provided in an embodiment of the present application;

[0035] Fig.10 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0037] The blockchain network is distributed. The data in the blockchain network does not rely on a central server or central organization, but is distributed and stored in various nodes, which makes the blockchain network more robust because no single cracked or faulty node will have a serious impact on the entire network. The blockchain network also has the characteristics of decentralization. For example, the blockchain network is a peer-to-peer network, which is a decentralized network architecture. The peer-to-peer network does not rely on a central server or other centralized structure. Each node has the same status in the network and can communicate directly with other nodes. In a peer-to-peer network, nodes (usually called "peers" or "network nodes") communicate and exchange data directly without going through a central server. It can be seen that this model makes the performance of the network no longer dependent on a single central node, which helps to provide reliability.

[0038] The blockchain network is a data sharing system, see Figure 1a The data sharing system shown, the data sharing system 100 refers to a system for sharing data between nodes, and the data sharing system may include multiple nodes 101, and the multiple nodes 101 may refer to each client in the data sharing system. Each node 101 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the information intercommunication within the data sharing system, there may be an information connection between each node in the data sharing system, and information can be transmitted between nodes through the above information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0039] Each node in the data sharing system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system, so that the generated blocks can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. The following table only uses the IP address as an example for explanation.

[0040] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0041] Each node in the data sharing system stores the same blockchain. The blockchain can also be understood as a distributed database technology that implements data storage and transactions in a decentralized, secure, and tamper-proof manner. It stores information in a structured manner in data units called "blocks" and connects these blocks to each other through cryptographic principles to form a growing chain data structure. Each block contains a series of transaction data and is linked together in time. In other words, the blockchain consists of multiple blocks, see Figure 1bThe blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information. The next block of the genesis block takes the genesis block as the parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on. The block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0042] When generating each block in the blockchain, see Figure 1c When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:

[0043] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0044] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0045] In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system according to the node identification of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after the verification is completed.

[0046] The amount of data in the block messages agreed upon by the consensus nodes in the blockchain network is generally large. For example, the average block size of the public chain Ethereum in the past year is between 100K and 120K, and the average time for each block is 12s to 15s. Therefore, in terms of block message sending alone, a node will send about 1.2M to 1.7M of data to another node every minute on average. In addition, since the blockchain network is a distributed network composed of multiple nodes, the corresponding protocol (such as the Gossip protocol) is used for message transmission, which means that a consensus node needs to send the same message to multiple randomly selected consensus nodes, resulting in a large amount of bandwidth output per minute; at the same time, each consensus node may also receive the same message sent by multiple consensus nodes, resulting in a large amount of bandwidth input per minute. In addition, due to network delays, node failures leading to node downtime, etc., the node status of each consensus node in the blockchain network may not be consistent at a certain moment. In terms of node status, the node status between two consensus nodes is relatively backward or ahead. In this way, the block messages pushed out by each consensus node may be in different stages. When a consensus node in a lagging state receives an advanced consensus message, the consensus node cannot process it based on the current node state.

[0047] The present application proposes a data processing scheme based on a blockchain network, which relates to a data processing system, method and related equipment based on a blockchain network. The scheme is for any consensus node (first consensus node) in the blockchain network, which can receive a target block message synchronized by other consensus nodes (second consensus nodes) in the blockchain network, and detect whether the target block message is an advanced consensus message. This is because the node state required for the first consensus node to perform consensus processing on the target block message exceeds the current node state of the first consensus node, and the blockchain maintained by the first consensus node and the local space do not have the preceding block message of the target block message, which causes the target block message to be unable to be uploaded to the chain. Therefore, the first consensus node cannot process the target block message based on the current node state. At this time, the target block message can be cached in the local space (usually local memory) of the first consensus node, and the node state of the first consensus node can reach the corresponding node state as consensus processing is performed on other block messages. When the node state of the first consensus node reaches the target node state required for consensus on the target block message, the target block message can be directly obtained from the local space for consensus processing. In this process, by caching the target block message that cannot be processed currently locally instead of discarding it directly, and when the node state reaches the target node state that can process the target block message, the target block message that can be processed currently is loaded from the local space, without repeatedly requesting the target block message that has been received. Based on this, on the one hand, the synchronized block message does not need to be sent repeatedly, which can reduce the communication volume between each consensus node and save network bandwidth. On the other hand, by obtaining from the local space, compared with requesting to the consensus node through the network, the local space has a faster response efficiency and a faster data transmission speed, thereby improving the consensus efficiency, and can enable the consensus node with relatively backward node status to advance to the latest state of the blockchain in the blockchain network more quickly through the consensus block message.

[0048] The blockchain network includes multiple consensus nodes (or network nodes). Consensus nodes refer to nodes that participate in consensus. Nodes can be understood as computer devices. Consensus nodes in the blockchain network will continuously reach message consensus, including the broadcast of blocks and transactions, so that each consensus node in the blockchain network can receive enough information and apply this information in the same way to promote the transformation of node states. In one implementation, the consensus node can receive transactions forwarded by nodes that do not participate in the consensus and automatically package the blocks to generate blocks to be agreed upon. Each consensus node in the blockchain network will maintain a complete copy of the blockchain and reach consensus based on the consensus with other consensus nodes in the blockchain network. Based on the differences between the node states of each consensus node, the blockchain copies maintained by different consensus nodes may also differ at a certain moment.

[0049] In the embodiment of the present application, the first consensus node and the second consensus node are relative concepts. The first consensus node refers to the consensus node that receives the block message synchronized by other consensus nodes in the blockchain network, and the second consensus node refers to the consensus node that sends the block message to the outside in the blockchain network. If the consensus node that receives the block message sends the block message to other consensus nodes, then relative to the other consensus nodes, the consensus node that sends the block message can also be used as the second consensus node. For example, consensus node B sends a block message to consensus node A, then consensus node A is the first consensus node, and consensus node B is the second consensus node. If consensus node A sends a block message to consensus node C, then consensus node C is the first consensus node, and consensus node A is the second consensus node. In addition, the terms "first", "second", etc. in this application are used to distinguish between the same or similar items with basically the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", and the quantity and execution order are not limited. In this application, the term "at least one" means one or more, and the meaning of "multiple" means two or more; for example: multiple nodes refer to two or more nodes.

[0050] The specific implementation logic of the data processing method based on the blockchain network is as follows: the first consensus node in the blockchain network can receive the target block message synchronized by the second consensus node through step 1, and the target block message is the block message to be processed by consensus; the first consensus node can also determine the current node state of the first consensus node, and the current node state refers to: the node state of the first consensus node at the moment of receiving the target block message; further, according to the current node state of the first consensus node, it can be determined whether the received target block message is an advanced consensus message: the advanced consensus message refers to: a block message that needs to be processed by consensus based on the node state that the first consensus node has not yet reached; if the target block message is determined to be an advanced consensus message according to the current node state, the target block message is cached in the local space through step 2; the first consensus node can update the node state based on the currently processable block message through step 3, and then query the local space, after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, obtain the target block message from the local space through step 4, and perform consensus processing on the target block message based on the target node state through step 5. When the on-chain conditions are met, the target block message can be stored on the blockchain in the database.

[0051] The above data processing method is executed by the first consensus node in the blockchain network. The first consensus node and the second consensus node can both be computer devices. For the above scheme, please refer to Figure 1dSchematic diagram of the data processing architecture based on the blockchain network shown. The computer devices mentioned above are, for example, one or both of the terminal devices or servers, wherein the terminal devices include, but are not limited to: smart phones, tablet computers, smart wearable devices, smart voice interaction devices, smart home appliances, personal computers, vehicle terminals, smart cameras and other devices, and this application does not limit this. This application does not limit the number of terminal devices. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but is not limited to this. This application does not limit the number of servers.

[0052] By adopting the data processing scheme based on the blockchain network provided in the embodiment of the present application, for any node in the blockchain network, if an advanced consensus message for itself is received, such as a new receiving block that lacks a preceding block (because the blockchain is a continuously growing chain structure composed of blocks, each block is linked together by containing a hash of the preceding block, and if there is no preceding block in the consensus node, it cannot be processed), the advanced consensus message can be cached locally, and after the node state is updated to the required target node state in the consensus node (which can indicate the presence of a preceding block of the advanced consensus message), the block message can be loaded from the local cache for consensus on-chain processing. By caching the advanced consensus message, on the one hand, the probability of re-triggering the request can be reduced, and the peer node does not need to send the same message repeatedly. On the basis of a large amount of bandwidth input and output, the communication volume between nodes in the blockchain network is further reduced, saving node network bandwidth; on the other hand, directly obtaining messages from the node local cache for processing, compared with requesting other nodes through the network, not only reduces the data processing process, but also the high-efficiency response based on the local cache loading message can also receive messages faster, improve the node consensus efficiency, and thus improve the node state conversion efficiency. This solution is a more general solution that can be adapted to a variety of blockchain node engines, and through local cache and status callback, after the node status is updated, it is called back to query whether there are processable messages in the local cache, thereby improving processing efficiency.

[0053] Based on the above introduction, the data processing method based on the blockchain network provided by the embodiment of this application is introduced. Figure 2, is a flow chart of a data processing method based on a blockchain network provided by an embodiment of the present application. The blockchain network includes a first consensus node and a second consensus node. The first consensus node and the second consensus node are different consensus nodes in the blockchain network. Each consensus node maintains a blockchain. Based on the consensus on the message between the consensus nodes, the blockchains in the consensus nodes can be eventually synchronized. The data processing method based on the blockchain network can be executed by the first consensus node in the blockchain network. The first consensus node can be understood as a computer device. The data processing method based on the blockchain network can include the following steps S201-S204.

[0054] S201, receiving the target block message synchronized by the second consensus node.

[0055] The target block message is a block message to be processed by consensus, which can be understood as a block message in the second consensus node to be processed by other consensus nodes by consensus. For the second consensus node, the target block message is a block message in the second consensus node that has passed the consensus process and has not been on the chain. Here, passing the consensus process means that the consensus operation has been completed, and not on the chain means that it has not been submitted to the blockchain in the second consensus node. This is because other consensus nodes are required to participate in the consensus processing of the block message. When the target block message is synchronized to the first block message, it may not have been on the chain to the blockchain in the second consensus node. In a specific implementation, the target block message can be a block generated by the second consensus node for its own packaging, or it can be a block synchronized by other consensus nodes received by the second consensus node. In another specific implementation, a block message can also be generated by encapsulating the block, that is, the target block message is a message containing the target block, which includes not only the complete target block, but also the data required to transmit the message in the network, such as the communication protocol, etc. The consensus processing of the target block message is the consensus processing of the target block.

[0056] S202, determine the current node state of the first consensus node.

[0057] Each consensus node in the blockchain network has a node state at a certain moment, and the node state is the state involved in the consensus node maintaining the blockchain through the consensus block message. The first consensus node can determine its current node state, which refers to the node state of the first consensus node at the moment of receiving the target block message (which can be understood as the current moment). In order to determine the subsequent processing of the target block message, the current node state can be used to determine whether the target block message is an advanced consensus message; the advanced consensus message refers to a block message that needs to be processed by consensus based on the node state that the first consensus node has not yet reached.

[0058] For a certain consensus node, the node status at different times may be the same or different; the general logic of the judgment can be: according to the block height of the target block message, determine the target node status required for consensus on the target block message, and the target node status is the state that the consensus processing target block message needs to reach; then based on the relationship between the required target node status and the current node status, judge whether the target block message is an advanced consensus message. That is, by judging whether the target block message is an advanced consensus message based on whether the current node state reaches the required target node state, if the target node state required for consensus on the target block message is a node state that the current node state has not reached, then the target block message is determined to be an advanced consensus message, otherwise, it is determined that the target block message is not an advanced consensus message. In one implementation, based on the distributed characteristics of the blockchain network, the node states of different consensus nodes at the same time may present a relative advanced, backward or equal relationship. The block height of the target block message synchronized by the second consensus node is associated with the current node state of the second consensus node. Therefore, based on the relationship between the current node states of the first consensus node and the second node, it can be judged whether the target consensus message is an advanced consensus message. For example, if the node height of the second consensus node is 7, then the target block message synchronized by the second consensus node is the block with the maximum block height of 7 among the blocks that have been consensus processed by the second consensus node but have not yet been put on the chain, and the node height of the first consensus node is 5, the node state of the first consensus node is relatively behind the node state of the second consensus node, then the target block message is an advanced consensus message.

[0059] S203: If the target block message is determined to be an advanced consensus message according to the current node status, the target block message is cached in the local space.

[0060] In the case where the first consensus node determines that the target block message is an advanced consensus message, it means that the current node state of the first consensus node has not reached the target node state required for consensus processing of the target block message, and the target block message cannot be processed by consensus based on the current node state. However, in order to avoid repeated requests to other nodes due to discarding the target block message when the node state of the first consensus node is advanced to the target node state capable of consensus processing of the target block message, in the embodiment of the present application, the target block message can be cached in the local space of the first consensus node, and the local space can be the local memory of the first consensus node. It is understandable that before caching the target block message, there may be no block message in the local space of the first consensus node, or a block message that has passed the consensus processing but has not yet been put on the chain has been cached. This is because before receiving the target block message, other block messages may have been received and similar processing as in the embodiment of the present application has been performed.

[0061] Each consensus node in the blockchain network that receives the target block message synchronized by the second consensus node can process the target block message according to the above process, and can feed back the result of the consensus processing to the second consensus node to indicate that the consensus node has participated in the consensus of the synchronized target block message, so that the second consensus node can receive the results fed back by each peer consensus node, and based on the broadcast of the consensus node, the first consensus node can also receive the results fed back by other consensus nodes that participate in the consensus of the target block message. Since there may be a delay in the results fed back by different consensus nodes for the target block message, the first consensus node can cache the target block message in the local space before consensus processing the target block message, and wait for the results of consensus feedback by other consensus nodes on the same target block message. The feedback results can be used to determine whether the target block message meets the on-chain conditions, and when the on-chain conditions are met, the target block message is obtained from the local space for on-chain.

[0062] S204, after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, obtain the target block message from the local space, and perform consensus processing on the target block message based on the target node state.

[0063] After the first consensus node waits for itself to reach the target node state required for consensus processing of the target block message, the first consensus node can perform consensus processing on the target block message based on the target node state. Since the target block message has been cached in the local space before, the target block message can be obtained from the local space. The acquisition here means: a copy of the target block message in the local space is copied for consensus processing, but the target block message is still retained in the local space and is not deleted for the time being, so as to avoid the block message that can be processed being judged as an advanced consensus message after receiving other block messages in the future, thereby affecting the consensus. In one implementation, the consensus processing of the target block message includes: executing and verifying the transaction in the target block message, and voting on the target block message. By processing in the above manner, the step of sending a network request to obtain the block message again can be avoided, thereby simplifying the overall processing flow of the advanced consensus message, which can not only save the network bandwidth of the node, but also improve the consensus efficiency. Furthermore, in one implementation, the vote on the target block message may be an affirmative vote (i.e., supporting the target block message to be put on the chain) or a negative vote (i.e., not supporting the target block message to be put on the chain). The votes of other consensus nodes can be combined to determine whether the target block message can be put on the chain.

[0064] In one embodiment, while waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, the first consensus node may continue to receive advanced consensus messages without updating the current node state for a period of time. The first consensus node may also receive processable consensus messages and update the current node state based on the consensus processing of the block message. The processable block message may be a newly received block message that can be consensus processed based on the current node state. The updated node state may remain unchanged for a period of time according to similar logic, or it may be updated. With the update of the node state, the node state of the first consensus node can be advanced to reach the target node state. Before the waiting node reaches the target node state, the block message processed by consensus may include at least one of the following: a newly received block message, a block message queried from the local space.

[0065] In one implementation, the matched block message can be queried from the local space based on the current node state. The match here means that the node state required for consensus processing of the queried block message is the same as the current node state. If found, the queried block message can be obtained from the local space and consensus processing can be performed on it. The first consensus node reaches a consensus on a block message, which can update the current node state of the first consensus node and obtain an updated node state. If the updated node state reaches the target node state, the above-mentioned step of obtaining the target block message from the local space can be performed. For example, Figure 3a The schematic diagram of consensus node processing messages shown in the figure. The first consensus node is Node2, and the second consensus node is Node1. The node height is used to indicate the maximum block height of each block message that has passed the consensus processing but has not yet been put on the chain in the consensus node; when Node1 sends the message of block 7 (i.e., the block message with a block height of 7) to Node2, since the message is an advanced consensus message, Node2 cannot process it, so it can cache it in the memory of the local node, and then continue to wait for receiving other block messages in the blockchain network. When receiving the message of block 6 sent by Node3 (i.e., the block message with a block height of 6), since the message is a message that Node1 can process, after completing the consensus processing of the message of block 6, the node height can be updated to 7, and the node height 7 allows consensus processing of the message of block 7, and then it can be obtained from the local space.

[0066] If the updated node state has not reached the consensus processing of the target block message, the block message matching it can be queried from the local space of the first consensus node based on the updated node state, and new consensus messages can be received. After the consensus processing of the processable block message is completed, the updated node state can be further updated. By analogy, it may be necessary to perform consensus processing on multiple block messages in sequence to update the node state of the first consensus node multiple times before the node state of the first consensus node can reach the target node state, that is, the node state that can perform consensus processing on the target block message. For example, Figure 3b As shown, it is based on Figure 3a Schematic diagram of processing the cache of advanced consensus messages. After Node2 processes a message of block 6 (i.e., a block message with a block height of 6) and pushes the node height to be updated to 6, it can query whether there is a message of block 7 (i.e., a block message with a block height of 7) in the local cache, and then perform consensus processing on the queried block message with a block height of 7, and then update the node height to 7 after consensus processing.

[0067] After the first consensus node completes the consensus processing of the target block message, the target node state is also updated to obtain an updated target node state. In one implementation, based on the updated target node state, consensus processing can be performed on block messages with the target block message as the preceding block message. Based on the updated target node state, it is also possible to query whether there is a block message cached in the local space that matches the updated target node state; if so, the matching block message can be obtained and consensus processing can be performed on it. During the query process, the first consensus node may receive a new block message, so the new block message can be processed synchronously. As mentioned above Figure 3b In the example, when the node height of Node2 is updated to 7, it is possible to first query whether there is a block message with a block height of 8 cached in the local space. If so, the block message can be obtained for consensus processing. During the query process, when the new block message received is a matching consensus message, consensus processing is performed on it. When the new block message received is an advanced consensus message, similar processing is performed according to the above steps S201-S204.

[0068] In the data processing method based on the blockchain network provided by the embodiment of the present application, the first consensus node in the blockchain network can receive the target block message synchronized to it by the second consensus node in the blockchain network, and the target block message is the block message to be processed by consensus. The first consensus node can also determine its node state at the moment of receiving the target block message, that is, the current node state, and determine whether the target block message is an advanced consensus message according to the current node state. In the case where the target block message is an advanced consensus message, since the advanced consensus message needs to be processed by consensus at a node state that has not yet been reached by the first consensus node, it can be cached in the local space, and while waiting for the node state of the first consensus node to reach the target node state required for consensus processing of the target block message, the target block message can be obtained from the local space for consensus processing. In this way, there is no need to discard the advanced consensus messages that cannot be processed at present. Instead, the advanced consensus messages are cached in the local space of the consensus node, so that they can be directly obtained from the local space when the target node state is reached that can process the target block message through consensus, without requesting the target block message from other nodes through the network, thereby reducing the communication volume of consensus nodes in the blockchain network, saving network bandwidth, and based on the relatively fast response speed of the local space, the consensus efficiency of the nodes can also be improved.

[0069] Based on the above Figure 2 The method embodiment shown in the embodiment of the present application further proposes a more specific data processing method based on the blockchain network. In the embodiment of the present application, the first consensus node executes the method as an example for explanation; see Figure 4 , the data processing method based on the blockchain network may include the following steps S401-S407.

[0070] S401, receiving a target block message synchronized by the second consensus node.

[0071] S402, determining the current node status of the first consensus node.

[0072] In one embodiment, the current node state includes: the current node height and the current chain height. Among them, the current node height refers to: at the moment of receiving the target block message, the maximum block height among the block heights of each block message that has passed the consensus process in the first consensus node. In one implementation, the first consensus node may include at least one block message that has passed the consensus process, and these block messages that have passed the consensus process are all messages that have not been confirmed to be on the chain. Since the block heights of these block messages that have passed the consensus process and have not been on the chain are greater than the block heights of the block messages that have passed the consensus process and have been on the chain (i.e., the block messages on the blockchain), when the first consensus node includes a block message that has passed the consensus process and has not been on the chain, the node height is the block height of the block message that has passed the consensus process and has not been on the chain; when the first consensus node includes at least two block messages that have passed the consensus process and have not been on the chain, the node height is the maximum block height among the block heights of each block message that has passed the consensus process and has not been on the chain. Exemplarily, if the block messages in the first consensus node that have passed the consensus process and are not on the chain include: block a with a block height of 5, block b with a block height of 6, and block c with a block height of 7, then the node height is 7. The current chain height refers to: the block height of the last block stored on the blockchain in the first consensus node at the moment of receiving the target block message. The block height can be the number of the block, that is, the maximum block height in the blockchain in the first consensus node. Exemplarily, the blockchain includes 3 blocks, and the block heights are 0, 1, and 2 respectively, then the current chain height is 2. In one implementation, if the first consensus node does not include block messages that have passed the consensus process and are not on the chain, for example: at least the local space for storing block messages that have passed the consensus process and are not on the chain is empty, then the current node height is the block height of the last block on the blockchain. Among them, the blockchain in the first consensus node can be maintained locally in the first consensus node, or maintained in a database connected to the first database, such as a cloud database.

[0073] In one implementation, based on the consensus algorithm adopted, the node height and the current chain height may not be advanced synchronously, the current node height is greater than or equal to the current chain height, and the difference between the current chain heights is greater than or equal to 1. Exemplarily, at least three block messages with block heights of 7, 6, and 5 that have not yet been put on the chain are cached in the local space. Since multiple rounds of voting may be required for a block message before the block message can be submitted, the current node height is 7, and the current chain height is 4.

[0074] When the block height of the target block message is greater than the current node height, and there is a lack of continuity between the block height of the target block message and the current node height, the target block message is determined to be an advanced consensus message. When there is a lack of continuity between the block height of the target block message and the current node height, it means that at least the preceding block message of the target block message is lacking, then the target block message is an advanced consensus message. Exemplarily, the block height of the target block message is 7, and the node height is 5, and the values ​​of the two are discontinuous, then it can be determined to be an advanced consensus message.

[0075] In one embodiment, when the current node height is greater than the current chain height, the local space includes: at least one candidate block message, the candidate block message refers to: a block message that has passed the consensus process and has not been put on the chain; the block height of any candidate block message is greater than the current node height and less than or equal to the current chain height. Exemplarily, the current node height is 6 and the current chain height is 4, then the local space includes 3 block messages with block heights of 5, 6, and 7 that have not been put on the chain as candidate block messages. The above-mentioned consensus processing refers to: completing the consensus processing operation on the block message. During the consensus processing process, the consensus node can vote on the target block message. When the number of votes in favor is greater than a certain number during the voting, the block message can be considered to be confirmed once. If multiple rounds of confirmation are required, then when voting on other block messages (such as sub-blocks) that are on the same link as the target block message and have a block height higher than the block height of the target block message, the number of votes in favor is greater than a certain number (such as the sub-block is confirmed), and the target block is considered to be confirmed once again.

[0076] In one implementation, based on the size relationship between the block height of the target block message and the block height of the candidate block message, it can be determined whether the blockchain has a fork. If the block height of the target block message is greater than the current chain height, and less than or equal to the current node height, it is determined that the blockchain has a fork. Specifically, when the block height of the target block message is equal to the block height of any candidate block message, and the preceding block message is a block message on the blockchain or a candidate block message in the local space, it can be determined that the blockchain logically has multiple branches (i.e., forks) starting from a certain block. It is understandable that the blockchain maintained by the first consensus node has not actually forked. For example, if Figure 5aThe schematic diagram of a forked blockchain is shown in the figure. The current node height is 6 and the current chain height is 4. For example, the block height of the target block message is 5, and the previous block is the last block on the blockchain. If there is a candidate block message (block 5) with a block height of 5 in the local space, and the target block message (block 5') and the candidate block message both use the last block on the blockchain as the previous block, then it can be determined that the blockchain is forked. For another example, if the block height of the target block message is 6, and the previous block is a candidate block message (block 5) with a block height of 5 in the local space, then it can be determined that the blockchain is forked.

[0077] In the event of a fork in the blockchain, the candidate block messages and target block messages in the local space can be divided into at least two links; the block heights of the block messages in any link are continuous, and the previous block message of two adjacent block messages is used as the preceding block of the next block message. In one implementation, if the candidate block messages in the local space are block height continuous, and the previous block message of two adjacent candidate block messages is used as the preceding block of the next block message, then two links can be obtained through the division operation, one link including the candidate block messages in the local space, and the other link including the target block message. If the candidate block messages in the local space only satisfy the block height continuity but do not satisfy the previous block message of two adjacent candidate block messages being used as the preceding block of the next block message, then the two adjacent candidate block messages correspond to two separate links respectively through the division operation, such as Figure 5b shown.

[0078] Further, the first consensus node can detect whether there is a block message in at least two links that meets the on-chain conditions, and the detection here can be a timed detection or a real-time detection. When it is detected that there is a block message in at least two links that meets the on-chain conditions, the block message that meets the on-chain conditions is processed on the chain; and, the link containing the block message that meets the on-chain conditions in at least two links is used as the main link, and the block messages in each link other than the main link in at least two links are deleted. The on-chain conditions here include but are not limited to: having passed the consensus process, being qualified for on-chain, and the blockchain reaching the corresponding chain height. Among them, the blockchain reaching the corresponding chain height means that the chain height of the blockchain is continuous with the block height of the block message that meets the on-chain conditions. Being qualified for on-chain may include: the number of confirmation rounds for the block message reaches the number required by the consensus algorithm. When it is detected that there is a block message in each block message of at least two links that meets the chain-up conditions, the block message that meets the chain-up conditions can be submitted to the blockchain, and the link where the block message that meets the chain-up conditions is located can be determined as the main link, and each link except the main link is a branch link.

[0079] Furthermore, the block message in the main link can be submitted to the blockchain, while the block message in the branch link can be deleted. Submitting the block message here can be understood as storing the block message on the blockchain. Each block message on the branch link can be called a fork consensus message. For the fork consensus message, it may be cached in the local space after consensus processing, or it may be cached in the local space without consensus processing. For example, Figure 6a As shown, when the first consensus node Node2 receives block 6' first, since block 6' is a pre-consensus block, it can be cached locally at the node first, and then blocks 5, 6, and 7 are received in sequence. After block 5 is confirmed on the chain, block 6' is determined to be a fork consensus message, and block 6' can be deleted. In this process, block 6' has not been processed by consensus. For another example, Figure 6b As shown, when the first consensus node Node2 first receives block 5', it performs consensus processing on block 5' and caches it locally, and then receives blocks 5, 6 and 7. After confirming the on-chain block 5, it determines that block 5' is a fork consensus message, and then deletes block 5'. In this process, block 5' as a fork consensus message has undergone consensus processing.

[0080] In one embodiment, the block height of the target block message is greater than the current chain height and less than or equal to the current node height. Then: if the block height of the target block message is equal to the current node height, or there is continuity between the block height of the target block message and the current chain height, the target block message is processed by consensus. After the target block message passes the consensus processing, if it is not determined that the target block message needs to be deleted, the target block message is cached in the local space. Specifically, when the block height of the target block message is equal to the current node height and there is continuity between the block height of the target block message and the current chain height, when the information in the target block message indicates that there is a pre-block for linking in the first consensus node, the target block message can be processed by consensus. When the block height of the target block message is equal to the current node height, the blockchain is forked, and based on the relationship between the block height of the target block message, the current chain height and the current node height, it is necessary to determine whether the target block message is a forked consensus message, and then decide whether to delete the target block message. In a feasible implementation, after the target block message passes the consensus processing, the link division operation may not be performed, or the block message that meets the chain conditions may not be detected, or the main link may not be determined, or the link division operation is performed and the main link is determined, but the main link contains the target block message. In these cases, it can be considered that the target block message needs to be deleted, so that the target block message after consensus processing can be cached in the local space for use in subsequent chaining. In one implementation, if it is determined to be deleted but the target block message has not been cached in the local space, it can be directly deleted without caching. Directly deleting the target block message can avoid wasting processing resources and storage resources due to useless block messages being cached in the local space. If it is determined that the target block message needs to be deleted, and the target block message has been cached in the local space, then the target block message can be deleted from the local space, thereby avoiding unlimited expansion of data in the local space.

[0081] In the above method, when it is determined that a fork occurs in the blockchain, the main link and the branch link can be determined, so that the block message in the branch link can be deleted. If the block message in the branch link is cached in the local space, the useless block message in the local space can be cleared by deletion, thereby avoiding the occupation of storage resources by useless data.

[0082] S403: If the target block message is determined to be an advanced consensus message according to the current node status, the target block message is cached in the local space.

[0083] In a specific implementation, it is possible to determine whether the target block message is an advanced consensus message based on the current node height included in the current node state, and it is also possible to determine other message types based on one or more of the current node height and the current chain height included in the current node state, which may include any of the following: redundant consensus message, matching consensus message. In one embodiment, if the target block message is determined to be a matching consensus message according to the current node state, the target block message can be processed by consensus, and after the consensus processing, the target block message is cached in the local space. A matching consensus message refers to a block message that can be processed by consensus based on the current node state of the first consensus node, that is, a block message that can be processed by the first consensus node at the current moment. When the current node state reaches the node state required for consensus processing of the matching consensus message, the target block message can be processed by consensus. Schematically, when the block height of the target block message is continuous with the current node height and the block corresponding to the preceding block hash is the block with the maximum block height in the memory, or when the block height of the target block message is continuous with the current chain height and the block corresponding to the preceding block hash is the last block on the blockchain, it can be determined to be a matching consensus message. Specifically, when it is determined that the target block message is a matching consensus message, it means that the target block message can be processed by consensus under the current node state of the first consensus node, and the current node state matches the target block message. Therefore, the target block message can be processed by consensus.

[0084] In one embodiment, if the target block message is determined to be a redundant consensus message based on the current node state, the target block message is deleted. Redundant consensus messages refer to block messages that are not on the chain and whose block height is less than or equal to the current chain height in the current node state. Specifically, if the block height of the target block message is less than or equal to the current chain height in the current node state, and the target block message is not on the chain, then the target block message can be determined to be a redundant consensus message. For example: the chain height of the blockchain is 4, and the target block message is the same as the last block on the blockchain, then the target block message is a redundant consensus message. In the case where it is determined that the target block message is a redundant consensus message, it indicates that the first consensus node has consensus-processed messages with the same block height, and there are already block messages with the same block height on the blockchain, so there is no need to consensus-process the block message again.

[0085] In one achievable manner, while waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, the first consensus node may not be updated for a period of time and remains in the current node state. Then the contents shown in S404 to S406 below may be executed.

[0086] S404, receiving a reference block message to be processed for consensus.

[0087] Because before the current node state is updated, the block messages that can be processed by consensus cached in the local space have been processed before the node state reaches the current node state, and there are no processable block messages in the local space. Therefore, the first consensus node can wait to receive a new block message (i.e., a reference block message), and the reference block message refers to a block message that can be processed by consensus based on the current node state. The reference block message can be sent by the second node or by other nodes. The block height of the reference block message may be greater than or equal to the block height of the target block message. For example, the node height is 5, the target block message is a block with a block height of 7, and the reference block message is a block with a block height of 6. In one implementation, if the block height of the reference block message is equal to the block height of the target block message, and the target consensus message is not on the chain, then when the preceding blocks of the two block messages are the same block, it can be determined that the blockchain is forked, and the forked consensus message can be judged according to the above-mentioned content.

[0088] S405, consensus processing is performed on the reference block message to update the current node state; and after the current node state is updated, a state callback mechanism is used to determine the updated node state.

[0089] In a specific implementation, the first consensus node can perform consensus processing on the reference block message, and then update the current node height in the current node state to a new node height. After updating the current node state, the state callback mechanism can be used to call back the updated node state, and the updated node state includes the updated node height. Based on the updated node height, it can be queried from the local space whether there is a consensus message that can be processed and wait to receive a new consensus message.

[0090] S406, obtaining block messages that can be processed by consensus based on the updated node status from the local space, and performing consensus processing on the obtained block messages.

[0091] After the current node status is updated, the block message that the first consensus node can process by consensus can be obtained from the local space based on the updated node status, and consensus processing can be performed on the obtained block message. The block message obtained here may be the target consensus message, or it may be an advanced consensus message determined at a historical moment (i.e., a moment earlier than the current moment). Figure 3b For example, the node height is 5, the target block message is block 7 with a block height of 7 and is cached locally, and the block height of the reference block message is 6. After the consensus process of the reference block message is completed, the node height is updated to 6, and the target block message (block 7) can be obtained from the local space for consensus processing.

[0092] In one embodiment, the first consensus node includes the following working states: consensus state and non-consensus state; the consensus state refers to the working state when a block message is processed by consensus; the non-consensus state refers to the working state when no block message is processed by consensus. Exemplarily, if the first consensus node is consensus block 7, then the first consensus node is in the consensus state; if the first consensus node has not consensus block 7, then the first consensus node is in the non-consensus state.

[0093] The first consensus node can: determine the current working state of the first consensus node, and the current working state refers to: the working state of the first consensus node at the moment of receiving the target block message. The working state may be a non-consensus state or a consensus state. If the current working state is a non-consensus state, the step of receiving the reference block message to be processed by consensus is triggered; that is, when the first consensus node has not currently reached a consensus on other block messages, the current node state is updated by receiving the reference block message and performing consensus processing on it. In other words, if the first consensus node has not reached a consensus on any block message, it can wait to receive a new block message, that is, receive a reference block message, and update the current node state based on the consensus processing of the received reference block message. If the current working state is a consensus state, after updating the current node state based on the block message currently being processed by consensus, it jumps to the step of determining the updated node state using the state callback mechanism, and then the block message matching the updated node state can be obtained from the local space for consensus processing. For example, when the target block message is received, the current node height in the current node state is 6. If the first consensus node is consensus block 7, then after block 7 passes consensus, the current node state can be updated, and then the block message that can be processed can be queried from the local space, and the obtained block message can be processed by consensus.

[0094] In one embodiment, after any block message in the first consensus node is chained, the corresponding block message is marked; for example, after the block message cached in the local space that has passed the consensus process but has not been chained is chained, the block message in the local space can be marked so as to subsequently filter out the block message that has been chained but cached in the local space. Then the first consensus node can also: based on the updated node status, query invalid block messages in the local space; invalid block messages include at least one of the following: fork consensus messages, and marked block messages; fork consensus messages refer to: block messages that cause the blockchain to fork; if at least one invalid block message is queried, the invalid block message is deleted in the local space. Specifically, since the fork consensus message does not need to be submitted to the blockchain, if the fork consensus message exists in the local space, it can be deleted, and before deleting the fork consensus message, the fork consensus message may have been processed by consensus and cached locally, or it may not have been processed by consensus. A marked block message refers to a block message obtained from the local space that is marked when it is determined to be submitted to the blockchain after consensus processing. The marked block message can also be deleted after the current node status is updated. After the current node status is updated, by querying and deleting invalid consensus messages, useless data in the local space can be cleaned up, thereby avoiding the expansion of cached data in the local space, and also leaving space for caching subsequent block messages.

[0095] It is understandable that each time the node status of the first consensus node is updated, the status callback mechanism can be used to determine the updated node status, and the latest node status of the first consensus node can be called back through the status callback mechanism, so as to query whether there is a processable block message in the local space based on the latest node status, and directly request the block message from the local space for consensus processing when the query is found. In an achievable manner, if no query is found, the local space can continue to be queried to see whether there is an invalid consensus message, or when querying the processable block message, the local space can be synchronously queried to see whether there is an invalid consensus message, and the existing invalid consensus message can be deleted, thereby avoiding the expansion of cached data in the first consensus node.

[0096] S407, after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, obtain the target block message from the local space, and perform consensus processing on the target block message based on the target node state.

[0097] In one embodiment, after consensus processing is performed on the target block message based on the target node state, if it is determined that the target block message meets the on-chain condition, the target block message is processed on the chain to update the chain height of the blockchain in the first consensus node to the block height of the target block message; wherein the chain height refers to the height of the last block stored on the blockchain in the first consensus node. Specifically, the on-chain processing here may refer to adding the target block message to the blockchain of the first consensus node, and specifically may be storing the block on the blockchain, so that the chain height of the blockchain can be automatically updated. In one implementation, the chain height of the blockchain can be updated according to the block height of the target consensus message that meets the on-chain condition, which is equivalent to the local block height of the first consensus node that can record the consensus and on-chain block message. When the first consensus node needs to obtain the latest chain height, the first consensus node can obtain the latest chain height by accessing the recorded block height of the consensus and on-chain block message without accessing the blockchain, thereby improving the efficiency of the first consensus node in obtaining the chain height.

[0098] In one possible implementation, the conditions for being on the chain include: the block message must be eligible for being on the chain; the blockchain network is configured with a consensus mechanism. The consensus mechanism is commonly referred to as a consensus algorithm, which includes but is not limited to: Byzantine Fault Tolerance (BFT) consensus algorithm, Practical Byzantine Fault Tolerance (PBFT) consensus algorithm, HotStuff consensus algorithm (a three-stage voting BFT-type consensus protocol), Proof of Work (PoW), etc. The consensus mechanism is used to indicate that any block message must go through K rounds of confirmation before being on the chain, where K is a positive integer. Different consensus mechanisms may require different rounds of confirmation for the block message to be on the chain. For example, the block message indicated by the BFT consensus algorithm needs to go through one round of confirmation for being on the chain, and each node can only vote for it once when participating in the consensus. The block message indicated by the Tendermint consensus algorithm (a consensus algorithm optimized from the PBFT consensus algorithm) needs to go through 2 rounds of confirmation before it can be put on the chain, and the block message needs to go through two rounds of voting to decide whether to put it on the chain. The block message indicated by the HotStuff consensus algorithm needs to go through 3 rounds of confirmation before it can be put on the chain. HotStuff uses chain confirmation. Since the recognition of a block is actually the recognition of the parent block of the block. Therefore, in the chained HotStuff, the confirmation of the block can be placed in the next block. Three consecutive blocks are generated after a block, which means that the block has been confirmed by three rounds of voting.

[0099] There are two ways to determine whether the target block message is eligible for on-chain: (1) monitor the number of confirmation rounds corresponding to the target block message. If the monitored number of confirmation rounds is equal to K, the target block message is determined to be eligible for on-chain. (2) upon receiving the on-chain notification for the target block message sent by the second consensus node, the target block message is determined to be eligible for on-chain.

[0100] For (1), as long as the first consensus node receives the confirmation rounds for the target block message that meet the indicated confirmation rounds K, it can be determined that the target block message meets the on-chain conditions, and then the target consensus block can be on-chain. Based on the consensus mechanism adopted, a confirmation received by the first consensus node for the target block message may mean that the number of votes cast in favor of the target block message by each consensus node is greater than a preset number threshold. The confirmation here can be the number of votes logically cast by the first consensus node for the target block message. For example: after the first consensus node performs consensus processing on blocks 5, 6, and 7 in turn, when the consensus processing on block 7 is completed and more than the preset number of votes in favor of block 7 are received, it can represent that block 5 has been confirmed 3 times, so block 5 can be on-chain.

[0101] Regarding (2), after the first consensus node completes the consensus processing of the target block message, if it receives the on-chain notification for the target block message sent by the second consensus node before the first consensus node itself confirms that the on-chain conditions are met, then it can be determined that the target block message meets the on-chain conditions, and then the target block message is directly on-chained. Specifically, the on-chain notification for the target block message is used to indicate that the target block message can be added to the blockchain in the second consensus node, and because the blockchains in different consensus nodes are copies of a certain blockchain, that is, the target block message can also be added to the blockchain in the first consensus node, if the first consensus node has not yet reached a consensus on the target block message before receiving the on-chain notification, then the first consensus node does not need to reach a consensus on the target block message. In one implementation, the target block message can be added to the blockchain when the chain height of the blockchain in the first consensus node is updated to the chain height required for the target block message to be on-chained. At the required chain height, the block with the maximum block height on the blockchain can be used as the previous block message of the target block message. That is, the target block message can wait for the block on the blockchain in the consensus node to be updated to a previous block that the target block message can link to, and then the target block message will be put on the chain. The chain height of the blockchain in the first consensus node can be updated based on the block message submitted by the first consensus node. For example, the above Figure 3b After block 7 is confirmed, Node2 can broadcast an on-chain notification to Node1, such as Figure 3bBefore Node2 processes block 7 through consensus, if it receives a notification from Node1 about uploading block 7 to the blockchain, it may not process block 7. Instead, when block 6 exists in the blockchain maintained by Node1 and the chain height is 6, it may directly submit block 7 to the blockchain and update the chain height to 7.

[0102] It is understandable that the second consensus node sends the on-chain notification to the consensus node that has previously synchronized the target block message. Then, when each consensus node that receives the target block message allows consensus processing of the target block message in the node state, the consensus node may not perform consensus processing on the target block message, but add the target block message to the blockchain. After the target block message is on-chained to the blockchain in the first consensus node, the first consensus node may also broadcast an on-chain notification for the target block message to other nodes (such as the second consensus node), thereby avoiding other consensus nodes from performing repeated consensus processing on the target block message that has passed consensus but has not yet been on-chain, saving processing resources, and then submitting the target block message to the blockchain maintained by itself, and updating the chain height of the maintained blockchain.

[0103] In the above implementation, different consensus nodes can independently upload the same block message to the chain, without relying on the notification of upload broadcasted by other consensus nodes. In this process, even if the target block message is first uploaded to the chain in the second consensus node, the first consensus node still needs to perform consensus processing on the target block message to participate in the consensus on the target block message on its behalf. The block message uploaded to the chain is sufficiently trustworthy through the consensus confirmation of multiple consensus nodes; a consensus node can also improve the efficiency of updating the node status by receiving the notification of upload sent by other consensus nodes.

[0104] In one achievable manner, based on the above scheme, the following can be provided: Figure 7 An exemplary data processing flow chart is shown. Whenever the node status is updated, the local space can be queried first to see if there are block messages that can be processed in the cache. If so, the block messages in the cache are processed. If not, the local space can be further queried to see if there are invalid block messages cached, and then the invalid block messages are cleared when there are invalid block messages in the cache. If the message in the cache is processed to update the node status, the above process can be repeated. It can be seen that after the node status is updated, the cache is queried to see if there are invalid block messages or block messages that have been processed on the chain, and then the useless block messages in the local space can be deleted to avoid cache data expansion. If the message in the cache is processed but the node status is not updated, it may be because the blockchain has forked, and the local space can be queried to see if there are invalid block messages cached, and then the invalid block messages can be cleared when there are invalid block messages in the cache.

[0105] The above data processing scheme is described based on the logic that the first consensus node in the blockchain network receives a target block message synchronized by the second consensus node. Due to the decentralized nature of the blockchain network, the first consensus node in the blockchain network can also receive block messages synchronized by multiple consensus nodes at the same time, and a consensus node can synchronize a block message to the first consensus node.

[0106] In one embodiment, the blockchain network also includes a third consensus node. When receiving the target block message synchronized by the second consensus node, the third block message synchronized by the third consensus node is also received. That is, the first consensus node synchronously receives the block message synchronized by different consensus nodes. The block height of the third block message may be the same as or different from the target block height.

[0107] In one implementation, if the block height of the third block message is the same as the block height of the target block message, it is determined that a fork occurs in the blockchain in the first consensus node; and then, when the target block message is determined to be an advanced consensus message, the third block message is determined to be an advanced consensus message, and the third block message is cached in the local space. Block messages of the same block height only need to determine whether one is an advanced consensus message to determine whether the other is an advanced consensus message, which can improve the processing efficiency of other synchronously received block messages. The pre-block message of the third block message may be the same as the pre-block message of the target block message, or the pre-block message of the block message in the link where the target block message is located, where the block height is less than that of the target block message, may be the same. Since the fork is determined, it is also necessary to detect which block message between the target block message and the third block message is the fork consensus message. After consensus processing of the target block message, if it is detected that the target block message meets the on-chain conditions, the target block message is processed on the chain, and the third block message is deleted as a fork consensus message; after consensus processing of the third block message, if it is detected that the third block message meets the on-chain conditions, the third block message is processed on the chain, and the target block message is deleted as a fork consensus message. For the detection of whether the block message meets the on-chain conditions, please refer to the aforementioned relevant content of detecting whether the target block message meets the on-chain conditions, which will not be elaborated here. For example, if Figure 8 As shown, when Node4 synchronizes block 6, Node5 also synchronizes block 6', and block 6 and block 6' have the same preceding block hash, so it can be determined that a fork has occurred, and the block heights of the two are also the same. Since both blocks can be processed by Node2, they can be processed in sequence and then cached in the local space. When confirming the on-chain of block 6, block 6' is determined to be a fork consensus message and block 6' is deleted.

[0108] In another implementation, if the block height of the third block message is different from the target block height, then for the third block message, the following operation may be performed: Figure 2 The same processing of the target consensus message in the illustrated embodiment. That is, for the first consensus node, when receiving block messages synchronized by at least two consensus nodes respectively and the block heights are different, for each block message, the relationship between the node state required for the corresponding block message to be consensused and the current node state can be determined based on the block message, and similar processing can be performed, that is: first determine whether it is an advanced consensus message based on the current node state. In the case of an advanced consensus message, it is first cached and when the node state is updated to a node state that can process the corresponding block message, the corresponding block message is obtained from the local space for consensus processing. The node states required for consensus of these block messages may be the same or different. In this way, for multiple block messages received at the same time, the block messages that are advanced consensus messages among the multiple block messages can be cached first, and the block message can be obtained from the local space for consensus processing after the node state reaches the required node state. Among multiple block messages, the block messages that can be processed under the current node state can be processed by consensus first. After the consensus processing is completed, the block messages can be cached in the local space so that they can be obtained from the local space when the corresponding target block messages are uploaded to the chain, thereby improving the consensus efficiency of the node.

[0109] The embodiment of the present application is based on the data processing method of the blockchain network, which caches the consensus message that cannot be processed currently in the node locally, reduces the behavior of requesting the same data again through the network later, and reduces the network communication volume of each node; in the process of waiting for the node state to reach the target node state required for processing the target block message, the node state is updated based on the consensus processing of the newly received block message, and the cached block message can be queried from the local space first after the node state is updated, thereby improving the processing efficiency. Each time the node state is updated, the message in the local cache can be queried first, and the cached information can be used to promote the node state, so that the node state can be pushed to the latest state on the chain faster. The overall solution adopts the calling mechanism of memory cache and state callback to process the consensus message received in advance. At the same time, in the callback action, it can query whether the cached state in the memory has a consensus message that meets the conditions and can be processed, and it can also delete some invalid data that cannot be used due to the fork of the blockchain network, so as to avoid the infinite expansion of cached data.

[0110] See also Fig. 9 , Fig. 9 It is a structural diagram of a data processing device based on a blockchain network provided in an embodiment of the present application. The data processing device based on a blockchain network can be arranged in a computer device provided in an embodiment of the present application, and the computer device can be the terminal device mentioned in the above method embodiment. Fig. 9 The data processing device based on the blockchain network shown may be a computer program (including program code) running in a computer device, and the data processing device based on the blockchain network may be used to execute Figure 2 Part or all of the steps in the method embodiment shown. The blockchain network includes a first consensus node and a second consensus node, and the data processing device based on the blockchain network may include the following units:

[0111] The transceiver unit 901 is used to receive a target block message synchronized by the second consensus node, where the target block message is a block message to be processed by consensus;

[0112] The processing unit 902 is used to determine the current node state of the first consensus node, where the current node state refers to the node state of the first consensus node at the moment of receiving the target block message;

[0113] The processing unit 902 is further configured to cache the target block message in the local space if the target block message is determined to be an advanced consensus message according to the current node state; the advanced consensus message refers to a block message that needs to be processed by consensus based on the node state that has not yet been reached by the first consensus node;

[0114] The processing unit 902 is also used to obtain the target block message from the local space after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, and perform consensus processing on the target block message based on the target node state.

[0115] In one embodiment, the current node state includes: the current node height and the current chain height;

[0116] The current node height refers to: the maximum block height among the block heights of each block message that has passed consensus processing in the first consensus node at the moment when the target block message is received;

[0117] The current chain height refers to the block height of the last block stored on the blockchain in the first consensus node at the moment when the target block message is received;

[0118] Among them, when the block height of the target block message is greater than the current node height, and there is a lack of continuity between the block height of the target block message and the current node height, the target block message is judged to be an advanced consensus message.

[0119] In one embodiment, the processing unit 902 is further configured to:

[0120] If the target block message is determined to be a redundant consensus message based on the current node status, the target block message is deleted;

[0121] Among them, redundant consensus messages refer to block messages that are not on the chain and whose block height is less than or equal to the current chain height in the current node state.

[0122] In one embodiment, when the current node height is greater than the current chain height, the local space includes: at least one candidate block message, the candidate block message refers to: a block message that has passed the consensus process and is not on the chain; the block height of any candidate block message is greater than the current node height and less than or equal to the current chain height; the processing unit 902 is further used to:

[0123] If the block height of the target block message is greater than the current chain height and less than or equal to the current node height, it is determined that the blockchain has a fork;

[0124] Divide the candidate block messages and target block messages in the local space into at least two links; the block heights of the block messages in any link are continuous, and the previous block message of two adjacent block messages is used as the preceding block of the next block message;

[0125] When it is detected that there is a block message in at least two links that meets the uplink condition, uplink the block message that meets the uplink condition; and,

[0126] The link including the block message satisfying the uplink condition among the at least two links is taken as the main link, and the block messages in each link except the main link among the at least two links are deleted.

[0127] In one embodiment, if the block height of the target block message is greater than the current chain height and less than or equal to the current node height, the processing unit 902 is further configured to:

[0128] If the block height of the target block message is equal to the current node height, or the block height of the target block message is continuous with the current chain height, the target block message is processed by consensus;

[0129] After the target block message passes the consensus process, if it is not determined that the target block message needs to be deleted, the target block message is cached in the local space.

[0130] In one embodiment, after caching the target block message in the local space, the processing unit 902 is further configured to:

[0131] Receive reference block messages to be processed for consensus, where reference block messages refer to block messages that can be processed for consensus based on the current node status;

[0132] Perform consensus processing on the reference block message to update the current node status; and after updating the current node status, use the status callback mechanism to determine the updated node status;

[0133] From the local space, obtain block messages that can be processed by consensus based on the updated node status, and perform consensus processing on the obtained block messages.

[0134] In one embodiment, the first consensus node includes the following working states: consensus state and non-consensus state; the consensus state refers to the working state when consensus processing is performed on a block message; the non-consensus state refers to the working state when consensus processing is not performed on any block message; the processing unit 902 is further used to:

[0135] Determine the current working state of the first consensus node, where the current working state refers to the working state of the first consensus node at the moment of receiving the target block message;

[0136] If the current working state is a non-consensus state, the step of receiving a reference block message to be processed by consensus is triggered;

[0137] If the current working state is the consensus state, after updating the current node state based on the block message currently being processed by consensus, jump to the step of using the state callback mechanism to determine the updated node state.

[0138] In one embodiment, after any block message in the first consensus node is uploaded to the chain, the corresponding block message is marked; the processing unit 902 is further used to:

[0139] Based on the updated node status, query the invalid block message in the local space; the invalid block message includes at least one of the following: fork consensus message and marked block message; fork consensus message refers to: block message that causes a fork in the blockchain;

[0140] If at least one invalid block message is found, the invalid block message is deleted in the local space.

[0141] In one embodiment, the blockchain network further includes a third consensus node. If, when receiving the target block message synchronized by the second consensus node, a third block message synchronized by the third consensus node is also received, the processing unit 902 is further configured to:

[0142] If the block height of the third block message is the same as the block height of the target block message, it is determined that a fork occurs in the blockchain in the first consensus node;

[0143] In the case where it is determined that the target block message is an advanced consensus message, the third block message is determined to be an advanced consensus message, and the third block message is cached in the local space;

[0144] After consensus processing of the target block message, if it is detected that the target block message meets the on-chain conditions, the target block message is processed on-chain, and the third block message is deleted as a fork consensus message;

[0145] After consensus processing is performed on the third block message, if it is detected that the third block message meets the on-chain conditions, the third block message is processed on the chain, and the target block message is deleted as a fork consensus message.

[0146] In one embodiment, after consensus processing is performed on the target block message based on the target node state, the processing unit 902 is further configured to:

[0147] If it is determined that the target block message meets the on-chain conditions, the target block message is processed on-chain to update the chain height of the blockchain in the first consensus node to the block height of the target block message;

[0148] The chain height refers to the height of the last block stored on the blockchain in the first consensus node.

[0149] In one embodiment, the on-chain conditions include: the block message must be eligible for on-chain; the blockchain network is configured with a consensus mechanism, which is used to indicate that any block message must be confirmed by K rounds before being on-chain, where K is a positive integer; the processing unit 902 is also used to:

[0150] Monitor the number of confirmation rounds corresponding to the target block message. If the monitored number of confirmation rounds is equal to K, it is determined that the target block message is eligible for on-chain; or, when receiving the on-chain notification for the target block message sent by the second consensus node, it is determined that the target block message is eligible for on-chain.

[0151] Through the embodiments of the present application, it is possible to avoid discarding the advanced consensus messages that cannot be processed at present, and instead cache the advanced consensus messages in the local space of the consensus node, so that when the target node state is reached that can process the target block message by consensus, it can be directly obtained from the local space without requesting the target block message from other nodes through the network, thereby reducing the communication volume of the consensus nodes in the blockchain network, saving network bandwidth, and based on the relatively fast response speed of the local space, it can also improve the consensus efficiency of the nodes.

[0152] Next, the computer device provided in the embodiment of the present application is described.

[0153] See also Fig.10 , Fig.10It is a structural diagram of a computer device (i.e., the first consensus node mentioned above) provided in an embodiment of the present application. The computer device may include an independent device (e.g., one or more of a server, a node, a terminal, etc.), or may include components inside an independent device (e.g., a chip, a software module, or a hardware module, etc.). The computer device may include at least one processor 1001 and a communication interface 1002. Further optionally, the computer device may also include at least one memory 1003 and a bus 1004. Among them, the processor 1001, the communication interface 1002, and the memory 1003 are connected via a bus 1004.

[0154] Among them, the processor 1001 is a module that performs arithmetic operations and / or logical operations, and can specifically be a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a coprocessor (assisting the central processing unit to complete corresponding processing and applications), a microcontroller unit (MCU) and other processing modules, or a combination of multiple of them.

[0155] The communication interface 1002 may be used to provide information input or output for at least one processor. And / or, the communication interface 1002 may be used to receive data sent externally and / or send data externally, and may be a wired link interface including an Ethernet cable, etc., or a wireless link (Wi-Fi, Bluetooth, general wireless transmission, vehicle-mounted short-range communication technology, and other short-range wireless communication technologies, etc.) interface. The communication interface 1002 may be used as a network interface.

[0156] The memory 1003 is used to provide a storage space, in which data such as an operating system and a computer program can be stored. The memory 1003 can be a random access memory (RAM), a read-only memory (ROM), an erasable programmable read only memory (EPROM), or a portable read only memory (CD-ROM), etc., or a combination of multiple thereof.

[0157] In a possible implementation, the processor 1001 in the computer device is used to call a computer program stored in at least one memory 1003 to perform the following operations: receiving a target block message synchronized by the second consensus node, the target block message being a block message to be processed by consensus; determining a current node state of the first consensus node, the current node state referring to: the node state of the first consensus node at the moment of receiving the target block message; if the target block message is determined to be an advanced consensus message according to the current node state, then caching the target block message in the local space; the advanced consensus message refers to: a block message that needs to be processed by consensus based on the node state that the first consensus node has not yet reached; after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, obtaining the target block message from the local space, and performing consensus processing on the target block message based on the target node state.

[0158] In one embodiment, the current node state includes: the current node height and the current chain height;

[0159] The current node height refers to: the maximum block height among the block heights of each block message that has passed consensus processing in the first consensus node at the moment when the target block message is received;

[0160] The current chain height refers to the block height of the last block stored on the blockchain in the first consensus node at the moment when the target block message is received;

[0161] Among them, when the block height of the target block message is greater than the current node height, and there is a lack of continuity between the block height of the target block message and the current node height, the target block message is judged to be an advanced consensus message.

[0162] In one embodiment, the processor 1001 is further configured to:

[0163] If the target block message is determined to be a redundant consensus message based on the current node status, the target block message is deleted;

[0164] Among them, redundant consensus messages refer to block messages that are not on the chain and whose block height is less than or equal to the current chain height in the current node state.

[0165] In one embodiment, when the current node height is greater than the current chain height, the local space includes: at least one candidate block message, the candidate block message refers to: a block message that has passed the consensus process and is not on the chain; the block height of any candidate block message is greater than the current node height and less than or equal to the current chain height; the processor 1001 is further used to:

[0166] If the block height of the target block message is greater than the current chain height and less than or equal to the current node height, it is determined that the blockchain has a fork;

[0167] Divide the candidate block messages and target block messages in the local space into at least two links; the block heights of the block messages in any link are continuous, and the previous block message of two adjacent block messages is used as the preceding block of the next block message;

[0168] When it is detected that there is a block message in at least two links that meets the uplink condition, uplink the block message that meets the uplink condition; and,

[0169] The link including the block message satisfying the uplink condition among the at least two links is taken as the main link, and the block messages in each link except the main link among the at least two links are deleted.

[0170] In one embodiment, if the block height of the target block message is greater than the current chain height and less than or equal to the current node height, the processor 1001 is further configured to:

[0171] If the block height of the target block message is equal to the current node height, or the block height of the target block message is continuous with the current chain height, the target block message is processed by consensus;

[0172] After the target block message passes the consensus process, if it is not determined that the target block message needs to be deleted, the target block message is cached in the local space.

[0173] In one embodiment, after caching the target block message in the local space, the processor 1001 is further configured to:

[0174] Receive reference block messages to be processed for consensus, where reference block messages refer to block messages that can be processed for consensus based on the current node status;

[0175] Perform consensus processing on the reference block message to update the current node status; and after updating the current node status, use the status callback mechanism to determine the updated node status;

[0176] From the local space, obtain block messages that can be processed by consensus based on the updated node status, and perform consensus processing on the obtained block messages.

[0177] In one embodiment, the first consensus node includes the following working states: consensus state and non-consensus state; the consensus state refers to the working state when consensus processing is performed on a block message; the non-consensus state refers to the working state when consensus processing is not performed on any block message; the processor 1001 is further used to:

[0178] Determine the current working state of the first consensus node, where the current working state refers to the working state of the first consensus node at the moment of receiving the target block message;

[0179] If the current working state is a non-consensus state, the step of receiving a reference block message to be processed by consensus is triggered;

[0180] If the current working state is the consensus state, after updating the current node state based on the block message currently being processed by consensus, jump to the step of using the state callback mechanism to determine the updated node state.

[0181] In one embodiment, after any block message in the first consensus node is uploaded to the chain, the corresponding block message is marked; the processor 1001 is further configured to:

[0182] Based on the updated node status, query the invalid block message in the local space; the invalid block message includes at least one of the following: fork consensus message and marked block message; fork consensus message refers to: block message that causes a fork in the blockchain;

[0183] If at least one invalid block message is found, the invalid block message is deleted in the local space.

[0184] In one embodiment, the blockchain network further includes a third consensus node. If, when receiving the target block message synchronized by the second consensus node, a third block message synchronized by the third consensus node is also received, the processor 1001 is further configured to:

[0185] If the block height of the third block message is the same as the block height of the target block message, it is determined that a fork occurs in the blockchain in the first consensus node;

[0186] In the case where it is determined that the target block message is an advanced consensus message, the third block message is determined to be an advanced consensus message, and the third block message is cached in the local space;

[0187] After consensus processing of the target block message, if it is detected that the target block message meets the on-chain conditions, the target block message is processed on-chain, and the third block message is deleted as a fork consensus message;

[0188] After consensus processing is performed on the third block message, if it is detected that the third block message meets the on-chain conditions, the third block message is processed on the chain, and the target block message is deleted as a fork consensus message.

[0189] In one embodiment, after consensus processing is performed on the target block message based on the target node state, the processor 1001 is further configured to:

[0190] If it is determined that the target block message meets the on-chain conditions, the target block message is processed on-chain to update the chain height of the blockchain in the first consensus node to the block height of the target block message;

[0191] The chain height refers to the height of the last block stored on the blockchain in the first consensus node.

[0192] In one embodiment, the on-chain conditions include: the block message must be eligible for on-chain; the blockchain network is configured with a consensus mechanism, which is used to indicate that any block message must be confirmed by K rounds before being on-chain, where K is a positive integer; the processor 1001 is also used to:

[0193] Monitor the number of confirmation rounds corresponding to the target block message. If the monitored number of confirmation rounds is equal to K, it is determined that the target block message is eligible for on-chain; or, when receiving the on-chain notification for the target block message sent by the second consensus node, it is determined that the target block message is eligible for on-chain.

[0194] Through the embodiments of the present application, it is possible to avoid discarding the advanced consensus messages that cannot be processed at present, and instead cache the advanced consensus messages in the local space of the consensus node, so that when the target node state is reached that can process the target block message by consensus, it can be directly obtained from the local space without requesting the target block message from other nodes through the network, thereby reducing the communication volume of the consensus nodes in the blockchain network, saving network bandwidth, and based on the relatively fast response speed of the local space, it can also improve the consensus efficiency of the nodes.

[0195] In addition, it should be noted that the embodiment of the present application also provides a computer-readable storage medium, in which a computer program of the aforementioned blockchain network detection method is stored. When the computer program is executed by a processor, the description of the blockchain network detection method in the embodiment of the present application is executed. That is, when one or more processors load and execute the computer program, the description of the blockchain network detection method in the embodiment can be implemented, which will not be repeated here, and the description of the beneficial effects of using the same method will not be repeated here.

[0196] The computer-readable storage medium may be a detection device of the blockchain network provided in any of the aforementioned embodiments or an internal storage unit of the computer device, such as a hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flashcard), etc. equipped on the computer device. Furthermore, the computer-readable storage medium may also include both an internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0197] In one aspect of the present application, a computer program product or a computer program is provided, wherein a processor of a computer device reads the computer program from a computer-readable storage medium, and the processor executes the computer program, so that the computer device performs a method for detecting a blockchain network provided in one aspect of an embodiment of the present application.

[0198] In one aspect of the present application, another computer program product or computer program is provided, which includes a computer program, which, when executed by a processor, implements the steps of the blockchain network detection method provided in an embodiment of the present application.

[0199] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

[0200] The units in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.

[0201] The above disclosure is only part of the embodiments of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made in the claims of the present application still fall within the scope covered by the present application.

Claims

1. A data processing method based on a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, and the method is performed by the first consensus node; the method includes: Receive a target block message synchronized by the second consensus node, where the target block message is a block message to be processed by consensus; Determine a current node state of the first consensus node, where the current node state refers to: the node state of the first consensus node at the moment of receiving the target block message; If the target block message is determined to be an advanced consensus message according to the current node state, the target block message is cached in the local space; the advanced consensus message refers to a block message that needs to be processed by consensus based on the node state that the first consensus node has not yet reached; After waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, the target block message is obtained from the local space, and consensus processing is performed on the target block message based on the target node state.

2. The method according to claim 1, characterized in that The current node status includes: current node height and current chain height; The current node height refers to: at the moment of receiving the target block message, the maximum block height among the block heights of the block messages that have passed the consensus process in the first consensus node; The current chain height refers to: the block height of the last block stored on the blockchain in the first consensus node at the moment of receiving the target block message; Among them, when the block height of the target block message is greater than the current node height, and there is a lack of continuity between the block height of the target block message and the current node height, the target block message is determined to be an advanced consensus message.

3. The method according to claim 2, characterized in that The method further comprises: If the target block message is determined to be a redundant consensus message according to the current node status, the target block message is deleted; The redundant consensus message refers to a block message that is not on the chain and whose block height is less than or equal to the current chain height in the current node state.

4. The method according to claim 2, characterized in that When the current node height is greater than the current chain height, the local space includes: at least one candidate block message, where the candidate block message refers to a block message that has passed consensus processing and is not on the chain; the block height of any candidate block message is greater than the current node height and less than or equal to the current chain height; The method further comprises: If the block height of the target block message is greater than the current chain height and less than or equal to the current node height, it is determined that a fork occurs in the blockchain; Divide the candidate block message and the target block message in the local space into at least two links; the block heights of the block messages in any link are continuous, and the previous block message of two adjacent block messages is used as the preceding block of the next block message; When it is detected that there is a block message in the at least two links that meets the uplink condition, uplinking the block message that meets the uplink condition; and, The link including the block message satisfying the uplink condition among the at least two links is taken as the main link, and the block messages in each link among the at least two links except the main link are deleted.

5. The method according to claim 4, characterized in that If the block height of the target block message is greater than the current chain height and less than or equal to the current node height, the method further includes: If the block height of the target block message is equal to the current node height, or the block height of the target block message is continuous with the current chain height, consensus processing is performed on the target block message; After the target block message passes the consensus process, if it is not determined that the target block message needs to be deleted, the target block message is cached in the local space.

6. The method according to claim 1, characterized in that After caching the target block message in the local space, the method further includes: receiving a reference block message to be processed by consensus, wherein the reference block message refers to a block message that can be processed by consensus based on the current node state; Performing consensus processing on the reference block message to update the current node state; and after updating the current node state, using a state callback mechanism to determine the updated node state; From the local space, a block message that can be processed by consensus based on the updated node state is obtained, and consensus processing is performed on the obtained block message.

7. The method according to claim 6, characterized in that The first consensus node includes the following working states: consensus state and non-consensus state; the consensus state refers to the working state when consensus processing is performed on a block message; the non-consensus state refers to the working state when consensus processing is not performed on any block message; the method also includes: Determine a current working state of the first consensus node, where the current working state refers to: the working state of the first consensus node at the moment of receiving the target block message; If the current working state is the non-consensus state, triggering the step of receiving a reference block message to be processed by consensus; If the current working state is the consensus state, after updating the current node state based on the block message currently being processed by consensus, the process jumps to the step of using the state callback mechanism to determine the updated node state.

8. The method according to claim 6, characterized in that After any block message in the first consensus node is uploaded to the chain, the corresponding block message is marked; the method further includes: Based on the updated node status, query the local space for invalid block messages; the invalid block messages include at least one of the following: a fork consensus message and a marked block message; the fork consensus message refers to a block message that causes a fork in the blockchain; If at least one invalid block message is found, the invalid block message is deleted in the local space.

9. The method according to claim 1, characterized in that The blockchain network also includes a third consensus node. If, when receiving the target block message synchronized by the second consensus node, a third block message synchronized by the third consensus node is also received, the method further includes: If the block height of the third block message is the same as the block height of the target block message, it is determined that a fork occurs in the blockchain in the first consensus node; In the case where it is determined that the target block message is an advanced consensus message, determining that the third block message is an advanced consensus message, and caching the third block message in the local space; After consensus processing is performed on the target block message, if it is detected that the target block message meets the on-chain conditions, the target block message is processed on-chain, and the third block message is deleted as a fork consensus message; After consensus processing is performed on the third block message, if it is detected that the third block message meets the on-chain condition, the third block message is processed on the chain, and the target block message is deleted as a fork consensus message.

10. The method according to claim 1, characterized in that After consensus processing is performed on the target block message based on the target node state, the method further includes: If it is determined that the target block message meets the on-chain condition, the target block message is processed on-chain to update the chain height of the blockchain in the first consensus node to the block height of the target block message; The chain height refers to the height of the last block stored on the blockchain in the first consensus node.

11. The method according to claim 10, characterized in that The on-chain conditions include: the block message must be eligible for on-chain; the blockchain network is configured with a consensus mechanism, and the consensus mechanism is used to indicate that any block message must be confirmed by K rounds before being on-chain, where K is a positive integer; The method further comprises: Monitor the number of confirmation rounds corresponding to the target block message. If the monitored number of confirmation rounds is equal to K, determine that the target block message is eligible for on-chain; or, when receiving an on-chain notification for the target block message sent by the second consensus node, determine that the target block message is eligible for on-chain.

12. A data processing device based on a blockchain network, characterized in that: The blockchain network includes a first consensus node and a second consensus node, and the device includes: A transceiver unit, configured to receive a target block message synchronized by the second consensus node, wherein the target block message is a block message to be processed by consensus; a processing unit, configured to determine a current node state of the first consensus node, wherein the current node state refers to a node state of the first consensus node at the moment of receiving the target block message; The processing unit is further configured to cache the target block message in a local space if the target block message is determined to be an advanced consensus message according to the current node state; the advanced consensus message refers to a block message that needs to be processed by consensus based on a node state that has not yet been reached by the first consensus node; The processing unit is further used to obtain the target block message from the local space after waiting for the first consensus node to reach the target node state required for consensus processing of the target block message, and perform consensus processing on the target block message based on the target node state.

13. A computer device, characterized in that: include: a processor suitable for executing a computer program; A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by the processor, the data processing method based on the blockchain network as described in any one of claims 1 to 12 is executed.

14. A computer-readable storage medium, characterized in that: The computer storage medium stores a computer program, and when the computer program is executed by the processor, the data processing method based on the blockchain network as described in any one of claims 1 to 12 is executed.

15. A computer program product, characterized in that The computer program product includes a computer program or computer instructions, and the computer program or computer instructions are executed by a processor to implement the data processing method based on the blockchain network as described in any one of claims 1 to 12.

Images