Blockchain network-based data processing method, device, equipment and readable storage medium

Abstract

The application discloses a data processing method and device based on a blockchain network, equipment and a readable storage medium. The method comprises the following steps: a target node acquires transaction data from a target subnetwork, and constructs a first subblock based on the transaction data; the transaction data in the first subblock is subjected to consensus processing in the target subnetwork, and the first subblock is broadcast to the blockchain network when the consensus of the first subblock is passed; a second subblock broadcast by other block proposal nodes is acquired; the first subblock and the second subblock are merged based on a block merging rule to obtain a merged block, the merged block is executed to obtain a first transaction execution result, and the merged block is subjected to consensus processing in the blockchain network according to the first transaction execution result. By using the application, the fairness of transaction data being packed into a block can be ensured, and the execution success rate of transaction data can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, device, and readable storage medium based on a blockchain network. Background Technology

[0002] Block proposal nodes can construct blocks based on transaction data, execute these blocks to obtain execution results, and then conduct consensus processing on the blocks within the blockchain network based on the execution results. Specifically, block proposal nodes can decide whether to include transaction data in a block. When a block proposal node refuses to include transaction data in a block, it reduces the fairness of transaction data inclusion and causes transaction parties to miss transaction opportunities, potentially leading to the transaction data failing to be executed successfully in subsequent processes. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and readable storage medium based on a blockchain network, which can ensure the fairness of transaction data being packaged into blocks and improve the success rate of transaction data execution.

[0004] This application provides a data processing method based on a blockchain network. The blockchain network includes multiple block proposal nodes and is composed of multiple subnetworks. Each block proposal node is located in a different subnetwork, and at least one of the multiple subnetworks is used to store the same transaction data. The multiple block proposal nodes include a target node, and the multiple subnetworks include a target subnetwork where the target node is located. The method includes:

[0005] The target node obtains transaction data from the target sub-network and constructs the first sub-block based on the transaction data;

[0006] Consensus processing is performed on the transaction data in the first sub-block within the target sub-network. When consensus is reached on the first sub-block, the first sub-block is broadcast to the blockchain network.

[0007] Obtain the second sub-block broadcast by other block proposal nodes; other block proposal nodes refer to block proposal nodes other than the target node among multiple block proposal nodes. The second sub-block is constructed by other block proposal nodes and is a sub-block that has been passed through the consensus of its sub-network.

[0008] The first and second sub-blocks are merged according to the block merging rules to obtain a merged block. The merged block is then executed to obtain the first transaction execution result. Based on the first transaction execution result, consensus processing is performed on the merged block in the blockchain network.

[0009] The consensus process for transaction data in the first sub-block within the target sub-network includes:

[0010] In the target sub-network, the transaction data in the first sub-block is verified to obtain the transaction verification result;

[0011] Based on the transaction verification results, a first sub-vote is generated for the first sub-block, and the first sub-vote is broadcast to the blockchain network.

[0012] Obtain the second sub-vote broadcast by other block proposal nodes, and determine the consensus result for the first sub-block based on the first and second sub-votes; the second sub-vote is determined by other block proposal nodes by verifying the transaction data in the first sub-block.

[0013] Specifically, transaction verification is performed on the transaction data in the first sub-block within the target sub-network to obtain the transaction verification results, including:

[0014] In the target sub-network, the transaction signature of the transaction data in the first sub-block is verified to obtain the signature verification result;

[0015] Verify the resource availability of transaction data and account data resources to obtain resource verification results;

[0016] Perform data format validation on the transaction data and obtain the format validation results;

[0017] The signature verification result, resource verification result, and format verification result are determined as the transaction verification result for the transaction data in the first sub-block.

[0018] Specifically, the first and second sub-blocks are merged based on block merging rules to obtain a merged block, including:

[0019] Retrieve the H transaction data contained in the first and second sub-blocks; H is a positive integer; perform deduplication on the H transaction data to obtain S transaction data; S is a positive integer less than or equal to H;

[0020] Based on the numerical value of the resource consumption of S transaction data, the transaction data is sorted from high to low, and the resource availability of the sorted S transaction data is verified in order.

[0021] Transaction data that passes resource availability verification is identified as transactions to be merged. Block header parameters are generated based on the transactions to be merged, and merged blocks are generated based on the block header parameters and the transactions to be merged.

[0022] Among them, the S sorted transaction data include transaction data T i Where i is a positive integer less than or equal to S, and the transaction data T i There are corresponding object accounts; resource availability verification is performed on the sorted S transaction data in sequence, including:

[0023] The account data resources corresponding to the target account are compared with the transaction data T. i The resources consumed in the transactions were compared numerically.

[0024] If transaction data T i If the value of the transaction resource consumption is less than or equal to the value of the account data resource, then the transaction data T is determined. i Verify resource availability;

[0025] If transaction data T i If the value of the transaction's resource consumption is greater than the value of the account data resources, then the transaction data T is determined to be invalid. i Transaction data T failed the resource availability verification. i Delete it.

[0026] The sorted S transaction data also include transaction data T. j j is a positive integer less than or equal to S, and the transaction data is T. i Sort in transaction data T j Previously, and transaction data T i and transaction data T j The corresponding object accounts are the same; the method also includes:

[0027] When the transaction data T is determined i When verifying resource availability, based on transaction data T i The estimated account data resources are obtained by deducting the estimated account data resources from the estimated resources consumed by the transaction.

[0028] Estimated account data resources and transaction data T j The resources consumed in the transactions were compared numerically.

[0029] If transaction data T j If the value of the transaction resource consumption is less than or equal to the value of the estimated account data resources, then the transaction data T is determined. j Verify resource availability;

[0030] If transaction data T j If the value of the transaction resource consumption is greater than the estimated value of the account data resources, then the transaction data T is determined to be... j Transaction data T failed the resource availability verification. j Delete it.

[0031] The consensus process for merging blocks in the blockchain network, based on the execution result of the first transaction, includes:

[0032] Obtain the execution result of the second transaction; the execution result of the second transaction is obtained by other block proposal nodes through executing the block obtained by merging the first sub-block and the second sub-block;

[0033] Based on the results of the first and second transactions, the first voting result for the merged block is determined and broadcast to the blockchain network.

[0034] Obtain the second voting result, and determine the consensus result for the merged block based on the first and second voting results; the second voting result is the voting result provided by the consensus nodes and other block proposal nodes in the blockchain network for the block obtained by merging the first and second sub-blocks.

[0035] The determination of the first voting result for the merged block based on the execution results of the first and second transactions includes:

[0036] Compare the results of the first and second transactions;

[0037] If the execution results of the first transaction and the second transaction are the same, then the vote in favor will be determined as the first vote result for the merged block;

[0038] If the execution results of the first transaction and the second transaction are different, the dissenting vote will be determined as the first vote result for the merged block.

[0039] The consensus result for merging blocks is determined based on the first and second voting results, including:

[0040] Count the number of affirmative votes in the first and second voting results, obtain the total number of consensus nodes and multiple block proposal nodes in the blockchain network, and calculate the ratio between the number of affirmative votes and the total number of nodes;

[0041] If the ratio meets the block consensus conditions, the consensus success result is determined as the consensus result for the merged block, the merged block is stored in the blockchain database, and the status of the account associated with the merged block is updated according to the first transaction execution result.

[0042] If the ratio does not meet the block consensus conditions, the consensus failure result is determined as the consensus result for the merged block.

[0043] One embodiment of this application provides a data processing device based on a blockchain network, including:

[0044] The transceiver module is used by the target node to obtain transaction data from the target sub-network and construct the first sub-block based on the transaction data;

[0045] The transaction processing module is used to perform consensus processing on the transaction data in the first sub-block in the target sub-network, and broadcast the first sub-block to the blockchain network when the consensus on the first sub-block is passed.

[0046] The block acquisition module is used to acquire the second sub-block broadcast by other block proposal nodes. Other block proposal nodes refer to block proposal nodes other than the target node among multiple block proposal nodes. The second sub-block is constructed by other block proposal nodes and is a sub-block that has been passed through the consensus of its sub-network.

[0047] The block merging module is used to merge the first sub-block and the second sub-block based on the block merging rules to obtain a merged block, execute the merged block, obtain the first transaction execution result, and perform consensus processing on the merged block in the blockchain network based on the first transaction execution result.

[0048] In one possible implementation, when the transaction processing module performs consensus processing on the transaction data in the first sub-block within the target sub-network, it specifically performs the following operations:

[0049] In the target sub-network, the transaction data in the first sub-block is verified to obtain the transaction verification result;

[0050] Based on the transaction verification results, a first sub-vote is generated for the first sub-block, and the first sub-vote is broadcast to the blockchain network.

[0051] Obtain the second sub-vote broadcast by other block proposal nodes, and determine the consensus result for the first sub-block based on the first and second sub-votes; the second sub-vote is determined by other block proposal nodes by verifying the transaction data in the first sub-block.

[0052] In one possible implementation, the transaction processing module is used to verify the transaction data in the first sub-block within the target sub-network. Upon obtaining the transaction verification result, it is specifically used to perform the following operations:

[0053] In the target sub-network, the transaction signature of the transaction data in the first sub-block is verified to obtain the signature verification result;

[0054] Verify the resource availability of transaction data and account data resources to obtain resource verification results;

[0055] Perform data format validation on the transaction data and obtain the format validation results;

[0056] The signature verification result, resource verification result, and format verification result are determined as the transaction verification result for the transaction data in the first sub-block.

[0057] In one possible implementation, the block merging module is used to merge the first sub-block and the second sub-block based on the block merging rules. When the merged block is obtained, it is specifically used to perform the following operations:

[0058] Retrieve the H transaction data contained in the first and second sub-blocks; H is a positive integer; perform deduplication on the H transaction data to obtain S transaction data; S is a positive integer less than or equal to H;

[0059] Based on the numerical value of the resource consumption of S transaction data, the transaction data is sorted from high to low, and the resource availability of the sorted S transaction data is verified in order.

[0060] Transaction data that passes resource availability verification is identified as transactions to be merged. Block header parameters are generated based on the transactions to be merged, and merged blocks are generated based on the block header parameters and the transactions to be merged.

[0061] In one possible implementation, the sorted S transaction data include transaction data T. i Where i is a positive integer less than or equal to S, and the transaction data T i There is a corresponding object account; when the block merging module performs resource availability verification on the sorted S transaction data in sequence, it is specifically used to perform the following operations:

[0062] The account data resources corresponding to the target account are compared with the transaction data T. i The resources consumed in the transactions were compared numerically.

[0063] If transaction data T i If the value of the transaction resource consumption is less than or equal to the value of the account data resource, then the transaction data T is determined. i Verify resource availability;

[0064] If transaction data T i If the value of the transaction's resource consumption is greater than the value of the account data resources, then the transaction data T is determined to be invalid. i Transaction data T failed the resource availability verification. i Delete it.

[0065] In one possible implementation, the sorted S transaction data also include transaction data T. j j is a positive integer less than or equal to S, and the transaction data is T. i Sort in transaction data T j Previously, and transaction data T i and transaction data T j The corresponding object accounts are the same; the block merging module is also used to perform the following operations:

[0066] When the transaction data T is determinedi When verifying resource availability, based on transaction data T i The estimated account data resources are obtained by deducting the estimated account data resources from the estimated resources consumed by the transaction.

[0067] Estimated account data resources and transaction data T j The resources consumed in the transactions were compared numerically.

[0068] If transaction data T j If the value of the transaction resource consumption is less than or equal to the value of the estimated account data resources, then the transaction data T is determined. j Verify resource availability;

[0069] If transaction data T j If the value of the transaction resource consumption is greater than the estimated value of the account data resources, then the transaction data T is determined to be... j Transaction data T failed the resource availability verification. j Delete it.

[0070] In one possible implementation, the block merging module, when performing consensus processing on the merged block in the blockchain network based on the result of the first transaction execution, specifically performs the following operations:

[0071] Obtain the execution result of the second transaction; the execution result of the second transaction is obtained by other block proposal nodes through executing the block obtained by merging the first sub-block and the second sub-block;

[0072] Based on the results of the first and second transactions, the first voting result for the merged block is determined and broadcast to the blockchain network.

[0073] Obtain the second voting result, and determine the consensus result for the merged block based on the first and second voting results; the second voting result is the voting result provided by the consensus nodes and other block proposal nodes in the blockchain network for the block obtained by merging the first and second sub-blocks.

[0074] In one possible implementation, when the block merging module determines the first voting result for the merged block based on the first transaction execution result and the second transaction execution result, it specifically performs the following operations:

[0075] Compare the results of the first and second transactions;

[0076] If the execution results of the first transaction and the second transaction are the same, then the vote in favor will be determined as the first vote result for the merged block;

[0077] If the execution results of the first transaction and the second transaction are different, the dissenting vote will be determined as the first vote result for the merged block.

[0078] In one possible implementation, when the block merging module determines the consensus result for merging blocks based on the first and second voting results, it specifically performs the following operations:

[0079] Count the number of affirmative votes in the first and second voting results, obtain the total number of consensus nodes and multiple block proposal nodes in the blockchain network, and calculate the ratio between the number of affirmative votes and the total number of nodes;

[0080] If the ratio meets the block consensus conditions, the consensus success result is determined as the consensus result for the merged block, the merged block is stored in the blockchain database, and the status of the account associated with the merged block is updated according to the first transaction execution result.

[0081] If the ratio does not meet the block consensus conditions, the consensus failure result is determined as the consensus result for the merged block.

[0082] One embodiment of this application provides a computer device, including: a processor, a memory, and a network interface;

[0083] The processor is connected to a memory and a network interface. The network interface is used to provide data communication functions, and the memory is used to store computer programs. When the computer program is executed by the processor, the computer device performs the method provided in the embodiments of this application.

[0084] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0085] One embodiment of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method provided in this application embodiment.

[0086] This application embodiment obtains transaction data from a target node among multiple block proposal nodes, and constructs a first sub-block based on the transaction data. Consensus processing of the transaction data in the first sub-block is then performed within the target sub-network where the target node resides. The first sub-block is merged with second sub-blocks constructed by other block proposal nodes using block merging rules to obtain a merged block. The execution result of the first transaction obtained by executing the merged block is then used to perform consensus processing of the merged block within the blockchain network. Because a blockchain network consists of multiple sub-networks, with each block proposal node located in a different sub-network, and at least one of these sub-networks can store the same transaction data—meaning a transaction can send the same transaction data to multiple sub-networks—multiple block proposal nodes can obtain the transaction data through their respective sub-networks. These nodes can then package the same transaction data into their respective sub-blocks. Since at least one block proposal node has packaged the transaction data, it is highly likely that the merged block will also include it. This reduces the possibility of transaction data not being included in a block, ensuring fairness in the inclusion process and minimizing the likelihood of transaction parties missing transaction opportunities, thereby increasing the success rate of transaction execution. Attached Figure Description

[0087] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0088] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0089] Figure 2 This is a scenario illustration of a data processing method based on a blockchain network provided in an embodiment of this application. Figure 1 ;

[0090] Figure 3 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 1 ;

[0091] Figure 4 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 2 ;

[0092] Figure 5This is a schematic diagram of the structure of a data processing device based on a blockchain network provided in an embodiment of this application;

[0093] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0095] It is understood that, in the specific embodiments of this application, the user data involved requires user permission or consent when applied to specific products or technologies in the following embodiments of this application, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions.

[0096] If this application requires the collection of object data (such as user data), a prompt interface or pop-up window will be displayed before and during the collection process. This prompt interface or pop-up window is used to inform the user that certain data is being collected. The data acquisition steps will only begin after the user confirms the prompt interface or pop-up window; otherwise, the process will end. Furthermore, the acquired user data will be used in reasonable and legal scenarios or for legitimate purposes. Optionally, in scenarios where user data needs to be used but user authorization has not been obtained, authorization can be requested from the user, and the user data can only be used after authorization is granted.

[0097] This application relates to blockchain technology, and the specific embodiments are illustrated below.

[0098] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores the same blockchain. The blockchain network can distinguish between consensus nodes and business nodes, with the consensus node responsible for achieving consensus across the entire network. The process of writing transaction data into the ledger in a blockchain network can be described as follows: a resource client sends transaction data to a business node, which then relays this data among the business nodes in the blockchain network until the consensus node receives it. The consensus node then packages the transaction data into a block and reaches a consensus with other consensus nodes. After consensus is reached, the block containing the transaction data is written into the ledger.

[0099] A block is a data packet carrying transaction data on a blockchain network. It's a data structure marked with a timestamp and the hash value of the previous block. Blocks are verified and confirmed by the network's consensus mechanism. A block consists of a block header and a block body. The block header records metadata about the current block, including the current version number, the hash value of the previous block, a timestamp, a random number, and the hash value of the Merkle root. The block body records detailed data generated over a period of time, including all verified transactions and other information generated during the block creation process; it can be understood as a form of ledger representation. Furthermore, the detailed data in the block body may include a unique Merkle root recorded in the block header, generated through a Merkle tree hashing process.

[0100] Hash value: Also known as information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output through a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash value of its predecessor block, which is called the parent block of the current block. The hash value is a core and crucial aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0101] Broadcast mechanism: This refers to the process by which blockchain nodes propagate information (such as transactions and blocks) throughout the entire network via peer-to-peer network protocols. When a blockchain node generates a new transaction or block, it sends this information to other blockchain nodes directly connected to it. These nodes then forward the information, and so on, propagating it level by level until all blockchain nodes in the entire blockchain network have received the information. The broadcast mechanism ensures that data in the blockchain network can be propagated quickly and efficiently, while maintaining the network's decentralized nature and consistency.

[0102] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. For example... Figure 1 As shown, this network structure can be a blockchain network. The blockchain network can contain blockchain nodes 10a, 10b, 10c, 20d, ..., 20n, and all blockchain nodes can act as consensus nodes and block proposal nodes.

[0103] In a blockchain network, before a block is added to the chain, it must pass consensus among the consensus nodes. Only after consensus is reached can the block be added to the blockchain. Block proposal nodes can participate in block consensus, help propagate block and voting messages, and synchronize states. When the blockchain network uses the Byzantine consensus mechanism to achieve block consensus, the assembly of blocks and the initiation of consensus are usually completed by the block proposal node (also known as the master node or block producer node). In the embodiments of this application, as... Figure 1 The blockchain network shown can use the Byzantine consensus mechanism to achieve consensus on blocks. In this case, a blockchain node with consensus function, such as blockchain node 10b, after successfully putting the block at the current block height on the chain, needs to determine multiple block proposal nodes to generate the block corresponding to the next block height in order to complete the consensus operation for the block at the next block height.

[0104] Specifically, a blockchain network can contain multiple sub-networks. This involves first dividing the blockchain nodes within the network, and then constructing multiple sub-networks based on these divided nodes. For example... Figure 1 As shown, the blockchain network consists of three sub-networks (sub-network 1, sub-network 2, and sub-network 3), and blockchain nodes 20d, 20e, and 20n are used as block proposal nodes for illustration. Sub-network 1 can include blockchain node 20d and other consensus nodes in the blockchain network; sub-network 2 can include blockchain node 20e and other consensus nodes; and sub-network 1 can include blockchain node 20n and other consensus nodes.

[0105] Since there are block proposal nodes in the three sub-networks, there can be three block proposal nodes: block proposal node 20d, block proposal node 20e, and block proposal node 20n. Sub-block 1 can be generated through block proposal node 20d in sub-network 1, sub-block 2 can be generated through block proposal node 20e in sub-network 2, and sub-block 3 can be generated through block proposal node 20n in sub-network 3. The three sub-blocks can perform consensus processing on transaction data in their respective sub-networks. After consensus is reached, the three block proposal nodes can broadcast their consensus-reached sub-blocks to the entire blockchain network. Thus, each blockchain node (including consensus nodes and block proposal nodes) can merge the sub-blocks broadcast by the three block proposal nodes to obtain a merged block. Then, consensus processing is performed on the merged block based on the execution result obtained from executing the merged block.

[0106] It is understandable that since transaction objects can send the same transaction data to multiple sub-networks, allowing multiple block proposal nodes to obtain the transaction data through their respective sub-networks, multiple block proposal nodes can package the same transaction data into their respective sub-blocks. Therefore, as long as at least one block proposal node among multiple block proposal nodes has packaged the transaction data, it is very likely that the merged block will also include the transaction data. This reduces the possibility that the transaction data cannot be packaged into the block, ensuring the fairness of the packaging of transaction data into the block. This reduces the possibility that transaction objects will miss the transaction opportunity, thereby improving the execution success rate of transaction data.

[0107] Please see Figure 2 , Figure 2 This is a scenario illustration of a data processing method based on a blockchain network provided in an embodiment of this application. Figure 1 ;like Figure 2 As shown, a blockchain network can consist of multiple sub-networks. An object can send the same transaction data to any blockchain node within multiple sub-networks. The transaction data can then be further placed into transaction pools within these sub-networks. The block proposal node can then retrieve the transaction data from the transaction pool of its respective sub-network. At least one sub-network is used to store the same transaction data. For example, since an object can send the same transaction data to three sub-networks, all three sub-networks can be used to store the same transaction data, thus reducing the possibility that the transaction data cannot be included in a block.

[0108] One of the multiple block proposal nodes can be identified as the target node (e.g., Figure 1 In the blockchain node 20d), the subnetwork where the target node is located in multiple subnetworks can be identified as the target subnetwork, while other block proposal nodes can be Figure 1Blockchain nodes 20e and 20n, consensus nodes can be... Figure 1 Blockchain nodes 10a, 10b, and 10c are shown in the diagram. The target node can obtain transaction data from the transaction pool of its target sub-network via a P2P (Pix2Pix) network. Based on this data, it constructs block header parameters such as version number, Merkle root, timestamp, difficulty target, and random number. Then, it constructs the first sub-block based on the block header parameters and transaction data. Consensus processing of the transaction data in the first sub-block is then performed within the target sub-network. For example, transaction verification is performed on the transaction data in the first sub-block to obtain verification results (such as signature verification results, format verification results, etc.). The target node can then vote on the first sub-block to reach consensus within the target sub-network based on these verification results.

[0109] like Figure 2 As shown, other block proposal nodes in the sub-network can also construct a second sub-block using the acquired transaction data. When consensus on the second sub-block is reached within their respective sub-networks, the second sub-block is broadcast to the blockchain network. The target node can then obtain the second sub-block through the blockchain network and merge the first and second sub-blocks according to the block merging rules to obtain a merged block. For example, it can obtain H transaction data points (H is a positive integer) shared by the first and second sub-blocks, and remove duplicate transaction data from these H transaction data points to obtain S distinct transaction data points (S is a positive integer less than or equal to H).

[0110] The target node can obtain the resource consumption values ​​of S transactions, and then sort the transactions from highest to lowest based on their resource consumption values. The sorted S transactions are then identified as the transactions to be merged. Block header parameters are generated based on these transactions, and a merged block is generated based on the block header parameters and the transactions to be merged. By executing the merged block, the first transaction execution result is obtained. The target node can then perform consensus processing on the merged block within the blockchain network based on this first transaction execution result.

[0111] This application embodiment obtains transaction data from a target node among multiple block proposal nodes, and constructs a first sub-block based on the transaction data. Consensus processing of the transaction data in the first sub-block is then performed within the target sub-network where the target node resides. The first sub-block is merged with second sub-blocks constructed by other block proposal nodes using block merging rules to obtain a merged block. The execution result of the first transaction obtained by executing the merged block is then used to perform consensus processing of the merged block within the blockchain network. Because a blockchain network consists of multiple sub-networks, with each block proposal node located in a different sub-network, and at least one of these sub-networks can store the same transaction data—meaning a transaction can send the same transaction data to multiple sub-networks—multiple block proposal nodes can obtain the transaction data through their respective sub-networks. These nodes can then package the same transaction data into their respective sub-blocks. Since at least one block proposal node has packaged the transaction data, it is highly likely that the merged block will also include it. This reduces the possibility of transaction data not being included in a block, ensuring fairness in the inclusion process and minimizing the likelihood of transaction parties missing transaction opportunities, thereby increasing the success rate of transaction execution.

[0112] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 1 This data processing method can be executed by the target node, which can be, for example, Figure 1 The blockchain node 20d is shown below. The following explanation will use the execution of this data processing method by the target node as an example. This data processing method will at least include the following steps S101-S104:

[0113] Step S101: The target node obtains transaction data from the target sub-network and constructs the first sub-block based on the transaction data;

[0114] Specifically, a blockchain network can consist of multiple subnetworks, including multiple block proposal nodes. Each block proposal node resides in a different subnetwork. These multiple block proposal nodes include a target node, and the multiple subnetworks include the target subnetwork where the target node resides. At least one of these subnetworks stores the same transaction data. The target node can obtain transaction data from the transaction pool of the target subnetwork and construct the first subblock based on this data. Here, a subnetwork refers to a logical or physical partition within the blockchain network, composed of a group of blockchain nodes that can collaboratively perform specific tasks or process specific data. A single subnetwork is logically or physically isolated from other subnetworks and can operate independently or collaboratively with other subnetworks to achieve more complex tasks or higher efficiency.

[0115] For example, transaction data can be selected from the transaction pool based on factors such as transaction fees, transaction size, and transaction priority. This transaction data can then be used to construct the block body. For instance, a transaction counter can be built to record the number of transactions contained in a block, or a transaction list can be constructed to store the transaction data within the block. This transaction list can include the protocol version used by the transaction data, the input and output of the transaction data, and the lock time of the transaction data. The target node can obtain block header parameters such as the protocol version number, the Merkle root used to ensure transaction integrity, the timestamp used to record the current time, and the difficulty target used to reflect the current business difficulty of the blockchain network. Therefore, the block proposal node can construct the first sub-block based on the aforementioned block header parameters and the transaction data in the block body.

[0116] Step S102: Perform consensus processing on the transaction data in the first sub-block in the target sub-network. When the consensus on the first sub-block is passed, broadcast the first sub-block to the blockchain network.

[0117] Specifically, the target node can perform consensus processing on the transaction data in the first sub-block within the target sub-network. For example, within the target sub-network, the target node can verify the transaction signature of the transaction data in the first sub-block using a signature verification algorithm, such as the asymmetric encryption algorithm ECDSA (Elliptic Curve Digital Signature Algorithm), to obtain a signature verification result; it can also verify the availability of transaction resources and account data resources by comparing the transaction resources and account data resources to obtain a resource verification result; and it can verify the input and output of the transaction data, RLP encoding (Recursive Length Prefix), and other data formats to obtain a format verification result. Thus, the signature verification result, resource verification result, and format verification result are determined as the transaction verification result for the transaction data in the first sub-block, and the transaction verification result and the first sub-block are then broadcast to the target sub-network. The asymmetric encryption algorithm ECDSA is an asymmetric encryption algorithm based on elliptic curve cryptography, used to generate digital signatures and verify the integrity and origin of data in digital signatures. It leverages the mathematical complexity of elliptic curves to provide a secure method that ensures the security and authenticity of information during transmission. Because the asymmetric encryption algorithm ECDSA can provide the same or even higher level of security with shorter key lengths, it can be efficiently applied in scenarios requiring high security and processing speed, such as blockchain technology and secure communication.

[0118] The target node can generate a first sub-vote for the first sub-block based on the transaction verification results. For example, if the signature verification result, resource verification result, and format verification result are all successful, meaning the transaction signature of the transaction data in the first sub-block has been successfully verified, and the transaction resources consumed by the transaction data in the first sub-block are less than or equal to the account data resources of the transaction account, and the data format verification of the transaction data is successful, then it can be determined that the transaction data in the first sub-block has been successfully verified. The "yes" vote can then be determined as the first sub-vote and broadcast to the blockchain network. Conversely, if the signature verification result, resource verification result, or format verification result is a failure, then the "no" vote will be determined as the first sub-vote.

[0119] In the target sub-network, blockchain nodes other than the target node (including consensus nodes and block proposal nodes) can also determine the second sub-vote for the first sub-block by verifying the transaction data in the first sub-block and broadcast the second sub-vote to the target sub-network. The target node can then obtain the second sub-vote through the target sub-network and determine the consensus result for the first sub-block based on the first and second sub-votes. For example, the ratio of the number of affirmative votes in the first and second sub-votes to the total number of blockchain nodes in the target sub-network can be calculated. If the ratio meets the block voting conditions (such as a ratio greater than 2 / 3), it can be determined that the consensus for the first sub-block has passed, and the target node can then broadcast the first sub-block to the blockchain network.

[0120] Step S103: Obtain the second sub-block broadcast by other block proposal nodes;

[0121] Specifically, other block proposal nodes can build a second sub-block in their respective sub-network based on the process of the target node constructing the first sub-block, and perform consensus processing on the transaction data in the second sub-block. When the consensus on the second sub-block is passed in their respective sub-network, the second sub-block is broadcast to the blockchain network. The target node can then obtain the second sub-block broadcast by other block proposal nodes through the blockchain network.

[0122] Step S104: Based on the block merging rules, merge the first sub-block and the second sub-block to obtain a merged block, execute the merged block to obtain the first transaction execution result, and perform consensus processing on the merged block in the blockchain network based on the first transaction execution result.

[0123] Specifically, the target node can merge the first sub-block and the second sub-block based on the block merging rules to obtain a merged block. For example, it can obtain H transaction data commonly contained in the first and second sub-blocks, and then deduplicate the H transaction data to obtain S transaction data; where H is a positive integer and S is a positive integer less than or equal to H. Then, it can obtain the transaction resource consumption values ​​of the S transaction data, sort the transaction data from high to low according to the value of the transaction resource consumption of the S transaction data, and generate block header parameters based on the transaction data. Thus, it can generate a merged block based on the block header parameters and the transaction data, and then execute the merged block.

[0124] For example, the balance of relevant accounts can be updated based on the transaction data of the merged block. If the transaction involves a smart contract, the storage state of the smart contract can be updated to generate logs or events to record the execution result of the transaction data, i.e., to generate the first transaction execution result of the merged block. The target node can perform consensus processing on the merged block in the blockchain network based on the first transaction execution result. For example, other block proposal nodes can also obtain the second transaction execution result by executing the block obtained by merging the first and second sub-blocks, and then broadcast the second transaction execution result to the blockchain network. The target node can then obtain the second transaction execution result and determine the first voting result for the merged block based on the first and second transaction execution results. If the first and second transaction execution results are compared, and they are different, the dissenting vote can be determined as the first voting result for the merged block.

[0125] Consensus nodes and other block proposal nodes in a blockchain network can also generate a second voting result for the block obtained by merging the first and second sub-blocks, and then broadcast the second voting result to the blockchain network. For example, a consensus node can execute the block obtained by merging the first and second sub-blocks to obtain a third transaction execution result. It can then compare the received first, second, and third transaction execution results. If the first, second, and third transaction execution results are all the same, the affirmative vote result can be determined as the second voting result. Other block proposal nodes can compare the obtained first and second transaction execution results. If the first and second transaction execution results are the same, the affirmative vote result can be determined as the second voting result.

[0126] The target node can obtain the second voting result through the blockchain network, and then determine the consensus result for the merged block based on the first and second voting results. For example, by counting the number of affirmative votes in the first and second voting results, and obtaining the total number of consensus nodes and multiple block proposal nodes in the blockchain network, a ratio between the number of affirmative votes and the total number of nodes can be generated. If the ratio meets the block consensus condition (e.g., the ratio is greater than 2 / 3), the consensus success result can be determined as the consensus result for the merged block, and the merged block can be stored in the blockchain database. The status of the account associated with the merged block can be updated according to the first transaction execution result. If the ratio does not meet the block consensus condition, the consensus failure result can be determined as the consensus result for the merged block.

[0127] For example, a block consensus condition can be that the ratio of the number of affirmative votes to the total number of consensus nodes in the blockchain network is greater than or equal to 2 / 3. If there are a total of 6 consensus nodes and multiple block proposal nodes in the blockchain network, and the target node can receive the second voting results broadcast by other block proposal nodes and consensus nodes, and obtains 2 affirmative votes from the second voting results, then the ratio P of the number of affirmative votes in the second voting results to the total number of consensus nodes in the blockchain network is 1 / 3. Since P is less than 2 / 3, it can be determined that the ratio P does not meet the block consensus condition, thus determining that the consensus for the block merge has failed. Therefore, the consensus failure result can be determined as the consensus result for the merged block.

[0128] It is understood that the embodiments of this application obtain transaction data based on a target node among multiple block proposal nodes, and construct a first sub-block based on the transaction data, thereby performing consensus processing on the transaction data in the first sub-block within the target sub-network where the target node is located. By merging the first sub-block with the second sub-block constructed by other block proposal nodes through block merging rules, a merged block can be obtained. The first transaction execution result obtained by executing the merged block is then used to perform consensus processing on the merged block in the blockchain network based on the first transaction execution result. Because a blockchain network consists of multiple sub-networks, with each block proposal node located in a different sub-network, and at least one of these sub-networks can store the same transaction data—meaning a transaction can send the same transaction data to multiple sub-networks—multiple block proposal nodes can obtain the transaction data through their respective sub-networks. These nodes can then package the same transaction data into their respective sub-blocks. Since at least one block proposal node has packaged the transaction data, it is highly likely that the merged block will also include it. This reduces the possibility of transaction data not being included in a block, ensuring fairness in the inclusion process and minimizing the likelihood of transaction parties missing transaction opportunities, thereby increasing the success rate of transaction execution. Furthermore, by having multiple blockchain nodes propose solutions for transaction data, multiple sub-blocks can be obtained. Then, a merging rule based on the transaction resources consumed by the transaction data can be used to merge the sub-blocks into a merged block. If the consensus on the merged block is passed, it means that most blockchain nodes obtained the merged block by sorting according to the block merging rule. Therefore, the determinism of the sorting method can be guaranteed. As a result, it is difficult for a single block proposal node to extract value by changing the sorting of transaction data within the block, thus protecting the interests of the target.

[0129] Please see Figure 4 , Figure 4 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 2This data processing method can be executed by the target node, which can be, for example, Figure 1 The blockchain node 20d is shown below. The following explanation will use the execution of this data processing method by the target node as an example. This data processing method will at least include the following steps S201-S206:

[0130] Step S201: The target node obtains transaction data from the target sub-network and constructs the first sub-block based on the transaction data;

[0131] Specifically, a blockchain network can consist of multiple sub-networks, including multiple block proposal nodes. Each block proposal node resides in a different sub-network. These multiple block proposal nodes include a target node, and the multiple sub-networks include the target sub-network where the target node resides. At least one of these sub-networks stores the same transaction data. The target node can obtain transaction data from the transaction pool of the target sub-network and construct the first sub-block based on this data. For example, a secure connection can be established with the data source in the transaction pool of the target sub-network through an encrypted channel built on the TLS 1.3 (Transport Layer Security 1.3) protocol, allowing the selection of transaction data based on factors such as transaction fees, transaction size, and transaction priority.

[0132] A transaction pool can be a temporary storage area in a blockchain network used to store transaction data that has not yet been packaged into a block. The TLS 1.3 protocol is a new generation standard for secure communication, significantly improving security, performance, and protocol simplification compared to its predecessor, TLS 1.2. It increases connection speed by reducing the number of message exchanges during the handshake process, enforces forward secrecy for enhanced security, and removes some known insecure cryptographic algorithms, such as SHA-1 (Secure Hash Algorithm 1). TLS 1.3 also supports zero round-trip time recovery, further reducing connection latency and making data transmission faster and more secure.

[0133] The target node can construct a transaction counter represented as a variable-length integer (e.g., 0 and 1 can represent one transaction) to quickly verify transaction data. It can also construct a transaction list for the first sub-block based on the transaction data to store the transaction data within the first sub-block. This transaction list can include the protocol version used by the transaction data, the inputs and outputs of the transaction data, and the lock time of the transaction data. The target node can then construct the block body based on the transaction list and transaction counter. Furthermore, it can obtain block header parameters such as the version number, Merkle root, timestamp, difficulty target, random number, and the hash value of the previous block, and then construct the first sub-block based on these block header parameters and the transaction data within the block header.

[0134] The timestamp of the first sub-block can be used to record the generation time of the first sub-block. Its format can be a Unix timestamp or an ISO 8601 format (such as YYYY-MM-DDTHH:MM:SSZ), without any restrictions. The difficulty target of the first sub-block is used to limit the growth rate of the first sub-block and can be represented in a 4-byte compressed format, such as 1d00ffff. The random number of the first sub-block is used to adjust the hash value of the first sub-block so that the hash value meets the difficulty target. Obtaining the hash value of the previous block, that is, the hash value of the parent block of the first sub-block, is to verify the chain structure of the blockchain network to prevent tampering.

[0135] The target node can construct the Merkle tree for the first sub-block based on the selected transaction data. This is done by using a hash function such as SHA-256 (Secure Hash Algorithm 256, a 256-bit hash algorithm) to calculate the hash value of each leaf node for each transaction (each transaction corresponds to a leaf node). These leaf node hash values ​​are then combined pairwise, and the hash value of each combination is used to calculate the hash value of the intermediate nodes. If the number of transactions is odd, the hash value of the last leaf node is repeated to ensure that each intermediate layer has an even number of intermediate nodes. This process is repeated layer by layer upwards to generate intermediate nodes until a unique root node hash value is obtained, thus completing the construction of the Merkle tree. The root node hash value is used as the Merkle root, which is an important component of the block header and can be used to efficiently verify the integrity of the transaction data within the block. The target node can construct the first sub-block using the block header parameters and the transaction data in the block body.

[0136] Step S202: Verify the transaction data in the first sub-block in the target sub-network to obtain the transaction verification result; generate a first sub-vote for the first sub-block based on the transaction verification result and broadcast the first sub-vote to the blockchain network; obtain the second sub-vote broadcast by other block proposal nodes, determine the consensus result for the first sub-block based on the first and second sub-votes; when the consensus for the first sub-block is passed, broadcast the first sub-block to the blockchain network.

[0137] Specifically, the target node can verify the transaction data in the first sub-block within the target sub-network to obtain transaction verification results. For example, it can verify the transaction signature of the transaction data in the first sub-block within the target sub-network to obtain a signature verification result, verify the resource availability of the transaction data's consumed resources and account data resources to obtain a resource verification result, and verify the data format of the transaction data to obtain a format verification result. The signature verification result, resource verification result, and format verification result are then determined as the transaction verification results for the transaction data in the first sub-block, and the target node broadcasts the transaction verification results and the first sub-block to the target sub-network.

[0138] For example, a target node can verify the transaction signature of the transaction data in the first sub-block using the SHA256withRSA algorithm within the target sub-network. This verification involves hashing the transaction data using the SHA-256 algorithm to obtain a first hash value, and then decrypting the transaction signature using the corresponding public key to obtain a second hash value. The first and second hash values ​​are then compared; if they match, the transaction signature verification is successful. The SHA256withRSA algorithm is a cryptographic algorithm combining the SHA-256 hash function and the RSA encryption algorithm, widely used in data integrity and authentication scenarios. This combined algorithm provides a reliable method for secure information transmission by first hashing the data using SHA-256 and then encrypting the hash value using the RSA algorithm. SHA256withRSA is particularly important in digital signatures and secure communication protocols (such as TLS (Transport Layer Security)), ensuring the security and authenticity of data during transmission while preventing data tampering and unauthorized access.

[0139] The process of hashing transaction data using the SHA-256 algorithm to obtain the first hash value can be as follows: The obtained transaction data is evenly divided into five blocks, namely Block1, ..., Block5. These five blocks are then read cyclically. After reading Block1, it is submitted to hash object 1, at which point the hash value in hash object 1 is Z1 = 45678abc12345678 (hash value Z1 can also be called the hash value updated for the first time in hash object 1). After reading Block2, the hash value can be... The hash value Z1 in object 1 is updated by Z2 = Hash(Z1, Block2), resulting in the second updated hash value Z2 = 1234567890abcdef in hash object 1. Similarly, after reading the block transaction data Block5, the hash value Z4 in hash object 1 can be updated by Z5 = Hash(Z4, Block5), resulting in the fifth updated hash value Z5 = 9876543210fedcba9 in hash object 1. At this point, all block transaction data has been read, and the fifth updated hash value Z5 in hash object 1 can be determined as the first hash value.

[0140] Taking the verification and decryption of transaction signatures in transaction data using the RSA algorithm as an example, the process can be shown in formula (1):

[0141] de_hash_value = (signature) e mod n formula (1)

[0142] Here, 'e' represents the public key exponent, which can be used as part of the secure public key and is used in the exponential operation during signature verification and decryption. 'hash_value' represents the first hash value, 'de_hash_value' represents the second hash value, 'signature' represents the transaction signature, and 'n' represents a large modulus, usually obtained by multiplying two large prime numbers, and is shared by both the secure private and public keys. The second hash value, 'de_hash_value', is obtained by taking the modulus 'n' of the power obtained by raising the public key exponent 'e' to the power of the transaction signature. The target node can then compare the first hash value 'hash_value' with the second hash value 'de_hash_value'. If the first hash value 'hash_value' and the second hash value 'de_hash_value' are the same, the signature verification is successful, and the successful verification result is recognized as the signature verification result. It is understandable that if a leak occurs during the transmission of the transaction signature, causing the transaction signature to be tampered with, the first hash value (hash_value) or the first signature data (signature) may be changed. The target node can then calculate and confirm that the first hash value (hash_value) is different from the second hash value (de_hash_value) obtained from the signature verification and decryption, thereby determining that the transaction signature verification fails. This can prevent the transaction data corresponding to the leaked transaction signature from entering the subsequent process.

[0143] The target node can also obtain the transaction resources consumed by the transaction data and the account data resources of the corresponding object account, thereby verifying the resource availability of the transaction resources consumed by the transaction data and the account data resources, and obtaining the resource verification result. For example, by comparing the transaction resources consumed by the transaction data and the account data resources, if the value of the transaction resources consumed by the transaction data is less than or equal to the value of the account data resources, then the transaction data is determined to have passed the resource availability verification, and the successful verification result is determined as the resource verification result.

[0144] The target node can also perform data format validation on transaction data, obtaining the format validation result. For example, it can validate the data type of the transaction data to ensure it conforms to the expected type (e.g., integer, floating-point number, string, etc.); validate the numerical range of the transaction data to ensure it is within the allowed range (e.g., 1 billion); and validate the format of information in the transaction data (e.g., date, number, etc.), such as verifying that the date format conforms to the standard date format (i.e., year-month-day). The target node can also validate the input and output of transaction data to ensure that the input amount of each transaction references a valid unspent output, and to ensure that the output amount of each transaction does not exceed the difference between the input amount and the transaction fee. If all the above data format validations pass, the successful validation result can be determined as the format validation result.

[0145] Therefore, the target node can determine the signature verification result, resource verification result, and format verification result as the transaction verification result for the transaction data in the first sub-block, and then broadcast the transaction verification result and the first sub-block to the target sub-network. It can also generate the first sub-vote for the first sub-block based on the transaction verification result. For example, if the signature verification result, resource verification result, and format verification result are all successful, that is, the successful verification result is determined as the transaction verification result for the transaction data in the first sub-block, then the "yes" vote can be determined as the first sub-vote for the first sub-block. If the signature verification result, resource verification result, or format verification result is a failure, that is, the failure verification result is determined as the transaction verification result for the transaction data in the first sub-block, then the "no" vote can be determined as the first sub-vote for the first sub-block. The target node can then broadcast the first sub-vote to the blockchain network.

[0146] It is understandable that blockchain nodes in the target sub-network other than the target node (including consensus nodes and block proposal nodes) can also determine the second sub-vote for the first sub-block by verifying the transaction data in the first sub-block, and broadcast the second sub-vote to the target sub-network. Then, the target node can obtain the second sub-vote through the target sub-network, and then determine the consensus result for the first sub-block based on the first and second sub-votes. For example, the ratio of the number of affirmative votes in the first and second sub-votes to the total number of blockchain nodes in the target sub-network can be counted. If the ratio meets the block voting condition (such as a ratio greater than 2 / 3), it can be determined that the consensus for the first sub-block has passed, that is, the successful consensus result is determined as the consensus result for the first sub-block, and the target node can broadcast the first sub-block to the blockchain network. If the ratio of affirmative votes in the first and second sub-votes does not meet the block voting condition, the consensus failure result can be determined as the consensus result for the first sub-block.

[0147] Step S203: Obtain the second sub-block broadcast by other block proposal nodes;

[0148] Specifically, other block proposal nodes can construct the second sub-block based on the process of the target node constructing the first sub-block. In this way, consensus processing is carried out on the transaction data in the second sub-block within their respective sub-networks. When the consensus on the second sub-block is passed, the second sub-block can be broadcast to the blockchain network, and the target node can receive the second sub-block broadcast by other block proposal nodes.

[0149] Step S204: Obtain the H transaction data contained in the first sub-block and the second sub-block; perform deduplication on the H transaction data to obtain S transaction data; sort the transaction data from high to low based on the value of the transaction resources consumed by the S transaction data, and perform resource availability verification on the sorted S transaction data in order.

[0150] Specifically, since an object can send the same transaction data to multiple sub-networks, multiple block proposal nodes can package the transaction data obtained in their respective sub-networks. Therefore, the first sub-block generated by the target node and the second sub-block generated by other block proposal nodes may contain the same transaction data. The target node needs to deduplicate the transaction data in the first and second sub-blocks, i.e., obtain the H common transaction data contained in the first and second sub-blocks, deduplicate the H transaction data, and obtain S transaction data, where H is a positive integer and S is a positive integer less than or equal to H. For example, a unique identifier (such as a transaction ID) for each of the H transaction data can be stored as a key in a hash table, or the H transaction data can be added to a set. Since the keys of a hash table and the data structure of a set do not allow duplicate elements, deduplication of the H transaction data can be achieved.

[0151] The target node can also store H transaction data in a database, using the DISTINCT keyword in SQL (Structured Query Language) for deduplication. It can also sort the H transaction data based on transaction attributes (such as transaction ID or timestamp), and then use a script to traverse the sorted list of transaction data, comparing adjacent transactions for similarities and removing duplicates to obtain S distinct transaction data. SQL is a standardized programming language specifically designed for communicating with databases, allowing users to define, query, manipulate, and control data within the database. SQL is a powerful language capable of creating and managing databases and tables, as well as inserting, updating, deleting, and retrieving data. It is widely used in relational database management systems such as MySQL, Oracle, and SQL Server, and is the industry standard for database management and data querying. This allows developers and database administrators to efficiently retrieve information from large datasets, perform complex data analyses, and maintain data integrity and security.

[0152] The target node can obtain the resource consumption of S transactions, and then sort the S transactions from highest to lowest based on their resource consumption values. This can be done by using the `sorted()` function in the compiler or the `sort()` method of a list, or by using the `ORDER BY` clause in SQL. The resource availability of the sorted S transactions can then be verified sequentially. For example, for any one of the S transactions, T... i Where i is a positive integer less than or equal to S, transaction data T can be obtained. i The resources consumed in the transaction, and the acquisition of transaction data T i The corresponding account data resources of the target account, thereby transferring the transaction data T i The transaction resources consumed are compared with the account data resources of the target account. If the transaction data T... i If the value of the transaction resource consumption is less than or equal to the value of the account data resource, then the transaction data T is determined. i Verify resource availability; if transaction data T i If the value of the transaction's resource consumption is greater than the value of the account data resources, then the transaction data T is determined to be invalid. i Resource availability verification failed, and transaction data T was sent. i Delete it.

[0153] It is understandable that the S transaction data also include those sorted in transaction data T. i Subsequent transaction data T jj is a positive integer less than or equal to S, and the transaction data T i and transaction data T j These can correspond to the same object account. Then, the target node determines the transaction data T. i When verifying resource availability, transaction data T can be used as a reference. i The transaction resource consumption is estimated and deducted from the account data resources (this is an estimate, not an actual deduction), resulting in estimated account data resources (i.e., the estimated remaining account data resources of the target account). These estimated account data resources are then compared with the transaction data T. j The resource consumption of each transaction is compared numerically. If the transaction data T j If the value of the transaction resource consumption is less than or equal to the value of the estimated account data resources, then the transaction data T is determined. j Verify resource availability; if transaction data T j If the value of the transaction resource consumption is greater than the estimated value of the account data resources, then the transaction data T is determined to be... j Transaction data T failed the resource availability verification. j Delete it.

[0154] For example, given that the account data resource of object C is 100 yuan, object C sends transaction data T to the target subnetwork. i and transaction data T j Then, S transaction data can contain transaction data T. i and transaction data T j The target node can obtain transaction data T in the target subnetwork. i The transaction consumes 80 yuan of resources, and the transaction data T j The transaction consumes 60 yuan of resources. Then, the account data resources of object C's object account are combined with the transaction data T. i After comparing the resource consumption of each transaction, the transaction data T can be determined. i The value of the transaction resource consumption is less than the value of the account data resource, thus determining the transaction data T. i If the resource availability verification is passed, the target node can then use the transaction data T. i The estimated account data resources consumed by the transaction are deducted from the account data resources, resulting in an estimated account data resource value of 20 yuan. This estimated account data resource value is then compared with the transaction data T. j After comparing the resources consumed in each transaction, the transaction data T can be determined. j Resource availability verification failed, therefore transaction data T was not approved. j Delete it.

[0155] Step S205: The transaction data that has passed the resource availability verification is identified as the transaction to be merged, block header parameters are generated based on the transaction to be merged, and a merged block is generated based on the block header parameters and the transaction to be merged.

[0156] Specifically, the target node can identify the transaction data that has passed resource availability verification among the aforementioned S transaction data as the transactions to be merged. It then generates block header parameters based on these transactions, and generates a merged block based on the block header parameters and the transactions to be merged. The process of generating the merged block is similar to the process of generating the first sub-block described above, and will not be repeated here. The merged block can be represented as Block = [tx_1, tx_2, ..., tx_n](fee(tx1) >= fee(tx2) >= fee(tx_n)). n In this context, Block represents the merged block, tx_1, tx_2, ..., tx_n represent the transactions to be merged in the merged block, and fee(tx_1), fee(tx_2), ..., fee(tx_n) represent the transaction resources consumed by the transactions to be merged.

[0157] Step S206: Execute the merged block to obtain the first transaction execution result, and perform consensus processing on the merged block in the blockchain network based on the first transaction execution result.

[0158] Specifically, the target node can execute the merged block to obtain the first transaction execution result. For example, by executing each transaction data in the merged block, the balance of the relevant account can be updated according to the transaction content. If the transaction involves a smart contract, the storage state of the smart contract can be read, and the code in the smart contract can be executed to update the smart contract state, such as modifying the storage state, triggering events, or calling other contracts. The updated smart contract state is then written into the merged block to generate a transaction log or transaction event to record the first transaction execution result of the transaction data. The target node can also construct a transaction receipt containing information such as transaction hash, transaction log, and transaction resource consumption, without any restrictions.

[0159] Other block-proposing nodes can also obtain a second transaction execution result by executing the block resulting from the merger of the first and second sub-blocks, and then broadcast the second transaction execution result to the blockchain network. The target node can then obtain the second transaction execution result broadcast by other block-proposing nodes, and determine the first voting result for the merged block based on the first and second transaction execution results, and broadcast the first voting result to the blockchain network. For example, the first and second transaction execution results can be compared; if the first and second transaction execution results are the same, the "yes" vote is determined as the first voting result for the merged block; if the first and second transaction execution results are different, the "no" vote is determined as the first voting result for the merged block.

[0160] Consensus nodes and other block proposal nodes in the blockchain network can also generate a second voting result for the block obtained by merging the first and second sub-blocks, and then broadcast the second voting result to the blockchain network. For example, a consensus node can execute the block obtained by merging the first and second sub-blocks to obtain a third transaction execution result. It can then compare the received first, second, and third transaction execution results. If all three results are the same, the "yes" vote is determined as the second voting result; if any two of these results are different, the "no" vote is determined as the second voting result. Other block proposal nodes can compare the first and second transaction execution results they receive. If they are the same, the "yes" vote is determined as the second voting result; if they are different, the "no" vote is determined as the second voting result.

[0161] The target node can determine the consensus result for the merged block based on the first voting result and the received second voting result. For example, it can count the number of affirmative votes in the first and second voting results, and obtain the total number of consensus nodes and multiple block proposal nodes in the blockchain network, thereby calculating the ratio between the number of affirmative votes and the total number of nodes. If the ratio meets the block consensus condition, the consensus success result is determined as the consensus result for the merged block, the merged block is stored in the blockchain database, and the status of the account associated with the merged block is updated according to the first transaction execution result. If the ratio does not meet the block consensus condition, the consensus failure result is determined as the consensus result for the merged block.

[0162] For example, a block consensus condition can be that the ratio of the number of affirmative votes to the total number of consensus nodes in the blockchain network is greater than or equal to 2 / 3. If there are a total of 9 consensus nodes and multiple block proposal nodes in the blockchain network, and the target node can receive the second voting results broadcast by other block proposal nodes and consensus nodes, and obtains 7 affirmative votes from the second voting results, then the ratio Q of the number of affirmative votes in the second voting results to the total number of consensus nodes in the blockchain network is 7 / 9. Since Q is greater than 2 / 3, it can be determined that the ratio Q satisfies the block consensus condition, and thus the consensus for the block merge is successful. Therefore, the successful consensus result can be determined as the consensus result for the merged block.

[0163] The target node can write the successfully merged block to the blockchain database. This database can be a relational database, such as MySQL, or a non-relational database, such as MongoDB. For example, it can insert the block header parameters of the merged block into the block table of the blockchain database and create indexes for key fields of the block header parameters (such as block hash and height) to optimize query performance. Transaction data within the block body of the merged block can be inserted in batches, and transaction management ensures that the write of transaction data is atomic. The target node can also update the account data resources and smart contract status of the object account associated with the merged block based on the execution result of the first transaction of the merged block.

[0164] It is understood that the embodiments of this application obtain transaction data based on a target node among multiple block proposal nodes, and construct a first sub-block based on the transaction data, thereby performing consensus processing on the transaction data in the first sub-block within the target sub-network where the target node is located. By merging the first sub-block with the second sub-block constructed by other block proposal nodes through block merging rules, a merged block can be obtained. The first transaction execution result obtained by executing the merged block is then used to perform consensus processing on the merged block in the blockchain network based on the first transaction execution result. Because a blockchain network consists of multiple sub-networks, with each block proposal node residing in a different sub-network, and at least one of these sub-networks can store the same transaction data—meaning a transaction can send the same transaction data to multiple sub-networks—multiple block proposal nodes can access this data through their respective sub-networks. Therefore, each block proposal node can package the same transaction data into its own sub-block. If at least one block proposal node packages the transaction data, it's highly likely that the merged block will also include it, reducing the possibility of the transaction data not being included in the block and ensuring fairness in its inclusion. This also reduces the likelihood of transaction participants missing transaction opportunities, thereby increasing the success rate of transaction execution. Furthermore, by deduplicating and sorting the transaction data across multiple blockchain nodes, S sorted transaction data points can be obtained. If resource availability verification of these S transaction data points is successful, it indicates that all S transaction data points are valid. Therefore, a merging rule based on the transaction resource consumption of the transaction data can be used to merge the sub-blocks into a merged block, further improving the success rate of transaction execution in the merged block. If consensus on merging blocks is passed, it means that most blockchain nodes sorted the blocks according to the block merging rules, thus ensuring the determinism of the sorting method. Therefore, it is difficult for a single block proposal node to extract value by changing the sorting of transaction data within the block, thereby protecting the interests of the parties involved.

[0165] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a data processing device based on a blockchain network provided in an embodiment of this application. Figure 5 As shown, the data processing device includes a transceiver module 1100, a transaction processing module 1200, a block acquisition module 1300, and a block merging module 1400.

[0166] The transceiver module 1100 is used by the target node to obtain transaction data from the target sub-network and construct the first sub-block based on the transaction data;

[0167] The transaction processing module 1200 is used to perform consensus processing on the transaction data in the first sub-block in the target sub-network, and broadcast the first sub-block to the blockchain network when the consensus on the first sub-block is passed.

[0168] The block acquisition module 1300 is used to acquire the second sub-block broadcast by other block proposal nodes; other block proposal nodes refer to block proposal nodes other than the target node among multiple block proposal nodes. The second sub-block is constructed by other block proposal nodes and is a sub-block that has been passed through the consensus of its sub-network.

[0169] The block merging module 1400 is used to merge the first sub-block and the second sub-block based on the block merging rules to obtain a merged block, execute the merged block, obtain the first transaction execution result, and perform consensus processing on the merged block in the blockchain network based on the first transaction execution result.

[0170] In one possible implementation, when the transaction processing module 1200 performs consensus processing on the transaction data in the first sub-block in the target sub-network, it specifically performs the following operations:

[0171] In the target sub-network, the transaction data in the first sub-block is verified to obtain the transaction verification result;

[0172] Based on the transaction verification results, a first sub-vote is generated for the first sub-block, and the first sub-vote is broadcast to the blockchain network.

[0173] Obtain the second sub-vote broadcast by other block proposal nodes, and determine the consensus result for the first sub-block based on the first and second sub-votes; the second sub-vote is determined by other block proposal nodes by verifying the transaction data in the first sub-block.

[0174] In one possible implementation, the transaction processing module 1200 is used to verify the transaction data in the first sub-block in the target sub-network, and when the transaction verification result is obtained, it is specifically used to perform the following operations:

[0175] In the target sub-network, the transaction signature of the transaction data in the first sub-block is verified to obtain the signature verification result;

[0176] Verify the resource availability of transaction data and account data resources to obtain resource verification results;

[0177] Perform data format validation on the transaction data and obtain the format validation results;

[0178] The signature verification result, resource verification result, and format verification result are determined as the transaction verification result for the transaction data in the first sub-block.

[0179] In one possible implementation, the block merging module 1400 is used to merge the first sub-block and the second sub-block based on the block merging rules. When the merged block is obtained, it is specifically used to perform the following operations:

[0180] Retrieve the H transaction data contained in the first and second sub-blocks; H is a positive integer; perform deduplication on the H transaction data to obtain S transaction data; S is a positive integer less than or equal to H;

[0181] Based on the numerical value of the resource consumption of S transaction data, the transaction data is sorted from high to low, and the resource availability of the sorted S transaction data is verified in order.

[0182] Transaction data that passes resource availability verification is identified as transactions to be merged. Block header parameters are generated based on the transactions to be merged, and merged blocks are generated based on the block header parameters and the transactions to be merged.

[0183] In one possible implementation, the sorted S transaction data include transaction data T. i Where i is a positive integer less than or equal to S, and the transaction data T i There is a corresponding object account; when the block merging module 1400 performs resource availability verification on the sorted S transaction data in sequence, it is specifically used to perform the following operations:

[0184] The account data resources corresponding to the target account are compared with the transaction data T. i The resources consumed in the transactions were compared numerically.

[0185] If transaction data T i If the value of the transaction resource consumption is less than or equal to the value of the account data resource, then the transaction data T is determined. i Verify resource availability;

[0186] If transaction data T i If the value of the transaction's resource consumption is greater than the value of the account data resources, then the transaction data T is determined to be invalid. i Transaction data T failed the resource availability verification. i Delete it.

[0187] In one possible implementation, the sorted S transaction data also include transaction data T. j j is a positive integer less than or equal to S, and the transaction data is T. i Sort in transaction data T j Previously, and transaction data T i and transaction data T j The corresponding object accounts are the same; the block merging module 1400 is also used to perform the following operations:

[0188] When the transaction data T is determined i When verifying resource availability, based on transaction data T i The estimated account data resources are obtained by deducting the estimated account data resources from the estimated resources consumed by the transaction.

[0189] Estimated account data resources and transaction data T j The resources consumed in the transactions were compared numerically.

[0190] If transaction data T j If the value of the transaction resource consumption is less than or equal to the value of the estimated account data resources, then the transaction data T is determined. j Verify resource availability;

[0191] If transaction data T j If the value of the transaction resource consumption is greater than the estimated value of the account data resources, then the transaction data T is determined to be... j Transaction data T failed the resource availability verification. j Delete it.

[0192] In one possible implementation, when the block merging module 1400 performs consensus processing on the merged block in the blockchain network based on the result of the first transaction execution, it specifically performs the following operations:

[0193] Obtain the execution result of the second transaction; the execution result of the second transaction is obtained by other block proposal nodes through executing the block obtained by merging the first sub-block and the second sub-block;

[0194] Based on the results of the first and second transactions, the first voting result for the merged block is determined and broadcast to the blockchain network.

[0195] Obtain the second voting result, and determine the consensus result for the merged block based on the first and second voting results; the second voting result is the voting result provided by the consensus nodes and other block proposal nodes in the blockchain network for the block obtained by merging the first and second sub-blocks.

[0196] In one possible implementation, when the block merging module 1400 determines the first voting result for the merged block based on the first transaction execution result and the second transaction execution result, it specifically performs the following operations:

[0197] Compare the results of the first and second transactions;

[0198] If the execution results of the first transaction and the second transaction are the same, then the vote in favor will be determined as the first vote result for the merged block;

[0199] If the execution results of the first transaction and the second transaction are different, the dissenting vote will be determined as the first vote result for the merged block.

[0200] In one possible implementation, when the block merging module 1400 determines the consensus result for merging blocks based on the first voting result and the second voting result, it specifically performs the following operations:

[0201] Count the number of affirmative votes in the first and second voting results, obtain the total number of consensus nodes and multiple block proposal nodes in the blockchain network, and calculate the ratio between the number of affirmative votes and the total number of nodes;

[0202] If the ratio meets the block consensus conditions, the consensus success result is determined as the consensus result for the merged block, the merged block is stored in the blockchain database, and the status of the account associated with the merged block is updated according to the first transaction execution result.

[0203] If the ratio does not meet the block consensus conditions, the consensus failure result is determined as the consensus result for the merged block.

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

[0205] This application embodiment obtains transaction data from a target node among multiple block proposal nodes, and constructs a first sub-block based on the transaction data. Consensus processing of the transaction data in the first sub-block is then performed within the target sub-network where the target node resides. The first sub-block is merged with second sub-blocks constructed by other block proposal nodes using block merging rules to obtain a merged block. The execution result of the first transaction obtained by executing the merged block is then used to perform consensus processing of the merged block within the blockchain network. Because a blockchain network consists of multiple sub-networks, with each block proposal node residing in a different sub-network, and at least one of these sub-networks can store the same transaction data—meaning a transaction can send the same transaction data to multiple sub-networks—multiple block proposal nodes can access this data through their respective sub-networks. Therefore, each block proposal node can package the same transaction data into its own sub-block. If at least one block proposal node packages the transaction data, it's highly likely that the merged block will also include it, reducing the possibility of the transaction data not being included in the block and ensuring fairness in its inclusion. This also reduces the likelihood of transaction participants missing transaction opportunities, thereby increasing the success rate of transaction execution. Furthermore, by deduplicating and sorting the transaction data across multiple blockchain nodes, S sorted transaction data points can be obtained. If resource availability verification of these S transaction data points is successful, it indicates that all S transaction data points are valid. Therefore, a merging rule based on the transaction resource consumption of the transaction data can be used to merge the sub-blocks into a merged block, further improving the success rate of transaction execution in the merged block. If consensus on merging blocks is passed, it means that most blockchain nodes sorted the blocks according to the block merging rules, thus ensuring the determinism of the sorting method. Therefore, it is difficult for a single block proposal node to extract value by changing the sorting of transaction data within the block, thereby protecting the interests of the parties involved.

[0206] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 6As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include an object interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The object interface 1003 may include a display screen and a keyboard; optionally, the object interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 6 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, an object interface module, and a device control application.

[0207] In such Figure 6 In the computer device 1000 shown, the network interface 1004 can provide network communication elements; the object interface 1003 is mainly used to provide an input interface for objects; and the processor 1001 can be used to call the device control application stored in the memory 1005.

[0208] When the computer device 1000 is a data processing device, it achieves the following:

[0209] The target node obtains transaction data from the target sub-network and constructs the first sub-block based on the transaction data;

[0210] Consensus processing is performed on the transaction data in the first sub-block within the target sub-network. When consensus is reached on the first sub-block, the first sub-block is broadcast to the blockchain network.

[0211] Obtain the second sub-block broadcast by other block proposal nodes; other block proposal nodes refer to block proposal nodes other than the target node among multiple block proposal nodes. The second sub-block is constructed by other block proposal nodes and is a sub-block that has been passed through the consensus of its sub-network.

[0212] The first and second sub-blocks are merged according to the block merging rules to obtain a merged block. The merged block is then executed to obtain the first transaction execution result. Based on the first transaction execution result, consensus processing is performed on the merged block in the blockchain network.

[0213] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 4 The description of the data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0214] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program. When the processor executes the computer program, it can execute the aforementioned... Figure 3 , Figure 4 The description of the data processing method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0215] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, such as a 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, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer 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 displayed or will be displayed.

[0216] Furthermore, it should be noted that this application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned... Figure 3 , Figure 4 The method provided in any of the corresponding embodiments.

[0217] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. 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 not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0218] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0219] The methods and related apparatus provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0220] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0221] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0222] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on a blockchain network, characterized in that, The blockchain network includes multiple block proposal nodes, and the blockchain network is composed of multiple sub-networks. Each block proposal node is located in a different sub-network, and at least one of the multiple sub-networks is used to store the same transaction data. The plurality of block proposal nodes include target nodes, and the plurality of sub-networks include the target sub-network in which the target node is located; the method includes: The target node obtains transaction data from the target sub-network and constructs a first sub-block based on the transaction data; Consensus processing is performed on the transaction data in the first sub-block in the target sub-network, and the first sub-block is broadcast to the blockchain network when consensus is passed for the first sub-block; Obtain the second sub-block broadcast by other block proposal nodes; the other block proposal nodes refer to the block proposal nodes other than the target node among the multiple block proposal nodes, the second sub-block is constructed by the other block proposal nodes, and the second sub-block is a sub-block that has been passed through the consensus of its sub-network. The first sub-block and the second sub-block are merged based on the block merging rules to obtain a merged block. The merged block is executed to obtain a first transaction execution result. Consensus processing of the merged block is performed in the blockchain network based on the first transaction execution result.

2. The method according to claim 1, characterized in that, The consensus processing of the transaction data in the first sub-block within the target sub-network includes: In the target sub-network, the transaction data in the first sub-block is verified to obtain the transaction verification result; Based on the transaction verification result, a first sub-vote is generated for the first sub-block, and the first sub-vote is broadcast to the blockchain network. Obtain the second sub-vote broadcast by the other block proposal nodes, and determine the consensus result for the first sub-block based on the first sub-vote and the second sub-vote; the second sub-vote is determined by the other block proposal nodes by verifying the transaction data in the first sub-block.

3. The method according to claim 2, characterized in that, The step of performing transaction verification on the transaction data in the first sub-block in the target sub-network to obtain the transaction verification result includes: In the target sub-network, the transaction signature of the transaction data in the first sub-block is verified to obtain the signature verification result; The resource availability of the transaction data and account data resources is verified to obtain the resource verification results. The transaction data is subjected to data format verification to obtain the format verification result; The signature verification result, the resource verification result, and the format verification result are determined as the transaction verification result for the transaction data in the first sub-block.

4. The method according to claim 1, characterized in that, The process of merging the first sub-block and the second sub-block based on block merging rules to obtain a merged block includes: Obtain the H transaction data contained in the first sub-block and the second sub-block; H is a positive integer; perform deduplication on the H transaction data to obtain S transaction data; S is a positive integer less than or equal to H; Based on the numerical value of the resource consumption of the S transaction data, the transaction data are sorted from high to low, and the resource availability of the sorted S transaction data is verified in order. Transaction data that passes resource availability verification is identified as transactions to be merged. Block header parameters are generated based on the transactions to be merged, and a merged block is generated based on the block header parameters and the transactions to be merged.

5. The method according to claim 4, characterized in that, The sorted S transaction data include transaction data T i , where i is a positive integer less than or equal to S, and the transaction data T i There are corresponding object accounts; the sequential verification of resource availability for the sorted S transaction data includes: The account data resources corresponding to the object account are compared with the transaction data T. i The resources consumed in the transactions were compared numerically. If the transaction data T i If the value of the transaction resource consumption is less than or equal to the value of the account data resource, then the transaction data T is determined to be... i Verify resource availability; If the transaction data T i If the value of the transaction resource consumption is greater than the value of the account data resource, then the transaction data T is determined to be... i The transaction data T failed the resource availability verification. i Delete it.

6. The method according to claim 5, characterized in that, The sorted S transaction data also include transaction data T. j j is a positive integer less than or equal to S, and the transaction data T i Sort in the transaction data T j Previously, and the transaction data T i and the transaction data T j The corresponding object accounts are the same; the method also includes: When the transaction data T is determined i During resource availability verification, based on the transaction data T i The estimated account data resources are obtained by deducting the estimated account data resources from the estimated resources consumed by the transactions. The estimated account data resources and the transaction data T are combined j The resources consumed in the transactions were compared numerically. If the transaction data T j If the value of the transaction resource consumption is less than or equal to the value of the estimated account data resource, then the transaction data T is determined to be... j Verify resource availability; If the transaction data T j If the value of the transaction resource consumption is greater than the estimated value of the account data resources, then the transaction data T is determined to be... j The transaction data T failed the resource availability verification. j Delete it.

7. The method according to claim 1, characterized in that, The consensus processing of the merged block in the blockchain network based on the first transaction execution result includes: Obtain the second transaction execution result; the second transaction execution result is obtained by the other block proposal nodes through executing the block obtained by merging the first sub-block and the second sub-block; Based on the first transaction execution result and the second transaction execution result, a first voting result is determined for the merged block, and the first voting result is broadcast to the blockchain network; Obtain the second voting result, and determine the consensus result for the merged block based on the first voting result and the second voting result; the second voting result is the voting result provided by the consensus nodes and the other block proposal nodes in the blockchain network for the block obtained by merging the first sub-block and the second sub-block.

8. The method according to claim 7, characterized in that, The step of determining the first voting result for the merged block based on the first transaction execution result and the second transaction execution result includes: Compare the first transaction execution result with the second transaction execution result; If the execution results of the first transaction and the second transaction are the same, then the vote in favor will be determined as the first vote result for the merged block; If the execution results of the first transaction and the second transaction are different, then the dissenting vote result will be determined as the first vote result for the merged block.

9. The method according to claim 7, characterized in that, The step of determining the consensus result for the merged block based on the first voting result and the second voting result includes: The number of affirmative votes in the first and second voting results is counted to obtain the total number of consensus nodes and block proposal nodes in the blockchain network, and the ratio between the number of affirmative votes and the total number of nodes is calculated. If the ratio satisfies the block consensus condition, the consensus success result is determined as the consensus result for the merged block, the merged block is stored in the blockchain database, and the status of the account associated with the merged block is updated according to the first transaction execution result. If the ratio does not meet the block consensus conditions, then the consensus failure result is determined as the consensus result for the merged block.

10. A data processing device based on a blockchain network, characterized in that, include: The transceiver module is used for the target node to obtain transaction data from the target sub-network and construct a first sub-block based on the transaction data; The transaction processing module is used to perform consensus processing on the transaction data in the first sub-block in the target sub-network, and broadcast the first sub-block to the blockchain network when the consensus on the first sub-block is passed. The block acquisition module is used to acquire the second sub-block broadcast by other block proposal nodes; The other block proposal nodes refer to the block proposal nodes other than the target node among the plurality of block proposal nodes. The second sub-block is constructed by the other block proposal nodes, and the second sub-block is a sub-block that has been passed through the consensus of its sub-network. The block merging module is used to merge the first sub-block and the second sub-block based on the block merging rules to obtain a merged block, execute the merged block to obtain a first transaction execution result, and perform consensus processing on the merged block in the blockchain network based on the first transaction execution result.

11. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium and adapted to be read and executed by a processor so that a computer device having the processor performs the method of any one of claims 1-9.

Images