Data processing method, device and equipment of blockchain network and readable storage medium

Abstract

The application discloses a data processing method, device and equipment of a blockchain network and a readable storage medium. The method comprises the following steps: monitoring a cross-chain intention event on a first blockchain; the cross-chain intention event comprises cross-chain intention information, the cross-chain intention information is used for indicating that a cross-chain transaction is cooperatively executed by the first blockchain and a second blockchain, the cross-chain transaction comprises a first transaction executed on the first blockchain and a second transaction executed on the second blockchain, and block index information of a first block to which the first transaction belongs; based on the block index information, block header information of the first block is acquired from a light node of the first blockchain, and the cross-chain intention event is verified for legality according to the block header information; when the legality verification result indicates that the cross-chain intention event has legality, the second transaction is sent to the second blockchain. By adopting the application, the node construction cost of an intention relay node can be reduced, and the execution safety and efficiency of a cross-chain intention can be improved.

Description

Technical Field

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

[0002] In cross-chain intent technology, a cross-chain intent refers to a user's desired outcome for a cross-chain interaction (e.g., receiving a resource on chain B), rather than a specific transaction path or smart contract call. Its core characteristic is that the user only expresses "what they want," and the intent relay node and solver determine "how to achieve the user's desired content." Therefore, cross-chain intent abstracts on-chain behavior, allowing users to use intents to perform various on-chain actions.

[0003] In a cross-chain intent system, intent relay nodes are crucial, responsible for forwarding cross-chain intents from one blockchain to another. During this process, the intent relay node needs to obtain the cross-chain intent information from one chain and verify its legitimacy and validity before repackaging it and forwarding it to the other chain. Therefore, the success of a cross-chain intent hinges on the intent relay node's ability to securely obtain and verify the cross-chain intent information.

[0004] In current implementations of intent relay nodes, the node itself typically acquires and processes cross-chain intent information before synchronizing it to the corresponding chain. During this process, the intent relay node needs to verify the cross-chain intent information. This verification is achieved by establishing full nodes on all blockchains within the cross-chain intent system. The verification is then performed using the complete block information already synchronized across all nodes. This requires ensuring that nodes are continuously synchronized to the latest block information, resulting in extremely high node setup costs. Because of these high setup costs, many application scenarios cannot afford to use intent relay nodes, leading to insufficient decentralization and reduced security and efficiency in cross-chain intent execution. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and readable storage medium for a blockchain network, which can improve the security and efficiency of cross-chain intent execution while reducing the node setup cost of intent relay nodes.

[0006] This application provides a data processing method for a blockchain network, wherein the blockchain network includes a first blockchain, a second blockchain, and an intent relay node. The method is executed by the intent relay node and includes:

[0007] Monitor cross-chain intent events on the first blockchain; cross-chain intent events contain cross-chain intent information, which is used to instruct the first blockchain and the second blockchain to jointly execute cross-chain transactions. Cross-chain transactions include a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; cross-chain intent events also contain block index information of the first block to which the first transaction belongs on the first blockchain;

[0008] Based on the block index information of the first block, the block header information of the first block is obtained from the light nodes of the first blockchain, and the legality of the cross-chain intent event is verified according to the block header information of the first block to obtain the legality verification result.

[0009] When the legitimacy verification result indicates that the cross-chain intent event is legitimate, a second transaction is sent to the second blockchain to instruct the second blockchain to execute the second transaction.

[0010] One embodiment of this application provides a data processing device for a blockchain network, including:

[0011] The event monitoring module is used to monitor cross-chain intent events on the first blockchain. The cross-chain intent event contains cross-chain intent information, which is used to indicate that the first blockchain and the second blockchain will jointly execute cross-chain transactions. The cross-chain transaction includes a first transaction executed on the first blockchain and a second transaction executed on the second blockchain. The cross-chain intent event also contains the block index information of the first block to which the first transaction belongs on the first blockchain.

[0012] The verification module is used to obtain the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block, and to perform legality verification on the cross-chain intent event based on the block header information of the first block, and obtain the legality verification result.

[0013] The transaction sending module is used to send a second transaction to the second blockchain when the legality verification result indicates that the cross-chain intent event is legal, so as to instruct the second blockchain to execute the second transaction.

[0014] In one embodiment, the block index information of the first block includes the block hash and block height of the first block;

[0015] The specific implementation method of the verification module obtaining the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block includes:

[0016] The block hash recorded in the block index information of the first block is determined as the first block hash, and the block height recorded in the block index information of the first block is determined as the target block height;

[0017] Retrieve the second block indicated by the target block height in the first blockchain;

[0018] Obtain the block hash of the second block recorded by the light node of the first blockchain, and determine the block hash of the second block recorded by the light node of the first blockchain as the second block hash;

[0019] Based on the hash of the first block and the hash of the second block, the block index information of the first block is validated to obtain the validity validation result;

[0020] When the validity verification result indicates that the block index information of the first block is valid, the block header information of the second block stored in the light node of the first blockchain is determined as the block header information of the first block.

[0021] In one embodiment, the verification module verifies the validity of the block index information of the first block based on the hash of the first block and the hash of the second block, and obtains the validity verification result through a specific implementation method including:

[0022] Compare the hash of the first block with the hash of the second block;

[0023] If the hash of the first block is different from the hash of the second block, the light node in the first blockchain obtains the hash of the second block stored in the full node of the first blockchain, and verifies the validity of the block index information of the first block based on the hash of the first block and the hash of the second block stored in the full node of the first blockchain.

[0024] If the hash of the first block is the same as the hash of the second block, then the validity verification result of the block index information of the first block is determined to be a successful verification result.

[0025] In one embodiment, the specific implementation of the verification module obtaining the block hash of the second block stored by the full node in the first blockchain through the light node in the first blockchain includes:

[0026] Send a hash query instruction to the light node in the first blockchain; the hash query instruction is used to instruct the light node to query the block hash of the second block stored by each of the N full nodes in the first blockchain; N is a positive integer;

[0027] Receive N third block hashes returned by light nodes in the first blockchain; a third block hash is the block hash of the second block returned by one of the N full nodes to the light nodes in the first blockchain.

[0028] In one embodiment, the specific implementation of the verification module verifying the validity of the block index information of the first block based on the hash of the first block and the block hash of the second block stored by the full nodes in the first blockchain includes:

[0029] Based on the hash content of the N third block hashes, the N third block hashes are grouped to obtain at least one hash group; the hash content of each third block hash contained in a hash group is the same;

[0030] Count the number of hashes of the third block hash contained in each hash group;

[0031] The hash group with the largest number of hashes is identified as the target hash group, and the hash of the third block contained in the target hash group is identified as the correct block hash of the second block.

[0032] If the hash of the first block is the same as the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a successful verification result.

[0033] If the hash of the first block is different from the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a verification failure result.

[0034] In one embodiment, after the verification module determines that the validity verification result of the block index information of the first block is a successful verification result, the verification module further performs the following steps:

[0035] Generate data update instructions based on the correct block hash of the second block;

[0036] The data update command is sent to the light node in the first blockchain. The light node in the first blockchain updates its recorded second block hash to the correct second block hash based on the correct block hash of the second block.

[0037] In one embodiment, the verification module performs legality verification on the cross-chain intent event based on the block header information of the first block, and obtains the legality verification result through a specific implementation method including:

[0038] Send an information retrieval instruction for the first transaction to a light node in the first blockchain; the information retrieval instruction is used to instruct the light node in the first blockchain to retrieve the transaction verification information of the first transaction from at least one full node in the first blockchain.

[0039] Receive at least one transaction verification message for the first transaction returned by a light node in the first blockchain, each transaction verification message being returned by one of the at least one full node;

[0040] Based on the block header information of the first block and at least one transaction verification information, the legality of the cross-chain intent event is verified to obtain the legality verification result.

[0041] In one embodiment, the verification module verifies the legitimacy of a cross-chain intent event based on the block header information of the first block and at least one transaction verification message, and obtains the legitimacy verification result through a specific implementation method including:

[0042] Based on the information content of each transaction verification message in at least one transaction verification message, determine the correct transaction verification message from at least one transaction verification message;

[0043] The block header information of the first block is compared and verified with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event.

[0044] In one embodiment, the verification module determines the specific implementation method of the correct transaction verification information from at least one transaction verification information based on the information content of each transaction verification information, including:

[0045] Based on the information content of each transaction verification message, at least one transaction verification message is grouped to obtain at least one information group; the information content of the transaction verification messages contained in each information group is the same;

[0046] Count the number of transaction verification information items contained in each information group;

[0047] The information group with the largest amount of information is identified as the target information group, and the transaction verification information contained in the target information group is identified as the correct transaction verification information.

[0048] In one embodiment, the correct transaction verification information includes a Merkel proof for the first transaction;

[0049] The verification module compares the block header information of the first block with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event. The specific implementation methods include:

[0050] Perform a hash calculation on the first transaction to obtain the transaction hash of the first transaction;

[0051] Merkel calculations are performed on the transaction hash of the first transaction and the Merkel proof of the first transaction to obtain the first Merkel root;

[0052] The second Merkle root is obtained from the block header information of the first block, and the first Merkle root is compared with the second Merkle root.

[0053] If the first Merkle root is the same as the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification pass result;

[0054] If the first Merkle root is different from the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification failure result.

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

[0056] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the methods described in the embodiments of this application.

[0057] One aspect of this application provides a computer-readable storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions perform the methods described in this application.

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

[0059] In this embodiment of the application, a local verification scheme for an intent relay node is provided. After detecting a cross-chain intent event on a blockchain (e.g., a first blockchain), the cross-chain intent information contained in the cross-chain intent event can be obtained. This cross-chain intent information includes the block index information of the first block to which the first transaction executed on the first blockchain belongs. Through this block index information, the intent relay node can obtain the block header information of the first block from the light nodes of the first blockchain. Based on this block header information, the legality verification of the cross-chain intent event can be performed locally on the intent relay node (which can actually be understood as the legality verification of the cross-chain intent information). When the legality verification result indicates that the cross-chain intent event is legal, the second transaction to be executed on the second blockchain can be sent to the second blockchain to instruct the second blockchain to execute the second transaction. In summary, the cross-chain intent node in this application does not require building full nodes on each blockchain; only light nodes are needed. Compared to full nodes, light nodes do not need to synchronize complete block information, only block header information. Therefore, the cost of building light nodes is lower. Due to the reduced node setup cost of intent relay nodes, this method can be considered for many application scenarios, thereby improving the decentralization of intent relay nodes and thus enhancing the execution security of cross-chain intents. Furthermore, after each cross-chain intent event is received, the legality verification of the cross-chain intent event can be quickly completed based on the block header information stored in the light nodes of the blockchain, greatly reducing the resource consumption of verification. In conclusion, this application can improve the execution security and efficiency of cross-chain intents while reducing the node setup cost of intent relay nodes. Attached Figure Description

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

[0061] Figure 1 This is a schematic diagram of the implementation environment provided by an exemplary embodiment of this application;

[0062] Figure 2 This is a schematic diagram illustrating a scenario for verifying cross-chain intent information provided in an embodiment of this application;

[0063] Figure 3 This is a flowchart illustrating a data processing method for a blockchain network provided in an embodiment of this application;

[0064] Figure 4This is a schematic diagram of the logical flow of a verification intent event provided in an embodiment of this application;

[0065] Figure 5 This is a schematic diagram of a process for obtaining the block header information of a first block, provided in an embodiment of this application.

[0066] Figure 6 This is a schematic diagram of a logical flow for validating block index information provided in an embodiment of this application;

[0067] Figure 7 This is a schematic diagram of the structure of a data processing device for a blockchain network provided in an embodiment of this application;

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

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

[0070] This application involves technologies related to blockchain, full nodes, light nodes, and cross-chain intent. For ease of understanding, the relevant terms used in this application will be briefly explained below.

[0071] 1. Blockchain:

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

[0073] 2. All nodes:

[0074] In blockchain, a full node is a common node type. A full node stores the complete data of the blockchain (all block headers and block bodies) and independently verifies all transactions and blocks. It is the backbone of the blockchain, responsible for maintaining its decentralization and security. In data storage, a full node stores the entire historical data of the blockchain (all transactions and states from the genesis block to the latest block). In this application, a full node may be referred to as a full node.

[0075] 3. Light nodes:

[0076] In blockchain, a light node is a node that stores only the minimum necessary data (such as the block header) and relies on all nodes to obtain detailed information. Its design goal is low resource consumption. In data storage, a light node only stores the block header and does not store transaction details or state data.

[0077] It should be noted that each node in the blockchain network (such as a full node) can be a server or a terminal device. A server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart in-vehicle devices, smart voice interaction devices, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0078] 4. Cross-chain intent:

[0079] Cross-chain intent refers to the goal or need expressed by a user in cross-chain interaction (cross-blockchain interaction), without needing to know the specific transaction execution path or underlying technical details. The user only needs to state "what they want", and the intent relay node (IntentRelay) and solver determine "how to achieve it".

[0080] 5: Intent relay node:

[0081] In the process of cross-chain communication, cross-chain intentions need to be forwarded from one blockchain to another through off-chain mechanisms. The intention relay node is responsible for this forwarding function, which means that the intention relay node is the key to connecting the two chains.

[0082] In practical implementation, the execution of cross-chain intents can be categorized into two methods: ① calculating the optimal path off-chain; ② executing the intent first, followed by forwarding it through the intent relay node. The following is a brief overview of the execution flow for both methods:

[0083] Method ①: 1. The user submits a cross-chain intent; the cross-chain intent submitted by the user is not directly recorded on the blockchain, but is received by the intent relay node. For example, the cross-chain intent is: to exchange 1 resource A for 20,000 resource B, with slippage ≤ 1%. Here, slippage in this application refers to the deviation between the user's expected transaction price and the actual transaction price. For example, if the user's expected price is 1 resource A for 2000 resource B, but the actual transaction price is 1 resource A for 1980 resource B, the slippage is (2000-1980) / 2000 = 1%. 2. The intent relay node broadcasts the cross-chain intent to each connected solver, and each solver calculates the optimal execution path (the optimal execution path can be understood as the optimal execution plan calculated by the solver, which may include the best exchange rate, the lowest cost, the minimum slippage, etc.). For example: Solver A calculates the optimal execution plan as: finding a combination of cross-chain bridge X and aggregator Y, with a quote of 0.8% slippage + 0.1% service fee; Solver B calculates the optimal execution plan as: quoting 0.7% slippage + 0.15% service fee through aggregator Z. 3; The intent relay node selects the optimal execution plan from the optimal execution plans returned by each solver as the target execution plan for this cross-chain intent. For example, the intent relay node can choose the plan with the lowest slippage and the lowest transaction fee as the target execution plan. Of course, the target execution plan can also be manually selected by the user. The intent relay node can send the optimal execution plans returned by each solver to the user for selection. 4; The intent relay node converts the target execution plan into a transaction that can be executed on the source chain. For example, this transaction is: calling a contract on the source chain to sell 1 resource A. For this transaction, after user signature confirmation, it can be submitted to the source chain so that nodes in the source chain can execute the transaction. For example, a source chain node completes the exchange from 1 resource A to 1 resource B on the source chain. The intent relay node can submit this transaction to the source chain. 4. The source chain node executes the transaction. After the node on the source chain has completed its required transaction, it generates an execution success event for the transaction and adds it to the blockchain for storage. This execution success event can be called a cross-chain intent event, used to indicate that the source chain node has successfully executed its required transaction for this cross-chain intent. 5. The intent relay node verifies the cross-chain intent event. After successful verification, it packages the transaction to be executed on the target chain and sends it to the target chain, where nodes in the target chain execute their required transaction. For example, the transaction is: transferring the exchanged resource B to the user's account address.

[0084] Method ②: 1. The user submits an intent to the source chain. The user can directly call the smart contract on the source chain (such as the lockAndIntent method of a cross-chain bridge) to lock the resource to be exchanged (e.g., one resource A on the source chain) and declare the demand, for example: to exchange 2000 resources B on the target chain. 2. The node on the source chain calls the contract to lock the user's one resource A on the chain and issues a lock event for resource A. This lock event can be understood as a cross-chain intent event for the user's submitted cross-chain intent. 3. The intent relay node detects this event on the source chain and verifies whether the user's one resource A has been locked. 4. After verifying that the user's one resource A has indeed been locked, the intent relay node packages the cross-chain intent information and sends it to the target chain, where the node on the target chain executes the exchange.

[0085] As can be seen, regardless of the method described above, the intent relay node is crucial in the execution of each cross-chain intent (a cross-chain intent indicating a transaction from the source chain to the target chain), responsible for forwarding the cross-chain intent from one blockchain to another. In this process, the intent relay node needs to obtain the cross-chain intent information from one chain and verify its legitimacy and validity before repackaging it and forwarding it to another chain. Traditionally, intent relay nodes verify cross-chain intent information by setting up full nodes on all blockchains in the cross-chain intent system. The verification is done using the complete block information synchronized across all nodes. This requires nodes to continuously synchronize with the latest block information, resulting in extremely high node setup costs. Because the setup cost of intent relay nodes is too high, many application scenarios cannot afford it, leading to insufficient decentralization and reduced security and efficiency in cross-chain intent execution.

[0086] To facilitate understanding of the meaning of setting up a node for an intent relay node, the following explanation is provided. The methods for setting up a node for an intent relay node can include embedded and external methods. An embedded method refers to running a node client within the running process of the intent relay node; an external method refers to establishing a communication connection between the intent relay node and other nodes. Therefore, setting up a node for an intent relay node can be understood as embedding the node or establishing a communication connection with it. Similarly, setting up a full node for an intent relay node can be understood as embedding a full node within the intent relay node or establishing a communication connection with it. Since a full node needs to store all block data in the blockchain, the cost of maintaining a full node for an intent relay node is high. Therefore, regardless of the method, both methods will bring significant setup costs to the intent relay node, especially the embedded method, which incurs extremely high setup costs.

[0087] Based on this, this application provides a local verification scheme for intent relay nodes, which can improve the security and efficiency of cross-chain intent execution while reducing the node setup cost of intent relay nodes. The scheme provided by this application can generally include the following five steps: 1. Abandoning the traditional scheme of setting up full nodes in each blockchain, the intent relay node only needs to set up light nodes in each chain. For example, the intent relay node can be embedded in the light nodes of each chain, or the intent relay node can establish a connection with the light nodes of each chain. Since the external solution has a lower setup cost than the embedded solution, this application recommends the node setup scheme of establishing a connection between the intent relay node and the light nodes of each chain as the preferred solution. 2. The intent relay node monitors the blocks in each blockchain to detect whether any blocks contain cross-chain intent events. Here, the cross-chain intent event in this application refers to the event generated by the node on the source chain after it has completed the transaction it needs to execute. This cross-chain intent event can be used to indicate that the node on the source chain has successfully executed the transaction it needs to execute. Based on the above, a user-submitted cross-chain intent refers to a transaction request from one chain (the source chain) to another chain (the target chain). To fulfill this request, different blockchains need to collaboratively execute a cross-chain transaction. This cross-chain transaction must first be executed by nodes on the source chain, and then by nodes on the target chain. After the nodes on the source chain complete their respective transactions, they can generate an execution success event based on the transaction. This execution success event can be understood as the cross-chain intent event in this application. The nodes on the source chain will package the cross-chain intent event into a block. During packaging, the cross-chain intent information (used to indicate that the cross-chain transaction indicated by this cross-chain intent needs to be collaboratively executed by the source chain and the target chain) can be packaged into the block. Then, the nodes on the source chain can store the block on the source chain, and the intent relay node can monitor the cross-chain intent event in the block and obtain the cross-chain intent event. In other words, once an intent relay node detects that a block on a blockchain contains a cross-chain intent event, that blockchain can be considered the source chain of this cross-chain intent. The blockchain included in the cross-chain intent event that requires the collaborative execution of the cross-chain transaction by another blockchain can be considered the target chain of this cross-chain intent. Based on this, for the aforementioned first blockchain, after the intent relay node detects a cross-chain intent event on the first blockchain, it can consider the first blockchain as the source chain. The cross-chain intent event should contain cross-chain intent information, which is used to indicate that the cross-chain transaction indicated by this cross-chain intent needs to be collaboratively executed by the first blockchain and another blockchain (such as the second blockchain). This cross-chain transaction includes a transaction executed on the first blockchain (referred to as the first transaction in this application) and a transaction executed on the second blockchain (referred to as the second transaction in this application).It is worth noting that after each node on the source chain completes its assigned transaction, it packages the transaction into a block and adds it to the source chain. When generating a cross-chain intent event, the block index information of the block where this transaction is located (i.e., information that can index the block, such as block identifier, block hash, block height, etc.) can also be added to the cross-chain intent event. Therefore, for the cross-chain intent event on the first blockchain mentioned above, it will also include the block index information of the block to which the first transaction belongs on the first blockchain (referred to as the first block in this application). 3. Based on this block index information, the intent relay node obtains the block header information of the first block from the light nodes of the first blockchain. It should be understood that since the intent relay node in this application has built light nodes on each blockchain, the intent relay node can conveniently and quickly obtain the block header information of the first block from the light nodes of the first blockchain based on the block index information. 4. The legality of the cross-chain intent event is verified based on the obtained block header information to obtain the legality verification result. 5. When the legality verification result indicates that the cross-chain intention event is legal, send a transaction to be executed in the second blockchain (referred to as the second transaction in this application) to the second blockchain to instruct the second blockchain to execute the second transaction, thereby completing the execution of the cross-chain transaction indicated by the cross-chain intention.

[0088] The solution provided in this application can be used in the process of verifying cross-chain intentions by intention relay nodes. By building light nodes on each blockchain, verification can be achieved by synchronizing block header information from the light nodes, without the need to build all nodes on each blockchain. The cost of building light nodes is relatively small, which can reduce the node building cost. Moreover, since the node building cost of intention relay nodes is reduced, many application scenarios can consider using this method to implement intention relay nodes, thereby improving the decentralization of intention relay nodes and thus improving the execution security of cross-chain intentions.

[0089] Furthermore, the local verification scheme for the intent relay node provided in this application embodiment can be executed by the intent relay node, which may include a terminal or a server, and may also include both a terminal and a server. To facilitate understanding of the scheme provided in this application embodiment, the following is combined with... Figure 1 The schematic diagram shown illustrates the application scenarios involved in the embodiments of this application; wherein, Figure 1 This is a schematic diagram of the implementation environment provided by an exemplary embodiment of this application, such as... Figure 1 As shown, the implementation environment may include terminal 101 and a cross-chain intent system; wherein:

[0090] 1) Terminal 101 may include the terminal device used by the user. In this application, the user refers to the business user who generates transaction information. This transaction information can refer to a cross-chain intent. After user authorization, the transaction information (transaction) generated by the terminal device can be transmitted to a node in the blockchain. This node can record the transaction information generated by the terminal device in the blockchain. In a specific implementation, the user can submit a cross-chain intent through a blockchain application running on the terminal. This cross-chain intent can be constructed and converted into a cross-chain transaction by the blockchain application. Then, the blockchain application can send / submit this cross-chain transaction to the cross-chain intent system (either to an intent relay node in the cross-chain intent system or to a node on the source chain of the cross-chain intent system; the source chain refers to the blockchain where the resource being traded in this cross-chain transaction resides: i.e., the source chain of the resource being traded in this cross-chain transaction). The cross-chain intent system then executes the transaction indicated by the cross-chain intent and records it in the blockchain. Based on this, the cross-chain transaction submitted to the intent relay node or the blockchain in this application is equivalent to the cross-chain intent submitted by the user.

[0091] Of course, depending on the application scenario and field in which the cross-chain intent verification scheme provided in this application is applied, the terminal providing the local verification scheme for the intent relay node in the embodiments of this application will vary. Terminal devices may include, but are not limited to: smartphones (such as smartphones running the Android system, or smartphones running the Internetworking Operating System (IOS), tablet computers, portable personal computers, mobile Internet devices (MIDs), in-vehicle devices, head-mounted smart home devices, and smart voice interaction devices, etc. The embodiments of this application do not limit the type of terminal device, as stated here.

[0092] 2) A cross-chain intent system can refer to a system composed of intent relay nodes and different blockchains. For example, the cross-chain intent system may include intent relay nodes 102, blockchain 1031, blockchain 1032, ..., blockchain 103n. Intent relay nodes can monitor blocks in each blockchain to detect whether newly added blocks in each blockchain contain cross-chain intent events. Wherein, the cross-chain intent sent by a user through a terminal device needs to be completed collaboratively by multiple blockchains (in this application, "multiple" refers to two or more). Therefore, the cross-chain transaction indicated by the cross-chain intent needs to be executed collaboratively by multiple blockchains. Once the cross-chain intent system receives the cross-chain intent submitted by the user, the nodes on the source chain (e.g., blockchain 1031) need to first execute their own transaction (referred to as the first transaction in this application) and package the executed transaction into a block, recording the block on the source chain. Afterwards, the nodes on the source chain will, based on the block index information of the block containing the first transaction (i.e., information that can index this block, such as...),... The system uses information such as block hash and block height, along with relevant information about the cross-chain intent (which can be determined based on the user-submitted cross-chain intent and may include information such as the source chain, target chain, transaction volume, transaction resources, and the account address receiving the resources; referred to as cross-chain intent information in this application), to construct a cross-chain intent event for the first transaction. This cross-chain intent event represents a user initiating a cross-chain intent. For this cross-chain intent, the nodes on the source chain have already completed their required transactions (i.e., the first transaction). Subsequently, the nodes on the source chain can package the cross-chain intent event into a block and record the block on the source chain. In this way, the intent relay node can detect the cross-chain intent event issued by the nodes on the source chain by monitoring the blocks on each blockchain.

[0093] The intent relay node is also responsible for setting up light nodes in each blockchain (e.g., establishing communication connections with each light node). When the intent relay node detects a cross-chain intent event in a block of a blockchain, it can obtain the block header information of that block from the light nodes on that blockchain based on the block index information of the block containing the transaction. Then, it verifies the legitimacy of the obtained cross-chain intent event based on this block header information. If the legitimacy verification result indicates that the cross-chain intent event is legitimate, it can send a transaction (called the second transaction) to the target chain (which can be the blockchain that will receive the resources being traded in this cross-chain intent) to instruct the target chain to execute the second transaction. After the target chain completes the second transaction, the cross-chain transaction is considered to be completed.

[0094] It should be noted that the intended relay node and each node (such as a full node) in the blockchain proposed in this application can be a server or a terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. The terminal device can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, smart vehicle, smart voice interaction device, etc., but is not limited to these.

[0095] In this application, the terminal 101 and the intent relay node 102, or the terminal 101 and each node in the blockchain, can be directly or indirectly connected via wired or wireless communication. This is not limited in this application. Furthermore, this application does not limit the number of terminals, intent relay nodes, or the number of blockchains monitored by the intent relay nodes. Figure 1 The number of terminal 101 and intent relay node 102 is only a single example. In actual applications, multiple servers may be distributed in a distributed manner. This is just a brief explanation.

[0096] It should be noted that, in the specific embodiments of this application, data related to user information and user data (such as user-initiated transaction information and transaction data) are obtained only after the user has manually authorized permission (i.e., with the user's consent). In other words, when the above embodiments of this application are applied to specific products or technologies, the methods and related functions provided by the embodiments of this application operate with the user's permission or consent (the user may actively activate the functions provided by the embodiments of this application), and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant regions and areas.

[0097] The embodiments of this application can be applied to various scenarios, including but not limited to gaming, finance, cloud technology, artificial intelligence, smart transportation, and assisted driving. To facilitate understanding of the process by which the intent relay node verifies cross-chain intent information, the following will provide an illustrative description in conjunction with the accompanying drawings. Please refer to the accompanying drawings for further details. Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario for verifying cross-chain intent information provided in an embodiment of this application. Wherein, as... Figure 2 The scenario shown is illustrated by taking the node that receives the user's cross-chain intent as a node in the blockchain, rather than an intent relay node.

[0098] like Figure 2 As shown, user A initiates a cross-chain intent through a blockchain application running on a terminal device. This cross-chain intent refers to the requirement that user A wants to fulfill, which requires crossing blockchains to achieve. For example, the cross-chain intent is: to transfer 10 resources 'a' under user A's account name in chain A to account address 0x123 in chain B. Based on the cross-chain intent initiated by user A, the blockchain application constructs a transaction that calls the cross-chain contract in blockchain A (this transaction can be called a cross-chain transaction). This cross-chain transaction may contain information such as: blockchain A, blockchain B, the receiving address of 10 resources 'a' (i.e., account address: 0x123), the amount transferred (10), the resources transferred (resource a), the transaction fee, etc. This information can be referred to as the cross-chain intent information of the cross-chain intent submitted by user A. As can be seen, the cross-chain intent information reflects that this cross-chain transaction needs to be executed collaboratively by blockchain A and blockchain B. For this cross-chain transaction, a transaction needs to be executed on blockchain A (e.g., a transaction to lock or deduct 10 resources a from chain A), and then a transaction needs to be executed on blockchain B (e.g., minting 10 resources a to account address 0x123 on chain B).

[0099] Furthermore, for this cross-chain transaction, user a's private key can be used to sign it, forming a digital signature for the cross-chain transaction. The terminal device can submit this cross-chain transaction and user a's digital signature together to a node in blockchain A (which can be understood as submitting user a's cross-chain intention to blockchain A). Taking node A in blockchain A receiving this cross-chain transaction as an example, after receiving this cross-chain transaction, node A can first verify the signature. The signature verification refers to verifying the digital signature using user a's public key. If the verification is successful, the cross-chain transaction can continue to be executed. After successful verification, node A can call its own cross-chain contract code to execute the transaction it needs to execute: that is, deduct 10 resources 'a' from user a on blockchain A. After the execution is completed, node A can package the transaction it executed (here referred to as transaction A) into a block (here referred to as transaction block) and add this transaction block to blockchain A for storage.

[0100] Following this, node A will obtain the block hash and block height of this transaction block. Both the block hash and block height can be used as block index information for transaction A. Node A can generate a cross-chain intent event and add the block index information and the aforementioned cross-chain intent information to this event. For this cross-chain intent event, node A can package it into a block (e.g., as shown in the image). Figure 2Block 2001 (as shown) is added to blockchain A for storage. Thus, by monitoring blocks on each blockchain, the intent relay node can detect that block 2001 contains a cross-chain intent event. After detecting the cross-chain intent event, the intent relay node extracts the block index information of the aforementioned transaction A contained in this cross-chain intent event, and based on this block index information, extracts the block header information of the block containing transaction A in blockchain A from a light node in blockchain A.

[0101] Based on the obtained block header information, the intent relay node can verify this cross-chain intent event. This verification can be understood as verifying the cross-chain intent information in the cross-chain intent event. Through verification, it can detect who the creator of this cross-chain intent information is (e.g., a node on the source chain mentioned above), whether the node on the source chain has successfully executed the transaction it should have executed, etc. If the verification is successful, the cross-chain intent event can be considered legitimate. At this time, the intent relay node can extract the transaction that needs to be executed by blockchain B (e.g., transferring 10 resources 'a' to account address 0x123. This transaction can be called transaction B) and submit transaction B to a node of blockchain B (here, we take node B as an example). After receiving transaction B, node B can call the cross-chain contract on blockchain B to execute transaction B. After executing transaction B, transaction B can be packaged into a block. Here, we take block 2002 as an example. Node B will add block 2002 to blockchain B for storage. It is evident that for nodes in blockchain B, it is only necessary to verify the legitimacy of transactions (such as transaction B) submitted by the intended relay node, without needing to concern themselves with the origin of the traded resources or other related matters.

[0102] Through such Figure 2 As can be seen from the illustrated scenario, compared to the traditional scheme of setting up full nodes on each blockchain to verify cross-chain intent events, the cross-chain intent verification scheme for intent relay nodes provided in this application can accurately and efficiently achieve verification by setting up only light nodes on each blockchain, which can reduce the cost of node setup and improve the efficiency of verification.

[0103] Based on the verification scheme for intent relay nodes described above, this application proposes a more detailed data processing method for blockchain networks. This blockchain network refers to a network containing multiple blockchains and intent relay nodes (which can correspond to the above-described method). Figure 1 The cross-chain intent system shown here is illustrated using an example of multiple blockchains including a first blockchain and a second blockchain. For ease of understanding, the data processing method for the blockchain network provided in this application embodiment will be described in detail below with reference to the accompanying drawings. Please refer to... Figure 3 , Figure 3This is a flowchart illustrating a data processing method for a blockchain network provided in an embodiment of this application. This process can be executed by an intent relay node in the blockchain network, such as... Figure 3 As shown, the process may include at least the following steps S301-S303:

[0104] Step S301: Monitor cross-chain intent events on the first blockchain; the cross-chain intent event contains cross-chain intent information, which is used to instruct the first blockchain and the second blockchain to jointly execute cross-chain transactions. The cross-chain transaction includes a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; the cross-chain intent event also contains the block index information of the first block to which the first transaction belongs on the first blockchain.

[0105] In this application, to better understand cross-chain intent events, the processing process of cross-chain intents will be described below. The processing process of cross-chain intents can include at least the following four steps: 1. The user submits a cross-chain intent through a terminal device. A user can submit a cross-chain intent through a terminal device. This cross-chain intent represents a requirement that the user wants to achieve, which requires multiple blockchains to cooperate in executing a cross-chain transaction to achieve this requirement. For example, a cross-chain intent is to transfer 10 resources 'a' from blockchain A to account address 0x123 in blockchain B. This cross-chain intent means that it needs to be achieved by the cooperation of blockchain A and blockchain B. Blockchain A and blockchain B need to cooperate in executing the cross-chain transaction "transferring 10 resources 'a' from blockchain A to account address 0x123" to achieve this requirement. 2. Nodes on the source chain execute the transaction that needs to be executed on the source chain (which can be called the source chain transaction). In this application, the source chain refers to the blockchain to which the traded resource belongs in the cross-chain transaction indicated by the cross-chain intent; that is, the source blockchain of the traded resource. For a cross-chain transaction indicated by a cross-chain intent, the nodes on the source chain must first execute their own transactions. For example, a node on blockchain A would execute a transaction to "deduct 10 resources 'a' belonging to this user from blockchain A". 3. Based on the executed source chain transactions, the nodes on the source chain generate a block and add this block to the source chain for storage. For clarity, the block where the source chain transaction is located can be called the source chain transaction block. 4. Based on the relevant information of the cross-chain intent (i.e., cross-chain intent information) and the block index information of the source chain transaction block, a cross-chain intent event is generated for the cross-chain intent. Cross-chain intent information refers to relevant information generated based on cross-chain intents. This information may include the blockchain specified by the intent (e.g., blockchain A and blockchain B mentioned above), the transaction address of the resource (including the sending and receiving account addresses), fee requirements, slippage requirements, etc. The block index information of the source chain transaction block refers to information that can be traced back to the source chain transaction block. This information can be used to uniquely identify the source chain transaction block, such as block hash and block height. Based on the cross-chain intent information and the block index information of the source chain transaction block, nodes on the source chain can generate a cross-chain intent event for this cross-chain intent. This cross-chain intent event can be used to reflect that a user has submitted a cross-chain intent that needs to be executed by multiple blockchains, and the nodes on the source chain have already completed their required transactions. 5. When an intent relay node detects a cross-chain intent event recorded in the source chain transaction block, it verifies the legitimacy of this cross-chain intent event. Upon confirming the legitimacy of the cross-chain intent event, it forwards the transaction to be executed on the target chain (referred to as the target chain transaction) to the target chain, enabling nodes on the target chain to execute their required transactions. In this application, the target chain refers to the blockchain that receives the traded resources in the aforementioned cross-chain transaction; that is, the receiving blockchain of the traded resources.For example, in the cross-chain transaction illustrated above, the target chain refers to blockchain B, and the target chain transaction is: transferring 10 resources 'a' to account 0x123. The intent relay node can submit this target chain transaction to a node on the target chain. This node will execute the target chain transaction and generate a block based on it. This block can be called the target chain transaction block. Then, the node can add the target chain transaction block to the target chain for storage. Thus, blockchain A and blockchain B collaboratively realize the cross-chain intent submitted by the user. It should be noted that the nodes executing transactions in each blockchain are the same as those executing transactions on traditional blockchains. For example, a consensus node can execute the transaction, and the block generation is agreed upon by various consensus nodes in the blockchain. After consensus is reached, the block is added to the blockchain for storage.

[0106] Based on the cross-chain intent processing flow described above, it can be seen that the blockchain network provided in this application may include intent relay nodes and multiple blockchains (this application uses multiple blockchains, including a first blockchain and a second blockchain, as an example for illustration). The intent relay node can monitor blocks in each blockchain to determine whether the block contains a cross-chain intent event. Here, we take the example of an intent relay node detecting that a block on the first blockchain contains a cross-chain intent event to illustrate the process provided in this application for verifying the legitimacy of cross-chain intent events.

[0107] Based on the above description, a detected cross-chain intent event includes cross-chain intent information and the block index information of the source chain transaction block. Since the detected cross-chain intent event is on the first blockchain, the first blockchain can be understood as the source chain in the cross-chain transaction corresponding to this cross-chain intent event. The source chain transaction is the transaction that needs to be executed on the first blockchain in this cross-chain transaction (referred to as the first transaction in this application), and the source chain transaction block is the block where the first transaction is located on the first blockchain. That is, the cross-chain intent event contains cross-chain intent information, which can be used to reflect that a cross-chain transaction needs to be jointly executed by the first blockchain and the second blockchain (which is the target chain of this cross-chain transaction). This cross-chain transaction will include the transaction that needs to be executed on the first blockchain (the first transaction), the transaction that needs to be executed on the second blockchain (the second transaction), and the block index information of the block where the first transaction is located on the first blockchain. The block index information recorded in this cross-chain intent event can be referred to as the block index information of the first block in this application.

[0108] Step S302: Based on the block index information of the first block, obtain the block header information of the first block from the light nodes of the first blockchain, and perform legality verification on the cross-chain intent event according to the block header information of the first block to obtain the legality verification result.

[0109] In this application, the intent relay node can obtain the block index information of the first block from the cross-chain intent event. Based on this block index information, it can obtain the block header information of the first block from the light nodes of the first blockchain. As described above, the block index information of the first block includes the block hash and block height of the first block. Therefore, obtaining the block header information of the first block can be based on the block hash and block height. For details on obtaining the block header information of the first block from the light nodes of the first blockchain based on the block hash and block height recorded in the cross-chain intent event, please refer to the following sections. Figure 5 The relevant descriptions in the corresponding embodiments.

[0110] In practical applications, a light node in a blockchain records the block header information of each block on the blockchain. The block header information includes the block hash and the Merkle root of each transaction contained in the block. After obtaining the block header information of the first block from the light node of the first blockchain, this application can obtain the Merkle root of the first block from that block header information. Subsequently, the legitimacy of cross-chain intent events can be verified based on this Merkle root. The Merkle root contained in the block header information of the first block can be referred to as the second Merkle root. In the process of verifying the legitimacy of cross-chain intent events, the block information (i.e., complete block information) of the first block stored and recorded in the full nodes of the first blockchain can be used. Based on relevant blockchain concepts, it is known that the block information of each block stored and recorded in each full node of the blockchain contains a Merkle tree constructed based on the transaction hashes of each transaction in that block. This means that for any transaction in this block, the full node stores and records the Merkle path of that transaction (obtained from the Merkle tree, which can be understood as the Merkle proof of the transaction). Based on this, this application can verify the legitimacy of cross-chain intent events based on the Merkle path of the first transaction recorded in the full node, combined with the Merkle root of the first block stored and recorded in the light node.

[0111] Since the intention relay node in this application does not establish full nodes in each blockchain (i.e., there is no communication connection between the intention relay node and each full node, or no full node is deployed and running in the intention relay node), the intention relay node itself cannot obtain the Merkel path of the first transaction stored by the full node from the full node. However, since there is a network connection between the light node and the full node in a blockchain, the intention relay node can send an instruction to the light node in the first blockchain, and the light node can query the full node for the Merkel path of the first transaction recorded by the full node based on the instruction.

[0112] In other words, the specific implementation process for verifying the legitimacy of a cross-chain intent event based on the block header information of the first block and obtaining the legitimacy verification result can at least include: generating an information retrieval instruction for the first transaction. This instruction instructs a light node in the first blockchain to retrieve the transaction verification information of the first transaction from at least one full node in the first blockchain. This transaction verification information can refer to information used to verify the first transaction, specifically the Merkel proof (i.e., the Merkel path) of the first transaction. The intent relay node can send the information retrieval instruction for the first transaction to a light node in the first blockchain. Based on this instruction, the light node will send a query request for the transaction verification information of the first transaction to a full node in the first blockchain. The full node in the first blockchain can then return the transaction verification information (i.e., the Merkel proof) of the first transaction that it has stored and recorded to the light node. Light nodes can return the transaction verification information of the first transaction they receive to the intent relay node. After receiving the transaction verification information of the first transaction returned by the light nodes in the first blockchain, the intent relay node can perform legality verification on the cross-chain intent event based on the block header information of the first block and the transaction verification information to obtain the legality verification result.

[0113] In practical applications, it cannot be guaranteed that all full nodes are operating normally without any anomalies. This means that a blockchain may contain malicious nodes that could return incorrect or inaccurate information, affecting the legitimacy verification result. Therefore, this application allows querying the transaction verification information of the first transaction stored by multiple full nodes. Thus, light nodes in the first blockchain will query the transaction verification information of the first transaction from multiple full nodes. Even if one or a few full nodes are malicious and return incorrect information, it will not affect the final legitimacy verification result. In other words, a light node will send a query request for the transaction verification information of the first transaction to at least one full node (usually two or more), and each full node will return the transaction verification information of the first transaction it stores to the light node. The relay node will also receive at least one transaction verification message.

[0114] The specific implementation process for verifying the legitimacy of a cross-chain intent event based on the block header information of the first block and at least one transaction verification information, and obtaining the legitimacy verification result, may include at least the following: obtaining the information content of each transaction verification information, which can be understood as the specific path content of the transaction verification information. For example, at least one transaction verification information contains transaction verification information x, which is “xhshg” (this is just an example for ease of understanding and does not represent any actual reference meaning). It can be seen that the specific value of the transaction verification information x is “xhshg”, and the information content is “xhshg”.

[0115] Based on the information content of each transaction verification message in at least one transaction verification message, the correct transaction verification message can be determined from the at least one transaction verification message. The specific implementation process may include: grouping the at least one transaction verification message according to the information content of each transaction verification message; specifically, transaction verification messages with the same information content can be grouped together, thus obtaining at least one information group; the information content of each transaction verification message contained in each information group is the same; then, the number of transaction verification messages contained in each information group can be counted, and the information group with the largest number of messages can be obtained. The information group with the largest number of messages can be determined as the target information group, and the transaction verification message contained in the target information group can be determined as the correct transaction verification message.

[0116] After determining the correct transaction verification information for the first transaction, the block header information of the first block can be compared with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event. Since the transaction verification information contains the Merkle proof of the first transaction, comparing the block header information of the first block with the correct transaction verification information can refer to comparing the Merkle root contained in the block header information with the Merkle proof contained in the correct transaction verification information. The specific implementation process can include: First, a hash calculation can be performed on the first transaction to obtain its transaction hash. A hash algorithm can be used to perform the hash calculation on the first transaction. A hash algorithm is a function that maps data of arbitrary length to a fixed-length output (hash value). A hash algorithm can convert one piece of data into another of fixed length. The data calculated by the hash algorithm is called a hash value. Examples of hash algorithms include the SHA hash algorithm (SHA series) and the BLAKE hash algorithm (BLAKE series). This application can use the hash algorithm used in the first blockchain to perform the hash calculation on the first transaction to achieve uniformity. The hash value of the first transaction obtained from the calculation can be called the transaction hash of the first transaction.

[0117] After calculating the transaction hash of the first transaction, Merkle calculations can be performed on the transaction hash and Merkle proof of the first transaction to obtain the first Merkle root. It should be understood that the Merkle tree in this application is obtained by calculating the transaction hashes of each transaction in the block layer by layer. The root of the Merkle tree is the Merkle root. After obtaining the Merkle proof and transaction hash of the first transaction, the intention relay node can recalculate a Merkle tree based on the Merkle proof and transaction hash of the first transaction, according to the calculation method of the Merkle tree, thus obtaining a new Merkle root (the Merkle root calculated by the intention relay node is referred to as the first Merkle root in this application). The calculation method for the Merkle tree in this application is an existing and relatively mature technical process, which can be found in relevant literature.

[0118] After calculating the first Merkle root, the second Merkle root contained in the block header information can be obtained from the block header information of the first block. Then, the first Merkle root and the second Merkle root can be compared. If the first Merkle root and the second Merkle root are the same, the legality verification result of the cross-chain intent event can be determined as a verification passed result; if the first Merkle root and the second Merkle root are different, the legality verification result of the cross-chain intent event can be determined as a verification failed result.

[0119] It is worth noting that for the transaction verification information of the first transaction returned by each full node, the correct transaction verification information can be found. For those full nodes that send incorrect transaction verification information, the intention relay node can identify them as malicious nodes and add them to the blacklist. In this way, subsequent data acquisition will no longer be obtained from these malicious nodes in the blacklist.

[0120] Step S303: When the legality verification result indicates that the cross-chain intent event is legal, a second transaction is sent to the second blockchain to instruct the second blockchain to execute the second transaction.

[0121] In this application, if the legality verification result is confirmed as passed, it indicates that the cross-chain intent event is legitimate. The intent relay node can send a second transaction to a node in the second blockchain, and that node can execute the second transaction. Thus, the cross-chain intent corresponding to this cross-chain intent event is realized.

[0122] In this embodiment of the application, a local verification scheme for an intent relay node is provided. After detecting a cross-chain intent event on a blockchain (e.g., a first blockchain), the cross-chain intent information contained in the cross-chain intent event can be obtained. This cross-chain intent information includes the block index information of the first block to which the first transaction executed on the first blockchain belongs. Through this block index information, the intent relay node can obtain the block header information of the first block from the light nodes of the first blockchain. Based on this block header information, the legality verification of the cross-chain intent event can be performed locally on the intent relay node (which can actually be understood as the legality verification of the cross-chain intent information). When the legality verification result indicates that the cross-chain intent event is legal, the second transaction to be executed on the second blockchain can be sent to the second blockchain to instruct the second blockchain to execute the second transaction. In summary, the cross-chain intent node in this application does not require building full nodes on each blockchain; only light nodes are needed. Compared to full nodes, light nodes do not need to synchronize complete block information, only block header information. Therefore, the cost of building light nodes is lower. Due to the reduced node setup cost of intent relay nodes, this method can be considered for many application scenarios, thereby improving the decentralization of intent relay nodes and thus enhancing the execution security of cross-chain intents. Furthermore, after each cross-chain intent event is received, the legality verification of the cross-chain intent event can be quickly completed based on the block header information stored in the light nodes of the blockchain, greatly reducing the resource consumption of verification. Moreover, the verification process is based on the Merkle root in the block header information and the Merkle proof recorded in the full nodes, making it more secure and reliable. Tampered data cannot pass verification, further enhancing the security of cross-chain intent information verification and thus improving the security of cross-chain intent execution. In conclusion, this application can improve the execution security and efficiency of cross-chain intents while reducing the node setup cost of intent relay nodes.

[0123] Furthermore, for a better understanding of the verification process provided in this application, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of the logical flow of verifying intent events provided in an embodiment of this application. For example... Figure 4 As shown, the logical flow may include at least steps S41-S49:

[0124] Step S41: The intent relay node detects a cross-chain intent event in the first blockchain.

[0125] Specifically, the cross-chain intent event will contain cross-chain intent information, which is used to instruct the first blockchain and the second blockchain to jointly execute a cross-chain transaction. This cross-chain transaction includes a first transaction executed on the first blockchain and a second transaction executed on the second blockchain.

[0126] Step S42: The intent relay node queries the block header information from the light node of the first blockchain.

[0127] Specifically, based on the block index information contained in the cross-chain intent event, the intent relay node can obtain the block header information of the first exchange's block from the light node of the first blockchain.

[0128] Step S43: The light node of the first blockchain returns the block header information to the intent relay node.

[0129] Step S44: The intent relay node sends an information query instruction to the light node of the first blockchain.

[0130] Specifically, the intent relay node can verify the validity of the block index information recorded in the cross-chain intent event based on the block header information returned by the light node of the first blockchain. When the verification result is a successful verification, the intent relay node can send an information query instruction to the light node of the first blockchain. This instruction can be used to instruct the light node of the first blockchain to query the transaction verification information of the first transaction from at least one full node of the first blockchain.

[0131] Step S45: The light node of the first blockchain sends an information query request to the full node of the first blockchain.

[0132] Specifically, a light node in the first blockchain can send an information query request for transaction verification information for the first transaction to at least one full node in the first blockchain based on the received information query instruction.

[0133] Step S46: The full node of the first blockchain returns the information query result to the light node of the first blockchain.

[0134] Specifically, each full node that receives an information query request can return the information query result (i.e., the transaction verification information of the first transaction) to the light node of the first blockchain.

[0135] Step S47: The light node of the first blockchain returns the information query result to the intent relay node.

[0136] Step S48: The intent relay node verifies the legitimacy of the cross-chain intent event.

[0137] Specifically, the intent relay node can verify the legitimacy of cross-chain intent events based on the block header information returned by the light node and at least one transaction verification information, and obtain the legitimacy verification result.

[0138] Step S49: The intent is for the relay node to send a transaction to the second blockchain.

[0139] Specifically, if the legitimacy verification result indicates that the cross-chain intent event is legitimate, the intent relay node can send a transaction (i.e., the second transaction) to a node in the second blockchain, which will then execute the second transaction.

[0140] Furthermore, the following will illustrate, with reference to the accompanying diagram, the process of obtaining the block header information of the first block from the light node of the first blockchain based on the block hash and block height of the first block recorded in the cross-chain intent event. Please refer to the attached diagram. Figure 5 , Figure 5 This is a schematic diagram of a process for obtaining the block header information of a first block according to an embodiment of this application, wherein the process can correspond to the above. Figure 3 In the corresponding embodiment, the process of obtaining the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block is as follows: Figure 5 As shown, the process may include at least the following steps S501-S505:

[0141] Step S501: Determine the block hash recorded in the block index information of the first block as the first block hash, and determine the block height recorded in the block index information of the first block as the target block height.

[0142] Specifically, to facilitate differentiation, the block hash recorded in the block index information of the first block can be determined as the first block hash (i.e., the first block hash), and the block height recorded in the block index information of the first block can be determined as the target block height (i.e., the target block height).

[0143] Step S502: Obtain the second block indicated by the target block height in the first blockchain.

[0144] Specifically, based on this target block height, the block indicated by the target block height can be obtained in the first blockchain. It's worth noting that if the target block height recorded in the cross-chain intent event is not a correct value, there may not be a block with the target block height in the first blockchain. In this case, the cross-chain intent event can be directly determined to be illegitimate (i.e., the validity verification result of the cross-chain intent event is a failure). If there is a block with the target block height in the first blockchain, this block can be identified as the block indicated by the target block height, and this block can be called the second block.

[0145] Step S503: Obtain the block hash of the second block recorded by the light node of the first blockchain, and determine the block hash of the second block recorded by the light node of the first blockchain as the second block hash.

[0146] Specifically, after determining the second block indicated by the target block height from the first blockchain, the block hash of the second block recorded by the light node (which can be any light node) of the first blockchain can be obtained. To distinguish it, the block hash of the second block recorded by the light node of the first blockchain can be determined as the second block hash (i.e., called the second block hash).

[0147] Step S504: Based on the hash of the first block and the hash of the second block, the block index information of the first block is validated to obtain the validity validation result.

[0148] Specifically, in the implementation, even if a block with the target block height exists in the first blockchain, it does not prove that the block index information recorded in the cross-chain intent event is completely correct. In this case, the hash of the first block recorded in the cross-chain intent event needs to be verified to determine if it is incorrect. If the hash of the first block recorded in the cross-chain intent event is incorrect, then the block index information recorded in the cross-chain intent event can be determined to be inaccurate, and the cross-chain intent event is not legitimate. Therefore, after obtaining the first block hash and the second block hash, the validity of the block index information of the first block can be verified based on the first block hash and the second block hash to obtain the validity verification result. The validity verification result can include a pass result and a fail result. A pass result indicates that the block index information of this first block is valid, that is, the block index information recorded in the cross-chain intent event is correct. The first block hash and the target block height recorded in the cross-chain intent event can match the second block hash recorded in the light node in the first blockchain. At this time, it can be proven that the block index information stored in the cross-chain intent event is the index information of the second block. The block header information of the second block stored in the light node of the first blockchain can be obtained (the block header information of the second block and the second block hash are stored together in the light node, and the block header information of the second block can be determined through the second block hash). The block header information of the second block stored in the light node of the first blockchain is determined as the block header information of the first block.

[0149] A failed verification result indicates that the block index information of the first block is invalid. However, if the hash of the second block recorded on the light node of the first blockchain is different from the hash of the first block, it does not necessarily mean that the block index information recorded in the cross-chain intent event is incorrect. This is because the hash of the second block recorded on the light node of the first blockchain may be incorrect; the light node itself may have stored incorrect information (the light node may have synchronized incorrect information and stored it locally). Therefore, when the hash of the second block recorded on the light node of the first blockchain is different from the hash of the first block, the validity of the block index information of the first block can be verified based on the information recorded on the full node of the first blockchain.

[0150] In summary, the specific implementation process of this application for validating the block index information of the first block based on the first block hash and the second block hash, and obtaining the validity verification result, may include at least the following: comparing the first block hash and the second block hash; if the first block hash and the second block hash are the same, the validity verification result of the block index information of the first block can be directly determined as a successful verification result; if the first block hash and the second block hash are different, it is necessary to obtain the block hash of the second block recorded by the full node of the first blockchain (for ease of distinction, the block hash of the second block recorded by the full node is referred to as the third block hash), and then verify the validity of the block index information of the first block based on the third block hash and the first block hash. Since the intention relay node in this application does not set up full nodes in each blockchain (i.e., there is no communication connection between the intention relay node and each full node, or no full node is deployed and running in the intention relay node), the intention relay node itself cannot obtain the third block hash from the full node. However, since there is a network connection between the light node and the full node in a blockchain, the intention relay node can send an instruction to the light node in the first blockchain, and the light node can query the third block hash recorded by the full node based on this instruction.

[0151] The specific implementation process of obtaining the block hash of the second block stored by the full nodes in the first blockchain through a light node in the first blockchain can at least include: sending a hash query instruction to the light node in the first blockchain. This hash query instruction instructs the light node to query the block hash (i.e., the third block hash) of the second block stored by each of the N (N is a positive integer) full nodes in the first blockchain. In practical applications, it cannot be guaranteed that all full nodes are normal and error-free nodes. This means that there may be malicious nodes in a blockchain, which may return incorrect or inaccurate content, which will affect the validity verification result. Based on this, this application can set N to an integer value greater than 1. In this way, the light node in the first blockchain will query the third block hash from multiple full nodes. Even if one or a few full nodes are malicious nodes and return incorrect content, it will not affect the final validity verification result.

[0152] After receiving this hash query instruction, a light node in the first blockchain can select N full nodes from the first blockchain (which can be randomly selected) and send a query request for the block hash of the second block to each of the selected full nodes. Each full node can return the block hash of the second block that it has stored and recorded to the light node (the block hash of the second block recorded by each full node is referred to as the third block hash in this application). The light node can return the received N third block hashes to the intention relay node. After receiving the N third block hashes returned by the light node in the first blockchain, the intention relay node can verify the validity of the block index information of the first block based on the first block hash and these N third block hashes, and obtain the validity verification result.

[0153] Specifically, the implementation process for validating the block index information of the first block based on the first block hash and the block hash of the second block stored by the full nodes in the first blockchain can at least include: For the received N third block hashes, the hash content of each third block hash can be obtained. This hash content can be understood as the specific value of the third block hash. For example, among the N third block hashes, there is a third block hash x, which is "dhg93752". Therefore, the specific value of the third block hash x is "dhg93752", and its hash content is "dhg93752". Further, according to the hash content of the N third block hashes, they can be grouped. The specific grouping process is as follows: Third block hashes with the same hash content are grouped together. This results in at least one hash group, and the hash content of all third block hashes contained in a hash group is the same.

[0154] After this, the number of third block hashes contained in each hash group can be counted, and the hash group with the largest number of hashes can be obtained. The hash group with the largest number of hashes can be identified as the target hash group, and the third block hashes contained in the target hash group can be identified as the correct block hashes of the second block. It should be understood that malicious nodes in a blockchain are a minority, and the third block hashes returned by N full nodes should be the same. For one or a few full nodes with different third block hashes, they are very likely to be malicious nodes.

[0155] After determining the correct block hash of the second block, the hash of the first block can be compared with this correct block hash. If the first block hash is the same as the correct block hash of the second block, the validity verification result of the block index information of the first block can be determined to be a successful verification result. If the first block hash is different from the correct block hash of the second block, the block index information of the first block can be determined to be incorrect, and the validity verification result of the block index information of the first block is a failed verification result. In the case that the validity verification result of the block index information of the first block is a failed verification result, the legality verification result of the cross-chain intent event can also be determined to be a failed verification result, that is, the cross-chain intent event is not legal.

[0156] Step S505: When the validity verification result indicates that the block index information of the first block is valid, the block header information of the second block stored in the light node of the first blockchain is determined as the block header information of the first block.

[0157] Specifically, when the validity verification result indicates that the block index information of the first block is valid, the block header information of the second block stored in the light node of the first blockchain can be determined as the block header information of the first block.

[0158] It should be noted that if the comparison determines that the hash of the first block is the same as the correct hash of the second block, it indicates that the hash of the second block recorded in the light node of the first blockchain is an incorrect value. In this case, the intention relay node can generate a data update instruction based on the correct hash of the second block. This data update instruction is used to instruct the light node to update the hash of the second block it stores to the correct hash. The intention relay node can send the data update instruction to the light node, so that the light node can update the hash of the second block it stores to the correct hash.

[0159] It should also be noted that after the light node of the first blockchain obtains N third block hashes from N full nodes, it can verify the validity of the block index information itself based on the first block hash in the block index information and the N third block hashes (the verification process is the same as that of the intent relay node, which verifies the validity of the block index information based on the first block hash in the block index information and the N third block hashes). The light node then returns the verification result to the intent relay node. In other words, the intent relay node receives a validity verification result. Furthermore, when the validity verification result indicates that the block index information of the first block is valid (i.e., the first block hash is the same as the correct block hash of the second block), the light node can update its stored second block hash to the correct block hash of the second block.

[0160] To better understand the process of validating block index information provided in this application, please also refer to... Figure 6 , Figure 6 This is a schematic diagram of a logical flow for validating block index information, provided in an embodiment of this application. For example... Figure 6 As shown, the logical flow may include at least the following steps S61-S66:

[0161] Step S61: The intent relay node verifies the validity of the block index information based on the block header information.

[0162] Specifically, after receiving the block header information returned by the light node of the first blockchain, the intent relay node can verify the validity of the block index information based on the block header information. For example, as described above, the intent relay node can obtain the second block hash from the block header information of the light node and compare it with the first block hash to determine the validity verification result of the block index information.

[0163] Step S62: The intent relay node sends a hash query instruction to the light node of the first blockchain.

[0164] Specifically, when the intent relay node determines that the hash of the second block is different from the hash of the first block, it can send a query instruction for the hash of the second block to the light nodes of the first blockchain, which is used to instruct the light nodes of the first blockchain to query the hash of the second block from the full nodes of the first blockchain.

[0165] Step S63: The light node of the first blockchain sends a hash query request to the full node of the first blockchain.

[0166] Specifically, a light node in the first blockchain can send a query request for the block hash of the second block to N full nodes.

[0167] Step S64: The full node of the first blockchain returns the hash query result to the light node of the first blockchain.

[0168] Specifically, each full node that receives a hash query request can return the hash query result to the light node of the first blockchain. This hash query result is the block hash of the second block stored by the full node itself.

[0169] In step S65, the light node of the first blockchain returns the hash query result to the intent relay node.

[0170] In step S66, the intent relay node verifies the validity of the block index information based on the results of each hash query and the hash of the first block.

[0171] In this application, cross-chain intent nodes do not need to build full nodes on each blockchain; only light nodes are required. Compared to full nodes, light nodes do not need to synchronize complete block information, only block header information. Therefore, the cost of building light nodes is lower. Due to the reduced node construction cost of intent relay nodes, this method can be considered for many application scenarios, thereby improving the decentralization of intent relay nodes and thus enhancing the security of cross-chain intent execution. Furthermore, after each cross-chain intent event is received, the legality verification of the cross-chain intent event can be quickly completed based on the block header information stored in the light nodes of the blockchain, greatly reducing the resource consumption of verification. Moreover, the verification process is based on the Merkle root in the block header information and the Merkle proof recorded in the full nodes, making it more secure and reliable. Tampered data cannot pass verification, further enhancing the security of cross-chain intent information verification and thus improving the security of cross-chain intent execution.

[0172] Further, please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a data processing device for a blockchain network provided in an embodiment of this application. The data processing device for the blockchain network can be a computer program (including program code) running on a computer device; for example, the data processing device for the blockchain network is an application software. The data processing device for the blockchain network can be used to execute... Figure 3 The method shown. (As illustrated) Figure 7 As shown, the data processing device 1 of the blockchain network may include: an event monitoring module 11, a verification module 12, and a transaction sending module 13.

[0173] Event monitoring module 11 is used to monitor cross-chain intent events on the first blockchain; the cross-chain intent event contains cross-chain intent information, which is used to indicate that the first blockchain and the second blockchain will jointly execute cross-chain transactions, and the cross-chain transactions include a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; the cross-chain intent event also contains the block index information of the first block to which the first transaction belongs on the first blockchain;

[0174] The verification module 12 is used to obtain the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block, and to perform legality verification on the cross-chain intent event based on the block header information of the first block to obtain the legality verification result.

[0175] The transaction sending module 13 is used to send a second transaction to the second blockchain when the legality verification result indicates that the cross-chain intent event is legal, so as to instruct the second blockchain to execute the second transaction.

[0176] The specific implementation methods of the event monitoring module 11, the verification module 12, and the transaction sending module 13 can be found in the above description. Figure 3 The descriptions of steps S301-S303 in the corresponding embodiments will not be repeated here.

[0177] In one embodiment, the block index information of the first block includes the block hash and block height of the first block;

[0178] The specific implementation method of verification module 12 obtaining the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block includes:

[0179] The block hash recorded in the block index information of the first block is determined as the first block hash, and the block height recorded in the block index information of the first block is determined as the target block height;

[0180] Retrieve the second block indicated by the target block height in the first blockchain;

[0181] Obtain the block hash of the second block recorded by the light node of the first blockchain, and determine the block hash of the second block recorded by the light node of the first blockchain as the second block hash;

[0182] Based on the hash of the first block and the hash of the second block, the block index information of the first block is validated to obtain the validity validation result;

[0183] When the validity verification result indicates that the block index information of the first block is valid, the block header information of the second block stored in the light node of the first blockchain is determined as the block header information of the first block.

[0184] In one embodiment, the verification module 12 verifies the validity of the block index information of the first block based on the first block hash and the second block hash, and obtains the validity verification result through a specific implementation method including:

[0185] Compare the hash of the first block with the hash of the second block;

[0186] If the hash of the first block is different from the hash of the second block, the light node in the first blockchain obtains the hash of the second block stored in the full node of the first blockchain, and verifies the validity of the block index information of the first block based on the hash of the first block and the hash of the second block stored in the full node of the first blockchain.

[0187] If the hash of the first block is the same as the hash of the second block, then the validity verification result of the block index information of the first block is determined to be a successful verification result.

[0188] In one embodiment, the verification module 12 obtains the block hash of the second block stored by the full node in the first blockchain through the light node in the first blockchain, including:

[0189] Send a hash query instruction to the light node in the first blockchain; the hash query instruction is used to instruct the light node to query the block hash of the second block stored by each of the N full nodes in the first blockchain; N is a positive integer;

[0190] Receive N third block hashes returned by light nodes in the first blockchain; a third block hash is the block hash of the second block returned by one of the N full nodes to the light nodes in the first blockchain.

[0191] In one embodiment, the specific implementation of the verification module 12 verifying the validity of the block index information of the first block based on the hash of the first block and the block hash of the second block stored by the full nodes in the first blockchain includes:

[0192] Based on the hash content of the N third block hashes, the N third block hashes are grouped to obtain at least one hash group; the hash content of each third block hash contained in a hash group is the same;

[0193] Count the number of hashes of the third block hash contained in each hash group;

[0194] The hash group with the largest number of hashes is identified as the target hash group, and the hash of the third block contained in the target hash group is identified as the correct block hash of the second block.

[0195] If the hash of the first block is the same as the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a successful verification result.

[0196] If the hash of the first block is different from the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a verification failure result.

[0197] In one embodiment, after the verification module 12 determines that the validity verification result of the block index information of the first block is a successful verification result, the verification module further performs the following steps:

[0198] Generate data update instructions based on the correct block hash of the second block;

[0199] The data update command is sent to the light node in the first blockchain. The light node in the first blockchain updates its recorded second block hash to the correct second block hash based on the correct block hash of the second block.

[0200] In one embodiment, the verification module 12 performs legality verification on the cross-chain intent event based on the block header information of the first block, and obtains the legality verification result through a specific implementation method including:

[0201] Send an information retrieval instruction for the first transaction to a light node in the first blockchain; the information retrieval instruction is used to instruct the light node in the first blockchain to retrieve the transaction verification information of the first transaction from at least one full node in the first blockchain.

[0202] Receive at least one transaction verification message for the first transaction returned by a light node in the first blockchain, each transaction verification message being returned by one of the at least one full node;

[0203] Based on the block header information of the first block and at least one transaction verification information, the legality of the cross-chain intent event is verified to obtain the legality verification result.

[0204] In one embodiment, the verification module 12 performs legality verification on the cross-chain intent event based on the block header information of the first block and at least one transaction verification information, and obtains the legality verification result through a specific implementation method including:

[0205] Based on the information content of each transaction verification message in at least one transaction verification message, determine the correct transaction verification message from at least one transaction verification message;

[0206] The block header information of the first block is compared and verified with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event.

[0207] In one embodiment, the verification module 12 determines the specific implementation method of the correct transaction verification information from the at least one transaction verification information based on the information content of each transaction verification information, including:

[0208] Based on the information content of each transaction verification message, at least one transaction verification message is grouped to obtain at least one information group; the information content of the transaction verification messages contained in each information group is the same;

[0209] Count the number of transaction verification information items contained in each information group;

[0210] The information group with the largest amount of information is identified as the target information group, and the transaction verification information contained in the target information group is identified as the correct transaction verification information.

[0211] In one embodiment, the correct transaction verification information includes a Merkel proof for the first transaction;

[0212] The verification module 12 compares the block header information of the first block with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event. The specific implementation method includes:

[0213] Perform a hash calculation on the first transaction to obtain the transaction hash of the first transaction;

[0214] Merkel calculations are performed on the transaction hash of the first transaction and the Merkel proof of the first transaction to obtain the first Merkel root;

[0215] The second Merkle root is obtained from the block header information of the first block, and the first Merkle root is compared with the second Merkle root.

[0216] If the first Merkle root is the same as the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification pass result;

[0217] If the first Merkle root is different from the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification failure result.

[0218] In this application, cross-chain intent nodes do not need to build full nodes on each blockchain; only light nodes are required. Compared to full nodes, light nodes do not need to synchronize complete block information, only block header information. Therefore, the cost of building light nodes is lower. Due to the reduced node construction cost of intent relay nodes, this method can be considered for many application scenarios, thereby improving the decentralization of intent relay nodes and thus enhancing the security of cross-chain intent execution. Furthermore, after each cross-chain intent event is received, the legality verification of the cross-chain intent event can be quickly completed based on the block header information stored in the light nodes of the blockchain, greatly reducing the resource consumption of verification. Moreover, the verification process is based on the Merkle root in the block header information and the Merkle proof recorded in the full nodes, making it more secure and reliable. Tampered data cannot pass verification, further enhancing the security of cross-chain intent information verification and thus improving the security of cross-chain intent execution.

[0219] Further, please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 8As shown, the aforementioned computer device 8000 may include: a processor 8001, a network interface 8004, and a memory 8005. Furthermore, the computer device 8000 also includes: a user interface 8003, and at least one communication bus 8002. The communication bus 8002 is used to enable communication between these components. The user interface 8003 may include a display screen and a keyboard; optionally, the user interface 8003 may also include a standard wired interface or a wireless interface. The network interface 8004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 8005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 8005 may also be at least one storage device located remotely from the aforementioned processor 8001. Figure 8 As shown, the memory 8005, 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.

[0220] exist Figure 8 In the computer device 8000 shown, the network interface 8004 provides network communication functionality; the user interface 8003 is mainly used to provide an input interface for the user; and the processor 8001 can be used to call the device control application program stored in the memory 8005 to achieve:

[0221] Monitor cross-chain intent events on the first blockchain; cross-chain intent events contain cross-chain intent information, which is used to instruct the first blockchain and the second blockchain to jointly execute cross-chain transactions. Cross-chain transactions include a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; cross-chain intent events also contain block index information of the first block to which the first transaction belongs on the first blockchain;

[0222] Based on the block index information of the first block, the block header information of the first block is obtained from the light nodes of the first blockchain, and the legality of the cross-chain intent event is verified according to the block header information of the first block to obtain the legality verification result.

[0223] When the legitimacy verification result indicates that the cross-chain intent event is legitimate, a second transaction is sent to the second blockchain to instruct the second blockchain to execute the second transaction.

[0224] It should be understood that the computer device 8000 described in the embodiments of this application can execute the foregoing text. Figures 3 to 6 The description of the data processing method for the blockchain network in the corresponding embodiments can also be performed as described above. Figure 7The description of the data processing device 1 for the blockchain network in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0225] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing computer device 8000. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figures 3 to 6 The description of the data processing method for the blockchain network in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

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

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

[0228] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

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

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

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

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

Claims

1. A data processing method for a blockchain network, characterized in that, The blockchain network comprises a first blockchain, a second blockchain, and an intent relay node. The method is executed by the intent relay node and includes: Monitor cross-chain intent events on the first blockchain; the cross-chain intent events contain cross-chain intent information, which is used to indicate that the first blockchain and the second blockchain will jointly execute cross-chain transactions, the cross-chain transactions include a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; the cross-chain intent events also contain block index information of the first block to which the first transaction belongs on the first blockchain; Based on the block index information of the first block, the block header information of the first block is obtained from the light nodes of the first blockchain, and the legality of the cross-chain intent event is verified according to the block header information of the first block to obtain the legality verification result. When the legitimacy verification result indicates that the cross-chain intent event is legitimate, the second transaction is sent to the second blockchain to instruct the second blockchain to execute the second transaction.

2. The method according to claim 1, characterized in that, The block index information of the first block includes the block hash and block height of the first block; The step of obtaining the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block includes: The block hash recorded in the block index information of the first block is determined as the first block hash, and the block height recorded in the block index information of the first block is determined as the target block height. Obtain the second block indicated by the target block height in the first blockchain; Obtain the block hash of the second block recorded by the light node of the first blockchain, and determine the block hash of the second block recorded by the light node of the first blockchain as the second block hash; Based on the first block hash and the second block hash, the block index information of the first block is validated to obtain the validity validation result; When the validity verification result indicates that the block index information of the first block is valid, the block header information of the second block stored in the light node of the first blockchain is determined as the block header information of the first block.

3. The method according to claim 2, characterized in that, The step of validating the block index information of the first block based on the first block hash and the second block hash to obtain a validity verification result includes: Compare the hash of the first block with the hash of the second block; If the first block hash is different from the second block hash, then the light node in the first blockchain obtains the block hash of the second block stored in the full node of the first blockchain, and verifies the validity of the block index information of the first block based on the first block hash and the block hash of the second block stored in the full node of the first blockchain. If the first block hash is the same as the second block hash, then the validity verification result of the block index information of the first block is determined to be a successful verification result.

4. The method according to claim 3, characterized in that, The step of obtaining the block hash of the second block stored by the full node in the first blockchain through the light node in the first blockchain includes: Send a hash query instruction to the light node in the first blockchain; the hash query instruction is used to instruct the light node to query the block hash of the second block stored by each of the N full nodes in the first blockchain; N is a positive integer; Receive N third block hashes returned by the light nodes in the first blockchain; each third block hash is the block hash of the second block returned by one of the N full nodes to the light nodes in the first blockchain.

5. The method according to claim 4, characterized in that, Based on the hash of the first block and the hash of the second block stored by the full nodes in the first blockchain, the validity of the block index information of the first block is verified, including: Based on the hash content of the N third block hashes, the N third block hashes are grouped to obtain at least one hash group; the hash content of each third block hash contained in a hash group is the same; Count the number of hashes of the third block hash contained in each of the hash groups; The hash group with the largest number of hashes is determined as the target hash group, and the third block hash contained in the target hash group is determined as the correct block hash of the second block; If the hash of the first block is the same as the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a successful verification result. If the hash of the first block is different from the correct hash of the second block, then the validity verification result of the block index information of the first block is determined to be a verification failure result.

6. The method according to claim 5, characterized in that, After determining that the validity verification result of the block index information of the first block is a successful verification result, the method further includes: Based on the correct block hash of the second block, generate a data update instruction; The data update instruction is sent to a light node in the first blockchain, and the light node in the first blockchain updates its recorded second block hash to the correct block hash of the second block based on the correct block hash of the second block.

7. The method according to claim 1, characterized in that, The step of verifying the legitimacy of the cross-chain intent event based on the block header information of the first block to obtain a legitimacy verification result includes: Send an information retrieval instruction for the first transaction to a light node in the first blockchain; the information retrieval instruction is used to instruct the light node in the first blockchain to retrieve transaction verification information of the first transaction from at least one full node in the first blockchain; Receive at least one transaction verification message for the first transaction returned by a light node in the first blockchain, wherein each transaction verification message is returned by one of the at least one full nodes; Based on the block header information of the first block and the at least one transaction verification information, the legality of the cross-chain intent event is verified to obtain a legality verification result.

8. The method according to claim 7, characterized in that, The legality verification of the cross-chain intent event is performed based on the block header information of the first block and the at least one transaction verification information to obtain a legality verification result, including: Based on the information content of each of the at least one transaction verification information, the correct transaction verification information is determined from the at least one transaction verification information; The block header information of the first block is compared and detected with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event.

9. The method according to claim 8, characterized in that, The step of determining the correct transaction verification information from the at least one transaction verification information based on the information content of each of the at least one transaction verification information includes: Based on the information content of each transaction verification information, the at least one transaction verification information is grouped to obtain at least one information group; the information content of the transaction verification information contained in each information group is the same; Count the number of transaction verification information items contained in each of the aforementioned information groups; The information group with the largest amount of information is identified as the target information group, and the transaction verification information contained in the target information group is identified as the correct transaction verification information.

10. The method according to claim 8, characterized in that, The correct transaction verification information includes a Merkel proof for the first transaction; The block header information of the first block is compared and checked with the correct transaction verification information to obtain the legality verification result of the cross-chain intent event, including: Perform a hash calculation on the first transaction to obtain the transaction hash of the first transaction; Merkel calculations are performed on the transaction hash of the first transaction and the Merkel proof of the first transaction to obtain the first Merkel root; Obtain the second Merkle root from the block header information of the first block, and compare the first Merkle root with the second Merkle root; If the first Merkle root is the same as the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification pass result; If the first Merkle root is different from the second Merkle root, then the legality verification result of the cross-chain intent event is determined to be a verification failure result.

11. A data processing device for a blockchain network, characterized in that, The blockchain network includes a first blockchain, a second blockchain, and an intent relay node. The device is applied to the intent relay node, and the device includes: An event monitoring module is used to monitor cross-chain intent events on the first blockchain; the cross-chain intent event contains cross-chain intent information, which is used to indicate that the first blockchain and the second blockchain will jointly execute a cross-chain transaction, the cross-chain transaction includes a first transaction executed on the first blockchain and a second transaction executed on the second blockchain; the cross-chain intent event also contains the block index information of the first block to which the first transaction belongs on the first blockchain; The verification module is used to obtain the block header information of the first block from the light nodes of the first blockchain based on the block index information of the first block, and to perform legality verification on the cross-chain intent event based on the block header information of the first block to obtain a legality verification result. The transaction sending module is used to send the second transaction to the second blockchain when the legality verification result indicates that the cross-chain intent event is legal, so as to instruct the second blockchain to execute the second transaction.

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

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-10.

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

Images