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

Abstract

The present application discloses a data processing method, apparatus, device and readable storage medium based on blockchain, the method comprising: obtaining a transaction verification request sent by a first node in a first business chain; calling a transaction verification contract on a relay chain based on the transaction verification request, and obtaining a target index pair in the relay chain through the transaction verification contract and the chain information to be verified; the target index pair is generated when storing transaction block information through a data storage contract; the target index pair is used to indicate a mapping relationship between a target index key and a target index value, and the target index key contains block storage parameters associated with the transaction block information; based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value, the transaction data to be verified is subjected to transaction verification, and the verification result is sent to the first node. By adopting the present application, the reliability of the verification result can be improved in the cross-chain transaction business, thereby improving the security of the cross-chain transaction business.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain-based data processing method, apparatus, device, and readable storage medium. Background Art

[0002] With the rapid development of blockchain technology, many business systems now use blockchain to store relevant business data. Typically, different business systems are configured with different blockchains, and data exchange between these different blockchains is often required due to business needs. This data exchange between different blockchains is often referred to as cross-chain transactions.

[0003] When conducting cross-chain transactions between different blockchains, it's generally necessary to verify the validity and existence of the cross-chain transaction. Existing cross-chain transaction verification methods primarily involve the business party requiring transaction verification directly invoking a Simplified Payment Verification (SPV) node (an SPV node is a blockchain node that typically doesn't participate in consensus but serves as a service node for transaction verification). This invocation of the SPV node executes the SPV node's function of providing external transaction verification. However, since SPV nodes operate on a single machine, if the invoked SPV node fails or is malicious, transaction verification can easily fail, potentially preventing the cross-chain transaction from completing successfully. In other words, existing cross-chain transaction verification methods result in low security and reliability. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain-based data processing method, apparatus, device, and readable storage medium, which can improve the reliability of verification results in cross-chain transaction business, thereby improving the security of cross-chain transaction business.

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

[0006] Obtaining a transaction verification request sent by a first node in a first business chain; the transaction verification request carries information about the chain to be verified and a transaction identifier of the transaction data to be verified;

[0007] Based on the transaction verification request, the transaction verification contract on the relay chain is called, and the target index pair is obtained in the relay chain through the transaction verification contract and the chain information to be verified. The target index pair is generated when the transaction block information is stored in the data storage contract. The transaction block information is sent by the second node in the second business chain. The target index pair is used to indicate the mapping relationship between the target index key and the target index value. The target index key contains the block storage parameters associated with the transaction block information. The block storage parameters match the chain information to be verified. The target index value contains the transaction block information. The first business chain and the second business chain are different.

[0008] Based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value, the transaction data to be verified is subjected to transaction verification, and the verification result is sent to the first node.

[0009] On the one hand, an embodiment of the present application provides a data processing device based on blockchain, including:

[0010] A verification request acquisition module is configured to acquire a transaction verification request sent by a first node in a first business chain; the transaction verification request carries information about the chain to be verified and a transaction identifier of the transaction data to be verified;

[0011] The index pair acquisition module is used to call the transaction verification contract on the relay chain based on the transaction verification request;

[0012] The index pair acquisition module is further used to obtain a target index pair in the relay chain through the transaction verification contract and the chain information to be verified; the target index pair is generated when the transaction block information is stored through the data storage contract, and the transaction block information is sent by the second node in the second business chain; the target index pair is used to indicate the mapping relationship between the target index key and the target index value, the target index key includes the block storage parameters associated with the transaction block information, and the block storage parameters match the chain information to be verified; the target index value includes the transaction block information; the first business chain and the second business chain are different;

[0013] A transaction verification module, configured to perform transaction verification on the transaction data to be verified based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value;

[0014] The transaction verification module is further configured to send the verification result to the first node.

[0015] In one embodiment, the blockchain-based data processing device further includes:

[0016] A storage request acquisition module, configured to acquire a data storage request for transaction block information sent by the second node; the data storage request carries the block height of the block to which the transaction block information belongs;

[0017] A storage parameter determination module is used to call the data storage contract in the relay chain according to the data storage request, and determine the chain identifier of the second business chain and the block height of the block to which the transaction block information belongs as the block storage parameters through the storage logic of the data storage contract;

[0018] A key determination module, used to determine the target index key according to the block storage parameters;

[0019] a value determination module, configured to determine a target index value based on an initial index value corresponding to the target index key, transaction block information, and an identifier of the second node;

[0020] The data storage module is used to store the target index pair consisting of the target index key and the target index value into the relay chain.

[0021] In one embodiment, the key determination module includes:

[0022] An index pair traversal unit, configured to traverse N stored index pairs in the relay chain; a stored index pair is configured to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes stored block storage parameters associated with stored block information;

[0023] a key determining unit configured to determine, if among the stored block storage parameters included in the N stored index pairs, a target stored block storage parameter identical to the block storage parameter, the stored index key to which the target stored block storage parameter belongs as the target index key;

[0024] The key determination unit is further configured to determine the index key composed of the block storage parameters as the target index key if there is no target stored block storage parameter identical to the block storage parameter among the stored block storage parameters included in the N stored index pairs.

[0025] In one embodiment, the initial index value includes M association mapping relationships; one association mapping relationship is used to indicate an association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; M is a positive integer;

[0026] The value determination module includes:

[0027] A serialization processing unit, used to serialize the transaction block information to obtain target serialized block information;

[0028] Block information traversal unit, used to traverse M stored serialized block information;

[0029] an index value determining unit, configured to, if target stored serialized block information identical to the target serialized block information exists among the M stored serialized block information, add the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information, and increment the number of stored node identifiers in the target stored upload node identifier set to obtain a target index value;

[0030] The index value determination unit is further used to generate a target upload node identifier set corresponding to the target serialized block information based on the node identifier of the second node if the target stored serialized block information does not exist in the M stored serialized block information, use the number of node identifiers of the second node as the number of target node identifiers of the target upload node identifier set, associate the target serialized block information, the target upload node identifier set, and the number of target node identifiers and add them to the initial index key to obtain the target index value.

[0031] In one embodiment, the value determination module further includes:

[0032] A set traversal unit, used to traverse the stored upload node identifier set corresponding to the target stored serialized block information;

[0033] a value determining unit, configured to determine the initial index value as the target index value if the node identifier of the second node exists in the stored upload node identifier set corresponding to the target stored serialized block information;

[0034] The step execution unit is used to add the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information if the node identifier of the second node does not exist in the stored upload node identifier set corresponding to the target stored serialized block information, and increment the number of stored node identifiers in the target stored upload node identifier set to obtain a target index value.

[0035] In one embodiment, the chain information to be verified includes the chain identifier of the second business chain and the block height of the block to which the transaction data to be verified belongs;

[0036] The index pair acquisition module includes:

[0037] A traversal unit, configured to traverse N stored index pairs in the relay chain through the verification logic in the transaction verification contract; a stored index pair is used to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes a stored block storage parameter associated with the stored block information; the stored index key includes the stored block storage parameter, and the stored block storage parameter includes a stored chain identifier and a stored block height; the stored chain identifier is the chain identifier of the stored business chain, the stored block height is the block height of the block to which the stored block information belongs, and the block to which the stored block information belongs belongs to the stored business chain; the stored block information includes transaction block information, the N stored index pairs include an index pair corresponding to the transaction block information, the stored chain identifier in the index pair corresponding to the transaction block information is the chain identifier of the second business chain, and the stored block height in the index pair corresponding to the transaction block information is the block height of the block to which the transaction block information belongs, and the block height of the block to which the transaction data to be verified belongs is the same as the block height of the block to which the transaction data to be verified belongs;

[0038] The index pair determining unit is configured to determine, as a target index pair, an index pair corresponding to the transaction block information whose stored chain identifier matches the chain identifier of the second business chain and whose stored block height matches the block height of the block to which the transaction data to be verified belongs, among the N stored index pairs.

[0039] In one embodiment, the target index value includes Q association mapping relationships; one association mapping relationship is used to indicate an association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; a stored serialized block information refers to information obtained after serializing a stored block information, and the Q stored serialized block information include the target serialized block information corresponding to the transaction block information; Q is a positive integer;

[0040] The transaction verification module includes:

[0041] An identification quantity comparison unit, used to obtain the number of stored node identifications corresponding to the target serialized block information;

[0042] The identification number comparison unit is further configured to use the maximum number of stored node identifications among the numbers of stored node identifications corresponding to the remaining stored serialized block information as the number of node identifications to be compared, and compare the number of node identifications to be compared with the number of stored node identifications corresponding to the target serialized block information; the remaining stored serialized block information is the stored serialized block information among the Q stored serialized block information, excluding the target serialized block information;

[0043] a target number determination unit, configured to determine the maximum number of node identifiers between the number of stored node identifiers corresponding to the target serialized block information and the number of node identifiers to be compared as the target number of node identifiers;

[0044] The transaction verification unit is used to perform transaction verification on the transaction data to be verified according to the target node identification number and the transaction identification of the transaction data to be verified.

[0045] In one embodiment, the transaction verification unit is further configured to determine the verification result of the transaction data to be verified as a verification failure result if the number of target node identifiers is less than a node credibility threshold;

[0046] The transaction verification unit is further specifically configured to determine the stored serialized block information corresponding to the number of target node identifiers as the serialized block information to be verified if the number of target node identifiers is greater than the node credibility threshold, and perform transaction verification on the transaction data to be verified based on the serialized block information to be verified and the transaction identifier of the transaction data to be verified.

[0047] In one embodiment, the transaction verification unit is further specifically configured to obtain a stored transaction identifier of stored transaction data contained in the serialized block information to be verified;

[0048] The transaction verification unit is further specifically configured to determine that the transaction data to be verified exists in the stored transaction data if the transaction identifier of the transaction data to be verified exists in the stored transaction identifiers, and perform transaction verification on the transaction data to be verified based on the Merkle root of the stored transaction data contained in the serialized block information to be verified;

[0049] The transaction verification unit is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the transaction identifier of the transaction data to be verified does not exist in the stored transaction identifiers.

[0050] In one embodiment, the transaction verification unit is further configured to obtain an execution result hash value corresponding to the remaining transaction data; the remaining transaction data is the transaction data in the stored transaction data excluding the transaction data to be verified;

[0051] The transaction verification unit is further specifically configured to generate a Merkle root to be verified based on a hash value of an execution result corresponding to the remaining transaction data and a hash value of an execution result corresponding to the transaction data to be verified;

[0052] The transaction verification unit is further specifically used to match the Merkle root of the stored transaction data with the Merkle root to be verified;

[0053] The transaction verification unit is further specifically configured to, if the Merkle root of the stored transaction data matches the Merkle root to be verified, perform transaction verification on the transaction data to be verified based on the hash value corresponding to the stored transaction data contained in the serialized block information to be verified;

[0054] The transaction verification unit is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the Merkle root of the stored transaction data and the Merkle root to be verified result in a matching failure.

[0055] In one embodiment, the transaction verification unit is further specifically configured to obtain a data hash value corresponding to the remaining transaction data;

[0056] The transaction verification unit is further specifically configured to generate a hash value to be verified based on a data hash value corresponding to the remaining transaction data and a data hash value corresponding to the transaction data to be verified;

[0057] The transaction verification unit is further specifically used to match the hash value of the stored transaction data with the hash value to be verified;

[0058] The transaction verification unit is further specifically configured to determine the verification result of the transaction data to be verified as a successful verification result if the hash value of the stored transaction data matches the hash value to be verified;

[0059] The transaction verification unit is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the hash value of the stored transaction data and the hash value to be verified do not match.

[0060] In one embodiment, the blockchain-based data processing device further includes:

[0061] An abnormal set determination module is configured to, if the number of target node identifiers is greater than a node credibility threshold, determine the stored uploaded node identifier set corresponding to the target node identifier number as a normal node identifier set, and determine the remaining node identifier set as an abnormal node identifier set; the remaining node identifier set is the node identifier set other than the normal node identifier set in the stored uploaded node identifier sets corresponding to the Q stored serialized block information;

[0062] The shielding processing module is used to determine the uploading node corresponding to the abnormal node identification set as an abnormal node and shield the abnormal node within a target time period.

[0063] In one aspect, an embodiment of the present application provides a computer device, including: a processor and a memory;

[0064] The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the method in the embodiment of the present application.

[0065] On one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions. When the program instructions are executed by a processor, the method in the embodiment of the present application is executed.

[0066] In one aspect of the present application, a computer program product or computer program is provided. The computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of the present application.

[0067] In an embodiment of the present application, each node (such as an SPV node) in a business chain (such as a first business chain and a second business chain) can obtain transaction block information (such as block header information) in the local business chain in real time, and can send this transaction block information to the relay chain for storage. Since the relay chain stores transaction block information through a data storage contract, and since smart contracts are open and transparent, the reliability of the transaction block information submitted by each node can be greatly improved; wherein, when storing transaction block information, the relay chain can store it in an index pair data structure, and can use the block storage parameter associated with the transaction block information as the index key, and the transaction block information as part of the index value, thereby generating an index key for indicating the transaction block information in a certain business chain. Subsequently, after a node (such as the second node) in a certain business chain (such as the second business chain) successfully stores the index pair corresponding to the transaction block information in the relay chain, other business chains (such as the first business chain) that have cross-chain transaction needs with the business chain can send a transaction verification request to the relay chain for the transaction data to be verified in the transaction block information; the index pair corresponding to the transaction block information can be obtained through the transaction verification contract in the relay chain, and thus the transaction data to be verified can be verified based on the transaction block information in the index pair. The transaction verification process for the transaction data to be verified is also completed through the transaction verification contract. Due to the open and transparent nature of the smart contract, the transaction block information is reliable, and the security and reliability of the transaction verification can be greatly improved. In summary, by adding a relay chain to the cross-chain transaction verification business, there is no need for nodes in the business chain to save data, which can reduce the situation of relying on a single node for transaction verification. The storage and verification of transaction data can both be performed through smart contracts, which can better improve the reliability and security of transaction data, and thus improve the security and reliability of transaction verification. In other words, this application can improve the reliability of verification results in cross-chain transaction business, thereby improving the security of cross-chain transaction business. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0069] Figure 1 This is a schematic diagram of a network architecture provided by an embodiment of the present application;

[0070] Figure 2a This is a schematic diagram of a scenario of storing data in a relay chain provided by an embodiment of the present application;

[0071] Figure 2b This is a schematic diagram of a scenario in which transaction verification is performed through a relay chain, as provided in an embodiment of the present application;

[0072] Figure 3 This is a flowchart of a blockchain-based data processing method provided in an embodiment of the present application;

[0073] Figure 4 This is a flowchart of a blockchain-based data processing method provided in an embodiment of the present application;

[0074] Figure 5 This is a schematic diagram of a system component structure provided by an embodiment of the present application;

[0075] Figure 6 This is a logical flow chart of data storage contract provided by an embodiment of the present application;

[0076] Figure 7 This is a logical flow chart of transaction verification performed by a transaction verification contract provided in an embodiment of the present application;

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

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

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

[0080] See Figure 1 , Figure 1 This is a network architecture diagram provided by an embodiment of the present application. Figure 1 As shown, the network architecture may include a blockchain cluster 10, a blockchain node cluster 100, and a relay chain 1000. The blockchain cluster 10 may include one or more blockchains, and the number of blockchains is not limited. Figure 1 As shown, multiple blockchains may include blockchain 11, blockchain 12, ..., blockchain 1n; a blockchain in blockchain cluster 10 may correspond to a business system. For example, if the business system includes the business system of enterprise A and the business system of enterprise B, and blockchain 11 is the blockchain configured for enterprise A's business system, then blockchain 11 corresponds to enterprise A's business system, and blockchain 12 is the blockchain configured for enterprise B's business system, then blockchain 12 corresponds to enterprise B's business system. Each blockchain in blockchain cluster 10 may be referred to as a blockchain system, which may be a distributed system formed by connecting multiple blockchain nodes via network communication. In other words, all blockchain nodes in each blockchain may establish point-to-point or end-to-end (P2P) connections with each other to form a P2P network (i.e., a blockchain system).

[0081] For ease of understanding, the following will explain the blockchain nodes in the blockchain. A blockchain node can be any form of computer device connected to the blockchain network. For example, the computer device can be a user terminal connected to the blockchain network, or a server connected to the blockchain network. The specific form of the blockchain node is not limited here. It is understandable that the user terminal here can include smart phones, tablet computers, laptops, desktop computers and other smart terminals with data processing functions. The user terminal can be installed with a target application (i.e., an application client). When the application client runs in the user terminal, it can communicate with the above-mentioned Figure 1Data is exchanged between other blockchain nodes in the blockchain network shown. The application client may include a social client, a multimedia client (e.g., a video client), an entertainment client (e.g., a game client), an educational client, a live broadcast client, and other application clients. The application client may be an independent client or an embedded sub-client integrated into a client (e.g., a social client, an educational client, a multimedia client, etc.), without limitation. The server may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0082] The main functions of blockchain nodes include the blockchain database and network routing. Every node possesses routing functionality, but not necessarily all other functions. Core nodes (i.e., consensus nodes) generally include these functions. Such core nodes can participate in the verification and broadcasting of transaction data and block information, and discover and maintain connections with other nodes. These core nodes contain the complete blockchain database, including all transaction data. These nodes, which include all functions, are also called full nodes. Other nodes only store a portion of the blockchain database, typically storing only block headers and transaction data associated with their own node, rather than the full transaction data. These nodes perform transaction verification through Simplified Payment Verification (SPV), and are referred to as lightweight nodes or SPV nodes.

[0083] In such Figure 1 The blockchain nodes in each blockchain shown can form a blockchain node cluster 100. Figure 1 As shown, the blockchain 11 includes multiple blockchain nodes such as blockchain node 11a and blockchain node 11b, and the blockchain 12 includes multiple blockchain nodes such as blockchain node 12a and blockchain node 12b; the blockchain nodes in these blockchains can form a blockchain node cluster 100, that is, the blockchain node cluster 100 includes multiple blockchain nodes such as blockchain node 11a, blockchain node 11b, blockchain node 12a, and blockchain node 12b.

[0084] like Figure 1The relay chain 1000 shown can be any blockchain (this relay chain should be different from any blockchain in the blockchain cluster 10). Any blockchain in the blockchain cluster 10 can establish a network connection with the relay chain, so that any blockchain node (such as blockchain node 11a) in any blockchain (such as blockchain 11) can exchange data with the relay chain 1000. Taking blockchain 11 as an example and blockchain node 11a as an SPV node, that is, when the business system corresponding to blockchain 11 generates transaction data, blockchain 11 can generate a block corresponding to the transaction data. At this time, blockchain node 11a can obtain the block header information of the block. Blockchain node 11a may not store the block header information, but instead upload the block header information to the relay chain 1000 via a network connection. The relay chain 1000 stores the block header information, and the block header information can be referred to as block data.

[0085] like Figure 1 Each blockchain node shown can upload block data to relay chain 1000, which can store this block data. For example, relay chain 1000 may include block data 1001a, block data 1001b, block data 1001c, block data 1001d, block data 1001e, and block data 1001f. Block data 1001a can be uploaded by blockchain node 11a, block data 1001b and block data 1001c can be uploaded by blockchain node 11b, block data 1001d and block data 1001e can be uploaded by blockchain node 11c, and block data 1001f can be uploaded by de-blockchain node 11d.

[0086] It should be understood that each blockchain in this application (such as blockchain 11) can be called a business chain. This application can deploy a data storage contract (BlockSaveContract) and a transaction verification contract (TxProveContract) in the relay chain 1000. Both the data storage contract and the transaction verification contract are smart contracts. When a business chain has a data storage demand, it can directly call the data storage contract in the relay chain 1000, and the corresponding business data can be stored through the execution logic in the data storage contract. If any two or more business chains have a cross-chain transaction demand, the cross-chain transaction needs to be verified. After a business chain in the cross-chain transaction business executes the transaction data and uploads the transaction data to the relay chain 1000, the other business chains in the cross-chain transaction business can call the transaction verification contract in the relay chain 1000 and use the transaction verification contract to verify the transaction data of the business chain. After the transaction verification is successful, these business chains can execute the transactions they should do. For the specific process of storing data in the relay chain 1000 and verifying transactions through the relay chain 1000, please refer to the subsequent Figure 3 Description in the corresponding embodiment.

[0087] It should be understood that by deploying smart contracts in the relay chain and storing the block data (for example, block header information) in the business chain in the relay chain through the smart contract, the corresponding blockchain nodes (such as SPV nodes) do not need to save the corresponding block data. Therefore, when verifying cross-chain transactions, there is no need to call the corresponding SPV node, which can avoid the problem of transaction verification failure caused by a single SPV failure. At the same time, due to the open and transparent nature of smart contracts, smart contracts can also improve the reliability of the block data stored in the relay chain. Therefore, when using smart contracts for transaction verification, the security and reliability of transaction verification can also be improved.

[0088] For further understanding, please see Figure 2a , Figure 2a This is a schematic diagram of a scenario in which data is stored in a relay chain, as provided in an embodiment of the present application. Figure 2a In the scenario shown, the blockchain nodes that upload block data to the relay chain of each blockchain (also called business chain) are SPV nodes (also called light nodes). Figure 2a The blockchain node 12a shown may be the blockchain node 12a in the aforementioned blockchain 12 (hereinafter referred to as the business chain 12), and the blockchain node 1000a may be a node in the relay chain 1000. For ease of understanding, the blockchain node 12a will be referred to as the SPV node 12a, and the blockchain node 1000a will be referred to as the relay node 1000a.

[0089] like Figure 2a The scenario shown assumes that business chain 12 is the blockchain corresponding to Enterprise A, and business chain 11 is the blockchain corresponding to Enterprise B. Business chain 12 stores object information (i.e., user information) of business objects (i.e., users) in Enterprise A, while business chain 11 stores object information of business objects in Enterprise B. A user typically has accounts in both enterprises. For example, user A may have account A1 in Enterprise A and account B1 in Enterprise B. User A can store virtual asset data in Enterprise A using account A1, and can also store virtual asset data in Enterprise B using account B1.

[0090] When a user wishes to transfer some virtual asset data (e.g., 100 yuan) from account A1 to account B1, a transfer of virtual asset data occurs. For blockchains, since companies A and B correspond to different blockchains, this transfer of virtual asset data is equivalent to a cross-chain transaction. Cross-chain transactions require proof of the cross-chain transaction, which serves as proof of the transaction's validity. For example, if user A transfers 100 yuan from account A1 to account B1, the process must include at least the following steps: 1. In business chain 12 corresponding to company A, subtract 100 yuan from the balance of account A1 (i.e., the total value of the virtual asset data in the account); 2. In business chain 11 corresponding to company B, add 100 yuan to the balance of account B1 (i.e., the total value of the virtual asset data in the account). For business chain 11, before executing the operation of adding 100 yuan to the balance of account B1, it needs to first confirm that business chain 12 has completed the operation of subtracting 100 yuan from the balance of account A1. This confirmation operation of business chain 11 is the verification of the transaction of subtracting 100 yuan from account A1 in business chain 12; similarly, after business chain 11 executes the operation of adding 100 yuan to the balance of account B1, business chain 12 also needs to verify the transaction of adding 100 yuan to the balance of account B1 to confirm whether business chain 11 has actually been executed successfully.

[0091] For each transaction in each blockchain (such as the transaction of subtracting 100 yuan from the balance of account A1), the blockchain will generate a corresponding block and store the block in the blockchain. The SPV nodes of each blockchain can obtain the block header data (also called block header information) of each block in the blockchain at regular intervals (or through subscription). In this application, each SPV node does not need to save the obtained block header information, but instead uploads the block header information to the relay chain, which stores the block header information.

[0092] Taking the cross-chain transaction between business chain 12 and business chain 11 as an example, the transaction of business chain 12 is account A1 minus 100 yuan. The transaction can be called transaction data 3. Block a1 can be generated based on the transaction data 3, wherein the block a1 may include a block header and a block body; the block body may include transaction data 1, transaction data 2, transaction data 3 and transaction data 4; the block body may also include a content data Merkle tree corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4, and the content data Merkle tree includes data hash values corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4 respectively (that is, a hash value calculated according to the content of each transaction data), and a total hash value generated by the data hash values corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4 respectively (that is, a Merkle root corresponding to the hash value of the transaction data, which can be called the first Merkle root). The block body may also include transaction data 1, transaction data 2, transaction data 3 and transaction data 4. The Merkle tree of execution results corresponding to transaction data 3 and transaction data 4 includes the execution result hash values corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4, respectively, and the total result hash value generated by the execution result hash values corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4, respectively (i.e., the Merkle root corresponding to the execution result hash value, which can be called the second Merkle root); the block header may include the block height of block a1 (or other identity proof of block a1 in the business chain 12, such as the identifier and number of block a1), the block header may include the transaction identifiers (such as transaction index, transaction number, etc.) corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4, respectively, and the block header may also include the first Merkle root corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4, and the second Merkle root corresponding to transaction data 1, transaction data 2, transaction data 3 and transaction data 4.

[0093] like Figure 2a As shown, SPV node 12a can periodically obtain the block header information in block a1, as well as the data hash values corresponding to transaction data 1, transaction data 2, transaction data 3, and transaction data 4, and the execution result hash values corresponding to transaction data 1, transaction data 2, transaction data 3, and transaction data 4. The block header information, the data hash values of each transaction data, and the execution result hash values can be collectively determined as transaction block information 20a. SPV node 12a can call a data storage contract and send this transaction block information 20a to relay node 1000a through the data storage contract. Subsequently, relay node 1000a stores this transaction block information 20a in the relay chain 1000 through the data storage contract.

[0094] It is understood that, in addition to SPV node 12a, business chain 12 also includes other SPV nodes, and these SPV nodes will also periodically (or by subscription) obtain block header information from business chain 12. After obtaining the block header information, these SPV nodes will also upload the block header information and associated information (such as the data hash value and execution result hash value of each transaction data in the block to which the block header information belongs) to the relay chain. In other words, after obtaining the block header information of block a1, the other SPV nodes in business chain 12 will also obtain the data hash value and execution result hash value corresponding to transaction data 1-transaction data 4, respectively, to form transaction block information (which can be referred to as same-chain transaction block information), and send this transaction block information to the relay chain for storage.

[0095] Taking the example of SPV node 12f among the other SPV nodes in business chain 12, SPV node 12f generates transaction block information 20f (also referred to as same-chain transaction block information 20f) for the block header information of block a1. Subsequently, SPV node 12f may send transaction block information 20f to relay node 1000a, which then uploads transaction block information 20f to relay chain 1000. It is assumed here that SPV node 12f is the first node to send the transaction block information of block a1 to the relay chain. In other words, the block header information of block a1 currently does not exist in relay chain 1000. At this time, the relay chain 1000 can obtain the chain identifier (i.e. 12) of the blockchain to which the SPV node 12f belongs, and the block height of the block to which the transaction block information 20f belongs (i.e. the block height of block a1, such as 66), and can form an index key (12, 66) based on the chain identifier 12 and the block height 66; further, the transaction block information 20f can be serialized to obtain serialized transaction block information 20f. Assuming that after serialization, the obtained value is wring2, the wring2 can be called the serialized transaction block information 20f; then, the serialized transaction block information 20f can be obtained based on the upload node (i.e. The SPV node 12f) and the upload node identifier (i.e., 12f) generate an upload node identifier set {12f}. An index value can be generated according to the serialized transaction block information 20f, the upload node identifier set {12f}, and the node identifier quantity 1 of the upload node identifier set {12f}. An association mapping relationship can be established between the index value and the above-mentioned index key (12, 66), that is, an index pair is generated by the index key (12, 66) and the index value (the index pair can be numbered 1001h). For ease of understanding, please refer to Table 1. The index pair shown in Table 1 can be the index pair 1001h composed of the above-mentioned index key (12, 66) and the index value.

[0096]

[0097] As shown in Table 1, the index pair 1001h may include an index key and an index value. The index key is (12, 66) as mentioned above, indicating that the index pair belongs to block a1 in business chain 12; the index value includes serialized block information (including serialized block information 20f, i.e., wring2), an uploading node identifier set (including the node identifier 12f of the SPV node 12f), and the number of node identifiers (i.e., the number of nodes that have uploaded the serialized block information 20f, that is, the number of node identifiers in the uploading node identifier set, which is 1).

[0098] It should be understood that the index pair can be numbered (such as 1001h), and the index pair can be called index pair 1001h (the index pair can also be called block data, and the index pair 1001h can also be called block data 1001h), and the index pair 1001h can be stored in the relay chain 1000. Upon subsequently receiving the transaction block information corresponding to block a1 uploaded by other SPV nodes (including SPV node 12a) in business chain 12, if the transaction block information uploaded by other SPV nodes (such as SPV node 12u) is consistent with the transaction block information 20f, the node identifier 12u of SPV node 12u may be directly added to the upload node identifier set corresponding to the serialized block information 20f (i.e., wring2, hereinafter referred to as serialized block information wring2), and the corresponding node identifier quantity may be incremented. If the transaction block information uploaded by other SPV nodes (such as SPV node 12c) is inconsistent with the transaction block information 20f, new serialized block information (such as wring1) may be generated based on the transaction block information uploaded by SPV node 12c, and the new serialized block information wring1, the upload node identifier set corresponding to the serialized block information wring1 (i.e., {12c}), and the node identifier quantity (i.e., 1) may be associated and stored in the index value. That is, the index pair 1001h can be continuously updated.

[0099] According to the above description, after receiving the transaction block information 20a sent by the SPV node 12a, the relay chain 1000 may perform the following specific process for storing the transaction block information 20a: first, the chain identifier (i.e., 12) of the blockchain to which the SPV node 12a belongs and the block height (i.e., the block height of block a1, such as 66) of the block to which the transaction block information 20a belongs may be obtained; it should be understood that the index key (12, 66) can be formed according to the chain identifier of the business chain 12 and the block height of block a1; then, the relay chain 1000 may be traversed. stored index pairs (including stored index pair 1001g, stored index pair 1001h and stored index pair 1001i. Here, the index pairs already stored in the relay chain 1000 are referred to as stored index pairs) to query whether there is a stored index key identical to the index key (12, 66) in the stored index pair (here, the index keys already stored in the relay chain 1000 are referred to as stored index keys, that is, the index keys respectively contained in the stored index pair 1001g, the stored index pair 1001h and the stored index pair 1001i are all stored index keys).

[0100] Furthermore, through traversal, it can be known that the stored index key in the stored index pair 1001h is the same as the index key (12, 66), so the stored index pair 1001h can be obtained. The index key and index value included in the stored index pair 1001h can be as follows Figure 2a As shown. Further, the transaction block information 20a can be serialized to obtain the serialized block information 20a as wring2, and then the stored serialized block information in the index value can be traversed (that is, the serialized block information that has been stored in the relay chain 1000, such as Figure 2a As shown, the stored serialized block information includes serialized block information wring1 and serialized block information wring2), and the stored serialized block information of the stored index pair 1001h is traversed to check whether there is the same stored serialized block information as the serialized block information 20a (ie, wring2). Figure 2a As shown, through traversal, it can be known that the existing serialized block information wring2 is the same as the serialized block information 20a. At this time, the node identifier 12a of the SPV node 12a can be directly added to the uploaded node identifier set corresponding to the existing serialized block information wring2, and the node identifier quantity 2 corresponding to the existing serialized block information wring2 is incremented to obtain the node identifier quantity 3, thereby obtaining a new index pair 1001h.

[0101] Furthermore, after the addition is completed, it can be determined that the transaction block information 20a is successfully stored in the relay chain 1000. At this time, the relay node 1000a can send a storage success notification to the SPV node.

[0102] Further, see Figure 2b , Figure 2b This is a schematic diagram of a scenario for transaction verification through a relay chain provided by an embodiment of the present application. It should be understood that after the above-mentioned business chain 12 executes the transaction to subtract 100 yuan from the balance of account A1 (i.e., completes the execution of transaction data 3), business chain 12 can send a notification of the completion of the execution of transaction data 3 to business chain 11 to notify business chain 12 that transaction data 3 has been executed and business chain 11 can perform subsequent operations (such as adding 100 yuan to the balance of account B1). The transaction of adding 100 yuan to the balance of account B1 can be called transaction data w. Before executing transaction data w on its own, business chain 11 needs to verify transaction data 3.

[0103] like Figure 2b As shown, the specific process of business chain 11 verifying transaction data 3 may be as follows: blockchain node 11a in business chain 11 may send a transaction verification request to relay node 1000a, wherein the transaction verification request may carry the chain identifier of business chain 12 (i.e., 12), the block height (i.e., 66) of the block to which transaction data 3 belongs (i.e., block a1), and the transaction identifier (i.e., 3) of transaction data 3. Furthermore, relay node 1000a may traverse relay chain 1000 and query for an existing index key that is identical to the chain identifier 12 and the block height 66 carried in the transaction verification request. Since the index key contained in the existing index pair 1001h is (12, 66), the existing index pair 1001h may be obtained through traversal.

[0104] It should be understood that because malicious nodes may exist in the blockchain, the transaction block information generated by these malicious nodes and transmitted to the relay chain 1000 may not be authentic information. In this case, the transaction block information sent by the malicious node is different from the transaction block information sent by the normal node, and the serialized block information corresponding to the malicious node and the normal node will also be different. Since normal nodes in the blockchain usually account for a higher proportion and the number of malicious nodes is small, in this application, in the stored index pair, the serialized block information with the largest number of node identifiers is most likely sent by a normal node. Therefore, when performing transaction verification, the maximum number of node identifiers in the index value can be obtained, and subsequent transaction verification can be performed based on this maximum value.

[0105] For example, in the stored index pair 1001h, the maximum number of node identifiers is 3, which means that three SPV nodes have uploaded the same transaction block information. In this case, the maximum number of node identifiers, 3, can be compared with the node credibility threshold, where the node credibility threshold can be half of the total number of SPV nodes in business chain 12. For example, if business chain 12 contains 5 SPV nodes, the node credibility threshold can be 2.5 (optionally, the node credibility threshold can be rounded off to 3). If the maximum number of node identifiers is greater than the node credibility threshold, it can be assumed that the serialized block information wring2 was indeed uploaded by a normal node and is credible.

[0106] Furthermore, based on the transaction identifier of the transaction data to be verified (i.e., transaction data 3), it can be determined that the transaction data that the business chain 11 expects to verify is transaction data 3, and the relay node 1000a can perform transaction verification on the transaction data 3 based on the serialized block information wring2. The content of the verification includes but is not limited to the following three aspects: (1) Verification of the existence of transaction data 3; (2) Verification of the execution status of transaction data 3 (whether the execution result of transaction data 3 is successful or failed); (3) The content of transaction data 3 (which can be understood as: whether the amount subtracted by the business chain 12 from the account A1 is really 100 yuan). For the specific process of transaction verification of transaction data 3, please refer to the subsequent Figure 3 Description in the corresponding embodiment.

[0107] After verifying transaction data 3, a verification result is obtained. Relay node 1000a can send this verification result to blockchain node 11a, allowing business chain 11 to perform subsequent processing based on the verification result. For example, if the verification result is successful, business chain 11 can add 100 yuan to the balance of account B1. However, if the verification result is unsuccessful, business chain 11 may not perform the operation of adding 100 yuan to the balance of account B1.

[0108] It should be understood that, in cross-chain transaction verification, this application adds a relay chain, eliminating the need for SPV nodes on each business chain (i.e., blockchain) to store block header information. Instead, they simply upload block header information to the relay chain, which then stores it. Furthermore, when the SPV uploads data to the relay chain, there's no need for significant modifications to the SPV node; instead, the original transaction data needs to be converted to a format that conforms to the relay chain's transaction data format, and the converted transaction data (also referred to as the converted transaction data) is then sent to the relay chain. Furthermore, the relay chain in this application can be any blockchain, requiring no special development and resulting in minimal deployment costs. The relay chain eliminates the need to call a single SPV node during transaction verification, thereby preventing issues with SPV node failures that could prevent smooth transaction verification. Furthermore, data storage and verification are both accomplished through smart contracts, whose transparency significantly enhances the security and reliability of transaction verification.

[0109] It should be noted that the above-mentioned transaction data (such as transaction data 3: subtracting 100 yuan from the balance of account A1), transaction data identifiers, the results obtained after serializing the transaction block information (such as wring2, wring1), and other parameters are all examples made for ease of understanding and have no practical reference significance.

[0110] Further, see Figure 3 , Figure 3 This is a flowchart of a data processing method based on blockchain provided by an embodiment of the present application. This process can actually correspond to the process of storing data in the relay chain by the business chain. This process can be executed by a computer device, which can be as follows: Figure 1 Any blockchain node in the relay chain 1000 shown. Figure 3 As shown, the process may include the following steps S101-step S101-step S104:

[0111] Step S101: Obtain a data storage request for transaction block information sent by a second node; the data storage request carries the block height of the block to which the transaction block information belongs.

[0112] Specifically, a business chain can refer to the blockchain corresponding to a specific business. Each business chain can store business data (such as transaction information) for the corresponding business. These businesses can include invoicing, export, legal entity, and credit reporting services, among others. We will not provide examples of each business here. Because a blockchain can include core nodes, full nodes, and light nodes (such as SPV nodes), the second node here can also be a core node, full node, or light node in the second business chain.

[0113] It is understood that after executing transaction data, each business chain can generate a block containing the transaction data. In this application, nodes in a business chain (such as SPV nodes) can periodically (or by subscription) obtain block information for a block in their local business chain. This block information includes information that can be used to verify the transaction data. For example, the information used to verify the transaction data includes block header information, hash values of each transaction data contained in the block (i.e., content hash values or data hash values, generated based on the transaction data), and hash values corresponding to the execution results of each transaction data (i.e., execution result hash values). The information consisting of the block header information, the hash values of each transaction data contained in the block, and the hash values of the execution results of each transaction data can serve as block information (also referred to as transaction block information). In other words, transaction block information can be information used to verify transaction data, and specifically can include information consisting of the block header information, the hash values of each transaction data contained in the block, and the hash values of the execution results of each transaction data.

[0114] In the present application, the nodes in the business chain can send the transaction block information of each block to the relay chain. Taking the business chain as the second business chain and the node as the second node as an example, after the second node obtains the transaction block information of a certain block (hereinafter referred to as the target block), it can generate a data storage request for the transaction block information. Subsequently, the second node can send the data storage request and the block height of the block to which the transaction block information belongs (that is, the target block) (the block height can be used to indicate which block the target block is in the second business chain) to the blockchain node in the intermediate chain (hereinafter referred to as the relay node).

[0115] Optionally, what the second node sends to the relay node may not be the block height, but other identity information of the target block. The identity information can be used to characterize that the block to which the transaction block information belongs is the target block. For example, the identity information may be the block identifier (Identity document, ID), block number, block name, etc. of the target block.

[0116] Step S102: Call the data storage contract in the relay chain according to the data storage request. Through the storage logic of the data storage contract, the chain identifier of the second business chain and the block height of the block to which the transaction block information belongs are determined as block storage parameters.

[0117] Specifically, the relay node can invoke the data storage contract based on the data storage request. The data storage contract can then, based on the storage logic (code program logic), determine the block storage parameters along with the chain ID of the second business chain to which the second node belongs and the block height of the block to which the transaction block information belongs (i.e., the target block). For example, if the chain ID of the second business chain is 12 and the block height of the block to which the transaction block information belongs is 66, the block storage parameters for the transaction block information can be 12 and 66.

[0118] Step S103: determining a target index key according to the block storage parameters, and determining a target index value according to the initial index value corresponding to the target index key, the transaction block information, and the identifier of the second node.

[0119] Specifically, the target index key can be determined based on the block storage parameters corresponding to the transaction block information. The specific method can be as follows: N stored index pairs in the relay chain can be traversed; wherein, a stored index pair is used to indicate the mapping relationship between a stored index key and a stored index value; the stored index key includes the stored block storage parameters associated with the stored block information; if the stored block storage parameters included in the N stored index pairs contain a target stored block storage parameter that is identical to the block storage parameter, then the stored index key to which the target stored block storage parameter belongs is determined as the target index key; if the stored block storage parameters included in the N stored index pairs do not contain a target stored block storage parameter that is identical to the block storage parameter, then the index key composed of the block storage parameters is determined as the target index key.

[0120] It should be understood that the block storage parameters corresponding to a transaction block information can form an index key (i.e., a key value). For example, the block storage parameters 12 and 66 described above can form the index key (12, 66), which can be used to represent the target block (block height 66) in the second business chain (chain identifier 12). At the same time, an index value (i.e., a value) can also be generated based on the transaction block information. Using this index key and index value, an index pair (i.e., a key-value pair) can be generated. This index pair can be stored in the relay chain. The index pair stored in the relay chain indicates that the intermediate chain has stored the transaction block information and that the transaction block information belongs to the target block in the second business chain. An existing index pair can refer to an index pair corresponding to existing block information already stored in the relay chain. Because an index pair contains an index key and an index value, the index key contained in the existing index pair can be referred to as an existing index key, and the index key contained in the existing index pair can be referred to as an existing index value.

[0121] It should be understood that, after each node in the business chain obtains the transaction block information of a certain block, it will send the transaction block information to the relay chain. That is to say, for the same block, the relay node may obtain different transaction block information sent by different nodes (which may include normal transaction block information sent by normal nodes, and may also include tampered and erroneous transaction block information sent by abnormal nodes). That is to say, before receiving the transaction block information for the target block sent by the second node, the relay chain may have received other transaction block information for the target block sent by other nodes in the second business chain (which may be called same-chain transaction block information). For other transaction block information sent by other nodes, the relay chain has generated an index pair (the index key is the chain identifier of the second business chain and the block height of the target block, i.e. (12, 66)) and stored the index pair. Then, after determining the block storage parameters (12 and 66) of the transaction block information sent by the second node, the stored index pairs in the relay chain can be traversed to query whether there is a target stored block storage parameter (composed of the chain identifier of the stored business chain and the block height of the block to which the stored block information belongs) that is the same as the block storage parameter in the stored index key. If so, the stored index key to which the target stored block storage parameter belongs can be directly determined as the target index key; if not, the index key composed of the block storage parameters can be determined as the target index key.

[0122] That is to say, if before the second node sends the transaction block information of the target block, other nodes in the second business chain preferentially send other transaction block information for the target block to the intermediate chain, then at this time the relay chain already has an index key composed of the chain identifier of the second business chain and the block height of the target block. At this time, the index key can be directly used as the target index key for the transaction block information sent by the second node; and if before receiving the transaction block information sent by the second node, the relay node has not received the transaction block information for the target block sent by other nodes in the second business chain, then at this time the relay node can determine the index key composed of the chain identifier of the second business chain and the block height of the target block as the target index key.

[0123] It is understandable that when obtaining transaction block information sent by any node, in addition to generating an index key based on the chain identifier of the business chain and the block height of the block to which the transaction block information belongs, it is also necessary to generate an index value based on the transaction block information, and then generate an index pair from the index key and the index value. For example, before receiving the transaction block information sent by the second node, the relay node has not received the transaction block information for the target block sent by other nodes in the second business chain. After generating the target index key (the chain identifier of the second business chain and the block height of the target block), the relay node can serialize the transaction block information to obtain the target serialized block information; then, it can form an upload node identifier set based on the node identifier of the second node; the relay node can establish an association mapping relationship between the target serialized block information, the upload node identifier set, and the number of node identifiers corresponding to the upload node identifier set, and determine the association mapping relationship as the target index value. In this way, a target index pair composed of the target index key and the target index value can be obtained.

[0124] In other words, the index key in each index pair consists of the chain ID of the business chain and the block height of the block to which the transaction block information belongs. The index value in each index pair can include the serialized block information corresponding to the transaction block information, the set of upload node IDs that uploaded the transaction block information, and the number of node IDs in the upload node ID set. For example, if the node ID of the second node is 12f and the target serialized block information obtained after serializing the transaction block information is "wring2", the target index pair can be shown in Table 1 above.

[0125] It can be understood that, in fact, for each transaction block information, after determining its corresponding index key, the relay node will serialize it. After obtaining the serialized block information, the relay node will traverse the index value corresponding to the index key (which can be called the initial index value) to check whether the initial index value contains the same serialized block information (that is, other nodes have uploaded it), and update the initial index value according to the query result to obtain the target index value.

[0126] Taking the transaction block information sent by the second node as an example, the initial index value includes M (M is a positive integer) association mapping relationships; an association mapping relationship is used to indicate the association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; the specific method for determining the target index value can be: serializing the transaction block information to obtain the target serialized block information; traversing the M stored serialized block information; if there is a target stored serialized block information that is the same as the target serialized block information in the M stored serialized block information, then the second node The node identifier of the second node is added to the stored upload node identifier set corresponding to the target stored serialized block information, and the number of stored node identifiers in the target stored upload node identifier set is incremented to obtain a target index value; if the target stored serialized block information does not exist in the M stored serialized block information, a target upload node identifier set corresponding to the target serialized block information is generated according to the node identifier of the second node, and the number of node identifiers of the second node is used as the target node identifier number of the target upload node identifier set. The target serialized block information, the target upload node identifier set, and the target node identifier number are associated and added to the initial index key to obtain a target index value.

[0127] Among them, before executing the above-mentioned adding the node identifier of the second node to the target stored upload node identifier set corresponding to the target stored serialized block information, increasing the number of stored node identifiers in the target stored upload node identifier set, and obtaining the target index value, it is also necessary to check whether the node identifier of the second node exists in the target stored upload node identifier set (that is, the second node may have been uploaded, and it is a repeated upload in this case). If it exists, there is no need to add it. If not, then add it again. The specific method can be: traversing the stored upload node identifier set corresponding to the target stored serialized block information; if the node identifier of the second node exists in the stored upload node identifier set corresponding to the target stored serialized block information, then determining the initial index value as the target index value; if the node identifier of the second node does not exist in the stored upload node identifier set corresponding to the target stored serialized block information, then executing the step of adding the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information, increasing the number of stored node identifiers in the target stored upload node identifier set, and obtaining the target index value.

[0128] That is to say, if the same serialized block information exists in the initial index value, and the node identifier of the second node does not exist in the upload node identifier set, the node identifier of the second node can be directly added to the corresponding upload node identifier set, and the number of corresponding node identifiers can be incremented; as mentioned above Figure 2aIn the scenario shown, after traversal, if the initial index value contains the same serialized block information wring2, the node identifier 12a of SPV node 12a can be directly added to the uploaded node identifier set, and the corresponding node identifier quantity 3 can be incremented to 4. If the initial index value does not contain the same serialized block information, the serialized block information corresponding to the transaction block information, the uploaded node identifier set (containing only the node identifier of the second node), and the node identifier quantity (i.e., 1) can be added to the initial index value in an associated manner.

[0129] Step S104: store the target index pair consisting of the target index key and the target index value into the relay chain.

[0130] Specifically, if the target index key is an existing index key, then the initial index key corresponding to the target index key is updated, which can be considered as storing the target index pair.

[0131] It should be understood that by adding a relay chain and storing the transaction block information in the business chain through smart contracts, it is possible to accurately record which nodes uploaded each transaction block information, thereby quickly and accurately identifying normal nodes and malicious nodes.

[0132] Further, see Figure 4 , Figure 4 This is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. This process can actually correspond to the process of transaction verification of transaction data by the business chain through the relay chain, wherein the method can be executed by a computer device, which can be such as Figure 1 Any blockchain node in the relay chain 1000 shown. Figure 4 As shown, the process may include at least the following steps S201 to S203:

[0133] Step S201: Obtain a transaction verification request sent by a first node in a first service chain; the transaction verification request carries information of the chain to be verified and a transaction identifier of the transaction data to be verified.

[0134] In this application, the first business chain may refer to the blockchain corresponding to a certain business, and the first business chain may store business data (such as transaction information, etc.) of the corresponding business. Among them, the business may include invoice business, export business, legal person business, credit reporting business, etc., and examples of each business are not provided here. Because the blockchain can include core nodes, full nodes, and light nodes (such as SPV nodes), the first node here can also be a core node, full node, or light node in the first business chain.

[0135] It is understandable that because the business chains (blockchains) configured for different businesses are actually different, when two (or more) businesses have business interaction needs, then two business chains (or more) are required to cross the chain. The business that needs to be conducted across the chain can be called a cross-chain transaction business. Taking the first business chain (the blockchain corresponding to the first business) and the second business chain (the blockchain corresponding to the second business) as an example, in the cross-chain transaction business, when the first business chain executes a transaction, the second business chain can execute subsequent operations. At this time, before executing subsequent operations, the second business chain needs to verify whether the transaction of the first business chain has been completed. After confirming that the transaction of the first business chain has been completed, the second business chain will execute subsequent operations. For example scenarios corresponding to cross-chain transaction business, please refer to the above Figure 2a-2b The corresponding embodiment describes the scenario example of the cross-chain transaction business, and the example description of the cross-chain transaction is not repeated here.

[0136] It should be understood that through the above Figure 3 As described in the corresponding embodiment, the relay chain can store transaction block information for each business chain. Therefore, when a first business chain needs to verify a transaction for a piece of pending transaction data, the first node can send a transaction verification request to the relay node. This transaction verification request must carry the pending chain information, which is the relevant information about the business chain awaiting verification. For example, if a cross-chain transaction occurs between a first business chain and a second business chain, after the second business chain completes a transaction, it can send an execution completion notification to the first business chain (notifying the second business chain that the transaction has been completed, and at the same time, notifying the first business chain of the block height of the transaction, the transaction identifier (e.g., ID), and other transaction information used for transaction verification). The first business chain can then use the transaction as pending transaction data, and the chain identifier of the second business chain and the block height of the block to which the pending transaction data belongs as pending chain information. Subsequently, the first business chain can send the pending chain information and the transaction identifier of the pending transaction data to the relay node.

[0137] Step S202: Based on the transaction verification request, the transaction verification contract on the relay chain is called, and the target index pair is obtained in the relay chain through the transaction verification contract and the chain information to be verified; the target index pair is generated when the transaction block information is stored through the data storage contract, and the transaction block information is sent by the second node in the second business chain; the target index pair is used to indicate the mapping relationship between the target index key and the target index value, and the target index key contains the block storage parameters associated with the transaction block information, and the block storage parameters match the chain information to be verified; the target index value contains the transaction block information; the first business chain and the second business chain are different.

[0138] In this application, through the above Figure 3As can be seen from the corresponding embodiment, the intermediate chain stores each transaction block information using an index pair data structure. Therefore, when verifying pending transaction data, it is necessary to first obtain the transaction block information of the block to which the pending transaction data belongs. Specifically, the relay node can invoke the transaction verification contract based on the transaction verification request. The transaction verification contract, based on the contract logic (verification logic, i.e., code logic), obtains the target index pair and then retrieves the corresponding transaction block information from the target index pair. The specific method of obtaining the target index pair can be: traversing N stored index pairs in the relay chain through the verification logic in the transaction verification contract; a stored index pair is used to indicate the mapping relationship between a stored index key and a stored index value; the stored index key includes a stored block storage parameter associated with the stored block information; the stored index key includes the stored block storage parameter, and the stored block storage parameter includes a stored chain identifier and a stored block height; the stored chain identifier is the chain identifier of the stored business chain, the stored block height is the block height of the block to which the stored block information belongs, and the block to which the stored block information belongs belongs to the stored business chain; the stored block information includes The transaction block information, the N stored index pairs include an index pair corresponding to the transaction block information, the stored chain identifier in the index pair corresponding to the transaction block information is the chain identifier of the second business chain, and the stored block height in the index pair corresponding to the transaction block information is the block height of the block to which the transaction block information belongs, and the block height of the block to which the transaction block information belongs is the same as the block height of the block to which the transaction data to be verified belongs; the index pair corresponding to the transaction block information, whose stored chain identifier in the N stored index pairs matches the chain identifier of the second business chain, and whose stored block height matches the block height of the block to which the transaction data to be verified belongs, is determined as the target index pair.

[0139] It should be understood that because the transaction block information uploaded by the second business chain includes the transaction block information of the block to which the transaction data to be verified belongs, and because the chain information to be verified includes the chain identifier of the second business chain and the block height of the block to which the transaction data to be verified belongs, by traversing the stored index pairs, a target index key with the chain identifier of the second business chain and the stored block height of the block to which the transaction data to be verified belongs is obtained, and then the target index pair to which the target index key belongs can be obtained. The target index value in this target index pair is the transaction block information of the block to which the transaction data to be verified belongs.

[0140] Step S203 : Based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value, transaction verification is performed on the transaction data to be verified, and the verification result is sent to the first node.

[0141] In this application, through the above Figure 3It can be seen from the corresponding embodiment that each index value includes one or more serialized block information, an upload node identifier set corresponding to each serialized block information, and the number of node identifiers in the upload node identifier set. That is, the target index value includes Q (Q is a positive integer) association mapping relationships; an association mapping relationship is used to indicate the association relationship between an existing serialized block information, an existing upload node identifier set corresponding to the existing serialized block information, and the number of existing node identifiers in the existing upload node identifier set; an existing serialized block information refers to information obtained after serializing an existing block information, and the Q existing serialized block information include the target serialized block information corresponding to the transaction block information. A specific method for performing transaction verification on transaction data to be verified may be: obtaining the number of stored node identifiers corresponding to the target serialized block information; using the maximum number of stored node identifiers among the numbers of stored node identifiers corresponding to the remaining stored serialized block information as the number of node identifiers to be compared, and comparing the number of node identifiers to be compared with the number of stored node identifiers corresponding to the target serialized block information; the remaining stored serialized block information is the stored serialized block information other than the target serialized block information among the Q stored serialized block information; determining the target node identifier number by using the number of stored node identifiers corresponding to the target serialized block information and the maximum number of node identifiers among the numbers of node identifiers to be compared; and performing transaction verification on the transaction data to be verified based on the target node identifier number and the transaction identifier of the transaction data to be verified.

[0142] Among them, the specific implementation method of performing transaction verification on the transaction data to be verified based on the number of target node identifiers and the transaction identifier of the transaction data to be verified can be: if the number of target node identifiers is less than the node credibility threshold, the verification result of the transaction data to be verified is determined as a verification failure result; if the number of target node identifiers is greater than the node credibility threshold, the stored serialized block information corresponding to the number of target node identifiers is determined as the serialized block information to be verified, and transaction verification is performed on the transaction data to be verified based on the serialized block information to be verified and the transaction identifier of the transaction data to be verified.

[0143] Among them, for the transaction identifier of the transaction data to be verified based on the serialized block information to be verified and the transaction data to be verified, the specific method for performing transaction verification on the transaction data to be verified may be: obtaining the stored transaction identifier of the stored transaction data contained in the serialized block information to be verified; if the transaction identifier of the transaction data to be verified exists in the stored transaction identifier, it is determined that the transaction data to be verified exists in the stored transaction data, and transaction verification is performed on the transaction data to be verified based on the Merkle root of the stored transaction data contained in the serialized block information to be verified; if the transaction identifier of the transaction data to be verified does not exist in the stored transaction identifier, the verification result of the transaction data to be verified is determined as a verification failure result.

[0144] Among them, for the Merkle root of the stored transaction data contained in the serialized block information to be verified, the specific method for performing transaction verification on the transaction data to be verified may be: obtaining the execution result hash value corresponding to the remaining transaction data; the remaining transaction data is the transaction data other than the transaction data to be verified in the stored transaction data; generating the Merkle root to be verified based on the execution result hash value corresponding to the remaining transaction data and the execution result hash value corresponding to the transaction data to be verified; matching the Merkle root of the stored transaction data with the Merkle root to be verified; if the Merkle root of the stored transaction data and the Merkle root to be verified are a successful match result, performing transaction verification on the transaction data to be verified based on the hash value corresponding to the stored transaction data contained in the serialized block information to be verified; if the Merkle root of the stored transaction data and the Merkle root to be verified are a failed match result, determining the verification result of the transaction data to be verified as a failed verification result.

[0145] Among them, for the hash value corresponding to the stored transaction data contained in the serialized block information to be verified, the specific method for performing transaction verification on the transaction data to be verified may be: obtaining the data hash value corresponding to the remaining transaction data; generating the hash value to be verified based on the data hash value corresponding to the remaining transaction data and the data hash value corresponding to the transaction data to be verified; matching the hash value of the stored transaction data with the hash value to be verified; if the hash value of the stored transaction data and the hash value to be verified are a successful match, determining the verification result of the transaction data to be verified as a successful verification result; if the hash value of the stored transaction data and the hash value to be verified are a failed match, determining the verification result of the transaction data to be verified as a failed verification result.

[0146] It should be understood that the target index value actually contains the serialized block information corresponding to the transaction block information sent by different nodes (already stored, which can be called stored serialized block information). For example, as shown in the figure above Figure 2aAs shown in the corresponding embodiment, in the index pair 1001h, for the same block in the same business chain, node 12c corresponds to serialized block information wring1, while nodes 12f, 12h, and 12u correspond to serialized block information wring2. Because there may be a small number of malicious nodes among these uploading nodes, the serialized block information corresponding to these malicious nodes is inconsistent with the serialized block information corresponding to normal nodes. Since the number of malicious nodes is small and the number of normal nodes is large, the serialized block information with the largest number of node identifiers in the index value is most likely to be normal information sent by a normal node. Then, after obtaining the target index value, the maximum value of the number of stored node identifiers can be obtained (which may be the number of stored node identifiers corresponding to the target serialized block information, or the number of stored node identifiers corresponding to other serialized block information). Furthermore, the maximum value can be compared with a credibility node threshold (the credibility node threshold can be half of the total number of all uploading nodes in the entire business chain or other percentage values. For example, if the SPV node uploads the transaction block information to the relay chain in the second business chain, the credibility threshold can be half of the total number of all SPV nodes). If the maximum value is greater than the credibility threshold, it can be considered that the serialized block information corresponding to the maximum value is indeed sent by a normal node, and the serialized block information can be determined as the serialized block information to be verified. The transaction data to be verified can be further verified based on the serialized block information to be verified. The transaction verification may include: The existence of the transaction data is verified. This involves checking the existence of the transaction data in the serialized block information to determine whether it exists in the block indicated by the target index key using the transaction identifier of the transaction data to be verified. If the data does exist, the execution status of the transaction data is verified. This involves verifying whether the transaction data is successfully executed using the Merkle root of the execution result in the serialized block information to determine whether the transaction data is successfully executed. Once the Merkle root of the transaction data in the serialized block information to be verified is verified, the content of the transaction data is verified. This involves verifying the hash value of the transaction data using the Merkle root of the transaction data in the serialized block information to determine whether the data is successfully executed. If the content is also verified, the verification result of the transaction data is considered successful.

[0147] It should be understood that transaction verification of transaction data to be verified is not limited to the above three aspects (i.e., existence, execution status and content), but may also include other aspects for transaction verification of transaction data to be verified, which is not limited in this application.

[0148] It should be understood that the method provided by this application can not only accurately verify the transaction data to be verified, but also accurately determine which nodes are abnormal nodes (malicious nodes), and block the abnormal nodes so that the data sent by them is no longer received. The specific method can be: if the number of target node identifiers is greater than the node credibility threshold, then the stored upload node identifier set corresponding to the number of target node identifiers is determined as the normal node identifier set, and the remaining node identifier set is determined as the abnormal node identifier set; the remaining node identifier set is the node identifier set other than the normal node identifier set in the stored upload node identifier set corresponding to the Q stored serialized block information; the upload node corresponding to the abnormal node identifier set is determined as an abnormal node, and the abnormal node is blocked within the target time period.

[0149] In an embodiment of the present application, each node (such as an SPV node) in a business chain (such as a first business chain and a second business chain) can obtain transaction block information (such as block header information) in the local business chain in real time, and can send this transaction block information to the relay chain for storage. Since the relay chain stores transaction block information through a data storage contract, and since smart contracts are open and transparent, the reliability of the transaction block information submitted by each node can be greatly improved; wherein, when storing transaction block information, the relay chain can store it in an index pair data structure, and can use the block storage parameter associated with the transaction block information as the index key, and the transaction block information as part of the index value, thereby generating an index key for indicating the transaction block information in a certain business chain. Subsequently, after a node (such as the second node) in a certain business chain (such as the second business chain) successfully stores the index pair corresponding to the transaction block information in the relay chain, other business chains (such as the first business chain) that have cross-chain transaction needs with the business chain can send a transaction verification request to the relay chain for the transaction data to be verified in the transaction block information; the transaction verification contract in the relay chain can obtain the index pair corresponding to the transaction block information, and thus the transaction data to be verified can be verified based on the transaction block information in the index pair. The transaction verification process for the transaction data to be verified is also completed through the transaction verification contract. Due to the open and transparent nature of the smart contract, the transaction block information is reliable, and the security and reliability of the transaction verification can be greatly improved. In summary, by adding a relay chain to the cross-chain transaction verification business, the SPV node in the business chain does not need to store data, which can reduce the reliance on a single node for transaction verification. The storage and verification of transaction data can both be performed through smart contracts, which can better improve the reliability and security of transaction data, and thus improve the security and reliability of transaction verification. In other words, this application can improve the reliability of verification results in cross-chain transaction business, thereby improving the security of cross-chain transaction business.

[0150] For further understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram of a system component structure provided by an embodiment of the present application. Figure 5 As shown, the system component structure may include business chains, blockchain nodes, intermediate chains, business nodes, and databases. For ease of understanding, the system component structure will be explained below.

[0151] The business chain can include different blockchain nodes, such as core nodes, full nodes, and light nodes (SPV nodes). The blockchain nodes in this system structure can be SPV nodes in the business chain. SPV nodes can periodically poll (or subscribe) to obtain block header data from their local business chain. Subsequently, the SPV node can call the data storage contract in the relay chain and send the block header data to the intermediate chain in the form of a relay chain transaction (or the SPV node can send a data storage request to the relay node in the relay chain, and the relay node will then call the data storage contract). Furthermore, because the data storage contract has been called, the data storage contract can write the block header data of the business chain into the relay chain database.

[0152] A business node can be a node in the business chain of a business party (the party that needs to verify transaction data). This business node can refer to a blockchain node deployed on the user side and controlled by the user. The business node can call a transaction verification contract. Once called, the transaction verification contract can obtain relevant data stored in the database and execute relevant logic to obtain the transaction verification result.

[0153] For the specific implementation of data storage, please refer to the above Figure 3 The description of the corresponding embodiment will not be repeated here; for the specific implementation of transaction verification, please refer to the above Figure 4 The description in the corresponding embodiment will not be repeated here.

[0154] For further understanding, please see Figure 6 , Figure 6 This is a logical flow chart of a data storage contract for storing data provided by the embodiment of this application. Figure 6 As shown, the logic flow may include at least the following steps S61 to S74:

[0155] Step S61: Verify whether the node that submitted the block header information is legal.

[0156] Specifically, the blockchain nodes (such as SPV nodes) in each business chain (blockchain) can periodically obtain the block header information of the blocks in the local business chain (which may also include other block information of the block, such as the relevant hash value information of each transaction data mentioned above, here only the block header information is used as an example). The blockchain node can submit the block header information to the intermediate chain in the form of an intermediate chain transaction through the data storage contract in the relay chain. The data storage contract can verify whether the blockchain node submitting the block header information is legitimate. If it is legitimate, it can proceed to step S63; if it is not legitimate, it can proceed to the subsequent step S62.

[0157] Step S62, end.

[0158] Specifically, if the node that submits the information is an illegal node, no other logic will be executed.

[0159] Step S63: parse the data to obtain specific chain and block header information.

[0160] Specifically, the obtained data can be used to obtain the chain information (such as the chain identifier) of the business chain to which the node submitting the information belongs, and the specific block header information (which may also include other block information). The block header information includes the block height of the block to which the block header information belongs.

[0161] Step S64: Check whether the block height specified by the current chain exists.

[0162] Specifically, after obtaining the business chain identifier of the node submitting the information, the relay chain can be queried to see if the data for the block height in the business chain is currently stored. If the relay chain already contains the index key consisting of the business chain identifier and the block height, the subsequent step S65 can be executed; if not, the subsequent step S73 can be executed.

[0163] Step S65: Obtain relevant data stored in the relay chain.

[0164] Specifically, the relevant data indicated by the chain identifier and the block height (that is, the index value corresponding to the index key) can be obtained.

[0165] Step S66: parse the data to form an object set, and traverse the object set.

[0166] Specifically, each serialized block information in the index value can be obtained. Each serialized block information can form an object set. Traversing the object set is equivalent to traversing each serialized block information.

[0167] Step S67: determine whether the serialized block information of the two is consistent.

[0168] Specifically, the information submitted by the currently submitting node can be serialized, and the target serialized block information obtained after serialization can be compared with each serialized block information in the object set to determine whether the two are consistent. If the serialized block information in the object set is consistent with the target serialized block information, the process proceeds to step S70; if the serialized block information in the object set is inconsistent with the target serialized block information, the process proceeds to step S68.

[0169] Step S68, determining whether the traversal of the object set is complete.

[0170] Specifically, if the serialized block information in the object set is inconsistent with the target serialized block information, it is determined whether the object set has been completely traversed. If not, the process proceeds to step S66 to continue the traversal. If the traversal is complete, the process proceeds to step S69.

[0171] Step S69: add a record to the index value corresponding to the index key.

[0172] Specifically, the record is a mapping relationship between the target serialized block information, the upload node identifier set (consisting of the node identifier of the current submitting node), and the number of node identifiers (the number is 1). This record can be added to the index value. After the addition is completed, the subsequent step S71 can be entered.

[0173] Step S70: Determine whether the node is included in the upload node identifier set.

[0174] Specifically, if it is included, the process proceeds to the subsequent step S71; if it is not included, the process proceeds to the subsequent step S72.

[0175] Step S71, end.

[0176] Step S72: add the node ID of the current submitting node to the upload node ID set corresponding to the target serialized block information, and increment the number of node IDs (ie +1). After the execution is completed, the process proceeds to step S71.

[0177] Step S73: The current submission information (i.e., the current block information) is serialized and written into the relay chain.

[0178] Step S74: add a record of the index value corresponding to the index key.

[0179] Specifically, the record is a mapping relationship between the target serialized block information, the upload node identifier set (consisting of the node identifier of the current submitting node), and the number of node identifiers (the number is 1). The record can be added to the index value. After the addition is completed, step S71 can be entered.

[0180] Specifically, for the specific implementation of the above steps S61 to S74, please refer to the above Figure 3 The description in the corresponding embodiment will not be repeated here. The beneficial effects of adopting the same method will not be repeated here either.

[0181] For further understanding, please see Figure 7 , Figure 7 This is a logical flow chart of a transaction verification contract provided by the embodiment of this application for transaction verification. Figure 7 As shown, the logic flow may include at least the following steps S81 to S87:

[0182] Step S81: Use the chain ID and block height as indexes to query whether the corresponding block information exists.

[0183] Specifically, a blockchain node (which can be a business node) in a business chain that needs to verify a transaction (called pending transaction data) can call a transaction verification contract and submit the relay chain in the contract input parameters. The contract input parameters include the pending chain information (i.e., the chain ID of the business chain being verified and the block height of the block to which the pending transaction data belongs). The relay chain can query whether the relevant data is stored in the relay chain based on the chain ID and block height. If so, step S83 can be executed; if not, step 82 can be executed.

[0184] Step S82, end.

[0185] Specifically, if the relevant data does not exist in the intermediate chain, it is likely that the node that submitted the block information is slow in synchronizing data (or due to network problems), resulting in the relevant block information not being uploaded to the intermediate chain. Therefore, a retry prompt message can be returned to the business node to enable the business node to retry.

[0186] Step S83: Obtain the corresponding index value and parse the index value.

[0187] Specifically, if relevant data exists in the relay chain, the index value indicated by the chain identifier and block height can be obtained.

[0188] Step S84: Obtain the largest number of serialized block information.

[0189] Specifically, the serialized block information of the upload node identifier set with the largest number of node identifiers can be obtained from the index value.

[0190] Step S85: determine whether the quantity meets the threshold condition.

[0191] Specifically, if the maximum number meets the threshold condition, the subsequent step S86 can be executed; if not, step S82 can be executed (ie, end, recommend the service node to retry).

[0192] Step S86: Transaction verification is performed based on the serialized block information and the input information.

[0193] Specifically, transaction verification may include but is not limited to three aspects: 1. Proof of existence of the transaction (i.e., verifying that the transaction data to be verified exists in the block in the business chain to be verified); 2. Proof of execution status of the transaction (which can be verified by using the execution result of the transaction data to be verified and the Merkle root of the execution result of the block to which it belongs); Proof of content of the transaction (which can be judged by using the hash value of the contract information of the transaction or transaction execution contract). For the specific implementation of transaction verification, please refer to the above Figure 4 The description in the corresponding embodiment will not be repeated here.

[0194] Step S87, obtain the verification result.

[0195] Specifically, the verification results may include a successful verification result or a failed verification result. A successful verification indicates that the transaction data to be verified has been successfully verified. A failed verification may indicate a problem with the transaction data to be verified, or that the presence of a malicious node has prevented normal nodes from synchronizing the correct block information to the relay chain. It should be noted that if the threshold is set to half the total number of nodes in the business chain, the issue of normal nodes not synchronizing the correct block information to the relay chain due to the presence of a malicious node should not exist, and the business party can make the judgment and confirmation.

[0196] For the specific implementation of the above steps S81 to S87, please refer to the above Figure 4 The description in the corresponding embodiment will not be repeated here. The beneficial effects of adopting the same method will not be repeated here either.

[0197] Further, see Figure 8 , Figure 8 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application. The blockchain-based data processing device can be a computer program (including program code) running on a computer device, for example, the blockchain-based data processing device is an application software; the blockchain-based data processing device can be used to execute Figure 3-Figure 4 As shown in the method. Figure 8 As shown, the blockchain-based data processing device 1 may include: a verification request acquisition module 11, an index pair acquisition module 12 and a transaction verification module 13.

[0198] The verification request acquisition module 11 is configured to acquire a transaction verification request sent by the first node in the first service chain; the transaction verification request carries the chain information to be verified and the transaction identifier of the transaction data to be verified;

[0199] An index pair acquisition module 12 is used to call a transaction verification contract on the relay chain based on a transaction verification request;

[0200] The index pair acquisition module 12 is further configured to acquire a target index pair in the relay chain using the transaction verification contract and the chain information to be verified. The target index pair is generated when storing transaction block information using the data storage contract, and the transaction block information is sent by the second node in the second business chain. The target index pair is used to indicate a mapping relationship between a target index key and a target index value. The target index key includes block storage parameters associated with the transaction block information, and the block storage parameters match the chain information to be verified. The target index value includes the transaction block information. The first business chain and the second business chain are different.

[0201] A transaction verification module 13, configured to perform transaction verification on the transaction data to be verified based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value;

[0202] The transaction verification module 13 is further configured to send the verification result to the first node.

[0203] The specific implementation of the verification request acquisition module 11, the index pair acquisition module 12 and the transaction verification module 13 can be found in the above Figure 4 The description of steps S201 to S203 in the corresponding embodiment will not be repeated here.

[0204] In one embodiment, the blockchain-based data processing device 1 may further include: a storage request acquisition module 14, a storage parameter determination module 15, a key determination module 16, a value determination module 17 and a data storage module 18.

[0205] A storage request acquisition module 14 is configured to acquire a data storage request for transaction block information sent by the second node; the data storage request carries the block height of the block to which the transaction block information belongs;

[0206] The storage parameter determination module 15 is used to call the data storage contract in the relay chain according to the data storage request, and determine the chain identifier of the second business chain and the block height of the block to which the transaction block information belongs as the block storage parameters through the storage logic of the data storage contract;

[0207] A key determination module 16 is configured to determine a target index key based on the block storage parameters;

[0208] a value determination module 17, configured to determine a target index value based on an initial index value corresponding to the target index key, transaction block information, and an identifier of the second node;

[0209] The data storage module 18 is configured to store a target index pair consisting of a target index key and a target index value into the relay chain.

[0210] The specific implementation of the storage request acquisition module 14, the storage parameter determination module 15, the key determination module 16, the value determination module 17 and the data storage module 18 can be found in the above Figure 3 The description of steps S101 to S104 in the corresponding embodiment will not be repeated here.

[0211] In one embodiment, the key determination module 16 may include: an index pair traversal unit 161 and a key determination unit 162 .

[0212] An index pair traversal unit 161 is configured to traverse N stored index pairs in the relay chain; a stored index pair is configured to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes stored block storage parameters associated with stored block information;

[0213] a key determining unit 162 configured to determine the stored index key to which the target stored block storage parameter belongs as the target index key if there is a target stored block storage parameter identical to the block storage parameter among the stored block storage parameters included in the N stored index pairs;

[0214] The key determining unit 162 is further configured to determine the index key composed of the block storage parameters as the target index key if there is no target stored block storage parameter identical to the block storage parameter among the stored block storage parameters included in the N stored index pairs.

[0215] The specific implementation of the index pair traversal unit 161 and the key determination unit 162 can be found in the above Figure 3 The description of step S203 in the corresponding embodiment will not be repeated here.

[0216] In one embodiment, the initial index value includes M association mapping relationships; one association mapping relationship is used to indicate an association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; M is a positive integer;

[0217] The value determination module 17 may include: a serialization processing unit 171 , a block information traversal unit 172 , and an index value determination unit 173 .

[0218] The serialization processing unit 171 is used to serialize the transaction block information to obtain target serialized block information;

[0219] The block information traversal unit 172 is used to traverse M stored serialized block information;

[0220] An index value determining unit 173 is configured to, if target stored serialized block information identical to the target serialized block information exists among the M stored serialized block information, add the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information, and increment the number of stored node identifiers in the target stored upload node identifier set to obtain a target index value;

[0221] The index value determination unit 173 is further used to generate a target upload node identifier set corresponding to the target serialized block information based on the node identifier of the second node if the target serialized block information does not exist in the M stored serialized block information, use the number of node identifiers of the second node as the number of target node identifiers in the target upload node identifier set, associate the target serialized block information, the target upload node identifier set, and the number of target node identifiers and add them to the initial index key to obtain the target index value.

[0222] The specific implementation of the serialization processing unit 171, the block information traversal unit 172 and the index value determination unit 173 can be found in the above Figure 3 The description of step S203 in the corresponding embodiment will not be repeated here.

[0223] In one embodiment, the value determination module 17 may further include: a set traversal unit 174 , a value determination unit 175 and a step execution unit 176 .

[0224] A set traversal unit 174 is used to traverse the stored upload node identifier set corresponding to the target stored serialized block information;

[0225] a value determining unit 175 configured to determine the initial index value as the target index value if the node identifier of the second node exists in the stored upload node identifier set corresponding to the target stored serialized block information;

[0226] The step execution unit 176 is used to add the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information if the node identifier of the second node does not exist in the stored upload node identifier set corresponding to the target stored serialized block information, and to increase the number of stored node identifiers in the target stored upload node identifier set to obtain a target index value.

[0227] The specific implementation of the set traversal unit 174, the value determination unit 175 and the step execution unit 176 can be found in the above Figure 3 The description of step S203 in the corresponding embodiment will not be repeated here.

[0228] In one embodiment, the chain information to be verified includes the chain identifier of the second business chain and the block height of the block to which the transaction data to be verified belongs;

[0229] The index pair acquisition module 12 may include: a traversal unit 121 and an index pair determination unit 122 .

[0230] The traversal unit 121 is configured to traverse N stored index pairs in the relay chain through the verification logic in the transaction verification contract; a stored index pair is used to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes a stored block storage parameter associated with the stored block information; the stored index key includes the stored block storage parameter, and the stored block storage parameter includes a stored chain identifier and a stored block height; the stored chain identifier is the chain identifier of the stored business chain, the stored block height is the block height of the block to which the stored block information belongs, and the block to which the stored block information belongs belongs to the stored business chain; the stored block information includes transaction block information, the N stored index pairs include an index pair corresponding to the transaction block information, the stored chain identifier in the index pair corresponding to the transaction block information is the chain identifier of the second business chain, and the stored block height in the index pair corresponding to the transaction block information is the block height of the block to which the transaction block information belongs, and the block height of the block to which the transaction data to be verified belongs is the same as the block height of the block to which the transaction data to be verified belongs;

[0231] The index pair determination unit 122 is configured to determine, as a target index pair, an index pair corresponding to the transaction block information whose stored chain identifier matches the chain identifier of the second business chain and whose stored block height matches the block height of the block to which the transaction data to be verified belongs, among the N stored index pairs.

[0232] The specific implementation of the traversal unit 121 and the index pair determination unit 122 can be found in the above Figure 4 The description of step S202 in the corresponding embodiment will not be repeated here.

[0233] In one embodiment, the target index value includes Q association mapping relationships; one association mapping relationship is used to indicate an association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; a stored serialized block information refers to information obtained after serializing a stored block information, and the Q stored serialized block information include the target serialized block information corresponding to the transaction block information; Q is a positive integer;

[0234] The transaction verification module 13 may include: an identification quantity comparison unit 131 , a target quantity determination unit 132 , and a transaction verification unit 133 .

[0235] The identification number comparison unit 131 is used to obtain the number of stored node identifications corresponding to the target serialized block information;

[0236] The identification number comparison unit 131 is further configured to use the maximum number of stored node identifications among the numbers of stored node identifications corresponding to the remaining stored serialized block information as the number of node identifications to be compared, and compare the number of node identifications to be compared with the number of stored node identifications corresponding to the target serialized block information; the remaining stored serialized block information is the stored serialized block information among the Q stored serialized block information, excluding the target serialized block information;

[0237] A target number determining unit 132 is configured to determine the maximum number of node identifiers between the number of stored node identifiers corresponding to the target serialized block information and the number of node identifiers to be compared as the target number of node identifiers;

[0238] The transaction verification unit 133 is configured to perform transaction verification on the transaction data to be verified according to the number of target node identifiers and the transaction identifier of the transaction data to be verified.

[0239] The specific implementation of the identification quantity comparison unit 131, the target quantity determination unit 132 and the transaction verification unit 133 can be found in the above Figure 4 The description of step S203 in the corresponding embodiment will not be repeated here.

[0240] In one embodiment, the transaction verification unit 133 is further configured to determine the verification result of the transaction data to be verified as a verification failure result if the number of target node identifiers is less than the node credibility threshold;

[0241] The transaction verification unit 133 is further specifically configured to determine the stored serialized block information corresponding to the number of target node identifiers as the serialized block information to be verified if the number of target node identifiers is greater than the node credibility threshold, and perform transaction verification on the transaction data to be verified based on the serialized block information to be verified and the transaction identifier of the transaction data to be verified.

[0242] In one embodiment, the transaction verification unit 133 is further specifically configured to obtain a stored transaction identifier of stored transaction data contained in the serialized block information to be verified;

[0243] The transaction verification unit 133 is further specifically configured to determine that the transaction data to be verified exists in the stored transaction data if the transaction identifier of the transaction data to be verified exists in the stored transaction identifiers, and perform transaction verification on the transaction data to be verified based on the Merkle root of the stored transaction data contained in the serialized block information to be verified;

[0244] The transaction verification unit 133 is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the transaction identifier of the transaction data to be verified does not exist in the stored transaction identifiers.

[0245] In one embodiment, the transaction verification unit 133 is further configured to obtain an execution result hash value corresponding to the remaining transaction data; the remaining transaction data is the transaction data in the stored transaction data excluding the transaction data to be verified;

[0246] The transaction verification unit 133 is further specifically configured to generate a Merkle root to be verified based on the execution result hash value corresponding to the remaining transaction data and the execution result hash value corresponding to the transaction data to be verified;

[0247] The transaction verification unit 133 is further specifically configured to match the Merkle root of the stored transaction data with the Merkle root to be verified;

[0248] The transaction verification unit 133 is further specifically configured to, if the Merkle root of the stored transaction data matches the Merkle root to be verified, perform transaction verification on the transaction data to be verified based on the hash value corresponding to the stored transaction data contained in the serialized block information to be verified;

[0249] The transaction verification unit 133 is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the Merkle root of the stored transaction data and the Merkle root to be verified result in a matching failure.

[0250] In one embodiment, the transaction verification unit 133 is further specifically configured to obtain a data hash value corresponding to the remaining transaction data;

[0251] The transaction verification unit 133 is further specifically configured to generate a hash value to be verified based on the data hash value corresponding to the remaining transaction data and the data hash value corresponding to the transaction data to be verified;

[0252] The transaction verification unit 133 is further specifically configured to match the hash value of the stored transaction data with the hash value to be verified;

[0253] The transaction verification unit 133 is further specifically configured to determine the verification result of the transaction data to be verified as a successful verification result if the hash value of the stored transaction data matches the hash value to be verified;

[0254] The transaction verification unit 133 is further specifically configured to determine the verification result of the transaction data to be verified as a verification failure result if the hash value of the stored transaction data and the hash value to be verified do not match.

[0255] In one embodiment, the blockchain-based data processing device 1 may further include: an abnormal set determination module 19 and a shielding processing module 20.

[0256] The abnormal set determination module 19 is configured to, if the number of target node identifiers is greater than the node credibility threshold, determine the stored uploaded node identifier set corresponding to the target node identifier number as the normal node identifier set, and determine the remaining node identifier set as the abnormal node identifier set; the remaining node identifier set is the node identifier set other than the normal node identifier set in the stored uploaded node identifier sets corresponding to the Q stored serialized block information;

[0257] The shielding processing module 20 is configured to determine the uploading node corresponding to the abnormal node identification set as an abnormal node, and shield the abnormal node within a target time period.

[0258] The specific implementation of the abnormal set determination module 19 and the shielding processing module 20 can be found in the above Figure 4 The description of step S203 in the corresponding embodiment will not be repeated here.

[0259] In an embodiment of the present application, each node (such as an SPV node) in a business chain (such as a first business chain and a second business chain) can obtain transaction block information (such as block header information) in the local business chain in real time, and can send this transaction block information to the relay chain for storage. Since the relay chain stores transaction block information through a data storage contract, and since smart contracts are open and transparent, the reliability of the transaction block information submitted by each node can be greatly improved; wherein, when storing transaction block information, the relay chain can store it in an index pair data structure, and can use the block storage parameter associated with the transaction block information as the index key, and the transaction block information as part of the index value, thereby generating an index key for indicating the transaction block information in a certain business chain. Subsequently, after a node (such as the second node) in a certain business chain (such as the second business chain) successfully stores the index pair corresponding to the transaction block information in the relay chain, other business chains (such as the first business chain) that have cross-chain transaction needs with the business chain can send a transaction verification request to the relay chain for the transaction data to be verified in the transaction block information; the transaction verification contract in the relay chain can obtain the index pair corresponding to the transaction block information, and thus the transaction data to be verified can be verified based on the transaction block information in the index pair. The transaction verification process for the transaction data to be verified is also completed through the transaction verification contract. Due to the open and transparent nature of the smart contract, the transaction block information is reliable, and the security and reliability of the transaction verification can be greatly improved. In summary, by adding a relay chain to the cross-chain transaction verification business, the SPV node in the business chain does not need to store data, which can reduce the reliance on a single node for transaction verification. The storage and verification of transaction data can both be performed through smart contracts, which can better improve the reliability and security of transaction data, and thus improve the security and reliability of transaction verification. In other words, this application can improve the reliability of verification results in cross-chain transaction business, thereby improving the security of cross-chain transaction business.

[0260] Further, see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 9 As shown above Figure 8The blockchain-based data processing device 1 in the corresponding embodiment can be applied to the above-mentioned computer device 9000. The above-mentioned computer device 9000 may include: a processor 9001, a network interface 9004 and a memory 9005. In addition, the above-mentioned computer device 9000 also includes: a user interface 9003, and at least one communication bus 9002. Among them, the communication bus 9002 is used to realize the connection and communication between these components. Among them, the user interface 9003 may include a display screen (Display), a keyboard (Keyboard), and the optional user interface 9003 may also include a standard wired interface and a wireless interface. The network interface 9004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 9005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 9005 may optionally also be at least one storage device located away from the aforementioned processor 9001. As Figure 9 As shown, the memory 9005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0261] exist Figure 9 In the computer device 9000 shown, the network interface 9004 can provide network communication functions; the user interface 9003 is mainly used to provide an interface for user input; and the processor 9001 can be used to call the device control application stored in the memory 9005 to achieve:

[0262] Obtaining a transaction verification request sent by a first node in a first business chain; the transaction verification request carries information about the chain to be verified and a transaction identifier of the transaction data to be verified;

[0263] Based on the transaction verification request, the transaction verification contract on the relay chain is called, and the target index pair is obtained in the relay chain through the transaction verification contract and the chain information to be verified. The target index pair is generated when the transaction block information is stored in the data storage contract. The transaction block information is sent by the second node in the second business chain. The target index pair is used to indicate the mapping relationship between the target index key and the target index value. The target index key contains the block storage parameters associated with the transaction block information. The block storage parameters match the chain information to be verified. The target index value contains the transaction block information. The first business chain and the second business chain are different.

[0264] Based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value, the transaction data to be verified is subjected to transaction verification, and the verification result is sent to the first node.

[0265] It should be understood that the computer device 9000 described in the embodiment of the present application can execute the above Figures 3 to 4 The description of the data processing method based on blockchain in the corresponding embodiment can also be performed as described above. Figure 8 The description of the blockchain-based data processing device 1 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here.

[0266] In addition, it should be noted that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the computer device 9000 for data processing mentioned above, and the computer program includes program instructions. When the processor executes the program instructions, the computer program can execute the above-mentioned data processing. Figures 3 to 4 The description of the above-mentioned data processing method in the corresponding embodiment will therefore not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0267] The computer-readable storage medium can be the blockchain-based data processing device provided in any of the aforementioned embodiments, or the internal storage unit of the computer device, such as the computer device's hard drive or memory. 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. Furthermore, the computer-readable storage medium can include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or is about to be output.

[0268] In one aspect of the present application, a computer program product or computer program is provided. The computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of the present application.

[0269] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising 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 appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

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

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

Claims

1. A data processing method based on blockchain, characterized in that: include: Obtaining a transaction verification request sent by a first node in a first service chain; the transaction verification request carries information about the chain to be verified and a transaction identifier of the transaction data to be verified; Based on the transaction verification request, a transaction verification contract on the relay chain is called, and a target index pair is obtained in the relay chain through the transaction verification contract and the chain information to be verified; the target index pair is generated when the transaction block information is stored through the data storage contract, and the transaction block information is sent by the second node in the second business chain; the target index pair is used to indicate the mapping relationship between the target index key and the target index value, the target index key includes the block storage parameters associated with the transaction block information, and the block storage parameters match the chain information to be verified; the target index value includes the transaction block information; the first business chain and the second business chain are different; Performing transaction verification on the transaction data to be verified based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value, and sending the verification result to the first node; The process of storing the target index pair in the relay chain includes: Obtain a data storage request for the transaction block information sent by the second node; the data storage request carries the block height of the block to which the transaction block information belongs; call the data storage contract in the relay chain according to the data storage request, and determine the chain identifier of the second business chain and the block height of the block to which the transaction block information belongs as the block storage parameters through the storage logic of the data storage contract; determine the target index key according to the block storage parameters, and determine the target index value according to the initial index value corresponding to the target index key, the transaction block information, and the identifier of the second node; and store the target index pair consisting of the target index key and the target index value in the relay chain.

2. The method according to claim 1, characterized in that The determining the target index key according to the block storage parameter includes: Traversing N stored index pairs in the relay chain; a stored index pair is used to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes a stored block storage parameter associated with the stored block information; If there is a target stored block storage parameter identical to the block storage parameter among the stored block storage parameters included in the N stored index pairs, determining the stored index key to which the target stored block storage parameter belongs as the target index key; If there is no target stored block storage parameter identical to the block storage parameter among the stored block storage parameters included in the N stored index pairs, an index key composed of the block storage parameters is determined as the target index key.

3. The method according to claim 1, characterized in that The initial index value includes M association mapping relationships; one association mapping relationship is used to indicate the association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; M is a positive integer; The determining the target index value according to the initial index value corresponding to the target index key, the transaction block information, and the identifier of the second node includes: Serializing the transaction block information to obtain target serialized block information; Traverse M stored serialized block information; If there is target stored serialized block information identical to the target serialized block information among the M stored serialized block information, then adding the node identifier of the second node to the target stored upload node identifier set corresponding to the target stored serialized block information, and incrementing the number of stored node identifiers in the target stored upload node identifier set to obtain the target index value; If the target existing serialized block information does not exist in the M existing serialized block information, a target upload node identifier set corresponding to the target serialized block information is generated according to the node identifier of the second node, the number of node identifiers of the second node is used as the number of target node identifiers of the target upload node identifier set, the target serialized block information, the target upload node identifier set and the number of target node identifiers are associated and added to the initial index key to obtain the target index value.

4. The method according to claim 3, characterized in that The method further comprises: Traversing the stored upload node identifier set corresponding to the target stored serialized block information; If the node identifier of the second node exists in the stored upload node identifier set corresponding to the target stored serialized block information, determining the initial index value as the target index value; If the node identifier of the second node does not exist in the stored upload node identifier set corresponding to the target stored serialized block information, the step of adding the node identifier of the second node to the stored upload node identifier set corresponding to the target stored serialized block information, and increasing the number of stored node identifiers in the target stored upload node identifier set to obtain the target index value is performed.

5. The method according to claim 1, wherein The chain information to be verified includes the chain identifier of the second business chain and the block height of the block to which the transaction data to be verified belongs; The obtaining of a target index pair in the relay chain using the transaction verification contract and the chain information to be verified includes: The verification logic in the transaction verification contract traverses N stored index pairs in the relay chain; a stored index pair is used to indicate a mapping relationship between a stored index key and a stored index value; the stored index key includes a stored block storage parameter associated with the stored block information; the stored index key includes the stored block storage parameter, and the stored block storage parameter includes a stored chain identifier and a stored block height; the stored chain identifier is the chain identifier of the stored business chain, and the stored block height is the block height of the block to which the stored block information belongs. , the block to which the stored block information belongs belongs to the stored business chain; the stored block information includes the transaction block information, the N stored index pairs include the index pair corresponding to the transaction block information, the stored chain identifier in the index pair corresponding to the transaction block information is the chain identifier of the second business chain, and the stored block height in the index pair corresponding to the transaction block information is the block height of the block to which the transaction block information belongs, and the block height of the block to which the transaction block information belongs is the same as the block height of the block to which the transaction data to be verified belongs; An index pair corresponding to the transaction block information whose stored chain identifier among the N stored index pairs matches the chain identifier of the second business chain, and whose stored block height matches the block height of the block to which the transaction data to be verified belongs is determined as the target index pair.

6. The method according to claim 5, characterized in that The target index value includes Q association mapping relationships; one association mapping relationship is used to indicate the association relationship between a stored serialized block information, a stored upload node identifier set corresponding to the stored serialized block information, and the number of stored node identifiers in the stored upload node identifier set; a stored serialized block information refers to information obtained by serializing a stored block information, and the Q stored serialized block information include the target serialized block information corresponding to the transaction block information; Q is a positive integer; The performing transaction verification on the transaction data to be verified based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value includes: Obtain the number of stored node identifiers corresponding to the target serialized block information; The maximum number of stored node identifiers among the numbers of stored node identifiers corresponding to the remaining stored serialized block information is used as the number of node identifiers to be compared, and the number of node identifiers to be compared is compared with the number of stored node identifiers corresponding to the target serialized block information; the remaining stored serialized block information is the stored serialized block information among the Q stored serialized block information, excluding the target serialized block information; Determine the maximum number of node identifiers between the number of stored node identifiers corresponding to the target serialized block information and the number of node identifiers to be compared as the target number of node identifiers; Transaction verification is performed on the transaction data to be verified according to the target node identifier number and the transaction identifier of the transaction data to be verified.

7. The method according to claim 6, characterized in that The performing transaction verification on the transaction data to be verified according to the number of target node identifiers and the transaction identifier of the transaction data to be verified includes: If the number of target node identifiers is less than the node credibility threshold, the verification result of the transaction data to be verified is determined as a verification failure result; If the number of target node identifiers is greater than the node credibility threshold, the stored serialized block information corresponding to the number of target node identifiers is determined as the serialized block information to be verified, and transaction verification is performed on the transaction data to be verified based on the serialized block information to be verified and the transaction identifier of the transaction data to be verified.

8. The method according to claim 7, characterized in that The performing transaction verification on the transaction data to be verified according to the serialized block information to be verified and the transaction identifier of the transaction data to be verified includes: Obtaining a stored transaction identifier of stored transaction data contained in the serialized block information to be verified; If the transaction identifier of the transaction data to be verified exists in the stored transaction identifiers, determining that the transaction data to be verified exists in the stored transaction data, and performing transaction verification on the transaction data to be verified according to the Merkle root of the stored transaction data contained in the serialized block information to be verified; If the transaction identifier of the transaction data to be verified does not exist in the stored transaction identifiers, the verification result of the transaction data to be verified is determined as a verification failure result.

9. The method according to claim 8, characterized in that The performing transaction verification on the transaction data to be verified according to the Merkle root of the stored transaction data contained in the serialized block information to be verified includes: Obtaining an execution result hash value corresponding to the remaining transaction data; the remaining transaction data is the transaction data in the stored transaction data excluding the transaction data to be verified; Generate a Merkle root to be verified based on the execution result hash value corresponding to the remaining transaction data and the execution result hash value corresponding to the transaction data to be verified; Matching the Merkle root of the stored transaction data with the Merkle root to be verified; If the Merkle root of the stored transaction data matches the Merkle root to be verified, transaction verification is performed on the transaction data to be verified based on the hash value corresponding to the stored transaction data contained in the serialized block information to be verified; If the Merkle root of the stored transaction data and the Merkle root to be verified do not match, the verification result of the transaction data to be verified is determined as a verification failure result.

10. The method according to claim 9, characterized in that The performing transaction verification on the transaction data to be verified according to the hash value corresponding to the stored transaction data contained in the serialized block information to be verified includes: Obtaining a data hash value corresponding to the remaining transaction data; Generate a hash value to be verified based on the data hash value corresponding to the remaining transaction data and the data hash value corresponding to the transaction data to be verified; Matching the hash value of the stored transaction data with the hash value to be verified; If the hash value of the stored transaction data matches the hash value to be verified, the verification result of the transaction data to be verified is determined as a successful verification result; If the hash value of the stored transaction data and the hash value to be verified do not match, the verification result of the transaction data to be verified is determined as a verification failure result.

11. The method according to claim 7, characterized in that The method further comprises: If the number of target node identifiers is greater than the node credibility threshold, the stored uploaded node identifier set corresponding to the target node identifier number is determined as a normal node identifier set, and the remaining node identifier set is determined as an abnormal node identifier set; the remaining node identifier set is the node identifier set other than the normal node identifier set in the stored uploaded node identifier sets corresponding to the Q stored serialized block information; The uploading node corresponding to the abnormal node identification set is determined as an abnormal node, and the abnormal node is shielded within a target time period.

12. A data processing device based on blockchain, characterized in that: include: A verification request acquisition module, configured to acquire a transaction verification request sent by a first node in a first service chain; the transaction verification request carries information about the chain to be verified and a transaction identifier of the transaction data to be verified; An index pair acquisition module, configured to call a transaction verification contract on the relay chain based on the transaction verification request; The index pair acquisition module is further configured to acquire a target index pair in the relay chain using the transaction verification contract and the chain information to be verified; the target index pair is generated when storing transaction block information, and the transaction block information is sent by the second node in the second business chain; the target index pair is used to indicate a mapping relationship between a target index key and a target index value, the target index key including a block storage parameter associated with the transaction block information, the block storage parameter matching the chain information to be verified; and the target index value including the transaction block information. a transaction verification module, configured to perform transaction verification on the transaction data to be verified based on the transaction identifier of the transaction data to be verified and the transaction block information in the target index value; The transaction verification module is further configured to send the verification result to the first node; The process of storing the target index pair in the relay chain includes: Obtain a data storage request for the transaction block information sent by the second node; the data storage request carries the block height of the block to which the transaction block information belongs; call the data storage contract in the relay chain according to the data storage request, and determine the chain identifier of the second business chain and the block height of the block to which the transaction block information belongs as the block storage parameters through the storage logic of the data storage contract; determine the target index key according to the block storage parameters, and determine the target index value according to the initial index value corresponding to the target index key, the transaction block information, and the identifier of the second node; and store the target index pair consisting of the target index key and the target index value in the relay chain.

13. 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 a network communication function, the memory is used to store program code, and the processor is used to call the program code so that the computer device executes the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the method according to any one of claims 1 to 11.

Images