CN114493879A - A cross-blockchain interaction method based on relay chain - Google Patents

Abstract

The invention relates to a block chain crossing interaction method based on a relay chain, which belongs to the field of communication among block chains, comprises the steps of utilizing a transaction matching algorithm to match transactions, coordinating transactions by the relay chain, and verifying transactions by intelligent sub-mark contracts, and specifically comprises the following steps: s1: a user joins a relay chain; s2: a relay chain user submits a transaction requirement, the transaction requirement is packaged and stored in a block on a relay chain, the user performs matching through a transaction matching algorithm, when cross-chain transaction matching is successful, a mark intelligent contract which coordinates the cross-chain transaction at this time is generated on the relay chain, the contract generates a unique ID for marking the cross-chain transaction at this time, and matching information is sent to the user who succeeds in the matching at this time; s3: after matching is successful, entering a preparation stage, and preparing a relay chain and a block chain which specifically participates in chain crossing for the next actual chain crossing behavior; s4: after all preparation works are finished, entering a coordination stage; the coordination phase is a specific execution process of the cross-chain transaction.

Description

A Cross-Blockchain Interaction Method Based on Relay Chain

technical field

The invention belongs to the field of inter-blockchain communication, and relates to a cross-blockchain interaction method based on a relay chain.

Background technique

Blockchain technology has the advantages of decentralization, de-trust, non-tampering and traceability. It is a subversive change and challenge to traditional social organization and operation methods. "The supporting technology of the '' has received more and more attention from the investment community, academia, industry and government departments. With the rapid development of blockchain technology, various blockchain applications are emerging in an endless stream, but the current blockchain projects are heterogeneous projects developed by different teams based on different scenario requirements and design concepts and using different technical architectures. blockchain. Due to the technical characteristics such as the isolation of the blockchain itself, the isolation between the block information stored in different blockchains inevitably causes the "value island" effect of the blockchain. Therefore, how to realize the interconnection and value transfer between blockchains has become the research focus of current blockchain technology.

Cross-chain technology, as the name implies, is to use certain technologies to allow value to cross the barriers between chains, so that the value originally stored on a specific blockchain is converted into the value on another chain, thereby realizing the circulation of value. There are currently four main cross-chain technologies: notary mechanism, side chain/relay, hash locking and distributed private key control. Among them, although the notary technology is simple to implement, the introduction of trusted third parties such as notaries and exchanges is obviously contrary to the decentralization idea of the blockchain, and will also bring about performance bottlenecks. The side chain/relay technology realizes the cross-chain of heterogeneous blockchains, and the centralization problem is also weakened through the relay chain, but it needs to store a large number of block header information of heterogeneous blockchains for verification, and in the face of Poor performance for complex cross-chain transactions. The hash lock scheme is implemented by hash time lock. Although the implementation is relatively simple and the centralization problem is weakened, it only realizes cross-chain asset exchange and cannot realize cross-chain asset transfer. Although the distributed private key control mechanism ensures that the ownership of the assets by the users with the private key remains unchanged, it is more difficult to implement.

SUMMARY OF THE INVENTION

In view of this, the purpose of the present invention is that the existing relay chain cross-chain scheme needs to save a large number of different types of blockchain block header information for verification, and the scalability is poor, and the performance is more affected by the increase in the complexity of cross-chain transactions. It provides a highly scalable relay chain cross-chain method that can still have high efficiency for complex cross-chain transactions, and reduces the amount of information that the relay chain needs to store, improving the relay chain’s ability to coordinate cross-chain transactions. efficiency in.

To achieve the above object, the present invention provides the following technical solutions:

A relay chain-based cross-blockchain interaction method includes matching transactions using a transaction matching algorithm, coordinating transactions in relay chains, and verifying transactions by sub-sign smart contracts, which specifically includes the following steps:

S1: The user joins the relay chain;

S2: Relay chain users submit transaction requirements, and the transaction requirements are packaged and stored in blocks on the relay chain. Users on the relay chain are matched by the transaction matching algorithm in the consensus algorithm. When a cross-chain transaction is successfully matched, The relay chain will generate a sign smart contract for coordinating this cross-chain transaction, that is, an instance of the cross-chain transaction. The contract generates a unique ID to identify this cross-chain, and sends the matching information to the users who have successfully matched this time;

S3: After the matching is successful, it will enter the preparation stage, and the relay chain and the blockchain that specifically participates in the cross-chain will prepare for the actual cross-chain behavior;

S4: When all the preparations are completed, enter the coordination stage; the coordination stage is the specific execution process of the cross-chain transaction.

Further, the step S1 specifically includes: in step S1, the user first becomes a user of the relay chain before submitting cross-chain requirements, and each user on the relay chain has a reputation value R and a historical total income P, where the reputation value R reflects the integrity of the user's behavior in the relay chain. The user participates in the cross-chain transaction and consensus process according to the rules, and the reputation value R increases, otherwise it decreases; the reputation value R is used to influence the user's priority in submitting transaction requirements and the user's consensus. The probability of ; the historical total revenue P represents the sum of the benefits obtained by users participating in the consensus in the relay chain, which is used to balance the benefits among users and stimulate the enthusiasm of users to participate in the consensus. The higher the historical total revenue P obtained by users, the more The probability of obtaining a consensus in the future is lower; the users who reach a consensus not only get the packaging rights, but also the transaction matching rights; if the users of the relay chain want to participate in the consensus, they must first join the consensus group, and the requirement for joining the consensus group is the reputation value R _i is greater than or equal to the average reputation value R of the current consensus group.

Further, the transaction matching algorithm described in step S2 specifically includes: introducing user weights and time weights, and the format of transaction requirements is [CDid, CDnum, COid, COnum, Prior, Time], wherein CDid is the blockchain for the exchange purpose of the demand , CDnum is the exchange purpose amount, COid is the demanded exchange source blockchain, COnum is the exchange amount provided, Prior indicates the user weight, Time indicates the time weight; all the transactions to be matched together form the transaction demand set P; use depth to indicate the search depth .

Further, the transaction matching algorithm described in step S2 includes the following steps:

S211: Select the transaction requirement with the highest comprehensive ranking of the user weight Prior and the time weight Time from all the transaction requirement sets P to be matched, as the target requirement O of this matching, and the time weight Tme is the transaction requirement waiting period number;

S212: Search the transactions to be matched according to the CDid of the destination blockchain of the target demand O, find all the source blockchain COids as the demand of the CDid of the destination blockchain of the target demand O, and comprehensively sort the search results according to the user weight Prior and the time weight Time ;

S213: In the search result of step S212, look for the target blockchain CDid from left to right as the target demand O source blockchain COid transaction demand, each time a demand that meets the requirements is found, accumulate its transfer CDnum and transfer amount COnum, 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 the time weight Time of all transaction requirements in the successfully matched cross-chain transaction;

S214: If there is no successful matching in step S213, continue matching for the remaining unmatched amount in the target demand O; select the transaction demand with the largest weight and not selected in step S213 from the transaction demand list searched in step S212, and use this The destination blockchain CDid of the transaction demand is used as the new destination blockchain of the target demand, and CDnum also becomes the same as the demand; the source blockchain COid of the target demand remains unchanged, but the amount COnum becomes the remaining unmatched amount; go back to Step S212, the search depth depth is increased by one, and the search is performed again; the maximum search depth is set, and when the search depth depth is greater than the maximum search depth, this round of matching fails and returns.

Further, the consensus stage of step S1 specifically includes the following steps:

S221: At the beginning of the consensus, first calculate the average return P of the consensus group, which is recorded as:

Among them, n is the total number of users in the consensus group, and P _i is the historical total revenue of user i;

S222: According to whether the historical total return is greater than the average return P, divide the consensus group users into two groups, G ₁ and G ₂ :

G ₁ ={x∈G|f _x ≥P}

G ₂ ={y∈G|0<f _y <P}

Among them, G is the set composed of all consensus group users;

S223: Count the number of users n ₁ and n ₂ of G ₁ and G ₂ and the ratio of the reputation value of user i to the total reputation value of all users in the entire consensus group, and obtain the probability that user i is selected as the consensus representative:

Among them, Ri is the reputation value of user _i , Pi is the historical total revenue of user _i , and n is the total number of users in the consensus group;

S224: After the user is selected as the consensus user, the user obtains the packaging rights and transaction matching rights for the next cycle; the consensus user packages the transaction requirements submitted by the user in the current cycle, and invokes the matching algorithm to perform transaction matching, from which the commission and reputation of the corresponding transaction requirements are obtained. Value promotion reward; after the transaction is successfully matched, the matching information will be distributed to the corresponding users.

Further, step S3 specifically includes the following steps:

S31: After all the sub-flag smart contracts in the participating chains have been submitted, the users participating in the cross-chain in each chain submit the relevant specific sub-transactions according to the matching results, and use the status of the sub-flag smart contracts as the sub-transaction smart contracts. Trigger basis; after the submission is completed, coordinate with the sub-flag smart contract, the sub-flag smart contract will save the block id and transaction id of all cross-chain sub-transactions in the current chain, and the cross-chain sub-transaction will save the block id and transaction id;

S32: The sub-flag smart contract will verify whether the cross-chain sub-transaction of the current cross-chain transaction on the chain where it is located has been submitted and the information is correct. If both are correct, the synchronization status to the cross-chain transaction instance on the relay chain is Ready; if there is a user If you want to abort the transaction, after sending an interrupt request to the sub-flag smart contract, the sub-flag smart contract will synchronize the status of Abort to the cross-chain transaction instance on the relay chain;

S33: The cross-chain transaction instance detects the status of all sub-flag smart contracts. When the status of all sub-flag smart contracts is Ready, a state transfer instruction is sent to all sub-flag smart contracts, and the state is converted to Commit. After the transaction detects that the status of the sub-flag smart contract changes to Commit, the transaction is automatically triggered; if the status of any sub-flag smart contract becomes Abort, it sends a state transfer instruction to all sub-flag smart contracts to change the status to Abort, and each chain The cross-chain sub-transaction in the token automatically aborts the transaction after detecting that the status of the sub-flag smart contract has changed to Abort.

Further, step S4 specifically includes the following steps:

S41: The cross-chain transaction instance regularly detects the status of all sub-flag smart contracts recorded by it. When the status of all sub-flag smart contracts is Ready, a state transfer instruction is sent to all sub-flag smart contracts, and the status is changed to Commit. The cross-chain sub-transaction in the chain will automatically trigger the transaction after detecting that the status of the sub-flag smart contract has changed to Commit, and transfer the virtual currency locked in the smart contract to the corresponding account;

S42: If the status of any sub-flag smart contracts changes to Abort, send a state transfer instruction to all sub-flag smart contracts to change the state to Abort, and the cross-chain sub-transactions in each chain detect the status of the sub-flag smart contracts to Abort After that, the transaction is automatically terminated; if the wrong transaction information sent by the sub-flag smart contract is received, the cross-chain transaction instance will record the user with the wrong transaction information, reduce its reputation value as a penalty, and suspend the transaction and send it to all sub-flag smart contracts. The state transfer instruction changes the state to Abort; after the cross-chain sub-transaction detects that the state of the sub-flag smart contract is Abort, it interrupts the transaction and returns the locked virtual currency to the corresponding user.

The beneficial effects of the present invention are:

(1) The present invention designs a transaction matching algorithm for the transaction matching of cross-chain transactions, and designs a new consensus algorithm according to this algorithm, and finally designs a relay chain scheme based on this consensus algorithm. The relay chain cross-chain method of matching, coordinating and realizing cross-chain transactions is realized, and at the same time, the responsibilities of the relay chain are distributed to each participating chain to avoid excessive concentration.

(2) The present invention reduces the data that needs to be stored in the relay chain while ensuring the reliability of the transaction through the three-layer setting of cross-chain transaction instances, sub-sign smart contracts and sub-cross-chain transactions, and avoids Excessive interchain communication. Through in-chain verification, inter-chain synchronization status further improves cross-chain efficiency.

Other advantages, objects, and features of the present invention will be set forth in the description that follows, and will be apparent to those skilled in the art based on a study of the following, to the extent that is taught in the practice of the present invention. The objectives and other advantages of the present invention may be realized and attained by the following description.

Description of drawings

In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention will be preferably described in detail below in conjunction with the accompanying drawings, wherein:

1 is a state transition diagram of a neutron token smart contract according to an embodiment of the present invention;

FIG. 2 is a flowchart of a cross-chain method for relay chains based on transaction matching consensus in an embodiment of the present invention;

3 is a sequence diagram of a cross-chain transaction coordination phase in an embodiment of the present invention;

FIG. 4 is a flowchart of cross-chain transaction demand matching in an embodiment of the present invention;

FIG. 5 is a schematic diagram of an example of cross-chain transaction requirement matching in an embodiment of the present invention.

Detailed ways

The embodiments of the present invention are described below through specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents 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 also 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 drawings provided in the following embodiments are only used to illustrate the basic idea of the present invention in a schematic manner, and the following embodiments and features in the embodiments can be combined with each other without conflict.

Among them, the accompanying drawings are only used for exemplary description, and represent only schematic diagrams, not physical drawings, and should not be construed as limitations of the present invention; in order to better illustrate the embodiments of the present invention, some parts of the accompanying drawings will be omitted, The enlargement or reduction does not represent the size of the actual product; it is understandable to those skilled in the art that some well-known structures and their descriptions in the accompanying drawings may be omitted.

The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar components; in the description of the present invention, it should be understood that if there are terms "upper", "lower", "left" and "right" , "front", "rear" and other indicated orientations or positional relationships are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the indicated device or element must be It has a specific orientation, is constructed and operated in a specific orientation, so the terms describing the positional relationship in the accompanying drawings are only used for exemplary illustration, and should not be construed as a limitation of the present invention. situation to understand the specific meaning of the above terms.

The invention provides a priority cross-chain transaction matching algorithm. This algorithm is different from the algorithm in traditional matching theory. Cross-chain transaction matching is different from barter. In addition to type matching, it is also necessary to meet the amount matching, and the exchange rates of the transactions to be matched are different, and there are also one-to-many and many-to-many pairs. many situations. The algorithm performs differential matching on cross-chain transactions according to the priority of users who submit transaction requirements and the queuing time of transaction requirements. The storage format of each transaction is [CDid, CDnum, COid, COnum, Prior, Time], where CDid is The required exchange destination blockchain, CDnum is the amount of the exchange purpose, COid is the demanded exchange source blockchain, COnum is the amount provided for the exchange, the last Prior represents the user weight, and Time represents the time weight. All the transactions to be matched together form the transaction demand set P. At the same time, in order to avoid the search depth being too large, use depth to represent the search depth. The matching algorithm includes the following steps:

S11: Select the transaction requirement with the highest comprehensive ranking of the user weight Prior and the time weight Time (the number of transaction requirement waiting cycles) from all the transaction requirement sets P to be matched, as the target requirement O for this matching;

S12: Search for the transactions to be matched according to the target blockchain CDid of the target demand O, find all the source blockchain COids that are the target blockchain CDid requirements of the target demand O, and comprehensively sort the search results according to the user weight Prior and the time weight Time ;

S13: In the search results of S12, look for the target blockchain CDid from left to right as the target demand O source blockchain COid transaction demand, each time you find a demand that meets the requirements, accumulate its transfer CDnum and transfer amount COnum , 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 the time weight Time of all transaction requirements in the successfully matched cross-chain transaction;

S14: If the matching is not successful in S13, continue matching for the remaining unmatched amount in the target demand O. Select the transaction requirement with the largest weight and not selected by S13 from the transaction requirement list searched in S12, and use the target blockchain CDid of the transaction requirement as the new target blockchain of the target requirement, and CDnum also becomes the same as the requirement. . The source blockchain COid of the target demand remains unchanged, but the amount COnum becomes the remaining unmatched amount. Back to S12, the search depth depth is increased by one, and the search is performed again. In order to avoid the efficiency drop caused by too large search depth, the maximum search depth is set to 10. When the search depth is greater than 10, this round of matching fails and returns.

The present invention also provides a relay chain scheme for coordinating cross-chain transactions and for users to submit and match transaction requirements. To submit cross-chain requirements, a user must first become a user of the relay chain. Each user on the relay chain has a reputation value R and a historical total revenue P, where the reputation value R reflects the integrity of the user's behavior in the relay chain. Users participate in cross-chain transactions and consensus processes according to the rules, and the reputation value R will increase, otherwise it will decrease. The reputation value R will affect the user's priority for submitting transaction requirements and the probability that users obtain consensus. The historical total revenue P represents the sum of the benefits obtained by the users participating in the consensus in the relay chain. The purpose is to balance the benefits among users and stimulate the enthusiasm of users to participate in the consensus. The probability of obtaining consensus will be lower. The relay chain scheme integrates the transaction matching algorithm into the consensus, and the users who reach the consensus will not only obtain the packaging rights, but also the transaction matching rights. If the users of the relay chain want to participate in the consensus, they must first join the consensus group. The requirement for joining the consensus group is that the reputation value R _i must be greater than or equal to the average reputation value R of the current consensus group. The specific consensus process is as follows:

S21: At the beginning of the consensus, first calculate the average return P of the consensus group, which is recorded as:

Among them, n is the total number of users in the consensus group, and P _i is the historical total revenue of user i.

S22: According to whether the historical total revenue is greater than the average revenue P, the consensus group users are divided into two groups, G ₁ and G ₂ :

G ₁ ={x∈G|f _x ≥P}

G ₂ ={y∈G|0<f _y <P}

Among them, G is the set composed of all consensus group users.

S23: Count the number of users n ₁ and n ₂ of G ₁ and G ₂ and the ratio of the reputation value of user i to the total reputation value of all users in the entire consensus group, so that the probability of user i being selected as the consensus representative can be obtained:

Among them, Ri is the reputation value of user _i , Pi is the historical total revenue of user _i , and n is the total number of users in the consensus group.

S24: After the user is selected as the consensus user, he will obtain the packaging rights and transaction matching rights for the next cycle. Consensus users package the transaction requirements submitted by users in the current cycle, and call the matching algorithm for transaction matching, from which they can obtain commissions and credit value promotion rewards for the corresponding transaction requirements. Transaction matching is successful

Finally, the present invention provides a cross-chain method based on transaction matching consensus relay chain. The scheme uses the relay chain of transaction matching consensus as the center for coordinating cross-chain transactions. The problem of centralization is avoided by means of the relay chain. At the same time, the multi-level verification method avoids the need for existing relay chain schemes. A large amount of heterogeneous blockchain header information is stored for verification, and the message exchange is too centralized. Users on the relay chain not only have accounts on the relay chain, but also need to bind specific cross-chain blockchain accounts, such as Ethereum, etc., in this way to achieve the initial connection between the chains. The information that the relay chain needs to store includes the transaction demand information submitted by the user, the successfully matched cross-chain transaction information and the sub-flag smart contract information. The three-layer structure is: a cross-chain transaction instance located on the relay chain, which coordinates cross-chain transactions as a whole, interacts with the sub-flag smart contract, and stores the block information of the sub-flag smart contract to verify the transaction; it is located in each specific area. The sub-signature smart contract on the blockchain is responsible for coordinating and verifying cross-chain sub-transactions in the current chain; the cross-chain sub-transactions located on each specific blockchain are responsible for specific transfer operations and perform operations according to the status of the sub-signature smart contract . The sub-flag smart contract is a bridge connecting cross-chain transaction instances and cross-chain sub-transactions, and is also the key to ensuring cross-chain transaction transactionality. It coordinates cross-chain transactions by switching between four states (Public, Ready, Abort, Commit). Transactions are guaranteed to be atomic. Finally, a cross-chain method integrating transaction submission, matching and coordination is formed, and scalability and high efficiency are guaranteed. Figure 1 is a state transition diagram of the sub-flag smart contract according to the embodiment of the present invention. As shown in Figure 1, the sub-flag smart contract has a total of four states, which are public respectively, indicating that the sub-flag smart contract has been on the chain. Abort, means that the cross-chain transaction has been aborted; Ready, means that the relevant transactions in the chain where the current sub-flag smart contract is located has been completed, waiting for the status change of other blockchains participating in the cross-chain; Commit, means that all sub-flag smart contracts are completed, into the formal implementation phase. There are four transition relationships between these states, as follows:

1.Public to Ready. The sub-flag smart contract receives the state transition request from the user, and checks that all users participating in the cross-chain in the current blockchain have correctly submitted the corresponding cross-chain transaction, then converts from Public to Ready, and provides the state to the relay layer;

2.Public to Abort. In the current chain, there is a user request to abort or an abort message sent by the relay layer is received. After the child smart contract is received, the status changes from Public to Abort;

3.Ready to Abort. The smart contract marked as Ready receives the abort message from the relay layer, which means that a user has aborted the cross-chain transaction, and the status changes from Ready to Abort;

4.Ready to Commit. The smart contract in the Ready flag receives the Commit message from the relay layer, which means that all cross-chain sub-transactions have been submitted and uploaded to the chain, and the status has changed from Ready to Commit;

FIG. 2 is a flowchart of a relay chain cross-chain method based on transaction matching consensus in an embodiment of the present invention. As shown in the figure, when a user wants to perform a cross-chain operation through the method provided by the present invention, he must have an account on the relay chain, and the account is bound to the account on other relevant chains that the user wants to perform the cross-chain operation. , such as blockchain, Ethereum, etc. The specific binding method provides the user with the public key of the corresponding account. The relay chain uses the public key to encrypt a random string and returns it to the user. If the user can decrypt the string, it will be bound. success, otherwise fail. In this way, the association between different chains is initially realized, and subsequent operations related to cross-chain transactions are based on this account.

When entering the transaction submission matching stage, this stage is mainly related to the consensus of the relay chain, involving the matching of transaction demand information and matching result information on the chain and transactions. Users submit cross-chain transaction requirements, and the submitted content includes source chain, source address, destination chain, destination address, transfer amount, and transfer amount. After receiving the transaction request submitted by the user, the relay chain will package the transaction request in the next cycle and submit it to the chain. The specific user responsible for packaging will be selected in the consensus of the current cycle. The matching of cross-chain transactions and the packaging of transaction requirements need to be completed by the consensus algorithm of the relay chain. The relay chain selects a consensus representative through the consensus algorithm, and the consensus representative obtains the packaging rights and transaction matching rights. Consensus means matching the transaction requirements through the transaction matching algorithm, packaging the matching results on the chain, and then distributing them to the submitted users who have successfully matched the transaction requirements, and then officially enters the cross-chain stage. Users on the relay chain can earn commissions and increase their reputation by participating in consensus. The users of the consensus group on the relay chain participate in the consensus. When successfully elected as the consensus representative, the user will obtain the packaging rights and transaction matching rights. Transactions are matched through the transaction matching algorithm. When the transaction matching is completed, the consensus representative will generate a sign smart contract for coordinating cross-chain transactions on the relay chain for each matching cross-chain transaction, that is, a cross-chain transaction instance. Each contract A unique ID will be generated to identify this cross-chain, and the matching information will be sent to the corresponding users who have successfully matched. At the same time, the transaction requirements submitted by users in the current cycle of the chain will also be packaged.

After a consensus is reached and the transaction is successfully matched, the preparation stage is entered, and the preparation stage makes preliminary preparations for the coordination stage. The relay chain will generate a cross-chain transaction instance on the relay chain for all successfully matched cross-chain transactions to coordinate the cross-chain transaction, and will return the successfully matched cross-chain transaction to the submission account of the transaction requirements, and provide Each blockchain participating in this cross-chain designates a user to submit the sub-signature smart contract within the chain to coordinate the sub-transactions of each chain. When the cross-chain transaction instance and each sub-flag smart contract have been submitted to the chain, state synchronization will be performed between them. The sub-flag smart contract will save the ID of the cross-chain transaction instance, and the cross-chain transaction instance will save all sub-flag smart contracts. The block id and transaction id, and synchronize the status of all sub-flag smart contracts to public. The purpose of this step is that when the sub-flag smart contract is lost due to the blockchain fork, the cross-chain transaction instance can be quickly verified by the saved information.

When the sub-flag smart contract in the chain is submitted to the chain, the users participating in the cross-chain in the chain submit the relevant specific sub-transactions according to the matching results, and use the status of the sub-flag smart contract as the trigger basis for the sub-transaction smart contract. In this step, each blockchain participating in the cross-chain is not forced to be synchronized, but executed in parallel. After the submission is completed, in coordination with the sub-flag smart contract, the sub-flag smart contract will save the block id and transaction id of all cross-chain sub-transactions in the current chain, and the cross-chain sub-transaction will save the block id and transaction id of the flag smart contract of the chain where it is located.

The sub-flag smart contract will verify whether the cross-chain sub-transaction of the current cross-chain transaction on the chain where it is located has been submitted and the information is correct. If all are correct, the synchronization status to the cross-chain transaction instance on the relay chain will be Ready; if transaction information is found If an error occurs, an error message will be sent to the relay chain and the transaction will be interrupted, and the status will change to Abort; if a user wants to abort the transaction, after an interruption request is sent to the sub-flag smart contract, the sub-flag smart contract will send an interrupt request to the cross-border on the relay chain. The synchronization state of the chain transaction instance is Abort.

After the preparation stage, it officially enters the coordination stage, which involves specific transfer matters in cross-chain transactions. The process of the coordination phase is shown in Figure 3. The cross-chain transaction instance detects the status of all sub-flag smart contracts. When the status of all sub-flag smart contracts is Ready, a state transfer instruction is sent to all sub-flag smart contracts to change the state to Commit, the cross-chain sub-transaction in each chain will automatically trigger the transaction after detecting that the status of the sub-flag smart contract has changed to Commit; if the status of any sub-flag smart contract becomes Abort, it will send a state transfer instruction to all sub-flag smart contracts , change the status to Abort, and the cross-chain sub-transactions in each chain will automatically abort the transaction after detecting that the status of the sub-flag smart contract has changed to Abort. If the wrong transaction information sent by the sub-flag smart contract is received, the cross-chain transaction instance will record the user with wrong transaction information, reduce its reputation value as a penalty, and abort the transaction, send state transfer instructions to all sub-flag smart contracts, and transfer the state Convert to Abort. After the cross-chain sub-transaction detects that the status of the sub-flag smart contract is Abort, it will interrupt the transaction and return the locked virtual currency to the corresponding user.

FIG. 4 is a flowchart of cross-chain transaction requirement matching in an embodiment of the present invention. As shown in the figure, at the beginning of transaction matching, all the cross-chain transaction requirements that have been submitted to the chain will be sorted. The sorting is based on the priority of the user submitting the requirements and the transaction requirements in the chain time Time, and the priority is selected from the sorting results. The largest transaction demand at the level is the target demand O matched by this transaction. Then judge whether the search depth depth is greater than 10. This step is to improve the search efficiency. If the search depth is too large, the possibility of successful matching is small. If the search depth is less than 10, find all the transaction requirements of the target blockchain CDid whose source blockchain COid is the target demand O, sort the search results, and select the target blockchain CDid equal to the target demand source COid blockchain If the amount matching is successful, the transaction matching is successful; otherwise, the matching amount is subtracted from the remaining amount and the remaining amount is continued. From the search results of the previous step, select the highest-ranked and unmatched requirements, update the target blockchain CDid of the target requirement O to the target blockchain CDid of this requirement, and update the CDnum of the target requirement O to this The required CDnum starts the next round of matching.

FIG. 5 is a schematic diagram of an example of cross-chain transaction requirement matching in an embodiment of the present invention. The format of the transaction requirement is shown in the figure as a six-tuple [CDid, CDnum, COid, COnum, Prior, Time], where CDid is the exchange destination blockchain of the demand, CDnum is the exchange destination amount, and COid is the exchange source area of the demand Blockchain, COnum provides the amount for exchange, the last Prior represents the user weight, and Time represents the time weight.

In the example, the target demand is O, and the purpose is to exchange 1BTC for 20ETH. First, the CDid BTC of the target demand O is used to search all the transaction requirements to be matched that meet the transaction requirements whose COid is BTC. The search results in the figure are P1 and P2. The time weights of P1 and P2 are both 4, but the user weight of P1 is greater than that of P2. , so P1 comes first. Traverse the search results, find the transaction requirement with the same CDid and the COid of the target requirement O, find that P1 meets the requirements, then compare the CDnum and COnum of P1 and the target requirement O, and find that P1 partially meets the target requirement O, and the CDnum and COnum of the target requirement Updated for 0.5 and 10. Continue the search and find that there is no transaction requirement that meets the same transaction requirement as the COid of the target requirement O, so the first unmatched transaction requirement P2 is selected from the search results. The COnum of P2 is exactly the same as the CDnum of the target requirement O. At this time The target requirement O is matched, and the CDid of the updated target requirement is the CDid ETC of P2, and the CDnum is the CDnum of P2. A new target requirement O1 is obtained, and then another round of matching is performed according to the target requirement O1, the matching depth becomes 2, and the search results in P3 and P4, where the user weights of P3 and P4 are the same, but the time weight of P3 is greater than that of 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 requirement O2. At this time, the matching is completed, and the transaction requirement P4 is updated on the relay chain to be [ETH, 2, ETC, 20, 7, 6].

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be Modifications or equivalent replacements, without departing from the spirit and scope of the technical solution, should all be included in the scope of the claims of the present invention.

Claims (7)

1. A block chain crossing interaction method based on a relay chain is characterized in that: the method comprises the following steps of matching transactions by using a transaction matching algorithm, coordinating transactions by using a relay chain, and verifying transactions by using intelligent contracts with sub-signs, and specifically comprises the following steps:

s1: a user joins a relay chain;

s2: the method comprises the steps that a relay chain user submits a transaction requirement, the transaction requirement is packaged and stored in a block on a relay chain, the user on the relay chain is matched through a transaction matching algorithm in a consensus algorithm, when cross-chain transaction matching is successful, a marked intelligent contract coordinating the cross-chain transaction at this time, namely a cross-chain transaction example, is generated on the relay chain, the contract generates a unique ID for identifying the cross-chain transaction at this time, and matching information is sent to the user successfully matched at this time;

s3: after matching is successful, entering a preparation stage, and preparing a relay chain and a block chain which specifically participates in chain crossing for the next actual chain crossing behavior;

s4: after all preparation works are finished, entering a coordination stage; the coordination phase is a specific execution process of the cross-chain transaction.

2. The relay chain-based inter-block chain interaction method according to claim 1, wherein: the step S1 specifically includes: in step S1, the user becomes the user of the relay chain first, and can submit the cross-chain requirement, and the relayEach user on the chain has a credit value R and a historical total profit P, wherein the credit value R reflects the integrity degree of the user in the relay chain behavior, the user participates in the cross-chain transaction and consensus process according to rules, the credit value R is increased, and otherwise, the credit value R is reduced; the reputation value R is used for influencing the user priority of the user submitting the transaction requirement and the probability of obtaining consensus by the user; the historical total profit P represents the sum of profits obtained by the users participating in the consensus in the relay chain, and is used for balancing the profits among the users and stimulating the enthusiasm of the users participating in the consensus, and the higher the historical total profit P is obtained by the users, the lower the probability of the consensus obtained by the users in the future is; the users who reach the consensus obtain the transaction matching right besides the packaging right; the users of the relay chain want to participate in the consensus, and need to join the consensus group first, and the requirement of joining the consensus group is the credit value R_iAnd the average reputation value R is larger than or equal to the current consensus group.

3. The relay chain-based inter-block chain interaction method according to claim 1, wherein: the transaction matching algorithm in step S2 specifically includes: introducing user weight and Time weight, wherein the format of transaction requirements is [ CDid, CDnum, COid, COnum, Prior and Time ], wherein CDid is a required conversion destination block chain, CDnum is conversion destination amount, COid is a required conversion source block chain, COnum is conversion supply amount, Prior represents user weight, and Time represents Time weight; all transactions to be matched form a transaction requirement set P together; depth is used to represent the search depth.

4. The relay chain-based inter-block chain interaction method according to claim 3, wherein: the transaction matching algorithm of step S2 includes the following steps:

s211: selecting the transaction requirement with the highest comprehensive ranking of user weight Prior and Time weight Time from all the transaction requirement sets P to be matched as a target requirement O for the matching, wherein the Time weight Tme is the number of transaction requirement waiting cycles;

s212: searching the transaction to be matched according to the target block chain CDid of the target requirement O, finding out the requirement that all the source block chains COid are the target block chain CDid of the target requirement O, and comprehensively sequencing the search results according to the user weight Prior and the Time weight Time;

s213: in the search result of step S212, searching from left to right for a transaction requirement in which the target block chain CDid is the target requirement O source block chain COid, accumulating the transferred-in CDnum and the transferred-out amount of money cunm when finding a requirement meeting the requirement, matching successfully when matching with the amount of money of the target requirement, and scoring the cross-chain transaction according to the user weight Prior and the Time weight Time of all transaction requirements in the cross-chain transaction successfully matched;

s214: if the matching is not successful in the step S213, continuing to match the remaining unmatched money in the target requirement O; selecting the transaction requirement which has the largest weight and is not selected in the step S213 from the transaction requirement list searched in the step S212, and taking the destination block chain CDid of the transaction requirement as a new destination block chain of the target requirement, wherein CDnum is also the same as the requirement; the source block chain COid of the target demand is unchanged, but the amount COnum is changed into the remaining unmatched amount; returning to the step S212, adding one to the depth of search, and searching again; and setting the maximum search depth, and when the depth of the search is greater than the maximum search depth, failing the matching in the round and returning.

5. The relay chain-based inter-block chain interaction method according to claim 4, wherein: the consensus step of step S1 specifically includes the following steps:

s221: when the consensus starts, the average profit P of the consensus group is calculated and recorded as:

wherein n is the total number of users in the consensus group, P_iThe historical total income of the user i;

s222: dividing users in the consensus group into two groups G according to whether the historical total income is greater than the average income P₁And G₂：

G₁＝{x∈G|f_x≥P}

G₂＝{y∈G|0<f_y<P}

Wherein G is a set formed by all users in the consensus group;

s223: respectively count G₁And G₂Number of users n₁And n₂And the ratio of the reputation value of the user i to the total reputation value of all the users in the whole consensus group is obtained, and the probability that the user i is selected as the consensus representative is obtained:

wherein R is_iIs the reputation value, P, of user i_iThe historical total income of the user i is obtained, and n is the total number of the users in the consensus group;

s224: after the user is selected as a consensus user, obtaining the packing right and the transaction matching right of the next period; the consensus user packs the transaction requirements submitted by the users in the current period, and calls a matching algorithm to perform transaction matching, so as to obtain commission and reputation value promotion rewards of the corresponding transaction requirements; and after the transaction matching is successful, the matching information is distributed to the corresponding user.

6. The relay chain-based inter-block chain interaction method according to claim 1, wherein: step S3 specifically includes the following steps:

s31: after all sub-mark intelligent contracts participating in the chain are submitted, a user participating in the cross-chain in each chain submits related specific sub-transactions according to a matching result, and the state of the sub-mark intelligent contract is used as a triggering basis of the sub-transaction intelligent contract; after the submission is finished, coordinating with the intelligent contract with the sub-mark, wherein the intelligent contract with the sub-mark saves the block id and the transaction id of the cross-chain sub-transaction in all the current chains, and the cross-chain sub-transaction saves the block id and the transaction id of the intelligent contract marked in the chain in which the cross-chain sub-transaction is located;

s32: the intelligent contract with the sub-marks can verify whether the chain-crossing sub-transaction of the current chain-crossing transaction on the chain is submitted and the information is correct, and if the chain-crossing sub-transaction is not submitted and the information is correct, the synchronous state of the chain-crossing transaction to the relay chain is Ready; if a user wants to stop the transaction, after an interruption request is sent to the intelligent subconscriber contract, the synchronous state of the intelligent subconscriber contract to the cross-chain transaction instance on the relay chain is Abort;

s33: the cross-chain transaction example detects the states of all sub-mark intelligent contracts, when the states of all the sub-mark intelligent contracts are Ready, a state transfer instruction is sent to all the sub-mark intelligent contracts, the states are converted into Commit, and after the cross-chain sub-transactions in each chain detect that the states of the sub-mark intelligent contracts are changed into Commit, the transactions are automatically triggered; if the state of the intelligent contract with the sub-mark is changed into Abort, a state transition instruction is sent to all the intelligent contracts with the sub-mark, the state is changed into Abort, and after the chain-crossing sub-transactions in each chain detect that the state of the intelligent contract with the sub-mark is changed into Abort, the transaction is automatically stopped.

7. The method of claim 1, wherein the method comprises: step S4 specifically includes the following steps:

s41: the cross-chain transaction example regularly detects the states of all the sub-mark intelligent contracts recorded by the cross-chain transaction example, when the states of all the sub-mark intelligent contracts are Ready, a state transfer instruction is sent to all the sub-mark intelligent contracts, the states are converted into Commit, the cross-chain sub-transactions in each chain automatically trigger transactions after detecting that the states of the sub-mark intelligent contracts are changed into Commit, and the virtual money locked in the intelligent contracts is transferred to corresponding accounts;

s42: if the state of the intelligent contract with the sub-mark is changed into Abort, a state transfer instruction is sent to all the intelligent contracts with the sub-mark, the state is changed into Abort, and after chain-crossing sub-transactions in each chain detect that the state of the intelligent contract with the sub-mark is changed into Abort, the transaction is automatically stopped; if the transaction information sent by the intelligent sub-mark contract is wrong, the cross-chain transaction instance records the user with the wrong transaction information, reduces the credit value of the user as a punishment, stops the transaction, sends a state transfer instruction to all the intelligent sub-mark contracts and converts the state into an Abort; and after the cross-chain sub-transaction detects that the state of the sub-marker intelligent contract is Abort, interrupting the transaction and returning the locked virtual currency to the corresponding user.

Images