A multi-party cross-chain system based on relay chain

Abstract

The application relates to a multi-party cross-chain system based on a relay chain, which comprises a business chain, a relay chain and a cross-chain gateway, the execution sequence of a cross-chain request is determined first, then the cross-chain gateway listens to the update of a cross-chain trigger condition on the relay chain, starts to listen to chain transactions, the cross-chain gateway sends an application chain transaction meeting the cross-chain trigger condition to the relay chain to generate a cross-chain request, the cross-chain management contract of the relay chain first carries out relevant verification, after the cross-chain request is established, the cross-chain management contract on the relay chain controls the execution of the cross-chain request, the cross-chain management contract manages the storage of to-be-executed chain calling information, and the cross-chain gateway listens to whether the storage has relevant chain calling; if yes, the cross-chain trigger condition signature is verified and the chain calling is executed. The multi-party cross-chain system provided by the application supports cross-chain requests between different users on the business chain, the cross-chain request is completed by using a chain account specified by a user, and the cross-chain rule is jointly formulated by the two parties, so that the reliability of the cross-chain channel is increased.

Description

Technical Field

[0001] This invention relates to a multi-party cross-chain system based on a relay chain. Background Technology

[0002] With the rapid development of blockchain technology, more and more blockchain networks are being created and applied in various fields. Because each blockchain network has its own trust rules and protocols, effective collaboration between different blockchains is difficult. Cross-chain technology refers to the technology that crosses the data trust boundary (the scope of the consensus mechanism) of a single blockchain system to achieve blockchain interoperability, that is, effective collaboration between two or more blockchains that do not affect each other, thereby enabling the trusted cross-chain flow of information / value.

[0003] To achieve interoperability between blockchain systems, various cross-chain solutions have been proposed. These can be broadly categorized based on whether they rely on other blockchains: direct-connection solutions, where blockchains requiring cross-chain functionality directly achieve interoperability; and relay-chain solutions, where blockchains with cross-chain needs use other blockchains as relays to achieve interoperability through multi-hop cross-chain operations. Direct-connection solutions are suitable for scenarios with a small number of blockchain systems requiring cross-chain functionality, offering higher communication efficiency. Relay-chain solutions are suitable for scenarios with a large number of blockchain systems requiring cross-chain functionality, as they can reduce trust costs by reusing trusted verification data from different chains, but their communication efficiency is lower. A universal cross-chain system must ultimately be based on a relay chain.

[0004] Cross-chain operations are categorized into cross-chain write operations and cross-chain read operations based on whether they alter the blockchain state. Changes to the blockchain state require a transaction to trigger, and transactions need to be signed by a blockchain account to be recorded on the chain. Therefore, a cross-chain write operation necessarily requires a destination blockchain account to complete. Based on whether the source and destination blockchain accounts are held by the same user, relay-chain-based cross-chain systems can be further divided into relay-chain-based man-in-the-middle cross-chain systems and relay-chain-based multi-party cross-chain systems.

[0005] Interledger is a secure payment protocol proposed by Ripple for cross-chain asset transfers in the absence of usable intermediaries in interactive blockchains, and it is not limited by the blockchain connection topology. Its core idea is to connect the sender and receiver of cross-chain transactions using connectors with accounts on two blockchains simultaneously across multiple hops. Cross-chain payments are achieved through a set of transactions on the source blockchain, the connector's blockchain, and the destination blockchain, including transactions between the sender and connector, between connectors, and between the connector and the receiver, using one or more blockchains. Although Interledger aims to achieve interaction between two blockchains, multiple blockchains interact during implementation, essentially making it a relay-chain based cross-chain solution, with the blockchains of the connectors all serving as "relay chains."

[0006] TCIP is a cross-chain protocol proposed by ChangAn Chain, with a logical architecture as follows: Figure 1 As shown, TCIP comprises four logical modules: a relay chain, a relay gateway, a cross-chain gateway, and a business chain. Business chains can be homogeneous or heterogeneous blockchain systems. Each business chain has a corresponding cross-chain gateway listening for cross-chain requests. All cross-chain gateways and relay gateways are configured with default blockchain accounts. Cross-chain security comes from the fact that cross-chain gateway administrators can configure cross-chain triggers for their respective chains. Cross-chain permissions between chains are configured on the relay chain and managed by the relay chain administrator.

[0007] Business Chain: A business chain refers to the chain that a user is currently using. This chain needs to receive cross-chain requests from other business chains or initiate cross-chain requests to other business chains.

[0008] Relay chain: A relay chain, also known as a relayer, is a third-party chain that connects other chains in a blockchain network through a cross-chain messaging protocol.

[0009] Relay Gateway: As the name suggests, the relay gateway establishes a link with the relay chain. By interacting with the cross-chain management contract in the relay chain, it schedules various stages of cross-chain transactions and provides transaction verification functions.

[0010] Cross-chain gateway: A cross-chain gateway is a gateway that interacts with the business chain. It listens to the contract events of the business chain to determine whether the event is a cross-chain event. If the triggering conditions are met, it initiates a cross-chain transaction.

[0011] Cross-chain triggers: A cross-chain trigger is a way for a cross-chain gateway to handle contract events in a business chain. If the conditions of the cross-chain trigger are not met, the contract event will be discarded. If the conditions of the cross-chain trigger are met, the cross-chain gateway will construct a cross-chain transaction according to the configuration of the cross-chain trigger.

[0012] Interledger requires users to have chain accounts on both the source and destination blockchains, which limits its scalability. TCIP, on the other hand, uses default blockchain accounts for cross-chain communication, also resulting in insufficient scalability. Furthermore, TCIP's cross-chain permission control relies on the cross-chain gateway's trigger settings and the relay chain's interoperability configuration. This means it can only control chain-to-chain cross-chain permissions, not user-to-user cross-chain requests between different chains, leading to insufficient security and hindering its widespread adoption. Summary of the Invention

[0013] To address the existing problems, this invention provides a multi-party cross-chain system based on a relay chain.

[0014] The present invention adopts the following technical solution:

[0015] A multi-party cross-chain system based on a relay chain, the multi-party cross-chain system comprising: a business chain, a relay chain, and a cross-chain gateway, wherein the relay chain is configured with a cross-chain management contract and a verification contract, the cross-chain gateway corresponds one-to-one with the business chain, and the business chain communicates with the relay chain through the corresponding cross-chain gateway;

[0016] In a cross-chain transmission, the business chain that initiates the cross-chain information transmission is called the source blockchain, and the business chain that receives the cross-chain information is called the destination blockchain.

[0017] The cross-chain process includes:

[0018] Step 1: Execute a cross-chain request between the source blockchain and the destination blockchain;

[0019] Step 2: The cross-chain gateway listens for updates to the cross-chain triggering conditions from the relay chain. After verifying the signature, the cross-chain gateway stores the cross-chain triggering conditions locally and then starts listening for chain transactions.

[0020] Step 3: The cross-chain gateway sends application chain transactions that meet the cross-chain triggering conditions to the relay chain to generate a cross-chain request. The cross-chain management contract of the relay chain first verifies the validity of the transaction through the verification contract, and then verifies the cross-chain triggering conditions and event content.

[0021] Step 4: After a cross-chain request is established, the cross-chain management contract on the relay chain controls the execution of the cross-chain request. The cross-chain management contract manages the storage of chain call information to be executed. The cross-chain gateway listens to the storage for any related chain calls. If there are any, it verifies the cross-chain trigger condition signature and executes the chain call.

[0022] Furthermore, the cross-chain gateway includes an interface layer, a core module layer, and a service layer. The core module layer includes a cross-chain request processor, a chain account manager, and a cross-chain trigger. The cross-chain request processor is used to interact with the business chain and execute cross-chain requests. The chain account manager is used to enable users to register accounts on the cross-chain gateway through the interface and obtain private keys. The cross-chain trigger is used to pull cross-chain triggering rules from the relay chain and check whether the cross-chain triggering rule has the signature of a corresponding cross-chain gateway registered account.

[0023] Furthermore, the cross-chain request between the source blockchain and the destination blockchain includes: first, the source blockchain executes the corresponding contract call information to trigger the cross-chain request; then, the destination blockchain executes the corresponding contract call information. If the call is successful, the source blockchain executes the corresponding contract confirm call information, and the destination blockchain executes the corresponding contract confirm call information; if the call fails, the source blockchain executes the corresponding contract cancel call information, and the destination blockchain executes the corresponding contract cancel call information.

[0024] Furthermore, the cross-chain triggering condition is a cross-chain triggering condition that is pre-registered on the relay chain before the cross-chain operation. The cross-chain triggering condition is defined as follows:

[0025] cond={chain,contractName,eventName}

[0026] Here, cond represents the cross-chain trigger condition, chain is the chain name, contractName is the contract name, and eventName is the event name.

[0027] Furthermore, when monitoring on-chain transactions, the screening criteria for on-chain transactions are as follows:

[0028] equal(tx.chain,cond.chain)∧equal(tx.contractName,cond.contractName)

[0029] ∧equal(tx.eventName,cond.eventName)

[0030] Where tx = {chain, eventName, event} is the transaction that triggers the cross-chain request on the source blockchain, event is the event triggered by the transaction, event = {eventName, eventContent}, and eventContent is the event content defined by the contract.

[0031] Furthermore, in step 3, assuming f is a cross-chain request generation algorithm, different cross-chain request generation algorithms f are obtained based on different input parameters. gen :

[0032] f gen =f(confirm) source cancel source invoke dest confirm dest cancel dest )

[0033] Among them, confirm sourc 'e' indicates the contract confirm call information on the source blockchain; 'cancel' indicates the cancellation call information. source This indicates a contract cancellation call message on the source blockchain; invoke dest This indicates contract call information on the target blockchain; confirm dest This indicates a confirm call message for a contract on the target blockchain; cancel. dest This indicates a contract cancellation call message on the target blockchain;

[0034] q represents a cross-chain request, and its generation process is as follows:

[0035] q = f gen (tx.eventContent)

[0036] =confirm' source ,cancel′ source ,invoke′ dest ,confirm′ dest ,cancel′ dest

[0037] confirm' source =gen(confirm) source ,tx.eventContent)

[0038] cancel' source =gen(cancel) source ,tx.eventContent)

[0039] invoke′ dest =gen(invoke) dest ,tx.eventContent)

[0040] confirm' dest =gen(confirm)dest ,tx.eventContent)

[0041] cancel' dest =gen(cancel) dest ,tx.eventContent)

[0042] Here, gen is the message generation algorithm.

[0043] Furthermore, in step 4, the cross-chain request status includes 5 types: Pending, Confirm, Success, Rollback, and Fail.

[0044] When the status is Pending, the cross-chain management contract will invoke' dest Place it in the pending execution chain of calls;

[0045] If the cross-chain gateway executes successfully, the cross-chain request status will be changed to Confirm, and the invoke request will be deleted. dest Insert canfirm' source and confirm' dest Otherwise, change the status to Rollback and delete invoke'. dest Insert cancel' source and cancel' des t;

[0046] If confirm' source and confirm' dest If the execution is successful, the status will be "Success".

[0047] If cancel' source and cancel' dest If the execution is successful, the status will be Fail.

[0048] The beneficial effects of this invention include: the multi-party cross-chain system based on a relay chain provided by this invention can support cross-chain requests between different users on the source blockchain and the destination blockchain. The cross-chain request is completed using the chain account specified by the user, and the cross-chain rules are also jointly formulated by both parties, thereby increasing the reliability of the cross-chain channel and improving the interoperability and security between blockchains. Attached Figure Description

[0049] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below:

[0050] Figure 1 This is the existing TCIP logical architecture diagram;

[0051] Figure 2 This is a structural diagram of a multi-party cross-chain system based on a relay chain provided by the present invention;

[0052] Figure 3 This is a cross-chain gateway architecture diagram;

[0053] Figure 4 This is a cross-chain request state transition diagram. Detailed Implementation

[0054] To illustrate the technical solution described in this application, specific embodiments will be described below.

[0055] This embodiment provides a multi-party cross-chain system based on a relay chain, such as... Figure 2 As shown, it includes: business chain, relay chain and cross-chain gateway.

[0056] A business chain refers to the blockchain that users are currently using. This chain needs to receive cross-chain requests from other business chains or initiate cross-chain requests to other business chains. In a cross-chain transmission, the business chain that initiates the cross-chain information transmission is called the source blockchain, and the business chain that receives the cross-chain information is called the destination blockchain.

[0057] A relay chain, also known as a relayer, is a third-party chain that connects other chains in a blockchain network through a cross-chain messaging protocol.

[0058] The relay chain is configured with a cross-chain management contract and a verification contract. The cross-chain management contract supports adding / querying cross-chain trigger conditions and initiating cross-chain requests. The verification contract supports verifying the authenticity of transactions on the application chain.

[0059] Cross-chain gateway: A cross-chain gateway is a gateway that interacts with the business chain, responsible for simultaneously monitoring both the business chain and the relay chain. First, it obtains cross-chain triggering rules from the relay chain. Based on these rules, it monitors contract events on the business chain and sends transactions that meet the triggering conditions to the relay chain. The relay chain verifies the authenticity of the transactions by verifying the contract, and then initiates a cross-chain request based on the cross-chain triggering rules and the transaction content. Each cross-chain gateway corresponds one-to-one with a business chain, and the business chain communicates with the relay chain through its corresponding cross-chain gateway.

[0060] like Figure 3As shown, the cross-chain gateway comprises an interface layer, a core module layer, and a service layer. The core module layer includes a cross-chain request processor, a chain account manager, and cross-chain triggers. The cross-chain request processor interacts with the business chain to execute cross-chain requests. The chain account manager allows users to register accounts on the cross-chain gateway and obtain their private key Sk through an interface (specifically the ChainIdentity interface). The cross-chain triggers retrieve cross-chain trigger rules from the relay chain and check if the rule has a signature from a registered account on the cross-chain gateway.

[0061] Before describing the cross-chain process, let's first explain some basic parameters involved in it.

[0062] tx = {chain, contractName, event} is the transaction on the source blockchain that triggered the cross-chain request.

[0063] event = {eventName, eventContent} is an event that is triggered by tx.

[0064] "chain" is the name of the chain.

[0065] contractName is the name of the contract.

[0066] eventName is the event name.

[0067] eventContent is the event content.

[0068] args are the parameters used to call the contract.

[0069] invoke = {chain, contractName, args} represents the contract invocation information on the chain.

[0070] invoke source This indicates that chain = source, and source means source chain, which represents the source blockchain and the contract call information on the source chain.

[0071] invoke dest This indicates that chain = dest, and dest is the dest chain, representing the target blockchain and the contract call information on the dest chain.

[0072] cancel = {chain, contractName, args} represents the cancellation call information for the contract on the chain.

[0073] cancel sourceThis indicates that chain = source, and contains information about canceling a contract on the source chain.

[0074] cancel dest This indicates that chain=dest contains the contract cancel call information on the dest chain.

[0075] confirm = {chain, contractName, args} represents the confirm call information for the contract on the chain.

[0076] confirm source This indicates that chain = source, and the contract confirm call information is on the source chain.

[0077] confirm dest This indicates that chain=dest contains the contract confirm call information on the dest chain.

[0078] u source ={sk,pk} represents the user in the source chain. dest ={sk,pk} represents a user in the dest chain. sk and pk are a public-private key pair in asymmetric cryptography.

[0079] The cross-chain process is described in detail below.

[0080] Step 1: Execute a cross-chain request between the source blockchain and the destination blockchain.

[0081] Step 1 is the cross-chain request execution order confirmation process. Specifically: First, the source blockchain executes the corresponding contract call information, i.e., invoke. source This triggers a cross-chain request; then, the destination blockchain executes the corresponding contract call information, i.e., invoke. dest If the call is successful, the source blockchain executes the corresponding contract confirm call information, i.e., confirm. source The target blockchain executes the corresponding contract confirm call information, i.e., confirm. dest If the call fails, the source blockchain executes the corresponding contract's cancel call information, i.e., cancels the call. source The destination blockchain executes the corresponding contract cancel call information, i.e., cancel. dest .

[0082] Step 2: The cross-chain gateway listens for updates to the cross-chain trigger conditions from the relay chain. After verifying the signature, the cross-chain gateway stores the cross-chain trigger conditions locally and then starts listening for chain transactions.

[0083] Step 2 involves monitoring the chain transaction process. The cross-chain trigger condition is a condition that the user pre-registers on the relay chain before conducting a cross-chain transaction. The cross-chain trigger conditions are defined as follows:

[0084] cond={chain,contractName,eventName}

[0085] Here, cond represents the cross-chain trigger condition, chain is the chain name, contractName is the contract name, and eventName is the event name.

[0086] Executing a cross-chain request requires the cross-chain gateway to use a chain account to execute the request. Therefore, the account holder needs to sign the cross-chain triggering conditions and cross-chain request generation parameters using their private key, indicating their agreement to allow the cross-chain gateway to use the chain account to execute the cross-chain request when such a transaction occurs. Signature is an asymmetric cryptographic signature algorithm, and Verifity is an asymmetric cryptographic signature verification algorithm.

[0087] sign = {sign source ,sign dest}

[0088] msg

[0089] =hash(cond,confirm) source cancel source ,invok dest confirm dest cancel dest )

[0090] sign source =Signature(u source .sk,msg)

[0091] sign dest =Signature(u dest .sk,msg)

[0092] The cross-chain gateway listens for updates to the trigger conditions on the relay chain. After verifying the signature, the gateway stores the cross-chain trigger conditions locally. It then begins listening for chain transactions, filtering them according to the following criteria:

[0093] equal(tx.chain,cond.chain)∧equal(tx.contractName,cond.contractName)

[0094] ∧equal(tx.eventName,cond.eventName)

[0095] Here, "chain" specifically refers to the name of the chain on which the transaction takes place, "contractName" specifically refers to the name of the contract in which the transaction is executed, "event" specifically refers to the event triggered by the transaction, "eventName" specifically refers to the name of the event triggered by the transaction, and "eventContent" specifically refers to the event content defined by the contract.

[0096] Step 3: The cross-chain gateway sends application chain transactions that meet the cross-chain triggering conditions to the relay chain to generate a cross-chain request. The cross-chain management contract of the relay chain first verifies the validity of the transaction through the verification contract, and then verifies the cross-chain triggering conditions and event content.

[0097] Step 3 is the cross-chain request generation process. The cross-chain gateway sends the application chain transaction tx that meets the cross-chain triggering conditions to the relay chain to generate a cross-chain request. The cross-chain management contract of the relay chain will first verify the validity of the transaction through the verification contract, and then verify the cross-chain triggering conditions and event content.

[0098] Suppose f is a cross-chain request generation algorithm; different cross-chain request generation algorithms f are obtained based on different input parameters. gen :

[0099] f gen =f(confirm) source cancel source invoke dest confirm dest cancel dest )

[0100] q represents a cross-chain request, and its generation process is as follows:

[0101] q = f gen (tx.eventContent)

[0102] =confirm' source ,cancel′ source ,invoke′ dest ,confirm′ dest ,cancel′ dest

[0103] confirm' source =gen(confirm') sourxce ,tx.eventContent)

[0104] cancel' source =gen(cancel′) source ,tx.eventContent)

[0105] invoke′ dest =gen(invoke′) dest ,tx.eventContent)

[0106] confirm' dest =gen(confirm') dest ,tx.eventContent)

[0107] cancel' dest =gen(cancel′) dest ,tx.eventContent)

[0108] gen is a message generation algorithm. The first parameter arg[0] is a string, the second parameter arg[1] is a string array, and arg[1].[i] means to take the i-th item of the second parameter and replace the string in the first parameter arg[0] in the form of $[i] with arg[1].[i].

[0109] Step 4: After a cross-chain request is established, the cross-chain management contract on the relay chain controls the execution of the cross-chain request. The cross-chain management contract manages the storage of chain call information to be executed. The cross-chain gateway listens to the storage for any related chain calls. If there are any, it verifies the cross-chain trigger condition signature and executes the chain call.

[0110] Step 4 is the cross-chain request execution process. After the cross-chain request is established, the cross-chain management contract on the relay chain controls the execution of the cross-chain request. The cross-chain management contract manages the storage of chain call information to be executed. The cross-chain gateway listens to the storage for any related chain calls. If there are any, it verifies the cross-chain trigger condition signature and executes the chain call.

[0111] Cross-chain request states include five types: Pending, Confirm, Success, Rollback, and Fail.

[0112] like Figure 4 As shown, when the status is Pending, the cross-chain management contract will invoke' dest Place it in the pending execution chain.

[0113] If the cross-chain gateway executes successfully, the cross-chain request status will be changed to Confirm, and the invoke request will be deleted. dest Insert canfirm' source and confirm' dest Otherwise, change the status to Rollback and delete invoke'. dest Insert cancel' sourceand cancel' des t.

[0114] If confirm' source and confirm' dest If the execution is successful, the status will be "Success".

[0115] If cancel' source and cancel' dest If the execution is successful, the status will be Fail.

[0116] This embodiment provides a multi-party cross-chain system based on a relay chain, which has the following advantages:

[0117] (1) Cross-chain request multi-party protocol: Cross-chain requests involve multiple application chains executing together, so cross-chain requests should only be executed after the administrators of multiple application chains agree. However, it is impossible for every request to require the agreement of multiple administrators before execution, as this would be very inefficient and detrimental to production. It is advisable to consider a multi-party consensus among administrators on the triggering conditions and generation methods of cross-chain request generation. Assuming that the generator execution environment is trustworthy, then the cross-chain requests triggered by the consensus triggering generator to generate cross-chain requests are based on multi-party consensus.

[0118] (2) The cross-chain gateway sets up multiple proxy accounts. After verifying that the account signature of the cross-chain trigger condition is correct, it can call the corresponding chain account to complete the cross-chain request.

[0119] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-party cross-chain system based on a relay chain, characterized in that, The multi-party cross-chain system includes: a business chain, a relay chain, and a cross-chain gateway. The relay chain is configured with a cross-chain management contract and a verification contract. The cross-chain gateway corresponds one-to-one with the business chain, and the business chain communicates with the relay chain through the corresponding cross-chain gateway. In a cross-chain transmission, the business chain that initiates the cross-chain information transmission is called the source blockchain, and the business chain that receives the cross-chain information is called the destination blockchain. The cross-chain process includes: Step 1: Execute a cross-chain request between the source blockchain and the destination blockchain; Step 2: The cross-chain gateway listens for updates to the cross-chain triggering conditions from the relay chain. After verifying the signature, the cross-chain gateway stores the cross-chain triggering conditions locally and then starts listening for chain transactions. Step 3: The cross-chain gateway sends application chain transactions that meet the cross-chain triggering conditions to the relay chain to generate a cross-chain request. The cross-chain management contract of the relay chain first verifies the validity of the transaction through the verification contract, and then verifies the cross-chain triggering conditions and event content. Step 4: After a cross-chain request is established, the cross-chain management contract on the relay chain controls the execution of the cross-chain request. The cross-chain management contract manages the storage of chain call information to be executed. The cross-chain gateway listens to the storage for any related chain calls. If there are any, it verifies the cross-chain trigger condition signature and executes the chain call. Cross-chain triggering conditions are cross-chain triggering conditions that are pre-registered on the relay chain before the cross-chain operation. The cross-chain triggering conditions are defined as follows: ； in, Indicates the cross-chain triggering condition. It is the chain name. It is the contract name. It is the event name; When monitoring on-chain transactions, the filtering criteria for on-chain transactions are as follows: ； in, It is a transaction that triggers a cross-chain request on the source blockchain. It is an event triggered by a transaction. , It is the event content defined by the contract; In step 3, assume It is a cross-chain request generation algorithm, which generates different cross-chain request generation algorithms based on different input parameters. : ； in, This indicates the contract confirm call information on the source blockchain; This indicates the contract cancel call information on the source blockchain; This indicates contract call information on the target blockchain; This indicates the contract confirm call information on the target blockchain; This indicates a contract cancellation call message on the target blockchain; This is a cross-chain request, and the generation process is as follows: ； ； ； ； ； ； in, It is a message generation algorithm.

2. The multi-party cross-chain system based on a relay chain according to claim 1, characterized in that, The cross-chain gateway includes an interface layer, a core module layer, and a service layer. The core module layer includes a cross-chain request processor, a chain account manager, and a cross-chain trigger. The cross-chain request processor interacts with the business chain to execute cross-chain requests. The chain account manager enables users to register accounts on the cross-chain gateway through the interface and obtain private keys. The cross-chain trigger is used to pull cross-chain triggering rules from the relay chain and check whether the cross-chain triggering rule has the signature of a corresponding cross-chain gateway registered account.

3. The multi-party cross-chain system based on a relay chain according to claim 1, characterized in that, The process of executing a cross-chain request between the source blockchain and the destination blockchain includes: First, the source blockchain executes the corresponding contract call information to trigger the cross-chain request; then, the destination blockchain executes the corresponding contract call information. If the call is successful, the source blockchain executes the corresponding contract confirm call information, and the destination blockchain executes the corresponding contract confirm call information; if the call fails, the source blockchain executes the corresponding contract cancel call information, and the destination blockchain executes the corresponding contract cancel call information.

4. The multi-party cross-chain system based on a relay chain according to claim 1, characterized in that, In step 4, the cross-chain request status includes 5 types: Pending, Confirm, Success, Rollback, and Fail. When the status is Pending, the cross-chain management contract will Place it in the pending execution chain of calls; If the cross-chain gateway executes successfully, the cross-chain request status will be changed to Confirm and then deleted. , put and Otherwise, change the status to Rollback and delete. , put and ; if and If the execution is successful, the status will be "Success". if and If the execution is successful, the status will be Fail.

Images