A cross-blockchain interaction method based on a relay chain

Abstract

This invention relates to a cross-blockchain interaction method based on a relay chain, belonging to the field of inter-chain blockchain communication. It includes transaction matching using a transaction matching algorithm, transaction coordination by the relay chain, and transaction verification by a sub-marker smart contract. Specifically, it includes the following steps: S1: A user joins the relay chain; S2: A user submits a transaction request, which is packaged and stored in a block on the relay chain. The user matches the request using the transaction matching algorithm. When a cross-chain transaction is successfully matched, a marker smart contract coordinating this cross-chain transaction is generated on the relay chain. This contract generates a unique ID to identify the cross-chain transaction and sends the matching information to the successfully matched user; S3: After successful matching, a preparation phase begins, where the relay chain and the participating blockchains prepare for the subsequent actual cross-chain action; S4: After all preparations are completed, a coordination phase begins; the coordination phase is the specific execution process of the cross-chain transaction.

Description

Technical Field

[0001] This invention belongs to the field of blockchain inter-chain communication and relates to a cross-blockchain interaction method based on a relay chain. Background Technology

[0002] Blockchain technology, with its advantages of decentralization, trustlessness, immutability, and traceability, represents a disruptive transformation and challenge to traditional social organizations and operational methods. It is considered a supporting technology for building the future "Internet of Trust" and "Internet of Value," attracting increasing attention from the investment community, academia, industry, and government departments. With the rapid development of blockchain technology, various blockchain applications are emerging. However, current blockchain projects are heterogeneous blockchains developed by different teams based on different scenario requirements and design concepts, employing different technical architectures. Due to the inherent isolation characteristics of blockchain, the isolation between block information stored on different blockchains inevitably creates a "value silo" effect. Therefore, how to achieve interconnection and value transfer between blockchains has become a key research focus in current blockchain technology.

[0003] Cross-chain technology, as the name suggests, uses certain technologies to allow value to cross the barriers between chains, enabling the transfer of value from one blockchain to another, thus facilitating the circulation of value. Currently, there are four main cross-chain technologies: notary mechanisms, sidechains / relays, hash locking, and distributed private key control. While notary technology is simple to implement, the introduction of trusted third parties such as notaries and exchanges clearly contradicts the decentralized nature of blockchain and can also introduce performance bottlenecks. Sidechain / relay technology enables cross-chain communication between heterogeneous blockchains and mitigates centralization issues through relay chains, but it requires storing large amounts of block header information from heterogeneous blockchains for verification and performs poorly when dealing with complex cross-chain transactions. Hash locking schemes use hash time locks, which are relatively simple to implement and mitigate centralization issues, but they only enable cross-chain asset swaps, not cross-chain asset transfers. While distributed private key control mechanisms ensure that the user holding the private key retains ownership of the assets, they are difficult to implement. Summary of the Invention

[0004] In view of this, the purpose of this invention is to address the shortcomings of existing relay chain cross-chain solutions, which require storing a large amount of different types of blockchain block header information for verification, have poor scalability, and whose performance is greatly affected by the increasing complexity of cross-chain transactions. This invention provides a highly scalable relay chain cross-chain method that can still achieve high efficiency for complex cross-chain transactions, and reduces the amount of information that the relay chain needs to store, thereby improving the efficiency of the relay chain in coordinating cross-chain transactions.

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

[0006] A cross-blockchain interaction method based on a relay chain includes matching transactions using a transaction matching algorithm, coordinating transactions via the relay chain, and verifying transactions via a sub-signature smart contract. Specifically, it includes the following steps:

[0007] S1: User joins the relay chain;

[0008] S2: Relay chain users submit transaction requests, which are packaged and stored in blocks on the relay chain. Users on the relay chain match transactions using the transaction matching algorithm in the consensus algorithm. When a cross-chain transaction is successfully matched, a smart contract that coordinates this cross-chain transaction, i.e., a cross-chain transaction instance, is generated on the relay chain. This contract generates a unique ID to identify this cross-chain transaction and sends the matching information to the user who was successfully matched.

[0009] S3: After a successful match, the preparation phase begins, during which the relay chain and the blockchains participating in the cross-chain operation prepare for the actual cross-chain action.

[0010] S4: Once all preparations are complete, the coordination phase begins; the coordination phase is the specific execution process of cross-chain transactions.

[0011] Furthermore, step S1 specifically includes: In step S1, a user must first become a user of the relay chain before submitting a cross-chain request. Each user on the relay chain has a reputation value R and a historical total return P. The reputation value R reflects the integrity of a user's behavior on the relay chain. A user's reputation value R increases when participating in cross-chain transactions and the consensus process according to the rules; otherwise, it decreases. The reputation value R affects the user priority for submitting transaction requests and the probability of a user achieving consensus. The historical total return P represents the sum of the user's gains from participating in consensus on the relay chain, used to balance the returns among users and stimulate users' enthusiasm for participating in consensus. The higher a user's historical total return P, the lower their probability of achieving consensus in the future. Users who achieve consensus gain not only the right to package transactions but also the right to match transactions. Users on the relay chain who want to participate in consensus must first join a consensus group. The requirement for joining a consensus group is a reputation value R. i It is greater than or equal to the average reputation value R of the current consensus group.

[0012] Furthermore, the transaction matching algorithm described in step S2 specifically includes: introducing user weight and time weight; the format of the transaction request is [CDid, CDnum, COid, COnum, Prior, Time], where CDid is the blockchain of the redemption destination, CDnum is the redemption amount, COid is the blockchain of the redemption source, COnum is the redemption amount provided, Prior represents the user weight, and Time represents the time weight; all transactions to be matched together form the transaction request set P; depth is used to represent the search depth.

[0013] Furthermore, the transaction matching algorithm described in step S2 includes the following steps:

[0014] S211: Select the transaction demand with the highest combined ranking of user weight Prior and time weight Time from the set P of all transaction demands to be matched, and use it as the target demand O for this matching. The time weight Time is the number of waiting periods for the transaction demand.

[0015] S212: Search for matching transactions based on the target blockchain CDid of the target requirement O, find all source blockchain COids that are the target blockchain CDids of the target requirement O, and sort the search results by user weight Prior and time weight Time.

[0016] S213: In the search results of step S212, the transaction demand of the target blockchain CDid as the target demand O source blockchain COid is searched from left to right. For each demand that meets the requirements, its transfer in CDnum and transfer out COnum are accumulated. When it matches the amount of the target demand, the match is successful. After the match is successful, the cross-chain transaction will be scored according to the user weight Prior and time weight Time of all transaction demands in the successfully matched cross-chain transaction.

[0017] S214: If no match is found in step S213, continue matching for the remaining unmatched amount in the target demand O; select the transaction demand with the highest weight that was not selected in step S213 from the list of transaction demands obtained in step S212, and use the destination blockchain CDid of this transaction demand as the new destination blockchain for the target demand, and also change CDnum to be the same as this demand; the source blockchain COid of the target demand remains unchanged, but the amount COnum becomes the remaining unmatched amount; return to step S212, increment the search depth by one, and search again; set the maximum search depth, and when the search depth is greater than the maximum search depth, the matching in this round fails and returns.

[0018] Furthermore, the consensus phase of step S1 specifically includes the following steps:

[0019] S221: At the start of consensus, first calculate the average return P of the consensus group, denoted as:

[0020]

[0021] Where n is the total number of users in the consensus group, P i The total historical revenue of user i;

[0022] S222: Based on whether the total historical return is greater than the average return P, the consensus group users are divided into two groups, G1 and G2:

[0023] G1={x∈G|f x ≥P}

[0024] G2={y∈G|0 <f y <P}

[0025] Where G is the set of all consensus group users;

[0026] S223: Calculate the number of users n1 and n2 in G1 and G2 respectively, and the proportion of user i's reputation value to the total reputation value of all users in the consensus group, to obtain the probability that user i is selected as a consensus representative:

[0027]

[0028] Among them, R i P is the reputation value of user i. i Let n be the total historical earnings of user i, and n be the total number of users in the consensus group.

[0029] S224: After being selected as a consensus user, a user obtains the right to package and match transactions in the next cycle. The consensus user packages the transaction requests submitted by users in the current cycle and calls the matching algorithm to match transactions, thereby obtaining commissions and reputation value enhancement rewards for the corresponding transaction requests. After a transaction is successfully matched, the matching information is distributed to the corresponding user.

[0030] Furthermore, step S3 specifically includes the following steps:

[0031] S31: After all the sub-signature smart contracts in the participating chains have been submitted, the users participating in cross-chain transactions in each chain submit the relevant specific sub-transactions according to the matching results, and use the state of the sub-signature smart contract as the triggering basis for the sub-transaction smart contract; after submission, in coordination with the sub-signature smart contract, the sub-signature smart contract will save the block id and transaction id of all cross-chain sub-transactions in the current chain, while the cross-chain sub-transactions save the block id and transaction id of the signature smart contract of the chain in which they are located;

[0032] S32: The sub-signal smart contract will verify whether the cross-chain sub-transaction of the current cross-chain transaction on the chain it is on has been submitted and the information is correct. If both are correct, it will synchronize the status to Ready with the cross-chain transaction instance on the relay chain. If a user wants to abort the transaction, after initiating an interruption request to the sub-signal smart contract, the sub-signal smart contract will synchronize the status to Abort with the cross-chain transaction instance on the relay chain.

[0033] S33: Cross-chain transaction instances detect the status of all sub-signal smart contracts. When the status of all sub-signal smart contracts is Ready, a state transition instruction is sent to all sub-signal smart contracts to change the status to Commit. Cross-chain sub-transactions in each chain automatically trigger transactions after detecting that the status of a sub-signal smart contract has changed to Commit. If the status of any sub-signal smart contract changes to Abort, a state transition instruction is sent to all sub-signal smart contracts to change the status to Abort. Cross-chain sub-transactions in each chain automatically abort transactions after detecting that the status of a sub-signal smart contract has changed to Abort.

[0034] Furthermore, step S4 specifically includes the following steps:

[0035] S41: Cross-chain transaction instances periodically check the status of all the sub-signal smart contracts they record. When the status of all sub-signal smart contracts is Ready, a state transition instruction is sent to all sub-signal smart contracts to change the status to Commit. After detecting that the status of the sub-signal smart contract has changed to Commit, the cross-chain sub-transactions in each chain automatically trigger the transaction to transfer the virtual currency locked in the smart contract to the corresponding account.

[0036] S42: If the state of a sub-signal smart contract changes to Abort, a state transition instruction is sent to all sub-signal smart contracts to change their state to Abort. Cross-chain sub-transactions in each chain automatically abort the transaction upon detecting that the state of a sub-signal smart contract has changed to Abort. If an incorrect transaction information is received from a sub-signal smart contract, the cross-chain transaction instance will record the user with the incorrect transaction information, lower their reputation value as a penalty, abort the transaction, and send a state transition instruction to all sub-signal smart contracts to change their state to Abort. Cross-chain sub-transactions interrupt the transaction upon detecting that the state of a sub-signal smart contract is Abort and return the locked virtual currency to the corresponding user.

[0037] The beneficial effects of this invention are as follows:

[0038] (1) This invention designs a transaction matching algorithm for cross-chain transactions, and designs a new consensus algorithm based on this algorithm. Finally, a relay chain scheme is designed based on this consensus algorithm. It realizes a relay chain cross-chain method that integrates cross-chain transaction matching, coordination and implementation, while distributing the responsibilities of the relay chain to various participating chains to avoid excessive concentration.

[0039] (2) This invention employs a three-layer structure of cross-chain transaction instances, sub-signature smart contracts, and sub-cross-chain transactions, and through layered verification, it ensures transaction reliability while reducing the amount of data that the relay chain needs to store and avoiding excessive inter-chain communication. In-chain verification and inter-chain synchronization further enhance cross-chain efficiency.

[0040] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0041] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0042] Figure 1 This is a sub-signature smart contract state transition diagram in an embodiment of the present invention;

[0043] Figure 2 This is a flowchart of a cross-chain method based on a relay chain for transaction matching consensus, as described in an embodiment of the present invention.

[0044] Figure 3 This is a timing diagram of the cross-chain transaction coordination phase in an embodiment of the present invention;

[0045] Figure 4 This is a flowchart illustrating the cross-chain transaction demand matching process in an embodiment of the present invention.

[0046] Figure 5 This is a schematic diagram illustrating an example of cross-chain transaction demand matching in an embodiment of the present invention. Detailed Implementation

[0047] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0048] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0049] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0050] This invention provides a priority-based cross-chain transaction matching algorithm. This algorithm differs from traditional matching algorithms. Cross-chain transaction matching is not like bartering; besides matching by type, it also requires matching by amount, and the exchange rates of the transactions to be matched differ, including one-to-many and many-to-many scenarios. This algorithm performs differentiated matching of cross-chain transactions based on the priority of the users submitting transaction requests and the queuing time of the transaction requests. Each transaction is stored in the format [CDid, CDnum, COid, COnum, Prior, Time], where CDid is the destination blockchain for the exchange request, CDnum is the destination amount for the exchange, COid is the source blockchain for the exchange request, COnum is the amount provided for the exchange, Prior represents the user weight, and Time represents the time weight. All transactions to be matched together form the transaction request set P. To avoid excessive search depth, depth is used to represent the search depth. The matching algorithm includes the following steps:

[0051] S11: Select the transaction demand with the highest combined ranking of user weight Prior and time weight Time (number of waiting periods for the transaction demand) from the set of all unmatched transaction demands P, and use it as the target demand O for this matching;

[0052] S12: Search for matching transactions based on the target blockchain CDid of the target requirement O, find all source blockchain COids that are the target blockchain CDids of the target requirement O, and sort the search results by user weight Prior and time weight Time.

[0053] S13: In the search results of S12, from left to right, search for transaction requirements of the target blockchain CDid as the target requirement O source blockchain COid. For each requirement that meets the requirements, accumulate its transfer in CDnum and transfer out COnum. When it matches the amount of the target requirement, the match is successful. After a successful match, the cross-chain transaction will be scored according to the user weight Prior and time weight Time of all transaction requirements in the successfully matched cross-chain transaction.

[0054] S14: If no match is found in S13, continue matching for the remaining unmatched amount in the target demand O. Select the transaction demand with the highest weight from the list of transaction demands obtained in S12 that was not selected in S13. Use the destination blockchain CDid of this transaction demand as the new destination blockchain for the target demand, and change CDnum to be the same as this demand. The source blockchain COid of the target demand remains unchanged, but the amount COnum becomes the remaining unmatched amount. Return to S12, increment the search depth by one, and search again. To avoid inefficiency caused by excessive search depth, set the maximum search depth to 10. When the search depth is greater than 10, the matching in this round fails and returns.

[0055] This invention also provides a relay chain scheme to coordinate cross-chain transactions and facilitate user submission and matching of transaction requests. To submit a cross-chain request, a user must first become a user of the relay chain. Each user on the relay chain possesses a reputation value R and a historical total return P. The reputation value R reflects the user's integrity in the relay chain. A user's reputation value R increases when participating in cross-chain transactions and the consensus process according to the rules; otherwise, it decreases. The reputation value R affects the user's priority in submitting transaction requests and the probability of achieving consensus. The historical total return P represents the sum of the user's gains from participating in consensus within the relay chain, aiming to balance user returns and encourage participation in consensus. The higher a user's historical total return P, the lower their probability of achieving consensus in the future. This relay chain scheme integrates a transaction matching algorithm into the consensus process. Users who reach consensus gain not only the right to package transactions but also the right to match them. Relay chain users wishing to participate in consensus must first join a consensus group; joining a consensus group requires a reputation value R. i It must be greater than or equal to the average reputation value R of the current consensus group. The specific consensus process is as follows:

[0056] S21: At the start of consensus, first calculate the average return P of the consensus group, denoted as:

[0057]

[0058] Where n is the total number of users in the consensus group, P i This represents the total historical revenue of user i.

[0059] S22: Based on whether the total historical return is greater than the average return P, divide the consensus group users into two groups, G1 and G2:

[0060] G1={x∈G|f x ≥P}

[0061] G2={y∈G|0 <f y <P}

[0062] Where G is the set of all consensus group users.

[0063] S23: By calculating the number of users n1 and n2 in G1 and G2 respectively, and the proportion of user i's reputation value to the total reputation value of all users in the consensus group, we can determine the probability that user i will be selected as a consensus representative.

[0064]

[0065] Among them, R i P is the reputation value of user i. i Let n be the total historical earnings of user i, and n be the total number of users in the consensus group.

[0066] S24: After being selected as a consensus user, a user gains the right to package transactions and match transactions in the next cycle. The consensus user packages the transaction requests submitted by users in the current cycle and calls the matching algorithm to match transactions, thereby obtaining commissions and reputation point rewards for the corresponding transaction requests. Transaction matching is successful.

[0067] Finally, this invention provides a cross-chain method based on a transaction matching consensus relay chain. This scheme uses the transaction matching consensus relay chain as the central hub for coordinating cross-chain transactions. By using the relay chain, it avoids the problems of centralization. Furthermore, through multi-level verification, it avoids the issues of storing large amounts of heterogeneous blockchain header information for verification and the overly centralized message exchange found in existing relay chain solutions. Users on the relay chain not only have accounts on the relay chain but also need to bind specific blockchain accounts participating in the cross-chain process, such as Ethereum, thus achieving initial connections between chains. The information that the relay chain needs to store includes user-submitted transaction requests, successfully matched cross-chain transaction information, and sub-signature smart contract information. The three-layer structure is as follows: the cross-chain transaction instance on the relay chain coordinates cross-chain transactions overall, interacts with sub-signature smart contracts, and stores the block information of the sub-signature smart contracts to verify transactions; the sub-signature smart contracts on each specific blockchain are responsible for coordinating and verifying cross-chain sub-transactions within the current chain; and the cross-chain sub-transactions on each specific blockchain are responsible for specific transfer operations, executing operations based on the state of the sub-signature smart contracts. The sub-signature smart contract serves as a bridge connecting cross-chain transaction instances and cross-chain sub-transactions, and is crucial for ensuring the transactionality of cross-chain transactions. It coordinates cross-chain transactions by switching between four states (Public, Ready, Abort, Commit), guaranteeing atomicity. Ultimately, this forms a cross-chain method that integrates transaction submission, matching, and coordination, while ensuring scalability and high efficiency. Figure 1 This is a sub-signature smart contract state transition diagram in an embodiment of the present invention, such as... Figure 1As shown, the sub-signature smart contract has four states: public, indicating that the sub-signature smart contract has been uploaded to the chain; Abort, indicating that the cross-chain transaction has been aborted; Ready, indicating that the relevant transactions within the chain where the current sub-signature smart contract is located have been completed, and it is waiting for the state changes of other blockchains participating in the cross-chain; and Commit, indicating that all sub-signature smart contracts have been completed and have entered the formal execution phase. There are four types of transitions between these states, as follows:

[0068] 1. From Public to Ready. After the sub-signal smart contract receives a state transition request from a user and checks that all users participating in cross-chain transactions in the current blockchain have correctly submitted their corresponding cross-chain transactions, it transitions from Public to Ready and provides the state to the relay layer;

[0069] 2. From Public to Abort. When a user requests abort or receives an abort message from the relay layer in the current chain, the sub-smart contract receives the message and its state changes from Public to Abort.

[0070] 3. From Ready to Abort. When a smart contract in the Ready state receives an abort message from the relay layer, it indicates that a user has aborted a cross-chain transaction, and the state changes from Ready to Abort.

[0071] 4. From Ready to Commit. When a smart contract in the Ready state receives a Commit message from the relay layer, it means that all cross-chain sub-transactions have been committed and uploaded to the chain, and the state changes from Ready to Commit.

[0072] Figure 2 This is a flowchart illustrating a cross-chain method based on a relay chain using transaction matching consensus, as described in this invention. As shown, when a user wants to perform a cross-chain operation using the method provided by this invention, they must have an account on the relay chain. This account must be bound to an account on another relevant chain, such as Ethereum, where the user wants to perform the cross-chain operation. Specifically, the user provides the public key of the corresponding account. The relay chain uses this public key to encrypt a random string and returns it to the user. If the user can decrypt the string, the binding is successful; otherwise, it fails. This method initially establishes the connection between different chains, and subsequent cross-chain transaction operations are all based on this account.

[0073] When the transaction submission and matching phase begins, this phase primarily involves the relay chain's consensus, including uploading transaction request information and matching results to the chain and matching transactions. Users submit cross-chain transaction requests, including the source chain, source address, destination chain, destination address, amount to be transferred, and amount to be transferred in. After receiving the user's transaction request, the relay chain will package the transaction request and submit it to the chain in the next cycle. The user responsible for packaging is selected from the consensus of the current cycle. The matching of cross-chain transactions and the packaging of transaction requests require the relay chain's consensus algorithm. The relay chain selects consensus representatives through the consensus algorithm, and these representatives gain the right to package and match transactions. The consensus representatives match transaction requests using the transaction matching algorithm, package the matching results to the chain, and then distribute them to the users who submitted successfully matched transaction requests, thus officially entering the cross-chain phase. Users on the relay chain can earn commissions and increase their reputation value by participating in consensus. Users in the consensus group on the relay chain participate in consensus, and when successfully elected as a consensus representative, they gain the right to package and match transactions. Transactions are matched using a transaction matching algorithm. Once a transaction is matched, the consensus representative will generate a flag smart contract on the relay chain for each matched cross-chain transaction, which is a cross-chain transaction instance. Each contract will generate a unique ID to identify this cross-chain transaction and send the matching information to the corresponding successfully matched user. At the same time, it will also package and upload the transaction requests submitted by the user in the current period to the chain.

[0074] After consensus is reached and transactions are successfully matched, the preparation phase begins, which prepares for the coordination phase. The relay chain generates a cross-chain transaction instance on the relay chain for all successfully matched cross-chain transactions to coordinate the transactions. It also returns the successfully matched cross-chain transactions to the submitting account and assigns a user to each participating blockchain to submit sub-signature smart contracts for coordinating sub-transactions on each chain. Once the cross-chain transaction instance and all sub-signature smart contracts have been submitted to the chain, they synchronize their states. The sub-signature smart contracts store the ID of the cross-chain transaction instance, while the cross-chain transaction instance stores the block ID and transaction ID of all sub-signature smart contracts and synchronizes the state of all sub-signature smart contracts to public. The purpose of this step is that if a sub-signature smart contract is lost due to a blockchain fork, the cross-chain transaction instance can quickly verify it using the saved information.

[0075] Once a sub-signature smart contract from one chain is submitted to the chain, users participating in cross-chain transactions within that chain submit their own specific sub-transactions based on the matching results. The state of the sub-signature smart contract serves as the triggering basis for the sub-transaction smart contract. This step is not mandatory for synchronization among the participating blockchains; instead, they are executed in parallel. After submission, coordination with the sub-signature smart contract is established. The sub-signature smart contract stores the block ID and transaction ID of all cross-chain sub-transactions within the current chain, while the cross-chain sub-transaction stores the block ID and transaction ID of the signature smart contract of its own chain.

[0076] The sub-signature smart contract verifies whether the cross-chain sub-transaction of the current cross-chain transaction on its own chain has been committed and whether the information is correct. If both are correct, it will synchronize the state to Ready with the cross-chain transaction instance on the relay chain. If an error is found in the transaction information, it will send an error message to the relay chain and interrupt the transaction, changing the state to Abort. If a user wants to abort the transaction, after initiating an interruption request to the sub-signature smart contract, the sub-signature smart contract will synchronize the state to Abort with the cross-chain transaction instance on the relay chain.

[0077] After the preparation phase, the coordination phase officially begins, which involves the specific transfer details in cross-chain transactions. The coordination phase process is as follows: Figure 3 As shown, the cross-chain transaction instance detects the status of all sub-signature smart contracts. When all sub-signature smart contracts are in the "Ready" state, a state transition instruction is sent to all sub-signature smart contracts, changing the state to "Commit". Cross-chain sub-transactions in each chain automatically trigger transactions upon detecting that a sub-signature smart contract's state has changed to "Commit". If any sub-signature smart contract's state changes to "Abort", a state transition instruction is sent to all sub-signature smart contracts, changing the state to "Abort". Cross-chain sub-transactions in each chain automatically abort transactions upon detecting that a sub-signature smart contract's state has changed to "Abort". If an incorrect transaction message is received from a sub-signature smart contract, the cross-chain transaction instance records the user with the incorrect message, lowers their reputation score as a penalty, aborts the transaction, and sends a state transition instruction to all sub-signature smart contracts, changing the state to "Abort". Cross-chain sub-transactions interrupt transactions upon detecting that a sub-signature smart contract's state is "Abort", returning the locked cryptocurrency to the corresponding user.

[0078] Figure 4This is a flowchart illustrating the cross-chain transaction request matching process in this embodiment of the invention. As shown, at the start of transaction matching, all submitted cross-chain transaction requests are sorted based on the priority of the submitting user (Prior) and the on-chain time (Time). The transaction request with the highest priority is selected as the target request O for this transaction matching. Next, it is determined whether the search depth is greater than 10. This step improves search efficiency; a large search depth indicates a lower probability of successful matching. If the search depth is less than 10, all transaction requests whose source blockchain COid is the target blockchain CDid of target request O are searched, and the search results are sorted. Transaction requests whose target blockchain CDid equals the source blockchain COid of the target request are selected, and their CDnum and COnum are matched. If the amount matches successfully, the transaction is successfully matched; otherwise, the matched amount is subtracted, and the remaining amount is matched. From the search results of the previous step, the highest-ranked unmatched request is selected, and the target blockchain CDid of target request O is updated to the target blockchain CDid of this request. Simultaneously, the CDnum of target request O is updated to the CDnum of this request, and the next round of matching begins.

[0079] Figure 5 This is a schematic diagram illustrating an example of cross-chain transaction request matching in an embodiment of the present invention. The format of the transaction request is a six-tuple [CDid, CDnum, COid, COnum, Prior, Time], as shown in the figure. CDid is the blockchain of the destination for the exchange request, CDnum is the amount of the exchange request, COid is the blockchain of the source for the exchange request, COnum is the amount of the exchange provided, Prior represents the user weight, and Time represents the time weight.

[0080] In this example, the target demand O aims to exchange 1 BTC for 20 ETH. First, using the CDid BTC of target demand O, we search all matching transaction demands for those with a COid of BTC. The search results in the diagram are P1 and P2. Both P1 and P2 have a time weight of 4, but P1 has a higher user weight, so P1 comes first. We iterate through the search results, looking for transaction demands with the same CDid as the COid of target demand O. P1 meets this requirement. Then, we compare the CDnum and COnum of P1 with those of target demand O, finding that P1 partially meets target demand O. The CDnum and COnum of the target demand are updated to 0.5 and 10, respectively. Continuing the search, we find no other transaction demands with the same CDid as the COid of target demand O. Therefore, we select the first unmatched transaction demand P2 from the search results. P2's COnum is exactly the same as the CDnum of target demand O. At this point, target demand O is matched. The CDid of the target demand is updated to P2's CDid ETC, and the CDnum is updated to P2's CDnum. A new target demand O1 is obtained. Then, a second round of matching is performed based on target demand O1, and the matching depth becomes 2. The search yields P3 and P4, where P3 and P4 have the same user weight, but P3 has a greater time weight than P4, so P3 comes first. The CDid and COid of P3 and P4 meet the requirements, and the sum of CDnum and COnum is greater than the target demand O2. At this point, the matching is complete, and the transaction demand P4 is updated on the relay chain to [ETH,2,ETC,20,7,6].

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cross-blockchain interaction method based on a relay chain, characterized in that: This includes matching transactions using a transaction matching algorithm, coordinating transactions via a relay chain, and verifying transactions via sub-signature smart contracts, specifically including the following steps: S1: Users Join the Relay Chain; Users must first become users of the relay chain before they can submit cross-chain requests. Each user on the relay chain has a reputation value R and a historical total return P. The reputation value R reflects the user's integrity in the relay chain. Users' reputation value R increases when they participate in cross-chain transactions and the consensus process according to the rules, and decreases otherwise. The reputation value R affects the user priority for submitting transaction requests and the probability of achieving consensus. The historical total return P represents the sum of the user's gains from participating in consensus in the relay chain, used to balance the returns among users and encourage user participation in consensus. The higher a user's historical total return P, the lower their probability of achieving consensus in the future. Users who achieve consensus gain the right to package transactions and the right to match transactions. Users on the relay chain who want to participate in consensus must first join a consensus group. The requirement for joining a consensus group is a reputation value R. i Greater than or equal to the average reputation value R of the current consensus group; S2: Relay chain users submit transaction requests, which are packaged and stored in blocks on the relay chain. Users on the relay chain match transactions using the transaction matching algorithm in the consensus algorithm. When a cross-chain transaction is successfully matched, a marker smart contract coordinating this cross-chain transaction, i.e., a cross-chain transaction instance, is generated on the relay chain. This contract generates a unique ID to identify this cross-chain transaction and sends the matching information to the successfully matched user. The transaction matching algorithm specifically includes: introducing user weight and time weight; the format of the transaction request is [CDid, CDnum, COid, COnum, Prior, Time], where CDid is the destination blockchain of the request, CDnum is the destination amount, COid is the source blockchain of the request, COnum is the amount provided for the exchange, Prior represents the user weight, and Time represents the time weight; all transactions to be matched together form the transaction request set P; depth is used to represent the search depth; the transaction matching algorithm includes the following steps: S211: Select the transaction demand with the highest combined ranking of user weight Prior and time weight Time from the set P of all transaction demands to be matched, and use it as the target demand O for this matching. The time weight Time is the number of waiting periods for the transaction demand. S212: Search for matching transactions based on the target blockchain CDid of the target requirement O, find all source blockchain COids that are the target blockchain CDids of the target requirement O, and sort the search results by user weight Prior and time weight Time. S213: In the search results of step S212, the transaction demand of the target blockchain CDid as the target demand O source blockchain COid is searched from left to right. For each demand that meets the requirements, its transfer in CDnum and transfer out COnum are accumulated. When it matches the amount of the target demand, the match is successful. After the match is successful, the cross-chain transaction will be scored according to the user weight Prior and time weight Time of all transaction demands in the successfully matched cross-chain transaction. S214: If no match is found in step S213, continue matching for the remaining unmatched amount in the target demand O; select the transaction demand with the highest weight from the list of transaction demands obtained in step S212 that was not selected in step S213, and use the destination blockchain CDid of this transaction demand as the new destination blockchain for the target demand, and also change CDnum to be the same as this demand; the source blockchain COid of the target demand remains unchanged, but the amount COnum becomes the remaining unmatched amount; return to step S212, increment the search depth by one, and search again; set the maximum search depth, and when the search depth is greater than the maximum search depth, the matching in this round fails and returns; The consensus phase specifically includes the following steps: S221: At the start of consensus, first calculate the average return P of the consensus group, denoted as: Where n is the total number of users in the consensus group, P i The total historical revenue of user i; S222: Based on whether the total historical return is greater than the average return P, the consensus group users are divided into two groups, G1 and G2: G1={x∈G|f x ≥P} G2={y∈G|0<f y <P} Where G is the set of all consensus group users; S223: Calculate the number of users n1 and n2 in G1 and G2 respectively, and the proportion of user i's reputation value to the total reputation value of all users in the consensus group, to obtain the probability that user i is selected as a consensus representative: Among them, R i P is the reputation value of user i. i Let n be the total historical earnings of user i, and n be the total number of users in the consensus group. S224: After being selected as a consensus user, a user obtains the right to package and match transactions in the next cycle; the consensus user packages the transaction requests submitted by users in the current cycle and calls the matching algorithm to match transactions, thereby obtaining commissions and reputation value enhancement rewards for the corresponding transaction requests; after a transaction is successfully matched, the matching information is distributed to the corresponding user. S3: After a successful match, the preparation phase begins. The relay chain and the specific blockchains participating in the cross-chain process prepare for the actual cross-chain action. This includes the following steps: S31: After all the sub-signature smart contracts in the participating chains have been submitted, the users participating in cross-chain transactions in each chain submit the relevant specific sub-transactions according to the matching results, and use the state of the sub-signature smart contract as the triggering basis for the sub-transaction smart contract; after submission, in coordination with the sub-signature smart contract, the sub-signature smart contract will save the block ID and transaction ID of all cross-chain sub-transactions in the current chain, while the cross-chain sub-transactions will save the block ID and transaction ID of the signature smart contract of the chain in which they are located; S32: The sub-signal smart contract will verify whether the cross-chain sub-transaction of the current cross-chain transaction on the chain it is on has been submitted and the information is correct. If both are correct, it will synchronize the status to Ready with the cross-chain transaction instance on the relay chain. If a user wants to abort the transaction, after initiating an interruption request to the sub-signal smart contract, the sub-signal smart contract will synchronize the status to Abort with the cross-chain transaction instance on the relay chain. S33: Cross-chain transaction instances detect the status of all sub-signal smart contracts. When the status of all sub-signal smart contracts is Ready, a state transition instruction is sent to all sub-signal smart contracts to change the status to Commit. Cross-chain sub-transactions in each chain automatically trigger transactions after detecting that the status of a sub-signal smart contract has changed to Commit. If the status of any sub-signal smart contract changes to Abort, a state transition instruction is sent to all sub-signal smart contracts to change the status to Abort. Cross-chain sub-transactions in each chain automatically abort transactions after detecting that the status of a sub-signal smart contract has changed to Abort. S4: Once all preparations are complete, the coordination phase begins; the coordination phase is the specific execution process of cross-chain transactions; it includes the following steps: S41: Cross-chain transaction instances periodically check the status of all the sub-signal smart contracts they record. When the status of all sub-signal smart contracts is Ready, a state transition instruction is sent to all sub-signal smart contracts to change the status to Commit. After detecting that the status of the sub-signal smart contract has changed to Commit, the cross-chain sub-transactions in each chain automatically trigger the transaction to transfer the virtual currency locked in the smart contract to the corresponding account. S42: If the state of a sub-signal smart contract changes to Abort, a state transition instruction is sent to all sub-signal smart contracts to change their state to Abort. Cross-chain sub-transactions in each chain automatically abort the transaction upon detecting that the state of a sub-signal smart contract has changed to Abort. If an incorrect transaction information is received from a sub-signal smart contract, the cross-chain transaction instance will record the user with the incorrect transaction information, lower their reputation value as a penalty, abort the transaction, and send a state transition instruction to all sub-signal smart contracts to change their state to Abort. Cross-chain sub-transactions interrupt the transaction upon detecting that the state of a sub-signal smart contract is Abort and return the locked virtual currency to the corresponding user.

Images