A blockchain general abstract interface for multi-chain fusion

Abstract

The application discloses a kind of block chain general abstract interface for multi-chain fusion, it is related to blockchain technology field, the abstract interface mainly includes: target chain container loading module, for: after the received multi-chain synchronization verification data packet is parsed, determine the virtual machine corresponding to each target chain and load the container of the virtual machine;Cross-chain synchronization verification module, for: using the container loaded the virtual machine, change blockchain ledger state.The application achieves the purpose of compatible multiple heterogeneous blockchains while not needing to consider the specific contract language and virtual machine architecture of target chain, i.e. native complete contract execution of corresponding heterogeneous blockchain.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a general abstract interface for blockchain that is oriented towards multi-chain integration. Background Technology

[0002] Since the birth of the first blockchain, over 5,600 open-source blockchain systems and as many as 60,000 blockchain projects have emerged. However, these different blockchain systems differ significantly in security and privacy mechanisms, data throughput, and scalability, thus limiting the inherent openness of blockchain itself. The isolation of blockchain systems stems primarily from the substantial differences in their underlying technologies, leading to each system operating independently and creating technological barriers that hinder direct interoperability. Therefore, a bridge is needed to connect these different blockchain systems, break down these technological barriers, and enable the interconnection of data across different blockchains.

[0003] To achieve the goal of inter-chain value exchange, existing cross-chain systems mainly use three mainstream methods for cross-chain contract calls: hash locking mechanism, introduction of third parties, and sidechain mechanism.

[0004] Hash locking mechanisms utilize hash locks and time locks to ensure the atomicity of cross-chain data interactions. This means that data interaction can only be completed if certain time and hash conditions are met. However, hash locking can only perform exchanges and not data or information transfers, thus limiting its application scenarios. HTLC, on the other hand, is a concrete implementation of the atomic swap protocol.

[0005] Because hash locking uses time locks to limit the time of data interaction, it can complete cross-chain interactions faster. While this method can achieve cross-chain functionality, it is only suitable for data exchange between different blockchains and cannot support broader contract calls and verification tasks. Furthermore, the blockchain network must possess three characteristics: 1. There must be corresponding key data on-chain, meaning each user needs specific attributes; 2. The blockchain must support smart contract functionality to establish a hash locking mechanism and build trust; 3. Both parties involved in the data interaction must possess their own characteristic data in the two blockchain networks requiring cross-chain communication. Therefore, these characteristics limit its application in cross-chain blockchain communication, necessitating the development of a more universal cross-chain method that supports a wide range of contract calls.

[0006] The most common third-party strategy is the notary mechanism, where one or a group of nodes act as notaries to collect and verify data interactions. The notary tracks the state of both chains and informs the other, with both parties relying entirely on the notary for verification and interaction. If blockchains A and B cannot directly interoperate, they can introduce a mutually trusted third party as an intermediary to verify and forward cross-chain messages.

[0007] Ripple proposed a third-party cross-chain protocol called Interledger. Under this protocol, senders and receivers in different systems can interact across chains through one or more connectors, which provide data forwarding services. By providing escrow for the participants in the cross-chain data interaction, the corresponding data is only sent to the connector upon receiving proof that the receiver has received the data. Simultaneously, it guarantees that the connector will receive the data from the sender after fully executing the protocol. Its protocol architecture involves a three-way sequential interaction: the sender sends a cross-chain request, the connector verifies the trustworthiness of both parties and allows the cross-chain interaction, and the receiver receives equivalent feature data, thus completing the cross-chain process.

[0008] The advantage of introducing a third party is that it supports cross-chain communication between heterogeneous blockchains. The disadvantage is that it carries the risk of centralization, and it can only achieve the exchange between single data types. It cannot achieve the invocation of related contracts, nor can it achieve the overall transfer of related data.

[0009] A sidechain mechanism is a blockchain that verifies data from another blockchain, enabling the mapping of certain characteristic data between the main chain and the sidechain.

[0010] In existing projects, Cosmos uses a combination of sidechains and notaries to achieve cross-chain functionality, while Polkadot employs a structure of relay chains, parachains, and bridges. Taking Polkadot as an example, its architecture places the relay chain at the center of the network, handling overall consensus and security. Parachains, a type of sidechain, connect to the relay chain to access the Polkadot network, sharing the mainnet's computational workload. Bridges connect independent blockchains to the Polkadot network, enabling cross-chain operations through parachains, bridge contracts, or native built-in bridge interfaces. Cross-chain communication between parachains primarily utilizes ICMP (Inter-Chain Message Passing), which defines a trustless message passing mechanism between parachains and the relay chain. However, the entire process relies entirely on the Polkadot network's architecture and the corresponding relay and parachain mechanisms. The ICMP process involves the initiator leveraging the similarity between relay chains and parachains to perform contract verification and forwarding on the relay chain, thereby executing the relevant cross-chain contract on the chain requiring cross-chain communication and completing the communication.

[0011] The biggest advantage of the sidechain mechanism is that it eliminates the need for a trusted third party to monitor and verify the relevant data interactions. At the same time, more extensive and general smart contracts can be executed on the sidechain, rather than just the exchange of a single type of data. However, the two chains that achieve cross-chain goals using the sidechain mechanism are basically isomorphic, which limits the application scope of cross-chain using the sidechain, and this is also the biggest drawback of the sidechain mechanism.

[0012] In summary, existing cross-chain projects require negotiation with the target chain, including reaching protocol consensus, establishing a trusted intermediary for consensus, and receiving confirmation from the sidechain back to the target chain. These solutions share a common problem: they are limited by the architecture of the target chain's contracts and underlying virtual machine. When the target chain's contract language changes or its virtual machine is upgraded, the corresponding cross-chain solution becomes unusable. Therefore, a universal solution compatible with multiple chains is needed for cross-chain operations. Summary of the Invention

[0013] The purpose of this invention is to provide a general abstract interface for blockchain that is oriented towards multi-chain integration. It is a general abstract interface that is compatible with multiple chains and can perform cross-chain operations.

[0014] To achieve the above objectives, the present invention provides the following solution:

[0015] A general abstraction interface for blockchains oriented towards multi-chain integration includes:

[0016] The target chain container loading module is used for:

[0017] After parsing the received multi-chain synchronization verification data packets, the virtual machine corresponding to each target chain and the container that loads the virtual machine are determined.

[0018] The cross-chain synchronous verification module is used for:

[0019] The state of the blockchain ledger is changed using a container that houses the virtual machine.

[0020] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0021] This invention provides a general abstract interface for blockchains that are oriented towards multi-chain integration, and a pluggable general heterogeneous contract cross-chain execution method. It achieves compatibility with multiple heterogeneous blockchains without considering the specific contract language and virtual machine architecture of the target chain, that is, it natively completes the contract execution of the corresponding heterogeneous blockchain. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the underlying model of the blockchain general abstract interface for multi-chain integration of the present invention;

[0024] Figure 2 This is a flowchart of the target chain container loading module of the present invention;

[0025] Figure 3 This is an architecture diagram of the cross-chain state synchronization verification module of the present invention;

[0026] Figure 4 This is a flowchart of the cross-chain state synchronization verification module of the present invention. Detailed Implementation

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

[0028] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] The ultimate goal of this invention is to enable the local execution of applications (dApps) on other blockchains, achieving local compatibility with programs on other blockchains. These applications are essentially contract code, and the contract code for on-chain applications is actually stored on the blockchain's global ledger (full-node multi-chain synchronization verification data packets). It's worth noting that the entry point for running these dApps lies in the data exchange form within the block. This data exchange form contains the contract code, and the blockchain actually runs the contract code once during synchronization verification. If the consistency verification is successful, consensus is reached, and the next block is processed. The specific executor of the contract code within the data exchange form is the blockchain virtual machine.

[0030] This invention is actually a one-way compatible universal infrastructure. By being compatible with multiple target blockchains, it enables the contract code on the target chain to run directly locally. Theoretically, it can be compatible with blockchains of any smart contract virtual machine architecture.

[0031] The shortcomings of existing solutions and how this application improves upon them: As mentioned in the background section, existing cross-chain solutions are limited by the target chain contract and the underlying virtual machine architecture. A general abstract interface for multi-chain integration is needed to adapt to the architecture of any chain and run on-chain contract code.

[0032] The solution delivers the following intuitive benefits: In the current multi-chain world, messages between chains are independent, and inter-chain contract calls are not possible—meaning contracts on target chains A and B cannot be run on the local chain C. This solution, through its designed generic abstract interface, allows the execution of contract code on any target chain locally, and contracts from different chains can call each other.

[0033] A detailed introduction to the architecture of blockchain contracts and virtual machines: A blockchain is a globally synchronized, multi-chain, synchronously verified data packet ledger connected by hashes of blocks; that is, blockchain = multi-chain synchronously verified data packet ledger. A block is composed of n data interaction orders, each containing contract code. During the block packaging process, the first node on the entire network to execute the content of the data interaction order within the block (executes the contract code) is actually the blockchain virtual machine. After the block is packaged, it is broadcast to the entire network via the blockchain network. All nodes on the network synchronously verify it. Once verified, the block is added to the end of the blockchain. This process continues to form the blockchain. During synchronous verification, nodes actually run the contract and other content within the block completely.

[0034] Explanation of the Solution Architecture: This solution employs a container mechanism. After loading a virtual machine on the target chain and connecting it to the multi-chain synchronous verification data packet ledger of the target chain, contract code on the target chain can be executed. Theoretically, the container can load a virtual machine from any target chain and connect to a global multi-chain synchronous verification data packet ledger connected to any chain. The key to this solution lies in the execution of blockchain contracts through multi-chain integration. By being compatible with the virtual machine of any target chain, it can achieve compatibility with the execution of contracts on any target chain (provided that the multi-chain synchronous verification data packet ledger of the target chain is available), enabling the local execution of contracts on any chain. This provides an abstract interface for developing cross-chain contracts locally.

[0035] This invention designs a universal cross-chain verification mode consisting of a container, a target chain virtual machine, and a target chain state organization. This mode allows any target chain's virtual machine to execute within a container and interact with the corresponding target chain's ledger. During cross-chain operations, the target chain's virtual machine is natively migrated to the container. An interface is then established outside the container to connect to the target chain's multi-chain synchronization verification data packet. This multi-chain synchronization verification data packet stores a snapshot of the corresponding blockchain, thus connecting to the target chain's global ledger. When a block from the target chain is synchronized to the container, the block is parsed, and the corresponding container is scheduled. Inside the container, the virtual machine executes the data interaction contract within the block entirely according to the target chain's native execution mode. After all data interactions for the block are completed, the multi-chain synchronization verification data packet ledger of the target chain connected to the container is correspondingly converted to the same global state as that block on the target chain (the updated data is essentially a state update and synchronization of the target chain's global multi-chain synchronization verification data packet ledger). The external scheduling architecture can add or remove specified target chain runtime containers to achieve scheduling and maintenance of multi-chain heterogeneous contracts. Its underlying architecture is as follows: Figure 1 As shown.

[0036] Based on the above, this invention provides a general abstract interface for blockchain that is oriented towards multi-chain integration.

[0037] Example 1

[0038] This embodiment provides a general abstract interface for blockchain integration oriented towards multi-chain convergence, which mainly comprises two modules: a target chain container loading module and a cross-chain state synchronization and verification module. The target chain container loading module forms the basis for the cross-chain state synchronization module; the former can be considered the environment preparation foundation for the latter.

[0039] 1. Target Chain Container Loading Module

[0040] After parsing the received multi-chain synchronization verification data packet, the target chain container loading module creates different virtual machines for different target chains.

[0041] The specific parameters of the multi-chain synchronization verification data packet are shown in Table 1.

[0042] Table 1. Multi-chain Synchronization Verification Data Packet Parameter Design Table

[0043]

[0044] The loading of the target chain container can be divided into the following steps:

[0045] (1) Check the validity of the parameters in Table 1, and at the same time verify the target chain synchronization signature in the multi-chain synchronization verification data packet to ensure the reliability of the message source.

[0046] The following content will be analyzed:

[0047] A. Perform signature verification on the overall multi-chain synchronization verification data packet to ensure the identity of the sender of the multi-chain synchronization verification data packet as well as the integrity and availability of the data.

[0048] B. Parse the data structure within the multi-chain synchronization verification data packet: identify the chain ID to determine which chain is the target chain; confirm the initial synchronization height to facilitate the initialization of the ledger state; confirm the synchronization status parameters to determine whether to continue synchronization; and confirm whether the virtual machine is being updated.

[0049] (2) By querying the ledger DB of the corresponding blockchain in the multi-chain synchronization verification data packet, it is determined whether the state snapshot block height of the target chain stored in the current DB is lower than the target block. If it is lower than the block height required by the target chain, the synchronization program will be started to update the state snapshot in the multi-chain synchronization verification data packet so that the snapshot is synchronized to the corresponding block height.

[0050] (3) Determine the virtual machine corresponding to the target chain based on the parameters input by the user, and check whether the version is the same as the virtual machine version corresponding to the target chain. If the virtual machine of the target chain needs to be updated, upgrade the virtual machine in the backend multi-chain synchronization verification data packet.

[0051] (4) Container creation: Load the prepared target chain virtual machine into the container and link the state snapshot of the target chain stored in the multi-chain synchronization verification data packet. At the same time, open the corresponding and unified data interface to facilitate subsequent connection to the multi-chain synchronization verification data packet ledger and inter-container communication.

[0052] (5) Start the container, synchronize the target chain ledger to the block height marked by the message, and load the data.

[0053] (6) Once the environment is ready, control is handed over to the cross-chain state synchronization verification module (i.e., module 2) for scheduling and multi-chain synchronization verification.

[0054] The overall execution process described above can be found in [link to document]. Figure 2 , Figure 2The labels in the text correspond to the steps mentioned above. Solid lines represent the process flow, and dotted lines represent the data flow.

[0055] Therefore, the target chain container loading module is used for:

[0056] After parsing the received multi-chain synchronization verification data packets, the virtual machine corresponding to each target chain and the container that loads the virtual machine are determined.

[0057] The target chain container loading module includes:

[0058] Information verification unit, used for:

[0059] Verify the target chain synchronization signature in the parsed multi-chain synchronization verification data packet;

[0060] When the target chain's synchronous signature verification is successful, block height verification is initiated.

[0061] If the target chain fails to synchronize the signature verification, update the multi-chain synchronization verification data packet.

[0062] Blockchain ledger verification unit, used for:

[0063] Determine if the blockchain ledger block height is synchronized with the required verification data interaction area;

[0064] When the blockchain ledger block is highly synchronized with the required data interaction area for verification, the virtual machine version verification unit is started.

[0065] When the blockchain ledger block height does not keep up with the required data interaction area for verification, update the blockchain ledger and start the virtual machine version verification unit.

[0066] The virtual machine version verification unit is used for:

[0067] Determine if the virtual machine version matches the virtual machine version of the current target chain;

[0068] When the virtual machine version matches the virtual machine version of the current target chain, the container creation unit is started.

[0069] The container manufacturing unit is used for:

[0070] Create a container and start the container.

[0071] The container creation process involves loading the prepared target chain virtual machine into the container, linking the state snapshot of the corresponding target chain stored in the multi-chain synchronization verification data packet, and simultaneously opening a corresponding and unified data interface to facilitate subsequent connection to the multi-chain synchronization verification data packet ledger and inter-container communication.

[0072] The startup container is used to synchronize the target chain ledger to the block height marked by the message and load data.

[0073] 2. Cross-chain state synchronization verification module

[0074] After preprocessing, including loading the target chain virtual machine into the container, this method employs a cluster management tool to schedule tasks for divisible individual virtual machine containers to maximize the utilization of computer resources and ensure compatibility with multiple chains for cross-chain verification. The overall system architecture is described below. Figure 3 .

[0075] The overall architecture mainly consists of a message queue, cluster management software, executors, server clusters, and a database. The message queue stores relevant atomic data interaction verification tasks; the cluster management software manages the executors and server clusters. Executors are containers created in the target chain container loading module, used to execute data interaction verification tasks; the server cluster provides the necessary computing resources and hardware support for building the executors; and the database stores snapshots of the various blockchain states supported by this cross-link interface, used for executor construction and data storage after the executors complete their tasks. Based on this architecture, this module can mainly implement the following sub-functions:

[0076] Container scheduling and task distribution: The system takes the target blockchain as input and treats each data interaction order's verification task as an atomic task. Furthermore, for this system, the containers corresponding to different virtual machines are also executors completely isolated from the outside world. Task distribution involves assigning verification tasks to various executors. Once a verification task is matched with a container, the target container is scheduled and launched to execute subsequent operations.

[0077] Block parsing: Parses the block corresponding to the parameters to obtain the data interaction stored in the block, which facilitates the verification of the data interaction.

[0078] Data interaction execution and state update: The synchronized data interaction order containing contract bytecode is executed by the target chain virtual machine loaded into the container. Along with the data interaction execution, the global state ledger of the target chain will also be updated accordingly. After the cross-chain block synchronization verification is completed, the ledger of the target chain in the local database is updated for persistent storage.

[0079] The cross-chain synchronization verification module is used to: change the state of the blockchain ledger using a container that loads the virtual machine.

[0080] The cross-chain synchronous verification module specifically includes:

[0081] A message queue is used to input atomic tasks and distribute and schedule them; a container is used to execute synchronous data interaction orders containing contract bytecode through the target chain virtual machine loaded into the container, and update the global state ledger of the target chain; a database is used to persistently store and update the global state ledger of the target chain.

[0082] The steps of the cross-chain state synchronization verification module can be described in the following language:

[0083] Task Input: The system inputs the target chain block, treating each data interaction form's verification task as an atomic task. Therefore, this method places the received verification tasks into a message queue and uses cluster management software to schedule the tasks in the message queue.

[0084] Task distribution and scheduling: Scheduled tasks are distributed and assigned to corresponding executors, which are then launched by the cluster management software. After task distribution is complete, atomic tasks are distributed to various containers containing virtual machines in the server cluster, and the running images containing virtual machines are linked to the corresponding blockchain state snapshots.

[0085] Block parsing: Performs the same parsing operation as the target chain on the incoming target block, that is, parses the data interaction forms in the block and the contracts in the data interaction forms, so that the executor can complete the block parsing accordingly.

[0086] Contract execution: The parsed contract is passed into the container, and the virtual machine finally executes the smart contract to complete the verification of data interaction.

[0087] Target chain ledger status update: After verification, the blockchain ledger snapshot in the database has not yet been updated. Therefore, before the executor shuts down and the entire container is destroyed, the target chain snapshot in the local database needs to be updated. See the overall system process below. Figure 4 .

[0088] Compared with the prior art, the present invention has the following beneficial effects:

[0089] First, it fully synchronizes the target chain actions, resulting in low latency.

[0090] By using container images to mount data, the global state ledger of each blockchain full node is stored independently, thereby quickly establishing binary node files of different blockchains in each virtual machine container, fully synchronizing the actions of the target chain, and quickly verifying smart contracts in an independent blockchain virtual machine environment, achieving low-latency synchronization.

[0091] Secondly, its universal cross-chain architecture can be adapted to any blockchain, exhibiting high versatility and low coupling.

[0092] By utilizing the target chain container loading module, the corresponding data interaction single verification is divided into atomic tasks. Simultaneously, the cluster management system and container technology within the cross-chain synchronization verification module isolate the runtime environments of each blockchain virtual machine, thereby achieving high adaptability for calls to any blockchain. The use of container technology also reduces system coupling, facilitating the integration of more blockchains into the system.

[0093] Third, the verification of each blockchain can be scheduled, reducing resource overhead.

[0094] Leveraging the native compatibility of cluster management systems and container technology, a message queue model is adopted. When synchronizing multiple target chains, a high-concurrency message queue approach is used to verify blocks from multiple target chains simultaneously and update the corresponding chain states. By adjusting the internal scheduling algorithm, critical tasks can be executed in advance, ensuring overall system efficiency, improving system task processing efficiency, and reducing resource overhead.

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0096] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A general abstract interface for blockchains oriented towards multi-chain integration, characterized in that, include: The target chain container loading module is used for: After parsing the received multi-chain synchronization verification data packets, the virtual machine corresponding to each target chain and the container that loads the virtual machine are determined. The cross-chain synchronous verification module is used for: The state of the blockchain ledger is changed using a container that houses the virtual machine; The target chain container loading module includes: Blockchain ledger verification unit, used for: Determining whether the blockchain ledger block height is synchronized requires verifying the transaction area. When the blockchain ledger block is highly synchronized with the required verification transaction area, the virtual machine version verification unit is started. The virtual machine version verification unit is used for: Determine if the virtual machine version matches the virtual machine version of the current target chain; When the virtual machine version matches the virtual machine version of the current target chain, start the container creation unit; The container manufacturing unit is used for: Create a container and start the container; The container creation process involves: loading the prepared target chain virtual machine into the container, linking the state snapshot of the target chain stored in the multi-chain synchronization verification data packet, and opening a corresponding and unified data interface to facilitate subsequent connection to the multi-chain synchronization verification data packet ledger and inter-container communication. The startup container is used to synchronize the target chain ledger to the block height marked by the message and load data. The cross-chain synchronous verification module specifically includes: A message queue is used to input atomic tasks and to distribute and schedule said atomic tasks; Containers are used to execute synchronous transaction orders containing contract bytecode through the target chain virtual machine loaded into the container, updating the target chain's global state ledger; The database is used to persistently store and update the global state ledger of the target chain.

2. The general abstract interface for blockchain oriented towards multi-chain integration as described in claim 1, characterized in that, The blockchain ledger verification unit is also used for: When the blockchain ledger block height does not keep up with the required verification transaction area, update the blockchain ledger and start the virtual machine version verification unit.

3. The general abstract interface for blockchain oriented towards multi-chain integration as described in claim 1, characterized in that, The target chain container loading module further includes: Information verification unit, used for: Verify the target chain synchronization signature in the parsed multi-chain synchronization verification data packet; When the target chain's synchronous signature verification is successful, block height verification is initiated.

4. The general abstract interface for blockchain oriented towards multi-chain integration as described in claim 3, characterized in that, The information verification unit is further configured to: If the target chain fails to synchronize the signature verification, update the multi-chain synchronization verification data packet.

5. A general abstract interface for blockchain oriented towards multi-chain integration as described in claim 1, characterized in that, The cross-chain synchronous verification module also includes: Cluster management software is used to manage containers and server clusters; the server cluster provides the necessary computing resource hardware support for building containers.

6. The general abstract interface for blockchain oriented towards multi-chain integration as described in claim 5, characterized in that, Using the target chain block as input, the verification task of each transaction is treated as an atomic task; The task distribution involves assigning verification tasks to various containers. Once a verification task is matched with a target container, the target container is scheduled and started to perform a synchronous verification operation.

Images