A blockchain cross-chain method based on a BSN cross-chain communication hub

Abstract

The application discloses a kind of based on BSN cross-chain communication hub's blockchain cross-chain method, belong to blockchain technical field.The method relies on the BSN cross-chain communication hub of double-layer architecture and IBC protocol, provides standardized cross-chain service for user.After user opens service, system automatically allocates chain ID and manages contract address;User develops and deploys business application contract according to specification;Source chain application contract passes through calling cross-chain management contract, is forwarded to target chain by hub relay chain and relayer, and cross-chain information is transmitted to target chain;After target chain management contract verifies information, corresponding application contract is called to complete cross-chain interaction.The application realizes the safe, convenient interoperation between heterogeneous chain, user does not need to realize underlying cross-chain protocol, only needs to focus on business contract development, effectively reduces cross-chain complexity and development cost.

Description

Technical Field

[0001] This invention belongs to the field of computer technology and relates to blockchain technology, specifically a blockchain cross-chain method based on the BSN cross-chain communication hub. Background Technology

[0002] Blockchain technology is considered the cornerstone of the digital economy and has been widely applied in fields such as digital finance, the Internet of Things, supply chain management, product traceability, and digital asset trading, becoming an important tool for promoting high-quality development in various regions. With the widespread application of blockchain technology, different blockchain networks, such as public chains, private chains, and consortium chains, coexist in large numbers. However, their independence hinders the circulation of assets and data, creating "value silos." The need for data sharing between different blockchain applications is becoming increasingly urgent. Cross-chain technology is the process of interoperating ledger data between two or more blockchain networks, enabling the transfer and exchange of data, assets, and information. In a blockchain service network, each application chain maintains its own transaction, consensus, and ledger processing system, carrying data information from different application businesses. Cross-chain mechanisms enable data sharing and business collaboration between application chains, breaking down the "island" situation between chains, ensuring the secure and reliable flow of data across multiple application chains, and achieving interoperability. The main functions of cross-chain technology include: cross-chain registration management mechanisms, cross-chain contract functions, cross-chain transaction verification, cross-chain message routing protocols, and cross-chain transaction atomicity guarantees. Different blockchains differ in system architecture, consensus mechanisms, and data formats, making the design and implementation of cross-chain technology extremely complex. Cross-chain technology itself also needs to handle a large number of cross-chain transactions and data interactions, placing higher demands on system performance and scalability. If blockchain cross-chain technology cannot effectively address performance bottlenecks, it may limit the large-scale application and development of blockchain.

[0003] Currently, cross-chain technology lacks unified standards and specifications, resulting in poor interoperability between different projects. This limits the promotion and application of cross-chain technology, necessitating the establishment of standardized cross-chain protocols, contracts, and interfaces to achieve seamless interoperability between different blockchains. Furthermore, cross-chain operations involve the transfer and sharing of assets and data, posing security risks and privacy breaches. There is an urgent need for a cross-chain method that provides convenient, secure, reliable, and universal cross-chain support for various homogeneous / heterogeneous chains. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain cross-chain method based on the BSN cross-chain communication hub, to solve the problems of difficult cross-chain interoperability and insufficient compatibility faced by various existing homogeneous / heterogeneous blockchain networks. This invention can achieve its purpose through the following technical solutions:

[0005] An Interchain Communications Hub, a blockchain cross-chain communication system, is characterized by comprising: a relay chain, built based on a preset cross-chain protocol, for verifying the validity of cross-chain messages; at least one relayer for monitoring cross-chain events on the source blockchain, capturing cross-chain data packets and their corresponding on-chain proofs, submitting the data packets and proofs to the relay chain, and forwarding data packets from the relay chain to the target blockchain; and a cross-chain management contract deployed on each participating blockchain for interacting with business application contracts on the respective blockchain to generate or verify the cross-chain data packets and their on-chain proofs.

[0006] The cross-chain mechanism adopts the COSMOS IBC protocol to ensure that data packets can be transmitted securely and reliably in heterogeneous systems. The Poly Enterprise cross-chain service integrates four blockchain frameworks: Fabric, FISCO BCOS, Ethereum, and Neo, and supports cross-chain communication between consortium blockchains Fabric, FISCO BCOS, ETH testnet, NEO testnet, and open consortium blockchains Taian Chain and Wuhan Chain.

[0007] This invention also discloses a blockchain cross-chain method based on the BSN cross-chain communication hub, characterized in that the method includes the following steps:

[0008] Step 1: Service Activation and Registration Steps: The service provider, namely the BSN operation and maintenance system, receives the user's request to activate cross-chain services for at least two blockchains and assigns a globally unique chain ID to each blockchain that the user accesses.

[0009] Step 2: Contract Deployment Steps: The service provider provides the user with a standard cross-chain management contract (CCMC) code template, and after the user successfully deploys CCMC on each blockchain, it receives the CCMC contract address submitted by the user and completes the binding and registration of the address with the corresponding chain ID.

[0010] As a preferred embodiment of the present invention, the management contract in step two should include the following contract implementations: ETH, FISCO, NEO, Fabric and testnet cross-chain management contract addresses, as shown in Table 1.

[0011] Table 1

[0012]

[0013] Step 3: Business Contract Deployment Steps: The service provider receives the address information of the business application contract submitted by the user, which is developed and deployed on the source chain and the target chain according to the cross-chain application interface specification, and completes the association configuration. The cross-chain application interface specification defines the cross-chain call interface that the business application contract needs to implement, including the interface for initiating cross-chain and the interface for receiving cross-chain calls.

[0014] Step 4: Cross-chain transaction initiation processing steps: After the business application contract of the source chain initiates a cross-chain call, the business data is encapsulated into a standard cross-chain data packet through the cross-chain management contract of the source chain, and on-chain proof is generated based on the state of the source chain;

[0015] Step 5: Cross-chain routing and verification steps: The cross-chain data packet and proof are submitted to the relay chain for validity verification through the relay. After successful verification, the data is routed to the target chain.

[0016] Step Six: Target Chain Transaction Execution (Inbound); The cross-chain management contract receives and verifies the received cross-chain information through the BSN cross-chain communication hub. Then, the management contract calls the target chain application contract to pass the specified information to the target chain application contract, thus achieving Inbound.

[0017] As a preferred embodiment of the present invention, the BSN cross-chain communication hub described above should support application scenarios with eventual consistency requirements for transactions, and also support application scenarios with strong consistency requirements for transactions. It can support any transaction and can be scaled to any number of chains.

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

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

[0020] Beneficial effects

[0021] 1. Universality and Security: By mandating the adoption of standardized CCMC contracts and IBC data formats (technical means: standard adaptation layer), the adaptation work for heterogeneous chains is converged at the CCMC implementation layer, providing a unified interface to the upper layers. Dual verification is performed using relay chain consensus and cryptographic proofs (Merkel proofs) (technical means: decentralized trusted verification), ensuring that cross-chain information is not tampered with during transmission and that operations on the source chain do indeed occur, thus guaranteeing security from a mechanism perspective.

[0022] 2. Convenience and Low Coupling: Users (application developers) do not need to deploy and maintain complex relay chain networks and relay clusters. They only need to "activate the service" like using a cloud service, and then focus on developing the business contract logic that implements cross-chain call initiation and cross-chain transaction callbacks. The business contract is decoupled from the complex underlying cross-chain protocol.

[0023] 3. Scalability: The architecture is horizontally scalable. Adding a new blockchain type only requires developing a CCMC adaptation contract compliant with the IBC specification for that chain. Adding a new business chain only requires deploying a new CCMC instance and registering it. The relay chain and relayer do not need to be modified for each new business. Attached Figure Description

[0024] Figure 1 This is a diagram of the BSN cross-chain communication hub architecture in this invention;

[0025] Figure 2 This is a flowchart of the blockchain cross-chain method based on the BSN cross-chain communication hub in this invention. Detailed Implementation

[0026] The following section uses FISCO BCOS cross-chain communication based on the BSN cross-chain communication hub as an example to further illustrate the technical solutions in this embodiment of the invention.

[0027] like Figure 1 As shown, the BSN cross-chain communication hub upon which this invention relies is a distributed system built on the Cosmos IBC (Inter-Blockchain Communication) protocol standard. This system employs a heterogeneous chain cross-chain protocol and a two-layer structure design, using a relay chain as a cross-chain coordinator, multiple heterogeneous chains as cross-chain transaction executors, and a Relayer as a tool for transporting cross-chain information.

[0028] The BSN cross-chain communication hub, upon which this system relies, is an inter-blockchain communication infrastructure built on the Cosmos IBC (Inter-Blockchain Communication) protocol. Its architecture includes:

[0029] (1) Interchain: A public or consortium blockchain developed based on the Cosmos SDK and using the Tendermint consensus mechanism. Its core responsibility is to act as a verifiable state machine and routing hub. For each connected blockchain (such as FISCO BCOS chain A and chain B), the interchain maintains a corresponding "light client" state. This state is not the full ledger, but rather periodically updated block header information, especially the state root. The interchain ensures that all participants reach a consensus on the light client state of each connected chain through its consensus mechanism.

[0030] (2) Cross-Chain Management Contract (CCMC): This is a standardized smart contract template that conforms to the IBC protocol standard and implements light client verification logic. After deployment, users need to submit their contract address on the BSN service portal to complete registration. The BSN system will bind the address with a globally unique chain ID, thereby identifying the chain and its access point in the cross-chain network. CCMC is a bridge connecting business applications and the cross-chain hub, and it implements the following core functional logic internally:

[0031] Proof generation logic: When a cross-chain transaction needs to be initiated, this logic can construct a "proof of commitment" that conforms to the IBC standard based on specific on-chain data (such as an event log) and the current block height. This proof is essentially a Merkle proof, used to confirm to the verifier that "a certain piece of data exists in the state tree of a specific block".

[0032] Proof verification logic: When a cross-chain data packet is received from the relay chain, this logic can verify the validity of the attached proof based on the block header (light client state) of the counterpart chain provided by the relay chain.

[0033] The IBC protocol processing logic is responsible for encapsulating the business data transmitted from the business application contract into a standard IBC data packet with a fixed structure. This data packet structure typically includes the following fields: sequence number, source chain identifier, target chain identifier, source port identifier, target port identifier, timeout timestamp, and business data payload.

[0034] Event triggering logic: After the proof generation and data packet encapsulation are completed, a structured on-chain event will be triggered for the repeater to listen for and capture.

[0035] (3) Relayer: An independently running background daemon. It is an automated information transfer service. Each relay can be configured to listen to CCMC events of multiple chains. Its main workflow is: listen -> capture -> construct transaction -> commit. It continuously listens to specific events issued by the on-chain CCMC contract it is responsible for through the remote call interface of the blockchain node.

[0036] The core of this invention lies in providing a standardized service activation and contract interaction method based on the aforementioned hub, enabling users to quickly realize cross-chain business without having to worry about the complex deployment of the hub's underlying layer and relay chain.

[0037] The cross-chain mechanism adopts the COSMOS IBC protocol to ensure secure and reliable transmission of data packets across heterogeneous systems. In a preferred embodiment, a cross-chain service middleware compliant with the IBC standard, such as Poly Enterprise, can be used to integrate and adapt the four blockchain frameworks: Fabric, FISCO BCOS, Ethereum, and Neo. This supports cross-chain communication between consortium blockchains Fabric, FISCO BCOS, the ETH testnet, the NEO testnet, and the open consortium blockchains Taian Chain and Wuhan Chain.

[0038] FISCO BCOS is a stable, efficient, and secure blockchain platform. Led by WeBank and the China Blockchain Alliance, it adopts a consortium blockchain architecture and integrates various technologies such as distributed architecture, distributed storage, peer-to-peer network protocols, encryption algorithms, consensus algorithms, smart contracts, and virtual machines. It boasts advantages such as high performance, security and controllability, and rich functionality. It has been widely used in finance, healthcare, education, culture, social governance, and other fields, becoming an important underlying blockchain framework for promoting blockchain applications in various regions and sectors.

[0039] This embodiment will use the present invention to achieve cross-chain communication between two FISCO BCOS blockchains. The BSN cross-chain communication hub used is as follows: Figure 1 As shown, the specific workflow is as follows: Figure 2 As shown:

[0040] Step 1: Service activation and system initialization.

[0041] Users apply for cross-chain service activation on the BSN service portal for a specific business scenario (e.g., asset locking on chain A and asset minting on chain B). The BSN operations and maintenance system generates a globally unique service identifier for this service instance. Users need to obtain the CCMC standard contract code for the standard cross-chain management contract used for chain A and chain B respectively.

[0042] Step 2: Deployment and registration of cross-chain management contracts.

[0043] Users deploy the obtained CCMC contracts on both Chain A and Chain B. Upon successful deployment, each contract will have a unique address. Users then submit these two addresses on the BSN portal. The BSN system performs the following operations:

[0044] 1. Verify the validity of the contract address and the code compliance.

[0045] 2. Assign a globally unique chain identifier A to chain A, and assign a chain identifier B to chain B.

[0046] 3. On the system database and relay chain, bind and register the service identifier, chain identifier A with its CCMC address, and chain identifier B with its CCMC address. Essentially, this step establishes identity and routing tables for these two chains and their gateway (CCMC) in the cross-chain network, as shown in Table 2.

[0047] Table 2

[0048]

[0049] Step 3: Development and deployment of business application contracts.

[0050] Users develop two smart contracts based on their business logic: one deployed on chain A (called the asset locking contract) to lock assets; and one deployed on chain B (called the asset minting contract) to mint assets. Both contracts must conform to the cross-chain application interface specifications provided by BSN, i.e., implement specific functional interfaces.

[0051] For the asset locking contract of the source chain (Chain A), a cross-chain call initiation interface needs to be implemented. In one specific embodiment, this interface follows the function specification called sendCrossChainMessage, whose parameters include at least: target chain ID (targetChainID), business contract address on the target chain (targetContract), and encoded business payload (payload). Its internal execution logic includes: first, performing an asset locking operation and updating the state record within the contract; second, encoding the target user address and the amount of locked assets into a byte sequence according to a predetermined rule as the cross-chain business payload; and finally, calling the standard interface for sending data packets in the cross-chain management contract deployed on this chain, passing in the target chain identifier, the predefined target business port identifier, the business payload, and the timeout timestamp.

[0052] For the asset minting contract of the target chain (Chain B), a cross-chain transaction callback interface needs to be implemented. In one specific embodiment, this interface follows the function specification called handleCrossChainMessage, and its parameters include at least: source chain ID (sourceChainID), source chain business contract address (sourceContract), and business payload (payload). The calling permission for this interface should be limited to the cross-chain management contract of this chain. This interface should at least accept the source chain identifier and the business payload byte sequence as input parameters. Its internal execution logic includes: first, decoding the business payload according to predetermined rules to parse out the user address and asset quantity; then, performing the asset minting operation and updating the contract state.

[0053] Users deploy asset locking contracts and asset minting contracts to Chain A and Chain B respectively, and associate their contract addresses with service identifiers on the BSN portal.

[0054] Step 4: Cross-chain transaction initiation and proof generation (Outbound). The service provider's system responds and processes the cross-chain transaction initiation:

[0055] 1. The user calls the cross-chain call initiation interface of the asset locking contract on chain A.

[0056] 2. After the contract interface completes the business logic (asset locking), it calls the data packet sending interface of the standard cross-chain management contract CCMC (Cross-Chain Management Contract) of Chain A.

[0057] 3. The CCMC's data packet sending interface internally executes the following sub-steps:

[0058] a. Packet encapsulation: Construct the incoming parameters into a standard IBC packet structure.

[0059] b. State commitment storage: Calculate the hash value of the IBC packet as a commitment and store the commitment value in a specific state storage path of chain A. This path is usually determined by elements such as port, channel and sequence number.

[0060] c. On-chain proof generation: CCMC uses the interface provided by its blockchain to obtain the state root of the block currently in which the transaction is located and generates a Merkel proof. This proof confirms that the commitment value stored in the previous step does indeed exist in the state tree of this block. This set, consisting of the commitment, the Merkel proof, and the block height, constitutes the "on-chain proof".

[0061] d. Event Trigger: CCMC triggers an event containing the IBC data packet, commitment, Merkel proof, and block height information.

[0062] Step 5: Relay & Verify Cross-Chain Information.

[0063] 1. Listening and Capturing: The relayer responsible for listening to chain A captures the aforementioned events triggered by CCMC by subscribing to the event log. It extracts the IBC data packet, commitment, Merkel proof, and block height completely from the event.

[0064] 2. Submission to Relay Chain: The relayer constructs and submits a transaction to the relay chain. The core of this transaction is to submit a verification request, declaring the existence of a specific commitment at a specified block height on chain A, and attaching the corresponding Merkle proof, requesting the relay chain to verify it based on the block header of chain A at that height, which it maintains.

[0065] 3. Relay Chain Verification: The relay chain's verification module processes the transaction: After the relayer in the system detects the CCMC-triggered event, it captures the data packet and proof, and submits them to the system's relay chain for verification. Once verification is successful, the relay chain routes the transaction to the target chain (Chain B). The specific verification process is as follows:

[0066] Query the block header (including the state root) of chain A at a specified height, which is maintained internally and confirmed by consensus.

[0067] Using the state root and the Merkel proof provided by the repeater, recalculate the Merkel hash path of the commitment. If the calculated result matches the commitment submitted by the repeater, it proves that the IBC packet was indeed genuinely committed on chain A, and the verification passes.

[0068] Once the verification is successful, the relay chain records the IBC data packet and the successful verification information in its own ledger and triggers an event indicating that "a data packet destined for the target chain (chain B) is ready".

[0069] Step Six: Target Chain Transaction Execution (Inbound).

[0070] 1. Listening and capturing (target chain side): The repeater responsible for chain B listens to the relay chain and captures the "packet ready" event.

[0071] 2. Relay to Target Chain: The relayer constructs and submits a transaction to the CCMC of Chain B. The transaction contains: an IBC data packet from the relay chain, and proof that the relay chain has verified the data packet through the source chain (e.g., a Merkel proof of a block header of the relay chain itself).

[0072] 3. Target Chain CCMC Verification: After receiving the transaction, Chain B's CCMC contract executes the verification logic:

[0073] By utilizing the relay chain light client state that it maintains or can query, verify the validity of the "data packet verified" proof provided by the relayer.

[0074] Check whether the timeout, target port identifier, and other information in the IBC packet match the local registration information.

[0075] 4. Calling the business contract: Only after all verifications are passed will Chain B's CCMC call the cross-chain transaction callback interface of the business contract address (i.e., the asset minting contract) associated with the target port identifier in the IBC data packet, and pass the business payload in the data packet to it.

[0076] 5. Business Execution: The cross-chain transaction callback interface of the asset minting contract is executed, completing the asset minting logic for the corresponding user. At this point, a complete cross-chain transaction is atomically completed.

[0077] The system verifies the received data packets through the CCMC of the target chain (Chain B), and after successful verification, automatically calls the target chain business application contract pre-configured and associated by the user to complete the final cross-chain business logic.

[0078] The above, with specific embodiments, elaborates in detail the blockchain cross-chain method and system architecture based on the BSN cross-chain communication hub provided by the present invention. The embodiments, taking asset cross-chain transfer between two FISCO BCOS blockchains as an example, fully demonstrate the complete technical process from service activation, contract deployment, cross-chain transaction initiation to cross-chain verification and execution.

[0079] The core of this invention lies in constructing and utilizing a standardized, decentralized, and verified cross-chain communication hub. This hub consists of three main components: a relay chain, a cross-chain management contract (CCMC), and a relayer, and strictly adheres to cross-chain protocol specifications such as IBC. By encapsulating complex cross-chain protocol logic within a standardized CCMC and providing a unified development interface for business applications, this invention successfully achieves secure, reliable, and convenient interoperability for heterogeneous blockchain networks without modifying the underlying blockchain architecture. Specifically, this invention addresses the problems of "value silos," poor interoperability, implementation complexity, and security issues mentioned in the background art through the following technical means:

[0080] 1. Standardized Adaptation Layer: By deploying a unified and standardized CCMC on each chain, the technical differences between heterogeneous chains are isolated and adapted, and a consistent cross-chain call interface is provided to the upper chain.

[0081] 2. Decentralized Trusted Verification: By introducing a consensus-based relay chain as a trusted third party and utilizing cryptographic primitives such as Merkel proofs, the verifiability and immutability of cross-chain information during transmission are achieved without relying on the credit of a single centralized institution.

[0082] 3. Automated relay process: Through independently running relay programs, cross-chain event listening, proof capture, information submission and forwarding are completed automatically, freeing developers and users from tedious underlying network maintenance.

[0083] 4. Clear business layering: The underlying cross-chain protocol layer (implemented by the hub), the general adaptation layer (CCMC), and the business application layer are clearly defined, so that application developers only need to focus on the implementation of their own business logic, which greatly reduces the technical threshold and cost of cross-chain application development.

[0084] It should be noted that the above embodiments are only used to illustrate the principles and main features of the present invention, and are not intended to limit the scope of protection of the present invention. After reading the specification of this invention, those skilled in the art can make various modifications, substitutions, combinations, or adaptive adjustments to the implementation methods, operational details, supported blockchain framework types, and business application scenarios of the above embodiments without departing from the spirit and principles of the present invention. For example, the specific consensus algorithm of the relay chain, the specific implementation code of the CCMC contract on different blockchain platforms, the deployment and scheduling strategy of the relayer, and the specific function signature of the business contract interface can all be changed under the guidance of the core architecture and method flow disclosed in this invention.

[0085] Therefore, the scope of protection of this invention is not limited to the specific embodiments disclosed in the specification, but should be determined by the scope defined in the claims. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of this invention shall still fall within the scope of protection of this invention.

Claims

1. A blockchain cross-chain communication system, characterized in that, The system includes: The relay chain, built on a pre-defined cross-chain protocol, is used to verify the validity of cross-chain messages. At least one Relayer is used to monitor cross-chain events on the source blockchain, capture cross-chain data packets and their corresponding on-chain proofs, submit the data packets and proofs to the relay chain, and forward data packets from the relay chain to the target blockchain. A cross-chain management contract is deployed on each participating blockchain to interact with the business application contract on the blockchain and generate or verify the cross-chain data packet and its on-chain proof. A cross-chain management contract deployed on the source blockchain is used to respond to calls from business application contracts, generate cross-chain data packets and on-chain proofs on the source chain; A cross-chain management contract deployed on the target blockchain is used to verify cross-chain data packets and proofs from the relay chain and to invoke business application contracts on the target chain.

2. The blockchain cross-chain communication system according to claim 1, characterized in that, The preset cross-chain protocol is COSMOS's IBC protocol.

3. The blockchain cross-chain communication system according to claim 1 or 2, characterized in that, The cross-chain management contract is a standard contract that conforms to the IBC protocol light client verification logic. Its contract address is registered on the Blockchain Service Network (BSN) and bound to a globally unique chain ID.

4. A blockchain cross-chain method based on the system described in any one of claims 1-3, characterized in that, Performed by the service provider, including: S1. Service Activation and Registration Steps: The service provider, namely the BSN operation and maintenance system, receives the user's request to activate cross-chain services for at least two blockchains and assigns a globally unique chain ID to each blockchain that the user accesses; S2. Contract Deployment Steps: The service provider provides users with a standard cross-chain management contract (CCMC) code template, and after the user successfully deploys CCMC on each blockchain, it receives the CCMC contract address submitted by the user and completes the binding and registration of the address with the corresponding chain ID. S3. Business Contract Deployment Steps: The service provider receives the address information of the business application contract submitted by the user, which is developed and deployed on the source chain and the target chain in accordance with the cross-chain application interface specification, and completes the association configuration; S4. Cross-chain transaction initiation processing steps: After the business application contract of the source chain initiates a cross-chain call, the business data is encapsulated into a standard cross-chain data packet through the cross-chain management contract of the source chain, and on-chain proof is generated based on the state of the source chain. S5. Cross-chain routing and verification steps: The cross-chain data packet and proof are submitted to the relay chain for verification through the relay, and after the verification is passed, the data is routed to the target chain; S6. Cross-chain transaction execution steps: Verify the cross-chain data packet through the cross-chain management contract of the target chain, and after successful verification, call the business application contract of the target chain to execute the predetermined business logic.

5. The method according to claim 4, characterized in that, In step S3, the cross-chain application interface specification includes: The first interface function used by the source chain business application contract to initiate cross-chain transactions shall include at least the target chain ID, the target contract address, and the business load as its parameters. The second interface function is used for the target chain business application contract to receive and process cross-chain transactions. Its parameters include at least the source chain ID, the source contract address, and the business load.

6. The method according to claim 4, characterized in that, In step S2, the standard cross-chain management contract supports multiple heterogeneous blockchain frameworks, including Fabric, FISCO BCOS, Ethereum, and Neo.

7. The method according to claim 4, characterized in that, In step S4, the generation of on-chain proof includes: generating a commitment proof about the cross-chain data packet and its block height by the cross-chain management contract of the source chain.

8. The method according to claim 4, characterized in that, The relay captures data by listening to events triggered by the cross-chain management contract that contain the cross-chain data packets and proof information.

9. 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 method of claim 4.

10. 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 claim 4 above.

Images