Data processing method and device based on alliance chain, equipment and readable storage medium

Abstract

This application discloses a data processing method, apparatus, device, and readable storage medium based on a consortium blockchain. The method includes: obtaining first intent data from the intent pool of the source blockchain; executing the first intent data through an intent settlement contract; when the first intent data is detected to be a cross-chain intent for the target blockchain, and the execution of the first intent is successful, generating event information that can be stored in the source blockchain based on the first intent data; broadcasting the event information to the consortium blockchain through the intent settlement contract; if a relay node detects that the event information reception has failed, receiving an event acquisition request sent by the relay node, rebroadcasting the event information based on the block information carried in the event acquisition request, so that when the relay node successfully verifies the event information, generating a relay transaction for sending to the target blockchain based on the event information. This ensures the smooth progress of the entire cross-chain intent process, reducing the risk of asset loss in the transaction.

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 based on a consortium blockchain. Background Technology

[0002] Users can send requests containing intents to the source blockchain. Blockchain nodes on the source blockchain can execute the intents, locking the transaction assets on the source blockchain upon successful execution and sending asset lock information to the target blockchain. The target blockchain then uses this lock information to perform the corresponding asset issuance operation. However, if the asset lock information is lost during transmission, the target blockchain will not receive the lock information and will not perform the asset issuance operation. However, the transaction assets on the source blockchain will still be locked, causing an error in the cross-chain transaction process and potentially leading to asset loss. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and readable storage medium for consortium blockchains, which can ensure the smooth progress of the entire intended cross-chain process, thereby reducing the risk of asset loss in the transaction assets of the target.

[0004] This application provides a data processing method based on a consortium blockchain, wherein the consortium blockchain includes a source blockchain, a target blockchain, and relay nodes, and the method is executed by blockchain nodes in the source blockchain; including:

[0005] Obtain the first intent data from the intent pool of the source blockchain, and execute the first intent data through the intent settlement contract;

[0006] When the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent is successful, second intent data is generated based on the first intent data and the execution result corresponding to the first intent data. The second intent data is encapsulated into event information that can be stored in the source blockchain. The event information carries the block information of the block containing the first intent data.

[0007] Broadcast event information to the consortium blockchain via the intent settlement contract;

[0008] If a relay node detects that the event information reception has failed, it receives the event retrieval request sent by the relay node and rebroadcasts the event information based on the block information carried in the event retrieval request. This allows the relay node to package the second intent data in the event information to obtain a relay transaction when it successfully obtains and verifies the event information. The relay node then forwards the relay transaction to the target blockchain.

[0009] This also includes:

[0010] When the first intent data is detected as a single-chain intent targeting the source blockchain, the status of the account associated with the first intent data is updated based on the execution result of the first intent data.

[0011] This also includes:

[0012] When the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent data fails, the failure execution result of the first intent data is returned to the business system.

[0013] Specifically, second intent data is generated based on the first intent data and the corresponding execution result. This second intent data is then encapsulated into event information that can be stored in the source blockchain, including:

[0014] The intent sequence number, intent cross-chain path, and intent signature corresponding to the first intent data are obtained through the intent settlement contract. The intent sequence number is used to characterize the uniqueness of the first intent data. The intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain. The intent signature is obtained by digitally signing the first intent data based on the private key of the target object. The target object refers to the object that initiates the business request containing the first intent data.

[0015] The second intent data is generated based on the first intent data, the intent random number, the intent cross-chain path, the intent signature, and the execution result corresponding to the first intent data.

[0016] The first intent data and the second intent data are encapsulated to obtain event information that can be stored in the source blockchain.

[0017] This application provides another data processing method based on a consortium blockchain, wherein the consortium blockchain includes a source blockchain, a target blockchain, and relay nodes, and the method is executed by the relay nodes; including:

[0018] If event information reception failure is detected, an event retrieval request is sent to the blockchain nodes in the source blockchain, so that the blockchain nodes in the source blockchain rebroadcast the event information based on the block information carried in the event retrieval request; the event information is information encapsulated based on the second intent data and can be stored in the source blockchain, and the event information carries the block information of the block containing the first intent data; the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the first intent data is a cross-chain intent for the target blockchain;

[0019] The event information is verified to obtain the event verification result. When the event verification result is a successful verification result, the second intent data is packaged to obtain the relay transaction.

[0020] Relay transactions are forwarded to the target blockchain.

[0021] The process involves verifying the event information to obtain the event verification results, including:

[0022] The first intent data is deserialized for verification to obtain deserialized data;

[0023] Compare the deserialized data with the first intent data;

[0024] If the deserialized data is the same as the first intent data, then the event verification result is determined to be a successful verification result;

[0025] If the deserialized data is different from the first intent data, the event verification result is determined to be a verification failure result, and the deserialization verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0026] The process involves verifying the event information to obtain the event verification results, including:

[0027] Based on the highest block height corresponding to the processed events, the block height in the block information is verified to ensure continuity, and the block verification result is obtained.

[0028] The intent signature of the first intent data in the event information is verified based on the public key of the target object to obtain the signature verification result; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, and the target object refers to the object that initiates the business request containing the first intent data;

[0029] Perform data format validation on the intent field of the first intent data in the event information to obtain the field validation result;

[0030] The block verification result, signature verification result, and field verification result are determined as the event verification result for the event information.

[0031] The process involves verifying the event information to obtain the event verification results, including:

[0032] Obtain the data resource consumption transition status from the event information for the first intent data;

[0033] If the transfer status is "resource transferred", then the event verification result is determined to be a successful verification result.

[0034] If the transfer status is "resource not transferred", then the event verification result is determined to be a verification failure result. The verification failure result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0035] One embodiment of this application provides a data processing device based on a consortium blockchain, comprising:

[0036] The send / receive module is used to obtain the first intent data from the intent pool of the source blockchain and execute the first intent data through the intent settlement contract;

[0037] The event generation module is used to generate second intent data based on the first intent data and the execution result corresponding to the first intent data when it is detected that the first intent data is a cross-chain intent for the target blockchain and the first intent is successfully executed. The second intent data is encapsulated into event information that can be stored in the source blockchain. The event information carries the block information of the block containing the first intent data.

[0038] The event broadcasting module is used to broadcast event information to the consortium blockchain through the intent settlement contract;

[0039] The transaction generation module is used to receive the event acquisition request sent by the relay node if the relay node detects that the event information reception has failed. Based on the block information carried in the event acquisition request, the module rebroadcasts the event information so that when the relay node obtains the event information and successfully verifies the event information, it packages the second intent data in the event information to obtain a relay transaction. The relay node is used to forward the relay transaction to the target blockchain.

[0040] In one possible implementation, the event generation module is also used to perform the following operations:

[0041] When the first intent data is detected as a single-chain intent targeting the source blockchain, the status of the account associated with the first intent data is updated based on the execution result of the first intent data.

[0042] In one possible implementation, the event generation module is also used to perform the following operations:

[0043] When the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent data fails, the failure execution result of the first intent data is returned to the business system.

[0044] In one possible implementation, the event generation module is used to generate second intent data based on the first intent data and the execution result corresponding to the first intent data. When encapsulating the second intent data into event information that can be stored in the source blockchain, it is specifically used to perform the following operations:

[0045] The intent sequence number, intent cross-chain path, and intent signature corresponding to the first intent data are obtained through the intent settlement contract. The intent sequence number is used to characterize the uniqueness of the first intent data. The intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain. The intent signature is obtained by digitally signing the first intent data based on the private key of the target object. The target object refers to the object that initiates the business request containing the first intent data.

[0046] The second intent data is generated based on the first intent data, the intent random number, the intent cross-chain path, the intent signature, and the execution result corresponding to the first intent data.

[0047] The first intent data and the second intent data are encapsulated to obtain event information that can be stored in the source blockchain.

[0048] This application provides another data processing device based on a consortium blockchain, including:

[0049] The event acquisition module is used to send an event acquisition request to the blockchain nodes in the source blockchain if the event information reception failure is detected, so that the blockchain nodes in the source blockchain can rebroadcast the event information based on the block information carried in the event acquisition request; the event information is information encapsulated based on the second intent data and can be stored in the source blockchain, and the event information carries the block information of the block containing the first intent data; the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the first intent data is a cross-chain intent for the target blockchain;

[0050] The event verification module is used to verify event information and obtain event verification results. When the event verification result is a successful verification result, the second intent data is packaged to obtain the relay transaction.

[0051] The transaction forwarding module is used to forward relay transactions to the target blockchain.

[0052] In one possible implementation, the event verification module is used to verify event information. When the event verification result is obtained, it is specifically used to perform the following operations:

[0053] The first intent data is deserialized for verification to obtain deserialized data;

[0054] Compare the deserialized data with the first intent data;

[0055] If the deserialized data is the same as the first intent data, then the event verification result is determined to be a successful verification result;

[0056] If the deserialized data is different from the first intent data, the event verification result is determined to be a verification failure result, and the deserialization verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0057] In one possible implementation, the event verification module is used to verify event information. When the event verification result is obtained, it is specifically used to perform the following operations:

[0058] Based on the highest block height corresponding to the processed events, the block height in the block information is verified to ensure continuity, and the block verification result is obtained.

[0059] The intent signature of the first intent data in the event information is verified based on the public key of the target object to obtain the signature verification result; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, and the target object refers to the object that initiates the business request containing the first intent data;

[0060] Perform data format validation on the intent field of the first intent data in the event information to obtain the field validation result;

[0061] The block verification result, signature verification result, and field verification result are determined as the event verification result for the event information.

[0062] In one possible implementation, the event verification module is used to verify event information. When the event verification result is obtained, it is specifically used to perform the following operations:

[0063] Obtain the data resource consumption transition status from the event information for the first intent data;

[0064] If the transfer status is "resource transferred", then the event verification result is determined to be a successful verification result.

[0065] If the transfer status is "resource not transferred", then the event verification result is determined to be a verification failure result. The verification failure result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

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

[0067] The processor is connected to a memory and a network interface. The network interface is used to provide data communication functions, and the memory is used to store computer programs. When the computer program is executed by the processor, the computer device performs the method provided in the embodiments of this application.

[0068] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0069] One embodiment 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 this application embodiment.

[0070] In this embodiment, the blockchain node can obtain first intent data from the intent pool of the source blockchain, and then execute the first intent data through an intent settlement contract. When the first intent data is detected to be a cross-chain intent for the target blockchain, and the execution of the first intent is successful, second intent data can be generated based on the first intent data and the corresponding execution result. The second intent data is then encapsulated into event information that can be stored in the source blockchain (the event information carries block information of the block containing the first intent data), and then broadcast to the consortium blockchain through the intent settlement contract. If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node, and rebroadcasts the event information based on the block information carried in the event acquisition request. This allows the relay node to package the second intent data in the event information when it acquires and successfully verifies the event information, thus obtaining a relay transaction. The relay node is used to forward the relay transaction to the target blockchain. Since event information can be persistently stored on the source blockchain, and relay nodes can continue to send event retrieval requests to blockchain nodes when they detect event information reception failure, thereby obtaining the event information rebroadcast by the blockchain nodes, as long as the source blockchain can successfully execute the intent data, the relay node can ensure that it can package a relay transaction containing the intent data when it successfully verifies the corresponding event information. Therefore, it can be guaranteed that the target blockchain can successfully execute the intent data through the relay transaction sent by the relay node. That is, even if the event information reception fails, the entire cross-chain intent process can still be guaranteed to proceed smoothly, thereby reducing the risk of asset loss in the target's transaction assets. Attached Figure Description

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

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

[0073] Figure 2 This is a schematic diagram illustrating a data processing method based on a consortium blockchain provided in an embodiment of this application.

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

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

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

[0077] Figure 6 This is a schematic diagram of the structure of a data processing device based on a consortium blockchain provided in an embodiment of this application. Figure 1 ;

[0078] Figure 7 This is a schematic diagram of the structure of a data processing device based on a consortium blockchain provided in an embodiment of this application. Figure 2 ;

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

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

[0081] It is understood that, in the specific embodiments of this application, the user data involved requires user permission or consent when the following embodiments of this application are applied to specific products or technologies, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions.

[0082] If this application requires the collection of object data (such as user data), a prompt interface or pop-up window will be displayed before and during the collection process. This prompt interface or pop-up window is used to inform the user that certain data is being collected. The data acquisition steps will only begin after the user confirms the prompt interface or pop-up window; otherwise, the process will end. Furthermore, the acquired user data will be used in reasonable and legal scenarios or for legitimate purposes. Optionally, in scenarios where user data needs to be used but user authorization has not been obtained, authorization can be requested from the user, and the user data can only be used after authorization is granted.

[0083] This application relates to blockchain technology, and the specific embodiments are illustrated below.

[0084] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores the same blockchain. The blockchain network can distinguish between consensus nodes and business nodes, with the consensus node responsible for achieving consensus across the entire network. The process of writing transaction data into the ledger in a blockchain network can be described as follows: a resource client sends transaction data to a business node, which then relays this data among the business nodes in the blockchain network until the consensus node receives it. The consensus node then packages the transaction data into a block and reaches a consensus with other consensus nodes. After consensus is reached, the block containing the transaction data is written into the ledger.

[0085] Consortium chain: A consortium chain is a type of blockchain jointly managed by multiple organizations or institutions, where nodes need to be authorized to join. Its core feature is the combination of partial decentralization and access control mechanisms, which retains the transparency and security of blockchain while meeting enterprise-level collaboration needs through hierarchical permission systems, privacy protection, and efficient consensus mechanisms.

[0086] Intent: An intent is an abstraction of on-chain behavior (such as asset transactions or messaging), allowing objects to outsource transaction creation to third parties without giving full control to the transacting parties, while retaining control over assets and permissions. The lifecycle of an intent covers stages such as submission, path solving, bundling and packaging, and on-chain verification. Off-chain submission mechanisms based on intents can effectively reduce the barrier to entry for objects.

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

[0088] Hash value: Also known as information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output through a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash value of its predecessor block, which is called the parent block of the current block. The hash value is a core and crucial aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0089] Broadcast mechanism: This refers to the process by which blockchain nodes propagate information (such as transactions and blocks) throughout the entire network via peer-to-peer network protocols. When a blockchain node generates a new transaction or block, it sends this information to other blockchain nodes directly connected to it. These nodes then forward the information, and so on, propagating it level by level until all blockchain nodes in the entire blockchain network have received the information. The broadcast mechanism ensures that data in the blockchain network can be propagated quickly and efficiently, while maintaining the network's decentralized nature and consistency.

[0090] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. For example... Figure 1As shown, this network architecture can be a consortium blockchain. A consortium blockchain can contain multiple blockchains from different organizations, such as blockchain 100, blockchain 200, and blockchain 300, and can also include relay nodes 400 for forwarding transaction data. Since there are network gaps between the blockchains, relay nodes 400 can be used for interaction between different blockchains, and the consensus algorithms used by different blockchains can be the same or different. Furthermore, all blockchains can act as source or target blockchains, and all blockchains can contain multiple blockchain nodes; for example, blockchain 100 can contain blockchain node 10a.

[0091] Please see also Figure 2 , Figure 2 This is a schematic diagram illustrating a data processing method based on a consortium blockchain provided in an embodiment of this application. For example... Figure 2 As shown, a consortium blockchain can include a source blockchain, a target blockchain, and relay nodes. The source blockchain can be... Figure 1 The blockchain in the source blockchain can be blockchain100, while the blockchain nodes in the source blockchain can be Figure 1 Blockchain node 10a in the middle, the target blockchain can be Figure 1 In Blockchain 200, both the source and target blockchains can contain intent pools for storing multiple intent data, and relay nodes can be... Figure 1 The relay node is 400.

[0092] like Figure 2 As shown, the intent data of the target object can be stored in the intent pool of the source blockchain 100. Blockchain node 10a can obtain the first intent data from the intent pool and execute the first intent data through the intent settlement contract in the source blockchain 100 to obtain the execution result of the first intent data. For example, for a transfer of the target object, the account balance of the target object can be deducted through the intent settlement contract to obtain the execution result of successful deduction.

[0093] Blockchain node 10a can also detect the first intent data. For example, if it detects that the first intent data is a cross-chain intent for the target blockchain 200, and the intent settlement contract is successfully executed for the first intent data, it can synchronously obtain the relevant data corresponding to the first intent data, such as the intent sequence number used to characterize the uniqueness of the first intent data. Then, based on the relevant data, the first intent data and its corresponding execution result, second intent data is generated. The first intent data and the second intent data are then encapsulated to obtain event information that can be stored in the source blockchain 100. That is, the event information can be stored in the block containing the first intent data.

[0094] Blockchain node 10a can broadcast event information to the consortium blockchain through the intent settlement contract. Relay node 400 will continuously monitor the reception of event information. When it detects that the event information reception has failed, it can send an event retrieval request to blockchain node 10a of the source blockchain 100. Since the event information carries block information of the block containing the first intent data, blockchain node 10a can rebroadcast the event information according to the block information carried in the event retrieval request. Thus, relay node 400 can verify the received event information and obtain the event verification result. For example, it can verify the transfer status of the data consumption resources for the first intent data in the event information. When the transfer status is that the resources have been transferred, the event verification result can be determined to be a successful verification result. Then, the second intent data in the event information is packaged to obtain a relay transaction, and then the relay transaction is forwarded to the target blockchain 200.

[0095] After parsing the second intent data in the relay transaction, blockchain node 10a in target blockchain 200 can verify the execution result of the first intent data within the second intent data through the intent settlement contract. Upon successful verification, the first intent data will be executed, thereby achieving intent synchronization between source blockchain 100 and target blockchain 200 regarding the first intent data. For example, for transfer data, if blockchain node 10a in target blockchain 200 determines through the intent settlement contract that the target object's account balance has been correctly deducted, it can then deliver the corresponding assets to the recipient's account balance, thus completing the intent synchronization of the transfer data. Intent synchronization refers to the process of securely and accurately transmitting intent data from source blockchain 100 to target blockchain 200 in cross-chain communication, ensuring that operations on target blockchain 200 are consistent with those on source blockchain 100.

[0096] It is understood that the blockchain node in this embodiment can obtain first intent data from the intent pool of the source blockchain, and then execute the first intent data through the intent settlement contract. When it is detected that the first intent data is a cross-chain intent for the target blockchain, and the execution of the first intent is successful, second intent data can be generated based on the first intent data and the corresponding execution result. The second intent data is then encapsulated into event information that can be stored in the source blockchain (the event information carries block information of the block containing the first intent data), and then broadcast to the consortium blockchain through the intent settlement contract. If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node, and rebroadcasts the event information based on the block information carried in the event acquisition request. This allows the relay node to package the second intent data in the event information when it acquires the event information and successfully verifies it, thus obtaining a relay transaction. The relay node is used to forward the relay transaction to the target blockchain. Since event information can be persistently stored on the source blockchain, and relay nodes can continue to send event retrieval requests to blockchain nodes when they detect event information reception failure, thereby obtaining the event information rebroadcast by the blockchain nodes, as long as the source blockchain can successfully execute the intent data, the relay node can ensure that it can package a relay transaction containing the intent data when it successfully verifies the corresponding event information. Therefore, it can be guaranteed that the target blockchain can successfully execute the intent data through the relay transaction sent by the relay node. That is, even if the event information reception fails, the entire cross-chain intent process can still be guaranteed to proceed smoothly, thereby reducing the risk of asset loss in the target's transaction assets.

[0097] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method based on a consortium blockchain provided in an embodiment of this application. Figure 1 This data processing method can be executed by blockchain nodes, which can be, for example,... Figure 1 The blockchain node 10a is shown. The following explanation will use the execution of this data processing method by a blockchain node as an example. This data processing method will at least include the following steps S101-S104:

[0098] Step S101: Obtain the first intent data from the intent pool of the source blockchain and execute the first intent data through the intent settlement contract;

[0099] Specifically, a consortium blockchain can include a source blockchain, a target blockchain, and relay nodes. All blockchains can contain multiple blockchain nodes. This embodiment uses the blockchain nodes in the source blockchain as the executing entity. Blockchain nodes can obtain first intent data from the intent pool of the source blockchain. For example, the target object can declare intent data in its business software and then submit the intent data to the intent pool of the source blockchain in a standardized format (such as JSON). Blockchain nodes can establish a secure connection with the data source in the intent pool of the source blockchain through an encrypted channel built on the TLS (Transport Layer Security) protocol, thereby obtaining the first intent data from the intent pool.

[0100] The Intent Pool is a dedicated data structure within the blockchain network used to store and distribute user transaction intentions. Essentially, it's a temporary storage area within the blockchain network used to hold intention data that hasn't yet been packaged into blocks. It allows users to express their goals declaratively (e.g., "exchange and buy at the best price") without having to directly write complex transaction logic. By decoupling user intentions from the underlying execution logic, the Intent Pool simplifies the complexity of blockchain interactions while supporting solvers to competitively provide optimal execution solutions (such as cross-chain paths or liquidity aggregation). This mechanism not only enhances the user experience but also provides flexible and efficient solutions for scenarios such as cross-chain operations, business transactions, and off-chain service triggering.

[0101] The TLS protocol protects network communication from security threats such as tampering and man-in-the-middle attacks by encrypting data transmission, verifying the identities of communicating parties, and ensuring data integrity and confidentiality. This protocol improves connection speed by reducing the number of message exchanges during the handshake process, enforces forward secrecy to enhance security, and removes some known insecure encryption algorithms, such as SHA-1 (Secure Hash Algorithm 1). For example, a blockchain node and an intent pool first mutually verify each other's digital certificates based on the TLS protocol. During the TLS handshake, the blockchain node and the intent pool exchange digital certificates and negotiate a session key using an asymmetric encryption algorithm (such as RSA). After the handshake is complete, the two parties establish an encrypted channel based on the negotiated session key. Transmitting intent data through an encrypted channel better guarantees the security of intent data, thereby reducing the risk of asset loss in the transaction.

[0102] Blockchain nodes can execute first-intent data through intent settlement contracts in the source blockchain. For example, contract code can be built based on business rules (such as settlement rules), and then integrated and verified in the source blockchain to obtain an effective intent settlement contract. The intent settlement contract performs conditional verification on the first-intent data, such as verifying whether the first-intent data is within its validity period, whether the data format of the first-intent data is compliant, etc. After verification, the intent settlement contract finds the optimal execution path, and completes all operations on the first-intent data according to the execution path (such as deducting the account balance corresponding to the first-intent data if the first-intent data is parsed as transfer data). If multi-step operations are involved (such as cross-chain exchange), HTLC (Hashed Timelock Contract) can be used to ensure that all operations are executed successfully, thereby updating the on-chain state of the source blockchain (such as adjusting the account balance), and recording the execution results of the first-intent data through logs and other means.

[0103] Step S102: When the first intent data is detected to be a cross-chain intent for the target blockchain and the execution of the first intent is successful, the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the second intent data is encapsulated into event information that can be stored in the source blockchain.

[0104] For details, please refer to the following: Figure 4 , Figure 4 This is a flowchart illustrating a data processing method based on a consortium blockchain provided in an embodiment of this application. Figure 2 ,like Figure 4 As shown, blockchain nodes can perform cross-chain detection on the first intent data through routing protocols and other methods to determine its type (single-chain or cross-chain). For example, they can detect whether the first intent data contains a cross-chain protocol identifier. If the first intent data contains the target blockchain address (such as the smart contract address of another blockchain), cross-chain routing parameters (such as cross-chain path information), or cross-chain asset mapping identifier, then the first intent data can be determined to be a cross-chain intent. Alternatively, they can parse the contract function type contained in the first intent data. If it contains a hash timelock contract, that is, it contains a preset hash value and timelock, then the first intent data can be determined to be a cross-chain intent. Blockchain nodes can also determine this through inter-chain interaction protocols or transaction paths, which are not limited here.

[0105] Hash Time Lock Contracts (HTLCs) are a decentralized smart contract mechanism that combines hash locks and time locks to achieve secure, trustless conditional payment functionality. The core of HTLCs lies in ensuring the security and atomicity of transactions through hash verification and time constraints, and they are widely used in scenarios such as cross-chain transactions, decentralized exchanges, and micropayment channels. For example, in cross-chain transactions, HTLCs can enable asset exchange between different blockchains without centralized intermediaries, thereby improving transaction efficiency and security.

[0106] If the first intent data is detected as a single-chain intent targeting the source blockchain, the status of the account associated with the first intent data is updated based on the execution result of the first intent data. For example, after executing the first intent data on the source blockchain, the blockchain node can parse the execution result. If the execution of the first intent data is successful, the status field (such as status) of the associated account is updated to "completed" or "successful," and the relevant data of the execution result (such as hash value and timestamp) is written to the storage space corresponding to the associated account. If the first intent data involves asset transfers such as fund transfers, the locked assets are deducted, and the execution summary (such as time, data source, and operation type) can be broadcast to the consortium blockchain for other business application front-ends or other intent settlement contracts to detect and synchronously display the status.

[0107] If the execution of the first intent data fails, the status of the associated account is updated according to the error type. For example, ERROR_DATA_UNAVAILABLE indicates that the first intent data is faulty. In the case of locked assets, the blockchain node can unlock the assets of the associated account and roll back the block containing the first intent data (including returning the data resources consumed by the first intent data).

[0108] If the first intent data is detected as a cross-chain intent targeting the target blockchain, and execution of the first intent data fails, the failure result can be returned to the business system. For example, based on Webhook notifications, the failure result can be pushed to the business system via a pre-registered API (Application Programming Interface) endpoint using an HTTPS (Hypertext Transfer Protocol Secure) request. This allows the business system to atomically record the failure event and its callback confirmation, simultaneously verifying the first intent data to prevent tampering. Webhook notifications are a lightweight communication mechanism that allows applications to proactively push information to designated recipients when specific events occur. Webhook uses a "push" model; when an event is triggered, the system automatically sends data to a preset URL (Uniform Resource Locator) address, achieving immediate and efficient event notification.

[0109] API endpoints serve as a "bridge" for interaction between software and systems. Through predefined rules and protocols, they enable different programs or services to securely and efficiently share functionality and data without exposing underlying implementation details. For example, when viewing a map, developers don't need to write geolocation algorithms; they can simply call the Google Maps API. APIs cover a wide range of technical scenarios: such as operating system file resources (e.g., the Windows API managing file resources) and modern web services (e.g., transmitting JSON data via HTTP). This abstract design allows developers to quickly integrate third-party capabilities, driving software modularization, cross-platform collaboration, and technological innovation.

[0110] HTTPS requests are a secure communication method based on the HTTP protocol. It adds an SSL (Secure Sockets Layer) or TLS encryption layer on top of HTTP to ensure that data is not tampered with during transmission between the client and server. When a user initiates an HTTPS request, the client and server first perform an SSL / TLS handshake to negotiate the encryption algorithm and key. Subsequent data transmission is then encrypted, protecting user privacy and data security. It is widely used in e-commerce and other scenarios with high security requirements.

[0111] If the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent data is successful through the intent settlement contract, second intent data is generated based on the first intent data and the corresponding execution result. The second intent data is then encapsulated into event information that can be stored in the source blockchain. The specific process can be as follows: obtain the intent sequence number, intent cross-chain path, and intent signature corresponding to the first intent data through the intent settlement contract; the intent sequence number is used to characterize the uniqueness of the first intent data; the intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, where the target object refers to the object that initiates the business request containing the first intent data; generate the second intent data based on the first intent data, intent sequence number, intent cross-chain path, intent signature, and the corresponding execution result; encapsulate the first and second intent data to obtain event information that can be stored in the source blockchain.

[0112] The intent sequence number is the number of a specific intent data initiated by the target object. It is used to characterize the uniqueness of the intent data. That is, the first intent data is assigned an independent sequence number when it is generated, so that it can be distinguished from other intent data. Blockchain nodes can query the execution progress of the first intent data through the intent sequence number of the first intent data.

[0113] The intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain. The intent cross-chain path of the first intent data can include cross-chain routing and execution logic. It can be implemented through chain signature technology, which allows the target object to sign operations on a source blockchain, and the blockchain nodes of the target blockchain obtain and execute the first intent data according to the intent cross-chain path.

[0114] The intent signature is obtained by digitally signing the first intent data based on the private key of the target object. For example, the first intent data can be signed using the SHA256 with RSA algorithm. The computer device first calculates the first intent data based on the SHA-256 algorithm (Secure Hash Algorithm 256, 256-bit hash algorithm) to obtain the first hash value, and then encrypts the first hash value according to the secure private key in the RSA algorithm to obtain the intent signature. The encryption process can be shown in formula (1):

[0115] signature = (hash_value) d mod n formula (1)

[0116] In this context, `signature` represents the field generated by the signature, i.e., the intent signature; `hash_value` represents the first hash value; `d` represents the private key exponent, which can be part of the secure private key and is used in the exponentiation operation during the signature encryption process; and `n` represents a large modulus, usually obtained by multiplying two large prime numbers, and is shared by both the private and public keys. The value of the `signature` field, i.e., the intent signature, is obtained by taking the remainder of the power obtained by raising the first hash value to the power of the private key exponent `d` and dividing it by the modulus `n`. To ensure the security of the intent signature, the private key exponent `d` and the modulus `n` are usually set to large values, and since the RSA key length is typically at least 2048 bits, the private key exponent (`d`) and the public key exponent (`e`) can also be large numbers of corresponding lengths.

[0117] Blockchain nodes can generate second intent data based on first intent data, intent sequence number, intent cross-chain path, intent signature, and the execution result corresponding to the first intent data. For example, the second intent data can be obtained by concatenating the fields of the first intent data, intent sequence number, intent cross-chain path, intent signature, and the execution result corresponding to the first intent data, as shown in Table 1.

[0118] Table 1

[0119]

[0120] For example, given that the intent sequence number corresponding to the first intent data V is 1.1, the intent cross-chain path for the first intent data V to cross between the source blockchain and the target blockchain is L1-L2, the first intent data V is digitally signed based on the private key of the target object U to obtain the intent signature R, and the execution result of the first intent data V is UV1, then the first intent data V, the intent sequence number 1.1, the intent cross-chain path L1-L2, the intent signature R, and the execution result UV1 corresponding to the first intent data can be concatenated to obtain the second intent data (V|1.1|L1-L2|R|UV1).

[0121] Blockchain nodes can also synchronously parse the execution results of the first intent data through the intent settlement contract, obtaining execution information such as execution status, transaction hash, and timestamp. Based on this execution information and the real-time state of the source blockchain (such as congestion), they can plan cross-chain paths and select routing protocols to ensure that the second intent data can be compliantly forwarded by relay nodes. Routing protocols are a set of rules and algorithms used in computer networks to determine data transmission paths. They allow network devices (such as routers) to dynamically select the optimal path to transmit data packets from the source address to the destination address. Routing protocols ensure efficient and reliable data transmission by exchanging network topology information, calculating path costs, and adjusting routing selection in real time according to changes in network status. Common routing protocols include RIP (Routing Information Protocol) and OSPF (Open Shortest Path First).

[0122] RIP is a dynamic routing protocol based on the distance-vector algorithm. It updates routes by periodically broadcasting or multicasting routing table information to neighboring routers, using hop count as the metric, supporting a maximum of 15 hops; the 16th hop indicates unreachable. RIP is simple to implement, but its convergence speed is slow and it is prone to routing loops. Therefore, mechanisms such as split horizon are often used to avoid loops. Its working principle is that routers initially only record routes to directly connected networks, and then continuously receive routing table information from neighboring routers and update their own routing tables, eventually achieving convergence of routes across the entire network.

[0123] OSPF is a dynamic routing protocol based on a link-state algorithm. It calculates the shortest path by exchanging network topology information between routers, enabling it to quickly adapt to changes in network topology, converge rapidly, and is suitable for large and complex networks. OSPF divides the network into areas and reduces the size of routing tables through hierarchical routing strategies, improving routing calculation efficiency. It uses cost as the path metric, prioritizing the path with the lowest cost, and supports load balancing across multiple equal-cost paths.

[0124] Blockchain nodes can encapsulate first and second intent data to obtain event information that can be stored in the source blockchain. For example, the first and second intent data can be formatted first, and then metadata such as a globally unique identifier, timestamp (e.g., Unix or ISO 8601 format), and source blockchain network identifier (e.g., chainId:1 representing the source blockchain) can be added to the header of the event information. The first and second intent data can then be added to the body of the event information, which may include cross-chain state proofs (e.g., Merkle Patricia Trie paths) and signature fields (aggregating signatures from all parties and a list of public keys for verification). Blockchain nodes can encode the event information into JSON or binary format and further embed it into the intent settlement contract of the source blockchain for storage.

[0125] Cross-chain state proofs are a technology used to verify the consistency and authenticity of states between different blockchains. By generating and verifying specific proofs, it ensures that state information on the source blockchain can be accurately and securely identified and confirmed by the target blockchain during cross-chain interactions. For example, the Lagrange protocol uses zero-knowledge proof technology to generate state proofs for OptimisticRollups, allowing objects to securely transfer and interact with assets between different chains without relying on centralized third parties or complex intermediary protocols. This technology is significant in improving the security of cross-chain bridging, reducing trust costs, and supporting the interoperability of multi-chain decentralized applications (DApps).

[0126] The signature field is a crucial concept in digital signature technology. It's typically used to store digital signatures and related information in documents, forms, or data structures, ensuring document integrity and verifying the signer's identity. The signature field can contain the signer's identity information, a signature timestamp, the signature algorithm, and the signature value. This information allows users to verify whether the document has been tampered with and the signer's true identity. Furthermore, in blockchain and cryptography, signature fields are used to implement anonymous signatures, group signatures, or ring signatures to protect privacy and ensure the security and non-repudiation of transactions or information.

[0127] Blockchain nodes can also directly encapsulate second-intent data, without any restrictions. For example, the second-intent data can be preprocessed (e.g., standardized format), and a digital signature to prevent tampering can be generated using a hash function (e.g., SHA-256 (SecureHash Algorithm 256, a 256-bit hash algorithm)) or a secure private key provided by the target object. Then, the second-intent data can be structurally encapsulated through an intent settlement contract to obtain event information. Blockchain nodes can then perform root hash calculations on the event information using a hash function, and store the resulting Merkle root in the source blockchain. This allows for rapid verification of the event information within the source blockchain.

[0128] Step S103: Broadcast event information to the consortium blockchain through the intent settlement contract;

[0129] Specifically, blockchain nodes can broadcast event information to the consortium blockchain via intent settlement contracts under a broadcast mechanism. This can be done through a P2P protocol (Pix2Pix, a peer-to-peer protocol). Unlike public blockchains, which broadcast across the entire network, consortium blockchain broadcasts only cover authorized nodes. This means nodes in the consortium blockchain must join the network through identity authentication (such as digital certificates), and the propagation path is restricted by access control, thus preventing unauthorized nodes from receiving event information. The P2P protocol is a communication protocol based on a peer-to-peer network architecture. It allows each node in the network (peer node) to act as both a client and a server, directly interacting with other nodes without relying on a central server. The P2P protocol achieves resource sharing, file transfer, and communication in a distributed manner, featuring decentralization, high scalability, and strong fault tolerance.

[0130] Step S104: If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node and rebroadcasts the event information based on the block information carried in the event acquisition request, so that when the relay node acquires the event information and successfully verifies the event information, it packages the second intent data in the event information to obtain the relay transaction.

[0131] Specifically, relay nodes in a consortium blockchain can receive event information broadcast by blockchain nodes, i.e., continuously monitor the reception of event information. If the reception of event information fails, the relay node can send an event retrieval request to the blockchain node. Since the event information carries block information containing the first intent data, the relay node can add the block information from the processed event to the event retrieval request. The blockchain node then rebroadcasts the event information based on the block information carried in the event retrieval request.

[0132] For example, the block information could be the block height of the first intent data block. If a relay node obtains the highest block height of the processed events as E, and fails to obtain event information containing block height E+1 after the waiting time (the waiting time to obtain block height E+1) exceeds a time threshold, then the highest block height E can be added to the event acquisition request, thereby sending an event acquisition request to the blockchain node. The blockchain node then determines, based on the event acquisition request, that the relay node lacks event information containing block heights greater than the highest block height E. Therefore, it rebroadcasts event information with block heights greater than the highest block height E (including block height E+1). This allows the relay node to verify the event information after obtaining it. For example, it can verify the block height continuity of the rebroadcast event information by using the highest block height corresponding to the processed events. When the event information is successfully verified (i.e., the event information contains block height E+1), the second intent data in the event information is packaged to obtain a relay transaction.

[0133] For example, a relay node can first verify the second intent data, such as verifying that the second intent data comes from the source blockchain, and then parse the second intent data into a standard format specified by the cross-chain protocol (such as a Substrate-compatible format). The formatted second intent data is then packaged to generate a relay transaction. The relay node can then distribute the relay transaction to the corresponding interface node of the target blockchain based on the target blockchain's identifier (such as the target blockchain ID, address, etc.).

[0134] It is understood that the blockchain node in this embodiment can obtain first intent data from the intent pool of the source blockchain, and then execute the first intent data through the intent settlement contract. When it is detected that the first intent data is a cross-chain intent for the target blockchain, and the execution of the first intent is successful, second intent data can be generated based on the first intent data and the corresponding execution result. The second intent data is then encapsulated into event information that can be stored in the source blockchain (the event information carries block information of the block containing the first intent data), and then broadcast to the consortium blockchain through the intent settlement contract. If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node, and rebroadcasts the event information based on the block information carried in the event acquisition request. This allows the relay node to package the second intent data in the event information when it acquires the event information and successfully verifies it, thus obtaining a relay transaction. The relay node is used to forward the relay transaction to the target blockchain. Since event information can be persistently stored on the source blockchain, and relay nodes can continue to send event retrieval requests to blockchain nodes when they detect event information reception failure, thereby obtaining the event information rebroadcast by the blockchain nodes, as long as the source blockchain can successfully execute the intent data, the relay node can ensure that it can package a relay transaction containing the intent data when it successfully verifies the corresponding event information. Therefore, it can be guaranteed that the target blockchain can successfully execute the intent data through the relay transaction sent by the relay node. That is, even if the event information reception fails, the entire cross-chain intent process can still be guaranteed to proceed smoothly, thereby reducing the risk of asset loss in the target's transaction assets.

[0135] Please see Figure 5 , Figure 5 This is a flowchart illustrating a data processing method based on a consortium blockchain provided in an embodiment of this application. Figure 3 This data processing method can be executed by a relay node, which can be, for example,... Figure 1 The relay node 400 is shown. The following description uses the execution of this data processing method by the relay node as an example. This data processing method may include at least the following steps S201-S203:

[0136] Step S201: If the failure to receive event information is detected, an event acquisition request is sent to the blockchain node in the source blockchain so that the blockchain node in the source blockchain rebroadcasts the event information based on the block information carried in the event acquisition request.

[0137] Specifically, relay nodes can continuously monitor the reception of event information. If event information reception fails, they generate an event retrieval request based on block information such as the block height and block hash of the blocks in the processed event. This request is then sent to the blockchain nodes in the source blockchain, allowing the blockchain nodes to continuously broadcast the event information based on the block information carried in the event retrieval request.

[0138] The event information is information encapsulated based on the second intent data and can be stored in the source blockchain. The event information also carries block information of the block containing the first intent data. The second intent data is generated based on the first intent data and its corresponding execution result. The first intent data is a cross-chain intent targeting the target blockchain. The specific meanings and implementation processes of the first and second intent data can be found above. Figure 3 The specific descriptions of the first intent data and the second intent data in the corresponding embodiments will not be repeated here.

[0139] Step S202: Verify the event information to obtain the event verification result. If the event verification result is a successful verification result, package the second intent data to obtain the relay transaction.

[0140] Specifically, the relay node can deserialize and verify the first intent data to obtain deserialized data; compare the deserialized data with the first intent data; if the deserialized data is the same as the first intent data, the event verification result is determined to be a successful verification result; if the deserialized data is different from the first intent data, the event verification result is determined to be a failed verification result, and the deserialization verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0141] For example, the serialized first intent data can be deserialized for verification. This involves first serializing the first intent data based on the encoded serialized data packet, such as serializing the first intent data into a binary data stream (e.g., Protobuf encoding) or structured text (e.g., a signed JSON string). Then, the serialized first intent data can be deserialized for verification. This involves converting the format of the first intent data according to decoding rules, such as converting the serialized first intent data into in-memory target object data (e.g., a Python dictionary, a Java target object), etc.

[0142] Relay nodes can compare deserialized data with the initial intent data, such as comparing the timestamp and other metadata information of the deserialized data with the timestamp and other metadata information of the initial intent data. If the metadata information of the deserialized data is the same as that of the initial intent data, the event verification result can be determined as successful. If the metadata information of the deserialized data is different from that of the initial intent data, the event verification result can be determined as failed. In this case, the failure result is returned to the blockchain node, so that the blockchain node can roll back the data of the block containing the initial intent data, that is, revoke the block and all transactions in the subsequent blocks, and restore the source blockchain to the state before the block.

[0143] For example, if the first intent data is transfer data, that is, user A sends encrypted transfer data containing a receiving address and amount to user B (the first intent data is "transfer 10 yuan to address X"). If the relay node finds that the deserialized data is different from the first intent data during the deserialization verification process (e.g., when deserializing the transfer content, it finds that the timestamp of the deserialized data is different from the timestamp of the first intent data), then the management system or management object in the source blockchain can determine that the block in the first intent data is invalid and automatically roll back to the previous valid block, while ensuring that the abnormal transfer data is completely cleared.

[0144] Optionally, the relay node can verify the block height continuity of the block information based on the highest block height corresponding to the processed event, and obtain a block verification result; verify the intent signature of the first intent data in the event information based on the public key of the target object, and obtain a signature verification result; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, where the target object refers to the object that initiated the business request containing the first intent data; verify the data format of the intent field of the first intent data in the event information, and obtain a field verification result; and determine the block verification result, signature verification result, and field verification result as the event verification result for the event information.

[0145] Relay nodes can also verify the block height continuity in the block information based on the highest block height corresponding to the processed event, and obtain the block verification result. For example, a relay node can number the block heights, such as block height 1, block height 2, ..., and if the block information of the processed events includes the highest block height, i.e., block height 100, and if no event information containing block height 101 is obtained after the waiting time (the waiting time to obtain block height 101) exceeds a time threshold, it can be determined that the event information containing block height 101 is missing. The relay node can then add block height 101 to the event retrieval request and send the event retrieval request to the blockchain node. The blockchain node then iterates through the event information containing block height 101 according to the event retrieval request and sends the event information containing block height 101 to the relay node. The relay node verifies the block height continuity of the re-received event information and verifies that the event information contains the missing block height 101. Therefore, it can be determined that the block height continuity verification in the block information is successful, and the successful verification result is determined as the block verification result.

[0146] Relay nodes can verify the intent signature of the first intent data in the event information based on the public key of the target object, and obtain the signature verification result. The intent signature is obtained by the blockchain node in the source blockchain digitally signing the first intent data based on the private key of the target object. The target object refers to the target object that initiates the business request containing the first intent data.

[0147] For example, a relay node can verify the intent signature of the first intent data in the first sub-block using the SHA256withRSA algorithm in the target sub-network, obtaining the signature verification result. This involves hashing the first intent data using the SHA-256 algorithm to obtain a first hash value, and decrypting the intent signature using the corresponding secure public key to obtain a second hash value. The first and second hash values ​​are then compared; if they match, the intent signature verification is successful. The SHA256withRSA algorithm is a cryptographic algorithm combining the SHA-256 hash function and the RSA encryption algorithm, widely used in data integrity and authentication scenarios. This combined algorithm provides a reliable method for secure information transmission by first hashing the data using SHA-256 and then encrypting the hash value using the RSA algorithm. SHA256withRSA is particularly important in digital signatures and secure communication protocols (such as TLS (Transport Layer Security)), ensuring the security and authenticity of data during transmission while preventing data tampering and unauthorized access.

[0148] The process of hashing the first intent data using the SHA-256 algorithm to obtain the first hash value can be as follows: The obtained first intent data is evenly divided into five blocks, namely Block1, ..., Block5. These five blocks are then read cyclically. After reading Block1, it is submitted to hash target object 1. At this point, the hash value in hash target object 1 is Z1 = 45678abc12345678 (hash value Z1 can also be called the hash value updated for the first time in hash target object 1). After reading Block2, the hash value can be... The hash value Z1 in target object 1 is updated by Z2 = Hash(Z1, Block2), resulting in the second updated hash value Z2 = 1234567890abcdef in target object 1. Similarly, after reading the block intent data Block5, the hash value Z4 in target object 1 can be updated by Z5 = Hash(Z4, Block5), resulting in the fifth updated hash value Z5 = 9876543210fedcba9 in target object 1. At this point, all block intent data has been read, and the fifth updated hash value Z5 in target object 1 can be determined as the first hash value.

[0149] Taking the verification and decryption of the intent signature of the first intent data using the RSA algorithm as an example, the process can be shown in formula (2):

[0150] de_hash_value = (signatyre) e mod n formula (2)

[0151] Here, 'e' represents the public key exponent, which can be used as part of the secure public key and is used in the exponentiation operation during signature verification and decryption. 'hash_value' represents the first hash value, 'de_hash_value' represents the second hash value, 'signature' represents the intent signature, and 'n' represents a large modulus, usually obtained by multiplying two large prime numbers, and is shared by both the secure private and public keys. The second hash value, 'de_hash_value', is obtained by taking the modulus 'n' with the power obtained by raising the public key exponent 'e' to the power of the intent signature. Relay nodes can then compare the first hash value 'hash_value' with the second hash value 'de_hash_value'. If the first hash value 'hash_value' and the second hash value 'de_hash_value' are the same, the signature verification of the intent signature 'signature' is successful, and the successful verification result is recognized as the signature verification result. It is understandable that if a leak occurs during the transmission of the intent signature, causing the intent signature to be tampered with, the first hash value (hash_value) or the first signature data (signature) may be changed. In this case, the relay node can calculate and confirm that the first hash value (hash_value) is different from the second hash value (de_hash_value) obtained by signature verification and decryption, and thus determine that the intent signature verification fails. This can prevent the first intent data corresponding to the leaked intent signature from entering the subsequent process.

[0152] Relay nodes can perform data format validation on the intent fields of the first intent data in the event information to obtain field validation results. For example, they can validate the field type of the intent field to ensure it conforms to the expected type (e.g., integer, floating-point number, string, etc.); validate the field range of the intent fields in the first intent data to ensure it is within the allowed length range (e.g., 64 bytes); and validate the format of the field information (e.g., date, number, etc.), such as verifying that the date format conforms to the standard date format (i.e., year-month-day). Relay nodes can also verify whether the identifier of the intent field conforms to hierarchical encoding rules (e.g., following hierarchical classification serial number encoding rules). If the identifier conforms to hierarchical encoding rules, the uniqueness of the first intent data in the data category and data element can be determined. If all the above data format validations pass, the successful validation result can be determined as the field validation result. If the block validation result, signature validation result, and field validation result are all successful, the successful validation result can be determined as the event validation result.

[0153] Hierarchical coding rules are a method of encoding data or objects according to a hierarchical structure. It divides data into multiple levels and assigns specific coding rules to each level, thereby achieving efficient organization and management of complex data structures. For example, in a file system, hierarchical coding rules can be used to represent directory structures, with each directory and file having a unique path code, clearly showing the hierarchical relationships between them. In business resource management, hierarchical coding rules are also commonly used for organizational structure coding, material coding, etc., facilitating rapid information retrieval and management while reflecting the hierarchical relationships and logical structure of the data, improving data readability and maintainability.

[0154] Optionally, the relay node can obtain the transfer status of the data consumption resources for the first intent data from the event information, and then verify the transfer status. If the transfer status is that the resources have been transferred, the event verification result is determined to be a successful verification result; if the transfer status is that the resources have not been transferred, the event verification result is determined to be a failed verification result, and the failed verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0155] For example, if the first intent data is transfer data, the relay node can first verify the account balance of the transfer initiator. If the account balance is greater than the sum of the transfer amount and the data-consuming resources, it further verifies the transfer status of the data-consuming resources (such as the payment status of gas fees). If the transfer status is "resources have been transferred," a transfer receipt (such as one containing the transfer hash value) can be generated, thus determining the event verification result as a successful verification result. If the account balance is insufficient or the smart contract in the source blockchain fails to execute, resulting in a "resources not transferred" status, the event verification result is determined as a verification failure result. This failure result can then be returned to the blockchain node, allowing the blockchain node to roll back the block containing the first intent data, such as removing the first intent data and synchronously restoring the account balance to its original state. When the event information is successfully verified, the relay node can package the second intent data in the event information to obtain a relay transaction, and can add information such as the target blockchain identifier and target blockchain ID to the relay transaction.

[0156] Optionally, if the deserialized data is the same as the first intent data, and the block verification result, signature verification result, and field verification result are all successful verification results, and the data consumption resource transfer status of the first intent data is a resource transferred status, then it can be determined that the event information has been successfully verified, and thus the successful verification result can be determined as the event verification result.

[0157] Step S203: Forward the relay transaction to the target blockchain.

[0158] Specifically, relay nodes can forward relay transactions to the target blockchain based on the routing module and the target blockchain ID. For example, under the IBC protocol (Inter-Blockchain Communication Protocol), relay transactions can be forwarded to the IBC module of the target blockchain through a pre-established secure channel or secure connection. Alternatively, under the IBTP protocol (Inter-Blockchain Transfer Protocol), relay transactions can be forwarded to the cross-chain gateway of the target blockchain through the routing module. There are no restrictions on this.

[0159] The IBC protocol is an open-source protocol designed to address the silo problem between blockchains and facilitate cross-chain interaction. It enables secure, trustless communication and data transfer between different blockchains. The IBC protocol achieves this through a layered architecture: the transport layer is responsible for establishing secure connections and verifying data packets, while the application layer defines how data packets are packaged and interpreted. Its key features include no need for third-party trust, support for communication between blockchains with different consensus mechanisms, and low transaction costs.

[0160] The IBTP protocol is a general-purpose cross-chain message transmission protocol that allows cross-chain calls for assets, data, and services between heterogeneous blockchains, supporting interactions between application chains and relay chains, as well as between application chains themselves. The IBTP protocol uses a cross-chain gateway to convert event data formats from different application chains into a unified structure, submitting it to the relay chain for validity verification and reliable routing. Its key features include cross-chain services, cross-chain message proof, and a trust tree. The Proof field provides the relay chain with proof of the validity of cross-chain transactions, ensuring the security and reliability of cross-chain transactions.

[0161] It is understood that this embodiment is executed by a relay node. The relay node can detect the reception status of event information. If the event information reception fails, it sends an event retrieval request to the blockchain node in the source blockchain, so that the blockchain node in the source blockchain rebroadcasts the event information based on the block information carried in the event retrieval request. The event information is information encapsulated based on second intent data and can be stored in the source blockchain, and the event information carries block information of the block containing first intent data. The second intent data is generated based on the first intent data and the corresponding execution result, where the first intent data is a cross-chain intent for the target blockchain. The relay node can verify the event information to obtain an event verification result. When the event verification result is a successful verification result, it packages the second intent data to obtain a relay transaction, and then forwards the relay transaction to the target blockchain. Since event information can be persistently stored on the source blockchain, and relay nodes can continue to send event retrieval requests to blockchain nodes when they detect event information reception failure, thereby obtaining the event information rebroadcast by the blockchain nodes, as long as the source blockchain can successfully execute the intent data, the relay node can ensure that it can package a relay transaction containing the intent data when it successfully verifies the corresponding event information. Therefore, it can be guaranteed that the target blockchain can successfully execute the intent data through the relay transaction sent by the relay node. That is, even if the event information reception fails, the entire cross-chain intent process can still be guaranteed to proceed smoothly, thereby reducing the risk of asset loss in the target's transaction assets.

[0162] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a data processing device based on a consortium blockchain provided in an embodiment of this application. Figure 1 .like Figure 6 As shown, the data processing device 1 includes a transceiver module 1100, an event generation module 1200, an event broadcasting module 1300, and a transaction generation module 1400.

[0163] The transceiver module 1100 is used to obtain first intent data from the intent pool of the source blockchain and execute the first intent data through the intent settlement contract;

[0164] The event generation module 1200 is used to generate second intent data based on the first intent data and the execution result corresponding to the first intent data when it is detected that the first intent data is a cross-chain intent for the target blockchain and the first intent is successfully executed. The second intent data is encapsulated into event information that can be stored in the source blockchain. The event information carries the block information of the block containing the first intent data.

[0165] Event broadcasting module 1300 is used to broadcast event information to the consortium blockchain through the intent settlement contract;

[0166] The transaction generation module 1400 is used to receive the event acquisition request sent by the relay node if the relay node detects that the event information reception has failed. Based on the block information carried in the event acquisition request, the relay node rebroadcasts the event information so that when the relay node obtains the event information and successfully verifies the event information, it packages the second intent data in the event information to obtain a relay transaction. The relay node is used to forward the relay transaction to the target blockchain.

[0167] In one possible implementation, the event generation module 1200 is also used to perform the following operations:

[0168] When the first intent data is detected as a single-chain intent targeting the source blockchain, the status of the account associated with the first intent data is updated based on the execution result of the first intent data.

[0169] In one possible implementation, the event generation module 1200 is also used to perform the following operations:

[0170] When the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent data fails, the failure execution result of the first intent data is returned to the business system.

[0171] In one possible implementation, the event generation module 1200 is used to generate second intent data based on the first intent data and the execution result corresponding to the first intent data. When encapsulating the second intent data into event information that can be stored in the source blockchain, it is specifically used to perform the following operations:

[0172] The intent sequence number, intent cross-chain path, and intent signature corresponding to the first intent data are obtained through the intent settlement contract. The intent sequence number is used to characterize the uniqueness of the first intent data. The intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain. The intent signature is obtained by digitally signing the first intent data based on the private key of the target object. The target object refers to the object that initiates the business request containing the first intent data.

[0173] The second intent data is generated based on the first intent data, the intent random number, the intent cross-chain path, the intent signature, and the execution result corresponding to the first intent data.

[0174] The first intent data and the second intent data are encapsulated to obtain event information that can be stored in the source blockchain.

[0175] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a data processing device based on a consortium blockchain provided in an embodiment of this application. Figure 2 .like Figure 7As shown, the data processing device 2 includes an event acquisition module 1500, an event verification module 1600, and a transaction forwarding module 1700.

[0176] The event acquisition module 1500 is used to send an event acquisition request to the blockchain nodes in the source blockchain if the event information reception failure is detected, so that the blockchain nodes in the source blockchain rebroadcast the event information based on the block information carried in the event acquisition request; the event information is information encapsulated based on the second intent data and can be stored in the source blockchain, and the event information carries the block information of the block containing the first intent data; the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the first intent data is a cross-chain intent for the target blockchain;

[0177] The event verification module 1600 is used to verify event information and obtain event verification results. When the event verification result is a successful verification result, the second intent data is packaged to obtain the relay transaction.

[0178] The transaction forwarding module 1700 is used to forward relay transactions to the target blockchain.

[0179] In one possible implementation, the event verification module 1600 is used to verify event information, and when the event verification result is obtained, it is specifically used to perform the following operations:

[0180] The first intent data is deserialized for verification to obtain deserialized data;

[0181] Compare the deserialized data with the first intent data;

[0182] If the deserialized data is the same as the first intent data, then the event verification result is determined to be a successful verification result;

[0183] If the deserialized data is different from the first intent data, the event verification result is determined to be a verification failure result, and the deserialization verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

[0184] In one possible implementation, the event verification module 1600 is used to verify event information, and when the event verification result is obtained, it is specifically used to perform the following operations:

[0185] Based on the highest block height corresponding to the processed events, the block height in the block information is verified to ensure continuity, and the block verification result is obtained.

[0186] The intent signature of the first intent data in the event information is verified based on the public key of the target object to obtain the signature verification result; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, and the target object refers to the object that initiates the business request containing the first intent data;

[0187] Perform data format validation on the intent field of the first intent data in the event information to obtain the field validation result;

[0188] The block verification result, signature verification result, and field verification result are determined as the event verification result for the event information.

[0189] In one possible implementation, the event verification module 1600 is used to verify event information, and when the event verification result is obtained, it is specifically used to perform the following operations:

[0190] Obtain the data resource consumption transition status from the event information for the first intent data;

[0191] If the transfer status is "resource transferred", then the event verification result is determined to be a successful verification result.

[0192] If the transfer status is "resource not transferred", then the event verification result is determined to be a verification failure result. The verification failure result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

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

[0194] In this embodiment, the blockchain node can obtain first intent data from the intent pool of the source blockchain, and then execute the first intent data through an intent settlement contract. When the first intent data is detected to be a cross-chain intent for the target blockchain, and the execution of the first intent is successful, second intent data can be generated based on the first intent data and the corresponding execution result. The second intent data is then encapsulated into event information that can be stored in the source blockchain (the event information carries block information of the block containing the first intent data), and then broadcast to the consortium blockchain through the intent settlement contract. If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node, and rebroadcasts the event information based on the block information carried in the event acquisition request. This allows the relay node to package the second intent data in the event information when it acquires and successfully verifies the event information, thus obtaining a relay transaction. The relay node is used to forward the relay transaction to the target blockchain. Since event information can be persistently stored on the source blockchain, and relay nodes can continue to send event retrieval requests to blockchain nodes when they detect event information reception failure, thereby obtaining the event information rebroadcast by the blockchain nodes, as long as the source blockchain can successfully execute the intent data, the relay node can ensure that it can package a relay transaction containing the intent data when it successfully verifies the corresponding event information. Therefore, it can be guaranteed that the target blockchain can successfully execute the intent data through the relay transaction sent by the relay node. That is, even if the event information reception fails, the entire cross-chain intent process can still be guaranteed to proceed smoothly, thereby reducing the risk of asset loss in the target's transaction assets.

[0195] 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 8 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include an object interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The object interface 1003 may include a display screen and a keyboard; optionally, the object interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 8As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, an object interface module, and a device control application.

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

[0197] When the computer device 1000 is a data processing device 1, it achieves the following:

[0198] Obtain the first intent data from the intent pool of the source blockchain, and execute the first intent data through the intent settlement contract;

[0199] When the first intent data is detected as a cross-chain intent targeting the target blockchain, and the execution of the first intent is successful, second intent data is generated based on the first intent data and the execution result corresponding to the first intent data. The second intent data is encapsulated into event information that can be stored in the source blockchain. The event information carries the block information of the block containing the first intent data.

[0200] Broadcast event information to the consortium blockchain via the intent settlement contract;

[0201] If a relay node detects that the event information reception has failed, it receives the event retrieval request sent by the relay node and rebroadcasts the event information based on the block information carried in the event retrieval request. This allows the relay node to package the second intent data in the event information to obtain a relay transaction when it successfully obtains and verifies the event information. The relay node then forwards the relay transaction to the target blockchain.

[0202] When computer device 1000 is a data processing device 2, it can achieve the following:

[0203] If event information reception failure is detected, an event retrieval request is sent to the blockchain nodes in the source blockchain, so that the blockchain nodes in the source blockchain rebroadcast the event information based on the block information carried in the event retrieval request; the event information is information encapsulated based on the second intent data and can be stored in the source blockchain, and the event information carries the block information of the block containing the first intent data; the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the first intent data is a cross-chain intent for the target blockchain;

[0204] The event information is verified to obtain the event verification result. When the event verification result is a successful verification result, the second intent data is packaged to obtain the relay transaction.

[0205] Relay transactions are forwarded to the target blockchain.

[0206] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 5 The description of the data processing method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0207] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program. When the processor executes the computer program, it can execute the aforementioned... Figure 3 , Figure 5 The description of the data processing method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

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

[0209] Furthermore, it should be noted that this application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. The 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 aforementioned... Figure 3 , Figure 5 The method provided in any of the corresponding embodiments.

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

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

[0212] The methods and related apparatus 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 device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable 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 device to function 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 1 A 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 device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device 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.

[0213] It is understood that, in the specific embodiments of this application, the user data involved requires user permission or consent when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions.

[0214] If this application requires the collection of object data (such as user data), a prompt interface or pop-up window will be displayed before and during the collection process. This prompt interface or pop-up window is used to inform the user that certain data is being collected. The data acquisition steps will only begin after the user confirms the prompt interface or pop-up window; otherwise, the process will end. Furthermore, the acquired user data will be used in reasonable and legal scenarios or for legitimate purposes. Optionally, in scenarios where user data needs to be used but user authorization has not been obtained, authorization can be requested from the user, and the user data can only be used after authorization is granted.

[0215] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

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

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

Claims

1. A data processing method based on a consortium blockchain, characterized in that, The consortium blockchain includes a source blockchain, a target blockchain, and relay nodes; the method is executed by blockchain nodes in the source blockchain; the method includes: Obtain the first intent data from the intent pool of the source blockchain, and execute the first intent data through the intent settlement contract; When the first intent data is detected as a cross-chain intent for the target blockchain, and the execution of the first intent is successful, second intent data is generated based on the first intent data and the execution result corresponding to the first intent data. The second intent data is encapsulated into event information that can be stored in the source blockchain. The event information carries block information of the block containing the first intent data. The event information is broadcast to the consortium blockchain through the intent settlement contract; If the relay node detects that the event information reception has failed, it receives the event acquisition request sent by the relay node, and rebroadcasts the event information based on the block information carried in the event acquisition request, so that when the relay node acquires the event information and successfully verifies the event information, it packages the second intent data in the event information to obtain a relay transaction; the relay node is used to forward the relay transaction to the target blockchain.

2. The method according to claim 1, characterized in that, The method further includes: When the first intent data is detected to be a single-chain intent targeting the source blockchain, the account associated with the first intent data is updated based on the execution result of the first intent data.

3. The method according to claim 1, characterized in that, The method further includes: When it is detected that the first intent data is a cross-chain intent for the target blockchain, and the execution of the first intent data fails, the failure execution result of the first intent data is returned to the business system.

4. The method according to claim 1, characterized in that, The step of generating second intent data based on the first intent data and the execution result corresponding to the first intent data, and encapsulating the second intent data into event information that can be stored in the source blockchain, includes: The intent sequence number, intent cross-chain path, and intent signature corresponding to the first intent data are obtained through the intent settlement contract; the intent sequence number is used to characterize the uniqueness of the first intent data; the intent cross-chain path refers to the execution path for intent cross-chain between the source blockchain and the target blockchain; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, and the target object refers to the object that initiates the business request containing the first intent data. The second intent data is generated based on the first intent data, the intent sequence number, the intent cross-chain path, the intent signature, and the execution result corresponding to the first intent data; The first intent data and the second intent data are encapsulated to obtain event information that can be stored in the source blockchain.

5. A data processing method based on a consortium blockchain, characterized in that, The consortium blockchain includes a source blockchain, a target blockchain, and relay nodes; the method is executed by the relay nodes; the method includes: If event information reception failure is detected, an event retrieval request is sent to the blockchain nodes in the source blockchain, so that the blockchain nodes in the source blockchain rebroadcast the event information based on the block information carried in the event retrieval request; the event information is information encapsulated based on second intent data and can be stored in the source blockchain, and the event information carries block information of the block containing first intent data; the second intent data is generated based on the first intent data and the execution result corresponding to the first intent data, and the first intent data is a cross-chain intent for the target blockchain; The event information is verified to obtain an event verification result. When the event verification result is a successful verification result, the second intent data is packaged to obtain a relay transaction. The relay transaction is forwarded to the target blockchain.

6. The method according to claim 5, characterized in that, The process of verifying the event information to obtain the event verification result includes: The first intent data is deserialized for verification to obtain deserialized data; The deserialized data is compared with the first intent data; If the deserialized data is the same as the first intent data, then the event verification result is determined to be a successful verification result; If the deserialized data is different from the first intent data, the event verification result is determined to be a verification failure result, and the deserialization verification result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

7. The method according to claim 5, characterized in that, The process of verifying the event information to obtain the event verification result includes: Based on the highest block height corresponding to the processed event, the block height in the block information is verified to ensure continuity, and the block verification result is obtained. The intent signature of the first intent data in the event information is verified based on the public key of the target object to obtain a signature verification result; the intent signature is obtained by digitally signing the first intent data based on the private key of the target object, and the target object refers to the object that initiates the business request containing the first intent data. Perform data format validation on the intent field of the first intent data in the event information to obtain the field validation result; The block verification result, the signature verification result, and the field verification result are determined as the event verification result for the event information.

8. The method according to claim 5, characterized in that, The process of verifying the event information to obtain the event verification result includes: Obtain the data resource consumption transfer status for the first intent data from the event information; If the transfer status is a resource transfer status, then the event verification result is determined to be a successful verification result; If the transfer status is a resource not transferred status, then the event verification result is determined to be a verification failure result, and the verification failure result is returned to the blockchain node so that the blockchain node can roll back the data of the block containing the first intent data.

9. A data processing device based on a consortium blockchain, characterized in that, include: The send / receive module is used to obtain first intent data from the intent pool of the source blockchain and execute the first intent data through the intent settlement contract; The event generation module is used to generate second intent data based on the first intent data and the execution result corresponding to the first intent data when it is detected that the first intent data is a cross-chain intent for the target blockchain and the first intent is successfully executed, and to encapsulate the second intent data into event information that can be stored in the source blockchain. The event information carries block information containing the block of the first intent data; The event broadcasting module is used to broadcast the event information to the consortium blockchain through the intent settlement contract; The transaction generation module is used to receive an event acquisition request sent by the relay node if the relay node detects that the event information reception has failed, and rebroadcast the event information based on the block information carried in the event acquisition request, so that when the relay node acquires the event information and successfully verifies the event information, it packages the second intent data in the event information to obtain a relay transaction; the relay node is used to forward the relay transaction to the target blockchain.

10. A data processing device based on a consortium blockchain, characterized in that, include: The event acquisition module is used to send an event acquisition request to the blockchain node in the source blockchain if the failure to receive event information is detected, so that the blockchain node in the source blockchain rebroadcasts the event information based on the block information carried in the event acquisition request. The event information is information encapsulated based on the second intent data and can be stored in the source blockchain, and the event information carries block information of the block containing the first intent data; The second intent data is generated based on the first intent data and the execution result corresponding to the first intent data. The first intent data is a cross-chain intent for the target blockchain. The event verification module is used to verify the event information and obtain the event verification result. When the event verification result is a successful verification result, the second intent data is packaged to obtain the relay transaction. The transaction forwarding module is used to forward the relay transaction to the target blockchain.

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

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

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

Images