A cross-chain communication method based on the Dfinity blockchain

Abstract

The present invention discloses a cross-chain communication method based on the Dfinity blockchain. The gateway contract is responsible for sending and receiving cross-chain message requests on the access chain and organizing cross-chain messages into a Merkle tree format. The verifier contract on the Dfinity chain is responsible for regularly obtaining the Merkle tree root of the cross-chain message from the access chain for verifying the cross-chain message. The proxy contract on the Dfinity chain is responsible for receiving cross-chain messages from the off-chain relay and forwarding the verified cross-chain messages to the designated access chain. The off-chain relay is responsible for obtaining the latest cross-chain messages from all access chains, generating a Merkle proof for each cross-chain message, and submitting it to the proxy contract on the Dfinity chain for processing. The cross-chain communication method of the present invention can ensure security, has high scalability, supports heterogeneous inter-chain communication, and can support customized cross-chain message processing logic, which makes up for the shortcomings of existing cross-chain communication methods.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and specifically relates to a cross-chain communication method based on the Dfinity blockchain. Background Art

[0002] With the rapid development of blockchain technology and its related applications, various independent blockchains have emerged. Intercommunication between blockchains has become an urgent need. The main goal of cross-chain technology is to realize the value flow and information exchange between different chains.

[0003] To address the need for cross-chain communication, industry and academia have proposed several preliminary solutions. Currently, three major cross-chain technologies, depending on the verification mechanism, exist: light client verification, off-chain third-party verification, and fraud proofs (see [Zamyatin A, Al-Bassam M, Zindros D, et al. SoK: Communication Across Distributed Ledgers. 2019]). Light client verification requires both communicating chains to allow light clients from the other chain to verify the authenticity of messages from the other chain using the Merkle tree root in the block header. While light client solutions offer high security, they also have high implementation and operational overhead and poor scalability. There are many variations of off-chain third-party verification solutions. To address the single point of failure of private keys, multi-signature and threshold signature solutions have evolved. Multi-signature solutions are relatively simple to implement and highly scalable, but they are less secure than threshold signature solutions. Threshold signature solutions, however, introduce more complex cryptographic procedures and are more difficult to implement. Fraud proof schemes employ economic incentives to encourage supervisors to report malicious activity, thereby ensuring the honest performance of cross-chain message delivery. Once malicious activity is reported, it is penalized. Current schemes still require further improvement in security and scalability, and none support custom cross-chain message processing logic, resulting in limited flexibility.

[0004] In April 2022, the DFINITY Foundation released a new white paper titled "The Internet Computer for Geeks," which introduced Dfinity. Dfinity is a public blockchain supporting smart contracts. Smart contracts on Dfinity are called Canisters. Canisters can perform ECDSA signature operations using threshold signatures by calling system interfaces. Furthermore, unlike traditional smart contract sandboxes, Canisters on Dfinity can initiate HTTP requests to the outside world through system interfaces. When a contract initiates an HTTP request, each node in the subnet independently executes the request and obtains the response. The final result is returned to the contract after consensus. Summary of the Invention

[0005] In view of the above, the present invention provides a cross-chain communication method based on the Dfinity blockchain, which can effectively achieve interconnection between different blockchains and support developers to customize cross-chain message processing logic, greatly improving the flexibility of application developers in developing multi-chain applications.

[0006] A cross-chain communication method based on the Dfinity blockchain. Specifically: for any access chain, the gateway smart contract on the access chain is responsible for receiving cross-chain message requests from application smart contracts (App Contracts) on other chains. All cross-chain message requests are organized into a Merkle tree. When a new cross-chain message enters, its hash value will be inserted into the Merkle tree as a leaf node, and the Merkle tree root hash value will be updated accordingly; at the same time, the gateway smart contract receives and processes cross-chain messages from other chains, parses the receiving contract address of the cross-chain message, and calls the recipient's cross-chain message processing method to remind the recipient of the latest cross-chain message.

[0007] Furthermore, the steps of the cross-chain message processing method are as follows:

[0008] Step A. Monitor all access chains through off-chain relays to obtain the latest cross-chain message requests;

[0009] Step B. Upon receiving a cross-chain message request, the validator contract on the Dfinity chain is used to periodically query the Merkle root hash value of the latest cross-chain message from the access chain.

[0010] Step C. The off-chain relay generates a corresponding Merkle proof for each cross-chain message received, and submits the cross-chain message and Merkle proof to the proxy contract on the Dfinity chain;

[0011] Step D. After receiving the cross-chain message and Merkle proof, the proxy contract calls the verifier contract of the corresponding access chain to verify the authenticity of the cross-chain message;

[0012] Step E. The proxy contract forwards the verified cross-chain message to the receiving contract on the target chain;

[0013] Step F. If the target chain of the cross-chain message is the Dfinity chain, the proxy contract directly calls the application smart contract on the Dfinity chain and sends the cross-chain message to the application smart contract;

[0014] Step G. If the target chain of the cross-chain message is another access chain, the proxy contract constructs a target chain transaction, signs the transaction using the threshold ECDSA signature method provided by the Dfinity chain, and then sends the transaction to the target chain.

[0015] Furthermore, each access chain will correspond to a validator contract (ValidatorCanister) on the Dfinity chain. The validator contract is dynamically created and controlled by the proxy contract. The validator contract is responsible for regularly querying the Merkle tree root hash value of the latest cross-chain message from the corresponding access chain for subsequent verification of the authenticity of the cross-chain message.

[0016] Furthermore, the proxy contract (Proxy Canister) is located on the Dfinity chain, which is used to create and control all validator contracts. When a new chain needs to be accessed, the proxy contract will create a corresponding validator contract for the new access chain; the proxy contract is also used to receive and verify cross-chain messages from off-chain relays, and forward verified cross-chain messages.

[0017] Furthermore, the off-chain relay (Relayer) is responsible for collecting cross-chain message requests from all access chains, then generating a corresponding Merkle proof for each cross-chain message, and finally submitting the cross-chain message and Merkle proof data to the proxy contract on the Dfinity chain. The proxy contract will verify and process these cross-chain messages.

[0018] Furthermore, in step B, the verifier contract uses the Dfinity chain's heartbeat method to periodically query the Merkle tree root hash value of the latest cross-chain message from the access chain.

[0019] Furthermore, in step B, the verifier contract queries the Merkle tree root hash value of the cross-chain message from the access chain using the native HTTP method of the Dfinity chain, and queries the tree nodes from multiple access chains each time, eliminating the single point of failure problem.

[0020] Furthermore, in step D, the proxy contract uses the Merkle proof method to verify the authenticity of the received cross-chain message.

[0021] Furthermore, in step G, the proxy contract sends the transaction using the Http calling method provided by the Dfinity chain to the proxy contract.

[0022] The cross-chain communication method of this invention achieves programmability in cross-chain message transmission, namely, supporting customized cross-chain message processing logic. Developers can set the cross-chain message recipient to a designated application contract on the Dfinity chain. The application contract defines the cross-chain message processing logic. The proxy contract on the Dfinity chain will send the cross-chain message to the application contract, which can execute the customized cross-chain message processing logic and send the processed message back to the proxy contract, which forwards it to the target chain. This method of the invention can ensure security, has high scalability, supports heterogeneous inter-chain communication, and can support customized cross-chain message processing logic, thus addressing the shortcomings of existing cross-chain communication methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 Schematic diagram of the overall design architecture of the cross-chain communication technology solution of the present invention.

[0024] Figure 2 Flowchart of sending and processing messages to the gateway smart contract. DETAILED DESCRIPTION

[0025] In order to describe the present invention more specifically, the technical solution of the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] For any access chain, the cross-chain communication method of the present invention is based on the gateway smart contract on the access chain being responsible for receiving cross-chain message requests from the application smart contracts (App Contracts) on the chain. All cross-chain message requests are organized into a Merkle tree. When a new cross-chain message enters, its hash value is inserted into the Merkle tree as a leaf node, and the Merkle tree root hash value is updated accordingly. At the same time, the gateway smart contract receives and processes cross-chain messages from other chains, parses the receiving contract address of the cross-chain message, and calls the recipient's cross-chain message processing method to notify the recipient of the latest cross-chain message. It should be noted that this gateway contract has permission control, and only the proxy contract (ProxyCanister) on the Dfinity chain has permission to write cross-chain messages from other chains to the gateway.

[0027] The steps of cross-chain message processing are as follows:

[0028] Step A. The off-chain relay service monitors all access chains and obtains the latest cross-chain message requests;

[0029] Step B. The validator contract on the Dfinity chain periodically queries the latest cross-chain message Merkle tree root from the access chain;

[0030] Step C. The off-chain relay service generates a corresponding Merkle proof for each cross-chain message received, and submits the cross-chain message and Merkle proof to the proxy contract on the Dfinity chain;

[0031] Step D. After receiving the cross-chain message and Merkle proof, the proxy contract calls the verifier contract of the corresponding access chain to verify the authenticity of the cross-chain message;

[0032] Step E. The proxy contract forwards the verified message to the target contract on the target chain;

[0033] Step F. If the target chain of the cross-chain message is Dfinity, the proxy contract directly calls the application contract method on the Dfinity chain to send the cross-chain message to the application contract;

[0034] Step G. If the target chain of the cross-chain message is another access chain, the proxy contract constructs a target chain transaction, signs the transaction using the threshold ECDSA signature method provided by Dfinity, and then sends the transaction to the target chain.

[0035] like Figure 1 As shown on the right, the application smart contract is a smart contract that uses this cross-chain communication system for multi-chain communication and interaction. It is the originator and final recipient of all cross-chain messages. It is also a smart contract directly facing users and is developed by multi-chain application developers. There is no limit to the number of application contracts on the same chain. The application contract needs to send and receive cross-chain messages through the gateway smart contract on the corresponding chain.

[0036] Before an external chain can access this cross-chain communication system, it must first deploy a corresponding gateway smart contract on its chain. As the name suggests, all cross-chain message requests entering and leaving this access chain must pass through the gateway smart contract. The gateway smart contract is responsible for two aspects:

[0037] 1. Receive cross-chain message requests from the application smart contracts (App Contracts) on the chain. All cross-chain message requests are organized into a Merkle tree. When a new cross-chain message enters, its hash value will be inserted into the Merkle tree as a leaf node, and the Merkle tree root hash value will be updated accordingly. Figure 2 This shows the process of sending messages by the gateway smart contract.

[0038] 2. Receive and process cross-chain messages from other chains, parse the receiving contract address of the cross-chain message, and call the recipient's cross-chain message processing method to notify the recipient of the latest cross-chain message. It should be noted that this gateway contract has permission control, and only the proxy contract (Proxy Canister) on the Dfinity chain has permission to write cross-chain messages from other chains to the gateway.

[0039] like Figure 1 As shown on the right side of the Dfinity chain section, each access chain has a corresponding validator contract (Validator Canister) on Dfinity. This validator contract is dynamically created and controlled by a proxy contract (Proxy Canister). The validator contract is responsible for periodically querying the Merkle root hash of cross-chain messages from the corresponding access chain for subsequent verification of cross-chain message authenticity. This Merkle root query utilizes Dfinity's HTTP call feature, allowing the validator contract to directly query the gateway contract's Merkle root state data from the corresponding access chain's node via HTTP. To prevent single points of failure and ensure the authenticity of the retrieved Merkle root, the validator contract is pre-configured with node information from multiple access chains to form a node pool. During each Merkle root query, the validator contract randomly selects multiple nodes from the access chain node pool, queries data from each selected node, and compares the results returned by all nodes. If a result exceeds half of the total number of nodes, it is considered authentic; otherwise, the query result for that round is discarded. The validator contract also provides a message verification interface so that the proxy contract can verify the authenticity of a cross-chain message through Merkle proof.

[0040] The Proxy Canister on the Dfinity chain is the backbone of the entire cross-chain communication system, primarily completing the following tasks:

[0041] 1. Create and control all validator contracts. When a new chain needs to be connected, the proxy contract will create a corresponding validator contract for the new access chain.

[0042] 2. Receive and verify cross-chain messages from off-chain relays. When the proxy contract receives a cross-chain message from an off-chain relay, it first parses the origin chain of the message and calls the corresponding verifier contract to verify the authenticity of the message through the Merkle proof mechanism. If the verification passes, it proceeds to the next step, otherwise the cross-chain message is discarded.

[0043] 3. Forward verified cross-chain messages. If a cross-chain message passes Merkle verification, the proxy contract will parse the target chain and receiving contract address of the message. If the target chain is the Dfinity chain itself, the proxy contract will directly send the message to the application contract (App Canisters) on the Dfinity chain. If the target chain is an external access chain, the proxy contract will construct a transaction to call the gateway smart contract on the target chain, use Dfinity's threshold signature mechanism to sign the transaction, and send the transaction to the end chain via HTTP. The gateway smart contract on the target chain will remind the receiving contract of the latest cross-chain message.

[0044] 4. Forward messages from Dfinity’s own on-chain application contracts (App Canisters). The application contracts here refer to the contracts deployed by application developers on Dfinity to run custom cross-chain message processing logic.

[0045] The off-chain relay (Relayer) is responsible for collecting cross-chain message requests from all access chains, then generating a corresponding Merkle proof for each cross-chain message, and finally submitting the cross-chain message and the corresponding Merkle proof data to the proxy contract on the Dfinity chain, which verifies and processes the message. It is important to note that the message submission interface of the proxy contract has no permission control, because messages must be Merkle verified before execution. This means that off-chain relays are permissionless. Anyone can become an off-chain relay to transmit cross-chain messages, and multiple off-chain relays can exist at the same time, eliminating the problem of single point of failure.

[0046] For application developers, the Dfinity on-chain application contract is an optional component that embodies the programmability of this cross-chain communication system. Developers can customize cross-chain message processing logic in the application contract (App Canister). For example, a multi-chain application deploys smart contracts on both Chain A and Chain B, communicating through this cross-chain communication system. If the developer needs to customize the message processing logic, they can write the processing logic into App Canister and deploy it to Dfinity. The cross-chain message sent by the application contract on Chain A is set to the message processing App Canister on the Dfinity chain. After the proxy contract receives the message from the application contract on Chain A, it forwards it to App Canister. App Canister can process the cross-chain request according to the pre-defined logic, then send the processed message back to the proxy contract, which finally forwards it to the target chain B.

[0047] The above description of the embodiments is intended to facilitate understanding and application of the present invention by those skilled in the art. It is apparent that those skilled in the art can readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without requiring creative effort. Therefore, the present invention is not limited to the above embodiments. Any improvements or modifications made by those skilled in the art based on the disclosure of the present invention should fall within the scope of protection of the present invention.

Claims

1. A cross-chain communication method based on the Dfinity blockchain, characterized by: For any access chain, the gateway smart contract on the access chain is responsible for receiving cross-chain message requests from application smart contracts on other chains. All cross-chain message requests are organized into a Merkle tree. When a new cross-chain message enters, its hash value will be inserted into the Merkle tree as a leaf node, and the Merkle tree root hash value will be updated accordingly. At the same time, the gateway smart contract receives and processes cross-chain messages from other chains, parses the receiving contract address of the cross-chain message, and calls the recipient's cross-chain message processing method to remind the recipient of the latest cross-chain message. The steps of the cross-chain message processing method are as follows: Step A. Monitor all access chains through off-chain relays to obtain the latest cross-chain message requests; Step B. Upon receiving a cross-chain message request, the validator contract on the Dfinity chain is used to periodically query the Merkle root hash value of the latest cross-chain message from the access chain. Step C. The off-chain relay generates a corresponding Merkle proof for each cross-chain message received, and submits the cross-chain message and Merkle proof to the proxy contract on the Dfinity chain; Step D. After receiving the cross-chain message and Merkle proof, the proxy contract calls the verifier contract of the corresponding access chain to verify the authenticity of the cross-chain message; Step E. The proxy contract forwards the verified cross-chain message to the receiving contract on the target chain; Step F. If the target chain of the cross-chain message is the Dfinity chain, the proxy contract directly calls the application smart contract on the Dfinity chain and sends the cross-chain message to the application smart contract; Step G. If the target chain of the cross-chain message is another access chain, the proxy contract constructs a target chain transaction, signs the transaction using the threshold ECDSA signature method provided by the Dfinity chain, and then sends the transaction to the target chain.

2. The cross-chain communication method according to claim 1, characterized in that: Each access chain will correspond to a validator contract on the Dfinity chain. The validator contract is dynamically created and controlled by the proxy contract. The validator contract is responsible for regularly querying the Merkle tree root hash value of the latest cross-chain message from the corresponding access chain for subsequent verification of the authenticity of the cross-chain message.

3. The cross-chain communication method according to claim 1, characterized in that: The proxy contract is located on the Dfinity chain and is used to create and control all validator contracts. When a new chain needs to be accessed, the proxy contract will create a corresponding validator contract for the new access chain. The proxy contract is also used to receive and verify cross-chain messages from off-chain relays and forward verified cross-chain messages.

4. The cross-chain communication method according to claim 1, characterized in that: The off-chain relay is responsible for collecting cross-chain message requests from all access chains, then generating a corresponding Merkle proof for each cross-chain message, and finally submitting the cross-chain message and Merkle proof data to the proxy contract on the Dfinity chain. The proxy contract will verify and process these cross-chain messages.

5. The cross-chain communication method according to claim 1, characterized in that: In step B, the validator contract uses the Dfinity chain’s heartbeat method to periodically query the Merkle tree root hash value of the latest cross-chain message from the access chain.

6. The cross-chain communication method according to claim 1, characterized in that: In step B, the verifier contract queries the Merkle tree root hash value of the cross-chain message from the access chain using the native HTTP method of the Dfinity chain, and queries the tree nodes from multiple access chains each time, eliminating the single point of failure problem.

7. The cross-chain communication method according to claim 1, characterized in that: In step D, the proxy contract verifies the authenticity of the received cross-chain message using the Merkle proof method.

8. The cross-chain communication method according to claim 1, characterized in that: In step G, the proxy contract sends the transaction using the HTTP call method provided by the Dfinity chain to the proxy contract.

Images