A blockchain-based data processing method, device, and readable storage medium

Abstract

The embodiment of the application discloses a kind of based on blockchain data processing method, equipment and readable storage medium, the method is executed by side chain node, the method includes: according to the transaction on-chain request carrying service transaction, determine the transaction execution result of service transaction;When transaction execution result and service transaction are successfully stored to side block chain Z, according to transaction serial number, service type identifier and transaction execution result, the service transaction abstract information corresponding to service transaction is generated;Business transaction abstract information is transmitted to main block chain, so that main block chain stores service transaction abstract information;Service transaction abstract information stored in main block chain is used to be sent to verification device by main block chain;Verification device is used to verify the legality of service transaction abstract information according to the transaction execution result obtained from side block chain Z.It can not only reduce the computing resource and storage resource of main block chain by the application, but also ensure the security of blockchain network.

Description

Technical Field

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

[0002] With the rapid development of network technology and enterprises' emphasis on data security, blockchain has received great attention and application.

[0003] In existing technologies, the computing resources and storage space of a credible blockchain are limited. Therefore, as the number of blocks continues to increase, the credible blockchain will face the dilemma of insufficient computing resources and insufficient storage resources. Summary of the Invention

[0004] This application provides a blockchain-based data processing method, device, and readable storage medium, which can not only reduce the computing and storage resources of the main blockchain, but also ensure the security of the blockchain network.

[0005] This application provides a blockchain-based data processing method, which is executed by a sidechain node. The sidechain node belongs to a side blockchain Z in a consortium blockchain, which also includes a main blockchain. The method includes:

[0006] Obtain the transaction on-chain request sent by the business device, carrying the business transaction; determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request; and perform on-chain processing on the transaction execution result and the business transaction.

[0007] When the transaction execution result and the business transaction are successfully stored in the side blockchain Z, a business transaction summary information corresponding to the business transaction is generated based on the transaction sequence number, business type identifier, and transaction execution result. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0008] The business transaction summary information is transmitted to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used by the main blockchain to send to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

[0009] One embodiment of this application provides a blockchain-based data processing method, including:

[0010] A first data retrieval request carrying a business type identifier and a transaction sequence number is sent to the main blockchain in the consortium blockchain. This allows the main blockchain to return the business transaction summary information to the verification device when it determines that the verification device has the first access permission for the business transaction summary information based on the business type identifier and transaction sequence number. The transaction sequence number represents the sequence number of the business transaction in the side blockchain Z. The side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from the side blockchain Z to the main blockchain. The business transaction summary information is generated by the first side chain node in the side blockchain Z based on the transaction sequence number, business type identifier, and transaction execution result when the transaction execution result is successfully stored in the side blockchain Z. The transaction execution result is determined by the first side chain node based on the transaction upload request sent by the business device. The transaction upload request carries the business transaction. The business type identifier represents the business type of the business processed by the side blockchain Z.

[0011] Send a second data acquisition request carrying the transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it will return the transaction execution result associated with the transaction sequence number to the verification device.

[0012] Based on the transaction execution results, verify the legality of the business transaction summary information.

[0013] This application provides, in one aspect, a blockchain-based data processing device. This device operates on a sidechain node, which belongs to a side blockchain Z within a consortium blockchain. The consortium blockchain also includes a main blockchain. The device comprises:

[0014] The transaction execution module is used to obtain the transaction on-chain request carrying the business transaction sent by the business device, determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request, and perform on-chain processing on the transaction execution result and the business transaction.

[0015] The first generation module is used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, and transaction execution result when the transaction execution result and the business transaction are successfully stored in the side blockchain Z. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0016] The summary transmission module is used to transmit business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution results obtained from the side blockchain Z.

[0017] The blockchain-based data processing device also includes:

[0018] The state update module is used to update the historical state tree based on the transaction execution results to obtain the updated state tree; the historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z;

[0019] The first generation module is specifically used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, historical state tree, and updated state tree.

[0020] The first generation module includes:

[0021] The first acquisition unit is used to acquire the historical state root hash of the historical state tree and to acquire the value of the first target field from the historical state root hash.

[0022] The second acquisition unit is used to acquire the update state root hash of the update state tree and to retrieve the value of the second target field from the update state root hash.

[0023] The first generation unit is used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, first target field value, and second target field value.

[0024] Specifically, the state update module is used to update the historical state tree based on the write set in the transaction execution result to obtain the updated state tree; the full historical state values ​​include the historical write set in the transaction execution result; the write set includes the updated state value of the first business object in the business transaction; the historical write set includes the historical state value of the first business object;

[0025] The first generating unit includes:

[0026] The first generation subunit is used to generate the first hash value of the write set and obtain the value of the third target field from the first hash value;

[0027] The second generation subunit is used to generate the second hash value of the historical write set and obtain the value of the fourth target field from the second hash value.

[0028] The third generation subunit is used to generate the third hash value of the read set in the transaction execution result, and to obtain the value of the fifth target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction;

[0029] The fourth generation sub-unit is used to combine the transaction sequence number, business type identifier, third target field value, fourth target field value, fifth target field value, first target field value, and second target field value into business transaction summary information corresponding to the business transaction.

[0030] The transaction execution result includes the write set corresponding to the business transaction and the historical write set corresponding to the business transaction; the write set includes the updated status value B. c c is a positive integer and c is less than or equal to the total number of updated state values ​​in the write set; the history write set includes the history state value D. c ;

[0031] The blockchain-based data processing device also includes:

[0032] The second generation module is used to generate the updated state value B based on the updated state tree. c The Merkel path, based on the historical state tree, generates a target for historical state value D. c Merkel's path;

[0033] The associated storage module is used to associate and store the Merkel path corresponding to each updated state value in the write set with the write set.

[0034] The associated storage module is also used to associate and store the Merkel path corresponding to each historical state value in the historical write set with the historical write set.

[0035] The transaction execution module includes:

[0036] The first determining unit is used to determine the business type of the business transaction. If the business type of the business transaction matches the business type identifier, then according to the transaction on-chain request, the transaction execution function in the smart contract that matches the business type of the business transaction is called.

[0037] The third acquisition unit is used to acquire the historical state value of the second business object in the business transaction according to the transaction execution function, and combine the historical state value of the second business object into the read set of the business transaction.

[0038] The fourth acquisition unit is used to acquire the updated state value of the first business object in the business transaction generated when the transaction execution function is executed, based on the business transaction and the read set.

[0039] The second determining unit is used to determine the updated state value of the first business object as the write set of the business transaction, obtain the state value of the first business object before the execution of the transaction execution function, and determine the obtained state value as the historical write set of the business transaction.

[0040] The third determining unit is used to determine the transaction execution result corresponding to the business transaction based on the write set, the historical write set, and the read set.

[0041] The transaction execution module includes:

[0042] The fifth acquisition unit is used to acquire the block with the largest generation timestamp from the side blockchain Z when the side chain node has consensus permissions, and use the block header hash value of the parent block as the parent block hash value.

[0043] The second generation unit is used to generate sidechain blocks based on the parent block hash value, business transactions carrying transaction sequence numbers, transaction execution results, and the updated state tree generated based on the transaction execution results; the generation timestamp of the sidechain block is used to update the maximum generation timestamp of the side blockchain Z;

[0044] The block broadcasting unit is used to sign the sidechain block using the private key of the corresponding sidechain node, obtain the signature information, and broadcast the sidechain block carrying the signature information to the consensus node in the side blockchain Z.

[0045] The block adding unit is used to add the sidechain block to the sidechain Z when the consensus nodes in the determined sidechain Z reach a consensus on the sidechain block and return the transaction sequence number to the business device.

[0046] The digest transmission module includes:

[0047] The digest encryption unit is used to encrypt the business transaction digest information using the main blockchain's public key to obtain encrypted digest information;

[0048] The information upload unit is used to call the information upload function corresponding to the business type identifier in the main blockchain. Through the information upload function, the encrypted digest information is uploaded to the main blockchain, so that the main chain nodes in the main blockchain can use the main chain private key of the main blockchain to decrypt the encrypted digest information. When the decryption result is a successful decryption result, the business transaction digest information corresponding to the successful decryption result is stored.

[0049] One embodiment of this application provides a blockchain-based data processing device, which operates on a verification device, and the device includes:

[0050] The first sending module is used to send a first data acquisition request carrying a business type identifier and a transaction sequence number to the main blockchain in the consortium blockchain. This allows the main blockchain to return the business transaction summary information to the verification device when it determines that the verification device has the first access permission for the business transaction summary information based on the business type identifier and the transaction sequence number. The transaction sequence number represents the sequence number of the business transaction in the side blockchain Z. The side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from the side blockchain Z to the main blockchain. The business transaction summary information is generated by the first side chain node in the side blockchain Z based on the transaction sequence number, business type identifier, and transaction execution result when the transaction execution result is successfully stored in the side blockchain Z. The transaction execution result is determined by the first side chain node based on the transaction upload request sent by the business device. The transaction upload request carries the business transaction. The business type identifier represents the business type of the business processed by the side blockchain Z.

[0051] The second sending module is used to send a second data acquisition request carrying a transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it will return the transaction execution result associated with the transaction sequence number to the verification device.

[0052] The information verification module is used to verify the legality of business transaction summary information based on the transaction execution result.

[0053] The second sending module is also used to obtain the Merkel path set associated with the transaction sequence number returned by the second sidechain node when it determines that the verification device has the second access permission;

[0054] The information verification module is specifically used to verify the legality of business transaction summary information based on the transaction execution result and the Merkel path set.

[0055] The information verification module includes:

[0056] The first generation unit is used to generate the first hash value of the write set in the transaction execution result, and to obtain the value of the third verification target field from the first hash value; the write set includes the update status value of the first business object in the business transaction.

[0057] The second generation unit is used to generate the second hash value of the historical write set in the transaction execution result, and to obtain the value of the fourth verification target field from the second hash value; the historical write set includes the historical state value of the first business object;

[0058] The third generation unit is used to generate the third hash value of the read set in the transaction execution result, and to obtain the value of the fifth verification target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction;

[0059] The validity verification unit is used to verify the validity of business transaction summary information based on the values ​​of the third, fourth, and fifth verification target fields, the write set, the historical write set, the read set, and the Merkel path set.

[0060] The valid verification unit includes:

[0061] The first comparison subunit is used to compare the value of the third verification target field with the value of the third target field in the business transaction summary information to obtain the first comparison result;

[0062] The second comparison subunit is used to compare the value of the fourth verification target field with the value of the fourth target field in the business transaction summary information to obtain the second comparison result;

[0063] The third comparison subunit is used to compare the value of the fifth verification target field with the value of the fifth target field in the business transaction summary information to obtain the third comparison result;

[0064] The first generation subunit is used to generate a root hash for verifying the historical state based on the historical write set and the Merkel paths associated with the historical write set in the Merkel path set.

[0065] The second generation subunit is used to generate the verification update state root hash based on the write set and the Merkel path associated with the write set in the Merkel path set;

[0066] The valid verification subunit is used to re-execute the business transaction based on the read set to obtain the valid write set, and to verify the validity of the business transaction summary information based on the first comparison result, the second comparison result, the third comparison result, the verification historical state root hash, the verification updated state root hash, and the valid write set.

[0067] The valid verification subunit includes:

[0068] The first acquisition subunit is used to obtain the value of the first verification target field from the root hash of the verification history state, compare the value of the first verification target field with the value of the first target field in the business transaction summary information, and obtain the fourth comparison result.

[0069] The second acquisition subunit is used to obtain the value of the second verification target field from the root hash of the verification update status, compare the value of the second verification target field with the value of the second target field in the business transaction summary information, and obtain the fifth comparison result.

[0070] The set comparison subunit is used to compare the verification write set with the write set to obtain the sixth comparison result;

[0071] The first determining subunit is used to determine that the business transaction summary information is illegal information if there is a comparison result that is different among the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result.

[0072] The second determining subunit is used to determine that the business transaction summary information is legal information if the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result are all the same.

[0073] The blockchain-based data processing device also includes:

[0074] The transaction generation module is used to generate a challenge sidechain transaction based on the business type identifier, transaction sequence number, transaction execution result, and Merkel path set if the verified business transaction summary information is invalid.

[0075] The transaction transmission module is used to transmit challenge sidechain transactions to the main blockchain so that the main blockchain can reach a consensus on the challenge sidechain transactions. When the consensus passes the challenge sidechain transactions, the sidechain Z is confirmed as an untrusted chain.

[0076] This application provides a computer device, including: a processor, a memory, and a network interface;

[0077] The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the methods in the embodiments of this application.

[0078] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the method described in this application.

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

[0080] In this embodiment, when a sidechain node receives a transaction upload request carrying a business transaction from a business device, it can determine the transaction execution result corresponding to the business transaction based on the transaction upload request. The sidechain node belongs to side blockchain Z in a consortium blockchain, which also includes a main blockchain. Further, the sidechain node performs on-chain processing on the transaction execution result and the business transaction, i.e., stores them in side blockchain Z. Further, based on the transaction sequence number, business type identifier, and transaction execution result, the sidechain node can generate business transaction summary information corresponding to the business transaction and transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information. The business transaction summary information stored in the main blockchain is used by the main blockchain to send it to a verification device. The verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from side blockchain Z. As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network. Attached Figure Description

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

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

[0083] Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 1 ;

[0084] Figure 3 This application provides an example of a blockchain-based data processing scenario. Figure 1 ;

[0085] Figure 4 This application provides an example of a blockchain-based data processing scenario. Figure 2 ;

[0086] Figure 5 This is a schematic diagram of the structure of a business transaction summary information provided in an embodiment of this application;

[0087] Figure 6 This application provides an example of a blockchain-based data processing scenario. Figure 3 ;

[0088] Figure 7 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 2 ;

[0089] Figure 8 This application provides an example of a blockchain-based data processing scenario. Figure 4 ;

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

[0091] Figure 10 This is an interactive flowchart of a blockchain-based data processing method provided in an embodiment of this application;

[0092] Figure 11 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. Figure 1 ;

[0093] Figure 12 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. Figure 2 ;

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

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

[0096] To facilitate understanding, the following brief explanations are provided for some of the terms:

[0097] 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. Blocks use digital digests to verify previously obtained transaction history, making it suitable for the tamper-proof and scalable requirements of distributed ledger scenarios. In a broader sense, blockchain also refers to the distributed ledger technology implemented using the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, and smart contracts. The goal of blockchain is to implement a distributed data record ledger that only allows additions, not deletions. The underlying basic structure of the ledger is a linear linked list. The linked list consists of a series of "blocks," with each subsequent block recording the hash value of the previous block. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a node in the network proposes to add a new block, the block must be confirmed through a consensus mechanism.

[0098] For a reputable blockchain, its computing resources and storage space are limited. Therefore, as the number of blocks increases, the available storage space corresponding to the reputable blockchain may become insufficient, and the response time may be slower than the request. This necessitates scaling up, resulting in a scaled-up blockchain. To ensure efficiency, a private blockchain is typically used as the scaled-up blockchain. In this application, the reputable blockchain is referred to as the main blockchain, and the scaled-up blockchain is referred to as the side blockchain. The side blockchain's role is to scale up the main blockchain. The main blockchain and the side blockchain can form a consortium blockchain.

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

[0100] The predecessor block, also known as the parent block, is the block in which the blockchain achieves temporal ordering by recording the hash value of the block and the hash value of the parent block in the block header.

[0101] 3. Hash Value: Also known as an information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output using a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash values ​​of its predecessor blocks. The hash value is a core foundation and the most important aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0102] 4. Blockchain Nodes: Blockchain networks divide nodes into consensus nodes (also known as core nodes) and synchronization nodes (which can include data nodes and light nodes). Consensus nodes are responsible for the consensus process across the entire blockchain network; synchronization nodes are responsible for synchronizing the ledger information of the consensus nodes, i.e., synchronizing the latest block data. Both consensus and synchronization nodes include network communication components in their internal structure, because a blockchain network is essentially a peer-to-peer (P2P) network, requiring communication with other nodes in the blockchain network through P2P components. Resources and services in the blockchain network are distributed across various nodes; information transmission and service implementation occur directly between nodes, without the need for intermediaries or centralized servers (third parties).

[0103] In this application embodiment, the blockchain nodes included in the main blockchain are called main chain nodes, and the blockchain nodes included in the side blockchain are called side chain nodes. The side chain nodes can be further divided into side chain synchronization nodes (whose function is the same as the synchronization nodes mentioned above) and side chain consensus nodes (whose function is the same as the consensus nodes mentioned above).

[0104] 5. Write Set: After executing a transaction, the consensus node calculates the write set and fills it into the transaction's structure. The write set does not participate in the transaction hash calculation. The write set of a transaction records all disk write operations for that transaction. The write set allows for rapid updates to the chain state without executing the transaction. This application's embodiment proposes a historical write set, which refers to the initial state of the disk write object before transaction execution.

[0105] 6. Read Set: Similar to the Write Set, it records all read operations performed during the execution of a transaction.

[0106] 7. Merkle Tree, Merkle Root: A Merkle tree is a typical binary tree structure, consisting of a root node (Merkle root), a set of intermediate nodes, and a set of leaf nodes. The leaf nodes at the bottom level store data or its hash value, while the other nodes store the hash values ​​of the contents of their two child nodes.

[0107] 8. Asymmetric Signature: This algorithm involves two keys: a public key and a private key. The public and private keys are a pair; if data is signed using the private key, only the corresponding public key can verify the signature. Because the signing and verification processes use two different keys, this algorithm is called asymmetric signature. The basic process of using asymmetric signatures to exchange confidential information can be as follows: Party A generates a key pair and publishes the public key. When Party A needs to send information to another party (Party B), it signs the confidential information using its private key before sending it to Party B; Party B then uses Party A's public key to verify the signed information.

[0108] 9. Smart Contract: A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. In a blockchain system, a smart contract (or simply contract) is code that all nodes on the blockchain can understand and execute, capable of performing arbitrary logic and obtaining results. In practical applications, smart contracts are managed and tested through transactions on the blockchain. Each transaction is equivalent to a Remote Procedure Call (RPC) request to the blockchain system. If a smart contract is like an executable program, the blockchain is like the operating system that provides the runtime environment. A blockchain can contain multiple contracts (such as the resource fusion function and resource issuance function in this application), distinguished by contract identity (ID), identifier, or name.

[0109] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. For example... Figure 1 As shown, the system architecture may include a cluster of terminal devices and a cluster of blockchain nodes in the consortium blockchain 100. The terminal device cluster may include terminal devices 10g, 10h, 10i, and 10j. The blockchain node cluster may include blockchain nodes 10a, 10b, 10c, 10d, 10e, and 10f. It is understood that this application embodiment does not limit the number of terminal devices in the cluster, and may include one or more terminal devices. Similarly, it does not limit the attributes of the blockchain node cluster, and may include one or more blockchain nodes.

[0110] The terminal device clusters can have communication connections with each other, for example, a communication connection exists between terminal device 10i and terminal device 10g. Similarly, the blockchain node clusters can have communication connections, for example, a communication connection exists between blockchain node 10a and blockchain node 10c, and between blockchain node 10a and blockchain node 10d. Any blockchain node in the blockchain node cluster can have a communication connection with any terminal device in the terminal device cluster, for example, a communication connection exists between blockchain node 10a and terminal device 10h, between blockchain node 10d and terminal device 10j, between blockchain node 10c and terminal device 10g, and between blockchain node 10e and terminal device 10i. The communication connections are not limited to any particular method; they can be established directly or indirectly via wired communication, wireless communication, or other methods. This application does not impose any restrictions on these methods.

[0111] It is understandable that blockchain nodes can transmit data or blocks through the aforementioned communication connections. These communication connections between blockchain nodes can be based on node identifiers. Each blockchain node in the network has a corresponding node identifier, and each blockchain node can store the node identifiers of other blockchain nodes that are connected to it. This allows it to broadcast acquired data or generated blocks to other blockchain nodes based on their node identifiers. For example, blockchain node 10a can maintain a list of node identifiers, which stores the node names and identifiers of other blockchain nodes, as shown in Table 1.

[0112] Table 1

[0113] Blockchain node 10b AAAAA Blockchain node 10c BBBBB … … Blockchain node 10d CCCCC Blockchain Node 10e DDDDD Blockchain node 10f EEEEE … …

[0114] The node identifier can be an Internet Protocol (IP) address used for interconnecting networks, or any other information that can be used to identify a blockchain node in a blockchain network.

[0115] Assuming the node identifier of blockchain node 10a is FFFFFF, then blockchain node 10a can send a digest information upload request to blockchain node 10d through the node identifier CCCCC, and blockchain node 10d can know that the digest information upload request was sent by blockchain node 10a through the node identifier FFFFFF. Similarly, blockchain node 10d can send a block consensus request to blockchain node 10c through the node identifier BBBBBB, and blockchain node 10c can know that the block consensus request was sent by blockchain node 10d through the node identifier CCCCCC. Data transmission between other nodes is also like this, so it will not be elaborated on further.

[0116] This application embodiment divides the blockchain network into a main blockchain network and one or more side blockchain networks, forming a consortium blockchain 100. This application embodiment does not limit the number of blockchains in the consortium blockchain 100. Please refer to [link to previous document]. Figure 1 The consortium blockchain 100 can include a main blockchain 100a, side blockchains 100b, ..., and blockchain 100c. Blockchain nodes 10a, ..., 10b belong to the main blockchain 100a, i.e., they are the main chain nodes in the blockchain network cluster. Blockchain nodes 10c, ..., 10d belong to the side blockchain 100b, i.e., they are the side chain nodes in side blockchain 100b. Blockchain nodes 10e, ..., 10f belong to the blockchain 100c, i.e., they are the side chain nodes in side blockchain 100c. It can be understood that blockchain nodes (including blockchain nodes 10a, 10b, 10c, 10d, 10e, and 10f) can be used to maintain their respective blockchains. The aforementioned main blockchain 100a, side blockchains 100b, ..., and blockchain 100c can all be understood as distributed systems. In a distributed system, any device, such as a server or user terminal, can join and become a blockchain node.

[0117] It is understood that enterprises can include various types of business data, such as enterprise tax data, social security data, and business registration data. Different types of business data are stored on different blockchains. For example, terminal devices 10g and 10h store enterprise tax data in side blockchain 100b of consortium blockchain 100, terminal devices 10i and 10j store social security data in side blockchain 100c of consortium blockchain 100, and terminal devices 10g and 10i store business registration data in other side blockchains of consortium blockchain 100. In this embodiment, when a sidechain node in a side blockchain is working normally, it can receive business transactions sent by the client, generate blocks based on the received business transactions, and then perform block on-chain processing, that is, perform on-chain processing in the blockchain it maintains. It is understood that in the specific implementation of this application, data related to user information (such as business transactions) is involved. When this embodiment is applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0118] As described above, each side blockchain in this embodiment independently maintains a different set of full data; that is, the stored full business data is different, and the maintained blocks are also different. Similarly, the blocks maintained by the main blockchain 100a are also different from those of the side blockchains (e.g., Figure 1 The blocks maintained by the side blockchain 100b are different; please see the following text for details. Figures 2-10 The descriptions in the respective embodiments.

[0119] Understandable Figure 1 The blockchain nodes in the consortium blockchain 100 include, but are not limited to, mobile terminals or servers. These servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The mobile terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The mobile terminals and servers can be connected directly or indirectly via wired or wireless means; this application embodiment does not impose any limitations on this.

[0120] Further, please see Figure 2 , Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 1This blockchain-based data processing method can be executed by sidechain nodes in sidechain Z of a consortium blockchain. The consortium blockchain can provide... Figure 1 In the consortium blockchain 100, the side blockchain Z can be the above. Figure 1 Any one of the side blockchains. For example... Figure 2 As shown, the blockchain-based data processing method may include at least the following steps S101-S103.

[0121] Step S101: Obtain the transaction on-chain request carrying the business transaction sent by the business device; determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request; and perform on-chain processing on the transaction execution result and the business transaction.

[0122] Specifically, the business type of the business transaction is determined. If the business type of the business transaction matches the business type identifier, the transaction execution function in the smart contract that matches the business type of the business transaction is called according to the transaction on-chain request. Based on the transaction execution function, the historical state value of the second business object in the business transaction is obtained, and the historical state value of the second business object is combined into the read set of the business transaction. The transaction execution function is executed according to the business transaction and the read set, and the updated state value of the first business object in the business transaction generated when the transaction execution function is executed is obtained. The updated state value of the first business object is determined as the write set of the business transaction, and the state value of the first business object before the execution of the transaction execution function is obtained. The obtained state value is determined as the historical write set of the business transaction. Based on the write set, the historical write set, and the read set, the transaction execution result corresponding to the business transaction is determined.

[0123] Specifically, the historical state tree is updated based on the transaction execution results to obtain the updated state tree; the historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z.

[0124] The specific process of updating the historical state tree based on the transaction execution result to obtain the updated state tree may include: updating the historical state tree based on the write set in the transaction execution result to obtain the updated state tree; the full historical state values ​​include the historical write set in the transaction execution result; the write set includes the updated state value of the first business object in the business transaction; the historical write set includes the historical state value of the first business object.

[0125] Specifically, when a sidechain node has consensus permissions, it retrieves the block with the largest generation timestamp from sidechain Z as the parent block, using the parent block's block header hash value as the parent block hash value. Based on the parent block hash value, the business transaction carrying the transaction sequence number, the transaction execution result, and the updated state tree generated based on the transaction execution result, a sidechain block is generated. The generation timestamp of the sidechain block is used to update the largest generation timestamp of sidechain Z. Using the node private key corresponding to the sidechain node, the sidechain block is signed to obtain signature information, and the sidechain block carrying the signature information is broadcast to the consensus nodes in sidechain Z. When it is determined that the consensus nodes in sidechain Z have reached a consensus on the sidechain block, the sidechain block is added to sidechain Z, and the transaction sequence number is returned to the business device.

[0126] In this application embodiment, the business device refers to the device that generates business transactions and transmits them to the side blockchain. Business devices include, but are not limited to, terminal devices or business servers. The business server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft.

[0127] Please see also Figure 3 , Figure 3 This application provides an example of a blockchain-based data processing scenario. Figure 1 .like Figure 3 As shown, business object 20a operates on business device 201a, generating business transaction 202a, as follows. Figure 3 The example "transferring 30 resources from the current resources of object 201b to object 202b" means that if business object 20a authorizes business device 201a to send business transaction 202a to side blockchain 201c (i.e. side blockchain Z), then business device 201a generates a transaction on-chain request carrying the business transaction 202a, and then sends the transaction on-chain request to the side chain node 20c belonging to side blockchain 201c.

[0128] After receiving the transaction upload request, sidechain node 20c first verifies the business type of business transaction 202a, thus determining that the business type of business transaction 202a is 20d. Figure 3In example business transaction 202a, business type 20d is a resource transfer type. Further, sidechain node 20c matches business type 20d (i.e., the resource transfer type) with the business type processed by sidechain 201c (which can be represented by a business type identifier). If business type 20d does not match the business type identifier, for example, if the business type identifier indicates that the business type processed by sidechain 201c is a digital product rights confirmation type, then sidechain node 20c can refuse to process the transaction upload request sent by business device 201a. If business type 20d matches the business type identifier, then sidechain node 20c, according to the transaction upload request, calls the transaction execution function 20e in the smart contract that matches the resource transfer type, such as... Figure 3 The example resource transfer function.

[0129] According to the transaction execution function 20e, sidechain node 20c can determine the disk read data for the business transaction "transferring 30 resources from the current resources of object 201b to object 202b", that is, the current resources of object 201b and the current resources of object 202b. Figure 3 Example object 201b has a current resource of 30, and object 202b has a current resource of 50. Sidechain node 20c determines the read state data as read set 20f. Further, sidechain node 20c executes transaction execution function 20e (i.e., ...) based on read set 20f and business transaction 202a. Figure 3 The resource transfer function in the file retrieves the updated status value of object 201b after the execution of business transaction 202a (e.g., ...). Figure 3 The example shows the updated resources of object 201b (0) and the updated status value of object 202b (e.g., ...). Figure 3 The example object 202b's update resource (80) determines the state data that needs to be written to disk after the execution of business transaction 202a as the write set 20g. Further, sidechain node 20c obtains the historical state data that needs to be written to disk and determines the obtained state data as the historical write set 20h.

[0130] It is understandable that the first business object refers to the business object corresponding to the status data that needs to be written to disk after the business transaction is executed, and the second business object refers to the business object corresponding to the status data that needs to be read from disk when executing the business transaction. Figure 3 In the process, the first business object is the same as the second business object, that is, sidechain node 20c reads the historical state values ​​corresponding to objects 201b and 202b respectively, such as Figure 3 The current resource of object 202b is 50, and the current historical resource of object 201b is 30. Simultaneously, sidechain node 20c also writes the update status values ​​corresponding to objects 201b and 202b, respectively. Figure 3The updated resources of object 202b are 80, and the updated resources of object 201b are 0. In the above scenario, the historical write collection 20h contains the historical resources of object 202b: 50, and the historical resources of object 201b: 30. It is understandable that in practical applications, the first business object may differ from the second business object. For example, in the transaction "Create object 202z, transfer 30 resources from the current resources of object 204b to object 202b", the first business object includes both object 204b and object 202z, and the second business object includes object 204b.

[0131] Please see again. Figure 3 Sidechain node 20c determines the transaction execution result corresponding to business transaction 202a based on write set 20g, historical write set 20h, and read set 20f. This embodiment does not limit the content of the transaction execution result; it can be set according to the actual application scenario. Specifically, the transaction execution result may also include relevant parameters during business transaction execution, such as error code, transaction queue height, and transaction hash value.

[0132] The sideblock 201c maintains a state tree that includes the state data corresponding to all business objects. Please refer to [link / reference needed]. Figure 4 , Figure 4 This application provides an example of a blockchain-based data processing scenario. Figure 2 .like Figure 4 As shown, before executing business transaction 202a, the side blockchain 201c maintains the historical state tree 20i. It should be emphasized that, for ease of description and understanding, the total number of all business objects in this embodiment is four, namely object 201b, object 202b, object 203b, and object 204b. In actual applications, the total number of all business objects can be any positive integer.

[0133] The history state tree 20i includes the history state value 1 corresponding to object 201b (i.e. Figure 4 30), the historical state value 2 corresponding to object 202b (i.e. Figure 4 The 50 in the middle), the historical state value 3 corresponding to object 203b (40 in the spike 4), and the historical state value 4 corresponding to object 204b (i.e. Figure 4 In addition, the historical state 20i also includes the hash value 1 corresponding to the historical state value 1 (i.e., 80); Figure 4 H(1) in the historical state value 2 and the hash value 2 corresponding to the historical state value 2 (i.e. Figure 4 H(2) in the historical state value 3 and the hash value 3 corresponding to the historical state value 3 (i.e. Figure 4 H(3) in the middle), and the hash value 4 corresponding to the historical state value 4 (i.e. Figure 4In the historical state tree 20i, the hash values ​​corresponding to H(1) and H(2) are also included (e.g., H(4)). Figure 4 The hash values ​​corresponding to H(12) in the table, and the hash values ​​corresponding to H(3) and H(4) (e.g. Figure 4 In addition, the historical state tree 20i also includes H(12) and the hash value corresponding to H(34) (e.g., H(34)); Figure 4 H(1234) in the hash value is the Merkle root of the historical state tree 20i.

[0134] After sidechain node 20c completes business transaction 202a and obtains the transaction execution result, it updates the historical state tree 20i based on the result. Specifically, it updates the historical state tree 20i according to the state data in the write set 20g. Figure 4 As shown, sidechain node 20c updates the historical state value of object 201b to its updated state value, that is, updates 30 to 0; and updates the historical state value of object 202b to its updated state value, that is, updates 50 to 80. At this time, sidechain node 20c generates the hash value corresponding to the updated state value of object 201b (e.g., ...). Figure 4 H'(1) in the middle), and the hash value corresponding to the update state value of object 202b (e.g. Figure 4 In the case of H'(2), further, perform hash calculation on H'(1) and H'(2) to obtain H'(12). Further, perform hash calculation on H'(12) and H(34) to obtain H'(1234). At this time, the side chain node 20c can obtain the updated state tree 20j.

[0135] If sidechain node 20c is a node in sidechain 201c that has consensus and block-producing permissions, i.e., it is a consensus node in sidechain 201c, then the block with the largest generation timestamp from sidechain 201c is obtained as the parent block. Please refer to [further details]. Figure 4 Sidechain node 20c takes the block with the highest block height as its parent block and uses the parent block's block header hash as its parent block hash; based on the parent block hash, it carries the transaction sequence number ( Figure 4Example business transaction 202a (sequence number 100 in side blockchain 201c), transaction execution result, and updated state tree 20j generate sidechain block 20k. Further, sidechain node 20c uses its corresponding private key 203c to sign sidechain block 20k, obtaining signature information 201k. This signature information 201k is then broadcast to the consensus nodes in side blockchain 201c, enabling them to process the agreement. Once consensus is reached on sidechain block 20k, sidechain node 20c adds it to side blockchain 201c, resulting in side blockchain 202c, and simultaneously returns the transaction sequence number to business device 201a.

[0136] As can be seen from the above, the side blockchain in this application embodiment is an independent blockchain that can perform consensus processing on business transactions related to the business type it handles and store all data. Therefore, it can reduce the consensus load of the main blockchain and thus alleviate the storage pressure of the main blockchain.

[0137] Step S102: When the transaction execution result and the business transaction are successfully stored in the side blockchain Z, generate the business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier and transaction execution result; the transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0138] Specifically, based on the transaction sequence number, business type identifier, transaction execution result, historical state tree, and updated state tree, business transaction summary information corresponding to the business transaction is generated.

[0139] Specifically, the process involves obtaining the historical state root hash of the historical state tree and retrieving the first target field value from the historical state root hash; obtaining the updated state root hash of the updated state tree and retrieving the second target field value from the updated state root hash; and generating business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, the first target field value, and the second target field value.

[0140] Specifically, the process involves generating a first hash value for the write set and retrieving the third target field value from it; generating a second hash value for the historical write set and retrieving the fourth target field value from it; generating a third hash value for the read set in the transaction execution result and retrieving the fifth target field value from it; the read set includes the historical status values ​​of the second business object in the business transaction; and combining the transaction sequence number, business type identifier, third target field value, fourth target field value, fifth target field value, first target field value, and second target field value to form the business transaction summary information corresponding to the business transaction.

[0141] If a sidechain block containing the transaction execution result and the business transaction is stored on sidechain Z, then the sidechain node will generate a business transaction summary information corresponding to the business transaction. Please refer to [link / reference needed]. Figures 3-5 , Figure 5 This is a schematic diagram illustrating the structure of a business transaction summary information provided in an embodiment of this application. For example... Figure 5 As shown, the sidechain node obtains the historical state root hash of historical state tree 20i, as follows: Figure 4 as well as Figure 5 In H(1234), the first target field value 30e is obtained from the historical state root hash. This embodiment does not limit the range of the first target field value 30e; it can be set according to the actual application, for example, the first 16 bits, the last 8 bits, or the first 8 bits plus the last 8 bits of the historical state root hash. For ease of description and understanding, this embodiment uses the first 16 bits of the historical state root hash as an example. Figure 5 The part is "ababababababababab". Further, the sidechain node obtains the update state root hash of the update state tree 20j, such as... Figure 4 as well as Figure 5 H'(1234) in the updated state root hash obtains the second target field value 30f. The meanings of the second target field value, the third target field value, the fourth target field value and the fifth target field value are respectively referred to the explanation of the first target field value. Figure 5 The second target field value is 30f, as shown in the example of cdcdcdcdcdcdcdcd.

[0142] Furthermore, as shown in step S101, the transaction execution result can include a write set, a historical write set, and a read set. The sidechain node generates a first hash value for the write set, and retrieves the third target field value 30b from the first hash value. Figure 5 Taking the example of efefefefefefefef, the third target field value is 30b; the sidechain node generates the second hash value of the historical write set, and retrieves the fourth target field value 30c from the second hash value. Figure 5Taking the example of ghghghghghghghgh, the fourth target field value is 30c; the sidechain node generates the third hash value of the read set, and retrieves the fifth target field value 30d from the third hash value. Figure 5 Taking ijijijijijijijij as an example, the fifth target field value is 30d. Furthermore, the sidechain node will use the transaction sequence number ( Figure 5 Taking serial number 100 as an example), business type identifier, third target field value 30b, fourth target field value 30c, fifth target field value 30d, first target field value 30e, and second target field value 30f are combined to form the business transaction summary information corresponding to the business transaction.

[0143] In summary, considering the large storage capacity of the full data of business transactions (including transaction execution results), the business transaction summary information generated in this embodiment has a storage capacity far smaller than that of the full data of the business transaction. This business transaction summary information is transmitted to the main blockchain for storage. Therefore, this allows the main blockchain to store data related to the business transaction, reduces the storage pressure on the main blockchain, and maintains the security of the entire blockchain. For details, please refer to step S103 and the following text. Figure 9 The description in the corresponding embodiments.

[0144] Step S103: Transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

[0145] Specifically, the business transaction summary information is encrypted using the main blockchain's public key to obtain encrypted summary information. The information upload function corresponding to the business type identifier in the main blockchain is called to upload the encrypted summary information to the main blockchain. This allows the main blockchain nodes to decrypt the encrypted summary information using the main blockchain's private key. If the decryption result is successful, the business transaction summary information corresponding to the successful decryption result is stored.

[0146] Considering that business transaction summary information may be obtained and modified by unauthorized devices during transmission, before transmitting the business transaction summary information, the sidechain node uses the main blockchain's public key to encrypt the business transaction summary information, obtaining encrypted summary information. Further, the sidechain node calls the information upload function corresponding to the business type identifier in the main blockchain, and uploads the encrypted summary information to the main blockchain through the information upload function. Please refer to [link to relevant documentation]. Figure 6 , Figure 6This application provides an example of a blockchain-based data processing scenario. Figure 3 Sidechain node 401b maintains its respective sidechain 401c, and sidechain node 402b maintains its own sidechain 402c. The business types processed by sidechain 401c are different from those processed by sidechain 402c, and both blockchains process transactions independently. Therefore, the blocks stored in sidechain 401c are different from those stored in sidechain 402c. It is understandable that the blocks stored in the main blockchain 40d are also different from those in sidechains 401c and 402c. Specifically, the process of business device 401a sending a transaction request to sidechain node 401b, sidechain node 401b executing business transaction 1, and sidechain node 401b generating the encrypted digest information corresponding to business transaction 1 are all described. Figure 6 The process referred to as encrypted digest information 1, the process of business device 402a sending a transaction on-chain request to sidechain node 402b, the process of sidechain node 402b executing business transaction 2, and the process of sidechain node 402b generating encrypted digest information corresponding to business transaction 2 (referred to as encrypted digest information 1), the process of sidechain node 402a executing a business transaction 2, and the process of sidechain node 402b generating encrypted digest information corresponding to business transaction Figure 6 The process referred to as encrypted digest information 2) is described in the above description of steps S101-S102, and will not be repeated here.

[0147] like Figure 6 As shown, information upload function 1 is used to transmit the encrypted digest information 1 uploaded by side blockchain 401c, and information upload function 2 is used to transmit the encrypted digest information 2 uploaded by side blockchain 402c. When the main chain node obtains the encrypted digest information 1, it uses the main chain private key of the main blockchain to decrypt the encrypted digest information 1. If the decryption result is successful, the main chain node stores the business transaction digest information corresponding to the successful decryption result. The processing process of the main chain node for encrypted digest information 2 is the same as that for encrypted digest information 1, so it will not be described in detail.

[0148] The process of the main blockchain sending business transaction summary information to the verification device, and the process of the verification device verifying the legality of the business transaction summary information based on the transaction execution results obtained from the side blockchain Z, are detailed below. Figure 9 The descriptions in the corresponding embodiments will not be elaborated here.

[0149] In this embodiment, when a sidechain node receives a transaction upload request carrying a business transaction from a business device, it can determine the transaction execution result corresponding to the business transaction based on the transaction upload request. The sidechain node belongs to side blockchain Z in a consortium blockchain, which also includes a main blockchain. Further, the sidechain node performs on-chain processing on the transaction execution result and the business transaction, i.e., stores them in side blockchain Z. Further, based on the transaction sequence number, business type identifier, and transaction execution result, the sidechain node can generate business transaction summary information corresponding to the business transaction and transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information. The business transaction summary information stored in the main blockchain is used by the main blockchain to send it to a verification device. The verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from side blockchain Z. As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network.

[0150] Please see Figure 7 , Figure 7 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 2 This blockchain-based data processing method can be executed by sidechain nodes in sidechain Z of a consortium blockchain. The consortium blockchain can provide... Figure 1 In the consortium blockchain 100, the side blockchain Z can be the above. Figure 1 Any one of the side blockchains. For example... Figure 7 As shown, the method may include at least the following steps.

[0151] Step S201: Obtain the transaction on-chain request carrying the business transaction sent by the business device; determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request; and perform on-chain processing on the transaction execution result and the business transaction.

[0152] Step S202: When the transaction execution result and the business transaction are successfully stored in the side blockchain Z, generate the business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier and transaction execution result; the transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0153] Step S203: Transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

[0154] For the specific implementation process of steps S201-S203, please refer to the above text. Figure 2 Steps S101-S103 in the corresponding embodiments will not be described in detail here.

[0155] Step S204: Based on the updated state tree, generate the updated state value B. c The Merkel path, based on the historical state tree, generates a target for historical state value D. c Merkel's path.

[0156] Specifically, the transaction execution result includes the write set corresponding to the business transaction, and the historical write set corresponding to the business transaction; the write set includes the updated state value B. c c is a positive integer and c is less than or equal to the total number of updated state values ​​in the write set; the history write set includes the history state value D. c .

[0157] When the transaction execution result and business transaction are successfully stored in the sidechain, the sidechain nodes additionally maintain the Merkle paths corresponding to all state values ​​in the write set, as well as the Merkle paths of all state values ​​in the historical write set. These two types of Merkle paths are not stored on-chain, therefore consensus is not required from the sidechain's consensus nodes. Please also refer to... Figure 8 , Figure 8 This application provides an example of a blockchain-based data processing scenario. Figure 4 .like Figure 8 As shown, for the meanings of the historical write set 20h, write set 20g, historical state tree 20i, and update state tree 20j, please refer to the above text. Figures 3-5The description in the text will not be repeated here. For the historical resource value 50 of the historical write set 20h, the corresponding Merkel path 1 includes H(1) and H(34); for the historical resource value 30 of the historical write set 20h, the corresponding Merkel path 2 includes H(2) and H(34); for the updated resource value 80 of the write set 20g, the corresponding Merkel path 3 includes H'(1) and H(34); for the updated resource value 0 of the write set 20g, the corresponding Merkel path 4 includes H'(2) and H(34).

[0158] Step S205: Associate the Merkel path corresponding to each updated state value in the write set with the write set and store it; associate the Merkel path corresponding to each historical state value in the historical write set with the historical write set and store it.

[0159] For details, please refer to [link / reference]. Figure 8 The sidechain node will write each updated state value in set 20g (e.g., ...). Figure 8 Each updated resource value in the database corresponds to a Merkel path and is associated with write set 20g and stored in database 70a; the sidechain node stores each historical state value (such as...) in historical write set 20h. Figure 8 Each historical resource value in the database corresponds to a Merkel path and is associated with the historical write set 20h and stored in the database 70a.

[0160] Optionally, the execution of steps S204-S205 can precede the execution of steps S202-S203. Optionally, the execution of steps S204-S205 can be synchronized with the execution of steps S202-S203.

[0161] In this embodiment, when a sidechain node receives a transaction upload request carrying a business transaction from a business device, it can determine the transaction execution result corresponding to the business transaction based on the transaction upload request. The sidechain node belongs to side blockchain Z in a consortium blockchain, which also includes a main blockchain. Further, the sidechain node performs on-chain processing on the transaction execution result and the business transaction, i.e., stores them in side blockchain Z. Further, based on the transaction sequence number, business type identifier, and transaction execution result, the sidechain node can generate business transaction summary information corresponding to the business transaction and transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information. The business transaction summary information stored in the main blockchain is used by the main blockchain to send it to a verification device. The verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from side blockchain Z. As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network.

[0162] Please see Figure 9 , Figure 9 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. Figure 3 .like Figure 9 As shown, the method may include at least the following steps.

[0163] Step S301: The verification device sends a first data acquisition request carrying a business type identifier and a transaction sequence number to the main blockchain in the consortium blockchain. This allows the main blockchain to return the business transaction summary information to the verification device when it determines that the verification device has the first access permission for the business transaction summary information based on the business type identifier and the transaction sequence number. The transaction sequence number represents the sequence number of the business transaction in the side blockchain Z. The side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from the side blockchain Z to the main blockchain. The business transaction summary information is generated by the first side chain node in the side blockchain Z based on the transaction sequence number, business type identifier, and transaction execution result when the transaction execution result is successfully stored in the side blockchain Z. The transaction execution result is determined by the first side chain node based on the transaction upload request sent by the business device. The transaction upload request carries the business transaction. The business type identifier represents the business type of the business processed by the side blockchain Z.

[0164] In this embodiment of the application, the verification device can be a non-blockchain node device that has verification requirements, including but not limited to... Figure 2 The aforementioned business device. It is understood that when the verification device is not a business device, the verification device can first obtain the transaction sequence number corresponding to the business transaction from the business device, or the sidechain node can transmit the transaction sequence number to the business device. This application embodiment does not limit the method by which the verification device obtains the transaction sequence number; it can be set according to the actual application scenario.

[0165] Please see also Figure 10 , Figure 10 This is an interactive flowchart of a blockchain-based data processing method provided in an embodiment of this application. Figure 10 As shown, in step S1, the verification device sends a first data acquisition request to the main chain node. The main blockchain where the main chain node resides and the side blockchains to which the side chain nodes belong constitute a consortium blockchain. This application example does not limit the number of side blockchains in the consortium blockchain; it can be set according to the actual application scenario. The first data acquisition request carries a business type identifier and a transaction sequence number. In step S2, the main chain node determines the acquisition permission. The main chain node verifies the verification device based on the business type identifier and transaction sequence number to determine if it has the acquisition permission. Specifically, this may include: whether the main chain node can obtain the corresponding business transaction summary information from the main blockchain based on the business type identifier and transaction sequence number. If it can obtain business transaction summary information including the business type identifier and transaction sequence number, then the verification device is determined to have the first acquisition permission. In step S3, if the verification device has the first acquisition permission, the main chain node returns the business transaction summary information including the business type identifier and transaction sequence number to the verification device.

[0166] Step S302: Send a second data acquisition request carrying the transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it will return the transaction execution result associated with the transaction sequence number to the verification device.

[0167] Specifically, when the verification device has the second access permission, the second sidechain node returns the Merkel path set associated with the transaction sequence number to the verification device.

[0168] like Figure 10 Step S4: The verification device sends a second data acquisition request to the sidechain node. The second data acquisition request carries a transaction sequence number. Step S5: The sidechain node determines the acquisition permission. Specifically, the sidechain node authenticates the verification device. This embodiment does not limit the authentication method; it can be set according to the actual application scenario. The main goal of authentication is to prevent the verification device from acquiring data it does not have permission to, thus ensuring the visibility of data in the sidechain. Step S6: The sidechain node returns the transaction execution result and the Merkel path set. In the scenario where the verification device has the second acquisition permission, the sidechain node returns the transaction execution result associated with the transaction sequence number and the Merkel path set associated with the transaction sequence number to the verification device. The Merkel path set can include the above... Figure 2 The corresponding embodiment includes the Merkel path for each updated state value in the write set and the Merkel path for each historical state value in the historical write set. It is understood that the Merkel path set can improve the accuracy of business transaction summary information verification.

[0169] Step S303: Verify the legality of the business transaction summary information based on the transaction execution result.

[0170] Specifically, the legality of the business transaction summary information is verified based on the transaction execution results and the Merkel path set.

[0171] Specifically, the following steps are taken: First hash value of the write set in the transaction execution result is generated, and third verification target field value is obtained from the first hash value; the write set includes the update status value of the first business object in the business transaction; second hash value of the historical write set in the transaction execution result is generated, and fourth verification target field value is obtained from the second hash value; the historical write set includes the historical status value of the first business object; third hash value of the read set in the transaction execution result is generated, and fifth verification target field value is obtained from the third hash value; the read set includes the historical status value of the second business object in the business transaction; the legality of the business transaction summary information is verified based on the third verification target field value, fourth verification target field value, fifth verification target field value, write set, historical write set, read set, and Merkel path set.

[0172] The specific process of verifying the legality of business transaction summary information based on the third verification target field value, the fourth verification target field value, the fifth verification target field value, the write set, the historical write set, the read set, and the Merkel path set may include: comparing the third verification target field value with the third target field value in the business transaction summary information to obtain a first comparison result; comparing the fourth verification target field value with the fourth target field value in the business transaction summary information to obtain a second comparison result; comparing the fifth verification target field value with the fifth target field value in the business transaction summary information to obtain a third comparison result; generating a verification historical state root hash based on the historical write set and the Merkel path associated with the historical write set in the Merkel path set; generating a verification update state root hash based on the write set and the Merkel path associated with the write set in the Merkel path set; re-executing the business transaction based on the read set to obtain a verification write set; and verifying the legality of the business transaction summary information based on the first comparison result, the second comparison result, the third comparison result, the verification historical state root hash, the verification update state root hash, and the verification write set.

[0173] The specific process of verifying the legality of business transaction summary information based on the first comparison result, the second comparison result, the third comparison result, the verification historical state root hash, the verification updated state root hash, and the verification write set may include: obtaining the first verification target field value from the verification historical state root hash, comparing the first verification target field value with the first target field value in the business transaction summary information to obtain the fourth comparison result; obtaining the second verification target field value from the verification updated state root hash, comparing the second verification target field value with the second target field value in the business transaction summary information to obtain the fifth comparison result;

[0174] The verification write set is compared with the write set to obtain the sixth comparison result; if any of the first, second, third, fourth, fifth, and sixth comparison results are different, then the business transaction summary information is determined to be illegal information; if all of the first, second, third, fourth, fifth, and sixth comparison results are the same, then the business transaction summary information is determined to be legal information.

[0175] If the verified business transaction summary information is invalid, a challenge sidechain transaction is generated based on the business type identifier, transaction sequence number, transaction execution result, and Merkel path set. The challenge sidechain transaction is then transmitted to the main blockchain to enable the main blockchain to reach a consensus on the challenge sidechain transaction. When the consensus passes the challenge sidechain transaction, the side blockchain Z is confirmed as an untrusted chain.

[0176] Please see again. Figure 10 Step S7: The verification device generates verification target field values. The known business transaction summary information includes the transaction sequence number, business type identifier, third target field value, fourth target field value, fifth target field value, first target field value, and second target field value. Therefore, the verification device generates the third verification target field value based on the write set in the transaction execution result, the fourth verification target field value based on the historical write set in the transaction execution result, and the fifth verification target field value based on the read set in the transaction execution result. The verification device generates the first verification target field value based on the historical write set and the corresponding Merkel path, and generates the second verification target field value based on the write set and the corresponding Merkel path.

[0177] Step S8: The verification device compares the verification target field value with the target field value to obtain the comparison result. Specifically, the verification device compares the first target field value with the first verification target field value. If they are the same, the first target field value in the transaction business summary information is determined to be valid; if they are different, the first target field value is determined to be invalid. The verification device compares the second target field value with the second verification target field value. If they are the same, the second target field value in the transaction business summary information is determined to be valid; if they are different, the second target field value is determined to be invalid. The verification device compares the third target field value with the third verification target field value. If they are the same, the third target field value in the transaction business summary information is determined to be valid; if they are different, the third target field value is determined to be invalid. The comparison of the remaining two target field values ​​is also done in the same way, so it will not be described in detail.

[0178] Furthermore, the verification device re-executes the business transaction based on the read set in the transaction execution result to obtain the verification write set. The verification write set is then compared with the write set to obtain the sixth comparison result. Based on the first, second, third, fourth, fifth, and sixth comparison results, the verification device determines the legality of the business transaction summary information.

[0179] Step S9: If the comparison result is different, a challenge sidechain transaction is generated. It is understood that if one of the above six comparison results is different, the verification device can generate a challenge sidechain transaction based on the business type identifier, transaction sequence number, transaction execution result, and Merkel path set. Step S10: The verification device sends the challenge sidechain transaction to the main chain node. Step S11: The main chain node verifies the challenge sidechain transaction. If the challenge sidechain transaction is successfully executed on the main blockchain, it proves that the sidechain is an untrusted chain. At this time, the main blockchain can suspend data interaction with this untrusted chain.

[0180] As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network.

[0181] Further, please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. Figure 1 The blockchain-based data processing device can run on a sidechain node, which belongs to side blockchain Z in a consortium blockchain. The consortium blockchain also includes a main blockchain. The aforementioned blockchain-based data processing device 1 can be used to execute the corresponding steps in the methods provided in the embodiments of this application. Figure 11 As shown, the blockchain-based data processing device 1 may include: a transaction execution module 11, a first generation module 12, and a digest transmission module 13.

[0182] The transaction execution module 11 is used to obtain the transaction on-chain request carrying the business transaction sent by the business device, determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request, and perform on-chain processing on the transaction execution result and the business transaction.

[0183] The first generation module 12 is used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier and transaction execution result when the transaction execution result and the business transaction are successfully stored in the side blockchain Z. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0184] The summary transmission module 13 is used to transmit business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

[0185] The specific functional implementations of the transaction execution module 11, the first generation module 12, and the digest transmission module 13 can be found in the above description. Figure 2 Steps S101-S103 in the corresponding embodiment will not be described again here.

[0186] Please see again Figure 11 The blockchain-based data processing device 1 may also include: a status update module 14.

[0187] The state update module 14 is used to update the historical state tree according to the transaction execution result to obtain the updated state tree; the historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z;

[0188] The first generation module 12 is specifically used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, historical state tree and update state tree.

[0189] The specific functional implementation methods of the state update module 14 and the first generation module 12 can be found in the above description. Figure 2 Steps S101-S102 in the corresponding embodiment will not be described again here.

[0190] Please see again Figure 11 The first generation module 12 may include: a first acquisition unit 121, a second acquisition unit 122, and a first generation unit 123.

[0191] The first acquisition unit 121 is used to acquire the historical state root hash of the historical state tree and to acquire the value of the first target field from the historical state root hash.

[0192] The second acquisition unit 122 is used to acquire the update state root hash of the update state tree and to acquire the value of the second target field from the update state root hash.

[0193] The first generation unit 123 is used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, first target field value and second target field value.

[0194] The specific functional implementation methods of the first acquisition unit 121, the second acquisition unit 122, and the first generation unit 123 can be found in the above description. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0195] Please see again Figure 11The state update module 14 is specifically used to update the historical state tree based on the write set in the transaction execution result to obtain the updated state tree; the full historical state value includes the historical write set in the transaction execution result; the write set includes the updated state value of the first business object in the business transaction; the historical write set includes the historical state value of the first business object;

[0196] The first generation unit 123 may include: a first generation subunit 1231, a second generation subunit 1232, a third generation subunit 1233, and a fourth generation subunit 1234.

[0197] The first generation subunit 1231 is used to generate the first hash value of the write set and obtain the value of the third target field from the first hash value;

[0198] The second generation subunit 1232 is used to generate the second hash value of the historical write set and obtain the value of the fourth target field from the second hash value;

[0199] The third generation subunit 1233 is used to generate the third hash value of the read set in the transaction execution result, and to obtain the value of the fifth target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction;

[0200] The fourth generation sub-unit 1234 is used to combine the transaction sequence number, business type identifier, third target field value, fourth target field value, fifth target field value, first target field value, and second target field value into business transaction summary information corresponding to the business transaction.

[0201] The specific functional implementations of the first generation subunit 1231, the second generation subunit 1232, the third generation subunit 1233, and the fourth generation subunit 1234 can be found above. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0202] Please see again Figure 11 The transaction execution result includes the write set corresponding to the business transaction, and the historical write set corresponding to the business transaction; the write set includes the updated status value B. c c is a positive integer and c is less than or equal to the total number of updated state values ​​in the write set; the history write set includes the history state value D. c ;

[0203] The blockchain-based data processing device 1 may further include: a second generation module 15 and an associated storage module 16.

[0204] The second generation module 15 is used to generate the updated state value B based on the updated state tree. c The Merkel path, based on the historical state tree, generates a target for historical state value D.c Merkel's path;

[0205] The associated storage module 16 is used to associate and store the Merkel path corresponding to each updated state value in the write set with the write set.

[0206] The associated storage module 16 is also used to associate and store the Merkel path corresponding to each historical state value in the historical write set with the historical write set.

[0207] The specific functional implementation methods of the second generation module 15 and the associated storage module 16 can be found in the above description. Figure 7 Steps S204-S205 in the corresponding embodiment will not be described again here.

[0208] Please see again Figure 11 The transaction execution module 11 may include: a first determining unit 111, a third obtaining unit 112, a fourth obtaining unit 113, a second determining unit 114, and a third determining unit 115.

[0209] The first determining unit 111 is used to determine the business type of the business transaction. If the business type of the business transaction matches the business type identifier, then according to the transaction on-chain request, the transaction execution function in the smart contract that matches the business type of the business transaction is called.

[0210] The third acquisition unit 112 is used to acquire the historical state value of the second business object in the business transaction according to the transaction execution function, and combine the historical state value of the second business object into a read set of the business transaction.

[0211] The fourth acquisition unit 113 is used to acquire the updated state value of the first business object in the business transaction generated when the transaction execution function is executed, based on the business transaction and the read set execution transaction execution function;

[0212] The second determining unit 114 is used to determine the updated state value of the first business object as the write set of the business transaction, obtain the state value of the first business object before the execution of the transaction execution function, and determine the obtained state value as the historical write set of the business transaction.

[0213] The third determining unit 115 is used to determine the transaction execution result corresponding to the business transaction based on the write set, the historical write set, and the read set.

[0214] The specific functional implementation methods of the first determining unit 111, the third acquiring unit 112, the fourth acquiring unit 113, the second determining unit 114, and the third determining unit 115 can be found above. Figure 2 Step S101 in the corresponding embodiment will not be described again here.

[0215] Please see again Figure 11 The transaction execution module 11 may include: a fifth acquisition unit 116, a second generation unit 117, a block broadcasting unit 118, and a block addition unit 119.

[0216] The fifth acquisition unit 116 is used to acquire the block with the largest generation timestamp from the side blockchain Z when the side chain node has consensus permissions, and use the block header hash value of the parent block as the parent block hash value.

[0217] The second generation unit 117 is used to generate a sidechain block based on the parent block hash value, the business transaction carrying the transaction sequence number, the transaction execution result, and the updated state tree generated based on the transaction execution result; the generation timestamp of the sidechain block is used to update the maximum generation timestamp of the side blockchain Z.

[0218] Block broadcasting unit 118 is used to sign the sidechain block using the node private key corresponding to the sidechain node, obtain the signature information, and broadcast the sidechain block carrying the signature information to the consensus node in the side blockchain Z.

[0219] The block adding unit 119 is used to add the sidechain block to the sidechain Z when the consensus nodes in the sidechain Z reach a consensus on the sidechain block and return the transaction sequence number to the business device.

[0220] The specific functional implementation methods of the fifth acquisition unit 116, the second generation unit 117, the block broadcasting unit 118, and the block adding unit 119 can be found in the above description. Figure 2 Step S101 in the corresponding embodiment will not be described again here.

[0221] Please see again Figure 11 The digest transmission module 13 may include a digest encryption unit 131 and an information uploading unit 132.

[0222] The digest encryption unit 131 is used to encrypt the business transaction digest information using the main blockchain's main chain public key to obtain encrypted digest information;

[0223] The information upload unit 132 is used to call the information upload function corresponding to the business type identifier in the main blockchain. Through the information upload function, the encrypted digest information is uploaded to the main blockchain, so that the main chain node in the main blockchain can use the main chain private key of the main blockchain to decrypt the encrypted digest information. When the decryption result is a successful decryption result, the business transaction digest information corresponding to the successful decryption result is stored.

[0224] The specific functional implementation methods of the digest encryption unit 131 and the information uploading unit 132 can be found in the above description. Figure 2Step S103 in the corresponding embodiment will not be described again here.

[0225] In this embodiment, when a sidechain node receives a transaction upload request carrying a business transaction from a business device, it can determine the transaction execution result corresponding to the business transaction based on the transaction upload request. The sidechain node belongs to side blockchain Z in a consortium blockchain, which also includes a main blockchain. Further, the sidechain node performs on-chain processing on the transaction execution result and the business transaction, i.e., stores them in side blockchain Z. Further, based on the transaction sequence number, business type identifier, and transaction execution result, the sidechain node can generate business transaction summary information corresponding to the business transaction and transmit the business transaction summary information to the main blockchain so that the main blockchain stores the business transaction summary information. The business transaction summary information stored in the main blockchain is used by the main blockchain to send it to a verification device. The verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from side blockchain Z. As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network.

[0226] Further, please see Figure 12 , Figure 12 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. Figure 2 The aforementioned blockchain-based data processing device 2 can operate on a verification device, and this device can be used to execute the corresponding steps in the methods provided in the embodiments of this application. For example... Figure 12 As shown, the blockchain-based data processing device 2 may include: a first sending module 21, a second sending module 22, and an information verification module 23.

[0227] The first sending module 21 is used to send a first data acquisition request carrying a business type identifier and a transaction sequence number to the main blockchain in the consortium blockchain, so that when the main blockchain determines that the verification device has the first acquisition permission for the business transaction summary information based on the business type identifier and the transaction sequence number, it returns the business transaction summary information to the verification device. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z. The side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from the side blockchain Z to the main blockchain. The business transaction summary information is generated by the first side chain node in the side blockchain Z based on the transaction sequence number, the business type identifier, and the transaction execution result when the transaction execution result and the business transaction are successfully stored in the side blockchain Z. The transaction execution result is determined by the first side chain node based on the transaction on-chain request when it receives the transaction on-chain request sent by the business device. The transaction on-chain request carries the business transaction. The business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0228] The second sending module 22 is used to send a second data acquisition request carrying a transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it will return the transaction execution result associated with the transaction sequence number to the verification device.

[0229] The information verification module 23 is used to verify the legality of the business transaction summary information based on the transaction execution result.

[0230] The specific functional implementation methods of the first sending module 21, the second sending module 22, and the information verification module 23 can be found above. Figure 9 Steps S301-S303 in the corresponding embodiment will not be described again here.

[0231] Please see again Figure 12 The second sending module 22 is also used to obtain the Merkel path set associated with the transaction sequence number returned by the second sidechain node when it determines that the verification device has the second acquisition permission;

[0232] The information verification module 23 is specifically used to verify the legality of the business transaction summary information based on the transaction execution result and the Merkel path set.

[0233] The specific functional implementation methods of the second sending module 22 and the information verification module 23 can be found in the above description. Figure 9 Steps S302-S303 in the corresponding embodiment will not be described again here.

[0234] Please see again Figure 12 The information verification module 23 may include: a first generation unit 231, a second generation unit 232, a third generation unit 233, and a legal verification unit 234.

[0235] The first generation unit 231 is used to generate the first hash value of the write set in the transaction execution result, and to obtain the value of the third verification target field from the first hash value; the write set includes the update status value of the first business object in the business transaction.

[0236] The second generation unit 232 is used to generate the second hash value of the historical write set in the transaction execution result, and to obtain the value of the fourth verification target field from the second hash value; the historical write set includes the historical state value of the first business object;

[0237] The third generation unit 233 is used to generate the third hash value of the read set in the transaction execution result, and to obtain the value of the fifth verification target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction;

[0238] The legality verification unit 234 is used to verify the legality of the business transaction summary information based on the third verification target field value, the fourth verification target field value, the fifth verification target field value, the write set, the historical write set, the read set, and the Merkel path set.

[0239] The specific functional implementation methods of the first generation unit 231, the second generation unit 232, the third generation unit 233, and the legality verification unit 234 can be found above. Figure 9 Step S303 in the corresponding embodiment will not be described again here.

[0240] Please see again Figure 12 The valid verification unit 234 may include: a first comparison subunit 2341, a second comparison subunit 2342, a third comparison subunit 2343, a first generation subunit 2344, a second generation subunit 2345, and a valid verification subunit 2346.

[0241] The first comparison subunit 2341 is used to compare the value of the third verification target field with the value of the third target field in the business transaction summary information to obtain the first comparison result;

[0242] The second comparison subunit 2342 is used to compare the value of the fourth verification target field with the value of the fourth target field in the business transaction summary information to obtain the second comparison result;

[0243] The third comparison subunit 2343 is used to compare the value of the fifth verification target field with the value of the fifth target field in the business transaction summary information to obtain the third comparison result;

[0244] The first generation subunit 2344 is used to generate a verification history state root hash based on the history write set and the Merkel path associated with the history write set in the Merkel path set.

[0245] The second generation subunit 2345 is used to generate a verification update state root hash based on the write set and the Merkel path associated with the write set in the Merkel path set.

[0246] The valid verification subunit 2346 is used to re-execute the business transaction based on the read set to obtain the valid write set, and to verify the validity of the business transaction summary information based on the first comparison result, the second comparison result, the third comparison result, the verification historical state root hash, the verification update state root hash, and the valid write set.

[0247] The specific functional implementation methods of the first comparison subunit 2341, the second comparison subunit 2342, the third comparison subunit 2343, the first generation subunit 2344, the second generation subunit 2345, and the validity verification subunit 2346 can be found above. Figure 9 Step S303 in the corresponding embodiment will not be described again here.

[0248] Please see again Figure 12 The valid verification subunit 2346 may include: a first acquisition subunit 23461, a second acquisition subunit 23462, a set comparison subunit 23463, a first determination subunit 23464, and a second determination subunit 23465.

[0249] The first acquisition subunit 23461 is used to obtain the value of the first verification target field in the root hash of the verification history status, compare the value of the first verification target field with the value of the first target field in the business transaction summary information, and obtain the fourth comparison result.

[0250] The second acquisition subunit 23462 is used to obtain the value of the second verification target field in the root hash of the verification update status, compare the value of the second verification target field with the value of the second target field in the business transaction summary information, and obtain the fifth comparison result.

[0251] Set comparison subunit 23463 is used to compare the verification write set with the write set to obtain the sixth comparison result;

[0252] The first determining subunit 23464 is used to determine that the business transaction summary information is illegal information if there is a comparison result that is different among the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result.

[0253] The second determining subunit 23465 is used to determine that the business transaction summary information is legal information if the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result are all the same.

[0254] The specific functional implementation methods of the first acquisition subunit 23461, the second acquisition subunit 23462, the set comparison subunit 23463, the first determination subunit 23464, and the second determination subunit 23465 can be found above. Figure 9 Step S203 in the corresponding embodiment will not be described again here.

[0255] Please see again Figure 12 The blockchain-based data processing device 2 may also include: a transaction generation module 24 and a transaction transmission module 25.

[0256] The transaction generation module 24 is used to generate a challenge sidechain transaction based on the business type identifier, transaction sequence number, transaction execution result, and Merkel path set if the verified business transaction summary information is illegal.

[0257] The transaction transmission module 25 is used to transmit the challenge sidechain transaction to the main blockchain so that the main blockchain can reach a consensus on the challenge sidechain transaction, and when the consensus passes the challenge sidechain transaction, it confirms that the sidechain Z is an untrusted chain.

[0258] The specific functional implementation methods of the transaction generation module 24 and the transaction transmission module 25 can be found in the above description. Figure 9 Step S303 in the corresponding embodiment will not be described again here.

[0259] As described above, a sidechain node belonging to sidechain Z can execute business transactions that match the business type processed by sidechain Z, and store the transaction execution results and business transactions in sidechain Z. This avoids the excessive load on the main blockchain in the blockchain network, thus reducing the computational resources of the main blockchain. Since the main blockchain only stores business transaction summary information, its storage resources are also reduced. Furthermore, both the transaction execution results stored in sidechain Z and the business transaction summary information stored in the main blockchain can be sent to the verification device. Therefore, the verification device can verify the transaction execution results sent by sidechain Z and the business transaction summary information sent by the main blockchain, thereby determining the legality of the business transaction summary information and ensuring the security of the blockchain network.

[0260] Further, please see Figure 13 , Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 13As shown, the computer device 1000 may include: at least one processor 1001, such as a CPU; at least one network interface 1004; a user interface 1003; a memory 1005; and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. In some embodiments, the user interface 1003 may include a display screen and a keyboard, and 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 aforementioned processor 1001. Figure 13 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.

[0261] exist Figure 13 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0262] Obtain the transaction on-chain request sent by the business device, carrying the business transaction; determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request; and perform on-chain processing on the transaction execution result and the business transaction.

[0263] When the transaction execution result and the business transaction are successfully stored in the side blockchain Z, a business transaction summary information corresponding to the business transaction is generated based on the transaction sequence number, business type identifier, and transaction execution result. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z.

[0264] The business transaction summary information is transmitted to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used by the main blockchain to send to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

[0265] It should be understood that the computer device 1000 described in the embodiments of this application can perform the data processing methods or apparatus based on blockchain described in the preceding embodiments, and will not be repeated here. In addition, the beneficial effects of using the same method will also not be repeated.

[0266] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the blockchain-based data processing methods or apparatus described in the preceding embodiments, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0267] The aforementioned computer-readable storage medium can be the internal storage unit of the blockchain-based data processing apparatus provided in any of the foregoing embodiments or the computer device, such as the hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0268] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, enabling the computer device to perform the blockchain-based data processing methods or apparatus described in the preceding embodiments, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

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

[0270] 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 components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0271] 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 blockchain, characterized in that, The method is executed by a sidechain node, which belongs to sidechain Z in a consortium blockchain. The consortium blockchain also includes a main blockchain. The method includes: Obtain a transaction on-chain request carrying a business transaction sent by a business device; determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request; and perform on-chain processing on the transaction execution result and the business transaction. The historical state tree is updated based on the transaction execution result to obtain an updated state tree; the historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z. When the transaction execution result and the business transaction are successfully stored in the side blockchain Z, a business transaction summary information corresponding to the business transaction is generated based on the transaction sequence number, business type identifier, transaction execution result, historical state tree, and updated state tree; the transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z. The business transaction summary information is transmitted to the main blockchain so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to the verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

2. The method according to claim 1, characterized in that, The step of generating business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, historical state tree, and updated state tree includes: Obtain the historical state root hash of the historical state tree, and retrieve the value of the first target field from the historical state root hash; Obtain the update state root hash of the update state tree, and retrieve the value of the second target field from the update state root hash; Based on the transaction sequence number, business type identifier, transaction execution result, first target field value, and second target field value, generate business transaction summary information corresponding to the business transaction.

3. The method according to claim 2, characterized in that, The step of updating the historical state tree based on the transaction execution result to obtain an updated state tree includes: The historical state tree is updated based on the write set in the transaction execution result to obtain an updated state tree; the full historical state value includes the historical write set in the transaction execution result; the write set includes the updated state value of the first business object in the business transaction; the historical write set includes the historical state value of the first business object; The step of generating business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, first target field value, and second target field value includes: Generate a first hash value for the write set, and obtain the value of the third target field from the first hash value; Generate a second hash value for the historical write set, and obtain the value of the fourth target field from the second hash value; Generate a third hash value for the read set in the transaction execution result, and obtain the value of the fifth target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction; The transaction sequence number, business type identifier, the third target field value, the fourth target field value, the fifth target field value, the first target field value, and the second target field value are combined to form the business transaction summary information corresponding to the business transaction.

4. The method according to claim 1, characterized in that, The transaction execution result includes the write set corresponding to the business transaction and the historical write set corresponding to the business transaction; the write set includes the updated status value B. c c is a positive integer and c is less than or equal to the total number of updated state values ​​in the write set; The historical write set includes historical state values ​​D. c ; The method further includes: Based on the updated state tree, generate the updated state value B. c The Merkel path, based on the historical state tree, generates a value D for the historical state. c Merkel's path; The Merkel path corresponding to each updated state value in the write set is associated with and stored in the write set. The Merkel path corresponding to each historical state value in the historical write set is associated with and stored in the historical write set.

5. The method according to claim 1, characterized in that, The step of determining the transaction execution result corresponding to the business transaction based on the transaction on-chain request includes: The business type of the business transaction is determined. If the business type of the business transaction matches the business type identifier, the transaction execution function in the smart contract that matches the business type of the business transaction is called according to the transaction on-chain request. According to the transaction execution function, the historical state value of the second business object in the business transaction is obtained, and the historical state value of the second business object is combined into the read set of the business transaction; Execute the transaction execution function based on the business transaction and the read set, and obtain the updated state value of the first business object in the business transaction generated when the transaction execution function is executed; The updated state value of the first business object is determined as the write set of the business transaction. The state value of the first business object before the execution of the transaction execution function is obtained, and the obtained state value is determined as the historical write set of the business transaction. The transaction execution result corresponding to the business transaction is determined based on the write set, the historical write set, and the read set.

6. The method according to claim 1, characterized in that, The on-chain processing of the transaction execution result and the business transaction includes: When the sidechain node has consensus permissions, it obtains the block with the largest generation timestamp from the side blockchain Z as the parent block, and uses the block header hash value of the parent block as the parent block hash value. A sidechain block is generated based on the parent block hash value, the business transaction carrying the transaction sequence number, the transaction execution result, and the updated state tree generated based on the transaction execution result; the generation timestamp of the sidechain block is used to update the maximum generation timestamp of the side blockchain Z; Using the private key of the node corresponding to the sidechain node, the sidechain block is signed to obtain signature information, and the sidechain block carrying the signature information is broadcast to the consensus node in the side blockchain Z; When it is determined that the consensus nodes in the side blockchain Z have reached a consensus on the side chain block, the side chain block is added to the side blockchain Z, and the transaction sequence number is returned to the service device.

7. The method according to claim 1, characterized in that, The step of transmitting the business transaction summary information to the main blockchain includes: The business transaction summary information is encrypted using the main blockchain's public key to obtain encrypted summary information; The information upload function corresponding to the business type identifier in the main blockchain is invoked. The encrypted digest information is uploaded to the main blockchain through the information upload function, so that the main chain node in the main blockchain can decrypt the encrypted digest information using the main chain private key of the main blockchain. When the decryption result is a successful decryption result, the business transaction digest information corresponding to the successful decryption result is stored.

8. A data processing method based on blockchain, characterized in that, include: The verification device sends a first data acquisition request carrying a business type identifier and a transaction sequence number to the main blockchain in the consortium blockchain. When the main blockchain determines that the verification device has first-level access permission for business transaction summary information based on the business type identifier and transaction sequence number, it returns the business transaction summary information to the verification device. The transaction sequence number represents the sequence number of the business transaction in side blockchain Z. Side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from side blockchain Z to the main blockchain. The business transaction summary information is stored by the first side chain node in side blockchain Z upon transaction execution and successful storage of the business transaction. The side blockchain Z is generated based on the transaction sequence number, the business type identifier, the transaction execution result, the historical state tree, and the updated state tree. The transaction execution result is determined by the first side chain node when it receives a transaction upload request sent by a business device, based on the transaction upload request. The transaction upload request carries the business transaction. The business type identifier is used to characterize the business type of the business processed by the side blockchain Z. The updated state tree is obtained by the first side chain node updating the historical state tree based on the transaction execution result. The historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z. Send a second data acquisition request carrying the transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it returns the transaction execution result associated with the transaction sequence number to the verification device; Based on the transaction execution result, verify the legality of the business transaction summary information.

9. The method according to claim 8, characterized in that, The method further includes: Obtain the set of Merkel paths associated with the transaction sequence number returned by the second sidechain node when it determines that the verification device has the second acquisition permission; The step of verifying the legality of the business transaction summary information based on the transaction execution result includes: The legality of the business transaction summary information is verified based on the transaction execution result and the Merkel path set.

10. The method according to claim 9, characterized in that, The step of verifying the legality of the business transaction summary information based on the transaction execution result and the Merkel path set includes: Generate a first hash value for the write set in the transaction execution result, and obtain the value of the third verification target field from the first hash value; the write set includes the update status value of the first business object in the business transaction; Generate a second hash value for the historical write set in the transaction execution result, and obtain the value of the fourth verification target field from the second hash value; the historical write set includes the historical state values ​​of the first business object; Generate a third hash value for the read set in the transaction execution result, and obtain the value of the fifth verification target field from the third hash value; the read set includes the historical state value of the second business object in the business transaction; The legality of the business transaction summary information is verified based on the third verification target field value, the fourth verification target field value, the fifth verification target field value, the write set, the historical write set, the read set, and the Merkel path set.

11. The method according to claim 10, characterized in that, The step of verifying the legality of the business transaction summary information based on the third verification target field value, the fourth verification target field value, the fifth verification target field value, the write set, the historical write set, the read set, and the Merkel path set includes: The value of the third verification target field is compared with the value of the third target field in the business transaction summary information to obtain a first comparison result; The value of the fourth verification target field is compared with the value of the fourth target field in the business transaction summary information to obtain a second comparison result; The value of the fifth verification target field is compared with the value of the fifth target field in the business transaction summary information to obtain a third comparison result; Generate a verification history state root hash based on the historical write set and the Merkel paths associated with the historical write set in the Merkel path set; Generate a verification update state root hash based on the write set and the Merkel paths associated with the write set in the Merkel path set; The business transaction is re-executed based on the read set to obtain the verification write set. The legality of the business transaction summary information is verified based on the first comparison result, the second comparison result, the third comparison result, the verification history state root hash, the verification update state root hash, and the verification write set.

12. The method according to claim 11, characterized in that, The step of verifying the legality of the business transaction summary information based on the first comparison result, the second comparison result, the third comparison result, the verification history state root hash, the verification update state root hash, and the verification write set includes: The first verification target field value is obtained from the root hash of the verification history state, and the first verification target field value is compared with the first target field value in the business transaction summary information to obtain a fourth comparison result; The second verification target field value is obtained from the root hash of the verification update status, and the second verification target field value is compared with the second target field value in the business transaction summary information to obtain the fifth comparison result; The verification write set is compared with the write set to obtain the sixth comparison result; If any of the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result are different, then the business transaction summary information is determined to be illegal information. If the first comparison result, the second comparison result, the third comparison result, the fourth comparison result, the fifth comparison result, and the sixth comparison result are all the same, then the business transaction summary information is determined to be legitimate information.

13. The method according to claim 9, characterized in that, The method further includes: If the business transaction summary information is verified to be invalid, a challenge sidechain transaction is generated based on the business type identifier, the transaction sequence number, the transaction execution result, and the Merkel path set. The challenge sidechain transaction is transmitted to the main blockchain so that the main blockchain reaches a consensus on the challenge sidechain transaction, and when the consensus passes the challenge sidechain transaction, the sidechain Z is confirmed as an untrusted chain.

14. A data processing device based on blockchain, characterized in that, The device operates on a sidechain node, which belongs to sidechain Z in a consortium blockchain. The consortium blockchain also includes a main blockchain. The device comprises: The transaction execution module is used to obtain a transaction on-chain request carrying a business transaction sent by a business device, determine the transaction execution result corresponding to the business transaction based on the transaction on-chain request, and perform on-chain processing on the transaction execution result and the business transaction. The state update module is used to update the historical state tree according to the transaction execution result to obtain an updated state tree; the historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z; The first generation module is used to generate business transaction summary information corresponding to the business transaction based on the transaction sequence number, business type identifier, transaction execution result, historical state tree, and updated state tree when the transaction execution result and the business transaction are successfully stored in the side blockchain Z. The transaction sequence number is used to represent the sequence number of the business transaction in the side blockchain Z, and the business type identifier is used to represent the business type of the business processed by the side blockchain Z. A summary transmission module is used to transmit the business transaction summary information to the main blockchain, so that the main blockchain stores the business transaction summary information; the business transaction summary information stored in the main blockchain is used to be sent by the main blockchain to a verification device; the verification device is used to verify the legality of the business transaction summary information based on the transaction execution result obtained from the side blockchain Z.

15. A data processing device based on blockchain, characterized in that, The device operates on a verification device, and the device includes: The first sending module is used to send a first data acquisition request carrying a business type identifier and a transaction sequence number to the main blockchain in the consortium blockchain. This allows the main blockchain to return the business transaction summary information to the verification device when it determines that the verification device has first access permission for the business transaction summary information based on the business type identifier and transaction sequence number. The transaction sequence number represents the sequence number of the business transaction in the side blockchain Z. The side blockchain Z belongs to the consortium blockchain. The business transaction summary information is transmitted from the side blockchain Z to the main blockchain. The business transaction summary information is generated by the first side chain node in the side blockchain Z based on the transaction execution result and the success of the business transaction. When stored in the side blockchain Z, the transaction is generated based on the transaction sequence number, the business type identifier, the transaction execution result, the historical state tree, and the updated state tree. The transaction execution result is determined by the first side chain node based on the transaction on-chain request sent by the business device. The transaction on-chain request carries the business transaction. The business type identifier is used to characterize the business type of the business processed by the side blockchain Z. The updated state tree is obtained by the first side chain node updating the historical state tree based on the transaction execution result. The historical state tree is a Merkle tree generated based on all historical state values ​​in the side blockchain Z. The second sending module is used to send a second data acquisition request carrying the transaction sequence number to the side blockchain Z, so that when the second side chain node in the side blockchain Z determines that the verification device has the second acquisition permission, it will return the transaction execution result associated with the transaction sequence number to the verification device. The information verification module is used to verify the legality of the business transaction summary information based on the transaction execution result.

16. 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 invoke the computer programs to cause the computer device to perform the method according to any one of claims 1 to 13.

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

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

Images