Block chain data processing method and device, equipment and storage medium

Abstract

The embodiment of the invention discloses a block chain data processing method and device, equipment and a storage medium, and is applied to the block chain technology, and the method comprises the steps: obtaining transaction attribute information of a to-be-chained transaction from a current transaction pool of node equipment of a block chain network; when the current transaction pool meets the switching condition, switching the current transaction pool in the main node equipment into a target transaction pool matched with the transaction attribute information, and packaging a to-be-linked transaction in the current transaction pool of the main node equipment according to a transaction packaging format of the target transaction pool to obtain a to-be-verified block; a switching transaction is generated, and the to-be-verified block and the switching transaction are sent to the slave node equipment; and receiving a consensus result sent by the slave node equipment, and when the consensus result indicates that the to-be-verified block passes the consensus, according to the consensus result, uploading the to-be-verified block to a block chain corresponding to the block chain network. According to the invention, the network congestion of the block chain network can be avoided, and the transaction chaining efficiency is improved.

Description

Technical Field

[0001] The present application relates to fields such as blockchain technology, and in particular to a blockchain data processing method, device, equipment and storage medium. Background Art

[0002] A blockchain network can be a decentralized network composed of multiple node devices. When any node device in the blockchain network (for example, node device A) receives a transaction tx1 sent by a client, it will add the transaction tx1 to the transaction pool of node device A to be written to the blockchain. In addition, node device A will often broadcast the transaction tx1 to other node devices in the blockchain network (for example, node B).

[0003] In practice, blockchain networks only support a single type of transaction pool, which can easily lead to network congestion and inefficient transaction uploads. For example, when a blockchain network supports a universal transaction pool and node A becomes a proposing node and needs to produce a block, it packages the complete transaction tx1 along with other transactions from node A's universal transaction pool to create a block to be uploaded to the blockchain network. This block is then broadcast to other nodes in the network, which then reach consensus on it. Once consensus is reached, the block is uploaded to the blockchain. Consequently, any transaction in the block is broadcasted twice. This can lead to network congestion and inefficient transaction uploads when bandwidth is limited. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain data processing method, apparatus, device, and storage medium to avoid network congestion in the blockchain network and improve the efficiency of transaction on-chain.

[0005] On the one hand, an embodiment of the present application provides a blockchain data processing method, including:

[0006] Obtaining transaction attribute information of a transaction to be on-chain from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0007] When the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition, the current transaction pool in the master node device is switched to the target transaction pool that matches the transaction attribute information. The transactions to be uploaded to the chain in the current transaction pool of the master node device are packaged according to the transaction packaging format of the target transaction pool to obtain a block to be verified.

[0008] Generate a switch transaction, send the block to be verified and the switch transaction to the slave node device, and the slave node device is used to switch the current transaction pool in the slave node device to the target transaction pool according to the switch transaction, perform consensus processing on the block to be verified, and obtain a consensus result;

[0009] Receive the consensus result sent by the above-mentioned slave node device. When the above-mentioned consensus result indicates that the consensus of the above-mentioned block to be verified is passed, the above-mentioned block to be verified is chained to the blockchain corresponding to the blockchain network according to the above-mentioned consensus result.

[0010] On the one hand, an embodiment of the present application provides a blockchain data processing method, including:

[0011] Receiving a block to be verified and a switching transaction sent by a master node device in the blockchain network; the block to be verified is obtained by packaging and processing the transactions to be on-chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition and the current transaction pool in the master node device is switched to a target transaction pool that matches the transaction attribute information, and the transaction attribute information belongs to the transactions to be on-chain in the current transaction pool of the node device in the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0012] According to the switching transaction, the current transaction pool in the slave node device is switched to a target transaction pool that matches the transaction attribute information;

[0013] A consensus process is performed on the block to be verified to obtain a consensus result, and the consensus result is sent to the master node device; the master node device is used to link the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result when the consensus result indicates that the block to be verified has passed the consensus.

[0014] An embodiment of the present application provides a blockchain data processing device, including:

[0015] An acquisition module, configured to acquire transaction attribute information of a transaction to be on-chain from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0016] a switching module configured to, when the transaction attribute information indicates that the current transaction pool in the master node device satisfies a switching condition, switch the current transaction pool in the master node device to a target transaction pool that matches the transaction attribute information, and package the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified;

[0017] a sending module, configured to generate a switching transaction, and send the block to be verified and the switching transaction to the slave node device; the slave node device is configured to switch the current transaction pool in the slave node device to the target transaction pool according to the switching transaction, and perform consensus processing on the block to be verified to obtain a consensus result;

[0018] The on-chain module is used to receive the consensus result sent by the above-mentioned slave node device. When the above-mentioned consensus result indicates that the consensus of the above-mentioned block to be verified is passed, the above-mentioned block to be verified is chained to the blockchain corresponding to the blockchain network according to the above-mentioned consensus result.

[0019] Optionally, the transaction attribute information includes status information of the current transaction pools to which the transactions to be on-chained in the N node devices belong respectively; N is an integer greater than 1;

[0020] Optional, switching module, specifically used for:

[0021] Determine the difference between the status information of the current transaction pools to which the to-be-onlined transactions of each two node devices in the N node devices belong;

[0022] Determine the network status of the blockchain network based on the corresponding difference between every two node devices in the N node devices;

[0023] When the network status indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information;

[0024] Switch the current transaction pool in the master node device to the target transaction pool.

[0025] Optional, switching module, specifically used for:

[0026] Performing cumulative summation of the differences between every two node devices in the N node devices to obtain a total difference;

[0027] When the total difference is greater than the difference threshold, the network state of the blockchain network is determined to be abnormal.

[0028] When the total difference is less than or equal to the difference threshold, it is determined that the network status of the blockchain network is normal.

[0029] Optional, switching module, specifically used for:

[0030] Get the type of the current transaction pool in the above master node device;

[0031] When the current transaction pool in the master node device is of a general type and the network status of the blockchain network is abnormal, determining that the current transaction pool in the master node device meets the switching condition, and determining the batch type transaction pool as the target transaction pool that matches the transaction attribute information;

[0032] When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type, and the network status of the above-mentioned blockchain network is normal, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type of transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0033] Optionally, the transaction attribute information includes the business type of the to-be-online transaction in the current transaction pool of the master node device;

[0034] Optional, switching module, specifically used for:

[0035] Determine the stability of the demand for transactions to be on-chain in the current transaction pool of the master node device based on the above business type;

[0036] When the demand stability indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information;

[0037] Switch the current transaction pool in the master node device to the target transaction pool.

[0038] Optional, switching module, specifically used for:

[0039] Get the type of the current transaction pool in the above master node device;

[0040] When the current transaction pool in the master node device is of a general type and the demand stability is less than a stability threshold, it is determined that the current transaction pool in the master node device meets the switching condition, and a batch transaction pool is determined as a target transaction pool that matches the transaction attribute information;

[0041] When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type, and the above-mentioned demand stability is greater than or equal to the above-mentioned stability threshold, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type of transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0042] Optionally, the target transaction pool type is batch type;

[0043] Optional, switching module, specifically used for:

[0044] Obtain the transaction identifier of the transaction to be uploaded to the blockchain in the current transaction pool of the master node device, as well as the maximum block height of the block on the blockchain;

[0045] Generate a batch identifier based on the maximum block height and the pending transactions in the masternode device's current transaction pool;

[0046] Execute the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result;

[0047] Packaging the transaction identifier, the batch identifier, and the first execution result to obtain a block to be verified;

[0048] Among them, the above-mentioned slave node device is also used to execute the to-be-on-chain transactions in the current transaction pool of the above-mentioned slave node device according to the above-mentioned block to be verified, obtain a second execution result, verify the validity of the above-mentioned first execution result according to the above-mentioned second execution results, obtain a first verification result, verify the validity of the above-mentioned block to be verified, obtain a second verification result, and determine the consensus result of the above-mentioned block to be verified according to the above-mentioned first verification result and the above-mentioned second verification result.

[0049] Optional, switching module, specifically used for:

[0050] Selecting a target node identifier that matches the maximum block height from the node identifiers of the node devices of the blockchain network;

[0051] Perform hash operations on the transactions to be uploaded to the blockchain in the current transaction pool of the master node device to obtain a hash value;

[0052] Generate a batch ID based on the hash value and the target node ID.

[0053] Optionally, the target transaction pool type is a general type;

[0054] Optional, switching module, specifically used for:

[0055] Execute the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result;

[0056] The transactions to be on-chain in the current transaction pool of the master node device and the first execution result are packaged to obtain a block to be verified;

[0057] Among them, the above-mentioned slave node device is also used to execute the to-be-on-chain transactions in the above-mentioned block to be verified, obtain a third execution result, verify the validity of the above-mentioned first execution result based on the above-mentioned third execution result, obtain a third verification result, verify the validity of the above-mentioned block to be verified, obtain a fourth verification result, and determine the consensus result of the above-mentioned block to be verified based on the above-mentioned third verification result and the above-mentioned fourth verification result.

[0058] Optional uplink module, specifically used for:

[0059] Based on the consensus result, remove the pending transactions that did not pass the consensus and the execution results of the pending transactions that did not pass the consensus from the block to be verified to obtain the first verified block;

[0060] Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0061] The first verified block is uploaded to the blockchain corresponding to the blockchain network.

[0062] Optional uplink module, specifically used for:

[0063] Based on the consensus result, remove the transaction identifiers and execution results corresponding to the pending transactions that failed to pass the consensus in the on-chain block to obtain an updated block;

[0064] Obtaining the to-be-online transaction corresponding to the transaction identifier in the update block from the current transaction pool of the master node device, and adding the obtained to-be-online transaction to the update block to obtain a second verified block;

[0065] Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0066] The second verified block is uploaded to the blockchain corresponding to the blockchain network.

[0067] An embodiment of the present application provides a blockchain data processing device, including:

[0068] A receiving module, configured to receive a block to be verified and a switching transaction sent by a master node device in the blockchain network; the block to be verified is obtained by packaging and processing the transactions to be on-chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition and the current transaction pool in the master node device is switched to a target transaction pool matching the transaction attribute information; the transaction attribute information belongs to the transactions to be on-chain in the current transaction pool of the node device in the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0069] a switching module, configured to switch the current transaction pool in the slave node device to a target transaction pool matching the transaction attribute information according to the switching transaction;

[0070] The sending module is used to perform consensus processing on the above-mentioned block to be verified, obtain a consensus result, and send the above-mentioned consensus result to the above-mentioned master node device; the above-mentioned master node device is used to, when the above-mentioned consensus result indicates that the consensus of the above-mentioned block to be verified has passed, chain the above-mentioned block to the blockchain corresponding to the blockchain network according to the above-mentioned consensus result.

[0071] On one hand, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are implemented.

[0072] On one hand, an embodiment of the present application provides a computer program product, including a computer program, which implements the steps of the above method when executed by a processor.

[0073] In this application, the blockchain network supports multiple types of transaction pools (such as the current transaction pool and the target transaction pool). When the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device can be used to: reflect the network status of the blockchain network, or reflect the business scenario to which the to-be-on-chain transaction belongs. Therefore, by dynamically switching the adapted transaction pool based on the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device, and packaging and processing the to-be-on-chain transaction according to the transaction packaging format corresponding to the switched transaction pool (i.e., the target transaction pool), the blockchain network can avoid network congestion, improve the efficiency of transaction on-chain, and meet the different performance requirements of the block network. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0075] Figure 1 This is a structural diagram of a blockchain data processing system provided by this application;

[0076] Figure 2 This is a schematic diagram of the interaction between node devices in a blockchain data processing system provided by this application;

[0077] Figure 3 This is a schematic diagram of the interaction between node devices in a blockchain data processing system provided by this application;

[0078] Figure 4 This is a flowchart of a blockchain data processing method provided by this application;

[0079] Figure 5 This is a schematic diagram of a scenario in which a block to be verified is generated according to a transaction packaging format corresponding to a batch-type transaction pool provided by this application;

[0080] Figure 6 This is a transaction packaging format corresponding to a general batch type transaction pool provided by this application, and a schematic diagram of the scenario for generating blocks to be verified;

[0081] Figure 7 This is a flowchart of another blockchain data processing method provided by this application;

[0082] Figure 8 This is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of the present application;

[0083] Figure 9 This is a structural diagram of another blockchain data processing device provided in an embodiment of the present application;

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

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

[0086] First, we introduce the blockchain data processing system used in this solution. Figure 1 , Figure 1 A schematic diagram of the structure of a blockchain data processing system provided in an embodiment of the present application. The blockchain data processing system may include a blockchain network.

[0087] The blockchain network is an end-to-end decentralized network composed of multiple node devices (also called blockchain nodes). The number of node devices in the blockchain network can be deployed according to actual needs. This application does not limit the number of node devices. Figure 1 The blockchain network includes two node devices as an example for explanation, and the two node devices are respectively a master node device 10a and a slave node device 11a.

[0088] The master node device 10a can be a consensus node in the blockchain, which is responsible for maintaining data consistency across the entire blockchain network. The master node device 10a is primarily responsible for packaging transactions to construct blocks to be verified during a consensus round and broadcasting these blocks to other slave node devices in the blockchain network. Therefore, the master node device 10a plays a key role in a consensus round. If the master node device 10a acts maliciously, packaging invalid transactions, or if there are errors in the block structure, the consensus round will not reach consensus on any blocks.

[0089] It should be noted that every k blocks generated on the blockchain, or at regular intervals, a master node device can be randomly selected from the node devices in the blockchain network based on information such as the block height of the blockchain. That is, the selected node devices in the blockchain network can be referred to as master nodes, and the unselected node devices can be referred to as slave nodes. Therefore, any node device in the blockchain network can be selected as a master node device, meaning that any node device in the blockchain network has both master and slave node functions. k can be an integer greater than 1.

[0090] Among them, the slave node device 11a can refer to a role of a consensus node in the blockchain, and its main function is to verify the validity of the block to be verified after receiving the block to be verified proposed by the master node device 10a, and execute the transaction corresponding to the block to be verified. When the block to be verified is found to be invalid, or the execution result of the transaction corresponding to the block to be verified by the slave node device 11a is inconsistent with the execution result of the transaction corresponding to the block to be verified by the master node device 10a, the block to be verified will not be voted on, or will be voted against. When the block to be verified is found to be valid, and the execution result of the transaction corresponding to the block to be verified by the slave node device 11a is consistent with the execution result of the transaction corresponding to the block to be verified by the master node device 10a, the block to be verified will be voted on, that is, a consensus result on the consensus of the block to be verified is generated, and the consensus result is returned to the master node device 10a.

[0091] In one embodiment, the master node device 10a may include a transaction pool 101a, a core engine 102a, and a consensus engine 103a; similarly, the slave node device 11a may include a transaction pool 111a, a core engine 112a, and a consensus engine 113a.

[0092] Among them, the transaction pool (transaction pool 101a and transaction pool 111a) can receive and store transactions sent by other node devices, as well as receive and store transactions sent directly by the client. The transaction pool will broadcast the transactions sent by the client to other node devices. The purpose of broadcasting transactions is to ensure the consistency of transactions between various node devices as much as possible, so that the validity of the blocks and transactions to be verified can be quickly verified in the subsequent consensus process. For example, when the transaction pool 101a receives the transaction tx2 sent by the client, it will store the transaction tx2 in the transaction pool 101a and broadcast the transaction tx2 to the master node device 10a. After the master node device 10a receives the transaction tx2, it will send the transaction tx2 to the transaction pool 111a in the master node device 10a and store the transaction tx2 in the transaction pool 111a.

[0093] The transaction pool can include executable transaction queues and non-executable transaction queues. The non-executable (Queue) transaction queue: caches the queue of pending transactions that have passed the transaction validity check and anti-duplicate check; the executable (Pending) transaction queue: caches the queue of transactions that have been packaged into the block to be verified and are in the consensus process. When the transactions in the executable transaction queue are completed by consensus, the transactions in the executable transaction queue will be deleted, and the transactions in the non-executable queue can be added to the executable transaction queue. Figure 1 As shown, the transaction pool 101a may include a non-executable transaction queue 1011a and an executable queue 1012a; the transaction pool 111a may include a non-executable transaction queue 1111a and an executable queue 1112a. Figure 2 The transaction pool 104a may include a non-executable transaction queue 1041a and an executable queue 1042a; the transaction pool 114a may include a non-executable transaction queue 1141a and an executable queue 1142a.

[0094] Among them, the core engine 102a may include a block proposal module 1021a, a transaction scheduling module 1022a and a block submission module 1023a. The transaction scheduling module 1022a mainly plays the role of central scheduling. The consensus engine 103a of the master node device 10a will notify the core engine 102a to construct a block to be verified. The block proposal module 1021a in the core engine 102a can obtain the transactions to be put on the chain from the transaction pool 101a, execute the transactions to be put on the chain through the transaction scheduling module 1022a, and obtain the execution result 12a; the block proposal module 1021a generates a block to be verified 13a according to the obtained transactions to be put on the chain and the execution result 12a, and sends the block to be verified 13a to the peer network module 1032a, so that the peer network module 1032a can broadcast the block to be verified to the slave node device 11a, and the slave node device 11a performs consensus processing on the block to be verified. The block submission module 1023a can be used to upload the blocks to be verified that have passed the consensus to the blockchain.

[0095] Similarly, the core engine 112a may include a block proposal module 1121a, a transaction scheduling module 1122a, and a block verification module 1123a. The block proposal module 1121a may delete transactions in the non-executable transaction queue 1111a based on the pending block sent by the master node device 10. The transaction scheduling module 1122a may be used to execute pending transactions in the executable transaction queue 1112a to obtain execution results 14a. The block verification module 1123a may verify the pending block 13a based on the execution results 14a and 12a to obtain a verification result.

[0096] Among them, the consensus engine (recognition engine 103a and recognition engine 113a) mainly includes a consensus algorithm module and a peer-to-peer network module. Among them, the consensus algorithm module can include a variety of specific consensus algorithms, including the fault-tolerant type Raft consensus algorithm, and the Byzantine fault-tolerant type PBFT, Tendermint, HotStuff and other consensus algorithms. The consensus algorithm can be used to perform consensus processing on the blocks to be verified based on the verification results obtained by the block verification module. The peer-to-peer network module is responsible for the broadcasting and receiving of the blocks to be verified and voting messages. Figure 1 The consensus engine 103a may include a consensus algorithm module 1031a and a peer-to-peer network module 1032a; the consensus engine 113a may include a consensus algorithm module 1131a and a peer-to-peer network module 1132a.

[0097] It should be noted that node devices in a blockchain network can support multiple transaction pools, which can include general-purpose transaction pools and batch-type transaction pools. At the same time, a node device uses one of the multiple transaction pools to store transactions to be uploaded to the blockchain. The transaction pool can be used to store transactions to be uploaded to the blockchain, their transaction identifiers, and the timestamp of the generation of transactions to be uploaded to the blockchain. Different types of transaction pools correspond to different transaction packaging formats. For example, the transaction packaging format corresponding to a general-purpose transaction pool is used to indicate the packaging of transactions to be uploaded to the blockchain and the execution results of transactions to be uploaded to the blockchain in the transaction pool to obtain a block to be verified. The transaction packaging format corresponding to a batch-type transaction pool is used to indicate the packaging of transaction identifiers, batch identifiers, and the execution results of transactions to be uploaded to the blockchain in the transaction pool to obtain a block to be verified.

[0098] In other words, when the transaction pool is of the universal type, the pending transactions themselves will be synchronized to the slave node devices. This will consume a large amount of network bandwidth during the synchronization of the pending blocks. However, it can avoid the problem of consensus failure caused by the same transaction identifier but different corresponding pending transactions. This synchronization method of the pending blocks is conducive to improving the consensus stability of the pending blocks. For example, the master node device includes pending transactions tx3 and tx4, and the pending transactions tx3 and tx4 have the same transaction identifier. During the synchronization of the pending blocks, only the master node device will synchronize the pending transactions tx3 and tx4 to the slave node devices. In this way, the slave node devices can correctly distinguish between the pending transactions tx3 and tx4, and then correctly reach consensus on the pending transactions tx3 and tx4, thereby improving the consensus stability of the pending blocks. Among them, when the transaction pool is of batch type, only the batch identifier and the transaction identifier of the transaction to be on-chain are synchronized to the slave node device, which can reduce the network bandwidth overhead during the synchronization process of the block to be verified, and the synchronization efficiency of the block to be verified is relatively high.

[0099] As can be seen, general transaction pools are more suitable for the following scenarios: 1. High-quality blockchain network communication; 2. Business scenarios with high stability requirements, such as invoice reimbursement and resource transfer. Batch transaction pools are more suitable for the following scenarios: a. Poor blockchain network communication; b. High-efficiency business scenarios (such as synchronization efficiency of blocks to be verified), such as logistics and gaming applications.

[0100] It should be noted that the current transaction pool in this application may refer to the transaction pool used by the node device in the blockchain network when generating a new block, and the target transaction pool may refer to the transaction pool that matches the transaction attribute information of the transaction to be on the chain in the current transaction pool of the node device when the current transaction pool meets the switching conditions.

[0101] Among them, the transaction attribute information may include the status information of the current transaction pool to which the transactions to be on-chain in the N node devices belong, as well as the business type of the transactions to be on-chain in the current transaction pool; N can be an integer greater than 1, and the N node devices may include N slave node devices, or the N node devices include N slave node devices, or the N slave node devices include a master node device and N-1 slave node devices.

[0102] Among them, the status information of the current trading pool can be used to reflect the trading pool status of the current trading pool, and may include at least one of the transaction identifier of the transactions to be chained in the current trading pool, the number of transactions to be chained in the current trading pool, the type of the current trading pool, etc. When the type of the current trading pool is a batch type, the status information of the current trading pool may also include a batch identifier.

[0103] It should be noted that while the transaction pool types used by various node devices in a blockchain network at the same time are typically the same, due to factors such as poor communication quality or node device failures, some node devices may use different transaction pool types at the same time. For example, when a master node device sends a transaction pool switch transaction to a slave node device, if a node device fails to receive the switch transaction or is unable to execute the switch transaction normally due to a failure in a node device, the slave node device may use a different transaction pool type than the master node device (or other slave node devices). A switch transaction instructs a slave node device to switch its current transaction pool to a target transaction pool that matches the transaction attribute information.

[0104] In one embodiment, each transaction pool may also include a status service module, which is used to obtain transaction attribute information of transactions to be on-chain in the corresponding transaction pool and synchronize the transaction attribute information to other node devices. Figure 2 As shown, the transaction pool 101a of the master node device 10a may include a state service module 1013a, and the transaction pool 104a may include a state service module 1043a. When the master node device 10a uses the transaction pool 101a, the transaction attribute information of the transactions to be put on the chain in the transaction pool 101a can be obtained through the state service module 1013a. When the master node device 10a uses the transaction pool 104a, the transaction attribute information of the transactions to be put on the chain in the transaction pool 104a can be obtained through the state service module 1043a.

[0105] Similarly, the transaction pool 111a of the slave node device 11a may include a state service module 1113a, and the transaction pool 114a may include a state service module 1143a. When the master node device 11a uses the transaction pool 111a, the transaction attribute information of the transactions to be put on the chain in the transaction pool 111a can be obtained through the state service module 1113a. When the master node device 11a uses the transaction pool 114a, the transaction attribute information of the transactions to be put on the chain in the transaction pool 114a can be obtained through the state service module 1143a.

[0106] In one example, the core engine may further include a system contract, which may include a switching contract regarding a transaction pool, and the switching contract is used to switch the current transaction pool. Figure 2 The core engine 102a of the master node device 10a may include a system contract with a switching contract; and the core engine 112a of the slave node device 11a may include a system contract with a switching contract.

[0107] In practical applications, Figure 1 The blockchain data processing system in can be used to implement the blockchain data processing method in this application. First, Figure 2 As shown, when master node device 10a is required to generate a new block, the current transaction pool in master node device 10a is transaction pool 101a, and the current transaction pool in slave node device 11a is 111a. State service module 1013a in transaction pool 101a can obtain transaction attribute information of transactions to be uploaded to the blockchain in transaction pool 101a; state service module 1113a in transaction pool 111a can obtain transaction attribute information of transactions to be uploaded to the blockchain in transaction pool 111a. The slave node device 11a can synchronize the transaction attribute information obtained by the status service module 1113a to the master node device 10a. The master node device 10a can obtain the difference between the received transaction attribute information and the transaction attribute information obtained by the status service module 1013a. Based on the difference, it is verified whether the transaction pool 101a meets the switching condition. For example, when the difference is greater than the difference threshold, the communication quality of the blockchain network is relatively poor, or the performance of the node device (master node device or slave node device) is relatively poor. Therefore, when the transaction pool 101a belongs to the general type, it is determined that the transaction pool 101a meets the switching condition. Alternatively, when the difference is less than or equal to the difference threshold, it indicates that the communication quality of the blockchain network is relatively good, or the performance of the node device is relatively good. Therefore, when the transaction pool 101a belongs to the batch type, it is determined that the transaction pool 101a meets the switching condition.

[0108] Furthermore, when it is detected that transaction pool 101a meets the switching conditions, state service module 1013a can generate a switching transaction for transaction pool 101a. Core engine 102a can package the switching transaction to obtain block 15a to be verified, and send block 15a to be verified to slave node device 11a. Master node device 10a can execute the switching transaction through the switching contract within core engine 102a to switch the transaction pool 101a of master node device 10a to the target transaction pool that matches the transaction attribute information. The target transaction pool in master node device 10a can be transaction pool 104a. After receiving the block 15a to be verified from the node device 11a, the switching transaction is executed through the switching contract in the core engine 112a to switch the transaction pool 111a of the node device 11a to the target transaction pool that matches the transaction attribute information. The target transaction pool in the node device 11a can be the transaction pool 114a. The block 15a to be verified can be processed for consensus based on the consensus engine in the node device 11a. When the consensus of the block 15a to be verified is passed, the node device 11a can upload the block 15a to the blockchain. At the same time, when the master node device 11a receives a consensus message that the consensus of the block 15a to be verified is passed, the master node device 11a can upload the block 15a to the blockchain.

[0109] like Figure 3 As shown, after the master node device 10a switches to the transaction pool 104a, the state service module 1043a can generate a switch completion transaction, which is used to indicate that the switch has been made from the transaction pool 101a to the transaction pool 104a. The switch completion transaction is executed through the switch contract in the core engine 102a, and the switch completion transaction is packaged and processed according to the transaction packaging format of the transaction pool 104a to obtain the block 16a to be verified, and the block 16a to be verified is sent to the slave node device 11a. After the slave node device 11a receives the block 16a to be verified, it executes the switch completion transaction through the switch contract in the core engine 112a, and performs consensus processing on the block 16a to be verified based on the consensus engine in the slave node device 11a. When the consensus of the block 16a to be verified is passed, the slave node device 11a can link the block 16a to the blockchain. At the same time, when the master node device 11a receives the consensus message that the consensus of the block to be verified 16a has passed, the master node device 11a can link the block to be verified 16a to the blockchain.

[0110] After the master node device 10a switches to the transaction pool 104a, the transactions to be put on the chain in the transaction pool 101a can be packaged and processed according to the transaction packaging format corresponding to the transaction pool 104a to obtain the block to be verified, and the block to be verified is sent to the slave node device 11a, which performs consensus processing on the block to be verified. When the consensus of the block to be verified is passed, the slave node device 11a and the master node device 10a can put the block to be verified on the chain to the blockchain. When the master node device 10a receives the transaction to be put on the chain sent by the client (or other slave node device), the transaction to be put on the chain can be stored in the transaction pool 104a. When the slave node device 11a receives the transaction to be put on the chain sent by the client or the master node device (or other slave node device), the transaction to be put on the chain can be stored in the transaction pool 114a.

[0111] It is understandable that the slave node device and the master node device can refer to a server. The server can be an independent physical server, or a server cluster or distributed system composed of at least two physical servers. It can also be 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, Content Delivery Network (CDN), and big data and artificial intelligence platforms. The client can be a blockchain application client deployed in a terminal. The terminal can specifically refer to a car terminal, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a screen speaker, a smart TV, a smart watch, etc., but is not limited to this. Each terminal and the server can be directly or indirectly connected by wired or wireless communication. At the same time, the number of terminals and servers can be one or at least two, and this application does not limit this.

[0112] It can be seen that the present application provides a transaction pool automatic switching mechanism, so that the transaction pool of the node device can perceive the transaction pool status of the peer node device, and perform different processing based on the transaction pool status and network status. That is, based on the network status and the transaction pool status, the transaction pool automatic switching mechanism is implemented, so that the node device can adaptively manage the transaction pool, and adjust the type of the transaction pool according to different situations, so that it can better adapt to different network environments. In the case of network congestion, it can be switched to BatchPool (batch type transaction pool) that consumes less network bandwidth to avoid aggravating network congestion. The transaction pool automatic switching mechanism meets the user's needs to select different transaction pools for different performance scenarios and network status. If the user wants to obtain higher performance, he can manually switch the NormalPool (general type) to BatchPool to obtain higher performance.

[0113] Further, see Figure 4 , is a flowchart of a blockchain data processing method provided by an embodiment of the present application. Figure 4 As shown, this method can be Figure 1 The method may include the following steps:

[0114] S101. Obtain transaction attribute information of a transaction to be on-chain from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network.

[0115] In this application, when a new block needs to be generated, or every U blocks, the transaction attribute information of the transaction to be on the chain is obtained from the current transaction pool of the node device of the above-mentioned blockchain network, and U can be a positive integer greater than 1.

[0116] In one embodiment, when the transaction attribute information includes the business type corresponding to the transaction to be on-chain in the current transaction pool, the master node device can obtain the business type corresponding to the transaction to be on-chain from the current transaction pool of the master node device, or the master node device can receive the business type corresponding to the transaction to be on-chain in the current transaction pool synchronized from the node device.

[0117] In one embodiment, when the transaction attribute information includes the status information of the current transaction pools to which the transactions to be on-chained in N node devices respectively belong, the master node device can obtain the status information corresponding to the current transaction pools in the N slave node devices. In one embodiment, the master node device can obtain the status information of the current transaction pool in the master node device and the status information of the current transaction pools of N-1 slave node devices. In one embodiment, the master node device can obtain the status information corresponding to the current transaction pools of N slave node devices.

[0118] In one embodiment, the transaction attribute information can, to a certain extent, reflect the network status of the blockchain network. For example, when the transaction attribute information includes the status information of the current transaction pools to which the pending transactions on-chain belong on N node devices, if the difference in the status information of the current transaction pools of multiple node devices is small, it indicates that the network status of the blockchain network is normal. If the difference in the status information of the current transaction pools of multiple node devices is large, it indicates that the network status of the blockchain network is abnormal. A normal network status can refer to good communication quality of the blockchain network, good transaction processing performance of the node devices, etc., while an abnormal network status can refer to poor communication quality of the blockchain network, poor transaction processing performance of the node devices, etc.

[0119] In one embodiment, the transaction attribute information may include the business type corresponding to the transaction to be put on the chain in the current transaction pool. The business type may include invoice reimbursement type, asset transfer type, game application type, and logistics application type, etc. That is, the transaction attribute information can be used to reflect the business scenario to which the transaction to be put on the chain belongs.

[0120] S102. When the transaction attribute information indicates that the current transaction pool in the master node device meets the switching conditions, the current transaction pool in the master node device is switched to the target transaction pool that matches the transaction attribute information. The transactions to be on the chain in the current transaction pool of the master node device are packaged and processed according to the transaction packaging format of the target transaction pool to obtain a block to be verified.

[0121] In this application, the master node device can verify whether the current transaction pool in the master node device meets the switching conditions based on the transaction attribute information. When the current transaction pool in the master node device meets the switching conditions, the current transaction pool in the master node device can be switched to a target transaction pool that matches the transaction attribute information. According to the transaction packaging format of the target transaction pool, the transactions to be put on the chain in the current transaction of the master node device are packaged and processed to obtain a block to be verified. Since the transaction attribute information is used to reflect the network status of the blockchain network or reflect the business scenario to which the transaction to be put on the chain belongs, by dynamically switching to the target transaction pool that matches the transaction attribute information, network congestion in the blockchain network can be avoided, the efficiency of transaction on the chain can be improved, and the different performance requirements of the blockchain network can be met.

[0122] In one embodiment, the transaction attribute information includes status information of current transaction pools to which the transactions to be on-chained in N node devices respectively belong; N is an integer greater than 1; when the transaction attribute information indicates that the current transaction pool in the master node device meets a switching condition, switching the current transaction pool in the master node device to a target transaction pool matching the transaction attribute information may include the following steps S11 to S14:

[0123] S11. Determine the difference between the status information of the current transaction pools to which the transactions to be on-chained belong respectively of every two node devices among the N node devices.

[0124] Specifically, the master node device can determine the distance between the status information of the current transaction pools to which the transactions to be put on the chain belong respectively between each two node devices in the above-mentioned N node devices based on the distance algorithm, and determine the difference between the status information of the current transaction pools to which the transactions to be put on the chain belong respectively between each two node devices in the N node devices based on the corresponding distance between each two node devices.

[0125] Distance algorithms may include the Manhattan distance algorithm, the Euclidean distance algorithm, the Chebyshev distance algorithm, and the like. The distance between each pair of node devices is positively correlated with the degree of difference between the current transaction pool status information of each pair of node devices. That is, the greater the distance between each pair of node devices, the greater the degree of difference between the current transaction pool status information of each pair of node devices; conversely, the smaller the distance between each pair of node devices, the smaller the degree of difference between the current transaction pool status information of each pair of node devices.

[0126] S12. Determine the network status of the blockchain network based on the corresponding difference between every two node devices in the N node devices.

[0127] Specifically, the master node device can determine the network status of the blockchain network based on the corresponding difference between each two node devices in the N node devices. The network status of the blockchain network may include a normal state or an abnormal state.

[0128] S13. When the network status indicates that the current transaction pool in the master node device meets the switching condition, determine a target transaction pool that matches the transaction attribute information.

[0129] Specifically, the master node device can determine whether the current transaction pool in the master node device meets the switching conditions based on the network status. When the current transaction pool meets the switching conditions, the master node device can determine the transaction pool that matches the network status and use the transaction pool that matches the network status as the target transaction pool.

[0130] S14. Switch the current transaction pool in the master node device to the target transaction pool.

[0131] Specifically, after determining the target transaction pool, the current transaction pool in the master node device can be switched to the target transaction pool, so as to generate a block to be verified according to the transaction packaging format corresponding to the target transaction pool, and store the newly received transactions to be on the chain in the target transaction pool.

[0132] Optionally, the above step S12 may include the following steps S121 to S123:

[0133] S121 , performing cumulative summation processing on the corresponding difference between every two node devices in the N node devices to obtain a total difference.

[0134] S122. When the total difference is greater than the difference threshold, it is determined that the network state of the blockchain network is abnormal.

[0135] S123. When the total difference is less than or equal to the difference threshold, it is determined that the network status of the blockchain network is normal.

[0136] In steps S121 to S123, when N = 2, the corresponding difference between two node devices can be used as the total difference; when N is greater than 2, the master node device can accumulate and sum the corresponding differences between every two node devices in the N node devices to obtain the total difference. Generally, the status information of the current transaction pool of the node devices in the blockchain network is consistent. That is, when the total difference is greater, it indicates that the communication quality in the blockchain network is relatively poor, or the transaction processing performance of the node devices in the blockchain network is relatively poor; conversely, when the total difference is smaller, it indicates that the communication quality in the blockchain network is relatively good, or the transaction processing performance of the node devices in the blockchain network is relatively good. Therefore, when the above-mentioned total difference is greater than the difference threshold, the network status of the above-mentioned blockchain network is determined to be abnormal. When the above-mentioned total difference is less than or equal to the above-mentioned difference threshold, the network status of the above-mentioned blockchain network is determined to be normal.

[0137] Optionally, the above step S13 may include the following steps S131 to S133:

[0138] S131. Obtain the type of the current transaction pool in the master node device.

[0139] Specifically, the master node device may obtain the type of the current transaction pool in the master node device from the switching contract in the core engine of the master node device. The type of the current transaction pool may include a general type or a batch type.

[0140] S132. When the type of the current transaction pool in the above-mentioned master node device is a general type and the network status of the above-mentioned blockchain network is an abnormal state, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the batch type transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0141] Specifically, when the current transaction pool in the master node device is of a general type and the network status of the blockchain network is normal, although the general transaction pool consumes a large amount of network overhead during the synchronization of the pending block, the network status of the blockchain network is relatively good at this time, indicating that the general transaction pool is suitable for the blockchain network environment. Therefore, the master node device can determine that the current transaction pool in the master node device does not meet the switching conditions and continue to generate a new pending block using the current transaction pool. When the current transaction pool in the master node device is of a general type and the network status of the blockchain network is abnormal, since the general transaction pool consumes a large amount of network overhead during the synchronization of the pending block, and the network status of the blockchain network is relatively poor at this time, indicating that the general transaction pool is not suitable for the blockchain network environment. Therefore, the master node device can determine that the current transaction pool in the master node device meets the switching conditions and select the batch transaction pool as the target transaction pool that matches the transaction attribute information. This can reduce the network bandwidth overhead for synchronizing the pending block and avoid network congestion in the blockchain network.

[0142] S133. When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type and the network status of the above-mentioned blockchain network is normal, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0143] Specifically, when the current transaction pool in the master node device is of the batch type and the network status of the blockchain network is abnormal, although the network status of the blockchain network is relatively poor, the batch-type transaction pool only consumes a small amount of network overhead during the synchronization of the pending block, indicating that the batch-type transaction pool is suitable for the blockchain network environment. Therefore, the master node device can determine that the current transaction pool in the master node device does not meet the switching conditions and continue to generate a new pending block using the current transaction pool. When the current transaction pool in the master node device is of the batch type and the network status of the blockchain network is normal, since the batch-type transaction pool only consumes a small amount of network overhead during the synchronization of the pending block, the network status of the blockchain network is relatively good, indicating that the blockchain network bandwidth is underutilized. Therefore, the node device can determine that the current transaction pool in the master node device meets the switching conditions and select the general-type transaction pool as the target transaction pool that matches the transaction attribute information. This can improve network bandwidth utilization and enhance the synchronization stability of the pending block.

[0144] In one embodiment, the transaction attribute information includes a business type of the to-be-on-chain transaction in the current transaction pool of the master node device; when the transaction attribute information indicates that the current transaction pool in the master node device meets a switching condition, switching the current transaction pool in the master node device to a target transaction pool matching the transaction attribute information may include the following steps S21 to S23:

[0145] S21. Determine the stability of the demand for transactions to be on-chain in the current transaction pool of the master node device based on the business type.

[0146] S22. When the demand stability indicates that the current transaction pool in the master node device meets the switching condition, determine a target transaction pool that matches the transaction attribute information.

[0147] S23. Switch the current transaction pool in the master node device to the target transaction pool.

[0148] In steps S21 to S23, the master node device can determine the demand stability of the transactions to be on-chain in the master node device's current transaction pool based on the correspondence between the business type and the demand stability. The demand stability reflects the stability required for the business scenario corresponding to the transactions to be on-chain; and determine whether the current transaction pool in the master node device meets the switching conditions based on the demand stability. When the current transaction pool in the master node device meets the switching conditions, a transaction pool that matches the demand stability can be determined, and the transaction pool that matches the demand stability is determined as the target transaction pool. This helps the target transaction pool meet the needs of different business scenarios.

[0149] Optionally, the above step S22 may include the following steps S221 to S223:

[0150] S221. Obtain the type of the current transaction pool in the master node device.

[0151] Specifically, the master node device may obtain the type of the current transaction pool in the master node device from the switching contract in the core engine of the master node device. The type of the current transaction pool may include a general type or a batch type.

[0152] S222. When the type of the current transaction pool in the above-mentioned master node device is a general type and the above-mentioned demand stability is less than the stability threshold, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the batch type transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0153] Specifically, when the current transaction pool in the master node device is of a general type and the required stability is greater than or equal to the stability threshold, the general transaction pool can provide higher stability for the business scenario. Furthermore, the business scenario corresponding to the pending transactions in the current transaction pool also has a relatively high stability requirement, indicating that the current transaction pool can meet the stability requirements of the business scenario. Therefore, the master node device can determine that the current transaction pool in the master node device does not meet the switching conditions and continue to generate new blocks to be verified using the current transaction pool. When the current transaction pool in the master node device is of a general type and the required stability is less than the stability threshold, the general transaction pool can provide higher stability for the business scenario. Furthermore, the business scenario corresponding to the pending transactions in the current transaction pool also has a relatively low stability requirement, indicating that the current transaction pool is not suitable for the business scenario corresponding to the pending transactions in the current transaction pool. Therefore, the master node device can determine that the current transaction pool in the master node device meets the switching conditions and select the batch transaction pool as the target transaction pool that matches the transaction attribute information. This helps improve the synchronization efficiency of pending blocks.

[0154] S223. When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type, and the above-mentioned demand stability is greater than or equal to the above-mentioned stability threshold, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type of transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0155] Specifically, when the current transaction pool in the master node device is of the batch type and the required stability is less than the stability threshold, the batch-type transaction pool can provide lower stability for the business scenario. At the same time, the business scenario corresponding to the pending transactions in the current transaction pool also has a relatively low stability requirement, indicating that the current transaction pool can meet the stability requirements of the business scenario. Therefore, the master node device can determine that the current transaction pool in the master node device does not meet the switching conditions and continue to generate new blocks to be verified using the current transaction pool. When the current transaction pool in the master node device is of the batch type and the required stability is greater than or equal to the stability threshold, the batch-type transaction pool can provide lower stability for the business scenario. At the same time, the business scenario corresponding to the pending transactions in the current transaction pool has a relatively high stability requirement, indicating that the current transaction pool cannot meet the stability requirements of the business scenario. Therefore, the master node device can determine that the current transaction pool in the master node device meets the switching conditions and determine the general-type transaction pool as the target transaction pool that matches the transaction attribute information, thereby providing stable business services for the business scenario, meeting the needs of different business scenarios, and improving the flexibility of transaction pool usage.

[0156] In one embodiment, the target transaction pool is a batch type; and the process of packaging the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified may include the following steps S31 to S34:

[0157] S31. Obtain the transaction identifier of the transaction to be on-chain in the current transaction pool of the master node device, and the maximum block height of the block on the blockchain.

[0158] Specifically, the master node device can obtain the transaction identifier of the transaction to be on the chain in the current transaction pool of the master node device from the current transaction pool, and obtain the block height of the latest generated block from the blockchain as the maximum block height. The transaction identifier of the transaction to be on the chain can be generated by the client and used to mark a transaction to be on the chain. The latest generated block can refer to the latest generated block on the blockchain.

[0159] S32. Generate a batch identifier based on the maximum block height and the transactions to be on-chain in the current transaction pool of the master node device.

[0160] Specifically, the master node device can generate a batch identifier based on the maximum block height and the transactions to be put on the chain in the current transaction pool of the master node device. The batch identifier is used to mark a batch of transactions to be put on the chain that are packaged this time. A batch of transactions can refer to all transactions in the executable transaction queue of the current transaction pool of the master node device.

[0161] S33: Execute the transactions to be on-chain in the current transaction pool of the master node device to obtain a first execution result.

[0162] Specifically, the master node device can execute the transactions to be on-chain in the current transaction pool of the master node device to obtain a first execution result. One transaction to be on-chain corresponds to one first execution result.

[0163] S34. Packaging the transaction identifier, the batch identifier, and the first execution result to obtain a block to be verified.

[0164] Specifically, when the type of the target transaction pool is a batch type, the master node device can package and process the above-mentioned transaction identifier, the above-mentioned batch identifier and the above-mentioned first execution result to obtain a block to be verified. In this way, there is no need to synchronize the transactions to be on the chain to the slave node device, which can avoid repeated synchronization of the transactions to be on the chain, reduce the network bandwidth overhead, and avoid network congestion in the blockchain network.

[0165] Among them, the slave node device is also used to execute the to-be-on-chain transactions in the current transaction pool of the above-mentioned slave node device according to the above-mentioned block to be verified, obtain a second execution result, verify the validity of the above-mentioned first execution result according to the above-mentioned second execution results, obtain a first verification result, verify the validity of the above-mentioned block to be verified, obtain a second verification result, and determine the consensus result of the above-mentioned block to be verified according to the above-mentioned first verification result and the above-mentioned second verification result.

[0166] In other words, upon receiving a block to be verified, the slave node device can retrieve the pending transactions in the slave node device's current transaction pool based on the transaction identifier in the pending block, execute the pending transactions in the slave node device's current transaction pool, and obtain a second execution result. The slave node device can obtain the similarity between the first execution result and the second execution result. When the similarity exceeds a similarity threshold, the first execution result is determined to be valid, and a first verification result is generated indicating the validity of the first execution result. The slave node device can package the pending transactions in the slave node device's current transaction pool according to the transaction packaging format corresponding to the batch-type transaction pool, obtaining a first reference block. When the similarity between the first reference block and the block to be verified exceeds the similarity threshold, the block to be verified is determined to be valid, and a second verification result is generated indicating the validity of the block to be verified. When the first verification result indicates the validity of the first execution result, and when the second verification result indicates the validity of the block to be verified, a consensus result is generated indicating that consensus on the block to be verified has passed.

[0167] It should be noted that the first reference block may refer to a block used to verify the block to be verified. The slave node device packages the transactions to be uploaded to the chain in the current transaction pool of the slave node device according to the transaction packaging format corresponding to the batch type transaction pool to obtain the implementation method of the first reference block. You can refer to the above-mentioned master node device, and package the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format corresponding to the batch type transaction pool to obtain the implementation method of the block to be verified. The repetitive parts will not be repeated here.

[0168] It should be noted that after each node device generates a batch identifier, it can sign the batch identifier, package the batch identifier carrying the signature into the block to be verified, and broadcast the block to be verified to other node devices. The node device that receives the block to be verified will also verify the signature in the block to be verified to ensure that the node device does not forge the identity of others to construct a transaction batch (i.e., batch identifier).

[0169] Optionally, the above S32 may include the following steps S321 to S323:

[0170] S321. Select a target node identifier that matches the maximum block height from the node identifiers of the node devices of the blockchain network.

[0171] Specifically, the master node device can select a target node identifier that matches the above-mentioned maximum block height from the node identifiers of the node devices of the blockchain network. The node identifier can refer to the serial number of the node device. The target node identifier can refer to the node identifier of the node devices of the blockchain network, the node identifier with the smallest difference with the maximum block height; or, the target node identifier can refer to the node identifier of the node devices of the blockchain network, the node identifier that has a multiple relationship with the maximum block height, such as the maximum block height can be S times the target node identifier, where S is a positive integer.

[0172] S322. Perform a hash operation on the transactions to be uploaded to the chain in the current transaction pool of the master node device to obtain a hash value.

[0173] Specifically, the master node device can perform a hash operation on the transactions to be put on the chain in the current transaction pool of the master node device according to the Merkle root algorithm, obtain the Merkle root corresponding to the transactions to be put on the chain in the current transaction pool of the master node device, and determine the Merkle root as the hash value corresponding to the transactions to be put on the chain in the current transaction pool of the master node device.

[0174] S323. Generate a batch identifier based on the hash value and the target node identifier.

[0175] Specifically, the master node device can concatenate the hash value and the target node identifier to obtain a batch identifier, such as placing the hash value after the target node identifier to obtain the batch identifier; or placing the hash value before the target node identifier to obtain the batch identifier. For example, the target identifier can be 50, the hash value can be AHXX69, and the batch identifier can be 50AHXX69, or the batch identifier can be AHXX6950. The batch identifier is used to mark all transactions to be uploaded to the chain in this package.

[0176] It should be noted that the first reference block includes the transaction identifier, batch identifier and execution result of the transaction to be on the chain in the current transaction pool of the slave node device. The slave node device will also generate a batch identifier in the process of generating the first reference block. The process of generating the batch identifier in the first reference block from the slave node device can refer to the above steps S321 to S323. This is conducive to ensuring that the batch identifiers generated by each node device in the blockchain network remain unified, thereby improving the consensus accuracy of the block to be verified.

[0177] For example, Figure 5As shown, when the current transaction pool 50a is of the general type and the target transaction pool is of the batch type, the current transaction pool 50a may include transactions to be put on the chain 51a, transactions to be put on the chain 52a, transactions to be put on the chain 53a, and transactions to be put on the chain 54a. When the master node device switches the current transaction pool to the target transaction pool, the transaction identifiers corresponding to the transactions to be put on the chain 51a, transactions to be put on the chain 52a, transactions to be put on the chain 53a, and transactions to be put on the chain 54a can be obtained, as shown in FIG. Figure 5 In the example, transaction 51a to be on-chain corresponds to transaction identifier 51b, transaction 52a to be on-chain corresponds to transaction identifier 52b, transaction 53a to be on-chain corresponds to transaction identifier 53b, and transaction 54a to be on-chain corresponds to transaction identifier 54b. The master node device can obtain the maximum block height corresponding to the block on the blockchain, perform a hash operation on the transactions to be on-chain in the current transaction pool according to the Merkle root algorithm, obtain a hash value, and concatenate the maximum block height and the hash value to obtain batch identifier 55a. The master node device can execute transaction 51a to be on-chain, obtain execution result 51c, execute transaction 52a to be on-chain, obtain execution result 52c, execute transaction 53a to be on-chain, obtain execution result 53c, and execute transaction 54a to be on-chain, obtain execution result 54c. The master node device can package transaction identifiers 51b, 52b, 53b, 54b, batch identifier 55a, execution result 51c, 52c, 53c, and 54c in accordance with the transaction packaging format corresponding to the batch-type transaction pool, thereby obtaining block 56a to be verified. It can be seen that block 56a to be verified only includes the transaction identifiers, execution results, and batch identifiers of the transactions to be uploaded to the blockchain. That is, block 56a to be verified does not include the transactions to be uploaded to the blockchain. This can reduce the network bandwidth overhead of block 56a to be verified during the synchronization process and improve the synchronization efficiency of the blocks to be verified.

[0178] It should be noted that the transaction identifiers of the transactions to be put on the chain can be arranged in the block to be verified in ascending order according to the generation timestamps of the transactions to be put on the chain. A smaller generation timestamp indicates that the generation time of the corresponding transaction to be put on the chain is relatively early; a larger generation timestamp indicates that the generation time of the corresponding transaction to be put on the chain is relatively late.

[0179] In one embodiment, the target transaction pool is of a general type; and the process of packaging the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified may include the following steps S41 to S42:

[0180] S41: Execute the transactions to be on-chain in the current transaction pool of the master node device to obtain a first execution result.

[0181] S42: Packaging the transactions to be on-chain in the current transaction pool of the master node device and the first execution result to obtain a block to be verified.

[0182] In steps S41-S42, when the target transaction pool is a general type, the master node device may execute the pending transactions in the master node device's current transaction pool, obtain a first execution result, and then package the pending transactions in the master node device's current transaction pool and the first execution result according to the transaction packaging format corresponding to the general type transaction pool to obtain a block to be verified. This block to be verified includes the pending transactions, which helps improve the synchronization stability of the block to be verified.

[0183] Among them, the above-mentioned slave node device is also used to execute the to-be-on-chain transactions in the above-mentioned block to be verified, obtain a third execution result, verify the validity of the above-mentioned first execution result based on the above-mentioned third execution result, obtain a third verification result, verify the validity of the above-mentioned block to be verified, obtain a fourth verification result, and determine the consensus result of the above-mentioned block to be verified based on the above-mentioned third verification result and the above-mentioned fourth verification result.

[0184] In other words, after receiving the block to be verified from the node device, the transactions to be put on the chain in the block to be verified can be used to obtain a third execution result, obtain the similarity between the first execution result and the third execution result, and when the similarity is greater than the similarity threshold, determine that the first execution result is valid, and generate a third verification result indicating that the first execution result is valid. The slave node device can package the transactions to be put on the chain in the current transaction pool of the slave node device according to the transaction packaging format corresponding to the general type of transaction pool to obtain a second reference block. When the similarity between the second reference block and the block to be verified is greater than the similarity threshold, determine that the block to be verified is valid, and generate a fourth verification result indicating that the block to be verified is valid. When the third verification result indicates that the first execution result is valid, and when the fourth verification result indicates that the block to be verified is valid, a consensus result indicating that the consensus of the block to be verified has been passed is generated.

[0185] It should be noted that the second reference block may refer to a block used to verify the block to be verified. The slave node device packages the transactions to be uploaded to the chain in the current transaction pool of the slave node device according to the transaction packaging format corresponding to the general type of transaction pool to obtain the implementation method of the second reference block. You can refer to the above-mentioned master node device, and package the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format corresponding to the general type of transaction pool to obtain the implementation method of the block to be verified. The repetitive parts will not be repeated here.

[0186] For example, Figure 6As shown, when the current transaction pool is of the batch type and the target transaction pool is of the general type, the current transaction pool may include transactions to be on-chain 61b, transactions to be on-chain 62b, transactions to be on-chain 63b, and transactions to be on-chain 64b; transactions to be on-chain 61b corresponds to transaction identifier 62a, transactions to be on-chain 62b corresponds to transaction identifier 63a, transactions to be on-chain 63b corresponds to transaction identifier 64a, and transactions to be on-chain 64b corresponds to transaction identifier 65a. When the master node device does not switch the current transaction pool to the target transaction pool, the master node device may generate a block to be verified 61a, which may include a batch identifier, as well as transaction identifiers 62a, 63a, 64a, and 65a. The block to be verified 61a may also include the execution results of each transaction to be on-chain. When the master node device switches the current transaction pool to the target transaction pool, the master node device can package the pending transactions in the master node device's current transaction pool based on the transaction packaging format corresponding to the general type of transaction pool, and obtain a pending block 66a. Still taking the current transaction pool as an example, which may include pending transactions 61b, 62b, 63b, and 64b, the master node device can execute pending transaction 61b and obtain an execution result 61c, execute pending transaction 62b and obtain an execution result 62c, execute pending transaction 63b and obtain an execution result 63c, and execute pending transaction 64b and obtain an execution result 64c. Based on the transaction packaging format corresponding to the general type of transaction pool, pending transaction 61b, execution result 61c, pending transaction 62b, execution result 62c, pending transaction 63b, execution result 63c, pending transaction 64b, execution result 64c, and the block height are packaged to obtain a pending block 66a. The block hash here may refer to the aforementioned hash value. It can be seen that the block to be verified 66a includes transactions to be put on the chain, which can improve the synchronization stability of the block to be verified and is suitable for scenarios where the network status of the blockchain network is relatively good.

[0187] S103. Generate a switch transaction, send the block to be verified and the switch transaction to the slave node device, and the slave node device is used to switch the current transaction pool in the slave node device to the target transaction pool according to the switch transaction, perform consensus processing on the block to be verified, and obtain a consensus result.

[0188] In this application, the master node device can generate a switch transaction and send the block to be verified and the switch transaction to the slave node device. After receiving the block to be verified, the slave node device can verify the authenticity and validity of the switch transaction. When the switch transaction verification is passed, the switch transaction is executed to switch the current transaction pool of the slave node device to the target transaction pool, and the block to be verified is processed by consensus to obtain a consensus result. The consensus result indicates that the consensus of the block to be verified has passed, or the consensus result indicates that the consensus of the block to be verified has not passed. The consensus passing is used to indicate that the block to be verified is accurate; the consensus failing is used to indicate that the block to be verified is incorrect, such as the block high area, block hash value, transaction execution result, etc.

[0189] Here, consensus approval can mean that all corresponding transactions in the block to be verified have passed consensus, while consensus failure can mean that there are transactions in the block to be verified that have failed consensus. Alternatively, consensus approval can mean that some transactions in the block to be verified have passed consensus, while consensus failure can mean that most transactions (such as 50% of the transactions) or all transactions in the block to be verified have failed consensus.

[0190] S104. Receive the consensus result sent by the slave node device. When the consensus result indicates that the block to be verified has passed the consensus, the block to be verified is linked to the blockchain corresponding to the blockchain network according to the consensus result.

[0191] In this application, the master node device can receive the consensus result sent by the slave node device. When the consensus result indicates that the consensus of the block to be verified has passed, the block to be verified can be chained to the blockchain according to the consensus result.

[0192] It should be noted that when the consensus result indicates that the block to be verified has passed the consensus, the slave node device can also upload the block to be verified to the blockchain based on the consensus result.

[0193] Optionally, the target transaction pool is of a general type, and the process of uploading the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result may include the following steps S51 to S53:

[0194] S51. Based on the consensus result, remove the pending transactions that failed to pass the consensus and the execution results of the pending transactions that failed to pass the consensus from the pending block to obtain a first verified block.

[0195] S52: Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0196] S53. Uplink the first verified block to the blockchain corresponding to the blockchain network.

[0197] In steps S51 to S53, the target transaction pool is of a general type, and the consensus result indicates the transactions to be put on the chain that have passed the consensus, and the transactions to be put on the chain that have not passed the consensus. The master node device can remove the transactions to be put on the chain that have not passed the consensus and the execution results of the transactions to be put on the chain that have not passed the consensus from the above-mentioned block to be verified according to the consensus result, and obtain the first verified block, that is, the first verified block only includes the transactions to be put on the chain that have passed the consensus, and the execution results of the transactions to be put on the chain that have passed the consensus. Delete all the transactions to be put on the chain in the above-mentioned current transaction pool, and store the transactions to be put on the chain that have not passed the consensus in the above-mentioned target transaction pool to wait for the next packaging. The master node device can put the above-mentioned first verified block on the chain to the blockchain corresponding to the above-mentioned blockchain network. The slave node device will also refer to the above steps to obtain the first verified block and store the first verified block to the blockchain to ensure that the blockchain stored by each node device is consistent.

[0198] Optionally, the target transaction pool is of batch type, and uploading the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result may include the following steps S61 to S64:

[0199] S61. Based on the consensus result, remove the transaction identifiers and execution results corresponding to the pending transactions that failed to pass the consensus in the on-chain block to obtain an updated block.

[0200] S62. Obtain the transaction to be uploaded corresponding to the transaction identifier in the update block from the current transaction pool of the master node device, and add the acquired transaction to be uploaded to the update block to obtain a second verified block.

[0201] S63. Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0202] S64. Uplink the second verified block to the blockchain corresponding to the blockchain network.

[0203] In steps S61 to S64, when the type of the target transaction pool is a batch type, the master node device can remove the transaction identifiers and execution results corresponding to the transactions to be chained that have not passed the consensus in the above-mentioned on-chain block according to the above-mentioned consensus result to obtain an updated block. The master node device can obtain the transactions to be chained corresponding to the transaction identifiers in the above-mentioned update block from the current transaction pool of the above-mentioned master node device, and add the obtained transactions to be chained to the above-mentioned update block to obtain a second verified block. The master node device can delete all the transactions to be chained in the above-mentioned current transaction pool, store the transactions to be chained that have not passed the above-mentioned consensus in the above-mentioned target transaction pool, and wait for the next packaging; and store the above-mentioned second verified block on the blockchain corresponding to the above-mentioned blockchain network. The slave node device will also refer to the above steps to obtain the second verified block, and store the second verified block in the blockchain to ensure the consistency of the blockchain stored by each node device.

[0204] In one embodiment, the node device can implement a transaction pool switching mechanism by configuring transactions. Under this mechanism, the processing flow is basically the same as the adaptive transaction pool switching mechanism, except that the switching transaction of the transaction pool (i.e., the current transaction pool) is not automatically generated and triggered by the transaction pool, but is initiated by the user client. After receiving the switching transaction sent by the client, it will be processed according to the above process to realize the switching of the transaction pool.

[0205] In this application, the blockchain network supports multiple types of transaction pools (such as the current transaction pool and the target transaction pool). When the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device can be used to: reflect the network status of the blockchain network, or reflect the business scenario to which the to-be-on-chain transaction belongs. Therefore, by dynamically switching the adapted transaction pool based on the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device, and packaging and processing the to-be-on-chain transaction according to the transaction packaging format corresponding to the switched transaction pool (i.e., the target transaction pool), the blockchain network can avoid network congestion, improve the efficiency of transaction on-chain, and meet the different performance requirements of the block network.

[0206] Further, see Figure 7 , is a flowchart of a blockchain data processing method provided by an embodiment of the present application. Figure 7 As shown, this method can be Figure 1 The method may include the following steps:

[0207] S201. Receive the block to be verified and the switching transaction sent by the master node device in the above-mentioned blockchain network; the above-mentioned block to be verified is obtained by packaging and processing the transactions to be on-chain in the current transaction pool of the above-mentioned master node device according to the transaction packaging format of the above-mentioned target transaction pool when the transaction attribute information indicates that the current transaction pool in the above-mentioned master node device meets the switching condition and the current transaction pool in the above-mentioned master node device is switched to the target transaction pool matching the above-mentioned transaction attribute information, and the above-mentioned transaction attribute information belongs to the transactions to be on-chain in the current transaction pool of the node device of the above-mentioned blockchain network; the above-mentioned node device includes the above-mentioned master node device and at least one of the slave node devices in the above-mentioned blockchain network.

[0208] In the present application, the slave node device may receive the block to be verified and the switching transaction sent by the master node device, where the switching transaction is used to indicate that the current transaction pool is switched to the target transaction pool.

[0209] S202. According to the switching transaction, the current transaction pool in the slave node device is switched to a target transaction pool that matches the transaction attribute information.

[0210] In this application, the slave node device can switch the current transaction pool in the above-mentioned slave node device to a target transaction pool that matches the above-mentioned transaction attribute information based on the switching transaction, so as to subsequently store the newly received transactions to be uploaded to the target transaction pool, and package and process the transactions to be uploaded to the chain based on the corresponding transaction packaging format of the target transaction pool.

[0211] S203. Perform consensus processing on the block to be verified, obtain a consensus result, and send the consensus result to the master node device; when the consensus result indicates that the block to be verified has passed the consensus, the master node device is configured to link the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result.

[0212] In this application, the slave node device can perform consensus processing on the block to be verified, obtain a consensus result, and send the consensus result to the master node device. When the consensus result indicates that the consensus of the block to be verified has passed, the slave node device and the master node device can store the block to be verified on the blockchain corresponding to the blockchain network according to the consensus result.

[0213] It should be noted that the consensus processing process of the slave node device on the block to be verified can refer to the implementation process described above, and the repeated parts will not be repeated.

[0214] In this application, sending a switching transaction from the master node device to the slave node device is beneficial for the slave node device to dynamically switch the adapted transaction pool based on the transaction attribute information of the transaction to be on-chain in the current transaction pool of the node device. This can avoid network congestion in the blockchain network, improve the efficiency of transaction on-chain, meet the different performance requirements of the block network, and keep the transaction pools of the slave node device and the master node device consistent.

[0215] See Figure 8 , is a structural diagram of a blockchain data processing device provided by an embodiment of the present application. Figure 8 As shown, the blockchain data processing device may include:

[0216] An acquisition module 811 is configured to acquire transaction attribute information of a transaction to be uploaded from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0217] The switching module 812 is configured to, when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition, switch the current transaction pool in the master node device to a target transaction pool that matches the transaction attribute information, and package the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified;

[0218] The sending module 813 is configured to generate a switch transaction, and send the block to be verified and the switch transaction to the slave node device. The slave node device is configured to switch the current transaction pool in the slave node device to the target transaction pool according to the switch transaction, and perform consensus processing on the block to be verified to obtain a consensus result.

[0219] The on-chain module 814 is used to receive the consensus result sent by the above-mentioned slave node device. When the above-mentioned consensus result indicates that the consensus of the above-mentioned block to be verified is passed, the above-mentioned block to be verified is chained to the blockchain corresponding to the blockchain network according to the above-mentioned consensus result.

[0220] Optionally, the transaction attribute information includes status information of the current transaction pools to which the transactions to be on-chained in the N node devices belong respectively; N is an integer greater than 1;

[0221] Optionally, the switching module 812 is specifically configured to:

[0222] Determine the difference between the status information of the current transaction pools to which the to-be-onlined transactions of each two node devices in the N node devices belong;

[0223] Determine the network status of the blockchain network based on the corresponding difference between every two node devices in the N node devices;

[0224] When the network status indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information;

[0225] Switch the current transaction pool in the master node device to the target transaction pool.

[0226] Optionally, the switching module 812 is specifically configured to:

[0227] Performing cumulative summation of the differences between every two node devices in the N node devices to obtain a total difference;

[0228] When the total difference is greater than the difference threshold, the network state of the blockchain network is determined to be abnormal.

[0229] When the total difference is less than or equal to the difference threshold, it is determined that the network status of the blockchain network is normal.

[0230] Optionally, the switching module 812 is specifically configured to:

[0231] Get the type of the current transaction pool in the above master node device;

[0232] When the current transaction pool in the master node device is of a general type and the network status of the blockchain network is abnormal, determining that the current transaction pool in the master node device meets the switching condition, and determining the batch type transaction pool as the target transaction pool that matches the transaction attribute information;

[0233] When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type, and the network status of the above-mentioned blockchain network is normal, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type of transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0234] Optionally, the transaction attribute information includes the business type of the to-be-online transaction in the current transaction pool of the master node device;

[0235] Optionally, the switching module 812 is specifically configured to:

[0236] Determine the stability of the demand for transactions to be on-chain in the current transaction pool of the master node device based on the above business type;

[0237] When the demand stability indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information;

[0238] Switch the current transaction pool in the master node device to the target transaction pool.

[0239] Optionally, the switching module 812 is specifically configured to:

[0240] Get the type of the current transaction pool in the above master node device;

[0241] When the current transaction pool in the master node device is of a general type and the demand stability is less than a stability threshold, it is determined that the current transaction pool in the master node device meets the switching condition, and a batch transaction pool is determined as a target transaction pool that matches the transaction attribute information;

[0242] When the type of the current transaction pool in the above-mentioned master node device is the above-mentioned batch type, and the above-mentioned demand stability is greater than or equal to the above-mentioned stability threshold, it is determined that the current transaction pool in the above-mentioned master node device meets the switching conditions, and the above-mentioned general type of transaction pool is determined as the target transaction pool that matches the above-mentioned transaction attribute information.

[0243] Optionally, the target transaction pool type is batch type;

[0244] Optionally, the switching module 812 is specifically configured to:

[0245] Obtain the transaction identifier of the transaction to be uploaded to the blockchain in the current transaction pool of the master node device, as well as the maximum block height of the block on the blockchain;

[0246] Generate a batch identifier based on the maximum block height and the pending transactions in the masternode device's current transaction pool;

[0247] Execute the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result;

[0248] Packaging the transaction identifier, the batch identifier, and the first execution result to obtain a block to be verified;

[0249] Among them, the above-mentioned slave node device is also used to execute the to-be-on-chain transactions in the current transaction pool of the above-mentioned slave node device according to the above-mentioned block to be verified, obtain a second execution result, verify the validity of the above-mentioned first execution result according to the above-mentioned second execution results, obtain a first verification result, verify the validity of the above-mentioned block to be verified, obtain a second verification result, and determine the consensus result of the above-mentioned block to be verified according to the above-mentioned first verification result and the above-mentioned second verification result.

[0250] Optionally, the switching module 812 is specifically configured to:

[0251] Selecting a target node identifier that matches the maximum block height from the node identifiers of the node devices of the blockchain network;

[0252] Perform hash operations on the transactions to be uploaded to the blockchain in the current transaction pool of the master node device to obtain a hash value;

[0253] Generate a batch ID based on the hash value and the target node ID.

[0254] Optionally, the target transaction pool type is a general type;

[0255] Optionally, the switching module 812 is specifically configured to:

[0256] Execute the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result;

[0257] The transactions to be on-chain in the current transaction pool of the master node device and the first execution result are packaged to obtain a block to be verified;

[0258] Among them, the above-mentioned slave node device is also used to execute the to-be-on-chain transactions in the above-mentioned block to be verified, obtain a third execution result, verify the validity of the above-mentioned first execution result based on the above-mentioned third execution result, obtain a third verification result, verify the validity of the above-mentioned block to be verified, obtain a fourth verification result, and determine the consensus result of the above-mentioned block to be verified based on the above-mentioned third verification result and the above-mentioned fourth verification result.

[0259] Optionally, the uplink module 814 is specifically configured to:

[0260] Based on the consensus result, remove the pending transactions that did not pass the consensus and the execution results of the pending transactions that did not pass the consensus from the block to be verified to obtain the first verified block;

[0261] Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0262] The first verified block is uploaded to the blockchain corresponding to the blockchain network.

[0263] Optionally, the uplink module 814 is specifically configured to:

[0264] Based on the consensus result, remove the transaction identifiers and execution results corresponding to the pending transactions that failed to pass the consensus in the on-chain block to obtain an updated block;

[0265] Obtaining the to-be-online transaction corresponding to the transaction identifier in the update block from the current transaction pool of the master node device, and adding the obtained to-be-online transaction to the update block to obtain a second verified block;

[0266] Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool.

[0267] The second verified block is uploaded to the blockchain corresponding to the blockchain network.

[0268] In this application, the blockchain network supports multiple types of transaction pools (such as the current transaction pool and the target transaction pool). When the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device can be used to: reflect the network status of the blockchain network, or reflect the business scenario to which the to-be-on-chain transaction belongs. Therefore, by dynamically switching the adapted transaction pool based on the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device, and packaging and processing the to-be-on-chain transaction according to the transaction packaging format corresponding to the switched transaction pool (i.e., the target transaction pool), the blockchain network can avoid network congestion, improve the efficiency of transaction on-chain, and meet the different performance requirements of the block network.

[0269] See Figure 9 , is a structural diagram of a blockchain data processing device provided by an embodiment of the present application. Figure 9 As shown, the blockchain data processing device may include:

[0270] Receiving module 911 is configured to receive a block to be verified and a switching transaction sent by a master node device in the blockchain network; the block to be verified is obtained by packaging transactions to be on-chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition and the current transaction pool in the master node device is switched to a target transaction pool that matches the transaction attribute information; the transaction attribute information belongs to transactions to be on-chain in the current transaction pool of a node device in the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network;

[0271] A switching module 912 is configured to switch the current transaction pool in the slave node device to a target transaction pool matching the transaction attribute information according to the switching transaction;

[0272] The sending module 913 is used to perform consensus processing on the above-mentioned block to be verified, obtain a consensus result, and send the above-mentioned consensus result to the above-mentioned master node device; the above-mentioned master node device is used to, when the above-mentioned consensus result indicates that the consensus of the above-mentioned block to be verified has passed, link the above-mentioned block to the blockchain corresponding to the blockchain network according to the above-mentioned consensus result.

[0273] In this application, sending a switching transaction from the master node device to the slave node device is beneficial for the slave node device to dynamically switch the adapted transaction pool based on the transaction attribute information of the transaction to be on-chain in the current transaction pool of the node device. This can avoid network congestion in the blockchain network, improve the efficiency of transaction on-chain, meet the different performance requirements of the block network, and keep the transaction pools of the slave node device and the master node device consistent.

[0274] See Figure 10 , is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 10 As shown, the above-mentioned computer device 1000 may refer to a terminal or a server, including: a processor 1001, a network interface 1004 and a memory 1005. In addition, the above-mentioned computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between these components. In some embodiments, the user interface 1003 may include a display screen (DiSPlay), a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatileMeMory), such as at least one disk storage. The memory 1005 may optionally also be at least one storage device away from the aforementioned processor 1001. As Figure 10 As shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a computer program.

[0275] exist Figure 10 In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface; and the processor 1001 can be used to call the computer program stored in the memory 1005 to implement the steps in the various method embodiments of the present application.

[0276] In this application, the blockchain network supports multiple types of transaction pools (such as the current transaction pool and the target transaction pool). When the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device can be used to: reflect the network status of the blockchain network, or reflect the business scenario to which the to-be-on-chain transaction belongs. Therefore, by dynamically switching the adapted transaction pool based on the transaction attribute information of the to-be-on-chain transaction in the current transaction pool of the node device, and packaging and processing the to-be-on-chain transaction according to the transaction packaging format corresponding to the switched transaction pool (i.e., the target transaction pool), the blockchain network can avoid network congestion, improve the efficiency of transaction on-chain, and meet the different performance requirements of the block network.

[0277] It should be understood that the computer device described in the embodiments of this application can execute the description of the blockchain data processing method described in the corresponding embodiments above, and can also execute the description of the blockchain data processing device described in the corresponding embodiments above, and will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0278] The collection and processing of the relevant data in this application should be strictly in accordance with the requirements of relevant national laws and regulations when applied in practice, and the informed consent or separate consent of the personal information subject should be obtained. Subsequent data use and processing should be carried out within the scope of authorization of laws and regulations and the personal information subject.

[0279] In addition, it should be noted that the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the aforementioned blockchain data processing device, and the computer program includes program instructions. When the processor executes the program instructions, it can perform the description of the blockchain data processing method in the corresponding embodiment above. Therefore, it will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0280] As an example, the above program instructions may be deployed on a computer device for execution, or deployed on at least two computer devices at one location for execution, or executed on at least two computer devices distributed at at least two locations and interconnected via a communication network. The at least two computer devices distributed at at least two locations and interconnected via a communication network may constitute a blockchain network.

[0281] The computer-readable storage medium can be the blockchain data processing device provided in any of the aforementioned embodiments or the central storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can 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 (SD) card, a flash memory card, etc. equipped with the computer device. Furthermore, the computer-readable storage medium can also include both the central 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 can also be used to temporarily store data that has been output or is about to be output.

[0282] The terms "first," "second," and the like in the description, claims, and drawings of the embodiments of the present application are used to distinguish between contents in different media, rather than to describe a specific order. In addition, the terms "including" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules that are not listed, or may optionally include other steps and units inherent to these processes, methods, apparatuses, products, or devices.

[0283] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0284] The collection and processing of the relevant data in this application should be strictly in accordance with the requirements of relevant national laws and regulations when applied in practice, and the informed consent or separate consent of the personal information subject should be obtained. Subsequent data use and processing should be carried out within the scope of authorization of laws and regulations and the personal information subject.

[0285] The present application also provides a computer program product, including a computer program. When executed by a processor, the computer program implements the blockchain data processing method and decoding method described in the corresponding embodiments above. Therefore, they will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the embodiments of the computer program product involved in this application, please refer to the description of the method embodiments of this application.

[0286] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0287] The methods and related devices provided by the embodiments of the present application are described with reference to the method flow charts and / or structural diagrams provided by the embodiments of the present application. Specifically, each process and / or block in the method flow charts and / or structural diagrams, as well as the combination of processes and / or blocks in the flow charts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable network-connected device to generate a machine, so that the instructions executed by the processor of the computer or other programmable network-connected device generate instructions for implementing the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable network-connected device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the function specified in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be loaded onto a computer or other programmable network connected device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide the functions for implementing the process. Figure 1 The flow or flows and / or structures illustrate the steps of the functions specified in one block or multiple blocks.

[0288] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A blockchain data processing method, characterized in that: Masternode devices used in blockchain networks include: Obtaining transaction attribute information of a transaction to be on-chain from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network; When the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition, the current transaction pool in the master node device is switched to a target transaction pool that matches the transaction attribute information, and the transactions to be on-chain in the current transaction pool of the master node device are packaged according to the transaction packaging format of the target transaction pool to obtain a block to be verified; Generate a switch transaction, send the block to be verified and the switch transaction to the slave node device, and the slave node device is used to switch the current transaction pool in the slave node device to the target transaction pool according to the switch transaction, perform consensus processing on the block to be verified, and obtain a consensus result; Receive the consensus result sent by the slave node device, and when the consensus result indicates that the consensus of the block to be verified is passed, link the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result.

2. The method according to claim 1, wherein The transaction attribute information includes the status information of the current transaction pool to which the transactions to be on-chain in the N node devices belong respectively; N is an integer greater than 1; When the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition, switching the current transaction pool in the master node device to a target transaction pool matching the transaction attribute information includes: Determine the difference between the status information of the current transaction pools to which the to-be-online transactions of each two node devices of the N node devices belong; Determining a network state of the blockchain network based on a corresponding difference between every two node devices in the N node devices; When the network status indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information; Switch the current transaction pool in the master node device to the target transaction pool.

3. The method according to claim 2, wherein Determining the network state of the blockchain network according to the corresponding difference between every two node devices in the N node devices includes: Performing cumulative summation processing on the difference between every two node devices in the N node devices to obtain a total difference; When the total difference is greater than the difference threshold, determining that the network state of the blockchain network is an abnormal state; When the total difference is less than or equal to the difference threshold, it is determined that the network state of the blockchain network is normal.

4. The method according to claim 2, wherein When the network status indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information includes: Obtain the type of the current transaction pool in the master node device; When the type of the current transaction pool in the master node device is a general type and the network status of the blockchain network is an abnormal state, determining that the current transaction pool in the master node device meets the switching condition, and determining a batch type transaction pool as a target transaction pool that matches the transaction attribute information; When the type of the current transaction pool in the master node device is the batch type and the network status of the blockchain network is normal, it is determined that the current transaction pool in the master node device meets the switching conditions, and the general type of transaction pool is determined as the target transaction pool that matches the transaction attribute information.

5. The method according to claim 1, wherein The transaction attribute information includes the business type of the to-be-online transaction in the current transaction pool of the master node device; When the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition, switching the current transaction pool in the master node device to a target transaction pool matching the transaction attribute information includes: Determine, based on the business type, the stability of demand for transactions to be on-chain in the current transaction pool of the master node device; When the demand stability indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information; Switch the current transaction pool in the master node device to the target transaction pool.

6. The method according to claim 5, wherein When the demand stability indicates that the current transaction pool in the master node device meets the switching condition, determining a target transaction pool that matches the transaction attribute information includes: Obtain the type of the current transaction pool in the master node device; When the type of the current transaction pool in the master node device is a general type and the demand stability is less than the stability threshold, determining that the current transaction pool in the master node device meets the switching condition, and determining a batch type transaction pool as a target transaction pool that matches the transaction attribute information; When the type of the current transaction pool in the master node device is the batch type and the demand stability is greater than or equal to the stability threshold, it is determined that the current transaction pool in the master node device meets the switching condition, and the general type of transaction pool is determined as the target transaction pool that matches the transaction attribute information.

7. The method according to claim 1, wherein The type of the target transaction pool is batch type; The process of packaging the transactions to be uploaded to the blockchain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified includes: Obtaining the transaction identifier of the transaction to be on-chain in the current transaction pool of the master node device and the maximum block height of the block on the blockchain; Generate a batch identifier based on the maximum block height and the pending on-chain transactions in the current transaction pool of the master node device; Executing the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result; Packaging the transaction identifier, the batch identifier, and the first execution result to obtain a block to be verified; The slave node device is further configured to execute, based on the block to be verified, the to-be-on-chain transactions in the current transaction pool of the slave node device, to obtain a second execution result, verify the validity of the first execution result based on the second execution result, to obtain a first verification result, verify the validity of the block to be verified, to obtain a second verification result, and determine the consensus result of the block to be verified based on the first verification result and the second verification result.

8. The method according to claim 7, wherein The generating of a batch identifier according to the maximum block height and the transactions to be on-chain in the current transaction pool of the master node device includes: Selecting a target node identifier that matches the maximum block height from the node identifiers of the node devices of the blockchain network; Performing a hash operation on the transactions to be uploaded to the blockchain in the current transaction pool of the master node device to obtain a hash value; A batch identifier is generated according to the hash value and the target node identifier.

9. The method according to claim 1, wherein The type of the target transaction pool is a general type; The process of packaging the transactions to be uploaded to the blockchain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified includes: Executing the pending on-chain transactions in the current transaction pool of the master node device to obtain a first execution result; Packaging the transactions to be on-chain in the current transaction pool of the master node device and the first execution result to obtain a block to be verified; Among them, the slave node device is also used to execute the to-be-on-chain transactions in the block to be verified, obtain a third execution result, verify the validity of the first execution result according to the third execution result, obtain a third verification result, verify the validity of the block to be verified, obtain a fourth verification result, and determine the consensus result of the block to be verified according to the third verification result and the fourth verification result.

10. The method according to claim 1, wherein The target transaction pool is of a general type. The process of uploading the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result includes: According to the consensus result, the transactions to be put on the chain that did not pass the consensus and the execution results of the transactions to be put on the chain that did not pass the consensus are removed from the block to be verified to obtain a first verified block; Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool; The first verified block is uploaded to the blockchain corresponding to the blockchain network.

11. The method according to claim 1, wherein The target transaction pool is a batch type, and the block to be verified is uploaded to the blockchain corresponding to the blockchain network according to the consensus result, including: According to the consensus result, the transaction identifiers and execution results corresponding to the pending transactions that failed to pass the consensus in the on-chain block are removed to obtain an updated block; Obtaining, from the current transaction pool of the master node device, the to-be-online transaction corresponding to the transaction identifier in the update block, and adding the obtained to-be-online transaction to the update block to obtain a second verified block; Delete all pending transactions in the current transaction pool, and store pending transactions that have not passed the consensus in the target transaction pool; The second verified block is uploaded to the blockchain corresponding to the blockchain network.

12. A blockchain data processing method, characterized in that: Slave node devices used in blockchain networks include: Receiving a block to be verified and a switching transaction sent by a master node device in the blockchain network; the block to be verified is obtained by packaging and processing the transactions to be on-chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition and the current transaction pool in the master node device is switched to a target transaction pool matching the transaction attribute information, and the transaction attribute information belongs to the transactions to be on-chain in the current transaction pool of the node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network; According to the switching transaction, the current transaction pool in the slave node device is switched to a target transaction pool that matches the transaction attribute information; A consensus process is performed on the block to be verified to obtain a consensus result, and the consensus result is sent to the master node device; the master node device is used to, when the consensus result indicates that the consensus of the block to be verified has passed, link the block to the blockchain corresponding to the blockchain network according to the consensus result.

13. A blockchain data processing device, characterized in that: Masternode devices used in blockchain networks include: An acquisition module, configured to acquire transaction attribute information of a transaction to be on-chain from a current transaction pool of a node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network; a switching module configured to, when the transaction attribute information indicates that the current transaction pool in the master node device satisfies a switching condition, switch the current transaction pool in the master node device to a target transaction pool that matches the transaction attribute information, and package the transactions to be uploaded to the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool to obtain a block to be verified; a sending module, configured to generate a switching transaction, and send the block to be verified and the switching transaction to the slave node device; the slave node device is configured to switch the current transaction pool in the slave node device to the target transaction pool according to the switching transaction, and perform consensus processing on the block to be verified to obtain a consensus result; The on-chain module is used to receive the consensus result sent by the slave node device. When the consensus result indicates that the consensus of the block to be verified is passed, the block to be verified is chained to the blockchain corresponding to the blockchain network according to the consensus result.

14. A blockchain data processing device, characterized in that: Slave node devices used in blockchain networks include: A receiving module, configured to receive a block to be verified and a switching transaction sent by a master node device in the blockchain network; the block to be verified is obtained by packaging and processing the transactions to be put on the chain in the current transaction pool of the master node device according to the transaction packaging format of the target transaction pool when the transaction attribute information indicates that the current transaction pool in the master node device meets the switching condition and the current transaction pool in the master node device is switched to a target transaction pool matching the transaction attribute information, and the transaction attribute information belongs to the transactions to be put on the chain in the current transaction pool of the node device of the blockchain network; the node device includes the master node device and at least one of the slave node devices in the blockchain network; a switching module, configured to switch the current transaction pool in the slave node device to a target transaction pool matching the transaction attribute information according to the switching transaction; The sending module is used to perform consensus processing on the block to be verified, obtain a consensus result, and send the consensus result to the master node device; when the consensus result indicates that the consensus of the block to be verified is passed, the master node device is used to link the block to be verified to the blockchain corresponding to the blockchain network according to the consensus result.

15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 12 are implemented.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images