Data processing method and device based on blockchain network, equipment and storage medium

Abstract

The application discloses a data processing method and device based on a blockchain network, equipment and a storage medium. The method comprises the following steps: obtaining read set data corresponding to business data according to a receipt generation request; the read set data comprises state data required by an instruction corresponding to the executed business data in a chain process; generating snapshot data according to the read set data and block metadata corresponding to the business data; re-executing the instruction corresponding to the business data based on the snapshot data to obtain contract receipt information; the contract receipt information comprises data generated by re-executing the instruction corresponding to the business data, and the contract receipt information is used for generating verification information for the business data, and the verification information is used for indicating the main chain network to verify the correctness of the business data in the secondary chain network.

Description

Technical Field

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

[0002] In existing blockchain systems, to improve the efficiency of executing business data, an increasing number of blockchain systems are adopting Layer 2 design using secondary chain networks. This involves designating the main chain network as Layer 1 and the secondary chain network as Layer 2, with the secondary chain network assisting the main chain network in executing business data. In Layer 2 design, the secondary chain network needs to package and upload business data to the blockchain, and periodically aggregate the uploaded data in the secondary chain network to generate hash root data. This hash root data is then uploaded to the main chain network for processing; this process can also be called aggregation. Through aggregation, the main chain network can verify the uploaded business data in the secondary chain network using the hash root data. However, when malicious nodes exist in the secondary chain network, they may upload abnormal data, resulting in some uploaded data being abnormal. Since the main chain network cannot verify the correctness of the uploaded data in the secondary chain network using the hash root data, when the main chain network completes uploading the hash root data, it may mistakenly consider the abnormal uploaded data in the secondary chain network to be reliable, thus reducing the security of business data processing. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and storage medium based on a blockchain network, which can improve the security of business data processing in a blockchain network architecture that includes a secondary chain network and a main chain network.

[0004] This application provides a data processing method based on a blockchain network, wherein the blockchain network includes a main chain network and a secondary chain network, and the method is executed by blockchain nodes in the secondary chain network. The method includes:

[0005] Obtain a receipt generation request for business data; the business data is data that has already undergone the on-chain process in the secondary chain network;

[0006] The read set data corresponding to the business data is obtained based on the receipt generation request; the read set data includes the status data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0007] Snapshot data is generated based on the block metadata corresponding to the read set data and the business data;

[0008] Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain contract receipt information. The contract receipt information includes the data generated by re-executing the instructions corresponding to the business data. The contract receipt information is used to generate verification information for the business data. The verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

[0009] This includes retrieving the read set data corresponding to the business data from the node database based on the receipt generation request, including:

[0010] The on-chain data in the node database is queried using the data identifier in the receipt generation request;

[0011] If the on-chain data in the node database includes business data corresponding to the data identifier, then the read set data corresponding to the business data can be obtained from the node database through the data identifier.

[0012] If the on-chain data in the node database does not include the business data corresponding to the data identifier, an error message will be returned.

[0013] Specifically, snapshot data is generated based on the block metadata corresponding to the read set data and the business data, including:

[0014] Construct a snapshot data structure, obtain the status data corresponding to each read instruction in the read set data, obtain the business block containing business data, obtain the block metadata corresponding to the business block, and fill the status data and block metadata into the snapshot data structure in the order of execution of the read instructions in the read set data to obtain the snapshot data.

[0015] Specifically, based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain contract receipt information, including:

[0016] Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain the business receipt data of the business data; the business receipt data includes the data generated by re-executing the instructions corresponding to the business data.

[0017] The consistency of business receipt data is verified by using the read set data, write set data, and result data stored in the node database; both the write set data and the result data are associated with the business data.

[0018] After the consistency verification is passed, the business receipt data is hashed to obtain the business hash value;

[0019] The business hash value and business receipt data are identified as contract receipt information used to characterize the execution process of business data.

[0020] Specifically, based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain the business receipt data, including:

[0021] The snapshot data retrieves the account address associated with the business data and the resource data corresponding to the account address. Based on the account address associated with the business data and the resource data corresponding to the account address, the business data is re-executed to obtain the verification read set data, verification write set data, verification result data, and instruction execution log of the business data. The instruction execution log includes the data generated by re-executing N instructions corresponding to the business data, where N is a positive integer, and N instructions refer to the instructions obtained by the business data.

[0022] Verification read set data, verification write set data, verification result data, and instruction execution log are identified as business receipt data.

[0023] This also includes:

[0024] Package the business data to obtain business blocks;

[0025] Generate the execution results corresponding to the business blocks, and broadcast the business block and execution result data in the secondary chain network;

[0026] Obtain voting information for business blocks within the secondary chain network; the voting information is generated based on business blocks and execution result data.

[0027] Consensus processing of business blocks is carried out in the secondary chain network based on voting information. When consensus is passed, the business block containing business data is stored in the secondary chain network.

[0028] This application provides another data processing method based on a blockchain network, which includes a main chain network and a secondary chain network. The method is executed by a business client in the secondary chain network and includes:

[0029] Send receipt generation requests for business data to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database; M is a positive integer, the M blockchain nodes belong to the sub-chain network, and the business data is the data that has been executed on-chain in the sub-chain network; the contract receipt information is obtained by the blockchain nodes re-executing the instructions corresponding to the business data based on snapshot data; the snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data; the read set data is generated during the on-chain process of the business data, and includes the state data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0030] Obtain contract receipt information sent by M blockchain nodes respectively, and generate verification information for business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of business data in the secondary chain network.

[0031] This also includes:

[0032] Get the node's fault tolerance value f; f is a positive integer;

[0033] The consensus node value M is determined based on the node fault tolerance value f; M is a positive integer greater than f.

[0034] Based on the consensus node value M and the quality scores corresponding to the T candidate nodes, M blockchain nodes are selected from the T candidate nodes; T is a positive integer, T is greater than or equal to M; the T candidate nodes belong to the sub-chain network.

[0035] This involves obtaining contract receipt information sent by M blockchain nodes, and generating verification information for the business data based on the M contract receipt information, including:

[0036] Obtain contract receipt information sent by M blockchain nodes respectively, and determine the verification contract receipt information from the M contract receipt information;

[0037] Generate zero-knowledge proof information for verifying contract receipt information, and determine the zero-knowledge proof information as verification information for business data.

[0038] Among the M contract receipt messages, the verified contract receipt messages are identified, including:

[0039] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0040] If all P verified receipts are identical, and P is greater than or equal to the verification threshold, then any one of the P verified receipts will be determined as the contract verification receipt.

[0041] This also includes:

[0042] If there are different verified receipts among the P verified receipts, or if P is less than the verification threshold, then an updated node value Q is generated based on the consensus node value M, and Q blockchain nodes are selected from T candidate nodes based on the updated node value Q; Q is greater than M and less than or equal to T.

[0043] Send receipt generation requests for business data to Q blockchain nodes, obtain contract receipt information sent by Q blockchain nodes respectively, perform status checks on Q contract receipt information respectively, and determine C contract receipt information that pass the status check as C verified receipt information; C is a positive integer less than or equal to Q.

[0044] If all C verified receipts are identical, and C is greater than or equal to the verification threshold, then any one of the C verified receipts will be determined as the contract verification receipt.

[0045] Among the M contract receipt messages, the verified contract receipt messages are identified, including:

[0046] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0047] Group the P verified receipts into B receipt groups; B is a positive integer; all verified receipts within a receipt group are identical.

[0048] The receipt information group with the largest number of verified receipt information among the B receipt information groups is determined as the verification receipt information group, and any one of the verified receipt information in the verification receipt information group is determined as the verification contract receipt information.

[0049] The generation of zero-knowledge proof information for verifying contract receipt information includes:

[0050] The verification contract receipt information is encoded to obtain encoded values, and an encoded polynomial is constructed based on the encoded values; the coefficients of the encoded polynomial are determined based on the encoded values.

[0051] A verification polynomial is randomly generated. A commitment polynomial is generated based on the encoding polynomial and the verification polynomial. A Merkle tree is generated based on the solution set of the commitment polynomial. The Merkle tree includes S leaf nodes, where S is a positive integer. The S leaf nodes are used to indicate the solution set of the commitment polynomial.

[0052] The root hash value of the Merkle tree is hashed to obtain the verification value. The verification polynomial, the commitment polynomial, and the verification value are then used as zero-knowledge proof information.

[0053] This also includes:

[0054] The state root of the verification information and business data is sent to the main chain network so that the main chain network can verify the verification polynomial and the commitment polynomial through the verification value. After the verification polynomial and the commitment polynomial in the verification information are verified, the state root is processed on the chain. The state root that has been on the chain in the main blockchain network is used to indicate that the business data that has been on the chain in the secondary chain network is in a verified state.

[0055] This application provides, in one aspect, a data processing device based on a blockchain network, the blockchain network including a main chain network and a secondary chain network, wherein the data processing device is applied to a blockchain node in the secondary chain network; the data processing device includes:

[0056] The receipt generation request acquisition module is used to acquire receipt generation requests for business data; the business data is the data that has already undergone the on-chain process in the secondary chain network.

[0057] The read set data acquisition module is used to obtain the read set data corresponding to the business data based on the receipt generation request; the read set data includes the status data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0058] The snapshot data generation module is used to generate snapshot data based on the block metadata corresponding to the read set data and the business data.

[0059] The receipt information generation module is used to re-execute the instructions corresponding to the business data based on the snapshot data to obtain contract receipt information. The contract receipt information includes the data generated by re-executing the instructions corresponding to the business data. The contract receipt information is used to generate verification information for the business data. The verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

[0060] In one possible implementation, when the read set data acquisition module retrieves the read set data corresponding to the business data from the node database based on the receipt generation request, it specifically performs the following operations:

[0061] The on-chain data in the node database is queried using the data identifier in the receipt generation request;

[0062] If the on-chain data in the node database includes business data corresponding to the data identifier, then the read set data corresponding to the business data can be obtained from the node database through the data identifier.

[0063] If the on-chain data in the node database does not include the business data corresponding to the data identifier, an error message will be returned.

[0064] In one possible implementation, the snapshot data generation module, when generating snapshot data based on the read set data and the corresponding block metadata of the business data, specifically performs the following operations:

[0065] Construct a snapshot data structure, obtain the status data corresponding to each read instruction in the read set data, obtain the business block containing business data, obtain the block metadata corresponding to the business block, and fill the status data and block metadata into the snapshot data structure in the order of execution of the read instructions in the read set data to obtain the snapshot data.

[0066] In one possible implementation, the receipt information generation module is used to re-execute the instructions corresponding to the business data based on the snapshot data. When obtaining the contract receipt information, it is specifically used to perform the following operations:

[0067] Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain the business receipt data of the business data; the business receipt data includes the data generated by re-executing the instructions corresponding to the business data.

[0068] The consistency of business receipt data is verified by using the read set data, write set data, and result data stored in the node database; both the write set data and the result data are associated with the business data.

[0069] After the consistency verification is passed, the business receipt data is hashed to obtain the business hash value;

[0070] The business hash value and business receipt data are identified as contract receipt information used to characterize the execution process of business data.

[0071] In one possible implementation, the receipt information generation module is used to re-execute the instructions corresponding to the business data based on the snapshot data. When obtaining the business receipt data of the business data, it is specifically used to perform the following operations:

[0072] The snapshot data retrieves the account address associated with the business data and the resource data corresponding to the account address. Based on the account address associated with the business data and the resource data corresponding to the account address, the business data is re-executed to obtain the verification read set data, verification write set data, verification result data, and instruction execution log of the business data. The instruction execution log includes the data generated by re-executing the N instructions corresponding to the business data through N instructions, where N is a positive integer and N instructions refer to the instructions called by the business data.

[0073] Verification read set data, verification write set data, verification result data, and instruction execution log are identified as business receipt data.

[0074] In one possible implementation, the receipt generation request acquisition module is also used to perform the following operations:

[0075] Package the business data to obtain business blocks;

[0076] Generate the execution results corresponding to the business blocks, and broadcast the business blocks and execution results in the secondary chain network;

[0077] Obtain voting information for business blocks within the secondary chain network; the voting information is generated based on business blocks and execution result data.

[0078] Consensus processing of business blocks is carried out in the secondary chain network based on voting information. When consensus is passed, the business block containing business data is stored in the secondary chain network.

[0079] This application provides another data processing device based on a blockchain network, the blockchain network including a main chain network and a secondary chain network, the data processing device being applied to a business client in the secondary chain network; the data processing device includes:

[0080] The receipt information acquisition module is used to send receipt generation requests for business data to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database. M is a positive integer, the M blockchain nodes belong to the secondary chain network, and the business data is the data that has been executed on-chain in the secondary chain network. The contract receipt information is obtained by the blockchain nodes re-executing the instructions corresponding to the business data based on snapshot data. The snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data. The read set data includes the status data required to execute the instructions corresponding to the business data during the on-chain process.

[0081] The verification information generation module is used to obtain contract receipt information sent by M blockchain nodes respectively, and generate verification information for business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of business data in the secondary chain network.

[0082] In one possible implementation, the receipt information acquisition module is also used to perform the following operations:

[0083] Get the node's fault tolerance value f; f is a positive integer;

[0084] The consensus node value M is determined based on the node fault tolerance value f; M is a positive integer greater than f.

[0085] Based on the consensus node value M and the quality scores corresponding to the T candidate nodes, M blockchain nodes are selected from the T candidate nodes; T is a positive integer, T is greater than or equal to M; the T candidate nodes belong to the sub-chain network.

[0086] In one possible implementation, the verification information generation module is used to obtain contract receipt information sent by M blockchain nodes respectively. When generating verification information for business data based on the M contract receipt information, it is specifically used to perform the following operations:

[0087] Obtain contract receipt information sent by M blockchain nodes respectively, and determine the verification contract receipt information from the M contract receipt information;

[0088] Generate zero-knowledge proof information for verifying contract receipt information, and determine the zero-knowledge proof information as verification information for business data.

[0089] In one possible implementation, when generating verification information to determine the verification contract receipt information from M contract receipt information, it is specifically used to perform the following operations:

[0090] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0091] If all P verified receipts are identical, and P is greater than or equal to the verification threshold, then any one of the P verified receipts will be determined as the contract verification receipt.

[0092] In one possible implementation, the verification information generation module is also used to perform the following operations:

[0093] If there are different verified receipts among the P verified receipts, or if P is less than the verification threshold, then an updated node value Q is generated based on the consensus node value M, and Q blockchain nodes are selected from T candidate nodes based on the updated node value Q; Q is greater than M and less than or equal to T.

[0094] Send receipt generation requests for business data to Q blockchain nodes, obtain contract receipt information sent by Q blockchain nodes respectively, perform status checks on Q contract receipt information respectively, and determine C contract receipt information that pass the status check as C verified receipt information; C is a positive integer less than or equal to Q.

[0095] If all C verified receipts are identical, and C is greater than or equal to the verification threshold, then any one of the C verified receipts will be determined as the contract verification receipt.

[0096] In one possible implementation, when determining the verification contract receipt information from M contract receipt information, the verification information generation module specifically performs the following operations:

[0097] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0098] Group the P verified receipts into B receipt groups; B is a positive integer; all verified receipts within a receipt group are identical.

[0099] The receipt information group with the largest number of verified receipt information among the B receipt information groups is determined as the verification receipt information group, and any one of the verified receipt information in the verification receipt information group is determined as the verification contract receipt information.

[0100] In one possible implementation, when the verification information generation module generates zero-knowledge proof information for the verification contract receipt information, it specifically performs the following operations:

[0101] The verification contract receipt information is encoded to obtain encoded values, and an encoded polynomial is constructed based on the encoded values; the coefficients of the encoded polynomial are determined based on the encoded values.

[0102] A verification polynomial is randomly generated. A commitment polynomial is generated based on the encoding polynomial and the verification polynomial. A Merkle tree is generated based on the solution set of the commitment polynomial. The Merkle tree includes S leaf nodes, where S is a positive integer. The S leaf nodes are used to indicate the solution set of the commitment polynomial.

[0103] The root hash value of the Merkle tree is hashed to obtain the verification value. The verification polynomial, the commitment polynomial, and the verification value are then used as zero-knowledge proof information.

[0104] In one possible implementation, the verification information generation module is also used to perform the following operations:

[0105] The state root of the verification information and business data is sent to the main chain network so that the main chain network can verify the verification polynomial and the commitment polynomial through the verification value. After the verification polynomial and the commitment polynomial in the verification information are verified, the state root is processed on the chain. The state root that has been on the chain in the main blockchain network is used to indicate that the business data that has been on the chain in the secondary chain network is in the correctness verification state.

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

[0107] 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.

[0108] One aspect of this application provides a computer 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.

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

[0110] This application embodiment records the state data read during the execution of business data during the on-chain process of business data, obtaining read set data. When a receipt generation request for business data is received, the read set data corresponding to the business data stored in the node database can be obtained through the receipt generation request. Snapshot data is generated using the read set data and the corresponding block metadata of the business data. The snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the business data can be efficiently re-executed to obtain contract receipt information. The contract receipt information can be used to characterize the execution process of the business data and has traceability and transparency. Verification information for the business data is generated using the contract receipt information, which can be used to verify the correctness of the execution process of the business data. Therefore, the verification information is submitted to the main chain network. The main chain network can verify the execution process of the business data using the obtained verification information, thereby determining the correctness of the business data. This avoids the main chain network incorrectly recognizing abnormal data already on-chain in the secondary chain network, providing the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chains, the security of business data processing can be improved. Attached Figure Description

[0111] 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.

[0112] Figure 1 This is a schematic diagram of the structure of a blockchain network provided in an embodiment of this application;

[0113] Figure 2 This application provides an example of a data processing scenario based on a blockchain network. Figure 1 ;

[0114] 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 ;

[0115] Figure 4This application provides an example of a data processing scenario based on a blockchain network. Figure 1 ;

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

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

[0118] Figure 7 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 1 ;

[0119] Figure 8 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 2 ;

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

[0121] 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.

[0122] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain network provided in an embodiment of this application. Figure 1As shown, the structure of this blockchain network may include a main chain network 100 and a secondary chain network 200. The main chain network 100 may include blockchain nodes 10a, 10b, 10c, 10d, ..., 10n. The secondary chain network 200 may include a business client 300, blockchain nodes 20a, 20b, 20c, 20d, ..., 20n. In the main chain network 100, data connections can be established between blockchain nodes 10a, 10b, 10c, 10d, and 10n. In network 200, data connections can be established between business client 300, blockchain node 20a, blockchain node 20b, blockchain node 20c, blockchain node 20d, and blockchain node 20n. Data connections can also be established between the main chain network 100 and the secondary chain network 200. Among them, business client 300 can be a lightweight node (a node that does not need to store complete blockchain data, but only stores block header information and transaction digests). The above data connections are not limited in terms of connection method. They can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other methods. This application does not impose any restrictions on this.

[0123] The blockchain network can be structured as an extended architecture (two-layer architecture), with a complementary and collaborative relationship between the main chain network 100 and the secondary chain network 200. The secondary chain network 200 can serve as an extension of the main chain network 100, i.e., the main chain network 100 is Layer 1, and the secondary chain network 200 is Layer 2. The main chain network 100 is the settlement layer of the blockchain network, and the secondary chain network 200 is the execution layer, assisting the main chain network 100 in executing instructions corresponding to business data. Blockchain nodes in the secondary chain network 200 (such as business client 300, blockchain node 20a, blockchain node 20b, blockchain node 20c, blockchain node 20d, and blockchain node 20n) can package business data and perform on-chain processing within the secondary chain network 200.

[0124] After the business data in the secondary chain network 200 is processed on the chain, the business client 300 can obtain the corresponding verification data and submit it to the main chain network 100. The main chain network 100 can verify the business data through the verification data to determine its legality, that is, to verify the correctness of the execution process of the business data. The specific generation process of the verification data can be found below. Figure 2 The specific details of the corresponding embodiments.

[0125] Please see Figure 2 , Figure 2 This application provides an example of a data processing scenario based on a blockchain network. Figure 2 .like Figure 2 As shown, the blockchain maintained by the secondary chain network 200 can include blocks 1, 2, ..., 101, 102, etc. Block 102 can store business data 1, business data 2, business data 3, etc. Here, business data can refer to transaction tasks that have been executed on the blockchain network, such as transfer tasks executed on the blockchain network.

[0126] Blockchain node 20a can deploy a node database. This database records data generated during the execution of instructions corresponding to the business data during the on-chain process. This data can include read set data (TxReadSet, Transaction Read Set), write set data (TxWriteSet, Transaction Write Set), and execution result data (TxResult, Transaction Result). Read set data includes the state data required for executing instructions corresponding to the business data during the on-chain process; that is, the state data read from the node database before executing these instructions, such as the resource values ​​in each account before a transfer in a transfer task. Write set data includes the state data changed by the instructions executed during the on-chain process; that is, the state data generated after executing these instructions. Write set data represents the data written to the execution environment during the execution of business data. Execution result data refers to the execution result produced by calling a smart contract to execute instructions corresponding to the business data. For example, if a smart contract performs addition, with two addends as input and the sum as output, then the sum output of the smart contract is the execution result data.

[0127] Business client 300 can be a lightweight node in the secondary chain network 200. Taking the need for business client 300 to aggregate and process business data 3 as an example, business client 300 can send a receipt generation request for business data 3 to blockchain node 20a. The receipt generation request can include the data identifier TxId (TransactionIdentification) of business data 3. When blockchain node 20a receives the receipt generation request, it can use the data identifier in the receipt generation request to retrieve the read set data corresponding to business data 3 in the deployed node database. The read set data can include the state data required to execute the instructions corresponding to business data 3 during the on-chain process of business data 3, that is, the state data read before executing the instructions corresponding to business data 3 during the on-chain process.

[0128] Taking the example of business data instructing the first account (from) to transfer digital resources with business resource values ​​(asset) to the second account (to), blockchain node 20a can query the node database and the local ledger for the first account's digital resource first resource value (fromAsset) and the second account's digital resource second resource value (toAsset). It then updates the first resource value to the difference between fromAsset and asset, and updates the second resource value to the sum of toAsset and asset, returning the execution result of the business data. Therefore, before transferring the digital resources with business resource values ​​(asset), the business accounts (i.e., the first and second accounts) and resource values ​​(i.e., the first and second resource values) retrieved by blockchain node 20a from the node database can form a read set data. Thus, the status data in the read set data can include the first resource value (fromAsset) of the first account's digital resources and the second resource value (toAsset) of the second account's digital resources.

[0129] Blockchain node 20a can construct a snapshot of the read set data based on the read set data. Based on this snapshot, it re-executes the instructions corresponding to the business data to obtain the business receipt data (TraceInfo) for business data 3. The business receipt data can include verified read set data, verified write set data, verified result data, and instruction execution logs, meaning it can include data generated by re-executing the instructions corresponding to the business data. Specifically, verified read set data refers to the read set data generated by re-executing the instructions corresponding to the business data; verified write set data refers to the write set data generated by re-executing the instructions corresponding to the business data; verified result data refers to the execution result data obtained after re-executing the instructions corresponding to the business data; and the instruction execution log includes data generated by re-executing the instructions corresponding to the business data through calling the smart contract. For example, the instruction execution log can include event information such as the depth of the call stack when the smart contract executes a certain instruction in the business data, and the service value required to execute a certain instruction in the business data (such as transaction fees).

[0130] Blockchain node 20a can perform consistency verification on the verification read set data, verification write set data, and verification result data in the business receipt data using the read set data, write set data, and execution result data corresponding to the business data stored in the node database. After the consistency verification is successful, blockchain node 20a can perform a hash operation on the business receipt data to obtain a business hash value, and then use the business hash value and the business receipt data to determine the contract receipt information. Blockchain node 20a can then send the generated contract receipt information to business client 300. Business client 300 can generate verification information for the business data using the contract receipt information and submit this verification information to the main chain network 100. The main chain network 100 can then use the verification information to verify the correctness of the business data in the secondary chain network 200.

[0131] It is understood that in this embodiment, the secondary chain network can be Chang'an Chain (a public blockchain platform based on encrypted communication). Each blockchain node in the secondary chain network 200 can deploy a node database and an EVM (a virtual machine used to execute smart contracts). The EVM can be used to call smart contracts to execute instructions corresponding to business data, thereby completing the business operations or instructions required by the business data. Here, a smart contract is a piece of code with business logic that describes the business processing flow. Contract receipt information can refer to EVM receipts, including data generated when the EVM calls the smart contract to execute instructions corresponding to business data; the process of generating EVM receipts is the trace process.

[0132] This application embodiment can generate snapshot data using read set data and the corresponding block metadata of business data. Based on the snapshot data, the execution environment of the business data during execution can be restored, resulting in a restored EVM receipt. Since one piece of business data can correspond to one piece of read set data, it avoids the need to re-execute the instructions corresponding to the business data using periodically stored block backup data. Periodically stored block backup data involves multiple pieces of business data, and re-executing multiple pieces of business data involves complex calculation sequences and logic, leading to low re-execution efficiency. Snapshot data, on the other hand, can efficiently re-execute the instructions corresponding to the business data to obtain an EVM receipt, significantly improving the efficiency of EVM receipt generation. Verification information is generated from the EVM receipt and sent to the main chain network. This verification information can be used to verify the correctness of the business data execution process. The main chain network can verify the correctness of the business data using this verification information, thereby improving the security of business data processing in a blockchain network architecture that includes secondary chain networks and the main chain network.

[0133] 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 based on a blockchain network can be executed by blockchain nodes, which can be, for example,... Figure 1 Any blockchain node in the secondary chain network 200 shown can be, for example, blockchain node 20a. The following explanation will use the example of this data processing method being executed by a blockchain node. This data processing method based on the blockchain network will at least include the following steps S101-S110:

[0134] Step S101: Obtain the receipt generation request;

[0135] Specifically, the blockchain network can be structured as a scalable architecture (two-layer architecture), with a complementary and collaborative relationship between the main chain network and the secondary chain network. The secondary chain network can serve as an extension of the main chain network, with the main chain network acting as Layer 1 and the secondary chain network as Layer 2. The main chain network acts as the settlement layer, while the secondary chain network acts as the execution layer. The secondary chain network assists the main chain network in executing instructions corresponding to business data, and the main chain network verifies the correctness of business data that has been executed and uploaded to the chain in the secondary chain network. The secondary chain network can also function as a scaling component for the main chain network, with all business data and execution processes completed within it, thus reducing the storage and operational burden on the main chain network.

[0136] For example, blockchain nodes in a secondary blockchain network can process business data on-chain. Business data can refer to transaction tasks that have already undergone on-chain processing, such as transfer tasks executed on the blockchain network. Blockchain nodes in the secondary blockchain network can package the business data into business blocks. These blocks can then execute the instructions corresponding to the business data, obtaining the execution result data. The business blocks and execution result data are broadcast among the various blockchain nodes in the secondary blockchain network. Other blockchain nodes can verify the execution result data based on the business blocks and their deployed node databases, thereby generating voting information for the business blocks. This voting information is generated based on the business blocks and execution result data.

[0137] Blockchain nodes can obtain voting information from other blockchain nodes in the secondary blockchain network regarding business blocks. Based on this voting information, consensus processing of business blocks is performed within the secondary blockchain network. This application embodiment does not limit the voting method, the method for determining the voting result, or the number of voting rounds. For example, consensus can be determined only when the voting information of a majority of blockchain nodes in the secondary blockchain network has been collected.

[0138] Upon consensus, the business block containing business data is stored in the secondary chain network. In this embodiment, business clients can upload massive amounts of business data to the secondary chain network, reducing the storage burden and computational costs on the main chain network and improving the execution efficiency of business data on the main chain network.

[0139] After detecting that the business data has been processed on the blockchain in the secondary chain network, or after a certain aggregation period, the business client can generate a receipt generation request for the business data, and the blockchain node can obtain the receipt generation request sent by the business client.

[0140] Step S102: Obtain the data identifier from the receipt generation request;

[0141] Specifically, the business client can also be a blockchain node. The receipt generation request can include the data identifier (TxId) of the business data. The blockchain node can deploy a node database, which can include a block database for storing blocks and business data, and a state database for storing state data. The node database can be LevelDB (a hierarchical database with ordered mapping key-value pairs), BadgerDB (a tree-structured key-value pair database), or SQLDB (Structured Query Language Database, a database based on a query language). This embodiment of the application does not impose any limitations. The state database can store a state tree, which contains resource data corresponding to multiple account addresses. The account address and its associated resource data can be referred to as state data.

[0142] Step S103: Query the node database using the data identifier;

[0143] Step S104: Does the business data exist?

[0144] Step S105: Obtain the read set data corresponding to the business data;

[0145] Specifically, blockchain nodes can query on-chain data in the block database using the data identifier (TxId) in the receipt generation request. On-chain data can include read set data, write set data, and execution result data corresponding to the business data. Read set data can include the state data required to execute the instructions corresponding to the business data during the on-chain process; that is, the state data read from the node database before executing the instructions, such as the resource values ​​in each account before the transfer in a transfer task. Write set data can include the state data changed by the instructions corresponding to the business data during the on-chain process; that is, the state data generated after executing the instructions. Write set data can represent the data written to the execution environment during the execution of the business data. Execution result data can refer to the execution result produced by calling the smart contract to execute the instructions corresponding to the business data. For example, if a smart contract performs addition, with two addends as input and the sum as output, then the output sum of the smart contract is the execution result data.

[0146] To facilitate understanding, let's take the example of business data instructing a first account (from) to transfer digital resources with a business resource value (asset) to a second account (to). A blockchain node can query its local ledger to find the first resource value (fromAsset) of the digital resources in the first account and the second resource value (toAsset) of the digital resources in the second account. It sets the first resource value to the difference between fromAsset and the asset, and sets the second resource value to the sum of toAsset and the asset, returning the execution result of the business data. Therefore, the status data in the read set can include the first resource value (fromAsset) of the digital resources in the first account and the second resource value (toAsset) of the digital resources in the second account.

[0147] If the on-chain data in the node database includes the business data corresponding to the data identifier, then the read set data corresponding to the business data can be obtained from the node database through the data identifier; if the on-chain data in the node database does not include the business data corresponding to the data identifier, then an error message is returned, indicating to the business client that the business data corresponding to the data identifier does not exist.

[0148] As can be understood, this application embodiment obtains read set data by recording the status data read when executing instructions corresponding to the business data during the process of uploading business data to the blockchain. Storing the read set data in the node database ensures the immutability of the read set data. Querying through the data identifier corresponding to the business data allows for quick and convenient retrieval of the read set data. Furthermore, each blockchain node can deploy a node database, achieving decentralized storage of the read set data and improving its security.

[0149] Step S106: Generate snapshot data;

[0150] For details, please see Figure 4 , Figure 4 This application provides an example of a data processing scenario based on a blockchain network. Figure 3 .like Figure 4 As shown, the read set data can include several read instructions (ReadSet). If the business data is a transaction task, then the read instruction can represent a specific transaction read operation. For example, the read set data can include read instruction 1, read instruction 2, and read instruction 3. Each read instruction can read state data, such as reading state data from the parent block corresponding to the business data. State data can include key-value pairs, which can include a data key and a data value. Blockchain nodes can construct a snapshot data structure and obtain the state data required by each read instruction through an external interface (API, Application Programming Interface). For example, the data key required by the read instruction can be obtained through the GetByKey interface. In the business block containing the business data (i.e., the block where the business data is located), the blockchain node can obtain the block metadata corresponding to the business data through interfaces such as GetBlockHeight, GetTimeStamp, and GetProposer. The block metadata can include block height, timestamp, and proposer. The snapshot data structure can be viewed as a flat key-value store that contains the data of the storage slots corresponding to all read commands.

[0151] Blockchain nodes can obtain the state data corresponding to each read instruction in the read set data. For example, this could include data key 1 and data value 1 for read instruction 1, data key 2 and data value 2 for read instruction 2, and data key 3 and data value 3 for read instruction 3. Blockchain nodes can also obtain business blocks containing business data and their corresponding block metadata. For instance, if the execution order of read instruction 1 precedes that of read instruction 2, and the execution order of read instruction 2 precedes that of read instruction 3, then the aforementioned data keys and data values ​​are all state data. Blockchain nodes can then sequentially fill the state data and block metadata into the snapshot data structure according to the execution order of the read instructions in the read set data, obtaining snapshot data used to reconstruct the state data required before executing the instructions corresponding to the business data.

[0152] Step S107: Re-execute the instruction corresponding to the business data;

[0153] Specifically, blockchain nodes can use snapshot data as the execution environment for business data. Based on the snapshot data, they can call smart contracts to re-execute the instructions corresponding to the business data. For example, they can obtain the account address associated with the business data and the corresponding resource data from the snapshot data. Based on the account address associated with the business data and the corresponding resource data, they can re-execute the instructions corresponding to the business data, record the data generated by the smart contract, and obtain the business receipt data (TraceInfo). The business receipt data includes the data generated during the re-execution of the business data, that is, the data generated by each step (or instruction) of the smart contract execution. The business receipt data can include detailed data generated after the business data calls the smart contract for re-execution, which can be used to locate the execution process and state changes of the business data, providing traceability for the execution of the business data.

[0154] Snapshot data can be understood as representing the execution environment of business data during execution. Based on snapshot data, smart contracts can be efficiently and correctly invoked to re-execute the instructions corresponding to the business data. Since one piece of business data can correspond to one set of reads, it avoids the need to periodically store block backup data to re-execute the instructions corresponding to the business data. Periodically stored block backup data involves multiple pieces of business data, and re-executing multiple pieces of business data involves complex calculation sequences and logic, resulting in low re-execution efficiency. Snapshot data, on the other hand, can efficiently re-execute the instructions corresponding to the business data, significantly improving the efficiency of re-execution. When a smart contract needs to obtain information such as the height and timestamp of the block where the business data was executed, it can restore the block height, timestamp, and other metadata from the snapshot data, ensuring that the functionalities in the smart contract can execute normally.

[0155] For example, a smart contract can include N instructions. Business receipt data can include verification write set data, verification result data, and instruction execution logs generated by re-executing the instructions corresponding to the business data based on snapshot data. The verification write set data is the write set data generated by re-executing the instructions corresponding to the business data, and the verification result data is the result data obtained after re-executing the instructions corresponding to the business data. The instruction execution log can include data generated by each instruction when re-executing the instructions corresponding to the business data through N instructions, where N instructions refer to the instructions obtained by calling the smart contract from the business data. For example, the instruction execution log can include event information such as the depth of the call stack of a certain instruction in the smart contract executing the instructions corresponding to the business data, and the service value (such as transaction fees) required to execute a certain instruction in the business data.

[0156] It is understandable that the read set data is the data read during the execution of business data. Therefore, by simply constructing a snapshot data from the read set data and block metadata of the business data, and using the snapshot data as the execution environment for the business data, the business data can be executed again from the beginning, and the execution result will be completely consistent with the previous one.

[0157] Step S108: Does the consistency check pass?

[0158] Specifically, blockchain nodes can verify the consistency of business receipt data using the read set data, write set data, and execution result data corresponding to the business data stored in the node database. The read set data, write set data, and execution result data are the data generated during the execution of the instructions corresponding to the business data during the on-chain process. If the read set data is the same as the verified read set data, the write set data is the same as the verified write set data, and the execution result data is the same as the verified result data, then the blockchain node can determine that the business receipt information has passed the consistency verification. Passing the consistency verification means that the data generated during the on-chain processing by executing the instructions corresponding to the business data and the data generated by re-executing the instructions corresponding to the business data are identical.

[0159] Step S109: Perform a hash operation;

[0160] Step S110: Obtain contract receipt information.

[0161] Specifically, after the consistency verification is successful, the blockchain node can perform a hash operation on the business receipt data to obtain the business hash value. This business hash value and the business receipt data are then used to define the contract receipt information. The contract receipt information includes data generated from re-executing the instructions corresponding to the business data.

[0162] It is understandable that blockchain nodes in a secondary blockchain network can deploy a node database and an EVM (a virtual machine used to execute smart contracts). The EVM can be used to call smart contracts to execute instructions corresponding to business data, thereby completing the business operations or instructions required by the business data. Here, a smart contract is a piece of code with business logic that describes the business processing flow. Contract receipt information can refer to EVM receipts, including data generated when the EVM calls the smart contract to execute instructions corresponding to business data; the process of generating EVM receipts is the trace process.

[0163] In this embodiment, contract receipt information can be used to characterize the re-execution process of business data. It can include a business hash value and business receipt data. The business hash value can be used for status detection, and the business receipt data provides traceability for the execution of the business data. Therefore, contract receipt information can be used to verify the correctness of business data and determine whether the business data has been successfully executed, thereby ensuring the security and correctness of the business data.

[0164] Blockchain nodes can send the generated contract receipt information to business clients. Business clients can use the contract receipt information to generate verification information for their business data and submit this verification information to the main chain network. The main chain network can then use this verification information to verify the correctness of the business data in the secondary chain network.

[0165] This application embodiment records the state data read during the execution of instructions corresponding to business data during the on-chain process of business data, obtaining read set data. When a receipt generation request for business data is received, the read set data corresponding to the business data stored in the node database can be obtained through the receipt generation request. Snapshot data is generated using the read set data and the corresponding block metadata of the business data. The snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the instructions corresponding to the business data can be efficiently re-executed to obtain contract receipt information. The contract receipt information can be used to characterize the execution process of the business data and has traceability and transparency. Verification information for the business data is generated using the contract receipt information, which can be used to verify the correctness of the execution process of the business data. Therefore, the verification information is submitted to the main chain network. The main chain network can verify the execution process of the business data using the obtained verification information, thereby determining the correctness of the business data. This avoids the main chain network incorrectly recognizing abnormal data already on-chain in the secondary chain network, providing the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chains, this improves the security of business data processing.

[0166] Please see Figure 5 , Figure 5 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 2 This data processing method based on a blockchain network can be executed by a business client, which can be, for example,... Figure 1 The business client 300 in the secondary chain network 200 shown below. The following explanation will use the execution of this data processing method by a resource client as an example. This data processing method based on the blockchain network may include at least the following steps S201-S206:

[0167] Step S201: Send a receipt generation request;

[0168] Specifically, a blockchain network includes a main chain network and secondary chain networks. The secondary chain network can serve as an extension of the main chain network, with the main chain network acting as Layer 1 and the secondary chain network as Layer 2. The secondary chain network assists the main chain network in executing instructions corresponding to business data. Blockchain nodes in the secondary chain network can process business data on-chain within the secondary chain network. The secondary chain network comprises M blockchain nodes and a business client, which can be a lightweight node.

[0169] After detecting that the business data has been processed on the secondary chain network, or after a certain aggregation period, the business client can send a receipt generation request for the business data to M blockchain nodes. The M blockchain nodes can be selected and determined by the business client in the secondary chain network. The process can be as follows: obtain the node fault tolerance value f; f is a positive integer; determine the consensus node value M based on the node fault tolerance value f; M is a positive integer greater than f; select M blockchain nodes from the T candidate nodes based on the consensus node value M and the quality scores corresponding to the T candidate nodes; T is a positive integer, T is greater than or equal to M; the T candidate nodes belong to the secondary chain network.

[0170] Specifically, the business client can obtain a pre-set node fault tolerance value f. This value f represents the number of malicious nodes that can be allowed in the secondary chain network. The node fault tolerance value f can be determined based on Byzantine Fault Tolerance (BFT). The business client can determine the consensus node value M based on the node fault tolerance value f, where M is a positive integer greater than f. For example, the consensus node value M can be greater than or equal to 3f+1.

[0171] The business client can obtain the quality scores (such as credit scores) corresponding to T candidate nodes. These quality scores are calculated based on the consensus processing performance of the candidate nodes and represent their trustworthiness and reliability. The business client can then select M blockchain nodes from the T candidate nodes, ranked from highest to lowest quality score, based on the consensus node value M and the corresponding quality scores of the T candidate nodes. The T candidate nodes belong to a sub-chain network.

[0172] The M blockchain nodes can include blockchain node 1, ..., blockchain node n. For example, blockchain node 1 can specifically be one of the above... Figure 1 In the corresponding embodiment, blockchain node 20a and blockchain node n can specifically be as described above. Figure 1In the corresponding embodiment, blockchain nodes 20n and M can, upon receiving a receipt generation request, retrieve the read set data corresponding to the business data from the deployed node database based on the receipt generation request. The read set data may include the state data required to execute the instructions corresponding to the business data during the on-chain process, i.e., the state data read before executing the instructions corresponding to the business data during the on-chain process.

[0173] For ease of understanding, let's take blockchain node 20a as an example. Blockchain node 20a can construct snapshot data from the read set data and the corresponding block metadata of the business data. Based on the snapshot data, it re-executes the instructions corresponding to the business data to obtain contract receipt information. Blockchain node 20a can then send the generated contract receipt information to the business client. The method for generating contract receipt information can be found above. Figure 3 The specific descriptions of steps S101 to S110 in the corresponding embodiments will not be repeated here.

[0174] It's understandable that the node fault tolerance value can be determined based on the BFT consensus mechanism. Through the BFT consensus mechanism, when the business client determines that the contract receipt information of most blockchain nodes is consistent, it can assume that the majority of consistent contract receipt information is accurate, thus obtaining the verified contract receipt information. Simultaneously, while ensuring that the system can still determine accurate verified contract receipt information even when the proportion of malicious nodes is small, it improves detection efficiency.

[0175] In this embodiment, the secondary chain network can be Chang'an Chain. Each blockchain node in the secondary chain network can deploy a node database and an EVM. The EVM can be used to call smart contracts to execute instructions corresponding to business data, thereby completing the business operations or instructions required by the business data. Here, a smart contract is a piece of code with business logic that describes the business processing flow. Contract receipt information can refer to EVM receipts, including receipt information generated when the EVM calls the smart contract to execute instructions corresponding to business data. The process of generating EVM receipts is the trace process.

[0176] EVM receipts can be presented to the business client as a JSON data structure. Taking N instructions in a smart contract, including instruction 1, as an example, Table 1 shows part of the content of the JSON data structure of an EVM receipt. An EVM receipt can also include the above... Figure 3 The business receipt data and business hash value corresponding to the example are as follows:

[0177] Table 1

[0178]

[0179] The EVM receipt may include the execution status, total service cost (gas), return value, and instruction execution log. For example, the execution status can be set to `failed: false` to indicate successful execution; the total service cost can represent the total amount of work required to execute the smart contract; and the return value can be the actual service cost incurred in executing the smart contract. The instruction execution log may include log information for instruction 1, such as the stack depth of instruction 1 being 1 and the unit service cost (gasCost) of instruction 1 being 3.

[0180] The JSON data structure corresponding to instruction 1 can also be represented as {"depth":1, "gasCost":3, "op":"GET", "key":"to", "data":"1000"}. Here, "depth":1 indicates the stack depth of instruction 1 is 1; "gasCost":3 indicates the actual service cost (e.g., transaction fee) incurred in executing instruction 1; "op":"GET" indicates the instruction type of instruction 1; "key":"to" indicates the key value of the operation performed by instruction 1, such as the "to" account; and "data":"1000" indicates the data involved in instruction 1, such as the resource value of the "to" account.

[0181] Step S202: Obtain contract receipt information;

[0182] Step S203: Are the contract receipt information the same?

[0183] Specifically, the business client can obtain contract receipt information returned by each blockchain node. A status check is performed on each of the M contract receipts. For example, the business client can compare the business hash value in each contract receipt with the root hash value of the Merkle tree of the block containing the business data. If the business hash value is the same as the root hash value of the Merkle tree, then the contract receipt has passed the status check. For details regarding the business hash value, please refer to the above. Figure 3 The specific description of step S110 in the corresponding embodiment is not limited here. By using state detection, this embodiment can directly exclude contract receipt information generated by malicious nodes, ensuring that the business hash value generated during the re-execution process is the same as the root hash value of the Merkle tree generated during the on-chain process, thereby improving the security of the re-execution process.

[0184] The business client can identify P contract receipts that pass status checks as P verified receipts. The business client can then verify these P verified receipts by comparing whether they are identical.

[0185] Step S204: Select a new blockchain node;

[0186] Specifically, if there are different verified receipts among the P verified receipts, or if P is less than the verification threshold, the business client can generate an update node value Q based on the consensus node value M. Here, Q is greater than M and less than or equal to T. The verification threshold can be a pre-set value, such as a positive integer greater than or equal to f+1. By using the verification threshold, this embodiment can directly determine the verification of contract receipts when a certain number of identical contract receipts are obtained, without waiting for all blockchain nodes to generate corresponding contract receipts, thus improving the detection efficiency of contract receipts.

[0187] The business client can reselect Q blockchain nodes from T candidate nodes based on the updated node value Q. These Q blockchain nodes may or may not include any of the previously selected M blockchain nodes. For example, the business client can update the quality scores of the M blockchain nodes based on the verification results (such as the status detection results mentioned above) corresponding to the business receipt information returned by the M blockchain nodes. Then, based on the updated quality scores of the T candidate nodes, the business client can select Q blockchain nodes from the T candidate nodes. For instance, if the contract receipt information generated by a blockchain node fails the status detection, the business client can lower the quality score of that blockchain node to obtain more blockchain nodes, i.e., Q blockchain nodes.

[0188] The business client can send receipt generation requests for business data to Q blockchain nodes, obtain contract receipt information sent by each of the Q blockchain nodes, perform status checks on each of the Q contract receipt information, and determine the C contract receipt information that passes the status check as C verified receipt information; C is a positive integer less than or equal to Q. The detection content of the business client on the Q blockchain nodes can be the same as the detection content of the M blockchain nodes in step S203 above, and will not be repeated here in this embodiment.

[0189] Step S205: Confirm the contract confirmation information;

[0190] Specifically, if all verified receipts are identical, and the number of verified receipts is greater than or equal to the verification threshold, the business client can identify any one of the verified receipts as the contract verification receipt. Optionally, when the number of identical verified receipts is f+1, the business client can identify any one of the f+1 verified receipts as the contract verification receipt.

[0191] It is understood that in this application embodiment, the verification contract receipt information is determined from the verified receipt information that has passed the status detection. When the verification contract receipt information cannot be determined, the business client can re-determine the blockchain node to generate the contract receipt information, thereby ensuring the accuracy of the verification contract receipt information determined by the business client and improving the security of the contract receipt information.

[0192] Step S206: Generate verification information.

[0193] Specifically, business clients can generate verification information for business data using M contract receipt messages. This verification information instructs the main chain network to perform state verification on the business data in the secondary chain network. For example, the verification information could be zero-knowledge proof (ZKP). A zero-knowledge proof is a cryptographic protocol that allows one party to prove a statement to another party is true without providing any information other than the truth of the statement. In other words, a zero-knowledge proof allows a prover to prove a statement to a verifier without revealing any additional information.

[0194] In this embodiment, the prover in the zero-knowledge proof can be a secondary chain network, and the verifier can be a main chain network. The business client can generate zero-knowledge proof information for the verification contract receipt information, and determine this zero-knowledge proof information as verification information for business data. The process can be as follows: encoding the verification contract receipt information to obtain an encoded value; constructing an encoded polynomial based on the encoded value; the coefficients of the encoded polynomial are determined based on the encoded value; randomly generating a verification polynomial; generating a commitment polynomial based on the encoded polynomial and the verification polynomial; generating a Merkle tree based on the solution set of the commitment polynomial; the Merkle tree includes S leaf nodes, where S is a positive integer, and the S leaf nodes indicate the solution set of the commitment polynomial; performing a hash operation on the root hash value of the Merkle tree to obtain the verification value; and determining the verification polynomial, the commitment polynomial, and the verification value as the zero-knowledge proof information.

[0195] Specifically, zero-knowledge proofs can include interactive zero-knowledge proofs and non-interactive zero-knowledge proofs. In interactive zero-knowledge proofs, there are multiple rounds of interaction between the prover and the verifier. The prover proves the truth of their statement through a series of challenges and responses. In non-interactive zero-knowledge proofs, the prover generates a one-time proof, which the verifier can verify independently.

[0196] For ease of understanding, a non-interactive zero-knowledge proof is used as an example. The business client encodes the verification contract receipt information to obtain an encoded value. An encoding polynomial P(X) is constructed based on this encoded value. The business client can also add a random value of a certain length to the encoded value when constructing the polynomial P(X). The coefficients of the encoding polynomial P(X) are determined based on the encoded value. One coefficient in the encoding polynomial can represent a single bit of the encoded value. For example, the encoding polynomial P(X) = 3x^3 + 5x^2 + 1 can represent the encoded value 351. The encoded value can also be a binary value; this embodiment does not impose any limitations on this.

[0197] Optionally, the encoded value can also be a series of coordinate values, such as (1, x1), (5, x2), (3, x1). The business client can add a certain number of random points (e.g., 10) to the encoded value and construct the encoded polynomial P(X) by interpolation. This application embodiment does not impose any limitations here.

[0198] The business client can randomly generate a verification polynomial based on a zero-knowledge proof protocol. This protocol can be associated with a zero-knowledge proof verification contract deployed on the mainnet. The verification polynomial can include a first verification polynomial C(X) and a second verification polynomial D(X). The unknowns in the second verification polynomial D(X) can be determined based on the length of the encoded value, and the unknowns in the first verification polynomial C(X) can be determined based on the length of the added random number. For example, if the length of the encoded value is 10^6 and the length of the added random number is 10, then the first verification polynomial C(X) can be expressed as C(X) = (X-1)(X-2)...(X-10), and the second verification polynomial D(X) can be expressed as (X-1)(X-2)...(X-10^6). The first verification polynomial C(X) is associated with a random value of a certain length added by the business client, and the second verification polynomial D(X) is associated with the encoded value.

[0199] The business client can generate a commitment polynomial C'(X) based on the encoding polynomial and the verification polynomial, where C'(X) satisfies C'(P(X)) = D(X)C'(X). For the commitment polynomial C'(X), the business client can compute its solution set in the domain defined in the aforementioned zero-knowledge proof protocol, and generate a Merkle tree based on the solution set of the commitment polynomial C'(X). The Merkle tree includes S leaf nodes, where S is a positive integer, and the S leaf nodes indicate the solution set of the commitment polynomial. The business client can use the Collision-ResistantHash (CRH) function disclosed in the aforementioned zero-knowledge proof protocol to hash the root hash value of the Merkle tree to obtain a verification value, which can represent a verification path in the Merkle tree. The verification value, the first verification polynomial C(X), the second verification polynomial D(X), and the commitment polynomial C'(X) are determined as zero-knowledge proof information.

[0200] Business clients can send verification information and the state root of business data to the main chain network. The state root can be the root hash value of the state tree of the block containing the business data, indicating the execution result of the business data. The main chain network can invoke a zero-knowledge proof verification contract using zero-knowledge proof information. Based on the zero-knowledge proof verification contract, it verifies the verification polynomial and the commitment polynomial using verification values. After both the verification polynomial and the commitment polynomial in the verification information pass verification, the main chain network can add the state root to the chain. The state root already added to the main blockchain network indicates that the business data already added to the secondary chain network is in a correctness verification passed state.

[0201] The main chain network can verify the execution process of business data through verification information, thereby determining the correctness of the business data. This avoids the main chain network incorrectly recognizing abnormal data already on the secondary chain network, providing a solution for the main chain network to verify the correctness of the business data execution process. When the verification information is zero-knowledge proof information, the secondary chain network does not need to submit any data related to the execution process of the business data (such as read data, contract receipt information, etc.) to the main chain network, ensuring the privacy and security of data related to the execution process of the business data (such as account balance, account address, etc.). Furthermore, the secondary chain network does not need to verify the complete contract receipt information to verify the correctness of the business data. The zero-knowledge proof information can be automatically verified through associated zero-knowledge proof smart contracts, eliminating the need for the main chain network to perform complex verification and calculations, as well as verifying the specific content of the contract receipt information, thus reducing the computational cost of the main chain network. This reduces the computational and communication costs of the verification process. Additionally, the small data volume of the zero-knowledge proof information allows for deletion after verification, reducing the storage costs of the main chain network.

[0202] This application embodiment avoids malicious nodes tampering with the contract receipt information corresponding to business data by sending receipt generation requests to multiple blockchain nodes. Each blockchain node's deployed node database stores the state data read during the execution of instructions corresponding to the business data on-chain, resulting in read set data. Upon receiving a receipt generation request for business data, each blockchain node can obtain the read set data corresponding to the business data stored in its node database, as well as the block metadata corresponding to the business data, to generate snapshot data. Snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the instructions corresponding to the business data can be efficiently re-executed to obtain contract receipt information. This contract receipt information can characterize the execution process of the business data and is traceable and transparent. Verification information for the business data is generated from the contract receipt information, which can be used to verify the correctness of the business data's execution process. Therefore, submitting verification information to the main chain network allows the main chain network to verify the execution process of business data using the obtained verification information, thereby determining the correctness of the business data. This can prevent abnormal data already uploaded to the secondary chain network from being incorrectly recognized by the main chain network, and provides the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chain networks, this can improve the security of business data processing.

[0203] On the other hand, the verification information in this application embodiment can be zero-knowledge proof information. Through zero-knowledge proof information, the secondary chain network can verify the correctness of business data without disclosing the specific content of the contract receipt information to the main chain network, which can greatly improve the security and privacy of business data. Furthermore, zero-knowledge proof information can be automatically invoked by associated zero-knowledge proof smart contracts for lightweight verification, eliminating the need for complex verification and calculations by the main chain network, and also eliminating the need to verify the specific content of each step instruction in the smart contract, thus reducing the computational cost of the main chain network. Simultaneously, the data volume of zero-knowledge proof information is small, and it can be deleted after verification, reducing the storage cost of the main chain network.

[0204] Please see Figure 6 , Figure 6 This is a flowchart illustrating a data processing method based on a blockchain network provided in an embodiment of this application. Figure 3 This data processing method based on a blockchain network can be executed by blockchain nodes, which can be, for example,... Figure 1Any blockchain node in the secondary chain network 200 shown can be, for example, blockchain node 20a. The following explanation will use the example of this data processing method being executed by a blockchain node. This data processing method based on the blockchain network will at least include the following steps S301-S311:

[0205] Step S301: Query the node database using the data identifier;

[0206] Step S302: Obtain the read set data;

[0207] For details, please refer to the above. Figure 3 The specific descriptions of steps S102 to S105 in the corresponding embodiments will not be repeated here.

[0208] Step S303: Initialize i = 0 and construct the snapshot data structure;

[0209] Step S304: Obtain the read command;

[0210] Specifically, a blockchain node can initialize the traversal value `i` by assigning it the value 0, constructing a snapshot data structure. This snapshot data structure can be viewed as a flat key-value store containing data for the storage slots corresponding to all read instructions. The blockchain node can retrieve the read instructions from the read set data based on their execution order. For example, the read set data includes read instruction 1, read instruction 2, and read instruction 3. Read instruction 1 can be executed before read instruction 2, and read instruction 2 can be executed before read instruction 3. The blockchain node can first retrieve the first executed read instruction, i = 1, when the traversal value `i` = 1. For example, if the business data is a transaction task, then the read instruction can represent a specific transaction read operation.

[0211] Step S305: Parse the status data in the read instruction;

[0212] Step S306: Set the status data to the snapshot data structure;

[0213] Step S307, i++;

[0214] Step S308, i>=len;

[0215] Specifically, each read command can read state data, which may include key-value pairs. Blockchain nodes can parse read commands to obtain the state data required for each command and then set this state data into the snapshot data structure. For details on setting state data into the snapshot data structure, please refer to the above. Figure 3The specific description of step S106 in the corresponding embodiment will not be repeated here. After setting the status data corresponding to read instruction 1 to the snapshot data structure, the blockchain node can increment the traversal value i by 1, and the new traversal value i can be 1. The blockchain node can obtain the length of the read instructions in the read set data, i.e., the number of read instructions, by taking the length function len(TxReadSet), and set the length of the read instructions to the parameter len. The blockchain node can determine the relationship between the traversal value i and the parameter len to determine whether the read instructions in the read set data have been traversed. If i is less than len, the blockchain node can continue to obtain the next read instruction and set the status data of the read instruction to the snapshot data structure. For example, when i = 1, the blockchain node can obtain read instruction 2 and set the status data of read instruction 2 to the snapshot data structure. If i is greater than or equal to len, it means that the blockchain node has traversed all the instructions in the read set data.

[0216] Step S309: Obtain block metadata;

[0217] Step S310: Set the block metadata into the snapshot data structure;

[0218] Step S311: Obtain snapshot data.

[0219] Specifically, after traversing all read instructions in the read set, a blockchain node can retrieve the block metadata corresponding to the business data from the node database or external interface. This block metadata is essentially the block metadata of the block containing the business data. Block metadata can include block height, timestamp, proposer, etc. The blockchain node can then set the block metadata into a snapshot data structure to obtain snapshot data.

[0220] This application embodiment records the state data read during the execution of instructions corresponding to business data during the on-chain process of business data, obtaining read set data. When a receipt generation request for business data is received, the read set data corresponding to the business data stored in the node database can be obtained through the receipt generation request. Snapshot data is generated using the read set data and the corresponding block metadata of the business data. The snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the instructions corresponding to the business data can be efficiently re-executed to obtain contract receipt information. The contract receipt information can be used to characterize the execution process of the business data and has traceability and transparency. Verification information for the business data is generated using the contract receipt information, which can be used to verify the correctness of the execution process of the business data. Therefore, the verification information is submitted to the main chain network. The main chain network can verify the execution process of the business data using the obtained verification information, thereby determining the correctness of the business data. This avoids the main chain network incorrectly recognizing abnormal data already on-chain in the secondary chain network, providing the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chains, this improves the security of business data processing. On the other hand, since one piece of business data can correspond to one set of read data, it avoids the need to re-execute the instructions corresponding to the business data using periodically stored block backup data. This is because periodically stored block backup data involves multiple pieces of business data, and re-executing multiple pieces of business data involves complex calculation sequences and logic, leading to low re-execution efficiency. However, snapshot data can efficiently re-execute the instructions corresponding to the business data to obtain contract receipt information, greatly improving the efficiency of contract receipt information. Verification information is generated from the contract receipt information and sent to the main chain network. This verification information can be used to verify the correctness of the business data execution process. The main chain network can verify the correctness of the contract receipt information through the verification information, thus improving the security of business data processing in a blockchain network architecture that includes secondary chain networks and the main chain network.

[0221] Please see Figure 7 , Figure 7 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 1 A blockchain network includes a main chain network and a secondary chain network. Data processing devices are used in the blockchain nodes of the secondary chain network; for example... Figure 7 As shown, the data processing device 1 includes a receipt generation request acquisition module 710, a read set data acquisition module 720, a snapshot data generation module 730, and a receipt information generation module 740.

[0222] The receipt generation request acquisition module 710 is used to acquire receipt generation requests for business data; the business data is data that has already undergone the on-chain process in the secondary chain network.

[0223] The read set data acquisition module 720 is used to acquire the read set data corresponding to the business data based on the receipt generation request; the read set data includes the status data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0224] The snapshot data generation module 730 is used to generate snapshot data based on the block metadata corresponding to the read set data and the business data.

[0225] The receipt information generation module 740 is used to re-execute the instructions corresponding to the business data based on the snapshot data to obtain contract receipt information. The contract receipt information includes the data generated by re-executing the instructions corresponding to the business data. The contract receipt information is used to generate verification information for the business data. The verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

[0226] In one possible implementation, when the read set data acquisition module 720 retrieves the read set data corresponding to the business data from the node database based on the receipt generation request, it specifically performs the following operations:

[0227] The on-chain data in the node database is queried using the data identifier in the receipt generation request;

[0228] If the on-chain data in the node database includes business data corresponding to the data identifier, then the read set data corresponding to the business data can be obtained from the node database through the data identifier.

[0229] If the on-chain data in the node database does not include the business data corresponding to the data identifier, an error message will be returned.

[0230] In one possible implementation, when the snapshot data generation module 730 generates snapshot data based on the block metadata corresponding to the read set data and the business data, it specifically performs the following operations:

[0231] Construct a snapshot data structure, obtain the status data corresponding to each read instruction in the read set data, obtain the business block containing business data, obtain the block metadata corresponding to the business block, and fill the status data and block metadata into the snapshot data structure in the order of execution of the read instructions in the read set data to obtain the snapshot data.

[0232] In one possible implementation, the receipt information generation module 740 is used to re-execute the instructions corresponding to the business data based on the snapshot data. When obtaining the contract receipt information, it is specifically used to perform the following operations:

[0233] Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain the business receipt data of the business data; the business receipt data includes the data generated by re-executing the instructions corresponding to the business data.

[0234] The consistency of business receipt data is verified by using the read set data, write set data, and result data stored in the node database; both the write set data and the result data are associated with the business data.

[0235] After the consistency verification is passed, the business receipt data is hashed to obtain the business hash value;

[0236] The business hash value and business receipt data are identified as contract receipt information used to characterize the execution process of business data.

[0237] In one possible implementation, the receipt information generation module 740 is used to re-execute the instructions corresponding to the business data based on the snapshot data. When obtaining the business receipt data of the business data, it is specifically used to perform the following operations:

[0238] The snapshot data retrieves the account address associated with the business data and the resource data corresponding to the account address. Based on the account address associated with the business data and the resource data corresponding to the account address, the business data is re-executed to obtain the verification read set data, verification write set data, verification result data, and instruction execution log of the business data. The instruction execution log includes the data generated by re-executing the N instructions corresponding to the business data through N instructions, where N is a positive integer and N instructions refer to the instructions called by the business data.

[0239] Verification read set data, verification write set data, verification result data, and instruction execution log are identified as business receipt data.

[0240] In one possible implementation, the receipt generation request acquisition module 710 is also used to perform the following operations:

[0241] Package the business data to obtain business blocks;

[0242] Generate the execution results corresponding to the business blocks, and broadcast the business blocks and execution results in the secondary chain network;

[0243] Obtain voting information for business blocks within the secondary chain network; the voting information is generated based on business blocks and execution result data.

[0244] Consensus processing of business blocks is carried out in the secondary chain network based on voting information. When consensus is passed, the business block containing business data is stored in the secondary chain network.

[0245] This application embodiment records the state data read during the execution of business data during the on-chain process of business data, obtaining read set data. When a receipt generation request for business data is received, the read set data corresponding to the business data stored in the node database can be obtained through the receipt generation request. Snapshot data is generated using the read set data and the corresponding block metadata of the business data. The snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the business data can be efficiently re-executed to obtain contract receipt information. The contract receipt information can be used to characterize the execution process of the business data and has traceability and transparency. Verification information for the business data is generated using the contract receipt information, which can be used to verify the correctness of the execution process of the business data. Therefore, the verification information is submitted to the main chain network. The main chain network can verify the execution process of the business data using the obtained verification information, thereby determining the correctness of the business data. This avoids the main chain network incorrectly recognizing abnormal data already on-chain in the secondary chain network, providing the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chains, this improves the security of business data processing. On the other hand, since one piece of business data can correspond to one set of read data, it avoids the need to re-execute business data using periodically stored block backup data. Periodically stored block backup data involves multiple pieces of business data, and re-executing these multiple pieces of business data involves complex computational sequences and logic, leading to low re-execution efficiency. However, snapshot data allows for efficient re-execution of business data, obtaining contract receipt information, which significantly improves the efficiency of contract receipt information. Verification information is generated from the contract receipt information and sent to the main chain network. This verification information can be used to verify the correctness of the business data execution process. The main chain network can verify the correctness of the contract receipt information through this verification information, thereby improving the security of business data processing in a blockchain network architecture that includes secondary and main chain networks.

[0246] 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.

[0247] Please see Figure 8 , Figure 8 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 2A blockchain network includes a main chain network and a secondary chain network. Data processing devices are used in business clients within the secondary chain network; for example... Figure 8 As shown, the data processing device 2 includes a receipt information acquisition module 810 and a verification information generation module 820.

[0248] The receipt information acquisition module 810 is used to send receipt generation requests for business data to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database; M is a positive integer, the M blockchain nodes belong to the secondary chain network, and the business data is the data that has been executed on-chain in the secondary chain network; the contract receipt information is obtained by the blockchain nodes re-executing the business data based on snapshot data; the snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data; the read set data is generated during the on-chain process of the business data, and the read set data includes the state data required to execute the business data during the on-chain process;

[0249] The verification information generation module 820 is used to obtain contract receipt information sent by M blockchain nodes respectively, and generate verification information for business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of business data in the secondary chain network.

[0250] In one possible implementation, the receipt information acquisition module 810 is also used to perform the following operations:

[0251] Get the node's fault tolerance value f; f is a positive integer;

[0252] The consensus node value M is determined based on the node fault tolerance value f; M is a positive integer greater than f.

[0253] Based on the consensus node value M and the quality scores corresponding to the T candidate nodes, M blockchain nodes are selected from the T candidate nodes; T is a positive integer, T is greater than or equal to M; the T candidate nodes belong to the sub-chain network.

[0254] In one possible implementation, the verification information generation module 820 is used to obtain contract receipt information sent by M blockchain nodes respectively, and when generating verification information for business data based on the M contract receipt information, it is specifically used to perform the following operations:

[0255] Obtain contract receipt information sent by M blockchain nodes respectively, and determine the verification contract receipt information from the M contract receipt information;

[0256] Generate zero-knowledge proof information for verifying contract receipt information, and determine the zero-knowledge proof information as verification information for business data.

[0257] In one possible implementation, when generating verification information to determine the verification contract receipt information from M contract receipt information, it is specifically used to perform the following operations:

[0258] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0259] If all P verified receipts are identical, and P is greater than or equal to the verification threshold, then any one of the P verified receipts will be determined as the contract verification receipt.

[0260] In one possible implementation, the verification information generation module 820 is also used to perform the following operations:

[0261] If there are different verified receipts among the P verified receipts, or if P is less than the verification threshold, then an updated node value Q is generated based on the consensus node value M, and Q blockchain nodes are selected from T candidate nodes based on the updated node value Q; Q is greater than M and less than or equal to T.

[0262] Send receipt generation requests for business data to Q blockchain nodes, obtain contract receipt information sent by Q blockchain nodes respectively, perform status checks on Q contract receipt information respectively, and determine C contract receipt information that pass the status check as C verified receipt information; C is a positive integer less than or equal to Q.

[0263] If all C verified receipts are identical, and C is greater than or equal to the verification threshold, then any one of the C verified receipts will be determined as the contract verification receipt.

[0264] In one possible implementation, when determining the verification contract receipt information from M contract receipt information, the verification information generation module 820 is specifically used to perform the following operations:

[0265] Perform status checks on each of the M contract receipts, and determine the P contract receipts that pass the status check as the P verified receipts; P is a positive integer less than or equal to M.

[0266] Group the P verified receipts into B receipt groups; B is a positive integer; all verified receipts within a receipt group are identical.

[0267] The receipt information group with the largest number of verified receipt information among the B receipt information groups is determined as the verification receipt information group, and any one of the verified receipt information in the verification receipt information group is determined as the verification contract receipt information.

[0268] In one possible implementation, when the verification information generation module 820 generates zero-knowledge proof information for the verification contract receipt information, it specifically performs the following operations:

[0269] The verification contract receipt information is encoded to obtain encoded values, and an encoded polynomial is constructed based on the encoded values; the coefficients of the encoded polynomial are determined based on the encoded values.

[0270] A verification polynomial is randomly generated. A commitment polynomial is generated based on the encoding polynomial and the verification polynomial. A Merkle tree is generated based on the solution set of the commitment polynomial. The Merkle tree includes S leaf nodes, where S is a positive integer. The S leaf nodes are used to indicate the solution set of the commitment polynomial.

[0271] The root hash value of the Merkle tree is hashed to obtain the verification value. The verification polynomial, the commitment polynomial, and the verification value are then used as zero-knowledge proof information.

[0272] In one possible implementation, the verification information generation module 820 is also used to perform the following operations:

[0273] The state root of the verification information and business data is sent to the main chain network so that the main chain network can verify the verification polynomial and the commitment polynomial through the verification value. After the verification polynomial and the commitment polynomial in the verification information are verified, the state root is processed on the chain. The state root that has been on the chain in the main blockchain network is used to indicate that the business data that has been on the chain in the secondary chain network is in the correctness verification state.

[0274] This application embodiment avoids malicious nodes tampering with the contract receipt information corresponding to business data by sending receipt generation requests to multiple blockchain nodes. Each blockchain node's deployed node database stores and records the state data read during the execution of business data on-chain, resulting in read set data. Upon receiving a receipt generation request for business data, each blockchain node can obtain the read set data corresponding to the business data stored in its node database, as well as the block metadata corresponding to the business data, and generate snapshot data. Snapshot data represents the execution environment of the business data during execution. Based on the snapshot data, the business data can be efficiently re-executed to obtain contract receipt information. This contract receipt information can characterize the execution process of the business data and is traceable and transparent. Verification information for the business data is generated from the contract receipt information, which can be used to verify the correctness of the business data execution process. Therefore, submitting verification information to the main chain network allows the main chain network to verify the execution process of business data using the obtained verification information, thereby determining the correctness of the business data. This can prevent abnormal data already uploaded to the secondary chain network from being incorrectly recognized by the main chain network, and provides the main chain network with a solution to verify the correctness of the execution process of business data. In a blockchain network architecture that includes both secondary and main chain networks, this can improve the security of business data processing.

[0275] On the other hand, the verification information in this application embodiment can be zero-knowledge proof information. Through zero-knowledge proof information, the secondary chain network can verify the correctness of business data without disclosing the specific content of the contract receipt information to the main chain network, which can greatly improve the security and privacy of business data. Furthermore, zero-knowledge proof information can be automatically invoked by associated zero-knowledge proof smart contracts for lightweight verification, eliminating the need for complex verification and calculations by the main chain network, and also eliminating the need to verify the specific content of each step instruction in the smart contract, thus reducing the computational cost of the main chain network. Simultaneously, the data volume of zero-knowledge proof information is small, and it can be deleted after verification, reducing the storage cost of the main chain network.

[0276] 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.

[0277] Please see Figure 9 , Figure 9This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As 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 a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user 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 9 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

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

[0279] When the computer device 1000 is used to execute the data processing device 1, it achieves the following:

[0280] Obtain a receipt generation request for business data; the business data is data that has already undergone the on-chain process in the secondary chain network;

[0281] The read set data corresponding to the business data is obtained based on the receipt generation request; the read set data includes the status data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0282] Snapshot data is generated based on the block metadata corresponding to the read set data and the business data;

[0283] Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain contract receipt information. The contract receipt information includes the data generated by re-executing the instructions corresponding to the business data. The contract receipt information is used to generate verification information for the business data. The verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

[0284] When the computer device 1000 is used to execute the data processing device 2, it achieves the following:

[0285] Send receipt generation requests for business data to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database; M is a positive integer, the M blockchain nodes belong to the sub-chain network, and the business data is the data that has been executed on-chain in the sub-chain network; the contract receipt information is obtained by the blockchain nodes re-executing the instructions corresponding to the business data based on snapshot data; the snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data; the read set data is generated during the on-chain process of the business data, and includes the state data required to execute the instructions corresponding to the business data obtained during the on-chain process;

[0286] Obtain contract receipt information sent by M blockchain nodes respectively, and generate verification information for business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of business data in the secondary chain network.

[0287] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 5 and Figure 6 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.

[0288] Furthermore, it should be noted that this application embodiment also provides a computer storage medium, which stores a computer program. When the processor executes the computer program, it can execute the aforementioned... Figure 3 , Figure 5 and Figure 6 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 storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0289] The aforementioned computer 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 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 storage medium can include both internal and external storage units of the computer device. The computer storage medium is used to store the computer program and other programs and data required by the computer device. The computer storage medium can also be used to temporarily store data that has been displayed or will be displayed.

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

[0291] 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.

[0292] 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.

[0293] 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 a main chain network and a secondary chain network. The method is executed by blockchain nodes in the secondary chain network. The method includes: Obtain a receipt generation request for business data; the business data is data that has undergone the on-chain process in the secondary chain network. The read set data corresponding to the business data is obtained according to the receipt generation request; the read set data includes the status data required to execute the instruction corresponding to the business data obtained during the on-chain process; Snapshot data is generated based on the read set data and the block metadata corresponding to the business data; Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain contract receipt information; the contract receipt information includes data generated by re-executing the instructions corresponding to the business data, and the contract receipt information is used to generate verification information for the business data, and the verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

2. The method according to claim 1, characterized in that, The step of obtaining the read set data corresponding to the business data based on the receipt generation request includes: The on-chain data in the node database is queried using the data identifier in the receipt generation request; If the on-chain data in the node database includes the business data corresponding to the data identifier, then the read set data corresponding to the business data is obtained from the node database through the data identifier; If the on-chain data in the node database does not include the business data corresponding to the data identifier, an error message will be returned.

3. The method according to claim 1 or 2, characterized in that, The step of generating snapshot data based on the read set data and the block metadata corresponding to the business data includes: Construct a snapshot data structure, obtain the status data corresponding to each read instruction in the read set data, obtain the business block containing the business data, obtain the block metadata corresponding to the business block, and fill the status data and the block metadata into the snapshot data structure in the order of execution of the read instructions in the read set data to obtain snapshot data.

4. The method according to any one of claims 1 to 3, characterized in that, The step of re-executing the instructions corresponding to the business data based on the snapshot data to obtain contract receipt information includes: Based on the snapshot data, the instructions corresponding to the business data are re-executed to obtain the business receipt data of the business data; the business receipt data includes the data generated by re-executing the instructions corresponding to the business data. The consistency of the business receipt data is verified by using the read set data, write set data, and execution result data stored in the node database; both the write set data and the execution result data are associated with the business data. After the consistency verification is passed, a hash operation is performed on the business receipt data to obtain the business hash value; The business hash value and the business receipt data are identified as contract receipt information.

5. The method according to any one of claims 1 to 4, characterized in that, The step of re-executing the instruction corresponding to the business data based on the snapshot data to obtain the business receipt data of the business data includes: The snapshot data is used to obtain the account address associated with the business data and the resource data corresponding to the account address. Based on the account address associated with the business data and the resource data corresponding to the account address, the business data is re-executed to obtain the verification read set data, verification write set data, verification result data and instruction execution log of the business data. The instruction execution log includes data generated by re-executing N instructions corresponding to the business data, where N is a positive integer and the N instructions refer to the instructions called by the business data. The verification read set data, the verification write set data, the verification result data, and the instruction execution log are identified as business receipt data.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: The business data is packaged to obtain business blocks; Generate the execution result corresponding to the business block, and broadcast the business block and the execution result data in the secondary chain network; Obtain voting information for the business block in the secondary chain network; the voting information is generated based on the business block and the execution result data; Based on the voting information, consensus processing is performed on the business block in the secondary chain network. When consensus is passed, the business block containing the business data is stored in the secondary chain network.

7. A data processing method based on a blockchain network, characterized in that, The blockchain network includes a main chain network and a secondary chain network. The method is executed by a business client in the secondary chain network, and the method includes: A receipt generation request for business data is sent to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database; M is a positive integer, the M blockchain nodes belong to the sub-chain network, and the business data is data that has been executed on-chain in the sub-chain network; the contract receipt information is obtained by the blockchain nodes re-executing the instructions corresponding to the business data based on snapshot data; the snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data; the read set data includes the status data required to execute the instructions corresponding to the business data during the on-chain process; Obtain contract receipt information sent by the M blockchain nodes respectively, and generate verification information for the business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

8. The method according to claim 7, characterized in that, Also includes: Get the node's fault tolerance value f; f is a positive integer; The consensus node value M is determined based on the node fault tolerance value f; M is a positive integer greater than f; Based on the consensus node value M and the quality scores corresponding to the T candidate nodes, M blockchain nodes are selected from the T candidate nodes; T is a positive integer, and T is greater than or equal to M; The T nodes to be selected belong to the subchain network.

9. The method according to claim 7 or 8, characterized in that, The step of obtaining the contract receipt information sent by the M blockchain nodes respectively, and generating verification information for the business data based on the M contract receipt information, includes: Obtain the contract receipt information sent by the M blockchain nodes respectively, and determine the verification contract receipt information from the M contract receipt information; Generate zero-knowledge proof information for the verification contract receipt information, and determine the zero-knowledge proof information as verification information for the business data.

10. The method according to any one of claims 7 to 9, characterized in that, The step of determining the verification contract receipt information from the M contract receipt information includes: The status of each of the M contract receipts is checked, and the P contract receipts that pass the status check are determined as P verified receipts; P is a positive integer less than or equal to M. If all P verified receipts are identical, and P is greater than or equal to the verification threshold, then any one of the P verified receipts will be determined as the contract verification receipt.

11. The method according to any one of claims 7 to 10, characterized in that, Also includes: If there are different verified receipts among the P verified receipts, or if P is less than the verification threshold, then an updated node value Q is generated based on the consensus node value M, and Q blockchain nodes are selected from the T candidate nodes based on the updated node value Q; Q is greater than M and less than or equal to T. Send a receipt generation request for the business data to the Q blockchain nodes, obtain the contract receipt information sent by the Q blockchain nodes respectively, perform status detection on the Q contract receipt information respectively, and determine the C contract receipt information that passes the status detection as C verified receipt information; C is a positive integer less than or equal to Q; If all C verified receipts are identical, and C is greater than or equal to the verification threshold, then any one of the C verified receipts will be determined as the contract verification receipt.

12. The method according to any one of claims 7 to 11, characterized in that, The step of determining the verification contract receipt information from the M contract receipt information includes: The status of each of the M contract receipts is checked, and the P contract receipts that pass the status check are determined as P verified receipts; P is a positive integer less than or equal to M. The P verified receipt information messages are grouped into B receipt information groups; B is a positive integer; the verified receipt information messages in a receipt information group are all the same. The receipt information group with the largest number of verified receipt information among the B receipt information groups is determined as the verification receipt information group, and any one of the verified receipt information in the verification receipt information group is determined as the verification contract receipt information.

13. The method according to any one of claims 7 to 12, characterized in that, The generation of zero-knowledge proof information for the verification contract receipt information includes: The verification contract receipt information is encoded to obtain an encoded value, and an encoded polynomial is constructed based on the encoded value; the coefficients of the encoded polynomial are determined based on the encoded value. A verification polynomial is randomly generated; a commitment polynomial is generated based on the encoding polynomial and the verification polynomial; and a Merkle tree is generated based on the solution set of the commitment polynomial. The Merkle tree includes S leaf nodes, where S is a positive integer, and the S leaf nodes are used to indicate the solution set of the commitment polynomial. A hash operation is performed on the root hash value of the Merkle tree to obtain a verification value. The verification polynomial, the commitment polynomial, and the verification value are then used as zero-knowledge proof information.

14. The method according to any one of claims 7 to 13, characterized in that, Also includes: The verification information and the state root of the business data are sent to the main chain network so that the main chain network can verify the verification polynomial and the commitment polynomial using the verification value. After both the verification polynomial and the commitment polynomial in the verification information are verified, the state root is processed on the chain. The state root that has been processed on the chain in the main blockchain network is used to indicate that the business data that has been processed on the chain in the secondary chain network is in a correctness verification passed state.

15. A data processing device based on a blockchain network, characterized in that, The blockchain network includes a main chain network and a secondary chain network, and the data processing device is applied to blockchain nodes in the secondary chain network; the data processing device includes: The receipt generation request acquisition module is used to acquire receipt generation requests for business data; the business data is data that has been processed on-chain in the secondary chain network. The read set data acquisition module is used to acquire the read set data corresponding to the business data according to the receipt generation request; the read set data includes the status data required to execute the instruction corresponding to the business data obtained during the on-chain process; The snapshot data generation module is used to generate snapshot data based on the read set data and the block metadata corresponding to the business data; The receipt information generation module is used to re-execute the instructions corresponding to the business data based on the snapshot data to obtain contract receipt information; the contract receipt information includes data generated by re-executing the instructions corresponding to the business data, and the contract receipt information is used to generate verification information for the business data, and the verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

16. A data processing device based on a blockchain network, characterized in that, The blockchain network includes a main chain network and a secondary chain network, and the data processing device is applied to a business client in the secondary chain network; the data processing device includes: The receipt information acquisition module is used to send receipt generation requests for business data to M blockchain nodes, so that each blockchain node generates contract receipt information based on its deployed node database; M is a positive integer, the M blockchain nodes belong to the sub-chain network, and the business data is data that has been executed on-chain in the sub-chain network; the contract receipt information is obtained by the blockchain node re-executing the instructions corresponding to the business data based on snapshot data; the snapshot data is generated based on the read set data associated with the business data in the node database and the block metadata corresponding to the business data; the read set data includes the status data required to execute the instructions corresponding to the business data during the on-chain process; The verification information generation module is used to obtain the contract receipt information sent by the M blockchain nodes respectively, and generate verification information for the business data based on the M contract receipt information; the verification information is used to instruct the main chain network to verify the correctness of the business data in the secondary chain network.

17. 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 program code so that the computer device executes the method according to any one of claims 1-14.

18. A computer storage medium, characterized in that, The computer storage medium stores a computer program adapted to be loaded and executed by a processor, such that a computer device having the processor performs the method according to any one of claims 1-14.

19. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer 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-14.

Images