Block chain cross-chain transaction method and block chain system

Abstract

The invention discloses a block chain cross-chain transaction method, which is characterized in that a cross-chain transaction between two or more block chains by a user follows an optimistic execution mechanism, the transaction is executed by an executor under the chain, a zero-knowledge proof does not need to be generated for each block, the zero-knowledge proof is generated only when the transaction is challenged, and a transaction execution result is stored on the chain; when the transaction is challenged, the smart contract on the chain performs cross-chain transaction verification, specifically including execution verification and inconsistency verification, the method provided by the invention verifies the transaction itself, which belongs to direct verification, and when the transaction verification is not passed, the account state of the associated account on the chain is withdrawn until the account state is updated, so that the security of system transaction execution is ensured; according to the transaction method provided by the invention, an optimistic execution mechanism is adopted, so that the transaction does not need to be executed on a chain, and compared with the prior art, the transaction method has higher throughput and stronger expandability.

Description

Technical Field

[0001] The present invention relates to cross-chain transaction technology, and in particular to a blockchain cross-chain transaction method and a blockchain system. Background Art

[0002] As a distributed ledger technology, blockchain realizes decentralized data storage and management through peer-to-peer networks and consensus mechanisms. It does not rely on centralized entities, while ensuring data transparency and security. It has been widely used in innovations in finance, security and other fields. Since then, the introduction of smart contract technology has further expanded the application boundaries of blockchain. Smart contracts can automatically execute related operations when preset conditions are met, realizing a reliable and efficient transaction process. With the rapid development of blockchain networks, the independent operation of each chain has led to information island problems. The transfer of digital currencies between different chains and cross-chain collaboration of smart contracts are difficult to be directly met. For this reason, cross-chain communication and collaboration have become an important research direction of blockchain technology.

[0003] The existing cross-chain transaction framework is mainly implemented through chain bridge technology. As a connection mechanism between different blockchains, chain bridges are mainly divided into two categories: notarization-based chain bridges and zero-knowledge proof-based chain bridges. Notarization-based chain bridges rely on trusted third parties or intermediary nodes. These entities are responsible for verifying the legitimacy of cross-chain transactions and executing transaction results on the target chain. Such chain bridges are usually simple to implement and highly efficient, but their security depends on the credibility of the notary. If the notary is attacked or malicious behavior occurs, it may lead to the loss of cross-chain assets or data. Zero-knowledge proof-based chain bridges achieve low-cost cross-chain block data transmission through zero-knowledge proofs, and complete the verification of cross-chain transactions based on cross-chain block data. Such chain bridges eliminate the reliance on trusted intermediaries and significantly improve the privacy and security of cross-chain transactions. However, due to the complex generation process of zero-knowledge proofs, the operation cost of chain bridges is high and the scalability is poor. Summary of the invention

[0004] Based on this, the present invention aims to propose a blockchain cross-chain transaction method and a blockchain system, improve the traditional chain bridge based on zero-knowledge proof based on the optimistic execution mechanism, and propose a new cross-chain transaction framework to ensure transaction security while improving the scalability of the chain bridge.

[0005] In a first aspect, the present invention proposes a blockchain cross-chain transaction method, comprising:

[0006] The executor executes the cross-chain transaction off-chain in response to the user's cross-chain transaction request, generates a transaction execution result and submits it to the first blockchain and the second blockchain, wherein the cross-chain transaction request includes the user performing a cross-chain transaction between the first blockchain and the second blockchain;

[0007] The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on the respective blockchains according to the transaction execution result;

[0008] If the transaction execution result is not challenged by the verifier during the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is carried out.

[0009] Furthermore, transaction verification includes execution verification, and execution verification includes:

[0010] The verifier verifies the validity of the transaction execution result off-chain, and initiates an execution challenge request to the first blockchain if the verification fails;

[0011] The first smart contract deployed on the first blockchain responds to the execution challenge request and verifies the validity of the transaction execution result. If the verification fails, the first smart contract restores the account status of the user account associated with the cross-chain transaction on the first blockchain to the state before the update, and generates a transaction withdrawal result corresponding to the transaction execution result;

[0012] The first smart contract sends the transaction withdrawal result to the executor and the verifier.

[0013] Furthermore, transaction verification includes consistency verification, which includes:

[0014] The verifier obtains the first transaction execution result on the first blockchain and the second transaction execution result on the second blockchain respectively, compares whether the first transaction execution result and the second transaction execution result are consistent, obtains the latest block information of the first blockchain if they are inconsistent, generates an inconsistency proof using the latest block information of the first blockchain and sends it to the second blockchain, and issues an inconsistency challenge request to the second blockchain;

[0015] The second smart contract deployed on the second blockchain responds to the inconsistency challenge request and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update based on the inconsistency proof.

[0016] Furthermore, when the first smart contract fails to verify the validity of the transaction execution result during the execution verification, the transaction verification also includes consistency verification, which includes:

[0017] The verifier sends the cross-chain proof and the latest block information of the first blockchain to the second blockchain, where the cross-chain proof is generated based on the latest block information of the first blockchain, and generates an inconsistency proof based on the transaction withdrawal result and sends it to the second blockchain, initiating an inconsistency challenge request to the second blockchain;

[0018] The second smart contract deployed on the second blockchain responds to the inconsistency challenge request, verifies the legitimacy of the latest block information of the first blockchain by using the cross-chain proof, adds the latest block information of the first blockchain to the cross-chain block list when the verification passes, obtains the transaction retraction result by using the inconsistency proof, and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction retraction result.

[0019] Furthermore, cross-chain proofs are generated using a zero-knowledge proof algorithm.

[0020] Furthermore, the generation of cross-chain proofs includes:

[0021] Determine the xth block of the first blockchain, the latest block of the first blockchain is the rth block, wherein the xth block is a block that does not require validity verification, the rth block is the Nth successor block of the xth block, and there are N-1 blocks between the rth block and the xth block;

[0022] Verifying the validity of the rth block is equivalent to verifying the validity of the N subsequent blocks of the xth block, and the following binary interactive verification process is performed:

[0023] The first smart contract provides the validator with the hash value of the x+N / 2th block for validity verification. If the verification is successful, the validity of the blocks between the x+N / 2th block and the rth block is verified. Otherwise, the validity of the blocks between the xth block and the x+N / 2th block is verified. The binary verification process is repeated until the N subsequent blocks cannot be binary-divided.

[0024] The verifier generates a cross-chain proof based on the verification results of the binary interactive verification process.

[0025] Furthermore, the second smart contract uses the inconsistency proof to obtain the transaction reversal result, and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction reversal result, including:

[0026] Obtain the latest state root from the latest block information of the first blockchain;

[0027] The latest state root is used to verify the legitimacy of the inconsistency proof. When the verification passes, the inconsistency proof is used to obtain the transaction withdrawal result. The transaction withdrawal result is compared with the stored transaction execution result to generate a comparison result. According to the comparison result, the account status of the user account associated with the cross-chain transaction on the second blockchain is restored to the state before the update.

[0028] Furthermore, the generation of transaction retracement results includes:

[0029] The first smart contract modifies the preset status field in the transaction execution result to obtain the transaction withdrawal result.

[0030] Furthermore, the validator includes a light node on the first blockchain, and / or a shared node between the first blockchain and the second blockchain.

[0031] In a second aspect, the present invention provides a blockchain transaction system, including a first blockchain, a second blockchain, an executor, a verifier, and a user;

[0032] A first smart contract and a second smart contract are deployed on the first blockchain and the second blockchain respectively, and a user performs cross-chain transactions between the first blockchain and the second blockchain;

[0033] The executor is used to respond to the user's cross-chain transaction request, execute the cross-chain transaction off-chain, generate the transaction execution result and submit it to the first blockchain and the second blockchain;

[0034] The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on the respective blockchains according to the transaction execution result;

[0035] The validator challenges the transaction execution result during the challenge period. If the transaction execution result is not challenged by the validator during the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0036] Furthermore, the validator includes a light node on the first blockchain, and / or a shared node between the first blockchain and the second blockchain.

[0037] In a third aspect, the present invention provides an electronic device, including a memory and a processor;

[0038] The memory is used to store programs;

[0039] The processor is used to execute the program to implement each step of the aforementioned blockchain cross-chain transaction method.

[0040] In a fourth aspect, the present invention provides a readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the various steps of the aforementioned cross-chain transaction method are implemented.

[0041] Compared with existing cross-chain transactions, the present invention has the following beneficial effects:

[0042] The cross-chain transaction method proposed in the present invention is an improvement based on optimistic execution. In order to complete the cross-chain transaction between two or more blockchains of users, it is not necessary to generate zero-knowledge proof for each block. It is only generated when the transaction is challenged. The transaction is executed by the executor off-chain, and the transaction execution result can be packaged and stored on the chain. In a more specific implementation method, when the transaction is challenged, the smart contract on the chain performs cross-chain transaction verification. Compared with the prior art in which multiple verifiers endorse the transaction to prove the validity of the transaction, the verification method proposed in the present invention verifies the transaction itself, which is a direct verification rather than an indirect verification through endorsement. When the transaction verification fails, the account status of the associated account on the chain is withdrawn to before the update, thereby ensuring the security of the system transaction execution. Due to the use of an optimistic execution mechanism, the transaction method proposed in the present invention does not need to execute transactions on the chain, and has higher throughput and stronger scalability than the prior art. Secondly, the proposed transaction verification mechanism can support the correctness of the system operation as long as there is an honest verifier to initiate a challenge, which is more secure than the traditional chain bridge framework. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0044] Figure 1 This is a diagram of a blockchain system architecture for executing cross-chain transactions provided by an embodiment of the present invention;

[0045] Figure 2 This is an interactive diagram of a blockchain cross-chain transaction method provided by an embodiment of the present invention;

[0046] Figure 3 It is a flow chart of consistency verification interaction initiated by a verifier due to cross-chain inconsistency caused by verification execution provided by an embodiment of the present invention;

[0047] Figure 4 It is a schematic diagram of generating a cross-chain proof through binary interactive verification provided by an embodiment of the present invention;

[0048] Figure 5 It is a schematic diagram of account status change for cross-chain transactions between chains L1 and L2 in an optimistic scenario provided by an embodiment of the present invention;

[0049] Figure 6 It is an illustration of initiating a challenge to a cross-chain transaction between chains L1 and L2 provided by an embodiment of the present invention;

[0050] Figure 7This is a specific illustration of a cross-chain transaction executed by a smart contract deployed on chains L1 and L2 in an optimistic scenario provided by an embodiment of the present invention;

[0051] Figure 8 It is a specific illustration of initiating execution challenge and consistency challenge for cross-chain transactions between chains L1 and L2 provided by an embodiment of the present invention;

[0052] Fig. 9 This is a diagram of the electronic device architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0053] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0054] The optimistic execution mechanism is an off-chain expansion solution. Its core concept is to move the calculation and storage of a large number of transactions from the main chain to the off-chain execution, while storing the minimized transaction summary and proof information on the main chain to ensure security and verifiability. By "rolling up" transactions off-chain and submitting them to the main chain in batches, the optimistic execution mechanism makes transaction execution not subject to the performance limitations of the complex verification process on the blockchain, significantly improving the throughput of the blockchain network. The optimistic execution mechanism usually includes an executor and multiple verifiers. The executor executes transactions separately off-chain and submits transaction data and execution results to the smart contract on the chain (called Rollup contract). The smart contract on the chain assumes that the execution result is correct by default and does not perform any verification. After a dispute period, the execution result is directly adopted. During the dispute period, if a verifier finds that the execution result is wrong and initiates a challenge, the smart contract will re-execute the uploaded transaction and withdraw the wrong result. In the optimistic case, if all the results submitted by the executor are correct, the system does not need to execute any transactions, which greatly reduces the overhead of system execution.

[0055] Traditional zero-knowledge proof-based cross-chain transaction bridge technology requires constructing a zero-knowledge proof for each block. In order to prove the validity of the latest block, the cost is O(N), where N represents the number of blocks between the last cross-chain block and the latest block. The principle is: since the existing zero-knowledge proof technology can only prove that a block is a legitimate subsequent block of another block, that is, it can only use a trusted block header blkH n Verify another block header blkH n+1Under the optimistic execution mechanism, if the Rollup contract wants to use the last cross-chain block blkH0 saved in the contract to verify the latest block blkH N The legitimacy of the blocks blkH1,...,blkH N-1 The legitimacy of , therefore, the verification cost is still O(N).

[0056] In order to solve the above problems, the present invention proposes a blockchain cross-chain transaction method, which improves the traditional chain bridge based on zero-knowledge proof based on the optimistic execution mechanism, and proposes a new cross-chain transaction framework to ensure transaction security while improving the scalability of the chain bridge. These will be explained one by one in the following embodiments.

[0057] like Figure 1 As shown, it shows a blockchain system proposed in one embodiment of the present invention, including a first blockchain L1, a second blockchain L2, an executor, a verifier and a user.

[0058] Among them, the blockchain is responsible for managing the user's digital currency assets and running smart contracts. In the following embodiments, for the convenience of explanation, only the case of cross-chain transactions between two blockchains is considered. It is easy to understand that those skilled in the art can increase the number of blockchains for cross-chain transactions as needed.

[0059] A first smart contract and a second smart contract are deployed on the first blockchain and the second blockchain respectively, and a user performs cross-chain transactions between the first blockchain and the second blockchain.

[0060] The executor is responsible for executing cross-chain transactions off-chain and submitting the transaction execution results to the smart contract on the blockchain. Figure 1 In the illustrated scenario, the executor responds to the user's cross-chain transaction request to execute the cross-chain transaction off-chain, generates the transaction execution result and submits it to the first blockchain and the second blockchain.

[0061] The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on the corresponding blockchain according to the transaction execution result.

[0062] The validator is responsible for off-chain verification of the transaction execution results submitted by the executor, and challenges the transaction execution results during the challenge period. If the transaction execution results are not challenged by the validator during the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0063] In a more preferred implementation, a reward and punishment mechanism can be set up for the executor and the verifier. When a transaction challenged by the verifier is verified to be invalid or illegal, the challenge is deemed successful, and the verifier can receive incentives and the executor will be punished, and vice versa.

[0064] A more preferred implementation method may require all executors and validators to pledge assets before they can serve, and they can receive dividends from the earnings of the contract platform based on the amount of pledged assets. When a challenge occurs, the malicious or dishonest party in the challenge will be arbitrated by the smart contract, and all assets of the malicious or dishonest party will be frozen by the contract. If the validator successfully challenges the incorrect result, he will receive the malicious party's assets as an incentive.

[0065] A more preferred implementation method, in order to ensure the correctness of the transaction execution process, can require the executor and each validator to run the light client of all underlying blockchains, synchronize all blockchain data and listen to the status updates on the smart contract. In this way, the executor and validator can obtain the status update information on the blockchain in a timely manner and obtain the block data of each chain for cross-chain transmission.

[0066] Since the verifier can obtain the block information of the blockchain associated with the transaction, it is usually a light node on one blockchain, which usually only stores the block header information. In a more preferred implementation mode, the verifier can also be a shared node of multiple blockchains.

[0067] The user is the party that holds token assets and has transaction needs. He creates an account by depositing tokens into the smart contract on the chain, and then submits the cross-chain transaction to the executor to complete the cross-chain transaction execution.

[0068] In terms of examples, the following design is proposed for the smart contract (Rollup contract) with optimistic execution mechanism on the chain:

[0069] (1) Account management: Manage token accounts of different users. Tokens of different chains are managed by their respective Rollup contracts. When a cross-chain transaction is not confirmed, the Rollup contract will lock the account funds involved in the cross-chain transaction.

[0070] (2) System member management: manage all executors and verifiers. Only executors and verifiers can call functions such as execution result submission and challenge. At the same time, malicious verifiers and malicious executors that are identified are continuously removed from the system.

[0071] (3) Commitment submission: allows the executor to submit the execution results of a batch of transactions as a commitment at one time. The contract manages commitments in the form of a list and updates the account status based on the execution results contained in the commitment.

[0072] (4) Execution Verification: Allows the verifier to challenge the correctness of a transaction execution result, and the contract will re-execute the transaction on the chain to complete the verification. If the execution result is correct, the verifier who initiated the challenge will be considered a malicious attacker and removed from the system; if the execution result is incorrect, or there is an illegal transaction in the transaction (for example, an illegal signature), then the executor who submitted the transaction execution result will be removed from the system, and the contract can select a new executor from all verifiers.

[0073] (5) Consistency verification: allows validators to challenge inconsistent commitments on different blockchains. In this process, the validator needs to submit a legitimate block and its proof from another blockchain as a basis. Then, based on this cross-chain block information, the Rollup contract can verify whether the commitment data on the two blockchains is consistent. If consistent, the contract punishes the validator who initiated the challenge, otherwise it punishes the executor who submitted the commitment.

[0074] (6) Cross-chain block verification function: This function allows the Rollup contract to verify the legitimacy of a cross-chain block based on the information submitted by the verifier. In various embodiments of the present invention, the verification process is mainly implemented through zero-knowledge proof, and a verification method with lower verification overhead is proposed.

[0075] Based on the blockchain systems proposed in the above embodiments, the blockchain cross-chain transaction method proposed in the present invention will be introduced below.

[0076] See also Figure 2 An embodiment of the present invention provides a blockchain cross-chain transaction method, comprising the following steps:

[0077] Step S210. The executor executes the cross-chain transaction off-chain in response to the user's cross-chain transaction request, generates a transaction execution result and submits it to the first blockchain and the second blockchain. The cross-chain transaction request includes the user performing a cross-chain transaction between the first blockchain and the second blockchain.

[0078] In this step, the execution of cross-chain transactions is based on the optimistic execution mechanism. The executor completes the transaction execution and generates the transaction execution result off-chain, and submits it to the blockchain associated with the cross-chain transaction. The cross-chain transaction mentioned here can be the transfer of assets between accounts created by the same user on different chains, or the transfer of assets between different users on different chains. For example, user U can create accounts on both chains L1 and L2 and transfer assets between the two accounts; or users U and V can belong to different chains and transfer assets.

[0079] Step S220. The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on their respective blockchains according to the transaction execution result.

[0080] In this step, based on the optimistic execution mechanism, the transaction execution results are synchronized to the first blockchain and the second blockchain at the same time, and the smart contracts on the two chains can update the account status of the accounts associated with the transaction on their respective chains according to the received transaction execution results.

[0081] Specifically, if a cross-chain transaction is conducted in the form of tokens, before the cross-chain transaction is finalized, the tokens in the input account are directly consumed, and the newly added tokens in the output account are locked. When the transaction execution result is deemed valid, the newly added tokens are unlocked and the transaction is successfully executed.

[0082] Step S230: If the transaction execution result is not challenged by the verifier during the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0083] In this step, the optimistic execution mechanism allows the validator to challenge the transaction during the challenge period. Since the account status of the Rollup contract is public and the transaction execution result includes complete transaction data and execution result data, the validator can execute transactions and verify transaction execution results off-chain to verify the validity of the execution results and the consistency of cross-chain account status.

[0084] In a further embodiment, only challenges initiated during the challenge period will be accepted. The system allows any validator to initiate a challenge individually during the challenge period. A successful challenge will incentivize the validator, and the validator's challenge does not need to reach a consensus within a committee composed of multiple validators, which will cause the security of the system to rely on the honesty of the majority of the committee. Malicious validators can also initiate challenges, but their malicious challenges cannot be verified by the Rollup contract, so they will be arbitrated as malicious challengers. Malicious challengers will have all their collateral assets frozen and removed from the committee. This design is to ensure that even if most of the validators in the committee are malicious or controlled, honest validators can maintain the security of the system by initiating challenges alone.

[0085] In a further embodiment, the transaction verification includes execution verification, and the execution verification includes the following steps:

[0086] The verifier verifies the validity of the transaction execution result off-chain, and initiates an execution challenge request to the first blockchain if the verification fails;

[0087] The first smart contract deployed on the first blockchain responds to the execution challenge request and verifies the validity of the transaction execution result. If there is invalid information in the transaction execution result, the verification fails. The first smart contract restores the account status of the user account associated with the cross-chain transaction on the first blockchain to the state before the update, and generates a transaction withdrawal result corresponding to the transaction execution result;

[0088] The first smart contract sends the transaction withdrawal result to the executor and the verifier.

[0089] Examples include Figure 2 As shown, the transaction execution result is in the form of commitment c i On-chain, the verifier executes the transaction off-chain and considers the commitment c i If there is an execution error, such as a transaction including an invalid signature of a user, an execution challenge request is initiated to chain L1. The Rollup contract deployed on the first blockchain responds to the execution challenge request and re-executes the transaction, i.e., performs a validity verification. If an execution error such as an invalid signature is identified, the account status is rolled back, i.e., the balance of the transaction is revoked by the commitment c i The user account status is updated as a result of the transaction execution, and a withdrawal record is generated, which is recorded as an invalid commitment c i ', the transaction withdrawal result will be used as the basis for subsequent consistency verification. If the transaction execution is valid, that is, the challenge is unsuccessful, the verifier is considered malicious and punished. Finally, the verification result is sent to the executor and the verifier.

[0090] A more preferred embodiment is to invalidate the commitment c i 'You can modify the original commitment c i The preset status field in is generated.

[0091] Since all data on the blockchain is stored in the form of Merkel trees, invalid commitments can be i ' or the original promise c i Generate a Merkel proof. As long as the Rollup contract on another blockchain L2 has the latest block of chain L1, it can use the state tree root in the block header to verify this proof and obtain the real c i ' and c i Based on this data, the Rollup contract on chain L2 can verify the commitment c i Cross-chain consistency. If the c in the proof i If it is inconsistent with the commitment stored in the contract on chain L2, then the Rollup contract on chain L2 can confirm the commitment c i If there is a cross-chain inconsistency, the account status will be rolled back.

[0092] When the second blockchain is used as the input account party, its input list does not have the account on the first blockchain, so the smart contract on the second blockchain cannot detect the illegality of the account signature on the first blockchain. In order to ensure the consistency of the Rollup contracts on the two chains, the verifier needs to initiate a consistency challenge and provide an invalid commitment c iThe Merkel proof proves to the Rollup contract of chain L2 that the account status on chain L1 has been withdrawn. The Rollup contract of chain L2 will withdraw its account status only after confirming that there is a cross-chain inconsistency.

[0093] In a specific embodiment, Figure 3 As shown, when consistency verification needs to be initiated due to cross-chain inconsistency caused by verification execution, the following steps are included:

[0094] The validator sends the cross-chain proof to the second blockchain L2 and the latest block information blkH1 of the first blockchain L1, where the cross-chain proof is generated based on the latest block information of the first blockchain, and the inconsistency proof is generated based on the transaction withdrawal result Send to the second blockchain L2, and initiate an inconsistency challenge request to the second blockchain L2;

[0095] The Rollup contract deployed on the second blockchain L2 responds to the inconsistency challenge request, verifies the legitimacy of the latest block information of the first blockchain using the cross-chain proof, adds the latest block information of the first blockchain to the cross-chain block list when the verification passes, and obtains the transaction retraction result using the inconsistency proof. Based on the transaction retraction result, the account status of the user account associated with the cross-chain transaction on the second blockchain is restored to the state before the update.

[0096] A more preferred embodiment, inconsistency proof It can be an invalid commitment c generated based on the state root in block blkH1 i ' Merkel proof. The Merkel proof contains c i 'The original data and the intermediate hash value required for proof verification. The Rollup contract on chain L2 can judge the invalid commitment c on chain L1 based on this proof. i 'Whether it is true, specifically includes the following steps:

[0097] Get the latest state root tRoot from the latest block information of the first blockchain;

[0098] Use the latest state root to verify the legitimacy of the inconsistent proof, that is, verify that tRoot=hash(h n ,hash(...,hash(h2,hash(h1,c i ')))), when verification passes, from the invalid promise c i 'Get c from Merkel's proof i ', compare c i ' and chain L2 storage commitment c iWhether they are consistent, that is, comparing the transaction withdrawal result and the stored transaction execution result, specifically comparing whether the verification information in the two commitments is consistent. If they are consistent, it means that the inconsistency proof is valid. According to the comparison result, the account status of the user account associated with the cross-chain transaction on the second blockchain can be restored to the state before the update. By identifying the commitment c of the current chain i and chain L1 has been withdrawn and the invalid commitment c generated i ', thereby reversing the account status of the associated account on the current chain, so that the committed status of chains L1 and L2 can be restored to consistency.

[0099] In addition to being triggered by the account status on one chain being withdrawn due to execution verification failure, consistency verification can also be triggered by the executor submitting inconsistent transaction execution results on different chains, such as commitments with the same index but different content, or a transaction execution result not being synchronized to all blockchains associated with cross-chain transactions. Therefore, consistency verification is not necessarily initiated only when execution verification fails, and can also be initiated by the verifier alone when execution verification is not initiated. In a more preferred implementation, this separately initiated consistency verification includes the following steps:

[0100] The verifier obtains the first transaction execution result on the first blockchain and the second transaction execution result on the second blockchain respectively, compares whether the first transaction execution result and the second transaction execution result are consistent, obtains the latest block information of the first blockchain if they are inconsistent, generates an inconsistency proof using the latest block information of the first blockchain and sends it to the second blockchain, and issues an inconsistency challenge request to the second blockchain;

[0101] The second smart contract deployed on the second blockchain responds to the inconsistency challenge request and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update based on the inconsistency proof.

[0102] In a more preferred embodiment, the aforementioned cross-chain proof can use traditional zero-knowledge proof technology to construct a block proof with O(N) overhead, or it can be the following binary interactive verification process proposed by the present invention.

[0103] For a blockchain such as a Rollup contract on L1, the traditional zero-knowledge proof technology assumes that the last valid block header received from chain L2 is blkH x , define the block header to be verified as blkH r Assume blkH r and blkH x There are N-1 blocks between them, and the verification goal is to prove blkH r It is blkH in chain L2 x The Nth successor block header of . The workflow is as follows: The prover uploads the candidate block header blkHr In a period of controversy If a challenger blocks blkH r Initiate a challenge, the prover needs to provide a cross-chain proof to the Rollup contract In response. Rollup contract verification , to reject invalid blkH r If blkH r exist If it is not rejected, it will be added to the cross-chain block list H.

[0104] Specifically, when the binary interactive verification process proposed by the present invention is used as a cross-chain proof, it is an abstract proof concept, that is, if a block cannot be proven invalid within the challenge period, it is considered valid. The binary interactive verification process proposed by the present invention continuously divides the verification problem into two until only one zero-knowledge proof is required to complete the verification, including the following steps:

[0105] Determine the xth block of the first blockchain, the latest block of the first blockchain is the rth block, wherein the xth block is a block that does not require validity verification, the rth block is the Nth successor block of the xth block, and there are N-1 blocks between the rth block and the xth block;

[0106] Verifying the validity of the rth block is equivalent to verifying the validity of the N subsequent blocks of the xth block, and the following binary interactive verification process is performed:

[0107] The first smart contract provides the validator with the hash value of the x+N / 2th block for validity verification. If the verification is successful, the validity of the blocks between the x+N / 2th block and the rth block is verified. Otherwise, the validity of the blocks between the xth block and the x+N / 2th block is verified. The binary verification process is repeated until the N subsequent blocks cannot be binary-divided.

[0108] The verifier generates a cross-chain proof based on the verification results of the binary interactive verification process.

[0109] Example aspects, such as Figure 4 As shown in the first stage, the questioner's block header blkH r Initiate a challenge. The Rollup contract creates a record for this verification. At this stage, blkH rThe verification problem can be equivalent to blkH[x:x+N], which requires N zero-knowledge proofs. In each round of the second phase, the validator provides the Rollup contract with the hash value of the intermediate block header blkH{x+N / 2}, and the questioner responds with a Boolean value ack to indicate whether it recognizes the validity of blkH{x+N / 2}. If ack is true (True), the verification problem is reduced to the second half blkH[x+N / 2:x+N]; otherwise, it is reduced to the first half blkH[x:x+N / 2]. In this way, the relayer and the questioner reach a consensus on the validity of the other half of the block header and divide the verification problem into two parts. The binary interaction continues until the problem is reduced to blkH[y:y+1], at which point only one zero-knowledge proof is required. In the third phase, the validator provides a BCP proof for blkH{y+1} , Includes a zero-knowledge proof that blkH{y+1} is signed by the consensus committee selected by blkH{y}. Invalid, the Rollup contract will reject block blkH r In a more preferred embodiment, in order to prevent collusion between relayers and challengers, other validators are allowed to challenge the same block head during this process.

[0110] In this process, The zero-knowledge proof in is a proof of block signature. Since each block signed by the majority of validators in the PBFT and PoS protocols can be regarded as a legal block, the legitimacy of the block can be verified by completing the signature verification using zero-knowledge proof. In this verification process, the significance of zero-knowledge proof is to reduce the cost of proof verification and increase the cost of attack.

[0111] In order to further illustrate the blockchain cross-chain transaction method proposed in the present invention, a specific scenario is introduced below.

[0112] User U exchanges tokens between chains L1 and L2, using 3 A tokens from account acc1 on chain L1 to exchange 4 B tokens from account acc2 on chain L2. acc1 is user U's account on L1, and acc2 is U's account on L2.

[0113] like Figure 5As shown in the figure, in the optimistic scenario, that is, no one initiates a transaction challenge, user U first deposits 3 A tokens into the Rollup contract on chain L1, and sends a cross-chain transaction Tx representing the token exchange to the executor. Next, the executor verifies and executes the cross-chain transaction, and submits the transaction data and execution results as a commitment to the Rollup contracts on L1 and L2. A commitment usually packages the execution results of multiple transactions and uploads them together. The submitted commitment will lock the tokens that need to be exchanged for transaction Tx in the Rollup contracts on L1 and L2. If no challenge is received during the dispute period, the Rollup contracts on chains L1 and L2 will confirm the commitment and unlock the exchanged tokens. Subsequently, user U can withdraw the 4 B tokens that he has completed the exchange from the Rollup contract on chain L2.

[0114] like Figure 6 As shown, if the execution result submitted by the executor is wrong or the verifier is malicious, the transaction execution result may be challenged and trigger the account status update withdrawal. This embodiment stipulates that when the commitment is invalid or there is an inconsistency between the commitments submitted to the blockchain L1 and L2 (meaning that the atomicity is destroyed), the verifier can use the Rollup contract to initiate a challenge. The Rollup contract will arbitrate the challenge according to the cross-chain verification mechanism described in the previous embodiment. A successful challenge will trigger the account status withdrawal, restoring the account status to the result before the transaction, while a failed challenge will be rejected.

[0115] Specifically, Figure 7 As shown in the figure, during optimistic execution, the cross-chain transaction Tx for token exchange is submitted to the executor. The executor first packages the transaction Tx into a set Txs i and execute Txs i , generate the execution result Res i , which contains the updated status of the relevant accounts on each blockchain. For example, Res i =[acc1:-3,acc2:+4] means that account acc1 consumes 3 tokens, while account acc2 receives 4 tokens. In order to submit the execution result, the executor calls the commitment submission function of the Rollup contract on chains L1 and L2, and sends Txs i and Res i As a new promise c i Upload, the Rollup contracts on the two chains will c i Add to Commitment List C and according to Res i Update token status.

[0116] In this process, the tokens in the input account In are consumed directly, while the newly generated output tokens in the cross-chain output account Out are locked. iIf it is not challenged within the challenge period ∆ch, the Rollup contract will commit to c i The transaction Tx is deemed valid and unlocks the corresponding output tokens.

[0117] Figure 8 This shows the execution verification and consistency verification caused by the invalid signature of account acc1, in order to withdraw c on chain L1. i The user account status is updated by all transaction execution results. The verifier can call the execution challenge interface of the Rollup contract on L1. After receiving the challenge, the Rollup contract verifies the Res i The Rollup contract of chain L1 starts to withdraw the account status and generates an invalid commitment c i '. The original commit c can be modified by i This record will be used as the basis for consistency proof in subsequent consistency challenges.

[0118] Since all data on the blockchain is stored in the form of Merkel trees, invalid commitments c i ' or the original promise c i Generate a Merkel proof. As long as the Rollup contract on chain L2 has the latest block of chain L1, it can use the state tree root in the block header to verify this proof and obtain the real c i ' and c i Based on this data, the Rollup contract on L2 can verify the commitment c i If the commitment in the proof matches the commitment c stored in the current contract i If inconsistent, the Rollup contract of chain L2 can confirm the commitment c corresponding to transaction Tx i There is a cross-chain inconsistency, and the withdrawal is due to the commitment c i Resulting in an account status update.

[0119] The inconsistent verification in this embodiment is due to the fact that the commitment on chain L1 has changed due to the failure of the execution verification. In order to maintain the consistency of the commitments on the two chains, the verifier provides an invalid commitment c i Merkel proof of L1 to prove the L2 Rollup contract i It has been updated, and the Rollup contract of chain L2 also performs account status update and withdrawal after confirming the cross-chain inconsistency. Please refer to the corresponding parts described in the above embodiments for details, which will not be repeated here.

[0120] Through the above links, the present invention provides a cross-chain transaction architecture for blockchains, where the executor is responsible for off-chain execution and submitting execution results, and the verifier is responsible for ensuring the correctness of the transaction execution process. Since the verifier will only generate cross-chain proofs for blocks when a consistency challenge occurs, , which only needs to include one zero-knowledge proof, greatly reducing the verification overhead. The method proposed in the present invention introduces an optimistic execution mechanism and designs a Rollup contract execution framework. Even when the throughput of the blockchain itself is limited, it can achieve a cross-chain transaction throughput several times that of the blockchain throughput. Compared with the design of the traditional zero-knowledge proof bridge, each cross-chain transaction needs to be executed on the chain. The cross-chain transaction execution framework proposed in the present invention has higher performance and stronger scalability. Secondly, the transaction verification mechanism ensures that the correctness of the operation can be ensured as long as there is an honest verifier. If the attacker wants to control the entire system, he needs to attack all the verifiers, while the traditional notarization-based bridge only needs to attack more than half or 2 / 3 of the verifiers. Therefore, the security of the present invention is high. In a further implementation method, the present invention proposes a binary interactive verification method, which uses the binary method to reduce the verification problem of the block until only one zero-knowledge proof is required, reducing the verification overhead to O(1). In the optimistic case, no cross-chain verification is required, which can significantly reduce the verification cost of the system.

[0121] The implementation principle and technical effects of the device provided in the embodiments of the present application are the same as those of the aforementioned method embodiments. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiments.

[0122] The methods and related devices mentioned in the above embodiments are described with reference to the method flow charts and / or structural diagrams provided in the embodiments of the present application. Specifically, each process and / or block in the method flow charts and / or structural diagrams, as well as the combination of processes and / or blocks in the flow charts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A flow or multiple flows and / or structures illustrate the steps of the functions specified in one block or multiple blocks.

[0123] The following embodiments are described by taking the method applied to a computer device as an example. It can be understood that the computer device can be any device with computing and processing functions, and can be but not limited to a server or a personal laptop computer, etc. In one embodiment, the computer device can be an application server, and the application server can be a server for running an application to be tested.

[0124] See also Fig. 9 , which shows a hardware block diagram of an electronic device, the electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0125] like Fig. 9 As shown, the electronic device includes: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4;

[0126] In the embodiment of the present application, the number of the processor 1, the communication interface 2, the memory 3, and the communication bus 4 is at least one, and the processor 1, the communication interface 2, and the memory 3 communicate with each other through the communication bus 4;

[0127] The processor 1 may be a central processing unit CPU, or an application-specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present invention, etc.;

[0128] The memory 3 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), etc., such as at least one disk memory;

[0129] Among them, the memory stores a program, and the processor can call the program stored in the memory, and the program is used to: implement various processing processes of the aforementioned blockchain cross-chain transactions.

[0130] An embodiment of the present invention also provides a readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the various processing flows of the blockchain cross-chain transaction solution provided in the above embodiment and / or any possible implementation method in combination with the embodiment are implemented.

[0131] The above-mentioned embodiments have described the present invention in particular detail with respect to possible scenarios, and those skilled in the art will recognize that the present invention can be practiced through other embodiments. The specific naming of components, the capitalization of terms, attributes, data structures, or any other programming or structural aspects are not mandatory or important, and the mechanisms or features of the present invention may have different names, forms, or procedures. The system may be implemented by a combination of hardware and software (as described), entirely by hardware elements, or entirely by software elements. The specific division of functions between the various system components described herein is exemplary only and not mandatory; on the contrary, the functions performed by a single system component may be performed by multiple components, or the functions performed by multiple components may be performed by a single component.

[0132] Those skilled in the art should understand that the various steps of the above disclosed method can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, optionally, they can be implemented with program codes executable by the computing device, so that they can be stored in a storage device and executed by the computing device, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the embodiments of the present invention are not limited to any specific combination of hardware and software.

[0133] These computing device executable programs (also referred to as programs, software, software applications, or code) include machine instructions for programmable processors, and these computing programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0134] Certain aspects of the present invention include process steps and instructions described herein in the form of algorithms. It should be noted that the process steps and instructions of the present invention can be implemented in software, firmware and / or hardware, and when implemented by software, it can be downloaded, stored on different platforms used by various operating systems and operated from the platforms.

[0135] Those skilled in the art will understand that the structures shown in the accompanying drawings are merely block diagrams of partial structures related to the scheme of the present application, and do not constitute a limitation on the terminal device to which the scheme of the present application is applied. The specific terminal device may include more or fewer components than shown in the figures, or combine certain components, or have a different arrangement of components.

[0136] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "possible design" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0137] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0138] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain cross-chain transaction method, characterized in that: include: The executor executes the cross-chain transaction off-chain in response to the cross-chain transaction request of the user, generates a transaction execution result and submits it to the first blockchain and the second blockchain, wherein the cross-chain transaction request includes the user performing a cross-chain transaction between the first blockchain and the second blockchain; The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on their respective blockchains according to the transaction execution result; If the transaction execution result is not challenged by the verifier during the challenge period, the corresponding cross-chain transaction is considered valid, otherwise transaction verification is performed.

2. The method according to claim 1, characterized in that: The transaction verification includes execution verification, and the execution verification includes: The verifier verifies the validity of the transaction execution result off-chain, and initiates an execution challenge request to the first blockchain if the verification fails; The first smart contract deployed on the first blockchain responds to the execution challenge request, verifies the validity of the transaction execution result, and restores the account status of the user account associated with the cross-chain transaction on the first blockchain to the state before the update when the verification fails, generates a transaction withdrawal result corresponding to the transaction execution result, and sends the transaction withdrawal result to the executor and the verifier.

3. The method according to claim 1, characterized in that The transaction verification includes consistency verification, and the consistency verification includes: The verifier obtains the first transaction execution result on the first blockchain and the second transaction execution result on the second blockchain respectively, compares whether the first transaction execution result and the second transaction execution result are consistent, obtains the latest block information of the first blockchain when they are inconsistent, generates an inconsistency proof using the latest block information of the first blockchain and sends it to the second blockchain, and submits an inconsistency challenge request to the second blockchain; The second smart contract deployed on the second blockchain responds to the inconsistency challenge request and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update based on the inconsistency proof.

4. The method according to claim 2, characterized in that: When the first smart contract fails to pass the validity verification of the transaction execution result in the execution verification, the transaction verification further includes consistency verification, and the consistency verification includes: The verifier sends the cross-chain proof and the latest block information of the first blockchain to the second blockchain, the cross-chain proof is generated according to the latest block information of the first blockchain, and generates an inconsistency proof according to the transaction withdrawal result and sends it to the second blockchain, initiating an inconsistency challenge request; The second smart contract deployed on the second blockchain responds to the inconsistency challenge request, verifies the latest block information of the first blockchain by using the cross-chain proof, adds the latest block information of the first blockchain to the cross-chain block list when the verification passes, obtains the transaction retraction result by using the inconsistency proof, and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction retraction result.

5. The method according to claim 4, characterized in that The second smart contract uses the inconsistency proof to obtain the transaction withdrawal result, and restores the account status of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction withdrawal result, including: Obtain the latest state root from the latest block information of the first blockchain; The latest state root is used to verify the legitimacy of the inconsistency proof. When the verification passes, the inconsistency proof is used to obtain the transaction withdrawal result, the transaction withdrawal result is compared with the stored transaction execution result to generate a comparison result, and the account status of the user account associated with the cross-chain transaction on the second blockchain is restored to the state before the update according to the comparison result.

6. The method according to claim 2, characterized in that The generation of the transaction withdrawal result includes: The first smart contract modifies a preset status field in the transaction execution result to obtain a transaction withdrawal result.

7. The method according to claim 4, characterized in that The generation of the cross-chain proof includes: Determine the xth block of the first blockchain, the latest block of the first blockchain is the rth block, wherein the xth block is a block that does not require validity verification, the rth block is the Nth successor block of the xth block, and there are N-1 blocks between the rth block and the xth block; Verifying the validity of the rth block is equivalent to verifying the validity of the N subsequent blocks of the xth block, and the following binary interactive verification process is performed: The first smart contract provides the validator with the hash value of the x+N / 2th block for validity verification. If the verification is successful, the validity of the blocks between the x+N / 2th block and the rth block is verified. Otherwise, the validity of the blocks between the xth block and the x+N / 2th block is verified. The binary verification process is repeated until N subsequent blocks cannot be binary-divided, and the verifier generates a cross-chain proof based on the verification result of the binary interactive verification process.

8. A blockchain transaction system, characterized in that: Includes a first blockchain, a second blockchain, an executor, a validator, and a user; A first smart contract and a second smart contract are deployed on the first blockchain and the second blockchain respectively, and the user performs a cross-chain transaction between the first blockchain and the second blockchain; The executor is used to respond to the user's cross-chain transaction request to execute the cross-chain transaction off-chain, generate the transaction execution result and submit it to the first blockchain and the second blockchain; The first smart contract and the second smart contract respectively deployed on the first blockchain and the second blockchain update the account status of the user account associated with the cross-chain transaction on their respective blockchains according to the transaction execution result; The verifier challenges the transaction execution result within the challenge period. If the transaction execution result is not challenged by the verifier within the challenge period, the corresponding cross-chain transaction is considered valid, otherwise transaction verification is performed.

9. An electronic device, characterized in that: including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement the blockchain cross-chain transaction method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the cross-chain transaction method as described in any one of claims 1 to 7 is implemented.

Images