Low-delay cross-chain interaction method and device based on asynchronous processing

Abstract

The invention provides a low-delay cross-chain interaction method and device based on asynchronous processing, and the method comprises the steps: a source chain generates a cross-chain message, screens the cross-chain message through an eICN node, and asynchronously transmits the cross-chain message to a target chain; the target link receives and stores the cross-chain message, and temporarily stores the cross-chain message as an unconfirmed state under the condition that the validity of the cross-chain message is not verified; after the source chain confirms a block corresponding to the cross-chain message, the eICN node sends verification data of the block to the destination chain; and the target chain performs validity verification on the cross-chain message in the unconfirmed state based on the verification data, and executes a corresponding cross-chain service logic or deletes an invalid cross-chain message according to a verification result. According to the method, the combination of a cross-chain interaction process and a block chain execution process is realized, and the cross-chain interaction time delay is reduced through asynchronous driving of message transmission and message confirmation.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a low-latency cross-chain interaction method and device based on asynchronous processing. Background Art

[0002] Cross-chain technology aims to achieve secure and coordinated updates of states within multiple blockchains, and it is necessary to ensure the validity, atomicity, and isolation of state updates. The state update of the source chain must not only be able to be transmitted to the destination chain, but the destination chain must also be able to verify that the state has been confirmed on the source chain, thereby providing a secure foundation for the destination chain to perform subsequent operations. On top of the security foundation provided by trusted verification, cross-chain technology also needs to ensure atomicity and isolation. Atomicity means that a cross-chain transaction may involve multiple sub-transactions on multiple blockchains, and these sub-transactions are either all executed successfully or all executed failed. Isolation means that multiple cross-chain transactions or cross-chain transactions and local chain transactions will not interfere with each other during concurrent execution due to reading and writing shared states, and the final execution result is the same as the result of executing these transactions one by one in a certain order (usually serialized order).

[0003] A cross-chain operation involves multiple sub-transactions on multiple blockchains. Each sub-transaction must go through a confirmation (finality) process, so a cross-chain operation may go through multiple confirmation processes, which ultimately leads to high cross-chain latency. The number of cross-chain interactive sub-transactions in different scenarios is also different. For example, for scenarios that require two sub-transactions, first execute the cross-chain application on the source chain and create a cross-chain message. After the cross-chain message is confirmed on the source chain, the destination chain executes the corresponding operation and confirms it; for scenarios that require three sub-transactions, the source chain creates a cross-chain message, the destination chain executes the cross-chain message, and the source chain performs the confirmation operation; for scenarios that require four sub-transactions, first the coordination chain creates a cross-chain transaction, and multiple participating chains execute prepare in parallel. The coordination chain collects the prepare results of each chain and decides on commit / rollback, and the participating chains execute commit / rollback. In practice, a cross-chain transaction contains more serial sub-transactions. In order to confirm the sub-transactions, multiple rounds of message broadcasting are required between the consensus nodes of the blockchain, which ultimately leads to high latency problems for cross-chain transactions, and the total latency of cross-chain transactions is proportional to the number of sub-transactions executed serially.

[0004] In order to reduce cross-chain latency and improve cross-chain performance, the current cross-chain latency optimization methods can be divided into the following categories:

[0005] ① Parallel submission strategy. The parallel submission strategy usually manages the atomicity of cross-chain transactions by introducing a coordinator (such as a dedicated chain, committee, or client), and uses the parallelization strategy of the two-phase commit protocol (2PC) to decompose complex transactions into multiple subtasks for synchronous execution. The coordinator is responsible for coordinating the submission or rollback of each chain to ensure the lightweight and efficient cross-chain operation. Some solutions optimize the process by building a transaction execution tree or a cross-chain transaction graph to reduce dependencies and improve throughput. Optimistic concurrency. Cross-chain transactions generally use 2PCL to ensure isolation between transactions, but it also leads to low concurrency of cross-chain transactions.

[0006] ② Optimistic concurrency strategy. Optimistic concurrency strategy usually adopts optimistic locking or non-blocking mechanism, allowing multiple cross-chain transactions to be executed simultaneously, and checking conflicts only at the final submission. By temporarily storing intermediate states (such as the "dirty state layer"), resources are locked to avoid blocking other transactions for a long time. If a conflict occurs, roll back, otherwise submit directly, thereby improving concurrency efficiency and solving the low concurrency problem caused by traditional 2PC isolation.

[0007] ③ Consensus optimization strategy. Consensus optimization strategies usually reduce latency by simplifying the consensus process or off-chain processing. For example: concentrating cross-chain transaction consensus on a few nodes, and other nodes only need reliable broadcasting; using the trusted execution environment (TEE) to process complex logic off-chain to reduce the number of on-chain consensus; pre-execute transaction messages or pipeline protocols (such as merging BFT consensus with 2PC steps) to shorten end-to-end processing time. The core is to improve overall performance by reducing consensus overhead or parallelizing steps.

[0008] However, the parallel submission and optimistic concurrency solutions take each single-chain sub-transaction as the minimum execution unit, and optimize the interaction mode based on the cross-chain business characteristics (whether the application logic can be executed in parallel, the conflict rate of application status read and write operations, etc.). Therefore, no matter how the optimization is performed, the latency of a single cross-chain transaction in these solutions is limited by the number of serial sub-transactions. In the cross-chain scenario, the consensus optimization-based solution requires a hard fork of the chain to support the upgrade of the underlying consensus mechanism, so it is highly invasive to the chain. In summary, the current solution does not meet the following goals: without invading the underlying mechanism of the blockchain, combine the execution process of the single-chain sub-transaction with the cross-chain interaction process, thereby reducing the cross-chain interaction latency and improving the cross-chain interaction performance. Summary of the invention

[0009] In view of the shortcomings of the prior art, the present invention proposes a low-latency cross-chain interaction method and device based on asynchronous processing. The method realizes the combination of the cross-chain interaction process and the blockchain execution process, and reduces the cross-chain interaction delay by asynchronously driving "message transmission" and "message confirmation".

[0010] In order to achieve the above objectives, the present invention provides a low-latency cross-chain interaction method based on asynchronous processing, including:

[0011] The source chain generates a cross-chain message, and filters the cross-chain message through the extended interoperability consensus node (eICN) and asynchronously transmits it to the destination chain;

[0012] The destination chain receives and stores the cross-chain message, and temporarily stores it in an unconfirmed state without verifying its validity;

[0013] When the source chain confirms the block corresponding to the cross-chain message, the eICN node sends the verification data of the block to the destination chain;

[0014] The destination chain verifies the validity of the unconfirmed cross-chain message based on the verification data, and executes corresponding cross-chain business logic or deletes invalid cross-chain messages according to the verification result.

[0015] In one embodiment of the present invention, the source chain generates a cross-chain message, and screens the cross-chain message through the eICN node and asynchronously transmits it to the destination chain, including:

[0016] The consensus node of the source chain executes the transaction to generate an initial cross-chain message, and temporarily stores the initial cross-chain message and the corresponding storage proof in the local state tree;

[0017] The eICN node screens valid blocks for the initial cross-chain message based on the consensus mechanism and performs aggregate signature to generate a cross-chain message including a chain identifier, a block header, a cross-chain message set, a storage certificate and a signature;

[0018] The filtered cross-chain message is asynchronously sent to the cross-chain contract of the destination chain.

[0019] In one embodiment of the present invention, the eICN node screens valid blocks for the initial cross-chain message based on a consensus mechanism, including:

[0020] Multiple eICN nodes elect a leader node based on a polling algorithm, and the leader node collects and verifies signatures of other nodes on candidate blocks;

[0021] If the number of signatures of the candidate block meets the preset threshold, the cross-chain message of the candidate block is aggregated and signed to generate the filtered cross-chain message.

[0022] In one embodiment of the present invention, the destination chain temporarily stores the cross-chain message in the following manner:

[0023] Create a queue based on the chain ID and block height to store multiple candidate block hashes of the same height;

[0024] Using the block hash as the key, the cross-chain message and the corresponding storage proof are stored in a dictionary structure for retrieval during validity verification.

[0025] In one embodiment of the present invention, the verification data includes header information of the block and a corresponding Merkle tree root;

[0026] The destination chain verifies the validity of the unconfirmed cross-chain message based on the verification data, and executes corresponding cross-chain business logic or deletes invalid cross-chain messages according to the verification result, including:

[0027] The destination chain verifies the validity of the block header based on a light client algorithm;

[0028] If the verification is successful, the Merkle tree root of the block header is compared with the storage proof corresponding to the unconfirmed message for consistency;

[0029] If they are consistent, the cross-chain message is submitted to the application contract to execute the cross-chain business logic; if they are inconsistent, the cross-chain message and its associated storage data are deleted.

[0030] In one embodiment of the present invention, the method further includes:

[0031] When the destination chain does not receive the verification data within a preset time, the cross-chain message in the unconfirmed state is automatically cleared.

[0032] In one embodiment of the present invention, the storage proof is generated by the following steps:

[0033] After the source chain executes the transaction, the cross-chain message is written into the local state tree as a state update;

[0034] Based on the current root node of the state tree, a storage proof of the cross-chain message is generated and associated with the corresponding block header.

[0035] In one embodiment of the present invention, in the polling algorithm, the leader node and the follower node asynchronously perform the following operations:

[0036] The follower node performs preliminary verification on the received block and sends the signed block header to the leader node;

[0037] The leader node redistributes the blocks that do not have sufficient signatures to the follower nodes for additional verification;

[0038] When the number of signatures of the candidate block meets the threshold, the transmission of the cross-chain message is triggered.

[0039] In one embodiment of the present invention, the execution of the cross-chain business logic includes:

[0040] The application contract of the destination chain performs asset transfer, status update or smart contract call operation according to the content of the cross-chain message.

[0041] In one embodiment of the present invention, the eICN node dynamically joins or exits the cross-chain network through a staking mechanism, and its identity information is recorded in the node management contracts of the source chain and the destination chain.

[0042] On the other hand, the present invention also provides a low-latency cross-chain interaction device based on asynchronous processing, comprising:

[0043] The cross-chain message transmission module is configured on the source chain and is used to filter the cross-chain messages generated by the source chain and asynchronously transmit them to the destination chain through the extended interoperability consensus node (eICN);

[0044] A message temporary storage module, configured on the destination chain, is used to receive and store the cross-chain message and mark it as unconfirmed when its validity is not verified;

[0045] A verification data sending module, configured in the eICN node of the source chain, is used to send the verification data of the block to the destination chain after the block corresponding to the cross-chain message is confirmed;

[0046] The validity verification and execution module is configured on the destination chain, and is used to verify the validity of the unconfirmed cross-chain message based on the verification data, and trigger the cross-chain business logic or delete the invalid cross-chain message according to the verification result.

[0047] It can be seen from the above scheme that the advantages of the present invention are:

[0048] The low-latency cross-chain interaction method based on asynchronous processing provided by the present invention, in the transmission stage, the source chain executes the cross-chain application contract, creates a cross-chain message, the cross-chain message is filtered and aggregated by the eICN node, and then forwarded to the smart contract of the destination chain, and the cross-chain message is stored in an unconfirmed state on the destination chain; then, in the confirmation stage, after the cross-chain message is confirmed on the source chain, the eICN node passes the trust root to the destination chain, and the destination chain performs a safe and reliable verification of the cross-chain message according to the trust root. If the verification passes, it means that the cross-chain message can be converted to a confirmed state, and then the cross-chain service contract delivers it to the corresponding cross-chain application contract to execute the business logic, otherwise, if the verification fails, the message is directly deleted. This method does not need to wait for the end of the "execution result confirmation stage" to pass the cross-chain message, but directly passes the message to the next-hop blockchain after the cross-chain message is generated at the end of the "transaction execution stage". This method realizes the combination of the cross-chain interaction process and the blockchain execution process without invading the underlying consensus and execution mechanism of the blockchain, and reduces the cross-chain interaction delay by asynchronously driving "message transmission" and "message confirmation". BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 The schematic diagram of the principle of the FF protocol of the prior art is shown;

[0050] Figure 2 A schematic diagram showing the principle of the PF protocol of the present invention is shown;

[0051] Figure 3 A schematic diagram of the overall process of a low-latency cross-chain interaction method based on asynchronous processing provided by an embodiment of the present invention;

[0052] Figure 4 A schematic diagram showing the principle of an eICN node of the present invention is shown;

[0053] Figure 5 A schematic diagram of the overall structure of a low-latency cross-chain interaction device based on asynchronous processing provided in one embodiment of the present invention.

[0054] Wherein, the accompanying drawings are marked as follows:

[0055] 400: Low-latency cross-chain interaction device based on asynchronous processing;

[0056] 410: cross-chain message transmission module;

[0057] 420: message temporary storage module;

[0058] 430: Verify data sending module;

[0059] 440: Validation and execution module. DETAILED DESCRIPTION

[0060] In order to make the above features and effects of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings.

[0061] It should be noted that, in this application, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0062] Without more constraints, an element defined by the phrase "comprising a..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0063] In the existing technology, the current mainstream cross-chain solution adopts the cross-chain protocol Forward-Finality (FF) which first confirms and then transmits across chains. Specifically, the current cross-chain transaction solution takes each single-chain sub-transaction as the minimum execution unit, and its minimum latency is limited by the number of serial sub-transactions in the entire cross-chain interaction process. In order to combine the execution process of single-chain sub-transactions with the cross-chain process, we analyzed the transaction processing process of the current mainstream blockchain and divided the execution process of single-chain sub-transactions into two stages:

[0064] Transaction execution phase: When a transaction is sent to the blockchain network, the transaction will first enter the transaction pool. When a new round of consensus begins, the miner node responsible for packaging the transaction selects the transaction from the transaction pool to build a block, and then broadcasts the block to the consensus nodes of the entire network for consensus. The node will then execute the transactions in the block and update the status and status tree in the local database. After all transactions in the block are executed, the cross-chain message will also be recorded locally in the form of an event (for external nodes to listen and obtain), or stored in the database in the form of a status. The order of consensus and execution is not fixed, such as execution first and then consensus, or consensus block first (determine the transaction order) and then execution. The transaction execution phase mentioned here has nothing to do with consensus. When the entire block is executed and a cross-chain message is generated, the "transaction execution phase" means that it has ended, followed by the "execution result confirmation phase";

[0065] Execution result confirmation phase: This phase refers to the process of reaching consensus on the new state and generating proof of validity. For probabilistic consensus such as Bitcoin or Ethereum 1.0, when enough blocks are added to a block, it is proved that the block has reached consensus in the whole network with a high enough probability; for Tendermint, although Tendermint is a deterministic consensus, since Tendermint adopts the strategy of consensus first and then execution, the "execution result confirmation phase" is when the consensus of the next block is completed; Ethereum 2.0 based on PoS is also a deterministic consensus, but it also needs to wait for 1 epoch to confirm that the block in the previous epoch has been confirmed.

[0066] From the above analysis of the cross-chain interaction scheme, we can see that the current cross-chain interaction schemes only transmit cross-chain messages to the destination chain after the execution result confirmation phase is completed. Figure 1 As shown in , this results in cross-chain messages going through a complete confirmation phase every time they pass through a blockchain.

[0067] In this regard, in order to break through the limitations of the FF protocol, the present invention proposes a Post-Finality (PF for short) protocol, which does not need to wait for the end of the "execution result confirmation phase" to pass the cross-chain message, but directly passes the message to the next-hop blockchain after the cross-chain message is generated at the end of the "transaction execution phase". The key to the PF protocol is that once the source chain generates a cross-chain message, the message does not need to wait for confirmation, and can be directly passed to the destination chain. When the cross-chain message is confirmed by the source chain, the destination chain will update the data, while the traditional FF protocol needs to wait for the cross-chain message to be confirmed by the source chain before it can be passed to the destination chain. The key to the PF protocol is that once the source chain generates a cross-chain message, the message does not need to wait for confirmation, and can be directly passed to the destination chain. When the cross-chain message is confirmed by the source chain, the destination chain verifies that the cross-chain message is valid and then executes the corresponding business logic. According to the core functions of the PF protocol, it is divided into two processes, refer to Figure 2 As shown in, the message transmission process and the message confirmation process are asynchronous, that is, the message transmission process can be executed without waiting for the message confirmation process to be completed. The message transmission process (simplified as PF-Transmit) mainly transmits the cross-chain message that has been generated but not yet confirmed to the destination chain. When the source chain executes the block and obtains the latest cross-chain message, the eICN node sends the cross-chain message to the destination chain. The destination chain stores the cross-chain message in units of block hashes and executes the cross-chain message after the cross-chain message is confirmed to be valid. The message confirmation process (simplified as PF-Finalize) and the message transmission process are asynchronous. The eICN node forwards the confirmed block header on the source chain to the destination chain. The destination chain verifies the validity of the cross-chain message based on the block header. If it is valid, the message is used as input to execute the business logic, otherwise the cross-chain message is deleted.

[0068] Based on the Post-Finality (PF) protocol, the present invention specifically proposes a low-latency cross-chain interaction method based on asynchronous processing, for specific reference Figure 3 As shown in Figure 3 The overall process diagram of the low-latency cross-chain interaction method based on asynchronous processing is shown.

[0069] Specifically, a low-latency cross-chain interaction method based on asynchronous processing includes the following steps:

[0070] Step S1: The source chain generates a cross-chain message, and screens the cross-chain message through the extended interoperability consensus node (eICN) and asynchronously transmits it to the destination chain.

[0071] Since the PF protocol needs to pass unconfirmed cross-chain messages to the destination chain, it faces two problems: (1) How to obtain unconfirmed messages in a timely manner without invading the underlying blockchain. Since the messages are unconfirmed, that is, they are not written into the node's database, it is impossible to use the traditional relayer to query a certain / group of nodes for messages; (2) How to reduce the number of invalid cross-chain messages received by the destination chain? Since the messages are unconfirmed, many invalid cross-chain messages will be generated on the destination chain (due to forks, network partitions, malicious forgeries, etc.), increasing the computational and storage overhead on the destination chain. Therefore, in one embodiment, an extended Interoperability Consensus Node (eICN for short) is introduced to the PF protocol, see Figure 4 As shown in , the eICN node extends the interoperability function based on the consensus node. It can use the characteristics of the consensus node to obtain the blocks in the consensus in time, and then execute the transactions in the block to obtain the cross-chain messages generated by the cross-chain contract, and construct the storage proof for the temporarily valid cross-chain messages. It is worth noting that the eICN node only needs to expand a small number of consensus nodes, and does not require blockchain forks to achieve system upgrades of all network nodes, thus achieving non-intrusiveness. At the same time, in order to reduce invalid cross-chain messages on the destination chain, we integrated the Filter Invalid Messages Algorithm (FIMA for short) algorithm in the eICN node. The algorithm first uses the block proposal verification algorithm (eICN is naturally introduced as a consensus node) to filter malicious messages, and then performs BLS aggregate signatures between multiple eICN nodes to avoid a single eICN node from doing evil, thereby reducing the number of malicious cross-chain messages received on the destination chain.

[0072] In one embodiment, reference Figure 4 As shown in , both the source chain and the destination chain are equipped with eICN nodes. Specifically, the consensus node becomes an eICN node by staking in the cross-chain contract. The eICN nodes of each chain form a structured network (each information is recorded in the cross-chain contract). Whenever a new node joins, all eICN nodes use a decentralized threshold key distribution protocol to update their own keys for aggregate signatures. Since different blockchains cannot communicate directly (receive or send messages from the outside world), the source chain and the destination chain actually communicate through the eICN nodes of their respective chains.

[0073] Therefore, based on this, in this embodiment, the source chain generates a cross-chain message, and screens the cross-chain message and asynchronously transmits it to the destination chain through the extended interoperability consensus node eICN.

[0074] Specifically, first, the consensus node of the source chain executes the transaction to generate the initial cross-chain message, and temporarily stores the initial cross-chain message and the corresponding storage proof in the local state tree. For example, in the transaction packaging process, when a user initiates a cross-chain transaction to the cross-chain contract of source chain A, the miner node of source chain A packages the transaction into block B. h1 In the process, different blockchains process block B h1 The method is different, but in the end, each consensus node of source chain A (including eICN nodes) will receive the block and execute it. During the block execution process, the consensus node of the source chain executes the transaction to call the cross-chain contract, and the cross-chain contract calls the application contract according to the transaction parameters. The cross-chain application contract determines the request information (that is, the contract, function and parameters on the specified destination chain) and returns it to the cross-chain contract. The cross-chain contract constructs it into the initial cross-chain message cm and stores it as a state on the chain. When the entire block is executed, the updated state (including the cross-chain message) will be added to the Merkle Tree as a new leaf node, and the Merkle root will be updated to root h1 , each state is related to the Merkle tree root h1 There will be a unique Merkle path (also called storage proof) between them, so that external entities can efficiently verify the correctness of the data through the storage proof. It is worth noting that the Merkle root root at this time h1 Not necessarily included in the block header at the current height.

[0075] Then, the eICN node of the source chain filters the valid blocks of the initial cross-chain message based on the consensus mechanism and executes the aggregate signature to obtain the filtered cross-chain message, which contains the chain identifier, block header, cross-chain message set, storage proof and signature, etc., and sends the filtered cross-chain message asynchronously to the cross-chain contract of the destination chain. Specifically, in the message filtering process, after the eICN node (which is also the consensus node) executes the block, it will jointly execute the leader selection algorithm Filter InvalidMessagesAlgorithm (FIMA for short) using the consensus mechanism with other eICN nodes. By verifying the block information and aggregate signature, the malicious forged cross-chain messages are filtered out from the initial cross-chain message, thereby reducing the high storage overhead caused by a large number of invalid cross-chain messages on the destination chain. Finally, the eICN node will send the filtered cross-chain message that has completed the aggregate signature through the interoperability interface.<chainId,header,CMs,MPs,blsAggrSig> A cross-chain contract sent to the destination chain in the form of a transaction, where chainId, header, CMs, MPs, and blsAggrSig represent the chain identifier, block header, cross-chain message set, storage proof, and signature, respectively.

[0076] Finally, the transaction will also go through the transaction packaging process on the destination chain. During the cross-chain message execution after the destination chain has filtered the message, the cross-chain contract will first verify the aggregate signature blsAggrSig, and then verify(cm i ,mp i ,header.root)Verify cm i Is it correct? After verification, the message is delivered to the ShadowStore() interface to store the cross-chain message.

[0077] In this embodiment, the eICN node, as a consensus node, can quickly obtain and effectively filter invalid blocks. At the same time, it can execute transactions in the block to obtain cross-chain messages generated by the cross-chain contract, and construct storage proof for temporarily valid cross-chain messages. Finally, the FIMA algorithm is used to aggregate the cross-chain messages and pass them to the destination chain.

[0078] In one embodiment, multiple eICN nodes elect a leader node based on a polling algorithm, and the leader node collects and verifies signatures of other nodes on candidate blocks; if the number of signatures of the candidate block meets a preset threshold, the cross-chain message of the candidate block is aggregated and signed to generate the filtered cross-chain message.

[0079] Specifically, for each block height of the source chain, the eICN node starts a new epoch, and each epoch is independent and does not affect each other. In each epoch, multiple eICN nodes filter and use BLS aggregate signatures to sign cross-chain messages through the FIMA algorithm. The FIMA algorithm contains two roles: the leader node and multiple follower nodes. The polling algorithm Round Robin is used between multiple eICN nodes to determine the Leader and Followers. The process of each epoch can be divided into the block verification phase, the collection phase, the supplementary verification phase, and the sending phase, specifically:

[0080] In the block verification phase, each Follower (eICN node is also a consensus node) collects the initial cross-chain message blocks from other consensus nodes, verifies whether the block proposal is valid (needs to be determined according to the leader election algorithm of the chain consensus mechanism), and if valid, sends the block header to the Leader of this round after BLS signature.

[0081] In the block collection phase, the Leader is responsible for collecting the block headers and signatures of all Followers, and verifying the validity and BLS signature of each block header in parallel. If after a period of time, a verified valid block header has collected a sufficient number of BLS signatures, it can be directly added to the set of block headers to be transmitted. Otherwise, a set of block headers to be signed is constructed and sent to other Followers that do not own the block (due to forks or network delays, some followers may not have the block header temporarily).

[0082] In the supplementary verification phase, the Follower receives the set of proxy-signed block headers sent by the Leader, verifies each block in the set in parallel, performs BLS signatures on valid blocks and returns them to the Leader; the Leader performs aggregate signatures on each block that has been verified to be valid and has collected a sufficient number of BLS signatures, and adds it to the set of block headers to be transmitted, thus realizing the final process of screening the initial cross-chain message.

[0083] In the message sending phase, for each block header to be transmitted, the Leader obtains the cross-chain message and its storage proof (the Merkle path pointing to the state root in the block header) from the Follower that has the complete block. Since the Follower has the complete block header, it can execute all transactions in the block and obtain the cross-chain message. At the same time, for the latest local Merkle tree, it obtains the storage proof of the cross-chain message. Finally, the Leader sends <chain identifier, block header, cross-chain message set, storage proof set, aggregate signature> to the eICN node of the destination chain.

[0084] The supplementary verification phase and the sending phase are asynchronous, that is, as long as a new block enters the set of block headers to be transmitted, the sending phase can be entered to send the block header to the destination chain.

[0085] In addition, it should be noted that before the final confirmation, multiple blocks may be generated at the same height. In this case, the eICN node can choose to The block header and its cross-chain message are transmitted to the destination chain. When , it means that none of them will be transmitted, and it is necessary to wait until the block is completely confirmed before transmitting (that is, for this block, it degenerates to the FF mechanism). It will only affect the computation and storage overhead on the destination chain, but will not affect the correctness of the results. It can be used as the basic parameter for cross-chain interaction and is set by the target chain’s cross-chain basic contract.

[0086] Step S2: The destination chain receives and stores the filtered cross-chain message, and temporarily stores it in an unconfirmed state without verifying its validity.

[0087] In one embodiment, the destination chain receives and stores cross-chain messages transmitted by the eICN node of the source chain. Due to network partitions, forks, and malicious forgery of messages by adversaries, the destination chain may simultaneously receive multiple blocks at the same height and cross-chain messages within the block. Since the destination chain cannot temporarily verify which cross-chain messages are valid, the destination chain needs to store these cross-chain messages in the cross-chain contract. In one embodiment, the destination chain temporarily stores the cross-chain messages in the following manner: a queue is created based on the chain identifier and block height, and multiple candidate block hashes of the same height are stored; using the block hash as the key, the cross-chain message and the corresponding storage proof are stored in a dictionary structure for retrieval during validity verification.

[0088] Specifically, in one embodiment, the cross-chain messages in different blocks at the same height are stored in the ShadowStore() interface, for each<chainId,height> Create a queue to store all block hashes at the same height, and store all cross-chain messages in the block in a dictionary with the block hash as the key, so as to facilitate finding valid cross-chain messages in the FinalizeStore() interface.

[0089] In the FinalizeStore() interface, the cross-chain message of the block is searched in the dictionary according to the hash header.hash of the verified valid block. These cross-chain messages will be identified as valid cross-chain messages and returned to the cross-chain contract.<chainId,header.height> Find the current height block hash queue. At this time, you can delete the block hash in the queue and all cross-chain messages mapped to the block hash in the dictionary.

[0090] Executing all cross-chain messages in a block at one time may easily exceed the transaction execution limit on the destination chain. Therefore, before sending the block header to the destination chain cross-chain contract, the eICN node can first query the number of cross-chain messages corresponding to the block. If the number is large, multiple transactions can be sent, and each transaction executes a small part of the cross-chain messages, thereby avoiding the problem of exceeding the execution limit when executing all cross-chain messages at one time.

[0091] Step S3: After the source chain confirms the block corresponding to the cross-chain message, the eICN node sends the verification data of the block to the destination chain, where the verification data includes the header information of the block and the corresponding Merkle tree root.

[0092] The above steps S1-S2 are the message transmission stage, and the message verification stage steps S3-S4 are executed next. In the message verification stage, first, when the source chain confirms the block corresponding to the cross-chain message, the eICN node sends the verification data of the block to the destination chain, and the verification data includes the header information of the block and the corresponding Merkle tree root.

[0093] Step S4: Then, the destination chain verifies the validity of the unconfirmed cross-chain message based on the verification data, and executes the corresponding cross-chain business logic or deletes the invalid cross-chain message according to the verification result.

[0094] In one embodiment, the destination chain verifies the validity of the block header based on a light client algorithm; if the verification passes, the Merkle tree root of the block header is compared for consistency with the storage proof corresponding to the unconfirmed message; if they are consistent, the cross-chain message is submitted to the application contract to execute the cross-chain business logic; if they are inconsistent, the cross-chain message and its associated storage data are deleted.

[0095] In one embodiment, the execution of the cross-chain business logic can be configured according to actual needs: the application contract of the destination chain executes asset transfer, status update or smart contract call operation according to the content of the cross-chain message.

[0096] For example, suppose block B h1 After the execution is completed, the Merkle tree root is included in block B h2 Medium (h 2 >=h 1 ), when B h2 After being confirmed on the source chain A, the eICN node will send the block header BH h2 Passed to the cross-chain contract of the destination chain.

[0097] The cross-chain contract of the destination chain will be verified in the following order: (1) Verify BH based on the block header chain through the Light Client algorithm h2 Is it valid? If not, discard it. Otherwise, store it at the end of the block header chain (2) Check B h2 .root vs root h1 Are they the same? If they are different, call the FinalizeStore() interface to remove the invalid cross-chain message. If they are the same, it means that the cross-chain message is valid, and the message will be delivered to the application contract for execution.

[0098] In addition, the PF protocol is compatible with the FF protocol. Although it is generally assumed that the message transmission process ends earlier than the message confirmation process, due to network reasons, the message transmission may be slower, causing the block header of the source chain to arrive earlier than the message, which degenerates into the processing method of the FF protocol. In order to deal with this method, the PF protocol only needs to check whether there is a corresponding block header when the cross-chain message is transmitted to the destination chain.

[0099] In addition, in one embodiment, when the destination chain does not receive the verification data within a preset time, the cross-chain message in the unconfirmed state is automatically cleared.

[0100] In summary, the low-latency cross-chain interaction method based on asynchronous processing disclosed by the present invention, the source chain executes the cross-chain application contract to create a cross-chain message, and sends it to the destination chain, and finally safely triggers the target cross-chain application contract and executes the corresponding business logic. First, in the transmission stage, the source chain executes the cross-chain application contract, creates a cross-chain message, and the cross-chain message is filtered and aggregated by the eICN node, and then forwarded to the smart contract of the destination chain. The cross-chain message is stored in the destination chain in an unconfirmed state; then, in the confirmation stage, after the cross-chain message is confirmed on the source chain, the eICN node passes the trust root to the destination chain, and the destination chain performs a safe and reliable verification of the cross-chain message based on the trust root. If the verification passes, it means that the cross-chain message can be converted to a confirmed state, and then the cross-chain service contract delivers it to the corresponding cross-chain application contract to execute the business logic, otherwise, if the verification fails, the message is directly deleted. This method does not need to wait for the end of the "execution result confirmation phase" of the prior art to pass the cross-chain message, but directly passes the message to the next-hop blockchain after the "transaction execution phase" ends and generates a cross-chain message. The key to this method is that once the source chain generates a cross-chain message, the message does not need to wait for confirmation and can be directly passed to the destination chain. When the cross-chain message is confirmed on the source chain, the destination chain updates the data. The traditional FF protocol needs to wait for the cross-chain message to be confirmed on the source chain before it can be passed to the destination chain. At the same time, in order to be able to promptly obtain the unconfirmed cross-chain messages generated after the end of the "transaction execution phase" and reduce the number of invalid cross-chain messages on the destination chain, the eICN node is introduced. The message broadcast attribute of the consensus node can be used to obtain unconfirmed cross-chain messages in a timely manner. At the same time, the FIMA algorithm is integrated, and the leader election algorithm based on the consensus mechanism filters malicious proposed blocks, thereby reducing the number of invalid cross-chain messages received by the destination chain. It is specifically reflected in the following aspects:

[0101] ① The present invention adopts the Post-Finality protocol. Without invading the underlying consensus and execution mechanism of the blockchain (no need to upgrade all network nodes through hard forks), the cross-chain interaction process is combined with the blockchain execution process, and the cross-chain interaction delay is reduced by asynchronously driving "message transmission" and "message confirmation".

[0102] ② The present invention introduces the eICN node. Different from the traditional relayer device that is only responsible for cross-chain message monitoring and forwarding, the eICN node realizes the cross-chain interoperability function based on the consensus node, which can not only meet the Post-Finality's demand for timely acquisition of unconfirmed messages, but also facilitate the use of the leader selection algorithm of the consensus mechanism to filter invalid cross-chain messages (introduced because the Post-Finality protocol transmits unconfirmed messages). More importantly, the introduction of the eICN node makes it unnecessary for Post-Finality to upgrade the underlying mechanism of the blockchain through a hard fork, but only needs to update the execution logic of the consensus node at the constant level.

[0103] ③The eICN node combines the FIMA algorithm to screen cross-chain messages. This algorithm aims to use the leader selection algorithm of the consensus mechanism to reduce the number of invalid cross-chain messages in Post-Finality, and use BLS aggregate signatures to improve the execution efficiency of the destination chain when verifying the validity of cross-chain messages, as well as reduce invalid messages on the destination chain.

[0104] ④ Use the ShadowStore method combined with the FinalizeStore method to store on the destination chain. In the confirmation phase, unconfirmed cross-chain messages will be submitted to the destination chain. The ShadowStore method explains how to store these unconfirmed cross-chain messages, so that all relevant cross-chain messages can be found quickly and accurately in the PF-Finalize phase. At the same time, unconfirmed cross-chain messages cannot affect other states on the destination chain. Unconfirmed cross-chain messages on the destination chain will be confirmed. FinalizeStore explains how to handle invalid cross-chain messages and how to handle valid cross-chain messages.

[0105] ⑤ Communication method between source chain eICN nodes and destination chain eICN nodes. The special functions of eICN nodes (including the transmission of unconfirmed cross-chain messages and aggregated signatures, the transmission of confirmed block headers, etc.) put forward new requirements for the communication protocol between the source chain and the destination chain eICN nodes. It is necessary to be able to transmit unconfirmed cross-chain messages and their aggregated signatures, transmit confirmed block header information, and also be able to synchronize the identity information of the source chain eICN node, so that the destination chain contract can verify the aggregated signature from the source chain eICN node.

[0106] ⑥ eICN node message validity proof construction method. Unlike the traditional off-chain relayer, which can directly query the validity proof of the confirmed state on the chain through the RPC interface, the eICN node needs to construct the validity proof before the state is confirmed. This requires the eICN node to temporarily update the local world state after executing the block, so as to obtain the temporary validity proof of the state, and requires that the state updates of multiple blocks at the same height (forks result in multiple blocks at the same height) do not affect each other.

[0107] The following takes a cross-chain asset transfer as an example, which includes two parallel chains, the source chain Paral-src and the destination chain Paral-dst. It is assumed that each parallel chain adopts the processing strategy of execution first and then consensus. Based on this, the specific implementation process of the low-latency cross-chain interaction method based on asynchronous processing of the present invention is explained in detail.

[0108] First, the specific scenario and the deployment of the source chain Paral-src and the destination chain Paral-dst are explained:

[0109] (1) Scenario explanation:

[0110] 1) The user has a wallet wallet-src in Paral-src, which contains m number of C-src coins.

[0111] 2) The user has a wallet-dst in Paral-dst, which contains n number of C-dst coins.

[0112] 3) Now the user wants to initiate a cross-chain asset transfer transaction to transfer k Paral-src assets to Paral-dst. Assuming the exchange rate between C-src and C-dst is 1:1, this means that k C-src coins are reduced in the wallet-src wallet, leaving mk C-src coins, and k C-dst coins are added to the wallet-dst wallet, leaving n+k C-dst coins.

[0113] 4) If you want to transfer assets across chains, you need to unlock the tokens on Paral-dst. Then, Paral-dst needs to get a confirmed cross-chain message from Paral-src, that is, Paral-src has completed the corresponding number of asset locks, and Paral-dst can release the tokens, otherwise Paral-dst refuses to lock the assets.

[0114] (2) Prerequisites:

[0115] 1) The source chain Paral-src and the destination chain Paral-dst deploy cross-chain contracts as follows:

[0116] A. Cross-chain application contract. Parachains must first deploy cross-chain application contracts for minting and destroying tokens, that is, the contract requires a token pool. When a user needs to transfer assets out, the user's assets on this chain should be pledged in the token pool. Similarly, when a user needs to transfer assets in, the token pool should be able to release the corresponding number of tokens and transfer them to the user's wallet on this chain.

[0117] B. Cross-chain basic contract

[0118] Paral-src side application will complete a series of verification and transmission support contracts after the asset is pledged. Paral-dst side application will complete a series of verification and transmission support contracts after the asset is released. The following functions need to be implemented: cross-chain message construction and storage functions; ShadowStore interface; FinalizeStore interface; support for mutual calls between cross-chain application contracts; Implemented the light client algorithm of the source chain.

[0119] C.eICN node management contract is as follows:

[0120] Both Paral-src and Paral-dst need to deploy the eICN node management contract to register valid eICN nodes on the chain and provide an interface for the access of eICN nodes. The following functions need to be included: Registration / staking function: support new consensus nodes to become eICN nodes by staking assets; query function: the outside world can query active eICN nodes on the chain; exit function: eICN nodes can apply to ensure safe exit.

[0121] 2) eICN node deployment is as follows:

[0122] Blockchains cannot directly send or receive messages to or from the outside world. The eICN node actually performs the sending / receiving operation.

[0123] A.eICN-src: The eICN node of Paral-src is responsible for delivering the cross-chain message of Paral-src to the destination chain, specifically: receiving new blocks from miner nodes; verifying whether the block proposal is legal; executing blocks and obtaining cross-chain messages in blocks; performing aggregate signatures on cross-chain messages; constructing temporary validity proofs of cross-chain messages; and sending cross-chain messages to the eICN node of the destination chain.

[0124] B.eICN-dst: Paral-dst’s eICN node is responsible for receiving cross-chain messages from eICN-src and submitting them to the Paral-dst chain. Specifically, it receives cross-chain messages from eICN-src; constructs cross-chain messages into destination chain transactions; and sends transactions to the destination chain’s cross-chain basic contract.

[0125] C. The eICN-src node has the communication information of the eICN-dst node (such as the rpc address), and the eICN-dst node has the identity information of the eICN-src node (such as the public key).

[0126] Then, the low-latency cross-chain interaction method based on asynchronous processing of the present invention is applied to the above-mentioned specific scenarios and the source chain Paral-src and the destination chain Paral-dst, which includes two processes: message transmission and message confirmation.

[0127] (I) In the message transmission stage, the specific process includes the following:

[0128] (1) The user initiates a cross-chain asset transfer transaction ctx in Paral-src.

[0129] (2) ctx is broadcasted across the entire network and enters the consensus node transaction pool.

[0130] (3) When the system starts a new round of consensus, the miner node selects the ctx building block from the transaction pool. i .

[0131] (4) The miner node executes the block (assuming the chain adopts the strategy of execution first and then consensus), filling the block i Status root and other information.

[0132] (5) Miner node broadcasts block i .

[0133] (6) When the eICN-src node receives the block from the miner node i hour:

[0134] a) Verify block i Whether the format is correct, the hash value is correct, and the forward block hash value is correct.

[0135] b) Verify the block i Whether the creator of complies with the leader election strategy of the consensus mechanism.

[0136] c) If the above conditions are not met, the block is discarded i , otherwise, continue execution.

[0137] d) Call the eICN node management contract and set the block height to block. i .height selects the eICN.leader of this round of eICN nodes and sets block i Sent to eICN.leader, and other nodes act as followers.

[0138] e) eICN.leader verifies the block format and the legitimacy of the creator, and builds the block set BSet.

[0139] f) eICN.leader sends block blocki to eICN.followers that have not signed yet.

[0140] g) eICN.followers verify the block format, creator legitimacy, etc. If correct, the block status root block i .root executes the BLS signature and returns it to eICN.leader.

[0141] h) If eICN.leader does not collect enough signatures within the specified time, it will terminate. Otherwise, the block i All BLS signatures of .root are aggregated.

[0142] i) eICN.leader queries eICN.followers for blocks i Cross-chain messaging and temporary validity proofs in .

[0143] j) After eICN.followers receives the query request, it executes the block i , for cross-chain transaction ctx execution:

[0144] i. The cross-chain application contract completes the staking operation of k C-src assets to the token pool, that is, k C-src are transferred out of the wallet-src wallet, and k C-src are transferred into the token pool contract.

[0145] ii. After the cross-chain application contract executes the business logic, it calls the cross-chain basic contract And pass necessary parameters, such as the destination chain ID, the destination chain cross-chain application contract, the destination chain asset transfer quantity, etc.

[0146] iii. Cross-chain basic contract Create a cross-chain message cm. Since the asset transfer transaction involves Paral-dst operations, after the cross-chain application contract of Paral-src completes the corresponding operation, it is necessary to create a cross-chain message to inform the token pool on Paral-dst to release k C-dst to Wallet-dst.

[0147] iv. Cross-chain basic contract Store the cross-chain message cm as a persistent state in the contract.

[0148] v.Cross-chain basic contract Throw the cross-chain message cm as an event.

[0149] vi. After the entire block is executed, obtain all cross-chain messages and their temporary validity proof cms = { <cm k ,π k >|k∈[0,C)}, where C is the block i The number of cross-chain messages in. Return cms to eICN.leader.

[0150] k)eICN.leader will im= <chainId,block i .header,cms,Sig aggr >eICN-dst sent to the destination chain.

[0151] 7) When the eICN-dst node of the destination chain receives the message im from the eICN-src node of the source chain:

[0152] a) Check whether im has been processed. If it has been processed, ignore the message; otherwise, continue execution.

[0153] b) Verify Sig aggr Is it correct.

[0154] c) According to block i .header.root, verifies whether the Merkle path of cms is correct. If not, refuse to continue execution. Otherwise, continue execution.

[0155] d) Check the block i .header has been confirmed, if it has been confirmed, then:

[0156] i. Pass the cross-chain message to the specified destination cross-chain application contract.

[0157] ii. The cross-chain application contract transfers k C-dst coins from the token pool and transfers them to wallet-dst. After this operation, wallet-dst should contain n+k C-dst.

[0158] iii. Mark the cross-chain message as “confirmed”.

[0159] iv. At this point, it indicates that the transaction has been processed.

[0160] e) If block i .header has not been confirmed, then:

[0161] i. Execute shadowStore(chainId, header, cms) to store cross-chain messages on the chain.

[0162] ii. Mark the cross-chain message as “unconfirmed”.

[0163] (II) In the message confirmation stage, the specific process includes the following:

[0164] (1) When the block i After the source chain is confirmed:

[0165] a) The eICN-src node of the source chain constructs the trust root data according to the parameter requirements of the light client of this chain, which generally includes trustRoot i = <block i .header>.

[0166] b) eICN-src node does not need to use FIMA algorithm at this time, and directly sets trustRoot i Just send it to the eICN-dst node of the destination chain.

[0167] (2) When the eICN-dst node receives the trustRoot from the eICN-src node i ,implement:

[0168] c) eICN-dst node will trustRoot i Constructed as a transaction on the destination chain and sent to the cross-chain basic contract of the destination chain

[0169] d) Cross-chain basic contracts Verify trustRoot using the light client algorithm of the source chain i Is it valid? If not, reject it; otherwise, continue to execute.

[0170] e) Check if there is a height equal to trustRoot i If the cross-chain message of .header.height is in an unconfirmed state, it ends if it does not exist, otherwise, it continues to execute.

[0171] f) Verify trustRoot i .header.root is equal to the header.root of the cross-chain message (in an unconfirmed state), execute FinalizeStore(chainId, trustRoot i .header), specifically:

[0172] i. For cross-chain messages that do not meet the conditions, just delete them directly.

[0173] ii. For cross-chain messages that meet the conditions, they are delivered to the specified cross-chain application contract:

[0174] ① The cross-chain application contract transfers k C-dst coins from the token pool and transfers them to wallet-dst. After this operation, wallet-dst should contain n+k C-dst;

[0175] ②Mark the cross-chain message as "confirmed", which means that the cross-chain message has been processed.

[0176] In addition, the present invention also provides a low-latency cross-chain interaction device based on asynchronous processing, which can implement each process implemented by the low-latency cross-chain interaction method based on asynchronous processing. Figure 5 As shown, Figure 5 The overall structural diagram of a low-latency cross-chain interaction device based on asynchronous processing is shown.

[0177] A low-latency cross-chain interaction device 400 based on asynchronous processing, comprising at least:

[0178] The cross-chain message transmission module 410 is configured on the source chain and is used to filter the cross-chain messages generated by the source chain and asynchronously transmit them to the destination chain through the extended interoperability consensus node (eICN).

[0179] The message temporary storage module 420 is configured on the destination chain, and is used to receive and store the cross-chain message, and mark it as unconfirmed when its validity is not verified.

[0180] The verification data sending module 430 is configured in the eICN node of the source chain, and is used to send the verification data of the block to the destination chain after the block corresponding to the cross-chain message is confirmed.

[0181] The validity verification and execution module 440 is configured on the destination chain, and is used to verify the validity of the unconfirmed cross-chain message based on the verification data, and trigger the cross-chain business logic or delete the invalid cross-chain message according to the verification result.

[0182] It should be understood that the descriptions of the low-latency cross-chain interaction method based on asynchronous processing are also applicable to the low-latency cross-chain interaction device 400 based on asynchronous processing according to the embodiment of the present application. To avoid repetition, it will not be described in detail.

[0183] In addition, it should be understood that in the low-latency cross-chain interaction device 400 based on asynchronous processing according to the embodiment of the present application, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the low-latency cross-chain interaction device based on asynchronous processing can be divided into functional modules different from the modules illustrated above to complete all or part of the functions described above.

[0184] In addition, the embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A low-latency cross-chain interaction method based on asynchronous processing, characterized in that: include: The source chain generates a cross-chain message, and filters the cross-chain message through the extended interoperability consensus node (eICN) and asynchronously transmits it to the destination chain; The destination chain receives and stores the cross-chain message, and temporarily stores it in an unconfirmed state without verifying its validity; When the source chain confirms the block corresponding to the cross-chain message, the eICN node sends the verification data of the block to the destination chain; The destination chain verifies the validity of the unconfirmed cross-chain message based on the verification data, and executes corresponding cross-chain business logic or deletes invalid cross-chain messages according to the verification result.

2. The method according to claim 1, characterized in that: The source chain generates a cross-chain message, and filters the cross-chain message through the eICN node and asynchronously transmits it to the destination chain, including: The consensus node of the source chain executes the transaction to generate an initial cross-chain message, and temporarily stores the initial cross-chain message and the corresponding storage proof in the local state tree; The eICN node screens valid blocks for the initial cross-chain message based on the consensus mechanism and performs aggregate signature to generate a screened cross-chain message including a chain identifier, a block header, a cross-chain message set, a storage proof and a signature; The filtered cross-chain message is asynchronously sent to the cross-chain contract of the destination chain.

3. The method according to claim 2, characterized in that The eICN node screens valid blocks for the initial cross-chain message based on the consensus mechanism, including: Multiple eICN nodes elect a leader node based on a polling algorithm, and the leader node collects and verifies signatures of other nodes on candidate blocks; If the number of signatures of the candidate block meets the preset threshold, the cross-chain message of the candidate block is aggregated and signed to generate the filtered cross-chain message.

4. The method according to claim 1, characterized in that: The destination chain temporarily stores the cross-chain message in the following manner: Create a queue based on the chain ID and block height to store multiple candidate block hashes of the same height; Using the block hash as the key, the cross-chain message and the corresponding storage proof are stored in a dictionary structure for retrieval during validity verification.

5. The method according to claim 1, characterized in that: The verification data includes the header information of the block and the corresponding Merkle tree root; The destination chain verifies the validity of the unconfirmed cross-chain message based on the verification data, and executes corresponding cross-chain business logic or deletes invalid cross-chain messages according to the verification result, including: The destination chain verifies the validity of the block header based on a light client algorithm; If the verification is successful, the Merkle tree root of the block header is compared with the storage proof corresponding to the unconfirmed message for consistency; If they are consistent, the cross-chain message is submitted to the application contract to execute the cross-chain business logic; If they are inconsistent, the cross-chain message and its associated stored data are deleted.

6. The method according to claim 1, characterized in that The method further comprises: When the destination chain does not receive the verification data within a preset time, the cross-chain message in the unconfirmed state is automatically cleared.

7. The method according to claim 2, characterized in that The storage proof is generated by the following steps: After the source chain executes the transaction, the cross-chain message is written into the local state tree as a state update; Based on the current root node of the state tree, a storage proof of the cross-chain message is generated and associated with the corresponding block header.

8. The method according to claim 3, characterized in that In the polling algorithm, the leader node and the follower node asynchronously perform the following operations: The follower node performs preliminary verification on the received block and sends the signed block header to the leader node; The leader node redistributes the blocks that do not have sufficient signatures to the follower nodes for additional verification; When the number of signatures of the candidate block meets the threshold, the transmission of the cross-chain message is triggered.

9. The method according to claim 5, characterized in that The execution of the cross-chain business logic includes: The application contract of the destination chain performs asset transfer, status update or smart contract call operation according to the content of the cross-chain message.

10. The method according to claim 1, characterized in that The eICN node dynamically joins or exits the cross-chain network through a staking mechanism, and its identity information is recorded in the node management contracts of the source chain and the destination chain.

11. A low-latency cross-chain interaction device based on asynchronous processing, characterized in that: include: The cross-chain message transmission module is configured on the source chain and is used to filter the cross-chain messages generated by the source chain and asynchronously transmit them to the destination chain through the extended interoperability consensus node (eICN); A message temporary storage module, configured on the destination chain, is used to receive and store the cross-chain message and mark it as unconfirmed when its validity is not verified; A verification data sending module, configured in the eICN node of the source chain, is used to send the verification data of the block to the destination chain after the block corresponding to the cross-chain message is confirmed; The validity verification and execution module is configured on the destination chain, and is used to verify the validity of the unconfirmed cross-chain message based on the verification data, and trigger the cross-chain business logic or delete the invalid cross-chain message according to the verification result.

Images