A heterogeneous blockchain environment lightweight interoperation method, system and medium

Abstract

The application discloses a kind of heterogeneous block chain environment light weight interoperation method, system and medium, adopt side chain / relay mode combination intelligent contract and Relayer cluster, realize the safe and efficient interaction of cross-chain data.Method includes: source chain cross-chain transaction initialization;Relayer listens and captures source chain data;Relay chain carries out preliminary check and verification (including ZK-SNARK proof);Relayer listens and captures relay data and message distribution;Target chain triggers contract verification execution;Abnormality is automatically rolled back to ensure atomicity.System contains source chain module, Relayer cluster, relay chain and target chain module.The application solves the security and efficiency problem of heterogeneous chain interoperation through multilevel verification (merkle proof, multi-signature check) and light weight design, supports complex cross-chain call, avoids single point failure, and ensures transaction eventual consistency.

Description

Technical Field

[0001] This invention belongs to the field of computer technology and relates to blockchain technology. Specifically, it is a lightweight interoperability method, system and medium for heterogeneous blockchain environments. Background Technology

[0002] In traditional heterogeneous blockchain interoperability methods, one approach introduces a trusted third-party node (such as a notary node) as an intermediary for cross-chain interaction, verifying the legitimacy of cross-chain transactions and coordinating data transmission. However, this approach makes the centralized architecture of the notary node or gateway vulnerable to attack, posing a single point of failure risk. The trustworthiness of the notary node depends on external supervision; if the notary node is maliciously manipulated or attacked, cross-chain transaction data will be tampered with or lost. Another approach uses cryptographic hash locks and time lock mechanisms to achieve cross-chain atomic swaps; this method is limited to asset swaps and cannot handle complex cross-chain logic calls. Yet another approach uses multi-party computation (MPC) or threshold signature (TSS) technology to shard and store private keys across multiple nodes, achieving secure custody and transfer of cross-chain assets; however, this method has high key management complexity and high inter-node communication overhead, making it unsuitable for high-frequency trading scenarios. To address the above problems and the technical characteristics of blockchain, this application provides a lightweight interoperability method for heterogeneous blockchain environments. Summary of the Invention

[0003] The purpose of this invention is to provide a lightweight interoperability method for heterogeneous blockchain environments, which solves the problems of effectiveness, security and transactionality in cross-chain data, asset and information transmission and exchange in heterogeneous blockchain environments, and realizes a secure, easy-to-use and efficient cross-chain system.

[0004] The technical problem that this invention aims to solve is: how to simply and flexibly support lightweight ledger data interoperability for blockchains with various structures, and support the validity and security of cross-chain information.

[0005] The objective of this invention can be achieved through the following technical solution: a lightweight interoperability method for heterogeneous blockchain environments, comprising the following steps:

[0006] Step 1: Cross-chain configuration initialization: Initialize cross-chain transactions;

[0007] Step 2: Relayer event listening and source chain data capture: The user calls the cross-chain smart contract of the source chain and waits for the cross-chain transaction of the source chain to be settled. The Relayer listens for the cross-chain information of the source chain.

[0008] Step 3: Relay and preliminary verification of cross-chain data to the relay chain: Transmit the necessary information, such as cross-chain data, to the relay chain and continue preliminary verification;

[0009] Step 4: Relay Chain Transaction Status Deep Verification and Relay Synchronization: Verify the legality of cross-chain information. Once verified, unify the source chain's status information and perform relay synchronization.

[0010] Step 5: Relayer event listening and relay chain data capture and message distribution: The relay chain generates corresponding cross-chain information executable instruction packets, and the Relayer listens for the cross-chain information of the relay chain and distributes the messages to the target chain;

[0011] Step Six: Target Chain Triggers On-Chain Contract Instruction Verification: After receiving the information transmitted from the relay chain, the target chain verifies the legality of the information by calling the cross-chain contract on the target chain.

[0012] Step 7: Cross-chain transaction final state feedback and exception rollback: The target chain will send the execution result back to the relay chain through the Relayer. If an exception occurs, the rollback mechanism will be triggered.

[0013] In step one, the cross-chain management contracts of the source chain, target chain, and relay are initialized and configured.

[0014] In step two, the user invokes the cross-chain smart contract deployed on the source chain, passing in the target chain identifier, target chain contract information, and transfer data, triggering a transaction signature and submitting it to the source chain network. The user then waits for node consensus verification and block confirmation. The contract encodes the data into a standard cross-chain message (containing a unique transaction ID, source chain block height, target chain address, etc.). The Relayer cluster scans cross-chain transaction events in new blocks in real time, extracting transaction hashes, Merkel path proofs, and cross-chain message metadata, filtering out invalid or duplicate requests.

[0015] In step three, Relayer pushes the captured cross-chain data packets (including source chain block headers, transaction proofs, and message content) to the relay chain entry contract to invoke the transaction. The relay chain verification module first verifies the compliance of the data format (such as field integrity and digital signature validity) and verifies whether the source chain block header has reached a final consensus to eliminate the risk of forks.

[0016] In step four, the relay chain calls the built-in verification logic to verify the existence and legality of the source chain transaction in the Merkle tree. After verification, the cross-chain transaction state is written into the relay chain's global state tree to generate a transaction certificate carrying multi-chain signatures (including relay chain block hash, timestamp, etc.).

[0017] In step five, the relay chain generates a transaction certificate and associated proof based on the target chain identifier in the transaction certificate. The Relayer cluster scans the relay chain cross-chain transaction events in the new block in real time, extracts the transaction hash, Merkel path proof, and cross-chain message metadata, and filters out invalid or duplicate requests. The Relayer group performs secondary encapsulation on the data, adds a target chain-compatible protocol header, and forms an executable instruction package.

[0018] In step six, after receiving the instruction packet, the target chain node calls the target chain cross-chain contract to parse the instruction. First, it verifies the Merkel proof of the cross-chain transaction of the relay chain, including the transaction block header and consensus node signature. Combined with the current relay chain BookKeeper (consensus ledger administrator) information stored in the contract, it verifies whether the cross-chain data comes from the relay chain managed by the BookKeeper and has been executed, ensuring data credibility. After the verification is passed, it executes the state update or inter-chain callback.

[0019] In step seven, the target chain sends the execution result back to the relay chain via the Relayer, and the relay chain updates its global state to "completed". If the target chain fails to execute, the relay chain initiates a timeout rollback mechanism, sends an unlocking instruction to the source chain, triggers the unfreezing of smart contract assets in the source chain, and ensures cross-chain atomicity.

[0020] This invention also discloses a lightweight interoperability system for heterogeneous blockchain environments, characterized in that it includes:

[0021] Source Chain Module: Used to perform cross-chain transaction initialization and data encapsulation, including cross-chain smart contracts and transaction signature modules;

[0022] Relayer cluster: Used to listen for cross-chain events on the relay chain and sidechains (source chain and target chain), capture cross-chain data, and filter invalid requests;

[0023] Relay Chain Module: Includes entry contract, verification module and state tree, used to verify the legality of cross-chain data and generate transaction credentials;

[0024] Target Chain Module: Used to receive transaction message instructions distributed by Relayer, verify them, execute cross-chain contract operations, and provide feedback on the execution results or trigger a rollback mechanism.

[0025] Preferably, the relay chain module further includes a ZK-SNARK verification contract, used to generate zero-knowledge proofs to verify the authenticity of source chain transactions.

[0026] Preferably, the Relayer cluster adopts a distributed architecture, with at least one Relayer node deployed for each blockchain participating in cross-chain operations to ensure high availability.

[0027] The present invention also discloses a non-volatile storage medium, characterized in that the non-volatile storage medium includes a stored program, wherein the program, when running, controls the device where the non-volatile storage medium is located to execute the above-described method.

[0028] The present invention also discloses a terminal device, characterized in that the terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the method described above.

[0029] The present invention has the following beneficial effects:

[0030] 1. To address the security vulnerabilities and low operational efficiency associated with differences in block structures and consensus algorithms among various blockchain applications, which can lead to inefficient interoperability and hinder reliable data flow and value exchange, a lightweight interoperability technology for heterogeneous blockchain environments was designed. This technology constructs cross-chain interoperability protocols for different applications built on different underlying frameworks or the same underlying framework, enabling free cross-chain interoperability of arbitrary information between homogeneous and heterogeneous blockchain environments. It solves security issues from the chain perspective and optimizes the efficiency of interoperability between heterogeneous chains.

[0031] 2. To address issues such as forgery and impersonation of member chains to perform interoperation on chains with the same structure, the lightweight interoperability technology for heterogeneous chain environments can manage the registration information and block information of each chain to ensure authenticity. At the same time, it integrates Merkel proofs to verify the interoperability data, ensuring that the received interoperability data does indeed exist on the chain, thereby ensuring data security. Attached Figure Description

[0032] Figure 1 This is a flowchart of a lightweight interoperability method for heterogeneous blockchain environments according to the present invention.

[0033] Figure 2 This is a structural block diagram of a lightweight interoperability method for heterogeneous blockchain environments in this invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0035] See Figure 2 As shown, taking chain A (using the PoW consensus mechanism) and chain B (using the PoS consensus mechanism) as an example, chain A and chain B need to interoperate across chains.

[0036] Step 1: Cross-chain configuration initialization. Initialize the configuration of Chain A, the relay chain, and Chain B. Register the relevant information of Chain A and Chain B to the relay chain (obtaining sidechain ID1 and ID2), and deploy cross-chain management contracts on Chain A and Chain B (obtaining contract addresses CA1 and CB1). Synchronize the BookKeeper (consensus ledger administrator) from the relay chain block header information to the cross-chain management contracts of Chain A and Chain B, and synchronize the block headers of Chain A and Chain B to the relay chain as a trust anchor root.

[0037] Step Two: Relayer Event Listening and Source Chain Data Capture. The user initiates a cross-chain request through the cross-chain smart contract on Chain A (contract address CA1), inputting the target chain identifier (chain BID2), the content of the cross-chain information to be shared (e.g., "Hello world"), the target chain's receiving contract address (business contract address CB2 on Chain B), and the receiving contract method name (CB2hear). The message is signed using the ECDSA signature algorithm and submitted to the Chain A network. The on-chain execution contract then encodes the data into a standardized cross-chain message, including a unique transaction ID (TXID_001) and the current block height of Chain A (#789000). Chain A miner nodes verify transactions through PoW consensus, package them into block #789001 and upload them to the chain, generating cross-chain event logs (including transaction hash H1 and Merkle root MR1). The deployed Chain ARelayer cluster (nodes R1-Rn) listens to block events of each block of the Chain A full nodes, filters CrossChainEvent events, and captures cross-chain events in block #789001 in real time. Using lightweight SPV verification technology, it extracts the Merkle path proof (path depth 3, node H1→H2→MR1) from the block header, verifies the legality and finality of transaction H1 on Chain A, filters duplicate requests, and encapsulates the data packet DP1 (including Chain A block header BH_A, transaction proof TP1, and cross-chain message).

[0038] Step 3: Relay and Preliminary Verification of Cross-Chain Data to the Relay Chain. Relayer node RA1 pushes data packet DP1 to the entry contract (contract address CR1) of the relay chain. The relay chain verification module performs the following operations: First, format verification: verifying the integrity of DP1 fields (transaction ID, target chain identifier, signature) and whether the PoW difficulty value of block header BH_A of chain A conforms to the current network rules; Second, finality confirmation: checking whether the number of confirmations for block #789001 of chain A exceeds 6 blocks (ensuring no fork risk); Third, signature verification: verifying the validity of the transaction signature using the public key PK_A of chain A. If the verification passes, DP1 is marked as "pending" and stored in the relay chain temporary storage pool.

[0039] Step 4: Relay Chain Transaction State Verification and Relay Synchronization. The relay chain calls ZK-SNARK to verify the contract (contract address CRZ1). Based on the Merkle root MR1 and transaction proof TP1 of chain A, it generates a zero-knowledge proof ZKP1 to verify the existence of H1 in chain A block #789001. After successful verification, the relay chain writes the cross-chain information into the global state tree and generates a transaction certificate TC1 (including relay chain block height #1000, timestamp T1, and multi-signature SIG_R).

[0040] Step 5: Relayer Event Listening and Relay Chain Data Capture and Message Distribution. The deployed ChainBRelayer cluster (nodes R B1-RBm) listens to relay chain events and confirms the cross-chain target chain as Chain B based on ChainB sidechain Id2 in TC1. The ChainB Relayer group then obtains TC1, ZKP1, and the relay chain block header BH_R from the event and relay chain RPC interface. The Relayer group reconstructs the data into a ChainB-compatible instruction packet IP1, including: the target chain contract address (ChainB cross-chain contract CB1); ABI-encoded parameters including the Merkle proof of the transaction on the relay chain, the transaction block header and consensus node signature, and serialized cross-chain information (including: the business contract address CB2 on ChainB, the receiving contract method name CB2 hear, and the cross-chain information "Hello world"); and ChainB transaction pre-calculation parameters (Gas Limit=50000, Gas Price=20 Gwei, Nonce=15). The transaction hash BH1 is obtained.

[0041] Step Six: Target Chain Triggers On-Chain Contract Instruction Verification. After receiving IP1, the Chain B verification node executes two steps: First, relay chain identity verification. The cross-chain management contract CB1 verifies the relay chain's cross-chain transaction Merkle proof, including the transaction block header and consensus node signature SIG_R, and combines this with the current relay chain BookKeeper information stored in the contract to verify whether the cross-chain data comes from the relay chain managed by BookKeeper and has been executed, ensuring data trustworthiness. Second, business contract execution. The cross-chain management contract CB1 deserializes the cross-chain information to obtain the business contract address CB2 on Chain B, the receiving contract method name CB2 hear, and the cross-chain information "Hello world". Within CB1, the CB2hear method of the business contract CB2 is called, passing in the cross-chain information "Hello world", generating the corresponding event, and transmitting the cross-chain information to the target location.

[0042] Step 7: Cross-chain transaction final state feedback and exception rollback. Chain B Relayer, based on the transaction hash BH1 obtained in Step 5, calls the RPC interface of the full node on Chain B to query the transaction status. If the transaction status corresponding to transaction hash BH1 is still pending within the preset timeout window (e.g., 120 blocks) on Chain B, it returns to the instruction packet IP1 generated in Step 5, modifies the Gas Price to twice the original value (40 Gwei), keeps the Nonce value unchanged, and resubmits the transaction to Chain B. It continues to query the transaction status based on the transaction hash, repeating this process until the transaction status is either successful or failed. If the transaction is successful, the execution result H2 is sent back to the relay chain, and the relay chain updates the TC1 status to "completed." If the transaction status fails, the relay chain triggers a rollback contract (address CR2), and the Chain A Relayer cluster (nodes R1-Rn) sends the execution result information to the Chain A cross-chain management contract CA1. CA1 updates the cross-chain status to either failure or success based on the unique cross-chain transaction ID, ensuring the atomicity of the entire cross-chain process.

[0043] This example demonstrates that the lightweight interoperability method for heterogeneous blockchain environments enables secure and efficient cross-chain operations between heterogeneous chains without modifying the native protocols of Chain A and Chain B, and supports automatic rollback in case of anomalies, ensuring the atomicity of cross-chain transactions.

[0044] The above embodiments are merely illustrative of the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solutions based on the technical concept proposed in this invention shall fall within the scope of protection of this invention.

Claims

1. A lightweight interoperability method for heterogeneous chain environments, characterized in that, The method includes the following steps: Step 1: Cross-chain configuration initialization: Initialize cross-chain transactions; Step 2: Relayer event listening and source chain data capture: The user calls the cross-chain smart contract of the source chain and waits for the cross-chain transaction of the source chain to be settled. The Relayer listens for the cross-chain information of the source chain. Users invoke the cross-chain smart contract deployed on the source chain, passing in the target chain identifier, target chain contract information and transfer data, triggering transaction signing and submitting it to the source chain network, waiting for node consensus verification and block confirmation, and the contract encodes the data into a standard cross-chain message; the Relayer cluster scans cross-chain transaction events in the new block in real time, extracts transaction hashes, Merkel path proofs and cross-chain message metadata, and filters invalid or duplicate requests. Step 3: Relay and preliminary verification of cross-chain data to the relay chain: Transmit the necessary information of the cross-chain data to the relay chain and continue the preliminary verification; Step 4: Relay Chain Transaction State Deep Verification and Relay Synchronization: Verify the legality of cross-chain information. Once passed, unify the state information of the source chain and perform relay synchronization. The relay chain calls the built-in verification logic to verify the existence and legality of the source chain transaction in the Merkle tree. Once passed, write the cross-chain transaction state into the relay chain's global state tree and generate a transaction certificate carrying multi-chain signatures. Step 5: Relayer Event Listening and Relay Chain Data Capture and Message Distribution: The relay chain generates corresponding cross-chain information executable instruction packages. The Relayer listens for cross-chain information from the relay chain and distributes messages to the target chain. Based on the target chain identifier in the transaction certificate, the relay chain generates transaction certificates and associated proofs. The Relayer cluster scans the relay chain cross-chain transaction events in new blocks in real time, extracting transaction hashes, Merkel path proofs, and cross-chain message metadata, filtering out invalid or duplicate requests. The Relayer group performs secondary encapsulation on the data, adding target chain-compatible protocol headers to form executable instruction packages. Step Six: Target Chain Triggers On-Chain Contract Instruction Verification: After receiving the instruction packet, the target chain node calls the target chain's cross-chain contract to parse the instruction. First, it verifies the Merkel proof of the cross-chain transaction in the relay chain, including the transaction block header and consensus node signature. Combined with the BookKeeper information of the current relay chain consensus ledger administrator stored in the contract, it verifies whether the cross-chain data comes from the relay chain managed by the consensus ledger administrator BookKeeper and has been executed, ensuring data credibility. After the verification is passed, it executes the state update or inter-chain callback. Step 7: Cross-chain transaction final state feedback and exception rollback: The target chain will send the execution result back to the relay chain through the Relayer. If an exception occurs, the rollback mechanism will be triggered.

2. The lightweight interoperability method for heterogeneous chain environments according to claim 1, characterized in that: In step one, the cross-chain management contracts for the source chain, target chain, and relay chain are initialized and configured.

3. The lightweight interoperability method for heterogeneous chain environments according to claim 1, characterized in that: In step three, Relayer pushes the captured cross-chain data packets to the relay chain entry contract to invoke the transaction; the relay chain verification module first verifies the compliance of the data format and verifies whether the source chain block header has reached a final consensus to eliminate the risk of fork.

4. The lightweight interoperability method for heterogeneous chain environments according to claim 1, characterized in that: In step seven, the target chain sends the execution result back to the relay chain via the Relayer, and the relay chain updates its global state to "completed". If the target chain fails to execute, the relay chain initiates a timeout rollback mechanism, sends an unlocking instruction to the source chain, triggers the unfreezing of the source chain's smart contract assets, and ensures cross-chain atomicity.

5. A lightweight interoperability system for heterogeneous blockchain environments, the system being based on the method described in claim 1, characterized in that, include: Source Chain Module: Used to perform cross-chain transaction initialization and data encapsulation, including cross-chain smart contracts and transaction signature modules; Relayer cluster: Used to listen to cross-chain events on the relay chain and sidechains, capture cross-chain data, and filter invalid requests; Relay Chain Module: Includes entry contract, verification module and state tree, used to verify the legality of cross-chain data and generate transaction credentials; Target Chain Module: Used to receive transaction message instructions distributed by Relayer, verify them, execute cross-chain contract operations, and provide feedback on the execution results or trigger a rollback mechanism.

6. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein the program, when executed, controls the device where the non-volatile storage medium is located to perform the method described in any one of claims 1 to 4.

7. A terminal device, characterized in that, The terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the method as described in any one of claims 1-4 above.

Images