Cross-chain system for multiple heterogeneous chains and cross-chain transaction incentive security guarantee method

Abstract

The present invention relates to a cross-chain system for multiple heterogeneous chains and a cross-chain transaction incentive security assurance method, characterized in that the cross-chain system comprises: a target chain module, a cross-chain alliance module, a cross-chain bridge module and a user module, wherein the number of cross-chain bridge modules is the same as the number of source chains added to the cross-chain system; the target chain module is used to generate target chain blocks, and to obtain, verify, package and chain-up submitted transaction orders; the cross-chain alliance module is used to submit verification transaction orders to the target chain module, and to develop, deploy and maintain the cross-chain bridge; the cross-chain bridge module is used to submit transmission transaction orders to the target chain module, and synchronize the latest status of the corresponding source chain to the target chain; the user module is used to submit basic transaction orders to the target chain module for transactions within the target chain, and submit cross-chain transaction orders to the target chain module for cross-chain transactions. The present invention can be widely used in the field of blockchain.

Description

Technical Field

[0001] The present invention relates to the field of blockchain, and in particular to a cross-chain system for multiple heterogeneous chains and a cross-chain transaction incentive security assurance method. Background Art

[0002] Blockchain uses cryptography, consensus mechanisms, game theory and other methods to enable different nodes in a decentralized network to maintain a secure public ledger that cannot be tampered with. However, due to different application scenarios and technological advances, different blockchains use different cryptographic algorithms, consensus mechanisms, security assumptions, block structures and communication protocols, making each blockchain system an independent vertical closed system, making it difficult to directly interconnect with other blockchains. In order to solve the problems of "information islands, heterogeneous data fusion and heterogeneous protocol interoperability" faced by the blockchain field, cross-chain technology came into being.

[0003] Although relevant personnel have proposed cross-chain solutions such as notary mechanism, hash locking mechanism, side chain / relay chain since 2016, cross-chain still has the following problems: 1) The design goal of partially decentralized multi-chain cross-chain systems is not to connect the existing isolated blockchain ecosystems, but to create another ecosystem that accommodates multiple blockchains. Typical examples of such multi-chain systems are Cosmos and Polkadot. 2) Cross-chain systems designed to connect isolated blockchain ecosystems are difficult to balance "decentralization" and "activity". On the one hand, active cross-chain systems are usually weakly centralized or even completely decentralized. The advantage of such solutions is that the maintenance cost of the cross-chain system is very low. Even if the system is in the cold start stage (i.e., there is a lack of sufficient cross-chain users), the system can still operate. The disadvantage is that the verification of cross-chain evidence depends on a fixed set of nodes (weak centralization) or a certain node (centralization). Once the trusted node is attacked or self-corrupted, cross-chain users will suffer significant losses. On the other hand, decentralized cross-chain systems usually lack activity. The advantage of this type of solution is that the cross-chain evidence is submitted to the blockchain by the source chain porter for verification. As long as the blockchain itself is secure, cross-chain users will not suffer losses. The disadvantage is that the source chain porter's act of submitting cross-chain evidence to the blockchain requires a price. When the cross-chain system is in the cold start phase, the source chain porter cannot collect enough compensation from the cross-chain users, so rational source chain porters will terminate this process, and cross-chain users will also choose to exit the system because the cross-chain evidence cannot be updated in time.

[0004] At present, for users of cross-chain systems, the cross-chain system will not be able to guarantee the security of cross-chain transactions regardless of sacrificing decentralization or activity. Summary of the invention

[0005] In view of the above problems, the purpose of the present invention is to provide a cross-chain system for multiple heterogeneous chains and a cross-chain transaction incentive security assurance method that can ensure the security of cross-chain transactions.

[0006] To achieve the above objectives, the present invention adopts the following technical solutions: In the first aspect, a cross-chain method for multiple heterogeneous chains is provided, comprising:

[0007] Generate target chain blocks through consensus mechanism;

[0008] Submit verification transaction orders to the target chain and develop, deploy and maintain cross-chain bridges;

[0009] Submit a transfer transaction order to the target chain to synchronize the latest status of the corresponding source chain to the target chain;

[0010] Submit the basic transaction order to the target chain for transactions within the target chain, and submit the cross-chain transaction order to the target chain for cross-chain transactions;

[0011] According to the predefined transaction order rules and consensus rules, the submitted transaction orders are acquired, verified, packaged and uploaded to the chain to generate a new target chain.

[0012] Furthermore, submitting the verification transaction form to the target chain and developing, deploying and maintaining the cross-chain bridge include:

[0013] For new source chains that have not joined the cross-chain system, encode the source chain light node consensus rules and transaction verification rules into a bridge contract, and develop a transfer client corresponding to the bridge contract;

[0014] Submit the bridge contract to the target chain module in the format of a verified transaction order, and make the corresponding transfer client public;

[0015] The target chain miner verifies the multi-signature of the cross-chain alliance in the verification transaction order. If the multi-signature is valid, the verification transaction order is uploaded to the chain and the bridge contract in the verification transaction order is deployed;

[0016] Determine the development status of each source chain in real time. If a special event occurs on the source chain, submit the verification transaction form to the target chain module, update the deployed bridge contract, and update the transfer client at the same time.

[0017] Furthermore, submitting the transmission transaction order to the target chain to synchronize the latest status of the corresponding source chain to the target chain includes:

[0018] The source chain porter runs the porter client to obtain the latest status of the bridge contract on the target chain and the latest status of the source chain, and judges whether it is necessary to submit necessary data to the bridge contract according to the pre-set judgment rules. If the judgment result is no, the porter client is run again; if the judgment result is yes, the source chain porter writes the necessary data into the transmission transaction form, submits it to the target chain module, and runs the porter client again;

[0019] The target chain miners verify the transmission transaction order and modify the status of the bridge contract according to the transaction order rules and the light node consensus rules in the bridge contract.

[0020] Furthermore, submitting a basic transaction order to a target chain for a transaction within the target chain, and submitting a cross-chain transaction order to a target chain for a cross-chain transaction, includes:

[0021] Ordinary users submit basic transaction orders to the target chain miners of the target chain module;

[0022] The target chain miners execute the basic transaction order according to the transaction order rules;

[0023] The cross-chain user monitors the latest status of the bridge contract. If the source chain block header where the source chain transaction is located has been submitted to the target chain module by the source chain porter, the source chain transaction and auxiliary proof will be written into the cross-chain transaction order and submitted to the target chain module;

[0024] The target chain miners execute valid cross-chain transaction orders according to the transaction order rules and the transaction verification rules in the bridge contract, but do not modify the status of the bridge contract.

[0025] Furthermore, the submitted transaction orders are acquired, verified, packaged and chained according to the predefined transaction order rules and consensus rules to generate a new target chain, including:

[0026] The target chain miner obtains the unexecuted transaction order;

[0027] The target chain miners verify the unexecuted transaction orders according to the transaction order rules and the additional rules corresponding to different types of transaction orders, and package the valid transaction orders;

[0028] The target chain miners generate a new target chain block including the packaged valid transaction order according to the consensus protocol;

[0029] The target chain miners repeat the above process of obtaining, verifying and packaging transaction orders and generate new blocks of the target chain.

[0030] In a second aspect, a cross-chain system for multiple heterogeneous chains is provided, including a target chain module, a cross-chain alliance module, a cross-chain bridge module and a user module, wherein the number of the cross-chain bridge modules is the same as the number of source chains added to the cross-chain system;

[0031] The target chain module is used to generate target chain blocks, and to obtain, verify, package and upload submitted transaction orders to the chain;

[0032] The cross-chain alliance module is used to submit verification transaction orders to the target chain module and develop, deploy and maintain the cross-chain bridge;

[0033] The cross-chain bridge module is used to submit a transmission transaction order to the target chain module, and synchronize the latest status of the corresponding source chain to the target chain;

[0034] The user module is used to submit a basic transaction order to the target chain module for transactions within the target chain, and submit a cross-chain transaction order to the target chain module for cross-chain transactions.

[0035] The third aspect is to provide a cross-chain transaction incentive security guarantee method for a cross-chain system with multiple heterogeneous chains, including:

[0036] The cross-chain system issues tokens as basic rewards for target chain miners and source chain porters;

[0037] The cross-chain system distributes the issued tokens and the handling fees paid by users to the target chain miners and source chain porters in a certain proportion;

[0038] When a source chain porter submits an invalid source chain block header, the cross-chain system punishes the source chain porter.

[0039] Furthermore, the cross-chain system issues tokens as basic rewards for target chain miners and source chain porters, including:

[0040] The cross-chain system sets the time parameters for issuing tokens and the decay function ;

[0041] In the first cycle , cross-chain system issuance Units of tokens, of which, The number of tokens issued by the cross-chain system in the first cycle;

[0042] In the Cycle, cross-chain system issuance A unit of token.

[0043] Furthermore, the cross-chain system distributes the issued tokens and the handling fees paid by users to the target chain miners and source chain porters in a certain proportion, including:

[0044] The cross-chain system sets the token distribution ratio between the target chain miners and the source chain porters ;

[0045] If a certain cycle, the target chain module generates new blocks, a target chain obtains handling fees from ordinary users in the user module , get the handling fee from the cross-chain users in the user module , then the target chain miner of the target chain will receive a reward ;

[0046] If in a certain period, the cross-chain system exists The cross-chain system obtains the total cross-chain handling fee , where number is Source chain submitted Valid transmission transaction orders, get cross-chain fees , then each source chain porter who effectively transmits a transaction order will receive a reward:

[0047] .

[0048] Furthermore, when the source chain porter submits an invalid source chain block header, the cross-chain system punishes the source chain porter, including:

[0049] When the source chain porter submits the transfer transaction order, the pledge Unit of token;

[0050] If all the source chain block headers included in the transmission transaction order are valid block headers, the source chain porter will recover all the deposits; if the source chain block headers included in the transmission transaction order include invalid block headers, the cross-chain system will punish the source chain porter to lose all the deposits, and the target chain miner of the target chain where the transmission transaction order is located will obtain half of the deposit and destroy the other half.

[0051] The present invention adopts the above technical solution, which has the following advantages:

[0052] 1. The present invention combines the blockchain solution and the cross-chain relay solution, so that the target chain can realize cross-chain verification of source chain transactions in a decentralized manner, and can support at least 5 types of 10 blockchains to join as source chains.

[0053] 2. The present invention can accommodate more than 100 nodes (including target chain miners, cross-chain alliance members, and different source chain porters) and 10,000 users (including ordinary users and cross-chain users).

[0054] 3. The present invention can achieve security protection for cross-chain transactions through an incentive mechanism, that is, in the cold start phase, when the cross-chain system lacks sufficient cross-chain users, the source chain porters still have sufficient motivation to transport the source chain block headers and maintain the decentralized cross-chain bridge. The system is decentralized and active at the same time, thereby ensuring the security of cross-chain transactions.

[0055] In summary, the present invention can be widely used in the field of blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Throughout the accompanying drawings, the same reference numerals are used to represent the same components. In the accompanying drawings:

[0057] Figure 1 is a schematic diagram of a cross-chain method provided by an embodiment of the present invention;

[0058] Figure 2 It is a schematic diagram of the working process of the cross-chain bridge module in the cross-chain method provided by one embodiment of the present invention;

[0059] Figure 3 It is a schematic diagram of the workflow of the target chain module in the cross-chain method provided in one embodiment of the present invention. DETAILED DESCRIPTION

[0060] The exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0061] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0062] Although the terms first, second, third, etc. can be used in the text to describe multiple elements, components, regions, layers and / or sections, these elements, components, regions, layers and / or sections should not be limited by these terms. These terms can only be used to distinguish an element, component, region, layer or section from another region, layer or section. Unless the context clearly indicates, terms such as "first", "second" and other numerical terms do not imply order or sequence when used in the text. Therefore, the first element, component, region, layer or section discussed below can be referred to as the second element, component, region, layer or section without departing from the teaching of the example embodiments.

[0063] For ease of description, spatially relative terms may be used herein to describe the relationship of one element or feature relative to another element or feature as shown in the figures, such as "inside", "outside", "inner side", "outer side", "below", "above", etc. Such spatially relative terms are intended to include different orientations of the device in use or operation in addition to the orientation depicted in the figures.

[0064] It should be noted that in the embodiment of the present invention, the existing blockchain is called the source chain, and the blockchain newly built to realize the cross-chain system is called the target chain.

[0065] The cross-chain system for multiple heterogeneous chains and the cross-chain transaction incentive security assurance method provided by the embodiment of the present invention realize decentralized verification of ordinary transactions and cross-chain transactions through the target chain module 1, realize the development, deployment and maintenance of the cross-chain bridge through the cross-chain alliance module 2, realize the decentralized verification of the source chain account book by the target chain through the cross-chain bridge module 3, enable the target chain to support the user's intra-chain transaction and cross-chain transaction through the user module 4, and realize the security of cross-chain transactions through the cross-chain transaction incentive security assurance method, which can ensure that the cross-chain system has both "decentralization" and "activity", thereby ensuring the security of cross-chain transactions.

[0066] Example 1

[0067] like Figure 1 As shown, this embodiment provides a cross-chain method for multiple heterogeneous chains, including the following steps:

[0068] 1) Target chain module 1 generates target chain blocks through a consensus mechanism.

[0069] 2) The cross-chain alliance module 2 submits the verification transaction order to the target chain and develops, deploys and maintains the cross-chain bridge, specifically:

[0070] 2.1) For new source chains that have not joined the cross-chain system and have a certain influence, encode the source chain light node consensus rules and transaction verification rules into a bridge contract, and develop a transfer client corresponding to the bridge contract.

[0071] 2.2) Submit the bridge contract to the target chain module 1 in the format of a verified transaction order, and make the corresponding transfer client public.

[0072] 2.3) The target chain miner verifies the multi-signature of the cross-chain alliance in the verification transaction order. If the multi-signature is valid, the verification transaction order will be uploaded to the chain and the bridge contract in the verification transaction order will be deployed.

[0073] Specifically, the target chain miners are nodes that run the target chain protocol, continuously execute transaction orders, and generate new blocks for the target chain.

[0074] 2.4) Determine the development of each source chain in real time. If a special event such as soft fork, hard fork or rollback occurs on the source chain, submit the verification transaction form to the target chain module 1, update the deployed bridge contract, and update the transfer client at the same time.

[0075] 3) If Figure 2 As shown, the cross-chain bridge module 3 submits the transmission transaction order to the target chain module 1, and synchronizes the latest status of the corresponding source chain to the target chain, specifically:

[0076] 3.1) The source chain porter runs the porting client to obtain the latest status of the bridge contract on the target chain and the latest status of the source chain, and judges whether it is necessary to submit the necessary data such as the new block header of the source chain to the bridge contract according to the pre-set judgment rules. If the judgment result is no, repeat step 3.1); if the judgment result is yes, the source chain porter writes the necessary data such as the new block header of the source chain into the transmission transaction form, submits it to the target chain module 1, and repeats step 3.1).

[0077] Specifically, the source chain porter is the node that submits the latest block header of the source chain to the target chain.

[0078] Specifically, the judgment rules are defined by the bridge contract, and different source chains have different specific judgment rules.

[0079] Specifically, the source chain porter needs to repeat step 3.1) all the time, that is, keep monitoring the source chain and bridge contract status. If the source chain generates a new block, the source chain porter will submit the corresponding block header to the target chain until the source chain porter actively exits the cross-chain system, and then stop repeating step 3.1).

[0080] 3.2) The target chain miners verify the transmission transaction order and modify the status of the bridge contract according to the transaction order rules and the light node consensus rules in the bridge contract.

[0081] Specifically, the specific process of the target chain miner verifying the transmission transaction order is as follows:

[0082] 3.2.1) The target chain miner parses the block header in the transmission transaction order. If the parsing fails, the transmission transaction order is rejected.

[0083] 3.2.2) The target chain miner queries the bridge contract to see if the block header has been submitted. If the block header has been submitted, the transfer transaction order is rejected.

[0084] 3.2.3) The target chain miner queries the bridge contract to see if the parent block header of the block header has been submitted. If not, the transfer transaction order is rejected.

[0085] 3.2.4) The target chain miner verifies whether the fields in the block header are correct. If the verification fails, the transmission transaction order is rejected.

[0086] 3.2.5) After all verifications are passed, the target chain miner writes the transfer transaction order into the target chain's new block and updates the status of the bridge contract.

[0087] 4) User module 4 submits the basic transaction order to target chain module 1 for transactions within the target chain, and submits the cross-chain transaction order to target chain module 1 for cross-chain transactions.

[0088] Specifically, users are divided into ordinary users and cross-chain users. Ordinary users submit transactions unrelated to cross-chain, and cross-chain users submit transactions related to cross-chain. The specific process of this step is:

[0089] 4.1) Ordinary users submit basic transaction orders to the target chain miners in target chain module 1.

[0090] 4.2) Target chain miners execute basic transaction orders according to transaction order rules.

[0091] 4.3) The cross-chain user monitors the latest status of the bridge contract. If the source chain block header where the source chain transaction is located has been submitted to the target chain module 1 by the source chain porter, the source chain transaction and auxiliary proof will be written into the cross-chain transaction order and submitted to the target chain module 1.

[0092] 4.4) The target chain miners execute valid (i.e., rule-verified) cross-chain transaction orders according to the transaction order rules and the transaction verification rules in the bridge contract, but do not modify the status of the bridge contract.

[0093] Specifically, the target chain miner verifies the cross-chain transaction order submitted by the cross-chain user in the user module 4 as follows:

[0094] 4.4.1) The target chain miner queries the bridge contract based on the block header hash to see whether the block header has been submitted, whether it is on the main chain, and whether it has been confirmed by 6 subsequent block headers. If all verifications are not passed, the cross-chain transaction order will be rejected.

[0095] Specifically, in the bridge contract, the block header corresponds one-to-one to the source chain block.

[0096] 4.4.2) The target chain miner calculates the Merkle tree root based on the source chain transaction and auxiliary proof, and queries the bridge contract for the transaction root corresponding to the block header to check whether the two are equal. If they are not equal, the cross-chain transaction order is rejected.

[0097] 4.4.3) After all verifications are passed, the target chain miner writes the cross-chain transaction order to the target chain, but does not modify the bridge contract status.

[0098] 5) If Figure 3 As shown, the target chain module 1 acquires, verifies, packages and processes the submitted transaction orders according to the predefined transaction order rules and consensus rules to generate a new target chain, specifically:

[0099] 5.1) Target chain miners obtain unexecuted transaction orders.

[0100] 5.2) Target chain miners verify unexecuted transaction orders according to the transaction order rules and additional rules corresponding to different types of transaction orders, and package valid transaction orders.

[0101] 5.3) The target chain miners generate a new target chain block including the packaged valid transaction order according to the consensus protocol.

[0102] 5.4) The target chain miner repeats steps 5.1) to 5.3) to continuously verify and package the transaction orders and generate new blocks for the target chain.

[0103] Furthermore, the target chain miners are A committee of nodes, is the upper limit of the number of malicious nodes that the target chain can accommodate. The specific process is:

[0104] A) The committee nodes are numbered as follows: , the current view number is .

[0105] B) Compute Node , numbered The node becomes the current view The master node.

[0106] C) The master node packages several valid transaction orders to generate a block to be signed and broadcasts it to other nodes of the committee.

[0107] D) After receiving the message, other nodes record the message and broadcast it to other nodes again.

[0108] E) The node receives more than After receiving the same message, verify whether the block to be signed is correct. If correct, generate a signature and broadcast it to other nodes.

[0109] F) If the node receives more than After the signature is completed, the block to be signed and the signature are uploaded to the chain, and the current view ends. .

[0110] G) The target chain miner updates the committee members and view number and repeats steps A) to F).

[0111] Example 2

[0112] This embodiment provides a cross-chain system for multiple heterogeneous chains, including a target chain module 1, a cross-chain alliance module 2, a cross-chain bridge module 3 and a user module 4, wherein the number of cross-chain bridge modules 3 is the same as the number of source chains added to the cross-chain system.

[0113] The target chain module 1 is used to generate target chain blocks, and to obtain, verify, package and upload submitted transaction orders.

[0114] The cross-chain alliance module 2 is used to submit verification transaction orders to the target chain module 1 and to develop, deploy and maintain the cross-chain bridge.

[0115] The cross-chain bridge module 3 is used to submit the transmission transaction order to the target chain module 1, and synchronize the latest status of the corresponding source chain to the target chain.

[0116] The user module 4 is used to submit a basic transaction order to the target chain module 1 for transactions within the target chain, and submit a cross-chain transaction order to the target chain module 1 for cross-chain transactions.

[0117] In a preferred embodiment, the target chain module 1 uses a PBFT (Practical Byzantine Fault Tolerance) consensus mechanism to continuously generate new blocks of the target chain.

[0118] In a preferred embodiment, the target chain module 1 includes a transaction order acquisition unit, a verification unit, a packaging unit and a target chain generation unit.

[0119] The transaction order acquisition unit is used to acquire unexecuted transaction orders.

[0120] The verification unit is used to verify the unexecuted transaction orders according to the transaction order rules and the additional rules corresponding to different types of transaction orders.

[0121] The packaging unit is used to package valid transaction orders.

[0122] The target chain generation unit is used to generate a new block of the target chain including the packaged valid transaction order according to the consensus protocol.

[0123] In a preferred embodiment, the cross-chain alliance module 2 includes a cross-chain bridge development unit, a transaction verification order submission unit, a cross-chain bridge deployment unit and a cross-chain bridge maintenance unit.

[0124] The cross-chain bridge development unit is used to encode the source chain light node consensus rules and transaction verification rules into a bridge contract for new source chains that have not joined the cross-chain system and have a certain influence, and develop a transfer client corresponding to the bridge contract.

[0125] The verification transaction order submission unit is used to submit the bridge contract to the target chain module 1 in the format of the verification transaction order, and disclose the corresponding transfer client.

[0126] The cross-chain bridge deployment unit is used to verify the multi-signature of the cross-chain alliance in the verification transaction order. If the multi-signature is valid, the verification transaction order will be uploaded to the chain and the bridge contract in the verification transaction order will be deployed.

[0127] The cross-chain bridge maintenance unit is used to determine the development status of each source chain in real time. If a special event such as a soft fork, hard fork or rollback occurs in the source chain, the deployed bridge contract is updated by submitting a verification transaction order, and the transfer client is updated at the same time.

[0128] In a preferred embodiment, the cross-chain bridge module 3 includes a judgment unit and a transmission transaction order verification unit.

[0129] The judgment unit is used to run the transfer client, obtain the latest status of the bridge contract on the target chain and the latest status of the source chain, and judge whether it is necessary to submit necessary data such as the new block header of the source chain to the bridge contract. If the judgment result is yes, the source chain porter writes the necessary data such as the new block header of the source chain into the transmission transaction order and submits it to the target chain module 1.

[0130] The transmission transaction order verification unit is used to verify the transmission transaction order and modify the status of the bridge contract according to the transaction order rules and the light node consensus rules in the bridge contract.

[0131] In a preferred embodiment, the user module 4 includes a common user unit, a basic transaction order execution unit, a cross-chain user unit and a cross-chain transaction order execution unit.

[0132] Ordinary user units are used to submit basic transaction orders to the target chain.

[0133] The basic transaction order execution unit is used to execute the basic transaction order according to the transaction order rules.

[0134] The cross-chain user unit is used to monitor the latest status of the bridge contract. If the source chain block header where the source chain transaction is located has been submitted to the target chain module 1 by the source chain porter, the source chain transaction and auxiliary proof will be written into the cross-chain transaction order and submitted to the target chain module 1.

[0135] The cross-chain transaction order execution unit is used to execute valid cross-chain transaction orders according to the transaction order rules and the transaction verification rules in the bridge contract, but does not modify the status of the bridge contract.

[0136] Example 3

[0137] This embodiment provides a cross-chain transaction incentive security assurance method for a cross-chain system for multiple heterogeneous chains based on the embodiment 2, including the following steps:

[0138] I) The cross-chain system issues tokens as the basic reward for target chain miners and source chain porters, specifically:

[0139] II) The cross-chain system sets the time parameters for issuing tokens and the decay function .

[0140] I.ii) In the first cycle , cross-chain system issuance Units of tokens, of which, The number of tokens issued by the cross-chain system in the first cycle.

[0141] I.iii) In Cycle, cross-chain system issuance A unit of token.

[0142] Furthermore, steps I.ii) and I.iii) are the upper limits of the tokens issued within the cycle. If there is no allocation object when allocating tokens, the actual issuance of tokens will be lower than the upper limit.

[0143] II) The cross-chain system distributes the issued tokens and the fees paid by users to the target chain miners and source chain porters in a certain proportion, specifically:

[0144] II.i) The cross-chain system sets the token distribution ratio between the target chain miners and the source chain porters .

[0145] II.ii) If in a certain cycle, the target chain module 1 generates new blocks, a target chain obtains handling fees from ordinary users in user module 4 , get the handling fee from the cross-chain user in user module 4 , then the target chain miner of the target chain will receive a reward .

[0146] II.iii) If a cross-chain system exists in a certain period The cross-chain system obtains the total cross-chain handling fee , where number is Source chain submitted Valid transmission transaction orders, get cross-chain fees , then each source chain porter who effectively transmits a transaction order will receive a reward:

[0147] .

[0148] Furthermore, if in a certain period, the number of source chains in the cross-chain system , the rewards of the target chain miners will not be affected, and no source chain porters will receive rewards.

[0149] III) When the source chain porter submits an invalid source chain block header, the cross-chain system will punish the source chain porter as follows:

[0150] III.i) When the source chain porter submits the transfer transaction order, the pledge A unit of token.

[0151] III.ii) If all the source chain block headers included in the transmission transaction order are valid block headers, the source chain porter will get back all the deposits; if the source chain block headers included in the transmission transaction order include invalid block headers, the cross-chain system will punish the source chain porter to lose all the deposits, and the target chain miner of the target chain where the transmission transaction order is located will get half of the deposit, that is , the other half of the deposit will be burned.

[0152] The above embodiments are only used to illustrate the present invention, wherein the structure, connection mode and manufacturing process of each component may be changed. Any equivalent transformations and improvements based on the technical solution of the present invention should not be excluded from the protection scope of the present invention.

Claims

1. A cross-chain method for multiple heterogeneous chains, characterized in that: include: Generate target chain blocks through consensus mechanism; Submit verification transaction orders to the target chain and develop, deploy and maintain cross-chain bridges; Submit a transfer transaction order to the target chain to synchronize the latest status of the corresponding source chain to the target chain; Submit the basic transaction order to the target chain for transactions within the target chain, and submit the cross-chain transaction order to the target chain for cross-chain transactions; According to the predefined transaction order rules and consensus rules, the submitted transaction orders are acquired, verified, packaged and uploaded to the chain to generate a new target chain; Submitting verification transaction orders to the target chain and developing, deploying and maintaining cross-chain bridges include: For new source chains that have not joined the cross-chain system, encode the source chain light node consensus rules and transaction verification rules into a bridge contract, and develop a transfer client corresponding to the bridge contract; Submit the bridge contract to the target chain module in the format of a verified transaction order, and make the corresponding transfer client public; The target chain miner verifies the multi-signature of the cross-chain alliance in the verification transaction order. If the multi-signature is valid, the verification transaction order is uploaded to the chain and the bridge contract in the verification transaction order is deployed; Determine the development of each source chain in real time. If a special event occurs on the source chain, submit the verification transaction form to the target chain module, update the deployed bridge contract, and update the transfer client at the same time; Submitting a transmission transaction order to the target chain to synchronize the latest status of the corresponding source chain to the target chain includes: The source chain porter runs the porter client to obtain the latest status of the bridge contract on the target chain and the latest status of the source chain, and judges whether it is necessary to submit necessary data to the bridge contract according to the pre-set judgment rules. If the judgment result is no, the porter client is run again; if the judgment result is yes, the source chain porter writes the necessary data into the transmission transaction form, submits it to the target chain module, and runs the porter client again; The target chain miners verify the transmission transaction order and modify the status of the bridge contract according to the transaction order rules and the light node consensus rules in the bridge contract.

2. A cross-chain method for multiple heterogeneous chains as claimed in claim 1, characterized in that: Submitting a basic transaction order to the target chain for transactions within the target chain, and submitting a cross-chain transaction order to the target chain for cross-chain transactions, includes: Ordinary users submit basic transaction orders to the target chain miners of the target chain module; The target chain miners execute the basic transaction order according to the transaction order rules; The cross-chain user monitors the latest status of the bridge contract. If the source chain block header where the source chain transaction is located has been submitted to the target chain module by the source chain porter, the source chain transaction and auxiliary proof will be written into the cross-chain transaction order and submitted to the target chain module; The target chain miners execute valid cross-chain transaction orders according to the transaction order rules and the transaction verification rules in the bridge contract, but do not modify the status of the bridge contract.

3. A cross-chain method for multiple heterogeneous chains as claimed in claim 1, characterized in that: According to the predefined transaction order rules and consensus rules, the submitted transaction order is obtained, verified, packaged and chained to generate a new target chain, including: The target chain miner obtains the unexecuted transaction order; The target chain miners verify the unexecuted transaction orders according to the transaction order rules and the additional rules corresponding to different types of transaction orders, and package the valid transaction orders; The target chain miners generate a new target chain block including the packaged valid transaction order according to the consensus protocol; The target chain miners repeat the above process of obtaining, verifying and packaging transaction orders and generate new blocks of the target chain.

4. A cross-chain system for multiple heterogeneous chains, characterized in that: It includes a target chain module, a cross-chain alliance module, a cross-chain bridge module and a user module, wherein the number of the cross-chain bridge modules is the same as the number of source chains added to the cross-chain system; The target chain module is used to generate the target chain, and to obtain, verify, package and upload submitted transaction orders to the chain; The cross-chain alliance module is used to submit verification transaction orders to the target chain module and develop, deploy and maintain the cross-chain bridge; The cross-chain bridge module is used to submit a transmission transaction order to the target chain module, and synchronize the latest status of the corresponding source chain to the target chain; The user module is used to submit a basic transaction order to the target chain module for transactions within the target chain, and submit a cross-chain transaction order to the target chain module for cross-chain transactions; Submitting verification transaction orders to the target chain and developing, deploying and maintaining cross-chain bridges include: For new source chains that have not joined the cross-chain system, encode the source chain light node consensus rules and transaction verification rules into a bridge contract, and develop a transfer client corresponding to the bridge contract; Submit the bridge contract to the target chain module in the format of a verified transaction order, and make the corresponding transfer client public; The target chain miner verifies the multi-signature of the cross-chain alliance in the verification transaction order. If the multi-signature is valid, the verification transaction order is uploaded to the chain and the bridge contract in the verification transaction order is deployed; Determine the development of each source chain in real time. If a special event occurs on the source chain, submit the verification transaction form to the target chain module, update the deployed bridge contract, and update the transfer client at the same time; Submitting a transmission transaction order to the target chain to synchronize the latest status of the corresponding source chain to the target chain includes: The source chain porter runs the porter client to obtain the latest status of the bridge contract on the target chain and the latest status of the source chain, and judges whether it is necessary to submit necessary data to the bridge contract according to the pre-set judgment rules. If the judgment result is no, the porter client is run again; if the judgment result is yes, the source chain porter writes the necessary data into the transmission transaction form, submits it to the target chain module, and runs the porter client again; The target chain miners verify the transmission transaction order and modify the status of the bridge contract according to the transaction order rules and the light node consensus rules in the bridge contract.

5. A cross-chain transaction incentive security assurance method for a cross-chain system for multiple heterogeneous chains based on claim 4, characterized in that: include: The cross-chain system issues tokens as basic rewards for target chain miners and source chain porters; The cross-chain system distributes the issued tokens and the handling fees paid by users to the target chain miners and source chain porters in a certain proportion; When a source chain porter submits an invalid source chain block header, the cross-chain system punishes the source chain porter.

6. The cross-chain transaction incentive security guarantee method according to claim 5, characterized in that: The cross-chain system issues tokens as basic rewards for target chain miners and source chain porters, including: The cross-chain system sets the time parameters for issuing tokens and the decay function ; In the first cycle , cross-chain system issuance Units of tokens, of which, The number of tokens issued by the cross-chain system in the first cycle; In the Cycle, cross-chain system issuance A unit of token.

7. The cross-chain transaction incentive security guarantee method according to claim 5, characterized in that: The cross-chain system distributes the issued tokens and the handling fees paid by users to the target chain miners and source chain porters in a certain proportion, including: The cross-chain system sets the token distribution ratio between the target chain miners and the source chain porters ; If a certain cycle, the target chain module generates new blocks, a target chain obtains handling fees from ordinary users in the user module , get the handling fee from the cross-chain users in the user module , then the target chain miner of the target chain will receive a reward ; If a certain period, the cross-chain system exists The cross-chain system obtains the total cross-chain handling fee , where number is Source chain submitted Valid transmission transaction orders, get cross-chain fees , then each source chain porter who effectively transmits a transaction order will receive a reward: 。 8. The cross-chain transaction incentive security guarantee method according to claim 5, characterized in that: When the source chain porter submits an invalid source chain block header, the cross-chain system will punish the source chain porter, including: When the source chain porter submits the transfer transaction order, the pledge Unit of token; If all the source chain block headers included in the transmission transaction order are valid block headers, the source chain porter will recover all the deposits; if the source chain block headers included in the transmission transaction order include invalid block headers, the cross-chain system will punish the source chain porter to lose all the deposits, and the target chain miner of the target chain where the transmission transaction order is located will obtain half of the deposit and destroy the other half.

Images