Data processing method and apparatus based on blockchain, and device and medium

Abstract

A data processing method based on a blockchain. The method, which is executed by means of a computer device that maintains a consensus node on a second blockchain, comprises: acquiring a cross-chain message submitted by means of a forwarding service device, and acquiring a blockchain identifier carried in the cross-chain message, wherein the cross-chain message is associated with cross-chain transaction data stored in a first blockchain (S101); acquiring, from a second blockchain corresponding to the blockchain identifier, block Merkle information corresponding to the first blockchain, and acquiring, from a block Merkle tree represented by the block Merkle information, a Merkle proof set corresponding to the cross-chain message, wherein the Merkle proof set includes node information of some nodes in the block Merkle tree, and the verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of a block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain (S102); performing validity verification on the cross-chain message according to the Merkle proof set and the block Merkle information, so as to obtain a cross-chain verification result corresponding to the cross-chain message (S103); and if the cross-chain verification result indicates that the verification is successful, acquiring a transaction execution result corresponding to the cross-chain message, and storing the transaction execution result in the second blockchain (S104).

Description

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

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2023106312148, filed on May 30, 2023, entitled “Blockchain-based data processing methods, devices, equipment and media,” the entire text of which is hereby incorporated by reference. Technical Field

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

[0004] Blockchain is a decentralized, distributed ledger system characterized by data immutability, decentralization, and openness. Consensus mechanisms, at the core of blockchain technology, are fundamental to ensuring the proper functioning of blockchain systems. The consensus process in a blockchain system can be understood as the process of maintaining consistency in the distributed ledgers across all blockchain nodes. With the development and application of blockchain technology, cross-chain transactions between different blockchains are becoming increasingly common, such as asset transfers and asset custody authorizations. In these cross-chain transaction scenarios, verification is necessary to ensure the security of data across different blockchains.

[0005] Currently, during the verification process for cross-chain transactions, each blockchain node must maintain a large amount of data from one or more blockchains (such as the block headers of all blocks on the chain) and verify the blockchain structure. As the amount of chain data increases, the data storage capacity of blockchain nodes becomes excessive, resulting in low cross-chain transaction verification efficiency.

[0006] Summary of the Invention

[0007] Based on the various embodiments of the present application, a blockchain-based data processing method, apparatus, device, and medium are provided.

[0008] On one hand, an embodiment of the present application provides a blockchain-based data processing method, which is executed by a computer device that maintains a consensus node on a second blockchain, including:

[0009] Obtaining a cross-chain message submitted by the forwarding service device and a blockchain identifier carried by the cross-chain message, wherein the cross-chain message is associated with cross-chain transaction data stored in the first blockchain;

[0010] In the second blockchain corresponding to the blockchain identifier, obtaining the block Merkle information corresponding to the first blockchain, and in the block Merkle tree represented by the block Merkle information, obtaining the Merkle proof set corresponding to the cross-chain message, wherein the Merkle proof set includes node information of some nodes in the block Merkle tree, and the verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of the cross-chain transaction data indicated by the cross-chain message in the first blockchain;

[0011] Verify the validity of the cross-chain message based on the Merkle proof set and the block Merkle information to obtain a cross-chain verification result corresponding to the cross-chain message; and

[0012] If the cross-chain verification result indicates that the verification is successful, the transaction execution result corresponding to the cross-chain message is obtained, and the transaction execution result is stored in the second blockchain.

[0013] On one hand, an embodiment of the present application provides a blockchain-based data processing method, which is executed by a forwarding service device, including:

[0014] Obtaining a cross-chain message triggered by the first blockchain, and obtaining the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain, wherein the cross-chain message carries a blockchain identifier corresponding to the second blockchain; and

[0015] If, in the second blockchain corresponding to the blockchain identifier, it is detected that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, the cross-chain message is forwarded to the consensus node of the second blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message based on the Merkle proof set corresponding to the cross-chain message and the Merkle information of the block at the verifiable height in the first blockchain, and obtains a cross-chain verification result corresponding to the cross-chain message;

[0016] The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message in the second blockchain when the cross-chain verification result indicates that the verification is successful.

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

[0018] A cross-chain message acquisition unit, configured to acquire a cross-chain message submitted by the forwarding service device and acquire a blockchain identifier carried by the cross-chain message, wherein the cross-chain message is associated with the cross-chain transaction data stored in the first blockchain;

[0019] a proof set acquisition unit, configured to acquire, from a second blockchain corresponding to the blockchain identifier, block Merkle information corresponding to the first blockchain, and acquire, from a block Merkle tree represented by the block Merkle information, a Merkle proof set corresponding to the cross-chain message, wherein the Merkle proof set includes node information of some nodes in the block Merkle tree, and a verifiable height of the block Merkle information in the first blockchain is greater than or equal to a block height of the block in which the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain;

[0020] The cross-chain message verification unit is used to verify the validity of the cross-chain message based on the Merkle proof set and the block Merkle information, and obtain the cross-chain verification result corresponding to the cross-chain message; and

[0021] The cross-chain message execution unit is configured to obtain a transaction execution result corresponding to the cross-chain message if the cross-chain verification result indicates that the verification is successful, and store the transaction execution result in the second blockchain.

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

[0023] a block height acquisition unit, configured to acquire a cross-chain message triggered by the first blockchain, and acquire the block height of the block in the first blockchain where the cross-chain transaction data indicated by the cross-chain message is located, wherein the cross-chain message carries a blockchain identifier corresponding to the second blockchain; and

[0024] a cross-chain message forwarding unit, configured to, if it is detected in the second blockchain corresponding to the blockchain identifier that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, forward the cross-chain message to the consensus node of the second blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message based on the Merkel proof set corresponding to the cross-chain message and the Merkel information of the block at the verifiable height in the first blockchain, and obtain a cross-chain verification result corresponding to the cross-chain message;

[0025] The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message in the second blockchain when the cross-chain verification result indicates that the verification is successful.

[0026] In one aspect, an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory is connected to the processor, the memory is used to store computer-readable instructions, and the processor is used to call the computer-readable instructions so that the computer device executes the method provided in the above aspect of the embodiment of the present application.

[0027] On one hand, an embodiment of the present application provides a computer-readable storage medium, in which computer-readable instructions are stored. The computer-readable instructions are suitable for being loaded and executed by a processor, so that a computer device with a processor executes the method provided in the above aspect of the embodiment of the present application.

[0028] According to one aspect of the present application, a computer program product is provided, the computer program product including computer-readable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer-readable instructions from the computer-readable storage medium and executes the computer-readable instructions, causing the computer device to perform the method provided in the above aspect.

[0029] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or traditional technical descriptions. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the disclosed drawings without any creative work.

[0031] FIG1 is a schematic diagram of a hierarchical structure of a blockchain network provided in an embodiment of the present application;

[0032] FIG2 is a schematic diagram of a multi-chain structure of a blockchain network provided in an embodiment of the present application;

[0033] FIG3 is a flow chart of a data processing method based on blockchain provided in an embodiment of the present application;

[0034] FIG4 is a schematic diagram of creating a block Merkle tree provided by an embodiment of the present application;

[0035] FIG5 is a schematic diagram of a block structure provided in an embodiment of the present application;

[0036] FIG6 is a timing diagram of a blockchain-based data processing method provided in an embodiment of the present application;

[0037] FIG7 is a schematic diagram of block data verification based on the Merkle Mountains provided in an embodiment of the present application;

[0038] FIG8 is a schematic diagram of a cross-chain message verification process provided by an embodiment of the present application;

[0039] FIG9 is a schematic diagram of the overall structure of a cross-chain technology between different blockchains provided in an embodiment of the present application;

[0040] FIG10 is a schematic diagram of the structure of a trusted prediction device provided in an embodiment of the present application;

[0041] FIG11 is a system architecture diagram of a tax blockchain system provided in an embodiment of the present application;

[0042] FIG12 is a first structural diagram of a blockchain-based data processing device provided in an embodiment of the present application;

[0043] FIG13 is a second structural diagram of a blockchain-based data processing device provided in an embodiment of the present application;

[0044] FIG14 is a schematic structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0046] For ease of understanding, the basic technologies involved in the embodiments of this application are described below:

[0047] Blockchain: A blockchain is a decentralized, distributed storage infrastructure. Specifically, it's a data structure that organizes data blocks in chronological order, similar to a linked list. It securely stores sequential, system-verifiable data, and uses cryptography to ensure that data is traceable, non-repudiable, tamper-proof, and unforgeable, all while maintaining a decentralized structure. Blockchains typically consist of consensus, transaction blocks, state data storage, and cryptographic identity security. The underlying blockchain platform can include modules such as basic services, smart contracts, and operations management.

[0048] The basic service module is deployed on each blockchain node to verify the validity of business requests and store valid requests after reaching consensus. For a new business request, the basic service module first performs interface adaptation, parsing, and authentication (i.e., interface adaptation) on the business request. It then encrypts the business information indicated by the business request through a consensus algorithm (consensus management). After encryption, it is completely and consistently transmitted to the shared ledger (network communication) for storage. The smart contract module is responsible for contract registration, release, contract triggering, and contract execution. Developers can define contract logic in a programming language and publish it to the blockchain (contract registration). Based on the logic of the contract terms, they call keys or other events to trigger execution and complete the contract logic. It also provides the ability to upgrade and cancel contracts. The operations management module is primarily responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time visualization of product status during product release, such as alarms, network management, and node device health status. It is understandable that the embodiments of the present application may involve cross-chain transaction processing between different blockchains (for example, a first blockchain and a second blockchain). Different blockchains may be responsible for different business types, and the interaction and communication between multiple blockchains are completed through cross-chain technology based on MMR (Merkle Mountain Range, which can be called Merkle Mountain Range, or range Merkle proof).

[0049] Smart contracts: A computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts can be understood as computer-readable instructions running on a blockchain. These instructions, with pre-defined rules, state, and response conditions, can encapsulate, verify, and execute complex behaviors of distributed nodes, fulfilling at least one of the following functions: information exchange, value transfer, or asset management. Based on blockchain's distributed architecture and consensus algorithms, smart contracts allow mutually untrusting users to complete transactions without the need for any trusted third-party intermediary or authority. Furthermore, digital smart contracts can be flexibly embedded in various tangible or intangible assets, transactions, and data to enable active or passive asset and information management and control, gradually building programmable smart assets and systems. Unlike ordinary programs, smart contracts guarantee identical results on every blockchain node in the blockchain network, enabling any blockchain node to verify the correctness of the smart contract execution results in the data block. In the embodiments of the present application, different smart contracts can be deployed in the blockchain according to the requirements of specific application scenarios. In other words, different smart contracts can have different functions. In the embodiments of the present application, the smart contracts can be named according to their functions. For example, a smart contract used to manage the permissions of a lightweight node (Simplified Payment Verification, SPV node) can be called an SPV permissions contract, and a smart contract used to clear general tax data can be called a general data clearing contract. It is understood that smart contracts can also use the first and second descriptions to distinguish different smart contracts. A lightweight node is a credential-based lightweight node that does not need to download, verify, and store the entire blockchain. Instead, it only needs to download a small number of blocks and some transactions in these blocks to complete a given task, such as verifying a specific transaction. Since only a small number of blocks need to be downloaded, SPV nodes have low hardware and bandwidth requirements, making them very feasible and easy to implement.

[0050] P2P (Peer-to-Peer) network: A peer-to-peer network based on a specific type of network protocol. Network nodes do not require a central node to maintain network status. Each network node can maintain the node status of the entire network, or the node status of the adjacent network node, by broadcasting and interacting with adjacent network nodes.

[0051] Digital Certificate: In a public key infrastructure (PKI), a digital certificate is a proof of identity for a public key holder. This digital certificate can be issued by an authority, referred to as a Certificate Authority (CA). Asymmetric encryption and digital signatures can be implemented using the public key certificate system.

[0052] Consortium chain: A blockchain with an access mechanism, including consensus nodes and non-consensus nodes (for ease of understanding, non-consensus nodes in the embodiments of this application can be referred to as business nodes). Generally speaking, smart contracts on any blockchain require execution by all consensus nodes. If the execution results are consistent, it can be determined that consensus has been reached among the consensus nodes on the blockchain. Business nodes generally do not execute smart contracts on the blockchain, but can synchronize the execution results of smart contracts from consensus nodes to their business nodes.

[0053] Subchains (or branch chains): A concept derived from the parent chain (or main chain), they can be simply understood as blockchains built on the underlying parent chain. Subchains represent various industries or verticals within blockchain, and are also a general term for various blockchains within these sub-sectors. When a subchain is created, its relevant information is recorded on the parent chain. This means that data added to the subchain must rely on the parent chain for storage, verification, and traceability.

[0054] Transaction: A form of blockchain execution. The transaction contains the private key signature of the initiator, which can ensure the authenticity, non-forgeability and non-repudiation of the transaction content.

[0055] Please refer to Figure 1, which is a schematic diagram of a blockchain network hierarchical structure provided in an embodiment of the present application. The blockchain network hierarchical structure in the embodiment of the present application can be the blockchain network 1 shown in Figure 1. The complete blockchain business system corresponding to the blockchain network 1 can be composed of the business network (also referred to as the witness network), the core consensus network and the routing proxy network shown in Figure 1. Among them, the number of proxy nodes in the routing proxy network can be one or more, which is not limited here. The embodiment of the present application takes the proxy node 10i as an example. The proxy node 10i can be used to isolate the business network and the core consensus network. The proxy node 10i can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services, which is not limited here. The proxy node 10i can perform network stratification on the peer-to-peer (P2P) network to form a hierarchical structure such as "business network-core consensus network", thereby improving the confidentiality and security of data on the blockchain.

[0056] The business network shown in FIG1 may include one or more blockchain nodes, and the number of nodes in the business network is not limited here. For example, the business network may specifically include nodes 10a, 10b, 10c, 10d, 10e, 10f, 10g, and 10h. In the present embodiment, the blockchain nodes in the business network may be referred to as business nodes. Business nodes do not need to participate in the accounting consensus and are primarily used to execute transaction operations to obtain corresponding business transactions. The business nodes here can be full nodes containing the complete blockchain database or lightweight nodes storing partial data in the blockchain database, and the above are not limited here. To reduce the waste of storage space of the business nodes, the business nodes in the present embodiment are exemplified by SPV nodes. Such business nodes do not need to store complete transaction data, but instead obtain block header data and partially authorized visible block data (e.g., business transactions associated with the business node itself) from the core consensus network shown in FIG1 through proxy node 10i.

[0057] The core consensus network shown in FIG1 may also include one or more blockchain nodes, and the number of nodes in the core consensus network is not limited. For example, the core consensus network may specifically include node 10j, node 10k, node 10m, node 10n, node 10p, node 10q, node 10r, and node 10s. In the embodiment of the present application, the blockchain nodes in the core consensus network may be referred to as consensus nodes (also referred to as accounting nodes), and these consensus nodes may run the blockchain consensus protocol.

[0058] It should be understood that in the embodiments of the present application, proxy nodes, business nodes, and consensus nodes may be collectively referred to as blockchain nodes in the blockchain network 1. A blockchain node may be a server connected to the blockchain network 1 or a terminal device connected to the blockchain network 1. The specific form of the blockchain node is not limited here. For example, terminal devices may include, but are not limited to, PCs (personal computers), smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smart watches and smart bracelets), smart voice interaction devices, smart home appliances (such as smart TVs), vehicle-mounted devices, aircraft, and other electronic devices. A server may be an independent physical server, or 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, CDNs (Content Delivery Networks), and big data and artificial intelligence platforms. This application does not limit the type of server. It is understandable that the business network and core consensus network shown in Figure 1 can be in different network environments. For example, the business nodes can be deployed in the business network on the public network, while the consensus nodes running the blockchain consensus protocol are deployed in the private core consensus network. The two can interact through the routing boundary.

[0059] As shown in Figure 1, the core consensus network may include blockchain 10t, which may include the genesis block, block B1, block B2, block B3, block B4, and block B5, etc., and blockchain 10t may be configured with consensus permissions. When a node 10j in the core consensus network has consensus permissions for blockchain 10t, it indicates that the node 10j can independently reach consensus on blockchain 10t, i.e., can participate in the consensus process of the blocks contained in blockchain 10t. The consensus nodes in the core consensus network that have consensus permissions for blockchain 10t can constitute an independent blockchain consensus network, which can include all or part of the consensus nodes in the core consensus network. The number of consensus nodes in the independent blockchain consensus network is not limited here. For example, if the blockchain network 1 shown in Figure 1 is a tax blockchain system used in tax business, the consensus node that independently reaches consensus on blockchain 10t can be a terminal device used by the tax management agency (e.g., the State Administration of Taxation, local tax bureau, etc.) in the tax blockchain system. The consensus node can be used to submit business transaction data in the tax business to blockchain 10t. The tax business here specifically includes different types of transaction businesses such as bill business, credit business, import and export business, enterprise qualification business, and tax refund business. It should be understood that in a complex environment of multiple types of transaction businesses, the embodiment of the present application can expand the two-layer structure of the blockchain network shown in Figure 1 into a multi-chain structure. Different blockchains can be responsible for different business directions, and different blockchains can interact and communicate with each other through cross-chain technology based on MMR.

[0060] In other words, in addition to the blockchain 10t shown in FIG1 , the blockchains included in the core consensus network may also include blockchains corresponding to various types of transaction services. Blockchain 10t and the blockchains corresponding to various types of transaction services may be independent blockchains in the core consensus network; alternatively, various types of transaction services may be transaction services derived from blockchain 10t in the core consensus network, i.e., the blockchains corresponding to various types of transaction services may be branches (child chains) of blockchain 10t. In this case, blockchain 10t may be referred to as the main chain (parent chain). This embodiment of the present application does not limit the relationship between the blockchains included in the core consensus network.

[0061] Alternatively, if multiple blockchains in the core consensus network are independent blockchains, then consensus nodes in the core consensus network with consensus authority for each blockchain can submit business transaction data to the corresponding blockchain. For example, if the core consensus network contains two independent blockchains (for ease of understanding, the two blockchains here can be referred to as blockchain A and blockchain B), all consensus nodes with consensus authority for blockchain A can constitute an independent consensus network for blockchain A, and all consensus nodes with consensus authority for blockchain B can constitute an independent consensus network for blockchain B. The independent consensus network for blockchain A and the independent consensus network for blockchain B can include the same consensus nodes or different consensus nodes, and this application does not limit this. For example, if blockchain A is a blockchain corresponding to bill business, then the consensus nodes in the independent consensus network for blockchain A can be used to add business transaction data from the bill business to blockchain A; if blockchain B is a blockchain corresponding to import and export business, then the consensus nodes in the independent consensus network for blockchain B can be used to add business transaction data from the import and export business to blockchain B. It is understood that the independent consensus network for blockchain A corresponding to blockchain A and the independent consensus network for blockchain B corresponding to blockchain B can be collectively referred to as independent consensus networks.

[0062] Optionally, if the multiple blockchains in the core consensus network include a main chain (e.g., blockchain 10t) and multiple branch chains corresponding to multiple transaction businesses derived from the main chain, blockchain 10t (main chain) may include registration information for each branch chain corresponding to each transaction business. The registration information for each branch chain corresponding to each transaction business may include the blockchain identifier of the branch chain, the business configuration information of the transaction business, the derivation conditions corresponding to the blockchain identifier, etc. Specifically, the business configuration information for a transaction business (e.g., a bill business) may include basic information about the transaction business (i.e., a description of the bill business) and node configuration information (business node configuration information and consensus node configuration information). The business node configuration information may include business nodes used to execute transaction businesses (e.g., bill businesses), i.e., the business nodes included in the business node configuration information may constitute an independent business network for the branch chain; the consensus node configuration information may include consensus nodes used to participate in the independent consensus of the branch chain, i.e., the consensus nodes included in the consensus node configuration information all have consensus authority over the branch chain, and may constitute an independent consensus network for the branch chain. The derivation conditions corresponding to each branch chain can be used to determine the genesis block of the corresponding branch chain on the blockchain 10t (main chain). Each branch chain is derived from the derivation conditions on the main chain. Each branch chain corresponds to a transaction business, and each branch chain corresponds to a blockchain identifier. This effectively distinguishes different transaction businesses and maintains the specificity of the data stored in a single branch chain. It is understood that the main chain independent business network corresponding to the main chain and the branch chain independent business network corresponding to each branch chain can be collectively referred to as independent business networks; the main chain independent consensus network and the branch chain independent consensus network can also be referred to as independent consensus networks.

[0063] It is understandable that in the embodiments of the present application, whether multiple independent blockchains or the main chain and its corresponding branch chains, can be collectively referred to as blockchains, and all blockchains involved in the embodiments of the present application can be consortium chains. In the multi-layer structure of the blockchain network, each blockchain can have its corresponding independent consensus network and corresponding independent business network; wherein, the independent consensus network can be composed of some or all of the consensus nodes in the core consensus network shown in Figure 1, and the blockchain independent business network can be composed of some or all of the business nodes in the business network shown in Figure 1. Different blockchains can interact and communicate through MMR-based cross-chain technology, and the blockchain independent business networks corresponding to different blockchains cannot interact directly.

[0064] For ease of understanding, please refer to Figure 2, which is a schematic diagram of a multi-chain blockchain network structure provided by an embodiment of the present application. As shown in Figure 2, the present application embodiment uses an electronic bill multi-chain network as an example to describe the multi-chain blockchain network structure. The complete blockchain business system corresponding to this multi-chain blockchain network structure can be composed of business network participants (which can be considered as business nodes in the business network), the electronic bill multi-chain network, and participants within the consortium chain (which can be considered as consensus nodes in the core consensus network). Participants in the business network may include, but are not limited to, individual users, corporate users, local bill SPV node 1 (local bill lightweight node 1), local bill SPV node 2, application X bill SPV node, and branch chain X bill SPV node. The electronic bill multi-chain network may include, but are not limited to, the management chain 20a, bill chain 20b, application contract chain 20c, and branch chain 20d derived from the application contract chain 20c. Participants within the consortium chain may include, but are not limited to, the management chain full SPV and its corresponding tax administration agency, the bill chain full SPV and its corresponding electronic bill data center, the application contract chain full SPV node and its corresponding government cooperation agency, and business-related organizations. Local bill lightweight node 1 refers to a specific region within the tax system, such as a province or county. X refers to a specific object, such as application X bill SPV node, which can refer to a bill SPV node for a specific application, and branch chain X bill SPV node, which can refer to a bill SPV node for a specific branch chain.

[0065] It's understandable that different blockchains can correspond to different business network participants and consortium chain internal participants. As shown in Figure 2, the business network participants corresponding to management chain 20a can include individual users and corporate users. Individual users and corporate users can access block header data and partially authorized block data (e.g., business transactions related to themselves) in management chain 20a through the tax administration agency portal. The consortium chain internal participants corresponding to management chain 20a can include the tax administration agency, which can act as the full SPV for the management chain and hold the complete block data in management chain 20a. Consortium chain internal participants can also include organizations within the government intranet.

[0066] The business network participants corresponding to the bill chain 20b may include local bill SPV node 1, local bill SPV node 2, application X bill SPV node and branch chain X bill SPV node, etc. Local bill SPV node 1, local bill SPV node 2, application X bill SPV node and branch chain X bill SPV node, etc. can all obtain block header data and partially authorized visible block data in the bill chain 20b through the electronic bill business entrance; the internal participants of the alliance chain corresponding to the bill chain 20b may include the electronic bill data center, which can serve as the full SPV node of the bill chain and hold the complete block data in the bill chain 20b.

[0067] The business network participants corresponding to application contract chain 20c may include application X-bill SPV nodes, etc., which can obtain block header data and partially authorized visible block data in application contract chain 20c through the tax derivative business portal. The internal participants of the consortium chain corresponding to application contract chain 20c may include government collaboration agencies and business-related agencies, etc., which can both serve as full-volume SPV nodes for the application contract chain and hold the complete block data in application contract chain 20c. Branch chain 20d, as the business branch chain corresponding to the transaction business derived from application contract chain 20c (any type of bill in the electronic bill business, such as type X bill), may include application X-bill SPV nodes and branch chain X-bill SPV nodes. Application X-bill SPV nodes and branch chain X-bill SPV nodes may obtain block header data and partially authorized visible block data in branch chain 20d through the tax derivative business portal. Branch chain 20d may have the same internal consortium chain participants as application contract chain 20c, but this embodiment of the present application does not limit this. It is understandable that the tax administration agency entrance, the electronic invoice business entrance, and the tax derivative business entrance can all be considered as proxy nodes in the routing proxy network shown in FIG. 1 .

[0068] As shown in Figure 2, the management chain 20a can be deployed with a global management information contract, which can be used to manage all management information related to tax business. This management chain 20a can be primarily responsible for tax metadata management. The bill chain 20b can be deployed with smart contracts such as the global information cross-chain contract, the electronic bill rights and clearance contract, the electronic bill SPV rights and clearance contract, and the electronic bill business contract. The application contract chain 20c can be deployed with smart contracts such as the global information cross-chain contract, the application chain SPV rights and clearance contract, various tax application contracts, and the general data clearance contract. The branch chain 20d of the application contract chain 20c can be deployed with smart contracts such as the global information cross-chain contract, the branch chain SPV rights and clearance contract, the dedicated tax application contract, and the general data clearance contract.

[0069] Among them, the global information cross-chain contract can be responsible for cross-chain processing of the complete data stored in the corresponding blockchain; the electronic bill SPV permission contract can be used to manage the read permission of the business node corresponding to the bill chain 20b on the data stored in the bill chain 20b; the electronic bill permission clearing contract is responsible for synchronizing the business transaction data stored in the bill chain 20b to the business node with read permission; the electronic bill business contract is responsible for processing the business transaction data (for example, electronic bill transaction data) submitted to the bill chain 20b. Various tax application contracts and dedicated tax application contracts can include a data clearing interface, through which the business transaction data stored in the corresponding blockchain can be synchronized to the business node with read permission; the general data clearing contract is responsible for synchronizing the general data stored in the corresponding blockchain to the business node with read permission; the application chain SPV permission contract can be used to manage the read permission of the business node corresponding to the application contract chain 20c on the data stored in the application contract chain 20c; the branch chain SPV permission contract can be used to manage the read permission of the business node corresponding to the branch chain 20d on the data stored in the branch chain 20d.

[0070] It is understandable that multiple blockchains in an electronic bill multi-chain network can interact and communicate with each other through a cross-chain relay. This cross-chain relay can be understood as establishing a channel between two blockchains. A specific data structure is created within the channel, allowing the two blockchains to interact with each other through the data structure within the channel. The channel established between the two blockchains can be called a cross-chain relay. In other words, different blockchains cannot interact and communicate directly, but need to interact and communicate through cross-chain technology. An important link in cross-chain technology is the verification process of cross-chain messages. In order to improve the verification efficiency of cross-chain messages, the embodiment of the present application proposes a cross-chain technology based on MMR (Merkel Mountain). In the cross-chain technology based on MMR, the verification capability of the MMR root can be relied upon to quickly verify cross-chain messages at a certain block height. At the same time, in order to ensure the correctness of the MMR root information, a TEE (Trusted Execution Environment) trusted oracle can be introduced to maintain and submit the MMR root information. In other words, in the MMR-based cross-chain technology proposed in the embodiment of the present application, each blockchain only needs to store part of the MMR root information to complete the verification of the cross-chain message, which can reduce the data storage usage and improve the verification efficiency of the cross-chain message.

[0071] Among them, the specific implementation process of this MMR-based cross-chain technology provided in the embodiments of the present application can be found in the embodiments corresponding to Figures 3 to 11 below.

[0072] Please refer to Figure 3, which is a flow chart of a blockchain-based data processing method provided in an embodiment of the present application. It is understood that the blockchain-based data processing method can be applied in a cross-chain communication scenario between a first blockchain and a second blockchain. The blockchain-based data processing method here can be executed by any consensus node on the second blockchain, specifically by the computer device that maintains any consensus node. As shown in Figure 3, the blockchain-based data processing method can include at least the following steps S101 to S104:

[0073] Step S101: Obtain a cross-chain message submitted by a forwarding service device, and obtain a blockchain identifier carried by the cross-chain message. The cross-chain message is associated with cross-chain transaction data stored in the first blockchain.

[0074] The forwarding service device may be a device used for cross-chain communication between the first blockchain and the second blockchain. The forwarding service device may be a device that actively or passively performs cross-chain communication between the first blockchain and the second blockchain. The forwarding service device may be a device other than the computer device that maintains the first blockchain and the second blockchain.

[0075] A blockchain identifier uniquely identifies a blockchain and can be a string. The blockchain identifier carried in a cross-chain message can be the identifier of a second blockchain. A cross-chain message is associated with cross-chain transaction data stored in a first blockchain, meaning the cross-chain transaction indicated by the cross-chain message is associated with the cross-chain transaction data stored in the first blockchain.

[0076] A cross-chain message can be a message sent to a second blockchain after the first blockchain completes the cross-chain transaction portion responsible for it. This message indicates the cross-chain transaction portion responsible for the second blockchain. In other words, a cross-chain message can be understood as a cross-chain transaction triggered by the first blockchain based on the cross-chain transaction data.

[0077] In a multi-chain structure of a blockchain network (for example, the multi-chain network of electronic bills in the embodiment corresponding to FIG2 ), cross-chain technology can be used to maintain interaction and communication between different blockchains. The embodiment of this application takes the interaction between the first blockchain and the second blockchain as an example to describe. The first blockchain and the second blockchain can collaboratively execute the same transaction, such as asset custody authorization, cross-chain transfer request, and other transactions. In this case, the first blockchain can be understood as the blockchain that triggers the cross-chain message, and the second blockchain can be understood as the blockchain that receives and executes the cross-chain message. Nodes in the first blockchain (including consensus nodes) can communicate cross-chain with nodes in the second blockchain (including consensus nodes) through a forwarding service device.

[0078] In one or more embodiments, a user can use a resource client to initiate a cross-chain transaction request to a cross-chain server. The cross-chain transaction request specifies cross-chain transaction data, and the cross-chain server submits the cross-chain transaction data to the first blockchain. When the cross-chain transaction data is successfully stored in the first blockchain, a cross-chain management contract deployed in the first blockchain can trigger a cross-chain message for the cross-chain transaction data.

[0079] Among them, the resource client used by the user can be used to implement the resource management business function, and based on the resource management business function, realize the communication connection with the cross-chain server (a decentralized application). The resource client is a tool for managing and storing user digital resources; for example, digital resources can be transferred to other accounts based on the resource client, and digital resources transferred from other accounts can be received based on the resource client. The resource client can be a hardware device or a software program. In the embodiment of the present application, the resource client used by the user can establish a communication connection with the cross-chain server to realize the user's authorized login and other related operations. It is understandable that with the widespread deployment of various decentralized applications on the blockchain, the user's activities on the blockchain have increased. When using decentralized applications, general users can use the resource client to log in. The user address in the resource client corresponds to a user of the blockchain. The decentralized application can obtain the user address from the resource client through some interfaces, solving the problem that the decentralized application cannot trust the user address used for login.

[0080] The cross-chain service end may refer to a service platform that interacts with users who initiate cross-chain business. The cross-chain service end may include a cross-chain service front-end and a cross-chain service back-end. The cross-chain service front-end may include but is not limited to web pages, applications, sub-programs embedded in applications (for example, they may be called mini-programs), etc.; the cross-chain service back-end may be the background service corresponding to the cross-chain service front-end, such as web page back-end service, application back-end service, etc. The cross-chain service back-end may be used to provide data and blockchain transaction functions for the cross-chain service front-end.

[0081] Cross-chain transaction data may refer to transactions encapsulated from cross-chain transactions triggered by users through resource clients on cross-chain servers. Such cross-chain transaction data may be transactions encapsulated based on asset custody authorization requests, or transactions encapsulated based on cross-chain transfer requests, etc.

[0082] A cross-chain message can be a message sent to a second blockchain after the first blockchain completes the cross-chain transaction portion responsible for it. This message indicates the cross-chain transaction portion responsible for the second blockchain. In other words, a cross-chain message can be understood as a cross-chain transaction triggered by the first blockchain based on the cross-chain transaction data.

[0083] A cross-chain management contract can be pre-deployed in both the first blockchain and the second blockchain. The cross-chain management contract can serve as the submission entry for cross-chain transactions and is used to manage cross-chain transactions received by the blockchain. The cross-chain management contract involved in the embodiments of this application can specifically be a cross-chain bridge contract. It is understood that a cross-chain bridge can refer to a system for transmitting information between two or more blockchains. In other words, a cross-chain bridge can realize information transmission between two or more blockchains. This information can include but is not limited to digital assets, contract calls, proofs, or status. The proof can be, for example, a range Merkle proof, and the status can be the blockchain status or the status of a blockchain node.

[0084] In an embodiment of the present application, a forwarding service device can detect cross-chain management contracts in each blockchain in real time or periodically. If the forwarding service device detects that a cross-chain management contract deployed in a first blockchain has triggered a cross-chain message, it can obtain the cross-chain message from the cross-chain management contract deployed in the first blockchain and submit the cross-chain message to the cross-chain management contract in the second blockchain. The forwarding service device forwards the cross-chain message triggered by the cross-chain management contract in the first blockchain to the second blockchain only if the block height H2 of the block containing the cross-chain message in the first blockchain is less than or equal to the verifiable height H1 of the first blockchain stored in the second blockchain. The forwarding service device can be used to forward cross-chain messages between different blockchains, that is, the forwarding service device can be used to provide a cross-chain message forwarding service. The forwarding service device does not need to guarantee the correctness of the cross-chain message and only needs to submit the cross-chain message triggered by the first blockchain to the second blockchain as is.

[0085] The consensus node of the second blockchain (i.e., any consensus node with consensus authority over the first blockchain, such as any consensus node in the independent consensus network corresponding to the second blockchain) can obtain the cross-chain message submitted by the forwarding service device through the cross-chain management contract in the second blockchain. The cross-chain message may include the blockchain identifier corresponding to the blockchain used to receive the cross-chain message. The consensus node of the second blockchain can obtain the blockchain identifier carried in the cross-chain message. The blockchain corresponding to the blockchain identifier can be referred to as the second blockchain.

[0086] Step S102: In the second blockchain corresponding to the blockchain identifier, obtain the block Merkle information corresponding to the first blockchain, and in the block Merkle tree represented by the block Merkle information, obtain the Merkle proof set corresponding to the cross-chain message. The Merkle proof set includes node information of some nodes in the block Merkle tree. The verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain.

[0087] The block Merkle information may refer to the MMRR (Merkle Mountain Range Root) information corresponding to the maximum block height in the first blockchain. The block Merkle tree may refer to the MMR tree composed of all blocks included in the first blockchain, where each leaf node in the MMR tree is a block in the first blockchain or a hash value of each block in the first blockchain. Alternatively, the block Merkle tree may refer to the MMR tree composed of the block headers of each block in the first blockchain, where the leaf nodes in the MMR tree are the block headers of each block in the first blockchain or may specifically be the hash values ​​of each block in the first blockchain. This application does not limit this.

[0088] A non-leaf node in a block Merkle tree is generated based on its child nodes. Furthermore, a non-leaf node in a block Merkle tree can be generated based on the blocks represented by its child nodes, or based on the hash values ​​of the blocks represented by its child nodes. Furthermore, a non-leaf node can be generated by performing a hash operation on the concatenation of the blocks represented by its child nodes. The block Merkle tree can be a binary tree.

[0089] A Merkle proof set (or MMR proof set) refers to the node information of some nodes in the block Merkle tree that the second blockchain needs to use to verify the validity of the cross-chain message. In other words, when verifying the validity of the cross-chain message, there is no need to store the node information of all nodes in the block Merkle tree. Instead, only the node information in the Merkle proof set is required, which saves storage space and reduces data storage usage.

[0090] Blocks are added to the blockchain in chronological order. The block height represents the number of blocks in the block Merkle tree at a given point in time, i.e., the number of blocks in the first blockchain. This can be the number itself or a positive correlation with it. The verifiable height can be the maximum block height corresponding to the block Merkle information stored in the second blockchain, or the maximum block height of the first blockchain known in the second blockchain.

[0091] In some embodiments, the block Merkle tree can be a binary tree. When a new block is added to the first blockchain and consensus is reached on the new block in the independent consensus network corresponding to the first blockchain, the new block can be added to the first blockchain, and the existing block Merkle tree corresponding to the first blockchain can be used as the first Merkle subtree. Based on the first Merkle subtree and the new block, a new block Merkle tree corresponding to the first blockchain is constructed, and the Merkle range root of the new block Merkle tree is obtained. The new block records the Merkle range root of the existing block Merkle tree.

[0092] Furthermore, in some embodiments, based on the first Merkle subtree and the newly added block, a new block Merkle tree corresponding to the first blockchain is formed, including: if there is no leaf node at the same level as the newly added block in the first Merkle subtree, then the newly added block is used as the second Merkle subtree, and the parent node information of the first Merkle subtree and the second Merkle subtree is generated. The first Merkle subtree, the second Merkle subtree, and the parent node information of the two form a new block Merkle tree corresponding to the first blockchain; if there is a leaf node in the first Merkle subtree that independently constitutes a Merkle subtree, then the leaf node is used as the second Merkle subtree. point, and the brother node of the leaf node that independently constitutes the Merkle subtree is the subtree root of another Merkle subtree, then based on the leaf node that independently constitutes the Merkle subtree and the newly added block, the first parent node information of the leaf node that independently constitutes the Merkle subtree and the newly added block is generated, and then based on the first parent node information and the subtree root of the aforementioned other Merkle subtree, the second parent node information is generated to obtain a new block Merkle tree corresponding to the first blockchain, which is composed of the subtree root of the other Merkle subtree, the leaf node that independently constitutes the Merkle subtree, the first parent node information and the second parent node information.

[0093] Please refer to Figure 4, which is a schematic diagram of the creation of a block Merkle tree provided in an embodiment of the present application; the block Merkle tree in the embodiment of the present application is an MMR tree. For example: the first blockchain contains three data blocks, namely block 1, block 2 and block 3, of which block 0 is the genesis block. When block 1 is generated in the first blockchain and block 1 reaches consensus in the independent consensus network corresponding to the first blockchain, block 1 can be added to the first blockchain. At this time, block 0 (genesis block) and block 1 can form an MMR tree. At this time, the MMR tree can include node information of two levels of nodes (including block 0, block 1, and parent node information 1 generated by block 0 and block 2). At this time, the MMR root corresponding to the MMR tree can be recorded as Merkle Mountain Root 1 (which can be recorded as MMRR1).

[0094] Next, if block 2 is added to the first blockchain, MMRR1 can be included in block 2. Since there is no leaf node at the same level as block 2 in the MMR tree, block 2 can be added to the MMR tree as a Merkle subtree, and block 0 and block 1 constitute another Merkle subtree in the MMR tree. At this time, the subtree roots of the two Merkle subtrees (i.e., block 2 and MMRR1) can be merged into Merkle mountain root 2 (which can be recorded as MMRR2).

[0095] Furthermore, if the first blockchain continues to add block 3, then block 3 can contain MMRR2. Since there is block 2 at the same level as block 3 in the MMR tree, parent node information 2 corresponding to block 2 and block 3 can be generated. The parent node information 2 is at the same level as the aforementioned parent node information 1, so parent node information 3 corresponding to parent node information 1 and parent node information 2 can be generated, thereby obtaining the MMR tree corresponding to the maximum block height (the maximum block height here is 3). The MMR root corresponding to the MMR tree at this time can be recorded as Merkle Mountain Root 3 (which can be recorded as MMRR3).

[0096] As shown in FIG4 , the MMR tree construction process shows that when a new block is added to the first blockchain (which can refer to the leaf node information in the MMR tree, and all blocks in the first blockchain can serve as leaf node information in the MMR tree), the intermediate node information in the MMR tree (for example, the aforementioned parent node information 1, parent node information 2, and parent node information 3, etc.) will not change, and data is always added to the MMR tree in an appended form. No additional data structure support is required in the process of constructing the MMR tree. It is only necessary to add the previous MMR root to each block, such as adding MMRR1 (Merkel range root 1) to block 2, adding MMRR2 (Merkel range root 2) to block 3, and so on. It should be noted that MMRR1, MMRR2, and MMRR3 in Figure 4 represent different root information. While it may appear that MMRR2 replaces MMRR1 and MMRR3 replaces MMRR2, this is not a replacement relationship. Instead, the Merkle Mountain Root corresponding to the time point when block 1 joins the MMR tree is MMRR1, and the Merkle Mountain Root corresponding to the time point when block 2 joins the MMR tree is MMRR2, and so on. In other words, MMRR1, MMRR2, and MMRR3 are the Merkle Mountain Roots of the MMR tree at different points in time. This characteristic of the MMR tree allows a single Merkle Mountain Root (MMRR) to cover all nodes. Furthermore, after each block is created, the corresponding Merkle Mountain Root does not need to be changed. Instead, a field storing the previous Merkle Mountain Root is added to the block header of each block, thus avoiding hard or soft forks.

[0097] Optionally, when constructing the MMR tree corresponding to the first blockchain, the block headers of all blocks contained in the first blockchain can be used to construct it, or the full data of all blocks contained in the first blockchain can be used to construct it. This application is not limited to this. Through the construction principle of MMR, the consensus node of the second blockchain only needs a small amount of proof data (that is, the node information in the MMR tree contained in the Merkel proof set), that is, it can verify whether block 3 and block 0 are in the same blockchain, which can save storage space.

[0098] Specifically, the block Merkle information corresponding to the first blockchain can be obtained in the chain verification contract deployed by the second blockchain corresponding to the blockchain identifier (the chain verification contract here can specifically be the first blockchain verification contract, and one blockchain can correspond to one chain verification contract); determine the first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs in the first blockchain, and obtain the block path information of the first cross-chain transaction block in the block Merkle tree represented by the block Merkle information; obtain the subtree root information corresponding to multiple Merkle subtrees contained in the block Merkle tree, and combine the subtree root information and the node information contained in the block path information into a Merkle proof set corresponding to the cross-chain message.

[0099] Optionally, the process of obtaining the block path information may include: obtaining a block hash value corresponding to the first cross-chain transaction block, determining the Merkle subtree to which the block hash value belongs in the block Merkle tree represented by the block Merkle information; using the block hash value as the starting node information, traversing the hierarchical node information in the Merkle subtree to which the block hash value belongs until traversing to the subtree root information in the Merkle subtree to which the block hash value belongs, and determining the block path information corresponding to the first cross-chain transaction block based on the traversed hierarchical node information. In other words, starting from the leaf node information (block hash value) corresponding to the first cross-chain transaction block, searching for the upper-level parent node information in the block Merkle tree (MMR tree) until terminating at the subtree root information (Merkle Tree Root, MTR) of the Merkle subtree to which the first cross-chain transaction block belongs in the block Merkle tree. The set of node information traversed through the search may be referred to as the block path information corresponding to the first cross-chain transaction block.

[0100] In a multi-chain blockchain network, multiple blockchain verification contracts can be deployed on each blockchain. For example, assume the multi-chain blockchain network structure contains four blockchains, designated as the first blockchain, the second blockchain, the third blockchain, and the fourth blockchain. The first blockchain can deploy the second blockchain verification contract, the third blockchain verification contract, and the third blockchain verification contract; the second blockchain can deploy the first blockchain verification contract, the third blockchain verification contract, and the fourth blockchain verification contract; and so on. Each chain verification contract deployed on a blockchain corresponds to one blockchain. Each chain verification contract can be used to store the latest block Merkle information (MMR root information) on the corresponding blockchain and update the corresponding verifiable height H1.

[0101] Further, please refer to Figure 5, which is a schematic diagram of a block structure provided by an embodiment of the present application. The blockchain shown in Figure 5 can be a first blockchain (specifically, it can include a genesis block, block 1, block 2, block 3, block 4, and block 5), and the block 4 shown in Figure 5 can be the first cross-chain transaction block to which the cross-chain transaction data belongs in the first blockchain. Among them, block 4 can be composed of a block header and a block body, and the block body can be used to store the transaction data (including cross-chain transaction data) encapsulated in the block 4. The block header can include a version number, a timestamp, a difficulty value, a target hash, a block header hash value of the previous block (i.e., a block header hash value of block 3), a Merkle tree root (transaction Merkle information), and a Merkle mountain root (block Merkle information).

[0102] The Merkle tree root in the block header may refer to the root information corresponding to the Merkle tree obtained by performing a hash operation on the multiple transaction data stored in block 4 (specifically, transaction tx1, transaction tx2, transaction tx3, and transaction tx4). The hash value corresponding to transaction tx1 may be recorded as Hash1, the hash value corresponding to transaction tx2 may be recorded as Hash2, and so on. By performing a hash operation on Hash1 and Hash2, a hash value Hash(1&2) may be obtained, and by performing a hash operation on Hash3 and Hash4, a hash value Hash(3&4) may be obtained. By performing a hash operation on Hash(1&2) and Hash(3&4), a hash value Hash((1&2)&(3&4)) may be obtained. Thus, a Merkle tree corresponding to all transaction data stored in block 4 may be constructed. The Merkle Mountain Root in the block header can refer to the MMR tree obtained by hashing the three block headers before block 4. That is, the Merkle Mountain Root in the block header of block 4 can be the Merkle Mountain Root corresponding to block 3. The hash value corresponding to the block header of block 1 is recorded as Hash5, the hash value corresponding to the block header of block 2 is recorded as Hash6, and the hash value corresponding to the block header of block 3 is recorded as Hash7. The hash value Hash(5&6) is obtained by hashing Hash5 and Hash6, and the Merkle Mountain Root in the block header can be obtained by merging Hash7 and Hash(5&6).

[0103] It should be noted that the hash algorithms used in the hash operations involved in the embodiments of the present application may include but are not limited to: SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512, and this application does not limit this.

[0104] Step S103: Verify the validity of the cross-chain message based on the Merkle proof set and the block Merkle information to obtain the cross-chain verification result corresponding to the cross-chain message.

[0105] Specifically, in an embodiment of the present application, the verification capability of the block Merkle information (MMR root information) can be relied upon, and the first blockchain verification contract in the second blockchain can be called by the cross-chain management contract in the second blockchain to quickly verify the validity of the cross-chain message. For example, the validity of the cross-chain message can be verified based on the Merkle proof set (such as the Merkle mountain proof set) and the block Merkle information (such as the MMR root information) to obtain the cross-chain verification result corresponding to the cross-chain message.

[0106] Among them, the validity verification process of the cross-chain message can include the verification of the first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs and the verification of the cross-chain transaction data, wherein the verification of the first cross-chain transaction block is based on the block Merkel information (MMR root information) and its corresponding block Merkel tree (MMR tree), and the verification of the cross-chain transaction data is based on the transaction Merkel information (the Merkel tree root in the block header of the first cross-chain transaction block) and its corresponding transaction Merkel tree (the Merkel tree corresponding to all transaction data in the block body of the first cross-chain transaction block).

[0107] If the cross-chain verification result indicates successful verification, it indicates that the cross-chain message is stored in the first blockchain and is intact and unaltered. If the cross-chain verification result indicates failed verification, it indicates that the cross-chain message is not stored in the first blockchain or has been tampered with. An error message corresponding to the cross-chain message can be generated and sent to the forwarding service device via the cross-chain management contract in the second blockchain, so that the forwarding service device forwards the error message to the cross-chain management contract in the first blockchain. The error message is used to instruct the first blockchain to re-trigger the cross-chain message.

[0108] Step S104: If the cross-chain verification result indicates that the verification is successful, the transaction execution result corresponding to the cross-chain message is obtained and the transaction execution result is stored in the second blockchain.

[0109] Specifically, if the cross-chain verification result indicates successful verification, it means that the cross-chain transaction data contained in the cross-chain message has been stored in the first blockchain and the cross-chain message is complete and untampered. Then, the cross-chain message (which may be the aforementioned cross-chain transaction data) can be encapsulated together with other transaction data into a second cross-chain transaction block. The second cross-chain transaction block can be broadcast in the independent consensus network corresponding to the second blockchain, so that all consensus nodes in the independent consensus network corresponding to the second blockchain (i.e., the consensus nodes of the second blockchain) can perform consensus processing on the second cross-chain transaction block. The structure of the second cross-chain transaction block can be as shown in block 4 of the embodiment corresponding to Figure 5 above, and will not be repeated here.

[0110] During the consensus phase of the second cross-chain transaction block, the consensus nodes participating in the consensus of the second cross-chain transaction block can obtain the transaction type corresponding to the cross-chain message, call the asset processor contract that matches the transaction type through the cross-chain management contract (e.g., the cross-chain bridge contract) in the second blockchain, perform transaction execution processing on the cross-chain message according to the asset processor contract, and obtain the transaction execution result corresponding to the cross-chain message. The transaction execution result can be added to the second cross-chain transaction block. If the second cross-chain transaction block reaches consensus in the independent consensus network corresponding to the second blockchain, the second cross-chain transaction block can be stored in the second blockchain. The consensus algorithm adopted by the second cross-chain transaction block in the consensus phase can be any consensus mechanism currently used in blockchain technology, and the embodiment of this application does not limit the type of consensus algorithm adopted.

[0111] It is understandable that the cross-chain transaction data stored in the first blockchain and the cross-chain message stored in the second blockchain involved in the embodiments of the present application are essentially the same cross-chain transaction, except that this cross-chain transaction requires the first blockchain and the second blockchain to be executed in coordination, that is, the first blockchain and the second blockchain collaborate to execute the cross-chain transaction. For example, the cross-chain transaction is a digital asset cross-chain transfer request, which can be used to instruct the transfer of a specific amount of digital assets from the first chain address of user S (the account address of user S on the first blockchain) to the second chain address (the account address of user S on the second blockchain). Then user S can use its own resource client to send cross-chain transaction data to the first blockchain through the cross-chain server. At this time, the cross-chain transaction data can refer to the transaction data encapsulated by the digital asset cross-chain transfer request triggered by user S in the cross-chain server. The cross-chain transaction can be encapsulated into a first cross-chain transaction block. When the first cross-chain transaction block is successfully stored on the first blockchain, it indicates that a specific amount of digital assets has been deducted from the address on the first blockchain. At this point, the first blockchain can trigger a cross-chain message through the cross-chain management contract (cross-chain bridge contract). In other words, the cross-chain transaction data stored on the first blockchain can be used to instruct the deduction of a specific amount of digital assets from the address on the first chain corresponding to user S. The cross-chain message triggered by the first blockchain can be submitted by the forwarding service device to the cross-chain management contract on the second blockchain. The cross-chain message at this point is essentially the aforementioned cross-chain transaction data. The cross-chain message and the transaction execution result corresponding to the cross-chain message can be stored on the second blockchain. The cross-chain message stored on the second blockchain (which can also be considered as the cross-chain transaction data stored on the second blockchain) can be used to instruct the addition of a specific amount of digital assets to the address on the second chain corresponding to user S.

[0112] In an embodiment of the present application, after receiving a cross-chain message submitted by the forwarding service device, the consensus node of the second blockchain obtains the block Merkle information corresponding to the first blockchain from the second blockchain corresponding to the blockchain identifier in the cross-chain message, and obtains the Merkle proof set corresponding to the cross-chain message from the block Merkle tree represented by the block Merkle information. In other words, in the interactive communication between the first blockchain and the second blockchain, the second blockchain only needs to store the partial data indicated by the Merkle proof set, without having to store the full block header data from the first blockchain, which can reduce data storage usage and save storage space. Furthermore, relying on the verification capability of the block Merkle information, that is, verifying the validity of the cross-chain message based on the block Merkle information and the Merkle proof set, it can quickly verify the cross-chain message at the block height, thereby improving the verification efficiency of the cross-chain message.

[0113] Please refer to Figure 6, which is a timing diagram of a blockchain-based data processing method provided in an embodiment of the present application. It is understood that the blockchain-based data processing method can be interactively executed by the first blockchain (which can be understood as the consensus node of the first blockchain), the second blockchain (which can be understood as the consensus node of the second blockchain), and the forwarding service device; as shown in Figure 6, the blockchain-based data processing method can include at least the following steps S201 to S209:

[0114] Step S201: Receive cross-chain transaction data sent by the cross-chain server, encapsulate the cross-chain transaction data into a first cross-chain transaction block, and if consensus is reached on the first cross-chain transaction block, store the first cross-chain transaction block in the first blockchain.

[0115] Among them, in the multi-chain structure of the blockchain network, if user S wants to process cross-chain transactions in the multi-chain structure of the blockchain network, then the user S can use its own resource client to initiate cross-chain transaction data through the cross-chain server, and the cross-chain server submits the cross-chain transaction data to the first blockchain. The consensus node of the first blockchain can obtain the cross-chain transaction data sent by the cross-chain server. Furthermore, after obtaining the cross-chain transaction data, the digital signature in the cross-chain transaction data can be verified. For example, the validity of the digital signature in the cross-chain transaction data can be verified based on the user public key corresponding to user S to obtain the signature verification result corresponding to the cross-chain transaction data; if the signature verification result indicates that the digital signature verification is passed, the cross-chain transaction data is encapsulated into the first cross-chain transaction block. In the consensus phase of the first cross-chain transaction block, the transaction type corresponding to the cross-chain transaction data can be obtained, and then the asset processor contract matching the transaction type can be called by the cross-chain management contract in the first blockchain to execute the cross-chain transaction data; if the signature verification result indicates that the digital signature verification fails, the cross-chain transaction data can be marked as an invalid transaction, the cross-chain transaction data is discarded, and the cross-chain server is notified to resubmit the cross-chain transaction data.

[0116] The verification process of the digital signature in the cross-chain transaction data may include: decrypting the digital signature in the cross-chain transaction data using the user public key corresponding to user S to obtain first summary information (hash value) corresponding to the cross-chain transaction data; performing a hash operation on the cross-chain transaction data using a hash algorithm to obtain second summary information corresponding to the cross-chain transaction data; if the first summary information is the same as the second summary information, it indicates that the cross-chain transaction data is a valid transaction, that is, the signature verification result corresponding to the cross-chain transaction data indicates that the verification is passed; if the first summary information is different from the second summary information, it indicates that the cross-chain transaction data is an invalid transaction (the cross-chain transaction data may have been maliciously tampered with during transmission), that is, the signature verification result corresponding to the cross-chain transaction data indicates that the verification has failed, and the cross-chain transaction data may be discarded. It should be noted that the hash algorithm used by the consensus node of the first blockchain may refer to the hash algorithm used by the user when signing the cross-chain transaction data.

[0117] It is understood that after receiving cross-chain transaction data, the consensus node of the first blockchain needs to synchronize the cross-chain transaction data within the independent consensus network corresponding to the first blockchain, such as broadcasting the cross-chain transaction data to other consensus nodes in the independent consensus network corresponding to the first blockchain. It is understood that cross-chain transaction data may be lost during the transmission process. To ensure that cross-chain transaction data reaches all consensus nodes in the independent consensus network corresponding to the first blockchain as much as possible, the consensus node that receives the cross-chain transaction data through broadcast can select one or more adjacent consensus nodes based on its own network topology and network traffic strategy to relay the broadcast, providing the basis for packaging the cross-chain transaction data into the first cross-chain transaction block during the consensus process.

[0118] Furthermore, the consensus nodes of the first blockchain can package the transactions in the transaction pool to generate a first cross-chain transaction block (assuming that the first cross-chain transaction block contains cross-chain transaction data). During the consensus process of the first cross-chain transaction block, the consensus nodes can execute all transactions in the first cross-chain transaction block, including the cross-chain transaction data contained in the block. After the first cross-chain transaction block reaches consensus in the independent consensus network, the first cross-chain transaction block can be stored in the first blockchain.

[0119] Step S202: triggering a cross-chain message corresponding to the cross-chain transaction data through the cross-chain management contract in the first blockchain.

[0120] Specifically, when the first cross-chain transaction block is successfully stored in the first blockchain, a cross-chain message corresponding to the cross-chain transaction data can be triggered through the cross-chain management contract in the first blockchain, and the cross-chain message can be submitted to the second blockchain by the forwarding service device.

[0121] Step S203: Obtain a cross-chain message triggered by the first blockchain, and obtain the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain. The cross-chain message carries a blockchain identifier corresponding to the second blockchain.

[0122] Specifically, the forwarding service device can obtain the contract status corresponding to the cross-chain management contract in the first blockchain. If the contract status is a transaction pending forwarding state (the transaction pending forwarding state is used to indicate that a new cross-chain message has been initiated in the cross-chain bridge contract in the first blockchain), then obtain the cross-chain message triggered by the cross-chain management contract in the first blockchain; determine in the first blockchain the first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs (that is, the block in the first blockchain that stores the cross-chain transaction data), and obtain the block height H2 of the first cross-chain transaction block in the first blockchain, that is, the block height of the first cross-chain transaction block in the first blockchain can be recorded as H2.

[0123] It can be understood that in the multi-chain architecture of the blockchain network, the forwarding service device can be used to forward cross-chain messages between different blockchains. The forwarding service device can simultaneously detect the contract status of the cross-chain management contracts in multiple blockchains. If a cross-chain message is detected in the cross-chain management contract of any blockchain, the cross-chain message can be forwarded to the blockchain receiving the cross-chain message.

[0124] Step S204: If, in the second blockchain corresponding to the blockchain identifier, it is detected that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, the cross-chain message is forwarded.

[0125] Specifically, after the forwarding service device obtains the cross-chain message from the cross-chain management contract of the first blockchain, before forwarding the cross-chain message, it can determine the blockchain used to receive the cross-chain message (i.e., the second blockchain) based on the blockchain identifier carried by the cross-chain message, and then obtain the verifiable height H1 corresponding to the first blockchain in the chain verification contract deployed by the second blockchain (specifically, the first blockchain verification contract). That is, the block height corresponding to the block Merkel information (such as MMR root information) stored in the contract verified by the first blockchain can be called the verifiable height H1. If it is detected in the second blockchain corresponding to the blockchain identifier that the verifiable height H1 corresponding to the first blockchain is greater than or equal to the block height H2, the cross-chain message can be forwarded to the second blockchain.

[0126] Optionally, if the verifiable height H1 is less than the block height H2, a height update prompt message corresponding to the first blockchain is generated and sent to a trusted oracle device (for example, a trusted MMR root oracle or a TEE trusted oracle), so that the trusted oracle device submits the block Merkle information corresponding to the maximum block height in the first blockchain to the chain verification contract in the second blockchain (specifically, the first blockchain verification contract) based on the height update prompt message; wherein, the block Merkle information corresponding to the maximum block height is used to overwrite the block Merkle information and verifiable height H1 stored in the chain verification contract deployed by the second blockchain. If the updated verifiable height H1 is still less than the block height H2 where the cross-chain message is located in the first blockchain, the forwarding service device does not need to forward the cross-chain message, that is, the cross-chain message submission fails.

[0127] Step S205: Obtain the blockchain identifier carried by the cross-chain message, obtain the block Merkle information corresponding to the first blockchain in the second blockchain corresponding to the blockchain identifier, and obtain the Merkle proof set corresponding to the cross-chain message in the block Merkle tree represented by the block Merkle information.

[0128] Among them, the consensus node of the second blockchain can obtain the cross-chain message triggered by the cross-chain management contract in the first blockchain through the cross-chain management contract deployed in the second blockchain, and then call the first blockchain verification contract in the second blockchain through the cross-chain management contract in the first blockchain, and verify the validity of the cross-chain message through the block Merkle information (MMR root information) in the first blockchain verification contract. Among them, the specific implementation process of step S205 can be found in the relevant description of steps S101 and S102 of the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0129] Step S206: Perform a hash operation on the Merkle proof set to obtain the first candidate Merkle information corresponding to the first cross-chain transaction block. By comparing the block Merkle information with the first candidate Merkle information, a block verification result corresponding to the first cross-chain transaction block is obtained.

[0130] Specifically, the consensus node of the second blockchain can perform a hash operation on the Merkle proof set (specifically, the MMR proof set) to obtain the first candidate Merkle information corresponding to the first cross-chain transaction block. The first candidate Merkle information in this case can refer to the block Merkle information obtained by re-hashing the Merkle proof set (i.e., the recalculated MMR root information, the first candidate Merkle information herein can be denoted as MMRR'). If the block Merkle information (i.e., the MMR root information stored in the first blockchain verification contract, which can be denoted as MMRR) is consistent with the first candidate Merkle information, i.e., MMRR'=MMRR, then the block verification result corresponding to the first cross-chain transaction block is determined to be a successful verification result, indicating that the data in the first cross-chain transaction block is authentic and has not been tampered with. If the block Merkle information is inconsistent with the first candidate Merkle information, i.e., MMRR'≠MMRR, then the block verification result corresponding to the first cross-chain transaction block is determined to be a failed verification result. Based on the irreversibility of hashing, this indicates that the data in the first cross-chain transaction block has been maliciously tampered with. In an embodiment of the present application, the data stored in the leaf node (first cross-chain transaction block) in the MMR tree (block Merkle tree) can be verified to ensure that the data has not been tampered with and is authentic. This process can be called an MMR certification process.

[0131] Please refer to Figure 7, which is a block data verification diagram based on the Merkle Mountains provided in an embodiment of the present application; the embodiment of the present application takes the leaf node B8 shown in Figure 7 (the leaf node B8 here can be considered as the aforementioned first cross-chain transaction block) as an example to describe the MMR (Merkle Mountain Root) proof process. The MMR tree shown in Figure 7 can include three Merkle subtrees, namely Merkle subtree 30a (a perfect binary subtree), Merkle subtree 30b (a perfect binary subtree) and a Merkle subtree containing only leaf node B12. Leaf nodes B0 to leaf nodes B12 in the MMR tree can be represented as block headers of all blocks contained in the first blockchain.

[0132] Among them, if you want to prove whether the leaf node B8 belongs to the MMR tree, you can obtain the Merkle proof set of the leaf node B8 in the MMR tree. The Merkle proof set can be composed of the hash values ​​of the leaf node B9, leaf node B12, intermediate node Hash(10&11), and intermediate node Hash(((0&1)&(2&3))&((4&5)&(6&7))) in the MMR tree; where Hash() represents taking the hash value. The proof process of the leaf node B8 may include:

[0133] ① Calculate the hash value H'(8) of leaf node B8, where H'(8) = Hash(B8), and obtain the hash value H(9) of leaf node B9 and the hash value H(12) of leaf node B12 in the Merkle Mountain path (the aforementioned block path information), where H(9) = Hash(B9) and H(12) = Hash(B12).

[0134] ② Obtain a right subroot H(10&11) in the Merkle subtree 30b where the leaf node B8 in the MMR tree is located, where H(10&11)=Hash(H(10)&H(11)).

[0135] ③ Perform hash operation on the hash value H'(8) of leaf node B8 and the hash value H(9) of leaf node B9 to obtain H'(8&9)=Hash(H'(8)&H(9)).

[0136] ④ Perform a hash operation on H'(8&9) calculated in step ③ and H(10&11) obtained in step ② to obtain H'(H'(8&9)&H(10&11)), H'(H'(8&9)&H(10&11))=Hash(H'(8&9)&H(10&11)).

[0137] ⑤ Obtain the subtree root of the Merkle subtree 30a in the MMR tree shown in Figure 7. The subtree root at this time can be expressed as H(((0&1)&(2&3))&((4&5)&(6&7))).

[0138] ⑥Hash H(12), H(((0&1)&(2&3))&((4&5)&(6&7))), and H'(H'(8&9)&H(10&11)) to obtain MMRR' (the first candidate Merkle information); where MMRR'=Hash(H(((0&1)&(2&3))&((4&5)&(6&7)))&H'(H'(8&9)&H(10&11))&H(12)).

[0139] ⑦ Compare the calculated MMRR' with the MMRR (block Merkle information) stored in the first blockchain verification contract deployed on the second blockchain. If MMRR' = MMRR, it proves that the leaf node B8 data has not been tampered with, that is, the leaf node B8 verification is successful.

[0140] It should be noted that H'(8), H'(8&9), and H'(H'(8&9)&H(10&11)) shown in Figure 7 are the results obtained by re-hashing the first blockchain verification contract in the second blockchain during the verification of the leaf node B8; H(9), H(12), H(((0&1)&(2&3))&((4&5)&(6&7))) shown in Figure 7 are the node hash values ​​in the MMR tree directly obtained, and no hash operation is required. It can be seen that the first blockchain verification contract in the second blockchain only needs to store H(9), H(12), H(10&11), and H(((0&1)&(2&3))&((4&5)&(6&7))) to realize the verification process of the data stored in the leaf node B8, which can save the storage space of the first blockchain verification contract in the second blockchain and reduce the data storage occupancy.

[0141] Step S207: Obtain transaction Merkle information from the block header of the first cross-chain transaction block, and obtain transaction path information of the cross-chain transaction data in the transaction Merkle tree corresponding to the transaction Merkle information.

[0142] Step S208: Verify the validity of the cross-chain transaction data based on the transaction path information and the transaction Merkle information to obtain a transaction verification result corresponding to the cross-chain transaction data.

[0143] Specifically, please refer to Figure 8, which is a schematic diagram of a cross-chain message verification process provided by an embodiment of the present application. As shown in Figure 8, the cross-chain message verification process may include data authenticity verification in the first cross-chain transaction block (which may be referred to as block verification) and verification of the storage location of the cross-chain transaction data indicated by the cross-chain message (which may be referred to as transaction verification). The data authenticity verification in the first cross-chain transaction block can be understood as verifying whether the data stored in the first cross-chain transaction block is authentic and has not been tampered with (which can be implemented by the aforementioned steps S205 and S206). Specifically, a Merkle proof can be performed in the form of log2(#blocks.), where blocks refers to blocks in the first blockchain. The storage location verification of the cross-chain transaction data can be understood as verifying whether the cross-chain transaction data is stored in the first blockchain. Specifically, a Merkle proof can be performed in the form of log2(#trans.), where trans refers to the transaction data stored in the first cross-chain transaction block. This embodiment of the present application describes the cross-chain transaction data verification process through steps S207 and S208.

[0144] In some embodiments, step S208 includes: performing a hash operation on the transaction path information to obtain second candidate Merkel information corresponding to the cross-chain transaction data; and obtaining a transaction verification result corresponding to the cross-chain transaction data by comparing the transaction Merkel information with the second candidate Merkel information.

[0145] The transaction Merkle information (e.g., the Merkle root in the block header of block 4 in the embodiment corresponding to FIG5 ) can be obtained from the block header of the first cross-chain transaction block through the first blockchain verification contract in the second blockchain. The transaction path information of the cross-chain transaction data in the transaction Merkle tree corresponding to the transaction Merkle information (e.g., the Merkle tree corresponding to the Merkle root in block 4 shown in FIG5 ) can be obtained, such as the Merkle path information of the cross-chain transaction data in the Merkle tree. By performing a hash operation on the transaction path information, the second candidate Merkle information corresponding to the cross-chain transaction data is obtained (which can be the Merkle root obtained by re-hashing). The second candidate Merkle information can be obtained by performing multiple hash operations on the node information (node ​​hash values) of different levels contained in the transaction path information. For example, the node information of the same level can be hashed, and the node information of the previous level can be hashed in sequence (e.g., the process from π1 to π2), and the second candidate Merkle information is finally calculated.

[0146] If the transaction Merkle information is consistent with the second candidate Merkle information, that is, the Merkle root in the block header of the first cross-chain transaction block is the same as the Merkle root obtained by rehashing the second blockchain, then the transaction verification result corresponding to the cross-chain transaction data is determined to be a successful verification result, indicating that the cross-chain transaction data is stored in the first cross-chain transaction block of the first blockchain; if the transaction Merkle information is inconsistent with the second candidate Merkle information, then the transaction verification result corresponding to the cross-chain transaction data is determined to be a failed verification result, indicating that the cross-chain transaction data is not stored in the first blockchain.

[0147] It is understood that if both the block verification result and the transaction verification result are successful, it indicates that the cross-chain message verification is successful (transaction verification is successful), that is, the cross-chain transaction data indicated by the cross-chain message is stored in the first blockchain and the cross-chain transaction data is complete and has not been tampered with. If either the block verification result or the transaction verification result is a failed verification result, or both are failed verification results, it indicates that the cross-chain message verification has failed, that is, the cross-chain transaction data indicated by the cross-chain message is not stored in the first blockchain or the cross-chain transaction data has been maliciously tampered with.

[0148] Step S209: If both the block verification result and the transaction verification result are successful verification results, then determine that the cross-chain verification result corresponding to the cross-chain message indicates successful verification, obtain the transaction execution result corresponding to the cross-chain message, and store the transaction execution result in the second blockchain.

[0149] The specific implementation process of step S209 can refer to step S104 in the embodiment corresponding to FIG3 , and will not be described again here.

[0150] Please refer to Figure 9, which is a schematic diagram of the overall structure of a cross-chain technology between different blockchains provided in an embodiment of the present application. As shown in Figure 9, the overall structure of the cross-chain technology proposed in an embodiment of the present application may include, but is not limited to: a cross-chain server, a cross-chain message forwarding service (forwarding service device), a trusted Merkle Mountain root oracle (trusted oracle device), and multiple blockchains for cross-chain communication (blockchain A and blockchain B as shown in Figure 9).

[0151] Cross-chain service: This can include a cross-chain service frontend and a cross-chain service backend. The cross-chain service frontend can take the form of, but is not limited to, a webpage, an application, or a subprogram embedded within an application (e.g., a mini-program). The cross-chain service frontend can be responsible for interacting with users. Users can use their own resource clients to initiate cross-chain requests through the cross-chain service frontend, which can encapsulate these cross-chain requests as cross-chain transaction data. These cross-chain requests may include, but are not limited to, asset custody authorization and cross-chain transfer requests. Upon completion of a cross-chain task, the cross-chain service frontend can display the task completion status and related data. Specifically, a request can be initiated to the blockchain to retrieve the task completion status and related data. The cross-chain service backend can be a backend service, primarily responsible for providing data and blockchain transaction support for the cross-chain service frontend. It is understood that the cross-chain service can register its identity in multiple blockchains to obtain authorization from them, i.e., the right to submit transaction data to them.

[0152] Cross-chain message forwarding services: These services may include, but are not limited to, multi-chain interface detection, cross-chain message forwarding, and cross-chain historical tasks and status management. The multi-chain interface detection service is responsible for detecting cross-chain messages sent by the cross-chain bridge contract (cross-chain management contract) on each blockchain. After detecting a cross-chain message through the multi-chain interface detection service, the cross-chain message forwarding service can inspect the cross-chain message and forward it to the cross-chain bridge contract on the blockchain used to execute the cross-chain message (for ease of understanding, the blockchain that sends the cross-chain message can be referred to as the source chain, and the blockchain that executes the cross-chain message can be referred to as the target chain. For example, the first blockchain mentioned above can be referred to as the source chain, and the second blockchain can be referred to as the target chain). The cross-chain historical tasks and status management service can be used to manage the cross-chain tasks forwarded by the cross-chain message forwarding service and their status. It should be noted that cross-chain messages will be verified using MMR technology in the chain verification contract on the blockchain. Therefore, the cross-chain message forwarding service does not need to guarantee the correctness of the cross-chain messages it forwards; it only needs to detect the cross-chain message on the source chain and submit it unchanged to the target chain. In other words, the cross-chain message forwarding service does not need to perform identity authentication in multiple blockchains, that is, there is no need to set trust in the cross-chain message forwarding service in the blockchain's on-chain contract. It can be understood that before forwarding the cross-chain message it detects, the cross-chain message forwarding service can obtain the block height H2 of the block to which the cross-chain message belongs in the original chain, and then detect whether there is an MMR root information greater than or equal to the block height H2 on the target chain. The block height of the MMR root information stored on the target chain can be called the verifiable height, recorded as H1; if the verifiable height H1 is less than the block height H2, the trusted MMR root oracle service is triggered to submit the MMR root information of the latest height (maximum block height) to the target chain. If the verifiable height H1 on the target chain becomes greater than or equal to the block height H2 after the submission is completed, the cross-chain message forwarding service will forward the cross-chain message to the target chain. If the verifiable height H1 on the target chain is still less than the block height H2 after the submission is completed, the cross-chain message submission fails.

[0153] Trusted MMR root oracle: The trusted MMR root oracle can run in a trusted execution environment (TEE) and can also be called a TEE trusted oracle. The trusted MMR root oracle can include but is not limited to services such as multi-chain detection and verification, and MMR root submission. The multi-chain detection and verification service can be used to detect the ledgers of each blockchain and verify the detected ledgers. The MMR root submission service can submit the MMR root information corresponding to the maximum block height on the original chain to the cross-chain bridge contract in the target chain after receiving the trigger prompt of the cross-chain message forwarding service. Please refer to Figure 10, which is a structural diagram of a trusted oracle device provided in an embodiment of the present application. As shown in Figure 10, the multi-chain detection and verification service in the trusted MMR root oracle can include multiple detection and verification services. One blockchain corresponds to one detection and verification service running in the TEE. Each detection and verification service can detect the ledger on a blockchain and verify the detected ledger by synchronizing each block to the local verification method. At the same time, the MMR root information of each block height can be stored. For example, a trusted MMR root oracle can include the Blockchain A ledger detection and verification service (used to detect and verify the ledger of Blockchain A), the Blockchain B ledger detection and verification service (used to detect and verify the ledger of Blockchain B), and the Blockchain C ledger detection and verification service (used to detect and verify the ledger of Blockchain C). The MMR root submission service can be connected to each detection and verification service. For example, the MMR root submission service can be connected to the Blockchain A ledger detection and verification service, the Blockchain B ledger detection and verification service, and the Blockchain C ledger detection and verification service at the same time. When the cross-chain message forwarding service triggers the MMR root submission service to submit the MMR root information of Blockchain A to Blockchain B, the MMR root submission service can obtain the MMR root information corresponding to the latest height from the Blockchain A ledger detection and verification service and submit it to the Blockchain A verification contract on Blockchain B.

[0154] Cross-chain bridge contract: The cross-chain bridge contract is the submission entry for cross-chain transactions (cross-chain messages). The cross-chain bridge contract can include but is not limited to the following functions:

[0155] ① Manage cross-chain relays: Manage the addition, deletion, modification, and query of relay objects to which cross-chain messages can be forwarded. The relay objects managed here (for example, forwarding service devices) only forward cross-chain messages and do not include confirmation of cross-chain messages.

[0156] ② Manage cross-chain transactions: The cross-chain bridge contract in the source chain can record the submission information of each cross-chain transaction (cross-chain message), and the cross-chain bridge contract in the target chain can record the execution status of each cross-chain transaction after submission and its corresponding status changes (for example, status changes such as inactivated-activated-approved-executed-canceled, etc.); for example, when the cross-chain transaction is a cross-chain transfer message, the cross-chain bridge contract in the source chain can record information such as the user submitting the cross-chain transfer, the amount of data transferred, the type of digital asset, the blockchain identification (ID) of the target chain, the user address used to receive the digital asset in the target chain, and the transaction sequence number. It should be noted that if the cross-chain bridge contract in the target chain receives a cross-chain message from blockchain A submitted by the forwarding service device, it can call the blockchain A verification contract through the cross-chain management contract and, based on the MMR verification technology in the blockchain A verification contract, determine whether the cross-chain message from blockchain A is stored in blockchain A and that the cross-chain message is complete and untampered.

[0157] ③After the cross-chain message is completed, the cross-chain bridge contract can be responsible for calling the message processors corresponding to various cross-chain transaction types. For example, a cross-chain transaction of the Token type is submitted to the asset processor contract, which can then execute the cross-chain transaction. Specifically, the asset processor contract where the digital asset corresponding to the cross-chain transaction is located can be operated to complete the cross-chain execution.

[0158] Chain Verification Contract: As shown in Figure 9, there are blockchain B verification contracts in blockchain A, blockchain A verification contracts in blockchain B, and so on. A blockchain can include multiple chain verification contracts, and one chain verification contract corresponds to one blockchain. Chain verification contracts can include but are not limited to the following functions:

[0159] ① Used to receive the latest MMR root information on each blockchain submitted by the MMR root submission service in the trusted MMR root oracle, and update the corresponding verifiable height.

[0160] ② It is used to receive and verify cross-chain messages transmitted by the cross-chain bridge contract. For each cross-chain message, the chain verification contract can obtain the transaction information corresponding to the cross-chain message (cross-chain transaction data), the Merkle path information of the cross-chain transaction data (transaction path information), the block header information of the block where the cross-chain transaction data is located (the first cross-chain transaction block), and the Merkle path information of the MMR tree corresponding to the block header of the block where the cross-chain transaction data is located (block path information). Based on the above information and the MMR root information stored in the chain verification contract, the correctness verification result of the cross-chain message (cross-chain verification result) can be obtained by calculating the Merkle tree. The verification principle of MMR technology can be found in the description of steps S205 to S208 of the embodiment corresponding to Figure 6 above, and will not be repeated here. Verifying cross-chain messages through MMR technology can improve the verification efficiency of cross-chain messages.

[0161] Please refer to Figure 11, which is a system architecture diagram of a tax blockchain system provided in an embodiment of the present application. As shown in Figure 11, the business network, routing proxy network, and core consensus network in the embodiment of the present application constitute the entire complete blockchain business system. The number of blockchains maintained by the core consensus network can be multiple, specifically core chain 1 and core chain 2 as shown in Figure 11, where core chain 1 and core chain 2 can be blockchains containing full data. It should be noted that the core consensus network shown in Figure 11 can include multiple independent consensus networks, specifically one independent consensus network can maintain one core chain, and the consensus nodes in the independent consensus network can be responsible for consensus and recording business transaction data in the corresponding core chain. The business network shown in Figure 11 can include multiple independent business networks, specifically one independent business network corresponding to one core chain, and the business nodes in the independent business network are responsible for uploading transaction data for tax business to the chain and clearing data related to tax business (for example, transaction clearing). Transaction clearing refers to the consensus node synchronizing the transaction data that the business node has permission to read to the business node after receiving a request for transaction synchronization from the business node. In summary, a core chain can correspond to an independent consensus network and an independent business network, and different core chains can correspond to different independent consensus networks and independent business networks.

[0162] It is understandable that when blockchain is used in some scenarios of management agencies (for example, tax systems) or commercial organizations, in order to improve the confidentiality and security of data, when personal privacy and other related data are involved in the blockchain system, the layered blockchain structure of "business network-core consensus network" in the embodiment of this application can be adopted; in other words, a layered blockchain structure of "business network-core consensus network" can be formed between the independent consensus network and the independent business network corresponding to each core chain. Among them, this system architecture diagram can be applied to multiple transaction businesses associated with tax business, such as invoice business, import and export business, legal person business, credit business and tax refund business, etc. One transaction business can correspond to one core chain, which can effectively distinguish different transaction businesses to maintain the specificity of the relevant data of a single transaction business for on-chain storage.

[0163] Since the entire tax business will involve regulatory agencies, invoicing parties, reimbursement parties, and tax payers, etc. Therefore, the business nodes in the business network shown in Figure 11 can be business terminal devices used by business users, or can have a network connection relationship with terminal devices used by business users. The business users here can include tax bureau institutional users, corporate users, and consumer users, etc. Among them, tax bureau institutional users can refer to regulatory agencies in the regulatory private network (for example, computer equipment corresponding to provincial, municipal, and district tax bureaus), corporate users can be invoicing service providers, reimbursement service providers, or retail enterprises in the public cloud (for example, KA enterprises, i.e., large retail customers and key retail customer enterprises), etc., and consumer users can be payment service providers, circulation service providers, or retail enterprises in the private cloud, etc.

[0164] The proxy nodes in the routing proxy network can be used to isolate the business network from the core consensus network. It should be understood that the independent consensus network and independent business network corresponding to each core chain can be isolated through the proxy nodes in the routing proxy network. The proxy nodes in the routing proxy network can provide peer-to-peer services (i.e., P2P services), routing services, certificate caching, and authentication services. Routing services are a fundamental function of blockchain nodes and can be used for communication between blockchain nodes to isolate the business network from the core consensus network. The certificate cache is used to cache the digital certificates of each blockchain node. In the public key certificate infrastructure (PKI), a digital certificate is an identity verification tool for a public key holder. The PKI in this context can include public and private key cryptography, X509 certificates, and CA certificate signing centers. Authentication services can be used to authenticate the identities of business nodes in the business network.

[0165] It is understood that in the embodiment of the present application, the proxy node can be used to forward the business transaction data (for example, specifically cross-chain transaction data, in which case the business node sending the business transaction data can be a cross-chain service end) sent by the business node to the consensus node of core chain 1 (in this case, core chain 1 can be the aforementioned first blockchain) so that the consensus node can upload the cross-chain transaction data to the chain; when the cross-chain transaction data is stored on core chain 1, the cross-chain bridge contract deployed in core chain 1 can trigger a cross-chain message to the consensus node of core chain 2 (in this case, core chain 2 can be the aforementioned second blockchain). After the forwarding service device detects the cross-chain message triggered by the cross-chain bridge contract in core chain 1, it can submit the cross-chain message to the cross-chain bridge contract deployed in core chain 2. The consensus node of core chain 2 obtains the cross-chain message sent by the consensus node of core chain 1 through the cross-chain bridge contract, and then can call the core chain 1 verification contract deployed in core chain 2. According to the MMR root of the latest block height stored in the core chain 1 verification contract, it determines whether the cross-chain transaction data indicated by the cross-chain message exists on core chain 1 and whether the cross-chain message is complete and tamper-free. After completing the verification process of the cross-chain message, the consensus node of core chain 2 can call the asset processor contract corresponding to the cross-chain message. The asset processor contract will execute the cross-chain message and store the cross-chain message and the transaction execution result of the cross-chain message in core chain 2. It should be understood that the proxy node can also be used to forward the transaction execution result (i.e., the execution result of the cross-chain message) sent by the consensus node of core chain 2 to the business node (such as the cross-chain server). This means that the proxy node can be used to provide communication services to the business nodes in the business network and the consensus nodes in the core consensus network; the forwarding service device can be used to provide cross-chain message forwarding services for different core chains.

[0166] As shown in Figure 11, the consensus nodes (i.e., accounting nodes) in the core consensus network can be trusted nodes in the tax-specific network and can determine their consensus responsibilities by calling permission contracts (e.g., smart contracts). The permission contracts here also store the flow logic for the entire life cycle of electronic bills, such as the bill status of the electronic bill, the circulation process, data access rights, electronic bill application conditions, electronic bill issuance conditions, and cross-chain transactions. For example, after receiving business transaction data forwarded by the proxy node, the consensus node in the core consensus network can store the business transaction data in the cache shown in Figure 11 (i.e., the transaction pool corresponding to the consensus node in the core consensus network). The cached business transaction data can then be encapsulated into a new block. After the new block reaches consensus in the independent consensus network corresponding to core chain 1, the block can be stored in core chain 1, indicating that the aforementioned business transaction data is successfully stored in core chain 1. It is understandable that in order to achieve interaction and communication between different core chains, a contract set can be deployed in multiple core chains in the core consensus network. The contract set can refer to a set of smart contracts associated with multiple cross-chain transactions deployed on each core chain, which may include but is not limited to cross-chain bridge contracts, asset processor contracts, various blockchain verification contracts (for example, core chain 1 verification contract, core chain 2 verification contract), cross-chain application contracts, cross-chain asset contracts, etc. Of course, each core chain can also deploy smart contracts associated with other transactions (non-cross-chain transactions), such as on-chain asset transfer contracts, data storage contracts, etc. The embodiment of this application does not limit the type of smart contracts deployed in the core chain.

[0167] It is understandable that the smart contracts involved in the embodiments of the present application can all be a piece of business code. The smart contract can run at the bottom layer of the blockchain. After it is successfully deployed to the blockchain, when the transaction data that needs to call the smart contract is subsequently obtained, the consensus nodes participating in the consensus in the blockchain network can execute the business code in the smart contract, and each consensus node can obtain the same result. In other words, the smart contract can be a computer-readable instruction code. Developers can use smart contract high-level languages ​​to write it. The compiler can compile the contract written in the high-level language into bytecode in the virtual machine of the blockchain node, and the virtual machine can be used to interpret and execute the bytecode in the smart contract. Smart contract high-level languages ​​can include but are not limited to Solidity (a smart contract programming language), Serpent (a smart contract programming language), LLL (a smart contract programming language). For example, developers can use Solidity to write smart contracts and use a compiler to compile the smart contract written in Solidity into virtual machine bytecode, and then deploy the compiled virtual machine bytecode in the blockchain. It should be noted that the user who submits the smart contract to the blockchain network can be any user who has completed identity registration in the cross-chain server (or other decentralized applications).

[0168] In an embodiment of the present application, after receiving a cross-chain message submitted by the forwarding service device, the consensus node of the second blockchain obtains the block Merkle information corresponding to the first blockchain from the second blockchain corresponding to the blockchain identifier in the cross-chain message, and obtains the Merkle proof set corresponding to the cross-chain message from the block Merkle tree represented by the block Merkle information. In other words, in the interactive communication between the first blockchain and the second blockchain, the second blockchain only needs to store the partial data indicated by the Merkle proof set, without having to store the full block header data from the first blockchain, which can reduce data storage usage and save storage space. Furthermore, relying on the verification capability of the block Merkle information, that is, verifying the validity of the cross-chain message based on the block Merkle information and the Merkle proof set, it can quickly verify the cross-chain message at the block height, thereby improving the verification efficiency of the cross-chain message.

[0169] It is understandable that in the specific implementation of this application, cross-chain messages may involve users' account addresses, assets and other personal information. When the above embodiments of this application are applied to specific products or technologies, the user's permission or consent must be obtained, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0170] Please refer to Figure 12, which is a structural diagram of a blockchain-based data processing device provided in an embodiment of the present application. It can be understood that the blockchain-based data processing device 1 can be applied to any consensus node on the aforementioned second blockchain, such as any consensus node in the independent consensus network corresponding to the second blockchain included in the core consensus network shown in Figure 1. As shown in Figure 12, the blockchain-based data processing device 1 may include: a cross-chain message acquisition unit 11, a proof set acquisition unit 12, a cross-chain message verification unit 13, and a cross-chain message execution unit 14;

[0171] A cross-chain message acquisition unit 11 is used to acquire the cross-chain message submitted by the forwarding service device and the blockchain identifier carried by the cross-chain message, where the cross-chain message is associated with the cross-chain transaction data stored in the first blockchain;

[0172] The proof set acquisition unit 12 is configured to obtain, in the second blockchain corresponding to the blockchain identifier, the block Merkle information corresponding to the first blockchain, and obtain, in the block Merkle tree represented by the block Merkle information, the Merkle proof set corresponding to the cross-chain message, wherein the Merkle proof set includes node information of some nodes in the block Merkle tree, and the verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain;

[0173] The cross-chain message verification unit 13 is used to verify the validity of the cross-chain message based on the Merkle proof set and the block Merkle information, and obtain the cross-chain verification result corresponding to the cross-chain message;

[0174] The cross-chain message execution unit 14 is configured to obtain a transaction execution result corresponding to the cross-chain message if the cross-chain verification result indicates that the verification is successful, and store the transaction execution result in the second blockchain.

[0175] In one or more embodiments, the proof set acquisition unit 12 is also used to obtain the block Merkle information corresponding to the first blockchain in the chain verification contract deployed by the second blockchain corresponding to the blockchain identifier; determine the first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs in the first blockchain, and obtain the block path information of the first cross-chain transaction block in the block Merkle tree represented by the block Merkle information; obtain the subtree root information corresponding to multiple Merkle subtrees contained in the block Merkle tree, and combine the subtree root information and the node information contained in the block path information into a Merkle proof set corresponding to the cross-chain message.

[0176] In one or more embodiments, the proof set acquisition unit 12 is further used to obtain a block hash value corresponding to the first cross-chain transaction block, and determine the Merkle subtree to which the block hash value belongs in the block Merkle tree represented by the block Merkle information; using the block hash value as the starting node information, traversing the hierarchical node information in the Merkle subtree to which the block hash value belongs until traversing to the subtree root information in the Merkle subtree to which the block hash value belongs, and determining the block path information corresponding to the first cross-chain transaction block based on the traversed hierarchical node information.

[0177] In one or more embodiments, the cross-chain message verification unit 13 is further used to perform a hash operation on the Merkel proof set to obtain a first candidate Merkel information corresponding to the first cross-chain transaction block, and obtain a block verification result corresponding to the first cross-chain transaction block by comparing the block Merkel information and the first candidate Merkel information; obtain the transaction Merkel information in the block header of the first cross-chain transaction block, and obtain the transaction path information of the cross-chain transaction data in the transaction Merkel tree corresponding to the transaction Merkel information; the transaction Merkel tree is determined by the transaction data contained in the first cross-chain transaction block; based on the transaction path information and the transaction Merkel information, the validity of the cross-chain transaction data is verified to obtain a transaction verification result corresponding to the cross-chain transaction data; if the block verification result and the transaction verification result are both successful verification results, then it is determined that the cross-chain verification result corresponding to the cross-chain message indicates that the verification is successful.

[0178] In one or more embodiments, the cross-chain message verification unit 13 is further configured to determine that the block verification result corresponding to the first cross-chain transaction block is a successful verification result if the block Merkle information is consistent with the first candidate Merkle information.

[0179] In one or more embodiments, the cross-chain message verification unit 13 is further configured to determine that the block verification result corresponding to the first cross-chain transaction block is a verification failure result if the block Merkle information is inconsistent with the first candidate Merkle information.

[0180] In one or more embodiments, the cross-chain message verification unit 13 is also used to perform a hash operation on the transaction path information to obtain second candidate Merkel information corresponding to the cross-chain transaction data; by comparing the transaction Merkel information with the second candidate Merkel information, a transaction verification result corresponding to the cross-chain transaction data is obtained.

[0181] In one or more embodiments, if the transaction Merkel information is consistent with the second candidate Merkel information, the transaction verification result corresponding to the cross-chain transaction data is determined to be a successful verification result; if the transaction Merkel information is inconsistent with the second candidate Merkel information, the transaction verification result corresponding to the cross-chain transaction data is determined to be a failed verification result.

[0182] In one or more embodiments, the cross-chain message execution unit 14 is further configured to encapsulate the cross-chain message into a second cross-chain transaction block if the cross-chain verification result indicates successful verification, and obtain the transaction type corresponding to the cross-chain message in the consensus phase of the second cross-chain transaction block; call the asset processor contract that matches the transaction type through the cross-chain management contract in the second blockchain, perform transaction execution processing on the cross-chain message according to the asset processor contract, and obtain the transaction execution result corresponding to the cross-chain message; add the transaction execution result to the second cross-chain transaction block, and if the second cross-chain transaction block reaches a consensus, store the second cross-chain transaction block in the second blockchain.

[0183] In one or more embodiments, the blockchain-based data processing device 1 also includes: a cross-chain message verification failure unit 15, which is used to generate error prompt information corresponding to the cross-chain message if the cross-chain verification result indicates verification failure, and send the error prompt information to the forwarding service device through the cross-chain management contract in the second blockchain, so that the forwarding service device forwards the error prompt information to the cross-chain management contract in the first blockchain; the error prompt information is used to instruct the first blockchain to re-trigger the cross-chain message.

[0184] According to one embodiment of the present application, the steps involved in the blockchain-based data processing method shown above can be performed by various units in the blockchain-based data processing device 1 shown in Figure 12. For example, step S101 shown in Figure 3 can be performed by the cross-chain message acquisition unit 11 shown in Figure 12, step S102 shown in Figure 3 can be performed by the proof set acquisition unit 12 shown in Figure 12, step S103 shown in Figure 3 can be performed by the cross-chain message verification unit 13 shown in Figure 12, step S104 shown in Figure 3 can be performed by the cross-chain message execution unit 14 shown in Figure 12, etc.

[0185] According to one embodiment of the present application, the various units in the blockchain-based data processing device 1 shown in Figure 12 can be individually or all combined into one or several units to constitute, or one (or some) of the units can be further divided into at least two functionally smaller sub-units to achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In actual applications, the functions of one unit can also be implemented by at least two units, or the functions of at least two units can be implemented by one unit. In other embodiments of the present application, the blockchain-based data processing device 1 can also include other units. In actual applications, these functions can also be implemented with the assistance of other units and can be implemented by the collaboration of at least two units.

[0186] In an embodiment of the present application, after receiving the cross-chain message submitted by the forwarding service device, the consensus node of the second blockchain obtains the block Merkle information corresponding to the first blockchain from the second blockchain corresponding to the blockchain identifier in the cross-chain message, and obtains the Merkle proof set corresponding to the cross-chain message from the block Merkle tree represented by the block Merkle information. In other words, in the interactive communication between the first blockchain and the second blockchain, only the partial data indicated by the Merkle proof set needs to be stored on the second blockchain, without the need to store the full block header data in the first blockchain, which can reduce the amount of data storage occupied and save storage space. Furthermore, the verification capability of the block Merkle information can be relied upon, that is, the validity of the cross-chain message can be verified based on the block Merkle information and the Merkle proof set, which can quickly verify the cross-chain message at the block height and improve the verification efficiency of the cross-chain message. In addition, in order to ensure the correctness of the block Merkle information (MMR root information), a TEE trusted oracle is introduced to maintain and submit the block Merkle information, which can improve the accuracy of the block Merkle information stored in the second blockchain.

[0187] Please refer to Figure 13, which is a second structural diagram of a blockchain-based data processing device provided in an embodiment of the present application. It can be understood that the blockchain-based data processing device 2 can be in a forwarding service device, such as the cross-chain message forwarding service shown in Figure 9; as shown in Figure 13, the blockchain-based data processing device 2 can include: a block height acquisition unit 21, a cross-chain message forwarding unit 22;

[0188] A block height acquisition unit 21 is configured to acquire a cross-chain message triggered by the first blockchain, and to acquire the block height of the block in the first blockchain where the cross-chain transaction data indicated by the cross-chain message is located, wherein the cross-chain message carries a blockchain identifier corresponding to the second blockchain; and

[0189] The cross-chain message forwarding unit 22 is configured to forward the cross-chain message to the consensus node of the second blockchain if it is detected in the second blockchain corresponding to the blockchain identifier that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message based on the Merkle proof set corresponding to the cross-chain message and the block Merkle information of the verifiable height in the first blockchain, and obtains a cross-chain verification result corresponding to the cross-chain message;

[0190] The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message in the second blockchain when the cross-chain verification result indicates that the verification is successful.

[0191] In one or more embodiments, the block height acquisition unit 21 is further used to obtain the contract status corresponding to the cross-chain management contract in the first blockchain. If the contract status is a transaction pending forwarding state, a cross-chain message triggered by the cross-chain management contract in the first blockchain is obtained; the first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs is determined in the first blockchain, and the block height of the first cross-chain transaction block in the first blockchain is obtained.

[0192] In one or more embodiments, the blockchain-based data processing device 2 further includes: a verifiable height acquisition unit 23, a prompt information generation unit 24, and a prompt information sending unit 25;

[0193] A verifiable height acquisition unit 23 is configured to acquire the verifiable height corresponding to the first blockchain in the chain verification contract deployed on the second blockchain;

[0194] The prompt information generating unit 24 is configured to generate a height update prompt information corresponding to the first blockchain if the verifiable height H1 is less than the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain;

[0195] The prompt information sending unit 25 is used to send the height update prompt information to the trusted oracle device, so that the trusted oracle device submits the block Merkle information corresponding to the maximum block height in the first blockchain to the chain verification contract in the second blockchain according to the height update prompt information;

[0196] Among them, the block Merkle information corresponding to the maximum block height is used to overwrite the block Merkle information and verifiable height stored in the chain verification contract deployed by the second blockchain.

[0197] According to one embodiment of the present application, the steps involved in the blockchain-based data processing method described above can be performed by various units in the blockchain-based data processing device 2 shown in Figure 13. For example, step S203 shown in Figure 6 can be performed by the block height acquisition unit 21 shown in Figure 13, and step S204 shown in Figure 6 can be performed by the cross-chain message forwarding unit 22 shown in Figure 13, etc.

[0198] According to one embodiment of the present application, the various units in the blockchain-based data processing device 2 shown in Figure 13 can be individually or all combined into one or several units to constitute, or one (or some) of the units can be further divided into at least two functionally smaller sub-units to achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above-mentioned units are divided based on logical functions. In actual applications, the functions of one unit can also be implemented by at least two units, or the functions of at least two units can be implemented by one unit. In other embodiments of the present application, the blockchain-based data processing device 2 can also include other units. In actual applications, these functions can also be implemented with the assistance of other units and can be implemented by the collaboration of at least two units.

[0199] In an embodiment of the present application, the cross-chain message between the first blockchain and the second blockchain can be forwarded by a forwarding service device. The forwarding service device does not need to verify the correctness of the cross-chain message. It only needs to detect the cross-chain message triggered by the cross-chain management contract (cross-chain bridge contract) in multiple blockchains in real time and forward the cross-chain message directly to the corresponding blockchain (for example, the second blockchain). This can improve the transmission speed of cross-chain messages between different blockchains. In addition, the forwarding service device will only submit the cross-chain message when there is a block Merkle information (MMR root information) corresponding to the block height H2 greater than or equal to the cross-chain message in the second blockchain. Otherwise, it can trigger a trusted oracle device (TEE trusted oracle) to submit the latest MMR root information on the first blockchain to the second blockchain. That is to say, in order to ensure the correctness of the MMR root information, the embodiment of the present application introduces a TEE trusted oracle to maintain and submit the MMR root information, which can improve the accuracy of the MMR root information stored in the second blockchain.

[0200] Please refer to Figure 14, which is a structural diagram of a computer device provided in an embodiment of the present application. As shown in Figure 14, the computer device 1000 can be a terminal device or a server, and will not be limited here. For ease of understanding, this application takes the computer device as a terminal device as an example. The computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage. The memory 1005 may also be at least one storage device located away from the aforementioned processor 1001. As shown in FIG. 14 , the memory 1005 , which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0201] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display and a keyboard. In the computer device 1000 shown in Figure 14, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0202] Obtaining a cross-chain message submitted by the forwarding service device and a blockchain identifier carried in the cross-chain message, where the cross-chain message is associated with cross-chain transaction data stored in the first blockchain;

[0203] In the second blockchain corresponding to the blockchain identifier, obtaining the block Merkle information corresponding to the first blockchain, and in the block Merkle tree represented by the block Merkle information, obtaining the Merkle proof set corresponding to the cross-chain message, where the Merkle proof set includes node information of some nodes in the block Merkle tree, and the verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain;

[0204] Based on the Merkle proof set and block Merkle information, the validity of the cross-chain message is verified to obtain the cross-chain verification result corresponding to the cross-chain message;

[0205] If the cross-chain verification result indicates that the verification is successful, the transaction execution result corresponding to the cross-chain message is obtained and the transaction execution result is stored in the second blockchain.

[0206] Alternatively, the processor 1001 may implement:

[0207] Obtaining a cross-chain message triggered by the first blockchain, and obtaining the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain, where the cross-chain message carries a blockchain identifier corresponding to the second blockchain; and

[0208] If, in the second blockchain corresponding to the blockchain identifier, it is detected that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, the cross-chain message is forwarded to the consensus node of the second blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message based on the Merkle proof set corresponding to the cross-chain message and the Merkle information of the block with the verifiable height in the first blockchain, and obtains a cross-chain verification result corresponding to the cross-chain message;

[0209] The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message in the second blockchain when the cross-chain verification result indicates that the verification is successful.

[0210] It should be understood that the computer device 1000 described in the embodiments of the present application can execute the description of the blockchain-based data processing method in any of the embodiments corresponding to Figures 3 and 6 above, and can also execute the description of the blockchain-based data processing device 1 in the embodiment corresponding to Figure 12 above, or execute the description of the blockchain-based data processing device 2 in the embodiment corresponding to Figure 13 above, and will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0211] In addition, it should be noted that the embodiments of the present application also provide a computer-readable storage medium, and the computer-readable storage medium stores computer-readable instructions executed by the aforementioned blockchain-based data processing device 1 or blockchain-based data processing device 2, and the computer-readable instructions include program instructions. When the processor executes the program instructions, it can execute the description of the blockchain-based data processing method in any of the embodiments corresponding to Figures 3 and 6 above. Therefore, it will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, the program instructions can be deployed on a computing device for execution, or executed on multiple computing devices located at one location, or executed on multiple computing devices distributed at multiple locations and interconnected by a communication network. Multiple computing devices distributed at multiple locations and interconnected by a communication network can constitute a blockchain system.

[0212] In addition, it should be noted that the embodiments of this application also provide a computer program product, which may include computer-readable instructions, which may be stored in a computer-readable storage medium. A processor of a computer device reads the computer-readable instructions from the computer-readable storage medium and executes the computer-readable instructions, causing the computer device to perform the blockchain-based data processing method described in the embodiments corresponding to either of Figures 3 and 6 above. Therefore, these methods will not be described in detail here. Furthermore, the beneficial effects of using the same methods will not be described in detail here. For technical details not disclosed in the computer program product or computer-readable instruction embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0213] It should be noted that for the aforementioned various method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0214] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

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

[0216] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware via computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0217] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A data processing method based on blockchain, performed by a computer device maintaining a consensus node on a second blockchain, comprising: Obtaining a cross-chain message submitted by the forwarding service device, and obtaining a blockchain identifier carried by the cross-chain message, wherein the cross-chain message is associated with the cross-chain transaction data stored in the first blockchain; In the second blockchain corresponding to the blockchain identifier, the block Merkle information corresponding to the first blockchain is obtained, and in the block Merkle tree represented by the block Merkle information, a Merkle proof set corresponding to the cross-chain message is obtained, the Merkle proof set includes node information of some nodes in the block Merkle tree, and the verifiable height of the block Merkle information in the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain; According to the Merkle proof set and the block Merkle information, the validity of the cross-chain message is verified to obtain a cross-chain verification result corresponding to the cross-chain message; and If the cross-chain verification result indicates that the verification is successful, the transaction execution result corresponding to the cross-chain message is obtained, and the transaction execution result is stored in the second blockchain.

2. The method according to claim 1, wherein in the second blockchain corresponding to the blockchain identifier, obtaining the block Merkle information corresponding to the first blockchain, and in the block Merkle tree represented by the block Merkle information, obtaining the Merkle proof set corresponding to the cross-chain message, comprises: In a chain verification contract deployed by a second blockchain corresponding to the blockchain identifier, obtaining block Merkle information corresponding to the first blockchain; Determine, in the first blockchain, a first cross-chain transaction block to which the cross-chain transaction data indicated by the cross-chain message belongs, and obtain block path information of the first cross-chain transaction block in the block Merkle tree represented by the block Merkle information; Obtain subtree root information corresponding to multiple Merkle subtrees contained in the block Merkle tree, and combine the subtree root information and the node information contained in the block path information into a Merkle proof set corresponding to the cross-chain message.

3. According to the method of claim 2, the step of obtaining the block path information of the first cross-chain transaction block in the block Merkle tree represented by the block Merkle information comprises: Obtain a block hash value corresponding to the first cross-chain transaction block, and determine the Merkle subtree to which the block hash value belongs in the block Merkle tree represented by the block Merkle information; Taking the block hash value as the starting node information, traverse the hierarchical node information in the Merkle subtree to which the block hash value belongs until traversing to the subtree root information in the Merkle subtree to which the block hash value belongs, and determine the block path information corresponding to the first cross-chain transaction block according to the traversed hierarchical node information.

4. According to the method of claim 2 or 3, the validity of the cross-chain message is verified according to the Merkel proof set and the block Merkel information to obtain the cross-chain verification result corresponding to the cross-chain message, including: Performing a hash operation on the Merkle proof set to obtain first candidate Merkle information corresponding to the first cross-chain transaction block, and obtaining a block verification result corresponding to the first cross-chain transaction block by comparing the block Merkle information with the first candidate Merkle information; Obtaining transaction Merkle information in a block header of the first cross-chain transaction block, and obtaining transaction path information of the cross-chain transaction data in a transaction Merkle tree corresponding to the transaction Merkle information, where the transaction Merkle tree is determined by the transaction data included in the first cross-chain transaction block; According to the transaction path information and the transaction Merkel information, the validity of the cross-chain transaction data is verified to obtain a transaction verification result corresponding to the cross-chain transaction data; If the block verification result and the transaction verification result are both successful verification results, it is determined that the cross-chain verification result corresponding to the cross-chain message indicates successful verification.

5. According to the method of claim 4, the step of obtaining a block verification result corresponding to the first cross-chain transaction block by comparing the block Merkle information with the first candidate Merkle information comprises: If the block Merkle information is consistent with the first candidate Merkle information, it is determined that the block verification result corresponding to the first cross-chain transaction block is a successful verification result.

6. The method according to claim 5, wherein obtaining a block verification result corresponding to the first cross-chain transaction block by comparing the block Merkle information with the first candidate Merkle information comprises: If the block Merkle information is inconsistent with the first candidate Merkle information, it is determined that the block verification result corresponding to the first cross-chain transaction block is a verification failure result.

7. According to the method according to any one of claims 4 to 6, the validity verification of the cross-chain transaction data is performed according to the transaction path information and the transaction Merkel information to obtain the transaction verification result corresponding to the cross-chain transaction data, including: Performing a hash operation on the transaction path information to obtain second candidate Merkle information corresponding to the cross-chain transaction data; By comparing the transaction Merkel information with the second candidate Merkel information, a transaction verification result corresponding to the cross-chain transaction data is obtained.

8. The method according to any one of claims 1 to 7, wherein if the cross-chain verification result indicates that the verification is successful, obtaining the transaction execution result corresponding to the cross-chain message, and storing the transaction execution result in the second blockchain, comprises: If the cross-chain verification result indicates that the verification is successful, encapsulating the cross-chain message into a second cross-chain transaction block, and obtaining the transaction type corresponding to the cross-chain message in the consensus phase of the second cross-chain transaction block; The cross-chain management contract in the second blockchain calls the asset processor contract that matches the transaction type, performs transaction execution processing on the cross-chain message according to the asset processor contract, and obtains the transaction execution result corresponding to the cross-chain message; The transaction execution result is added to the second cross-chain transaction block. If the second cross-chain transaction block reaches a consensus, the second cross-chain transaction block is stored in the second blockchain.

9. The method according to any one of claims 1 to 8, further comprising: If the cross-chain verification result indicates that the verification failed, an error prompt information corresponding to the cross-chain message is generated, and the error prompt information is sent to the forwarding service device through the cross-chain management contract in the second blockchain, so that the forwarding service device forwards the error prompt information to the cross-chain management contract in the first blockchain, and the error prompt information is used to instruct the first blockchain to re-trigger the cross-chain message.

10. A data processing method based on blockchain, executed by a forwarding service device, comprising: Obtaining a cross-chain message triggered by the first blockchain, and obtaining the block height of the block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain, wherein the cross-chain message carries a blockchain identifier corresponding to the second blockchain; and If, in the second blockchain corresponding to the blockchain identifier, it is detected that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, the cross-chain message is forwarded to the consensus node of the second blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message according to the Merkel proof set corresponding to the cross-chain message and the block Merkel information of the verifiable height in the first blockchain, and obtains the cross-chain verification result corresponding to the cross-chain message; The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message to the second blockchain when the cross-chain verification result indicates that the verification is successful.

11. According to the method of claim 10, the obtaining of a cross-chain message triggered by the first blockchain, and the obtaining of a block height of a block in which the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain, comprises: Obtaining the contract status corresponding to the cross-chain management contract in the first blockchain, and if the contract status is a transaction pending forwarding state, obtaining a cross-chain message triggered by the cross-chain management contract in the first blockchain; Determine in the first blockchain the first cross-chain transaction to which the cross-chain transaction data indicated by the cross-chain message belongs Block, obtaining the block height of the first cross-chain transaction block in the first blockchain.

12. The method according to claim 10 or 11, further comprising: In the chain verification contract deployed by the second blockchain, obtaining a verifiable height corresponding to the first blockchain; If the verifiable height is less than the block height of the block where the cross-chain transaction data is located in the first blockchain, generating height update prompt information corresponding to the first blockchain; Sending the height update prompt information to a trusted oracle device, so that the trusted oracle device submits the block Merkle information corresponding to the maximum block height in the first blockchain to the chain verification contract in the second blockchain according to the height update prompt information; Among them, the block Merkel information corresponding to the maximum block height is used to cover the block Merkel information and verifiable height stored in the chain verification contract deployed by the second blockchain.

13. A data processing device based on blockchain, comprising: A cross-chain message acquisition unit, used to acquire the cross-chain message submitted by the forwarding service device, and acquire the blockchain identifier carried by the cross-chain message; The cross-chain message is associated with the cross-chain transaction data stored in the first blockchain; A proof set acquisition unit, configured to acquire, in a second blockchain corresponding to the blockchain identifier, block Merkle information corresponding to the first blockchain, and acquire, in a block Merkle tree represented by the block Merkle information, a Merkle proof set corresponding to the cross-chain message, wherein the Merkle proof set includes node information of some nodes in the block Merkle tree, and a verifiable height of the block Merkle information in the first blockchain is greater than or equal to a block height of a block where the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain; A cross-chain message verification unit, used to verify the validity of the cross-chain message according to the Merkel proof set and the block Merkel information, and obtain a cross-chain verification result corresponding to the cross-chain message; and The cross-chain message execution unit is used to obtain the transaction execution result corresponding to the cross-chain message if the cross-chain verification result indicates that the verification is successful, and store the transaction execution result in the second blockchain.

14. A data processing device based on blockchain, comprising: A block height acquisition unit, configured to acquire a cross-chain message triggered by the first blockchain, and acquire a block height H2 of a block in which the cross-chain transaction data indicated by the cross-chain message is located in the first blockchain; the cross-chain message carries a blockchain identifier corresponding to the second blockchain; A cross-chain message forwarding unit is configured to forward the cross-chain message to a consensus node of the second blockchain if it is detected in the second blockchain corresponding to the blockchain identifier that the verifiable height corresponding to the first blockchain is greater than or equal to the block height of the block where the cross-chain transaction data is located in the first blockchain, so that the consensus node of the second blockchain verifies the validity of the cross-chain message according to the Merkel proof set corresponding to the cross-chain message and the block Merkel information of the verifiable height in the first blockchain, and obtains a cross-chain verification result corresponding to the cross-chain message; The block Merkle information is stored in the second blockchain, the Merkle proof set is obtained in the block Merkle tree represented by the block Merkle information, and the consensus node of the second blockchain is used to store the transaction execution result corresponding to the cross-chain message to the second blockchain when the cross-chain verification result indicates that the verification is successful.

15. A computer device, comprising a memory and a processor, wherein the memory is used to store computer-readable instructions, and the processor is used to call the computer-readable instructions so that the computer device executes the method according to any one of claims 1 to 12.

16. A computer-readable storage medium, wherein computer-readable instructions are stored in the computer-readable storage medium, wherein the computer-readable instructions are suitable for being loaded and executed by a processor, so that the processor executes the method according to any one of claims 1 to 12.

17. A computer program product, comprising computer readable instructions, wherein when the computer readable instructions are executed by a processor, the method according to any one of claims 1 to 12 is implemented.

Images