Blockchain cross-chain transaction data processing method and system

Abstract

The application discloses a kind of blockchain cross-chain transaction methods, cross-chain transaction between two and more blockchain of user follows optimistic execution mechanism, transaction is executed by executor off-chain, zero-knowledge proof is not needed to be generated for each block, only when transaction is challenged, it is generated, and transaction execution result is stored to chain;When transaction is challenged, cross-chain transaction verification is carried out by the smart contract on the chain, specifically including execution verification and inconsistency verification, the method proposed in the application verifies transaction itself, belongs to direct verification, when transaction verification fails, the account state of the account associated with the chain is withdrawn to update, guarantee the safety of system transaction execution;The transaction method proposed in the application does not need to execute transaction on the chain due to the adoption of optimistic execution mechanism, compared with prior art, has higher throughput, and is more scalable.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of cross-chain transactions, and particularly relates to a blockchain cross-chain transaction data processing method and system. BACKGROUND

[0002] As a distributed ledger technology, the blockchain realizes decentralized data storage and management through a peer-to-peer network and a consensus mechanism, does not rely on a centralized entity, and at the same time guarantees the transparency and security of data, and has been widely applied to the innovation of fields such as finance and security. After that, the introduction of smart contract technology further expands the application boundary of the blockchain. The smart contract can automatically execute related operations when the preset conditions are met, and realize a trusted and efficient transaction process. With the rapid development of the blockchain network, the independent operation of each chain leads to the problem of information silos, and the transfer of digital currency between different chains, cross-chain collaboration of smart contracts and other needs cannot be directly met. Therefore, cross-chain communication and collaboration have become an important research direction of the blockchain technology.

[0003] The existing cross-chain transaction framework is mainly realized through chain bridge technology. As a connection mechanism between different blockchains, the chain bridge is mainly divided into two categories: notarized chain bridge and zero-knowledge proof-based chain bridge. The notarized chain bridge relies on a trusted third party or intermediary node. These entities are responsible for verifying the legality of cross-chain transactions and executing the transaction results on the target chain. This type of chain bridge is usually simple to implement and efficient, but its security depends on the trustworthiness of the notary party. If the notary party is attacked or behaves maliciously, it may result in the loss of cross-chain assets or data. The zero-knowledge proof-based chain bridge realizes low-cost cross-chain block data transmission through zero-knowledge proof, and completes the verification of cross-chain transactions based on cross-chain block data. This type of chain bridge eliminates the dependence on trusted intermediaries, significantly improving the privacy and security of cross-chain transactions. However, due to the complexity of the generation process of zero-knowledge proof, the running cost of the chain bridge is high, and the scalability is poor. SUMMARY

[0004] Based on this, the application aims to propose a blockchain cross-chain transaction data processing method and system, which improves the traditional zero-knowledge proof-based chain bridge based on the optimistic execution mechanism, proposes a new cross-chain transaction framework, and guarantees the security of transactions while improving the scalability of the chain bridge.

[0005] In a first aspect, the application proposes a blockchain cross-chain transaction data processing method, comprising:

[0006] 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, and the cross-chain transaction request includes the cross-chain transaction between the user in the first blockchain and the second blockchain;

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

[0008] The transaction execution result is not challenged by the verifier within the challenge period, and the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0009] Further, the transaction verification includes execution verification, and the 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 when the verification fails;

[0011] 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 state of the user account associated with the cross-chain transaction on the first blockchain to the state before the update when the verification fails, and generates a transaction rollback result corresponding to the transaction execution result;

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

[0013] Further, the transaction verification includes consistency verification, and the consistency verification 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 when the first transaction execution result and the second transaction execution result are inconsistent, generates an inconsistency proof using the latest block information of the first blockchain and sends it to the second blockchain, and initiates 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 state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the inconsistency proof.

[0016] Further, when the first smart contract fails to verify the validity of the transaction execution result in the execution verification, the transaction verification further includes consistency verification, and the consistency verification includes:

[0017] The verifier sends the cross-chain proof and the latest block information of the first blockchain to the second blockchain, wherein the cross-chain proof is generated according to the latest block information of the first blockchain, and the inconsistency proof is generated according to the transaction rollback result and sent to the second blockchain, and an inconsistency challenge request is initiated to the second blockchain;

[0018] The second smart contract deployed on the second blockchain responds to the inconsistency challenge request, verifies the legality 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 is passed, obtains the transaction rollback result by using the inconsistency proof, and restores the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction rollback result.

[0019] Further, the cross-chain proof is generated by using a zero-knowledge proof algorithm.

[0020] Further, the generation of the cross-chain proof comprises:

[0021] The xth block of the first blockchain is determined, and the latest block of the first blockchain is the rth block, wherein the xth block is a block that does not need to be verified for validity, 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 Nth successor block of the xth block, and the following binary interaction verification process is performed:

[0023] The first smart contract provides the hash value of the x+N / 2th block to the verifier for validity verification, and if the verification is passed, 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, and the binary verification process is repeated until the Nth successor block cannot be divided.

[0024] The verifier generates the cross-chain proof according to the verification result of the binary interaction verification process.

[0025] Further, the second smart contract obtains the transaction rollback result by using the inconsistency proof, and restores the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction rollback result, which comprises:

[0026] The latest state root is obtained from the latest block information of the first blockchain.

[0027] The legality of the inconsistency proof is verified by using the latest state root, and the transaction rollback result is obtained by using the inconsistency proof when the verification is passed, a comparison result is generated by comparing the transaction rollback result and the stored transaction execution result, and the account state 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.

[0028] Further, the generation of the transaction rollback result comprises:

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

[0030] Further, the verifier includes a light node on the first blockchain, and / or a shared node of the first blockchain and the second blockchain.

[0031] In a second aspect, the present application provides a blockchain cross-chain transaction data processing system, comprising a first blockchain, a second blockchain, an executor, a verifier and a user;

[0032] The first blockchain and the second blockchain respectively deploy a first smart contract and a second smart contract, and the user performs cross-chain transactions between the first blockchain and the second blockchain;

[0033] The executor is used to execute cross-chain transactions off-chain in response to the cross-chain transaction request of the user, generate transaction execution results and submit them 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 state of the user account associated with the cross-chain transaction on the blockchain according to the transaction execution results;

[0035] The verifier initiates a challenge to the transaction execution results within a challenge period, and when the transaction execution results are not challenged by the verifier within the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0036] Further, the verifier includes a light node on the first blockchain, and / or a shared node of the first blockchain and the second blockchain.

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

[0038] The memory is used to store a program;

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

[0040] In a fourth aspect, the present application provides a readable storage medium having a computer program stored thereon, and the computer program is executed by a processor to realize each step of the blockchain cross-chain transaction data processing method.

[0041] Compared with the existing cross-chain transaction data processing, the present application has the following beneficial effects:

[0042] The blockchain cross-chain transaction data processing method provided by the application is an improvement based on optimistic execution. In order to complete cross-chain transactions between two or more blockchains, zero-knowledge proof does not need to be generated for each block, but only when the transaction is challenged. The transaction is executed off-chain by the executor, and the transaction execution result can be packaged and stored on the chain. In a more specific implementation, when the transaction is challenged, the smart contract on the chain verifies the cross-chain transaction. Compared with the prior art, the transaction is endorsed by multiple verifiers to prove that the transaction is valid. The verification method provided by the application directly verifies the transaction itself, rather than indirectly verifying through endorsement. When the transaction verification fails, the account state of the associated account on the chain is withdrawn to the previous update, ensuring the safety of system transaction execution. The transaction method provided by the application adopts an optimistic execution mechanism, and does not need to execute the transaction on the chain. Compared with the prior art, it has higher throughput and stronger scalability. Secondly, the transaction verification mechanism can ensure the correctness of the system operation as long as one honest verifier initiates a challenge, which is safer than the traditional chain bridge framework. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only embodiments of the application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of the provided drawings.

[0044] Figure 1 It is a system architecture diagram for executing cross-chain transaction data processing provided by the embodiment of the application;

[0045] Figure 2 It is an implementation interaction diagram of a blockchain cross-chain transaction data processing method provided by the embodiment of the application;

[0046] Figure 3 It is a consistency verification interaction flowchart initiated by a verifier due to cross-chain inconsistency caused by verification provided by the embodiment of the application;

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

[0048] Figure 5 It is an account state change diagram for cross-chain transaction between chain L1 and L2 in an optimistic scenario provided by the embodiment of the application;

[0049] Figure 6 It is a diagram for challenging cross-chain transaction between chain L1 and L2 provided by the embodiment of the application;

[0050] Figure 7 is a specific schematic diagram of the smart contract provided by the embodiment of the present application for deploying on the chain L1 and L2 to execute cross-chain transactions in an optimistic scenario;

[0051] Figure 8 is a specific schematic diagram of the execution challenge and consistency challenge provided by the embodiment of the present application for cross-chain transactions between the chain L1 and L2;

[0052] Figure 9 The electronic device architecture diagram provided by the embodiment of the present application. DETAILED DESCRIPTION

[0053] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0054] The optimistic execution mechanism is an off-chain expansion scheme, and its core idea is to move the calculation and storage of a large number of transactions from the main chain to off-chain execution, while storing a minimized transaction summary and proof information on the main chain to ensure security and verifiability. By "packing" (Roll 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 complex verification processes 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 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, and directly adopts the execution result at the end of a dispute period. During the dispute period, if a verifier finds that the execution result is incorrect and initiates a challenge, the smart contract will re-execute the uploaded transactions and withdraw the incorrect result. In the optimistic case, all the results submitted by the executor are correct, and the system does not need to execute any transactions, greatly reducing the execution overhead of the system.

[0055] The traditional cross-chain transaction chain bridge technology based on zero-knowledge proof needs to construct a zero-knowledge proof for each block, in order to prove the validity of the latest block, the overhead is O(N), N represents the number of blocks between the last block completed cross-chain and the latest block. The principle is: since the existing zero-knowledge proof technology can only prove that one block is the legal subsequent block of another block, that is, it can only use a trusted block header blkH n to verify another block header blkH n+1the legality of the Rollup contract. Under the optimistic execution mechanism, if the Rollup contract wants to use the last completed cross-chain block blkH0 saved in the contract, it needs to verify the legality of the latest block blkH N and the legality of the blocks blkH1, blkH2, …, blkH N-1 , so the verification overhead is still O(N).

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

[0057] As shown in Figure 1 , it shows a blockchain cross-chain transaction data processing system proposed by an embodiment of the present application, which includes 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 the smart contract. In the following embodiments, only the cross-chain transaction between two blockchains is considered for ease of explanation. It is easy to understand that those skilled in the art can increase the number of blockchains for cross-chain transactions as needed.

[0059] The first smart contract and the second smart contract are respectively deployed on the first blockchain and the second blockchain, and the 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 transaction execution results to the smart contract on the blockchain. In Figure 1 the case shown, the executor executes cross-chain transactions off-chain in response to the user's cross-chain transaction request, generates transaction execution results, and submits them to the first blockchain and the second blockchain.

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

[0062] The verifier is responsible for verifying the transaction execution results submitted by the executor off-chain, and initiating a challenge to the transaction execution results within the challenge period. When the transaction execution results are not challenged by the verifier within the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed.

[0063] In a more preferred embodiment, an incentive and punishment mechanism can be set for the executor and the verifier. When the challenged transaction is verified to be invalid or illegal, it is considered a successful challenge, and the verifier can obtain an incentive, and the executor will be punished, and vice versa.

[0064] More preferably, all executors and verifiers must mortgage assets to be eligible to serve, and they can get a share of the revenue from the contract platform according to the amount of assets they mortgage. When a challenge occurs, the malicious or dishonest party in the challenge is arbitrated by the smart contract, and all the assets of the malicious or dishonest party are frozen by the contract. If the verifier successfully challenges the incorrect result, he will get the assets of the malicious party as an incentive.

[0065] More preferably, in order to ensure the correctness of the transaction execution process, the executor and each verifier must run a light client of all underlying blockchains, synchronize all blockchain data and listen to state updates on the smart contract. In this way, the executor and the verifier can obtain state update information on the blockchain in a timely manner and obtain 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-party blockchain, which usually only stores block header information, and more preferably the verifier can also be a shared node of multiple blockchains.

[0067] Users are parties that hold token assets and have transaction needs. They create accounts by depositing tokens into smart contracts on the chain, and then submit cross-chain transactions to the executor to complete cross-chain transaction execution.

[0068] In an example aspect, the following design is proposed for the smart contract of the optimistic execution mechanism on the chain (Rollup contract):

[0069] (1) Account management: manage different users' token accounts, and different chains' tokens are managed by different chains' 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, and at the same time, continuously remove malicious verifiers and malicious executors from the system.

[0071] (3) Commitment submission: allow the executor to submit a batch of execution results as a commitment at a time, and the contract manages the commitment in the form of a list, and updates the account state according to the execution results contained in the commitment.

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

[0073] (5) Consistency verification: allow a verifier to challenge the inconsistency of commitments on different blockchains. In this process, the verifier needs to submit a legal block from another blockchain and its proof as the 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 verifier who initiates the challenge, otherwise, the executor who submits the commitment is punished.

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

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

[0076] Referring to Figure 2 , an embodiment of the present application proposes a blockchain cross-chain transaction data processing method, comprising the following steps:

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

[0078] In this step, the execution of the cross-chain transaction is based on the optimistic execution mechanism, and the executor completes the transaction execution off-chain and generates a transaction execution result, and submits it to the blockchain associated with the cross-chain transaction. The cross-chain transaction mentioned here can be asset transfer between accounts created by the same user on different chains, or asset transfer between different users on different chains. For example, user U can create accounts on chains L1 and L2, and transfer assets between the two accounts; or users U and V 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 state of the user account associated with the cross-chain transaction on the blockchain to which the transaction execution result belongs.

[0080] In this step, based on the optimistic execution mechanism, the transaction execution result is simultaneously synchronized to the first blockchain and the second blockchain, and the smart contracts on the two chains can update the account state of the account associated with the transaction on their respective chains according to the received transaction execution result.

[0081] Specifically, if the cross-chain transaction is in the form of tokens, the tokens of the input account are directly consumed before the cross-chain transaction is finally determined, the newly added tokens in the output account are locked, the newly added tokens are unlocked when the transaction execution result is considered valid, and the transaction is successfully executed.

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

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

[0084] In further embodiments, only challenges initiated within the challenge period are accepted, the system allows any verifier to independently initiate a challenge within the challenge period, a successful challenge will give the verifier an incentive, and the challenge of the verifier does not need to be consensus within the committee composed of multiple verifiers, which will lead to the security of the system depending on the honesty of the majority of the committee. Malicious verifiers can also initiate challenges, but their malicious challenges cannot pass the verification of the Rollup contract, so they will be arbitrated as malicious challengers. Malicious challengers will be frozen all the collateral assets and removed from the committee. This design is to ensure that even if the majority of the verifiers in the committee are malicious or controlled, honest verifiers can maintain the security of the system by independently initiating challenges.

[0085] In further embodiments, the transaction verification includes execution verification, which 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, verifies the validity of the transaction execution result, and if there is invalid information in the transaction execution result, the verification fails, the first smart contract restores the account state of the user account associated with the cross-chain transaction on the first blockchain to the state before the update, and generates a transaction rollback result corresponding to the transaction execution result;

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

[0089] An example aspect is as shown in Figure 2 The transaction execution result is in the form of a commitment c i The verifier believes that the commitment c i has an execution error after executing the transaction off-chain, for example, the transaction includes an invalid signature of the user, and initiates an execution challenge request to the chain L1. The Rollup contract deployed on the first blockchain responds to the execution challenge request to re-execute the transaction, that is, to perform a validity verification, and if an execution error such as an invalid signature is identified, to perform an account state rollback, that is, to withdraw the user account state update caused by the transaction execution result in the commitment c i , and generate a rollback record, denoted as an invalid commitment c i ’ which will serve 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 is punished. Finally, the verification result is sent to the executor and the verifier.

[0090] In a more preferred embodiment, the invalid commitment c i ’ can be generated by modifying the preset state field in the original commitment c i .

[0091] Since all data on the blockchain is stored in the form of a Merkel tree, a Merkel proof can be generated for the invalid commitment c i ’ or the original commitment c i . The Rollup contract on another blockchain L2 can use the state tree root in the block header to verify this proof and obtain the real data of c i ’ and c i if it has the latest block of chain L1. Based on this data, the Rollup contract on chain L2 can verify the cross-chain consistency of the commitment c i . If the c i in the proof is inconsistent with the commitment stored by the contract on chain L2, the Rollup contract on chain L2 can confirm that the commitment c i has cross-chain inconsistency and perform a rollback on its account state.

[0092] When the second blockchain acts as the input account holder, its input list does not contain accounts from the first blockchain. Therefore, the smart contract on the second blockchain cannot detect the invalidity of the account signature on the first blockchain. To ensure the consistency of the Rollup contract on both chains, the validator needs to initiate a consistency challenge and provide an invalid commitment. i The Merkel proof to the Rollup contract of chain L2 proves that the account state on chain L1 has been rolled back. The Rollup contract of chain L2 will only roll back its account state after confirming the cross-chain inconsistency.

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

[0094] The validator sends cross-chain proof π to the second blockchain L2. cross The latest block information blkH1 of the first blockchain L1 is used, 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 reversal results. con Send to the second blockchain L2 to 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, uses cross-chain proof to verify the legality of the latest block information of the first blockchain, adds the latest block information of the first blockchain to the cross-chain block list when the verification is successful, uses inconsistency proof to obtain the transaction rollback 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 based on the transaction rollback result.

[0096] A more preferred implementation method, proof of inconsistency π con It could be an invalid commitment c generated based on the state root in block blkH1. i The Merekl proof contains c i The original data and the intermediate hash value required for proof verification are used by the Rollup contract on chain L2 to determine the invalid commitment c on chain L1. i Whether it is true or not, the specific steps include the following:

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

[0098] The validity of the inconsistent proof is verified using the latest state root, i.e., verifying tRoot = hash(h n ,hash(...,hash(h2,hash(h1,c i ')))), when verification passes, remove invalid commitment ci Merkel proof of c i c i and the commitment c i stored in chain L2 are consistent, i.e. comparing the transaction rollback result and the stored transaction execution result, specifically comparing whether the verification information in the two commitments is consistent, if consistent, it means that the inconsistency proof is valid, and the account state of the user account associated with the cross-chain transaction on the second blockchain can be restored to the state before the update according to the comparison result, by identifying the inconsistency between the commitment c i of the current chain and the invalid commitment c i generated by rolling back chain L1, thereby rolling back the account state of the associated account on the current chain, so that the commitment states of chains L1 and L2 are restored to consistency.

[0099] In addition to being triggered due to the execution verification not passing, the consistency verification can also be triggered due to 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 cross-chain transaction associated blockchains, therefore, the consistency verification does not necessarily have to be initiated only when the execution verification does not pass, but can also be initiated independently by the verifier without initiating the execution verification. In a more preferred embodiment, such independently 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, and compares whether the first transaction execution result and the second transaction execution result are consistent, if not, obtains the latest block information of the first blockchain, 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;

[0101] The second smart contract deployed on the second blockchain responds to the inconsistency challenge request and restores the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to 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 the following two-way interactive verification process proposed by the present application.

[0103] Traditional zero-knowledge proof technology for a Rollup contract on a blockchain such as L1, assuming that the last valid block header received from chain L2 is blkH x , defines the block header to be verified as blkH r . Assuming blkH r and blkH xThere are N-1 blocks between the xth block and the rth block, and the verification target is to prove that blkH r is the Nth successor block header of blkH x in chain L2. The workflow is as follows: the prover uploads the candidate block header blkH r , and within a dispute period Δcross, if a challenger initiates a challenge to the block blkH r , the prover needs to provide a cross-chain proof π cross to the Rollup contract in response. The Rollup contract verifies π cross to reject invalid blkH r . If blkH r is not rejected after Δcross, it will be added to the cross-chain block list H.

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

[0105] determining the xth block of the first blockchain, the latest block of the first blockchain being the rth block, wherein the xth block is a block that does not require validity verification, and 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] equivalent to verifying the validity of the rth block, the following binary interactive verification process is performed:

[0107] The first smart contract provides the hash value of the x+N / 2th block to the verifier for validity verification. If the verification is passed, 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, and the binary verification process is repeated until the N successor blocks cannot be divided;

[0108] The verifier generates a cross-chain proof according to the verification result of the binary interactive verification process.

[0109] As shown in the example aspect, Figure 4 in the first stage, the challenger initiates a challenge to the block header blkH r . The Rollup contract creates a record for the verification. In 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 verifier provides the hash value of the intermediate position block header blkH{x+N / 2} to the Rollup contract, and the challenger responds with a Boolean value ack indicating whether it approves the validity of blkH{x+N / 2}. If ack is 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 challenger reach a consensus on the validity of the other half of the block header and divide the verification problem into two parts. The bisection 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 verifier provides a BCP proof π bcp for blkH{y+1} bcp , which includes a zero-knowledge proof that blkH{y+1} is signed by the consensus committee selected from blkH{y}. If π bcp is invalid, the Rollup contract will reject the block blkH r . In a more preferred embodiment, to prevent collusion between the relayer and the challenger, other verifiers are allowed to challenge the same block header during this process.

[0110] In this process, the zero-knowledge proof in π bcp is a proof of block signature. Since each block signed by a majority of verifiers in the PBFT and PoS protocols can be considered a legal block, the legality of the block can be verified as long as the signature verification is completed using a zero-knowledge proof. In this verification process, the significance of the zero-knowledge proof lies in reducing the proof verification overhead and increasing the cost of attacks.

[0111] To further illustrate the blockchain cross-chain transaction method proposed by the present application, a specific scenario is introduced below.

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

[0113] As Figure 5As shown, in an optimistic scenario where no one initiates a challenge, user U first deposits 3 A tokens into the Rollup contract on chain L1 and sends a cross-chain transaction Tx representing a token exchange to the executor. The executor then verifies and executes the cross-chain transaction, submitting the transaction data and execution result as a commitment to the Rollup contracts on L1 and L2. A commitment typically packages the execution results of multiple transactions together and the submitted commitment locks the tokens to be exchanged in transaction Tx within 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. User U can then withdraw the 4 B tokens they have exchanged from the Rollup contract on chain L2.

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

[0115] Specifically, such as Figure 7 As shown, during optimistic execution, the cross-chain transaction Tx that performs the token swap is submitted to the executor. The executor first packages the transaction Tx into a set Txs. i In, and execute Txs i Generate execution result Res i This includes the updated status of the relevant account on each blockchain. For example, Res i =[acc1:-3,acc2:+4] means that account acc1 consumes 3 tokens, while account acc2 receives 4 tokens. To submit the execution result, the executor calls the commitment commit function of the Rollup contract on chains L1 and L2, transferring the Txs... i and Res i As a new commitment i Upload, the Rollup contracts on both chains will c i Add to commitment list C and according to Res i Update token status.

[0116] During 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. If c iIf no challenge is received within the challenge period A ch, the Rollup contract will commit c i and the corresponding output token is considered valid and unlocked, the transaction Tx is successfully executed.

[0117] Figure 8 The execution verification and consistency verification due to the invalid signature of account acc1 is illustrated, in order to rollback c i on chain L1, the verifier can call the execution challenge interface of the Rollup contract on L1. After receiving the challenge, the Rollup contract verifies Res i and identifies the invalid signature. The Rollup contract on chain L1 starts to rollback the account state and generates the invalid commitment c i '. This can be achieved by modifying one state field in the original commitment c i . This record will be used as the basis for the consistency proof in the subsequent consistency challenge.

[0118] Since all data on the blockchain is stored in the form of Merkel tree, a Merkel proof is generated for the invalid commitment c i ' or the original commitment c i . 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 the proof and obtain the real data of c i ' and c i . Based on this data, the Rollup contract on L2 can verify the cross-chain consistency of commitment c i . If the commitment in the proof is inconsistent with the commitment c i stored in the current contract, the Rollup contract on chain L2 can confirm that the commitment c i corresponding to the transaction Tx has cross-chain inconsistency, and rollback the account state update caused by the commitment c i .

[0119] The inconsistency verification of the present embodiment is due to the change of the commitment on chain L1 caused by the failure of the execution verification. In order to maintain the consistency of the commitments on the two chains, the verifier provides a Merkel proof of the invalid commitment c i ' to the Rollup contract on L2 to prove that the commitment c i on L1 has been updated. After confirming the cross-chain inconsistency, the Rollup contract on chain L2 also performs the account state update rollback. For details, please refer to the corresponding parts described in the foregoing embodiments, which will not be repeated here.

[0120] Through the above steps, the application provides a blockchain cross-chain transaction data processing architecture, an executor is responsible for off-chain execution and submission of execution results, and a verifier is responsible for ensuring the correctness of the transaction execution process. Since the verifier only generates a cross-chain proof pi of a block when a consistency challenge occurs cross , only one zero-knowledge proof needs to be included, greatly reducing the verification overhead. The method proposed in the application introduces an optimistic execution mechanism and designs a Rollup contract execution framework. Even in the case of limited throughput of the blockchain itself, the cross-chain transaction throughput can be several times that of the blockchain. Compared with the traditional zero-knowledge proof chain bridge design, each cross-chain transaction needs to be executed on the chain, the cross-chain transaction execution framework proposed in the application has higher performance and stronger scalability. Secondly, the transaction verification mechanism ensures that as long as there is one honest verifier, the correctness of the operation can be ensured. If an attacker wants to control the entire system, all verifiers need to be attacked. In the traditional notary-based chain bridge, an attacker only needs to attack more than half or 2 / 3 of the verifiers. Therefore, the security of the application is higher. In a further embodiment, the application proposes a binary interactive verification method, which uses the bisection method to reduce the block verification problem until only one zero-knowledge proof is needed, reducing the verification overhead to O(1). In the optimistic case, no cross-chain verification needs to be performed, which can significantly reduce the verification cost of the system.

[0121] The device provided by the embodiment of the application has the same implementation principle and technical effects as the foregoing method embodiments. For brevity, the part not mentioned in the device embodiment is described with reference to the corresponding content in the foregoing method embodiments.

[0122] The method and related device mentioned in each of the foregoing embodiments are described with reference to the method flowchart and / or structural schematic diagram provided by the embodiments of the application. Each flow and / or block in the method flowchart and / or structural schematic diagram and the combination of the flows and / or blocks in the flowchart and / or block diagram can be implemented by computer program instructions. The computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices produce a device that implements the functions specified in the flow Figure 1 The computer program instructions can also be stored in a computer-readable memory capable of causing the computer or other programmable data processing devices to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the functions specified in the flow Figure 1 The computer program instructions can also be stored in a computer-readable memory capable of causing the computer or other programmable data processing devices to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the functions specified in the flow Figure 1 The computer program instructions can also be stored in a computer-readable memory capable of causing the computer or other programmable data processing devices to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the functions specified in the flow Figure 1The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0123] The following embodiments are described with reference to the method applied to a computer device. It should be understood that the computer device can be any device with computing and processing functions, which can be, but is not limited to, a server or a personal notebook computer. In one of the embodiments, the computer device can be an application server, which can be a server for running an application to be tested.

[0124] Referring to Figure 9 , which shows a hardware structural diagram of an electronic device, which is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0125] As shown in Figure 9 , 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 embodiments 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 complete mutual communication through the communication bus 4;

[0127] The processor 1 can be a central processing unit CPU, or a specific integrated circuit ASIC, or one or more integrated circuits configured to implement embodiments of the present application, etc.

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

[0129] The memory stores a program, and the processor can invoke the program stored in the memory, and the program is used for implementing each process of the blockchain cross-chain transaction data processing scheme.

[0130] The embodiment of the present application also provides a readable storage medium, which stores a computer program, and each process of the blockchain cross-chain transaction data processing scheme provided by the above embodiment and / or any possible implementation manner combined with the embodiment is implemented when the computer program is executed by a processor.

[0131] The above embodiments have described the present application in detail with respect to possible cases, and those skilled in the art will recognize that the present application can be practiced by other embodiments. The specific naming of the components, capitalization of terms, the attributes, data structures or any other programming or structural aspect is not mandatory or important, and the mechanisms of the present application can have different names, formats, or procedures that can implement the same way. The system can 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 various system components described herein is only exemplary, not mandatory; instead, a single system component can perform the functions performed by multiple components, or multiple components can perform the functions performed by a single component.

[0132] Those skilled in the art will understand that each step of the above disclosed method can be implemented by a general computing device, which can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by program codes executable by a computing device, so that they can be stored in a storage device and executed by a computing device, or they can be made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module. Thus, the embodiment of the present application is not limited to any specific hardware and software combination.

[0133] The computing device executable program (also called program, software, software application, or code) includes machine instructions of a programmable processor, and can be implemented by high-level process and / or object-oriented programming language, and / or assembly / machine language. As used herein, the terms "machine readable medium" and "computer readable medium" refer to any computer program product, device, and / or apparatus (for example, disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine readable medium receiving machine instructions as machine readable signals. The term "machine readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0134] Some aspects of the application include process steps and instructions described herein in the form of algorithms. It should be noted that the process steps and instructions of the application can be implemented in software, firmware and / or hardware, and where software is employed, it can be stored on and / or transmitted over varying platforms employed by a variety of operating systems.

[0135] Those skilled in the art can understand that the structures shown in the drawings are only block diagrams of part of the structures related to the solutions of the present application, and do not constitute a limitation on the terminal device to which the solutions of the present application are applied. The specific terminal device can include more or fewer components than those shown in the drawings, or combine certain components, or have a different arrangement of components.

[0136] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "a possible design" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples without contradiction.

[0137] Finally, it should also be noted that, in this document, the relationship terms such as first and second 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 the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of additional identical elements in the process, method, article or device including the element.

[0138] The above embodiments are only used to illustrate the technical solutions of the present application, but not limited to them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalent ones; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A blockchain cross-chain transaction data processing method, characterized in that, The method comprises the following steps: an executor executes a cross-chain transaction requested by a user off-chain, generates a transaction execution result and submits the result to a first blockchain and a second blockchain, wherein the cross-chain transaction requested by the user is between the first blockchain and the second blockchain; a first smart contract and a second smart contract deployed on the first blockchain and the second blockchain respectively update an account state of a user account associated with the cross-chain transaction on the blockchain according to the transaction execution result; the transaction execution result is not challenged by a verifier within a challenge period, and the corresponding cross-chain transaction is considered valid, otherwise the transaction is verified, including the following verification process: 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 verifies the validity of the transaction execution result in response to the execution challenge request, restores the account state of the user account associated with the cross-chain transaction on the first blockchain to the state before the update if the verification fails, generates a transaction rollback result corresponding to the transaction execution result, and sends the transaction rollback result to the executor and the verifier; if the verification fails, the following consistency verification is also performed: the verifier sends a 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 an inconsistency proof is generated according to the transaction rollback result and sent to the second blockchain to initiate an inconsistency challenge request; the second smart contract deployed on the second blockchain verifies the latest block information of the first blockchain using the cross-chain proof in response to the inconsistency challenge request, adds the latest block information of the first blockchain to a cross-chain block list if the verification is passed, obtains the transaction rollback result using the inconsistency proof, and restores the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction rollback result.

2. The method of claim 1, wherein, The second smart contract obtains the transaction rollback result using the inconsistency proof, and restores the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction rollback result, including: obtaining the latest state root from the latest block information of the first blockchain; verifying the legality of the inconsistency proof using the latest state root, obtaining the transaction rollback result using the inconsistency proof if the verification is passed, comparing the transaction rollback result with the stored transaction execution result to generate a comparison result, and restoring the account state of the user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the comparison result.

3. The method of claim 1, wherein, The generation of the transaction rollback result includes: the first smart contract modifies a preset state field in the transaction execution result to obtain the transaction rollback result.

4. The method of claim 1, wherein, The generation of the cross-chain proof includes: determining an xth block of the first blockchain, the latest block of the first blockchain being an rth block, wherein the xth block is a block without validity verification, the rth block is an Nth successor block of the xth block, and there are N-1 blocks between the rth block and the xth block; equating validity verification of the rth block to validity verification of N successor blocks of the xth block, and performing a binary interactive verification process as follows: the first smart contract provides a hash value of an x+N / 2th block to the verifier for validity verification, and if the validity verification is passed, the validity of blocks between the x+N / 2th block and the rth block is verified, otherwise the validity of blocks between the xth block and the x+N / 2th block is verified; repeating the binary interactive verification process until the N successor blocks cannot be bisected, and the verifier generates a cross-chain proof according to the verification result of the binary interactive verification process. 5.A blockchain cross-chain transaction data processing system, characterized in that, comprising a first blockchain, a second blockchain, an executor, a verifier, and a user; the first blockchain and the second blockchain respectively deploy a first smart contract and a second smart contract, and the user performs cross-chain transactions between the first blockchain and the second blockchain; the executor is configured to perform cross-chain transactions off-chain in response to a cross-chain transaction request of the user, generate a transaction execution result, and submit the transaction execution result 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 state of a user account associated with the cross-chain transaction on the respective blockchain according to the transaction execution result; the verifier initiates a challenge to the transaction execution result within a challenge period, and if the transaction execution result is not challenged by the verifier within the challenge period, the corresponding cross-chain transaction is considered valid, otherwise the transaction verification is performed, including the following verification process: the verifier verifies the validity of the transaction execution result off-chain, and if the verification fails, the verifier initiates an execution challenge request to the first blockchain; the first smart contract deployed on the first blockchain responds to the execution challenge request, verifies the validity of the transaction execution result, and if the verification fails, restores the account state of the user account associated with the cross-chain transaction on the first blockchain to the state before the update, generates a transaction rollback result corresponding to the transaction execution result, and sends the transaction rollback result to the executor and the verifier; if the verification fails, the following consistency verification is also performed: the verifier sends a 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 an inconsistency proof is generated according to the transaction rollback result and sent to the second blockchain to initiate an inconsistency challenge request; A second smart contract deployed on the second blockchain verifies the latest block information of the first blockchain by using the cross-chain proof in response to the inconsistency challenge request, adds the latest block information of the first blockchain to a cross-chain block list when the verification is passed, obtains the transaction rollback result by using the inconsistency proof, and restores the account state of a user account associated with the cross-chain transaction on the second blockchain to the state before the update according to the transaction rollback result.

6. An electronic device, comprising: comprising a memory and a processor; the memory, configured to store a program; the processor, configured to execute the program to implement the blockchain cross-chain transaction data processing method according to any one of claims 1-4.

7. A readable storage medium characterized by, a computer program is stored thereon, and the computer program is executed by a processor to implement the blockchain cross-chain transaction data processing method according to any one of claims 1-4.

Images