Data processing method and device based on multi-layer blockchain network and related equipment

Abstract

The application discloses a data processing method and device based on a multi-layer blockchain network and related equipment, and the method comprises the following steps: receiving a transaction detection request sent by a business terminal, performing network confirmation detection processing on a transaction with an account root according to the transaction detection request; when it is detected that the transaction with the account root is confirmed by a one-layer network node, a real transaction account root is obtained; if it is determined that the real transaction account root is inconsistent with a promised transaction account root, a challenge transaction for the transaction with the account root is generated, and the challenge transaction is sent to the one-layer network node; the challenge transaction is used for instructing the one-layer network node to perform confirmation and revocation processing on the transaction with the account root based on a two-layer network management contract. By using the application, the two-layer transaction state can be ensured not to be changed, so that the security of the transaction is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus and related equipment based on a multi-layer blockchain network. Background Technology

[0002] Currently, in multi-layer blockchain networks, the sequencer node is the central hub for transactions on the second-layer network. Transactions sent by business entities to the second-layer network are packaged into a single summary transaction by the sequencer node, which then submits the summary transaction to the first-layer network for confirmation.

[0003] However, in practice, it has been found that in multi-layer blockchain networks, the final order in which transactions in the second layer are packaged and executed is entirely determined by a single centralized sequencer node. This results in the transaction execution state not being guaranteed, meaning that the order of transaction packaging and execution is easily manipulated by the sequencer node. Changes in the order of transaction packaging and execution can lead to changes in the transaction state, thereby reducing transaction security. Summary of the Invention

[0004] This application provides a data processing method, apparatus, and related equipment based on a multi-layer blockchain network, which can ensure that the transaction status of the second layer remains unchanged, thereby guaranteeing the security of the transaction.

[0005] This application provides a data processing method based on a multi-layer blockchain network, characterized in that the multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; the method is executed by the challenger nodes, and the method includes:

[0006] The system receives transaction detection requests from business terminals and performs network confirmation detection processing on transactions with account roots based on these requests. The transaction detection request includes a committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first world state. The first world state is the Layer 2 network world state when the sequencer node receives an account root query request for the original transaction. Transactions with account roots are generated based on the original transaction and the committed transaction account root.

[0007] When a transaction with an account root is detected to be confirmed by a Layer 1 network node, the real transaction account root is obtained. The real transaction account root is used to identify the account state of the transaction-related account in the second world state. The second world state refers to the Layer 2 network world state corresponding to the target Layer 2 world state root. The target Layer 2 world state root refers to the latest Layer 2 world state root recorded by the Layer 1 network node when confirming the transaction with the account root.

[0008] If it is determined that the actual transaction account root is inconsistent with the promised transaction account root, a challenge transaction is generated for the transaction with the account root, and the challenge transaction is sent to the first-level network node. The challenge transaction is used to instruct the first-level network node to confirm or cancel the transaction with the account root based on the second-level network management contract.

[0009] The transaction detection request also includes the hash value of the transaction with the account root and the transaction commitment information; the transaction commitment information includes the hash value of the original transaction; the committed transaction account root belongs to the transaction commitment information; the transaction commitment information is generated by the sequencer node based on the account root query request and the first-world state;

[0010] The method also includes:

[0011] Retrieve the root transaction based on the hash value of the root transaction, and extract the original transaction fields from the root transaction; the original transaction fields are the same fields in the root transaction and the original transaction.

[0012] The original transaction fields are hashed to obtain the hash of the original transaction fields.

[0013] If the hash of the original transaction field is the same as the hash value of the original transaction, then the step of performing network confirmation detection processing on the transaction with account root according to the transaction detection request is executed.

[0014] This includes performing network confirmation checks on transactions with account roots based on transaction detection requests, including:

[0015] Based on the transaction detection request, a transaction on-chain query request for transactions with account roots is generated, and the transaction on-chain query request is sent to the first-layer network node so that the first-layer network node can determine the transaction on-chain result of transactions with account roots based on the transaction on-chain query request.

[0016] If the transaction is confirmed to be on-chain, then it is determined that the transaction with the account root has been confirmed by a network node at the first layer.

[0017] If the result of a transaction being recorded on the blockchain is determined to be a result of a transaction not being recorded on the blockchain, then a waiting timer is created;

[0018] When the duration recorded by the waiting timer equals the query waiting duration, a new transaction on-chain query request for the transaction with the account root is generated and sent to the first-layer network node so that the first-layer network node can determine the new transaction on-chain result for the transaction with the account root based on the new transaction on-chain query request.

[0019] The second world state includes the Layer 2 network account address and the first account state root hash corresponding to the Layer 2 network account address; the Layer 2 network account address refers to the account address of the business account registered in the Layer 2 network; the transaction-related account belongs to the business account registered in the Layer 2 network; the commitment transaction account root includes the commitment account address; the commitment account address refers to the account address of the transaction-related account.

[0020] When a transaction with an account root is detected to have been confirmed by a network node at layer one, the actual transaction account root is obtained, including:

[0021] When a transaction with an account root is detected to have been confirmed by a first-level network node, a status root query request is sent to the first-level network node.

[0022] Receive the target second-layer world state root sent by the first-layer network node according to the state root query request, and obtain the second world state corresponding to the target second-layer world state root;

[0023] The committed account address is determined as the real account address, and the first account state root hash corresponding to the Layer 2 network account address that is the same as the real account address in the second world state is determined as the real account state root hash.

[0024] Generate the real transaction account root based on the real account address and the real account status root hash.

[0025] This includes generating challenge transactions for transactions with account roots and sending the challenge transactions to a first-layer network node, including:

[0026] Obtain the transaction status information of transactions with account roots in the second world state, and generate a Merkel proof for the transaction status information based on the second world state.

[0027] Based on the real transaction account root, transaction status information, and Merkel proof, a challenge transaction is generated and sent to the first-layer network node. The first-layer network node is used to perform Merkel verification calculation on the transaction status hash and Merkel proof through the second-layer network management contract to obtain the world state root to be verified. When the world state root to be verified is the same as the target second-layer world state root, the committed transaction account root contained in the transaction with account root is obtained. It is also used to revert the latest recorded second-layer world state root to the target second-layer world state root when the obtained committed transaction account root is different from the real transaction account root.

[0028] This application provides a data processing method based on a multi-layer blockchain network, characterized in that the multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; the method is executed by the sequencer nodes, and the method includes:

[0029] The system receives an account root query request from a business terminal for the original transaction, generates transaction commitment information based on the account root query request and the first-world state, and sends the transaction commitment information to the business terminal. The first-world state refers to the Layer 2 network world state when the account root query request is received. The transaction commitment information includes the committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first-world state. The transaction commitment information is used to instruct the business terminal to add the committed transaction account root to the original transaction to obtain a transaction with an account root.

[0030] The system receives transactions with account roots sent by the service terminal, performs transaction verification processing on the transactions with account roots according to the third-world state, and obtains the transaction verification result; the third-world state refers to the Layer 2 network world state when the transaction with account roots is received.

[0031] If the transaction verification result is a successful transaction, the transaction with account root is submitted to the first-layer network node, and a transaction acceptance message is sent to the business terminal. This allows the business terminal to generate a transaction detection request based on the transaction acceptance message and transaction commitment information, and then send the transaction detection request to the challenger node. The transaction detection request instructs the challenger node to perform network confirmation detection processing on the transaction with account root. The challenger node sends a challenge transaction to the first-layer network node when it detects that the transaction with account root has been confirmed by the first-layer network node, and the real transaction account root is inconsistent with the committed transaction account root. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with account root. The challenge transaction instructs the first-layer network node to perform confirmation and revocation processing on the transaction with account root based on the second-layer network management contract.

[0032] The first-world state includes the Layer 2 network account address and the corresponding second account state root hash; the Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network; the account root query request includes the account address of the transaction-related account and the hash value of the original transaction; the transaction-related account refers to the business account whose account state was changed during the execution of the original transaction.

[0033] Based on the account root query request and the first-world state, transaction commitment information is generated and sent to the business terminal, including:

[0034] In the first world state, obtain the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the account associated with the transaction, and use it as the root hash of the committed account state;

[0035] Generate the committed transaction account root based on the account address and the committed account state root hash;

[0036] The hash value of the original transaction and the root of the committed transaction account are signed using the private key of the sequencer node to obtain the commitment signature information;

[0037] The transaction commitment information is generated based on the committed transaction account root, the hash value of the original transaction, and the commitment signature information. The transaction commitment information is then sent to the business terminal. The business terminal is used to verify the commitment signature information based on the committed transaction account root, the hash value of the original transaction, and the public key of the sequencer node. When the verification is successful, the committed transaction account root is added to the original transaction to obtain a transaction with account root. The business terminal is also used to send the transaction with account root to the sequencer node.

[0038] The third world state includes the Layer 2 network account address and the root hash of the third account state corresponding to the Layer 2 network account address;

[0039] Transaction verification is performed on transactions with account roots based on the third-world status, resulting in transaction verification results, including:

[0040] From transactions with account roots, obtain the committed transaction account root; the committed transaction account root contains the account address and the committed account state root hash;

[0041] In the third world state, the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the account associated with the transaction is obtained and used as the root hash of the transaction verification account state.

[0042] If the root hash of the transaction verification account is the same as the root hash of the commitment account, then the transaction verification result is determined to be a successful transaction verification result.

[0043] If the root hash of the transaction verification account state is different from the root hash of the commitment account state, the transaction verification result is determined to be a transaction verification failure result.

[0044] The methods also include:

[0045] If the transaction verification result is a transaction verification failure, a new commitment transaction account root is generated based on the account address and the transaction verification account state root hash. Account state update information is generated based on the new commitment transaction account root and sent to the business terminal. The account state update information is used to instruct the business terminal to add the new commitment transaction account root to the original transaction to obtain a new transaction with account root. The new transaction with account root is then sent to the sequencer node.

[0046] The methods also include:

[0047] If the transaction verification result is a transaction verification failure, a transaction rejection message is sent to the business terminal so that the business terminal can generate a new account root query request for the original transaction based on the transaction rejection message, and send the new account root query request to the sequencer node.

[0048] In the first-layer network, there are sequencer node accounts corresponding to sequencer nodes and business accounts of business objects corresponding to business terminals. The sequencer node accounts include the business resources of the sequencer nodes.

[0049] The method also includes:

[0050] A guarantee transaction is sent to the Layer 1 network so that the Layer 1 network can transfer the guarantee resources in the business resources of the sequencer node to the Layer 2 network management contract based on the guarantee transaction. The Layer 2 network management contract is used to calculate the loss compensation amount of the transaction with the account root when it is determined that the confirmation and cancellation of the transaction with the account root is successful, and transfer the business resources corresponding to the loss compensation amount to the business account based on the guarantee resources.

[0051] This application provides a data processing device based on a multi-layer blockchain network, characterized in that the multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; the device is operated by the challenger nodes, and the device includes:

[0052] The detection module is used to receive transaction detection requests sent by business terminals and perform network confirmation detection processing on transactions with account roots according to the transaction detection requests. The transaction detection request includes the committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first world state. The first world state is the Layer 2 network world state when the sequencer node receives the account root query request for the original transaction. Transactions with account roots are generated based on the original transaction and the committed transaction account root.

[0053] The acquisition module is used to acquire the real transaction account root when a transaction with an account root is confirmed by a first-layer network node. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with the account root.

[0054] The challenge module is used to generate a challenge transaction for the transaction with the account root if it is determined that the real transaction account root is inconsistent with the promised transaction account root, and send the challenge transaction to the first-level network node. The challenge transaction is used to instruct the first-level network node to perform confirmation and revocation processing on the transaction with the account root based on the second-level network management contract.

[0055] This application provides a data processing apparatus based on a multi-layer blockchain network, characterized in that the multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; the method is executed by the sequencer node, and the apparatus includes:

[0056] The transaction commitment module receives account root query requests sent by business terminals for original transactions, generates transaction commitment information based on the account root query requests and the first-world state, and sends the transaction commitment information to the business terminals. The first-world state refers to the Layer 2 network world state when the account root query request is received. The transaction commitment information includes the committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first-world state. The transaction commitment information is used to instruct the business terminals to add the committed transaction account root to the original transaction to obtain a transaction with an account root.

[0057] The transaction verification module is used to receive transactions with account roots sent by business terminals, perform transaction verification processing on transactions with account roots according to the third world state, and obtain the transaction verification result; the third world state refers to the Layer 2 network world state when the transaction with account roots is received.

[0058] The transaction acceptance module is used to submit the transaction with account root to the first-layer network node if the transaction verification result is successful. It then sends a transaction acceptance message to the business terminal, enabling the business terminal to generate a transaction detection request based on the transaction acceptance message and transaction commitment information, and send the request to the challenger node. The transaction detection request instructs the challenger node to perform network confirmation detection processing on the transaction with account root. When the challenger node detects that a transaction with account root has been confirmed by the first-layer network node, and the actual transaction account root is inconsistent with the committed transaction account root, it sends a challenge transaction to the first-layer network node. The actual transaction account root identifies the account status of the transaction-related account in the second-world state. The second-world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with account root. The challenge transaction instructs the first-layer network node to perform confirmation / revocation processing on the transaction with account root based on the second-layer network management contract.

[0059] One embodiment of this application provides a computer device, including: a processor, a memory, and a network interface;

[0060] The processor is connected to the memory and the network interface. The network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiments of this application.

[0061] One aspect of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor and executing the methods described in this application.

[0062] One aspect of this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in this application.

[0063] In this embodiment, the challenger node can perform network confirmation detection processing on transactions with account roots based on transaction detection requests sent by the service terminal. Then, when it detects that a transaction with account roots has been confirmed by a first-layer network node, it obtains the real transaction account root. If the real transaction account root is inconsistent with the committed transaction account root included in the transaction detection request, a challenge transaction is generated for the transaction with account roots, and the challenge transaction is sent to the first-layer network node. This challenge transaction instructs the first-layer network node to perform confirmation / revocation processing on the transaction with account roots based on the second-layer network management contract. The committed transaction account root identifies the account state of the transaction-related account in the first world state, which is the second-layer network world state when the sequencer node receives the account root query request for the original transaction. The transaction with account roots is generated based on the original transaction and the committed transaction account root. The real transaction account root identifies the account state of the transaction-related account in the second world state, which refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with account roots. Using the method provided in this application, it is possible to determine whether the transaction status of a transaction with an account root has been changed when it is finally submitted to the first-layer network, based on the consistency between the pre-determined committed transaction account root and the real account root corresponding to the actual execution of the transaction with account root. If the two are inconsistent, the transaction with account root can be revoked by challenging the transaction, thereby achieving the rollback of the transaction status and ensuring the security of the transaction. Attached Figure Description

[0064] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a schematic diagram of the structure of a layered blockchain network provided in an embodiment of this application;

[0066] Figure 2a This is a schematic diagram illustrating a data processing method based on a multi-layer blockchain network provided in an embodiment of this application.

[0067] Figure 2b This is a schematic diagram illustrating another data processing method based on a multi-layer blockchain network provided in this application embodiment;

[0068] Figure 3 This is a flowchart illustrating a data processing method based on a multi-layer blockchain network provided in an embodiment of this application;

[0069] Figure 4 This is a flowchart illustrating a data processing method based on a multi-layer blockchain network provided in an embodiment of this application;

[0070] Figure 5 This is a schematic diagram of the interactive process of a method for submitting a transaction root with an account based on a committed transaction account root, provided in an embodiment of this application.

[0071] Figure 6 This is a schematic diagram of the interaction process of a transaction detection and challenge method based on the root of a committed transaction account provided in an embodiment of this application;

[0072] Figure 7 This is a schematic diagram of the structure of a data processing device based on a multi-layer blockchain network provided in an embodiment of this application;

[0073] Figure 8 This is a schematic diagram of another data processing device based on a multi-layer blockchain network provided in this application embodiment;

[0074] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0075] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0076] Please see Figure 1 , Figure 1 This is a schematic diagram of a layered blockchain network structure provided in an embodiment of this application. For example... Figure 1 The layered blockchain network shown includes a business device cluster 100a, a second-layer network 200a, and a first-layer network 300a.

[0077] The business device cluster 100a can be a cluster of devices used by a business object to initiate business transactions. This business device cluster 100a can include multiple terminal devices (also called business devices), such as device 12a, device 12b, ..., device 12n, etc. The number of terminal devices in the business device cluster is not limited here.

[0078] Layer 2 network 200a can be a network for executing business transactions under the blockchain. Layer 2 network 200a can include multiple Layer 2 network nodes, such as Layer 2 network node 13a, Layer 2 network node 13b, ..., Layer 2 network node 13n, etc. The number of Layer 2 network nodes in Layer 200a is not limited here. It should be understood that this Layer 2 network can be used to execute business transactions under the blockchain and aggregate multiple business transactions into a single aggregated transaction, which is then submitted to the Layer 1 network. In this multi-layer blockchain network architecture, a Layer 2 network node (such as Layer 2 network node 13a) can aggregate one or more transactions submitted to it to obtain a single aggregated transaction. This allows one or more transactions from the aggregated transaction to be uploaded to the blockchain at once, improving the scalability of the Layer 1 network's blockchain to support a larger number of transactions submitted by more business entities.

[0079] Layer 300a can be a network used for blockchain ledger recording. This layer 300a can include multiple layer network nodes. In... Figure 1 In the layer 300a shown, multiple layer 1 network nodes are deployed. These layer 1 network nodes can specifically include... Figure 1The layer 1 network nodes shown are 11a, 11b, 11c, and 11d. The number of layer 1 network nodes deployed in layer 1 network 300a is not limited here. It should be understood that the various layer 1 network nodes in layer 1 network 300a can be used to jointly maintain a blockchain, such as... Figure 1 As shown, for multiple Layer 1 network nodes operating in Layer 1 network 300a, the jointly maintained blockchain can provide... Figure 1 The blockchain 11e shown.

[0080] It should be understood that the blockchain involved in the embodiments of this application (such as blockchain 11e mentioned above) is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof, while also enabling data verification, storage, and updating. Essentially, a blockchain is a decentralized database in which each node stores the same blockchain.

[0081] It should be understood that a first-layer network node can upload aggregated transactions submitted by second-layer network nodes to the blockchain. In the aforementioned multi-layer blockchain network (i.e., first-layer and second-layer networks), second-layer network nodes (such as second-layer network node 13a) are used to execute business transactions and aggregate transactions to obtain aggregated transactions, while first-layer network nodes (such as first-layer network node 11a) can upload individual transactions (such as aggregated transactions submitted by second-layer network nodes) to the blockchain.

[0082] It is understandable that smart contracts can be deployed on the blockchain maintained by Layer 1 network 300a (such as blockchain 11e mentioned above). A smart contract can be understood as code executed by each blockchain node (i.e., each Layer 1 network node). Layer 1 network nodes can execute corresponding logic and obtain results through this smart contract; smart contracts can also be referred to as business processing data. Specifically, smart contracts can run in a virtual machine (VM) on a Layer 1 network node. For example, a smart contract deployed on the blockchain maintained by the Layer 1 network (such as blockchain 11e mentioned above) can be a smart contract used to manage the Layer 2 network (i.e., a Layer 2 network management contract). When a Layer 1 network node receives a summary transaction submitted by a Layer 2 network node, it can call the Layer 2 network management contract to package the summary transaction obtained off-chain and upload it to the blockchain.

[0083] It should be understood that one or more smart contracts can be deployed on the blockchain of Layer 1 Network 300a (e.g., Blockchain 11e mentioned above). These smart contracts can be distinguished by their contract call address, contract identity document (ID), or contract name. Transactions submitted to Layer 1 Network 300a can carry the smart contract's contract call address, contract identity document (ID), or contract name to specify the smart contract to be executed. For example, a Layer 2 network node can carry the contract call address of the Layer 2 network management contract in its aggregated transaction submitted to a Layer 1 network node.

[0084] For further details, please see Figure 2a , Figure 2a This is a schematic diagram illustrating a data processing method based on a multi-layered blockchain network provided in an embodiment of this application. For example... Figure 2a As shown, business object U1 can construct the original transaction TX1 through business terminal 21a and obtain the account address Addresses (e.g., the account related to the original transaction TX1) of the transaction-related account. Figure 2a As shown in S211a in the diagram). The service terminal 21a can be one of the aforementioned... Figure 1 Any service device in the service device cluster 100a, such as device 12a. The related account for the original transaction TX1 refers to the service account in the Layer 2 network whose account status will change due to the execution of the original transaction TX1. The account address is a unique identifier used to identify the service account in the Layer 2 network. Then, service terminal 21a can send service transaction TX1 (e.g., ...) to Layer 2 network node 22a. Figure 2a As shown in S212a in the diagram). Layer 2 network node 22a can be... Figure 1 Any two-layer network node in the two-layer network 200a, such as node 13a.

[0085] In the Layer 2 network node 22a, a sequencer 201a can be deployed. In this case, the Layer 2 network node 22a can be referred to as the sequencer node of the Layer 2 network. The sequencer 201a can be the actual accounting program running the Layer 1 and Layer 2 networks. Through the sequencer 201a, the Layer 2 network node 22a can summarize and package the acquired business transactions and submit the summarized transactions to the Layer 1 network node. For example... Figure 2aAs shown, the sequencer 201a may include a sequencer component 202a and a second-layer world state 203a. The sequencer component 202a can be a module or component used to select transactions, confirm their order, and execute transactions in the second-layer network over a period of time, obtaining a summary transaction, and then submitting the summary transaction to the first-layer network nodes. The second-layer world state 203a refers to the blockchain world state in the second-layer network. The blockchain world state is the set of all account states in the blockchain network at a specific moment. In other words, the second-layer world state 203a consists of the states of numerous second-layer network accounts (i.e., business accounts registered in the second-layer network), and it can be stored using a hash-based tree data structure.

[0086] The account organization structure in two-tier world state 203a can be as follows: Figure 2a As shown in section 204a, smart contract type accounts have multiple stored key-value pairs (i.e., the states of these accounts). These multiple key-value pairs form an account subtree for that account and have a root hash. Taking account 1 as an example, the account states corresponding to account 1 can constitute account subtree 1, and its corresponding root hash is H1. Furthermore, in this application, the account root corresponding to the account can be generated by the hash of the account address and its account subtree. Therefore, the account root of account 1 can be represented as...<Addr1,H1> Where Addr1 refers to the account address of account 1. Further, such as... Figure 2a As shown in 204a, in addition to the account subtrees of each account and the root hash, the second-layer world state 203a also contains the second-layer world state root obtained by further hashing each root hash. The second-layer world state root is a hash value used to represent the world state of the entire second-layer network at a specific moment.

[0087] Understandably, the sequencing component 202a can access the second-level world state 203a at any time to obtain the second-level world state root and the account state root of the required account at the time of access. However, the account state stored in the second-level world state 203a changes as transactions are executed. Therefore, when the sequencing component 202a accesses the second-level world state 203a at different times, the second-level world state root and the account state root of the required account may be inconsistent.

[0088] like Figure 2a As shown, after receiving an account root query request, Layer 2 network node 22a can access Layer 2 world state 203a through sequencer component 202a to obtain the account root corresponding to account address Addrs at the time of access, which serves as the committed transaction account root (e.g., ...). Figure 2aAs shown in S213a), then, the Layer 2 network node 22a can generate transaction commitment information based on the committed transaction account root and send the transaction commitment information to the business terminal 21a corresponding to the business object U1 (e.g., ...). Figure 2a (As shown in S214a).

[0089] like Figure 2a As shown, after receiving the transaction commitment information, the business terminal 21a can generate a transaction TX1' with the account root based on the committed transaction account root contained in the transaction commitment information, such as... Figure 2a As shown in 205a, the adjusted business transaction TX1' can include the original transaction TX1 and the committed transaction account root. Furthermore, after receiving the transaction TX1' with the account root, the business terminal 21a can send the transaction TX1' with the account root to the Layer 2 network node 22a (e.g., ...). Figure 2a (As shown in S215a).

[0090] Furthermore, after obtaining the transaction TX1' with the account root, the second-layer network node 22a can submit the transaction TX1' with the account root to the first-layer network 300a (e.g., ...). Figure 2a (As shown in S216a). It should be understood that each layer network node in this layer network 300a can deploy a layer 2 network management contract, and thus the layer network node in the layer network 300a (such as node 11a) can put the transaction TX1' with the account root on the chain based on the layer 2 network management contract.

[0091] In this embodiment, by having the business object request the sequencer node to provide a committed transaction account root before transaction execution, the sequencer node can avoid affecting the account status of the transaction-related account before transaction execution through pre-emptive attacks, thus protecting the user's interests. Because the committed transaction account root can be used to identify the account status of the transaction-related account before the execution of the transaction TX1' with account root, the committed transaction account root can be used to verify whether the transaction execution order of TX1' with account root was changed when it was uploaded to the blockchain in the first-layer network. For ease of understanding, please also refer to... Figure 2b , Figure 2b This is a schematic diagram of another data processing method based on a multi-layer blockchain network provided in the embodiments of this application.

[0092] like Figure 2b As shown, after receiving the transaction commitment information sent by the sequencer node, i.e., the Layer 2 network node 22a, business object U1 can send a transaction detection request to the challenger node 23a in the Layer 2 network. This transaction detection request will contain the committed transaction account root (e.g., the account root of the transaction TX1') of the transaction (e.g., the transaction root of the transaction TX1'). Figure 2b (As shown in S221a). Challenger node 23a can be... Figure 1Any two-layer network node in the two-layer network 200a, such as node 12a.

[0093] like Figure 2b As shown, after receiving the transaction inspection request, challenger node 23a can perform network confirmation inspection on the transaction TX1' with the account root according to the transaction inspection request (e.g., Figure 2b As shown in S222a). The network confirmation check can be performed by querying the first-layer network node 24a to see if the transaction TX1' with the account root has been uploaded to the blockchain, i.e., whether it has been written into the next layer of the network blockchain. Figure 1 In the blockchain 11e, if the transaction TX1' with an account root has been uploaded to the chain, it indicates that the transaction TX1' with an account root has been confirmed by the first-layer network node 24a. If the challenger node 23a detects that the transaction TX1' with an account root has been confirmed by the first-layer network node 24a, the challenger node 23a can send a state root query request to the first-layer network node 24a. This state root query request is used to request the first-layer network node 24a to obtain the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded when the transaction TX1' with an account root is confirmed. Here, confirming the transaction TX1' with an account root can refer to processing the transaction TX1' with an account root on the chain; the latest second-layer world state root recorded when the transaction TX1' with an account root is confirmed refers to the latest second-layer world state root recorded before the transaction TX1' with an account root is uploaded to the chain, that is, the second-layer world state root carried in the transaction with an account root that was uploaded to the chain before the transaction TX1' with an account root.

[0094] Understandably, when the sequencer node submits a transaction with an account root, it adds the second-layer world state root after the execution of the transaction to the transaction. For example, the transaction TX1' with an account root can contain the second-layer world state root root1, which is the root hash of the second-layer world state after the execution of the transaction TX1'. Layer 1 network node 24a can invoke the Layer 2 network management contract based on the state root query request, and then use the Layer 2 network management contract to query the Layer 1 network blockchain for the previous transaction with an account root that was uploaded to the chain before the transaction TX1'. Assuming the Layer 1 network blockchain at this time is as follows... Figure 2b As shown in 206a, the transaction with the account root TX0' is the previous on-chain transaction with the account root TX1', which contains the second-level world state root root0. Therefore, the target second-level world state root obtained by the first-level network node 24a is the second-level world state root root0. The first-level network node 24a can send the target second-level world state root root0 to the challenger node 23a (e.g., ...). Figure 2b (As shown in S223a).

[0095] Challenger node 23a can find the second-level world state used when actually executing the transaction TX1' with account root based on the target second-level world state root0, and determine the real transaction account root from this second-level world state. The hash of this real transaction root can identify the account state corresponding to the transaction-related account before the actual execution of the transaction TX1' with account root (e.g., ...). Figure 2b (As shown in S224a). Further, challenger node 23a can compare the real transaction account root with the committed transaction account root. If the committed transaction account root does not match the real transaction account root, it sends a challenge transaction TX2 to layer 1 network node 24a. (As shown in S224a). Figure 2b (As shown in S225a). In this case, the challenge transaction TX2 is used to instruct the first-layer network node 24a to perform confirmation and revocation processing on the account root transaction TX1' based on the second-layer network management contract.

[0096] Furthermore, after receiving the challenge transaction TX2, the first-layer network node 24a will verify whether the transaction execution order of the transaction TX1' with account root has been tampered with based on the challenge transaction TX2. If the verification result is consistent with that of the challenger node 23a, that is, if it is confirmed that the promised transaction account root carried in the transaction TX1' with account root is inconsistent with the real transaction account root, the transaction will be revoked (e.g., Figure 2b (As shown in S226a). The next layer of the network blockchain after transaction reversal processing is as follows: Figure 2b As shown in 207a, at this point, it can be considered that both the transaction with the account root TX1' and the transaction with the account root TX2' are invalid. Then, the latest transaction recorded in the current layer network blockchain is the transaction with the account root TX0', and the latest second-layer world state root is the second-layer world state root root0.

[0097] In this embodiment of the application, once it is detected that the real transaction account root of the transaction with the account root is inconsistent with the promised transaction account root, a challenge transaction can be sent to a first-layer network node to cancel the transaction with the wrong execution order. This allows the associated account of the transaction to roll back its state when it is affected by preemptive attacks, thereby improving transaction security.

[0098] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0099] It is understood that the above scenarios are merely examples and do not constitute a limitation on the application scenarios of the technical solutions provided in the embodiments of this application. The technical solutions of this application can also be applied to other scenarios. For example, as those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0100] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method based on a multi-layer blockchain network provided in an embodiment of this application. The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes; the second-layer network nodes include an orderer node and a challenger node; the method is executed by the challenger node, for example, the challenger node can be... Figure 1 Node 12a in the diagram. The method may include at least the following steps S101-S103.

[0101] Step S101: Receive a transaction detection request sent by the business terminal, and perform network confirmation detection processing on transactions with account roots according to the transaction detection request.

[0102] Specifically, the transaction detection request includes a committed transaction account root; the committed transaction account root is used to identify the account status of the transaction-related account in the first world state; the first world state is the layer 2 network world state when the sequencer node receives an account root query request for the original transaction; the transaction with account root is generated based on the original transaction and the committed transaction account root.

[0103] The original transaction can be a transaction submitted by the business terminal for business processing. For example, this business transaction can be a transaction in which business object U1 transfers business resources to business object U2, and the business resources can be the digital resources of business object U1 on the blockchain. The committed transaction account root is the account root of the transaction-related accounts involved in the original transaction, determined by the sequencer node at the moment it receives the account root query request for the original transaction. It can be used to identify the account status of the transaction-related accounts at the moment the sequencer node receives the account root query request for the original transaction. After generating the committed transaction account root, the sequencer node can return it to the business terminal. The business terminal will generate a transaction with an account root based on the original transaction and the committed transaction account root. This transaction with an account root can be understood as an original transaction carrying the committed transaction account root. In this application, the transaction that the business terminal finally submits to the Layer 2 network for business processing is a transaction with an account root. Subsequent Layer 1 network nodes can determine whether the order of the transaction with an account root has been tampered with during transaction execution by comparing the committed transaction account root with the real transaction account root corresponding to the actual execution of the transaction with an account root. Among them, the transaction detection request can be generated after the business terminal submits a transaction with account root to the sequencer node. This transaction detection request can be used to request detection of whether the execution order of the transaction with account root has been tampered with, that is, to determine whether the transaction status of the transaction with account root has changed.

[0104] It should be understood that, in this application, the account root of a business account can be represented by its account address and the root hash of its account subtree. The account address is an identifier used to identify the business account, and the account subtree is a subtree formed by multiple stored key-value pairs (used to represent the account state of the business account) that the business account has in the organization of the world state tree, and it has a root hash. That is, the root hash used to identify the account state of the business account can be obtained in the world state of the blockchain. Therefore, the commitment transaction account root can contain the account address of the transaction-related account and the root hash of the transaction-related account in the first world state. Here, the first world state is the Layer 2 network world state at the instant that the sequencer node receives the account root query request for the original transaction.

[0105] Specifically, a feasible implementation process for a challenger node to perform network confirmation detection on transactions with account roots after receiving a transaction detection request can be as follows: A transaction on-chain query request for the transaction with account roots is generated based on the transaction detection request, and this query request is sent to a first-layer network node, allowing the first-layer network node to determine the on-chain result of the transaction with account roots based on the query request; if the on-chain result is determined to be a transaction already on-chain, then the transaction with account roots is confirmed by the first-layer network node; if the on-chain result is determined to be a transaction not on-chain, a waiting timer is created; when the duration recorded by the waiting timer equals the query waiting time, a new transaction on-chain query request for the transaction with account roots is generated, and this new query request is sent to a first-layer network node, allowing the first-layer network node to determine a new on-chain result for the transaction with account roots based on the new query request.

[0106] The on-chain transaction result includes both "transaction already on-chain" and "transaction not on-chain" results. "Transaction already on-chain" indicates that the transaction with the account root has been confirmed by a first-layer network node, while "transaction not on-chain" indicates that the transaction with the account root has not yet been confirmed by a first-layer network node. It's understood that the second-layer network often submits a summary transaction to the first-layer network. This summary transaction is typically generated by executing and summarizing one or more transactions with account roots. When the summary transaction is written into the first-layer network's blockchain, it can be assumed that its corresponding transaction with the account root has also been written into the first-layer network's blockchain, and the on-chain result for the transaction with the account root can be considered an "on-chain" result; otherwise, the on-chain result for the transaction with the account root can be a "transaction not on-chain" result.

[0107] The query waiting time can be ten seconds, one minute, or ten minutes, etc., and can be set according to actual operational needs. This application does not impose any restrictions on this. By setting the query waiting time and a timer, it is possible to periodically query the first-layer network nodes for the on-chain results of transactions with account roots until it is confirmed that the transaction with account roots has been approved by the first-layer network.

[0108] Optionally, the sequencer node can generate transaction commitment information based on the account root query request and the first-world state. That is, after generating the committed transaction account root, the sequencer node can sign the hash value of the original transaction and the committed transaction account root to obtain commitment signature information. This commitment signature information can be used to indicate that the committed transaction account root was generated by the sequencer node for the original transaction. The sequencer node can generate transaction commitment information based on the committed transaction account root, the hash value of the original transaction, and the commitment signature information, and then send the transaction commitment information to the business terminal. The business terminal can verify the commitment signature information in the transaction commitment information to confirm that the committed transaction account root was generated by the sequencer node. After successful verification, the committed transaction account root is added to the original transaction, resulting in a transaction with an account root. Therefore, the transaction detection request sent by the business terminal to the challenger node can include the hash value of the transaction with an account root and the transaction commitment information, which includes the hash value of the original transaction and the committed transaction account root. At this point, in order to verify the correlation between the transaction commitment information in the transaction detection request and the hash value of the transaction with account root, that is, to verify that the transaction commitment information in the transaction detection request was indeed generated by the sequencer node for the original transaction corresponding to the hash value of the transaction with account root in the transaction detection request, the challenger node can obtain the transaction with account root based on the hash value of the transaction with account root, and extract the original transaction field from the transaction with account root; the original transaction field refers to the field that is the same in the transaction with account root and the original transaction; the original transaction field is hashed to obtain the hash of the original transaction field; if the hash of the original transaction field is the same as the hash value of the original transaction, it means that the transaction commitment information is associated with the transaction with account root, and steps S101-S103 can be executed to detect whether the transaction status of the transaction with account root has been changed.

[0109] Step S102: When it is detected that a transaction with an account root has been confirmed by a network node at the first layer, the real transaction account root is obtained.

[0110] Specifically, the real transaction account root is used to identify the account status of the transaction-related account in the second world state. Here, the second world state refers to the second-level network world state corresponding to the target second-level world state root; the target second-level world state root refers to the latest second-level world state root recorded by the first-level network node when confirming the transaction with the account root.

[0111] Specifically, the second-world state can contain the Layer 2 network account address and the corresponding first account state root hash. Here, the Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network; the transaction-related account belongs to a business account registered in the Layer 2 network; the committed transaction account root contains the committed account address; and the committed account address refers to the account address of the transaction-related account. A feasible implementation process for obtaining the real transaction account root when a transaction with an account root is confirmed by a Layer 1 network node can be as follows: when a transaction with an account root is confirmed by a Layer 1 network node, a state root query request is sent to the Layer 1 network node; the target Layer 2 world state root sent by the Layer 1 network node according to the state root query request is received, and the second-world state corresponding to the target Layer 2 world state root is obtained; the committed account address is determined as the real account address, and the first account state root hash corresponding to the Layer 2 network account address that is the same as the real account address in the second-world state is determined as the real account state root hash; the real transaction account root is generated based on the real account address and the real account state root hash. The first account state root hash refers to the root hash of the account subtree corresponding to the Layer 2 network account address in the second world state.

[0112] It should be understood that each transaction with an account root can contain a second-level world state root corresponding to its own executed second-level network world state. Whenever a first-level network node confirms a transaction with an account root, the latest second-level world state root recorded by it is the second-level world state root contained in the most recently confirmed transaction with an account root. The latest second-level world state root recorded by a first-level network node when confirming a transaction with an account root is the second-level world state root contained in the transaction with an account root that precedes it in the chain. For example, if the latest transaction to be chained by a first-level network node is transaction with an account root TX00 containing the second-level world state root root00, then when the first-level network node confirms transaction with an account root TX01, the latest second-level world state root recorded is the second-level world state root root00. It can be understood that a first-level network node confirming transaction with an account root TX01 can be considered as initiating consensus on-chain processing for transaction with an account root TX01, at which point transaction with an account root TX01 has not yet been written into the first-level network's blockchain.

[0113] Optionally, when the sequencer node submits a transaction with an account root, it can add the second-level world state root corresponding to the second-level network world state before and after the execution of the transaction to the transaction with the account root. In this case, the first-level network node can directly obtain the target second-level world state root from the transaction with the account root.

[0114] Step S103: If it is determined that the real transaction account root is inconsistent with the promised transaction account root, a challenge transaction is generated for the transaction with account root, and the challenge transaction is sent to the first-layer network node. The challenge transaction is used to instruct the first-layer network node to perform confirmation and cancellation processing on the transaction with account root based on the second-layer network management contract.

[0115] Specifically, if the promised transaction account root is inconsistent with the actual transaction account root, it indicates that the transaction state at the time of generation is inconsistent with the actual transaction state at the time of execution. In other words, the transaction state of the transaction with the account root has changed, and in this case, the transaction with the account root should be revoked to protect the interests of the business entity. Therefore, a challenger node can send a challenge transaction to a Layer 1 network node. This challenge transaction can be used to instruct the Layer 1 network to revoke the transaction with the account root, or it can be used to instruct the Layer 1 network to revoke all transactions executed after the transaction with the account root.

[0116] Specifically, a feasible implementation of generating a challenge transaction for a transaction with an account root and sending the challenge transaction to a Layer 1 network node can be as follows: Obtain the transaction state information of the transaction with the account root in the second world state; generate a Merkel proof for the transaction state information based on the second world state; generate a challenge transaction based on the real transaction account root, transaction state information, and Merkel proof; and send the challenge transaction to a Layer 1 network node. The transaction state information can include the account state information of the transaction-related accounts associated with the transaction with the account root. For example, if the transaction with the account root involves business object A transferring 300 digital resources to business object B, then the transaction-related accounts associated with the transaction with the account root are business account A corresponding to business object A and business account B corresponding to business object B. If business account A has a balance of 600 and business account B has a balance of 500, then the transaction state information can include the balance of business account A as 600 and the balance of business account B as 500. Merkle proof, also known as Merkle path, is a cryptographic proof method used to verify whether data is included in a specific dataset. It can be understood that the world state of a two-layer network has a tree-like structure, such as... Figure 2a As shown in 204a, by continuously hashing and combining the underlying account state data upwards, a root hash value is finally obtained, which is the second-layer world state root mentioned above. When it is necessary to prove whether a certain account state information is in the second-layer network state, it is only necessary to provide all the hash values ​​on the path from the account state information to the second-layer world state root. These hash values ​​constitute the Merkel proof corresponding to the account state.

[0117] Specifically, after receiving a challenge transaction, a Layer 1 network node can perform Merkel verification calculations on the transaction state hash and Merkel proof through the Layer 2 network management contract to obtain the world state root to be verified. If the world state root to be verified is the same as the target Layer 2 world state root, the committed transaction account root contained in the transaction with account root is obtained. If the obtained committed transaction account root is different from the actual transaction account root, the currently recorded latest Layer 2 world state root is reverted to the target Layer 2 world state root. Reverting the currently recorded latest Layer 2 world state root to the target Layer 2 world state root means that the transaction with account root and all subsequent transactions uploaded to the chain are invalid.

[0118] Using the method provided in this application, it is possible to determine whether the transaction status of a transaction with an account root has been changed when it is finally submitted to the first-layer network, based on the consistency between the committed transaction account root queried in advance and the real account root corresponding to the actual execution of the transaction with account root. If the two are inconsistent, the transaction with account root can be revoked by challenging the transaction, thereby achieving the rollback of the transaction status and ensuring the security of the transaction.

[0119] Further, please see Figure 4 , Figure 4 This is a flowchart illustrating a data processing method based on a multi-layer blockchain network provided in an embodiment of this application. The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; the method is executed by the sequencer node, for example, the sequencer node can be... Figure 1 The method includes at least the following steps S201-S203. (The text also mentions node 13a in a two-layer network 200a, but this seems unrelated to the previous sentence.)

[0120] Step S201: Receive the account root query request sent by the business terminal for the original transaction, generate transaction commitment information based on the account root query request and the first world state, and send the transaction commitment information to the business terminal.

[0121] Specifically, the first world state refers to the Layer 2 network world state when the account root query request is received; the transaction commitment information includes the committed transaction account root; the committed transaction account root is used to identify the account status of the transaction-related account in the first world state; the transaction commitment information is used to instruct the business terminal to add the committed transaction account root to the original transaction to obtain a transaction with an account root.

[0122] Specifically, the first-world state includes the Layer 2 network account address and the corresponding second account state root hash. The Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network. The account root query request includes the account address of the transaction-related account and the hash value of the original transaction. The transaction-related account refers to the business account whose account state was changed during the execution of the original transaction. A feasible implementation process for generating transaction commitment information based on the account root query request and the first-world state, and sending the transaction commitment information to the business terminal, can be as follows: In the first-world state, obtain the account state root hash corresponding to the Layer 2 network account address that is the same as the account address of the transaction-related account, and use it as the commitment account state root hash; generate the commitment transaction account root based on the account address and the commitment account state root hash; perform signature processing on the hash value of the original transaction and the commitment transaction account root using the private key of the sequencer node to obtain commitment signature information; generate transaction commitment information based on the commitment transaction account root, the hash value of the original transaction, and the commitment signature information, and send the transaction commitment information to the business terminal.

[0123] In this system, the public and private keys of the sequencer node are a paired encryption key pair. In an asymmetric encryption system, the private key can be used for digital signatures. Data is signed using the private key, and others can use the corresponding public key to verify the authenticity of the signature. Therefore, the business terminal can verify the promised signature information based on the promised transaction account root, the hash value of the original transaction, and the public key of the sequencer node. Upon successful verification, the promised transaction account root is added to the original transaction, resulting in a transaction with an account root, which is then sent to the sequencer node. One feasible implementation of the verification process is as follows: the business terminal decrypts the promised signature information using the public key of the sequencer node to obtain a decryption hash. Simultaneously, the business terminal hashes the promised transaction account root and the hash value of the original transaction to obtain a verification hash. If the decryption hash and the verification hash are the same, the verification is considered successful.

[0124] Step S202: Receive the transaction with account root sent by the service terminal, perform transaction verification processing on the transaction with account root according to the third world state, and obtain the transaction verification result; the third world state refers to the Layer 2 network world state when the transaction with account root is received.

[0125] Specifically, during the process of the business terminal generating a transaction with an account root based on the transaction commitment information and submitting it to the sequencer node, there is a certain time difference, although it is generally a very short time. However, it is also possible that the account root of the account associated with the transaction with an account root has changed during this time. Therefore, the sequencer node needs to perform a transaction verification process on the transaction with an account root, that is, to verify whether the account root of the transaction associated with the transaction with an account root at this time (i.e., when the transaction with an account root is received) is consistent with the account root of the committed transaction with an account root.

[0126] Specifically, the third-world state includes the Layer 2 network account address and the corresponding third account state root hash. A feasible implementation process for verifying transactions with account roots based on the third-world state to obtain the transaction verification result can be as follows: Obtain the committed transaction account root from the transaction with account root; the committed transaction account root includes the account address and the committed account state root hash; in the third-world state, obtain the account state root hash corresponding to the Layer 2 network account address that is the same as the account address of the account associated with the transaction, and use it as the transaction verification account state root hash; if the transaction verification account state root hash is the same as the committed account state root hash, then the transaction verification result is determined to be a successful transaction verification result; if the transaction verification account state root hash is different from the committed account state root hash, then the transaction verification result is determined to be a failed transaction verification result.

[0127] Optionally, if the transaction verification result is a transaction verification failure, a new commitment transaction account root is generated based on the account address and the transaction verification account state root hash. Account state update information is generated based on the new commitment transaction account root and sent to the business terminal. The account state update information is used to instruct the business terminal to add the new commitment transaction account root to the original transaction to obtain a new transaction with account root. The new transaction with account root is then sent to the sequencer node.

[0128] Optionally, if the transaction verification result is a transaction verification failure, a transaction rejection message is sent to the business terminal so that the business terminal generates a new account root query request for the original transaction based on the transaction rejection message and sends the new account root query request to the sequencer node.

[0129] Step S203: If the transaction verification result is a successful transaction verification result, the transaction with the account root is submitted to the first-layer network node, and a transaction acceptance message is sent to the business terminal so that the business terminal generates a transaction detection request based on the transaction acceptance message and transaction commitment information, and sends the transaction detection request to the challenger node.

[0130] Specifically, the transaction detection request instructs the challenger node to perform network confirmation detection processing on transactions with account roots. When the challenger node detects that a transaction with account roots has been confirmed by a first-level network node, and the actual transaction account root is inconsistent with the promised transaction account root, it sends a challenge transaction to the first-level network node. The actual transaction account root identifies the account state of the transaction-related account in the second-world state. The second-world state refers to the second-level network world state corresponding to the target second-level world state root. The target second-level world state root refers to the latest second-level world state root recorded by the first-level network node when confirming the transaction with account roots. The challenge transaction instructs the first-level network node to perform confirmation / revocation processing on the transaction with account roots based on the second-level network management contract. The process of the challenger node performing network confirmation detection processing on transactions with account roots according to the transaction detection request and generating the challenge transaction can be found above. Figure 3 The descriptions of steps S101-S103 in the corresponding embodiments will not be repeated here.

[0131] Optionally, in this embodiment, to prevent the sequencer node from maliciously tampering with the transaction execution order, the sequencer node needs to deposit a security deposit (i.e., security resources) into the Layer 2 network management contract in advance. This allows the Layer 2 network management contract to compensate the business object based on the security resources when the Layer 1 network node detects that the execution order of a transaction with an account root has been tampered with. Specifically, a portion of the security deposit deposited by the sequencer node is used to compensate the business object. Therefore, in this embodiment, the Layer 1 network can register a sequencer node account corresponding to the sequencer node and a business account corresponding to the business object of the business terminal. The sequencer node account includes the business resources of the sequencer node. This embodiment may also include the following steps: sending a security transaction to the Layer 1 network, so that the Layer 1 network transfers the security resources in the business resources of the sequencer node to the Layer 2 network management contract based on the security transaction; the Layer 2 network management contract is used to calculate the loss compensation amount of the transaction with the account root when it is determined that the confirmation and revocation of the transaction with the account root is successful, and transfer the business resources corresponding to the loss compensation amount to the business account based on the security resources.

[0132] The business account can be the on-chain account corresponding to the business object on the blockchain. A guarantee transaction can be a transaction in which the sequencer node transfers guarantee resources to the Layer 2 network management contract. Guarantee resources can be resources used by the sequencer node to ensure that the execution order of transactions is not tampered with. Optionally, the guarantee resource amount of the sequencer node in the Layer 2 network contract should be greater than or equal to the guarantee resource amount threshold. That is, if a Layer 1 network node detects that the guarantee resources for the sequencer node in the Layer 2 network management contract are less than the resource amount, it needs to notify the sequencer node to transfer the guarantee resources to the Layer 2 network management contract. The Layer 2 network node can then send a guarantee transaction to the Layer 1 network node to transfer the guarantee resources to the Layer 2 network management contract, ensuring that the guarantee resources for the sequencer node in the Layer 2 network management contract are greater than the resource amount threshold. If the guarantee resource amount of the sequencer node in the Layer 2 network is less than the resource amount threshold, the Layer 1 network node may not process the business transactions (specifically, transactions with account roots) initiated by the business object submitted by the sequencer node.

[0133] The method provided in this application embodiment allows for querying the root of the committed transaction account corresponding to the original transaction after it is generated, and then adding the root of the committed transaction account to the original transaction to obtain a transaction with an account root. Subsequently, the root of the committed transaction account can be used to detect at any time whether the transaction order of the transaction with an account root has been tampered with during the actual execution process. Once a change in the transaction status of the transaction with an account root is detected, a challenge transaction can be sent to the first-layer network to revoke the transaction with an account root, thereby ensuring the interests of the business object and the security of transaction execution.

[0134] Further, please see Figure 5 , Figure 5 This is a schematic diagram of the interactive process of a method for submitting a transaction root with an account based on a committed transaction account root, provided in an embodiment of this application. For example... Figure 5 As shown, the entire interaction process involves a service terminal, a sequencer node, and a layer 1 network node. The service terminal can be one of the aforementioned... Figure 2a The corresponding service terminal 21a shown in the embodiment; the sequencer node can be the one described above. Figure 2a The corresponding embodiment shows a two-layer network node 22a; a one-layer network node can be the one described above. Figure 2a Any one of the layer network nodes in the layer network 300a shown.

[0135] The interaction process may include at least the following steps S1001-S1010:

[0136] Step S1001: The business terminal generates the original transaction and determines the transaction-related account of the original transaction.

[0137] Specifically, the business terminal can construct the original transaction locally and submit it to the Layer 2 network (i.e., the above). Figure 3 The original transaction described in the corresponding embodiment can be represented by the following transaction structure:

[0138] TX =<From,To,Value,Data>

[0139] In this context, TX represents the original transaction, which has the same structure as traditional blockchain Layer 2 network transactions, containing the four fields mentioned above. The From and To fields are the account addresses; the From field typically indicates the sender of the transaction, and the To field typically indicates the receiver. The Value field primarily indicates the value of the transaction; for example, in a digital resource transfer transaction, it represents the quantity of digital resources transferred from the sender to the receiver. The Data field is more flexible; it typically contains additional information related to the transaction, such as transaction notes, a description of the transaction's purpose, smart contract code, or parameters.

[0140] Specifically, the transaction-related accounts of the original transaction refer to the business accounts whose transaction status changes after the execution of the original transaction. It should be understood that the execution of the original transaction does not only change the status of accounts with "From" and "To" directives. When a transaction involves calling a smart contract, the smart contract may call other smart contracts (such as an asset routing contract calling an asset trading contract), resulting in changes to the status of N accounts. Therefore, the transaction-related accounts determined by the business terminal can include one or more business accounts, and the account address of the transaction-related account can be represented as:

[0141] Addrs=[Addr1,Addr2,…,AddrN]

[0142] Here, Addrs represents a set of account addresses containing transaction-related accounts. Addr1 can be the account address of business account 1, Addr2 can be the account address of business account 2, and AddrN can be the account address of business account N. The business terminal can perform the execution calculation of the original transaction locally to obtain this array, thereby determining the transaction-related accounts of the original transaction.

[0143] In step S1002, the service terminal sends an account status root query request to the sequencer node. This request may include the hash value of the original transaction and the associated account address.

[0144] Specifically, the account state root query request is used to retrieve the hash root of the account state of the transaction-related account. The related account organization in the Layer 2 network world state can be as described above. Figure 2aAs shown in section 204a, in the organization of the world state tree in a blockchain system, smart contract type accounts (Accounts) each have multiple stored key-value pairs (i.e., the states of these accounts). These multiple key-value pairs form a subtree of the account and have a root hash. Therefore, in this application, an account root can be generated. An account root is used to represent the account state of an account at a certain moment. The account root can be represented by the hash of an account's address and its subtree, such as:

[0145] AccountRoot i = <Addr i H i >

[0146] Among them, AccountRoot i The account root used to characterize account i, Addr i The account address used to represent account i, H i The root hash used to represent the account state subtree (or account subtree) of account i in the second-level world state.

[0147] In step S1003, the sequencer node generates transaction commitment information based on the account status root query request; the transaction commitment information includes the hash value of the original transaction, the committed transaction account root, and signature information.

[0148] Specifically, the signature information is as described above. Figure 4 The implementation process of the aforementioned commitment signature information and step S1003 can be found in the above description. Figure 4 The description of step S201 in the corresponding embodiment will not be repeated here.

[0149] Specifically, transaction commitment information can be represented as follows:

[0150] Commitment =<TX.Hash,AccountRoots,Sig>

[0151] Here, TX.Hash refers to the hash value of the original transaction, and AccountRoots refers to the set of all committed transaction account roots containing the original transaction, which is the aforementioned... Figure 3 The root of the committed transaction account in the corresponding embodiment, Sig is the sequencer node pair.<TX.Hash,AccountRoots> The signature information.

[0152] In step S1004, the sequencer node returns transaction commitment information to the business terminal.

[0153] In step S1005, after the business terminal verifies the signature information, it adds the promised transaction account root to the original transaction to obtain a transaction with account root.

[0154] Specifically, after the business terminal verifies the signature of Sig, it will add AccountRoots to the original transaction. Therefore, in this application, the transaction structure of a transaction with account roots is as follows:

[0155] TX′=<From,To,Value,Data,AccountRoots>

[0156] In step S1006, after the business terminal signs the transaction with the account root, it sends it to the sequencer node.

[0157] Specifically, the business terminal can sign TX′ with its own private key and then submit it to the given sequencer node.

[0158] In step S1007, the sequencer node verifies the committed transaction account root contained in the transaction with account root. After the verification is successful, it records the second-level world state root before and after the execution of the transaction with account root.

[0159] Specifically, during the execution of steps S1004 to S1006, there is a certain time difference (generally a very short time). Therefore, the account root of the transaction-related account may have changed. Thus, the sequencer node needs to traverse the user-submitted TX′.AccountRoots to check if all account roots match the current world state's corresponding account root. If they match, the transaction is accepted, and a confirmation message is returned to the business object. Furthermore, the sequencer node needs to record the values ​​of the second-level world state root before and after this transaction execution for future rollback. The recording format can be:

[0160] StateRoot′=Exec(TX′,StateRoot)

[0161] Where Exec is the function of the sequencer to execute TX′ in the second layer network, StateRoot is the second layer world state root before the execution of the transaction TX′ with account root, and StateRoot′ is the second layer world state root after the execution of the transaction TX′ with account root.

[0162] In step S1008, the sequencer node returns an acceptance confirmation message to the service terminal.

[0163] Specifically, confirming receipt of the information is as described above. Figure 4 The transaction acceptance information shown in the corresponding embodiment.

[0164] Step S1009: The sequencer node sends a transaction with the account root to the first-layer network node.

[0165] In step S1010, the first-layer network node records the transaction with the account root on the blockchain through the second-layer network management contract.

[0166] The Layer 2 network transaction (i.e., transaction with account root) submission technology based on the commitment transaction account root provided in this application embodiment can prevent the sequencer node from affecting the smart contract state before the user's transaction through preemptive attacks, thereby ensuring that the Layer 2 transaction state remains unchanged. This is achieved by requesting the sequencer node to make a commitment to the associated account state root before the transaction is executed.

[0167] It is understandable that after determining the committed transaction account root corresponding to the transaction with the account root, the business object or challenge node can check whether the execution order of the transaction with the account root has been tampered with (i.e., whether the associated account state has been changed before execution). If it is determined that the execution order of the transaction with the account root has been tampered with, a challenge is launched to the first-layer network. If the challenge is successful, the first-layer network will revoke the on-chain upload of the transaction with the account root. For details on the transaction detection and challenge process, please refer to [link to relevant documentation]. Figure 6 , Figure 6 This is a schematic diagram of the interaction process of a transaction detection and challenge method based on a committed transaction account root, provided in an embodiment of this application. Figure 6 As shown, the entire interaction process involves the business terminal, sequencer node, challenger node, and a first-layer network node. This interaction process may include at least the following steps S1011-S1018:

[0168] Step S1011: The sequencer node pays the guaranteed resources to the first-layer network node.

[0169] Specifically, the sequencer node can send a guarantee transaction to a first-layer network node, which can then transfer the sequencer node's guarantee resources to a second-layer network management contract deployed within the first-layer network node based on the guarantee transaction. For example, the payment process can be represented as:

[0170]

[0171] Here, SEQUENCER specifies the sequencer node, L2Contract refers to the Layer 2 network contract, and Amount refers to the guaranteed resources. The implementation process of step S1011 can be found above. Figure 4 The optional description of step S203 in the corresponding embodiment will not be repeated here.

[0172] In step S1012, the business terminal sends a transaction detection request to the challenger node. This request includes the hash value of the account root transaction and the transaction commitment information.

[0173] In step S1013, the challenger node performs network confirmation detection processing on transactions with account roots based on the transaction detection request.

[0174] Step S1014: When a transaction with an account root is detected to have been confirmed by a first-layer network node, the challenger node obtains the real transaction account root from the first-layer network node.

[0175] Specifically, the implementation process of steps S1012 to S1014 can be found above. Figure 3 The descriptions of steps S101-S102 in the corresponding embodiments will not be repeated here.

[0176] Step S1015: The challenger node verifies whether the promised transaction account root in the transaction commitment information is consistent with the real transaction account root.

[0177] For example, the verification process can be represented by the following formula (Formula 1).

[0178] ExactAccountRoot i ==AccountRoot i Formula 1

[0179] Among them, ExactAccountRoot i AccountRoot is used to represent the actual transaction account root of account i. i The root of the committed transaction account used to represent account i.

[0180] If the actual transaction account root and the committed transaction account root of the transaction associated with the transaction with the account root are the same, then the verification is determined to be consistent; if one is different, then the verification is determined to be inconsistent.

[0181] Optionally, the implementation process of steps S1013 to S1015 above can also be achieved by the interaction between the service terminal and the first-layer network node.

[0182] In step S1016, if the verification is inconsistent, the challenger node can send a challenge transaction to the first-layer network node.

[0183] Specifically, a challenger node can send a challenge transaction to a first-layer network node, which can be represented as:

[0184]

[0185] Here, CHALLENGER refers to the challenger node, L2Contract refers to the Layer 2 network management contract, Data refers to the Data field contained in the challenge transaction, TX'.Hash refers to the hash value of the transaction with account root, Commitment refers to the transaction commitment information, and States refers to the relevant transaction states and their Merkle proofs before the execution of the transaction with account root.

[0186] Step S1017: The first-layer network node performs transaction reversal processing on the challenge transaction pair with the account root transaction.

[0187] Specifically, the implementation process of step S1017 can be found in the above description. Figure 3 The specific description of step S103 in the corresponding embodiment will not be repeated here.

[0188] In step S1018, if the transaction with the account root is cancelled, the first-layer network node deducts the guaranteed resources of the sequencer node through the second-layer network management contract.

[0189] Specifically, the implementation process of step S1018 can be found above. Figure 4 The optional description of step S203 in the corresponding embodiment will not be repeated here.

[0190] The Layer 2 network transaction rollback technology based on the commitment transaction root detection and challenge of transactions with account roots, as described in the embodiments of this application, can detect changes in the transaction status of the final submitted transaction with account roots in the Layer 1 network through challenger nodes. Furthermore, it can enable the transaction status of the transaction associated with the transaction with account roots to be rolled back when affected by front-run attacks or other attacks, thereby reversing erroneous transaction execution results and improving security.

[0191] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a data processing device based on a multi-layer blockchain network provided in an embodiment of this application. The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; as shown... Figure 7 As shown, the data processing device 1 based on a multi-layer blockchain network can be a computer program (including program code) running on a challenger node (e.g., the aforementioned second-layer network node 12a). For example, the data processing device 1 based on a multi-layer blockchain network is an application software. It is understood that the data processing device 1 based on a multi-layer blockchain network can be used to execute the corresponding steps in the data processing method based on a multi-layer blockchain network provided in the embodiments of this application. Figure 7 As shown, the data processing device 1 based on a multi-layer blockchain network may include: a detection module 110, an acquisition module 120, and a challenge module 130.

[0192] The detection module 110 is used to receive transaction detection requests sent by the business terminal and perform network confirmation detection processing on transactions with account roots according to the transaction detection requests. The transaction detection request includes the committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first world state. The first world state is the Layer 2 network world state when the sequencer node receives the account root query request for the original transaction. The transaction with account root is generated based on the original transaction and the committed transaction account root.

[0193] The acquisition module 120 is used to acquire the real transaction account root when it is detected that a transaction with an account root has been confirmed by a first-layer network node. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with the account root.

[0194] Challenge module 130 is used to generate a challenge transaction for the transaction with account root if it is determined that the real transaction account root is inconsistent with the promised transaction account root, and send the challenge transaction to the first-level network node; the challenge transaction is used to instruct the first-level network node to perform confirmation and cancellation processing on the transaction with account root based on the second-level network management contract.

[0195] The transaction detection request also includes the hash value of the transaction with the account root and the transaction commitment information; the transaction commitment information includes the hash value of the original transaction; the committed transaction account root belongs to the transaction commitment information; the transaction commitment information is generated by the sequencer node based on the account root query request and the first-world state;

[0196] The data processing device 1 based on a multi-layer blockchain network further includes: a request verification module 140;

[0197] The request verification module 140 is specifically used for:

[0198] Retrieve the root transaction based on the hash value of the root transaction, and extract the original transaction fields from the root transaction; the original transaction fields are the same fields in the root transaction and the original transaction.

[0199] The original transaction fields are hashed to obtain the hash of the original transaction fields.

[0200] If the hash of the original transaction field is the same as the hash value of the original transaction, then the detection module 110 is called to perform the step of network confirmation detection processing of the transaction with account root according to the transaction detection request.

[0201] The detection module 110 is specifically used for:

[0202] Based on the transaction detection request, a transaction on-chain query request for transactions with account roots is generated, and the transaction on-chain query request is sent to the first-layer network node so that the first-layer network node can determine the transaction on-chain result of transactions with account roots based on the transaction on-chain query request.

[0203] If the transaction is confirmed to be on-chain, then it is determined that the transaction with the account root has been confirmed by a network node at the first layer.

[0204] If the result of a transaction being recorded on the blockchain is determined to be a result of a transaction not being recorded on the blockchain, then a waiting timer is created;

[0205] When the duration recorded by the waiting timer equals the query waiting duration, a new transaction on-chain query request for the transaction with the account root is generated and sent to the first-layer network node so that the first-layer network node can determine the new transaction on-chain result for the transaction with the account root based on the new transaction on-chain query request.

[0206] The second world state includes the Layer 2 network account address and the first account state root hash corresponding to the Layer 2 network account address; the Layer 2 network account address refers to the account address of the business account registered in the Layer 2 network; the transaction-related account belongs to the business account registered in the Layer 2 network; the commitment transaction account root includes the commitment account address; the commitment account address refers to the account address of the transaction-related account.

[0207] Module 120 is used specifically for:

[0208] When a transaction with an account root is detected to have been confirmed by a first-level network node, a status root query request is sent to the first-level network node.

[0209] Receive the target second-layer world state root sent by the first-layer network node according to the state root query request, and obtain the second world state corresponding to the target second-layer world state root;

[0210] The committed account address is determined as the real account address, and the first account state root hash corresponding to the Layer 2 network account address that is the same as the real account address in the second world state is determined as the real account state root hash.

[0211] Generate the real transaction account root based on the real account address and the real account status root hash.

[0212] Challenge module 130 is specifically used for:

[0213] Obtain the transaction status information of transactions with account roots in the second world state, and generate a Merkel proof for the transaction status information based on the second world state.

[0214] Based on the real transaction account root, transaction status information, and Merkel proof, a challenge transaction is generated and sent to the first-layer network node. The first-layer network node is used to perform Merkel verification calculation on the transaction status hash and Merkel proof through the second-layer network management contract to obtain the world state root to be verified. When the world state root to be verified is the same as the target second-layer world state root, the committed transaction account root contained in the transaction with account root is obtained. It is also used to revert the latest recorded second-layer world state root to the target second-layer world state root when the obtained committed transaction account root is different from the real transaction account root.

[0215] Please see Figure 8 , Figure 8 This is a schematic diagram of another data processing device based on a multi-layer blockchain network provided in this application embodiment. The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network; the second-layer network nodes in the second-layer network include sequencer nodes and challenger nodes; as shown... Figure 8 As shown, the data processing device 2 based on a multi-layer blockchain network can be a computer program (including program code) running on a sequencer node (e.g., the aforementioned second-layer network node 13a). For example, the data processing device 2 based on a multi-layer blockchain network is an application software. It is understood that the data processing device 2 based on a multi-layer blockchain network can be used to execute the corresponding steps in the data processing method based on a multi-layer blockchain network provided in the embodiments of this application. Figure 8 As shown, the data processing device 2 based on a multi-layer blockchain network may include: a transaction commitment module 210, a transaction verification module 220, and a transaction acceptance module 230.

[0216] The transaction commitment module 210 is used to receive the account root query request sent by the business terminal for the original transaction, generate transaction commitment information based on the account root query request and the first-world state, and send the transaction commitment information to the business terminal. The first-world state refers to the Layer 2 network world state when the account root query request is received. The transaction commitment information includes the committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first-world state. The transaction commitment information is used to instruct the business terminal to add the committed transaction account root to the original transaction to obtain a transaction with an account root.

[0217] Transaction verification module 220 is used to receive transactions with account roots sent by business terminals, perform transaction verification processing on transactions with account roots according to the third world state, and obtain transaction verification results; the third world state refers to the Layer 2 network world state when the transaction with account roots is received.

[0218] The transaction acceptance module 230 is used to submit the transaction with account root to the first-layer network node if the transaction verification result is a successful transaction verification result, and send a transaction acceptance message to the business terminal. This allows the business terminal to generate a transaction detection request based on the transaction acceptance message and transaction commitment information, and send the transaction detection request to the challenger node. The transaction detection request is used to instruct the challenger node to perform network confirmation detection processing on the transaction with account root. The challenger node is used to send a challenge transaction to the first-layer network node when it detects that the transaction with account root has been confirmed by the first-layer network node and the real transaction account root is inconsistent with the committed transaction account root. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with account root. The challenge transaction is used to instruct the first-layer network node to perform confirmation and revocation processing on the transaction with account root based on the second-layer network management contract.

[0219] The first-world state includes the Layer 2 network account address and the corresponding second account state root hash; the Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network; the account root query request includes the account address of the transaction-related account and the hash value of the original transaction; the transaction-related account refers to the business account whose account state was changed during the execution of the original transaction.

[0220] Transaction commitment module 210 is specifically used for:

[0221] In the first world state, obtain the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the account associated with the transaction, and use it as the root hash of the committed account state;

[0222] Generate the committed transaction account root based on the account address and the committed account state root hash;

[0223] The hash value of the original transaction and the root of the committed transaction account are signed using the private key of the sequencer node to obtain the commitment signature information;

[0224] The transaction commitment information is generated based on the committed transaction account root, the hash value of the original transaction, and the commitment signature information. The transaction commitment information is then sent to the business terminal. The business terminal is used to verify the commitment signature information based on the committed transaction account root, the hash value of the original transaction, and the public key of the sequencer node. When the verification is successful, the committed transaction account root is added to the original transaction to obtain a transaction with account root. The business terminal is also used to send the transaction with account root to the sequencer node.

[0225] The third world state includes the Layer 2 network account address and the root hash of the third account state corresponding to the Layer 2 network account address;

[0226] Transaction verification module 220 is specifically used for:

[0227] From transactions with account roots, obtain the committed transaction account root; the committed transaction account root contains the account address and the committed account state root hash;

[0228] In the third world state, the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the account associated with the transaction is obtained and used as the root hash of the transaction verification account state.

[0229] If the root hash of the transaction verification account is the same as the root hash of the commitment account, then the transaction verification result is determined to be a successful transaction verification result.

[0230] If the root hash of the transaction verification account state is different from the root hash of the commitment account state, the transaction verification result is determined to be a transaction verification failure result.

[0231] The data processing device 2 based on a multi-layer blockchain network also includes: a first commitment module 240;

[0232] The first commitment module 240 is specifically used for:

[0233] If the transaction verification result is a transaction verification failure, a new commitment transaction account root is generated based on the account address and the transaction verification account state root hash. Account state update information is generated based on the new commitment transaction account root and sent to the business terminal. The account state update information is used to instruct the business terminal to add the new commitment transaction account root to the original transaction to obtain a new transaction with account root. The new transaction with account root is then sent to the sequencer node.

[0234] The data processing device 2 based on a multi-layer blockchain network further includes: a second commitment module 250;

[0235] The second commitment module 250 is specifically used for:

[0236] If the transaction verification result is a transaction verification failure, a transaction rejection message is sent to the business terminal so that the business terminal can generate a new account root query request for the original transaction based on the transaction rejection message, and send the new account root query request to the sequencer node.

[0237] In the first-layer network, there are sequencer node accounts corresponding to sequencer nodes and business accounts of business objects corresponding to business terminals. The sequencer node accounts include the business resources of the sequencer nodes.

[0238] The data processing device 2 based on a multi-layer blockchain network also includes: a guarantee module 260;

[0239] The guarantee module 260 is specifically used for:

[0240] A guarantee transaction is sent to the Layer 1 network so that the Layer 1 network can transfer the guarantee resources in the business resources of the sequencer node to the Layer 2 network management contract based on the guarantee transaction. The Layer 2 network management contract is used to calculate the loss compensation amount of the transaction with the account root when it is determined that the confirmation and cancellation of the transaction with the account root is successful, and transfer the business resources corresponding to the loss compensation amount to the business account based on the guarantee resources.

[0241] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As shown above, Figure 7 The data processing device 1 based on a multi-layer blockchain network in the corresponding embodiment or Figure 8 The data processing device 2 based on a multi-layer blockchain network in the corresponding embodiments can all be applied to a computer device 1000. The computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 9 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0242] In such Figure 9 In the computer device 1000 shown, the network interface 1004 provides network communication elements; the user interface 1003 is mainly used to provide an input interface for users; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the data processing method based on the multi-layer blockchain network described in any of the corresponding embodiments above, which will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0243] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing the computer program executed by the data processing device 1 and the data processing device 2 based on the multi-layer blockchain network mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can perform the data processing method based on the multi-layer blockchain network described in the preceding embodiments. Therefore, it will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0244] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0245] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in any of the preceding corresponding embodiments. Additionally, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the embodiments of the computer program product or computer program involved in this application, please refer to the description of the method embodiments of this application.

[0246] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0247] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve the predetermined function, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0248] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0249] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on a multi-layer blockchain network, characterized in that, The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network. The Layer 2 network nodes in the Layer 2 network include sequencer nodes and challenger nodes; The method is executed by the challenger node, and the method includes: Receive a transaction detection request sent by a business terminal, and perform network confirmation detection processing on transactions with account root according to the transaction detection request; The transaction detection request includes a committed transaction account root; the committed transaction account root is used to identify the account status of the transaction-related account in the first world state; the first world state refers to the Layer 2 network world state when the sequencer node receives an account root query request for the original transaction; the transaction with account root is generated based on the original transaction and the committed transaction account root; When the transaction with the account root is detected to be confirmed by the first-layer network node, the real transaction account root is obtained; the real transaction account root is used to identify the account status of the transaction-related account in the second world state; the second world state refers to the second-layer network world state corresponding to the target second-layer world state root; the target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with the account root. If it is determined that the actual transaction account root is inconsistent with the committed transaction account root, a challenge transaction is generated for the transaction with account root, and the challenge transaction is sent to the first-layer network node; the challenge transaction is used to instruct the first-layer network node to perform confirmation and cancellation processing on the transaction with account root based on the second-layer network management contract.

2. The method according to claim 1, characterized in that, The transaction detection request also includes the hash value of the transaction with the account root and transaction commitment information; the transaction commitment information includes the hash value of the original transaction; the committed transaction account root belongs to the transaction commitment information; the transaction commitment information is generated by the sequencer node based on the account root query request and the first world state; The method further includes: The root transaction is obtained based on the hash value of the root transaction, and the original transaction fields are extracted from the root transaction; the original transaction fields refer to the fields that are the same in the root transaction and the original transaction. The original transaction fields are hashed to obtain the hash of the original transaction fields; If the hash of the original transaction field is the same as the hash value of the original transaction, then the step of performing network confirmation detection processing on the transaction with account root according to the transaction detection request is executed.

3. The method according to claim 1, characterized in that, The process of performing network confirmation detection on transactions with account roots according to the transaction detection request includes: Based on the transaction detection request, a transaction on-chain query request for the transaction with account root is generated, and the transaction on-chain query request is sent to the first-layer network node so that the first-layer network node can determine the transaction on-chain result of the transaction with account root based on the transaction on-chain query request. If the transaction on-chain result is determined to be a transaction that has been on-chain, then it is determined that the transaction with the account root has been confirmed by the first-layer network node. If it is determined that the transaction was not recorded on the blockchain, then a waiting timer is created; When the duration recorded by the waiting timer equals the query waiting duration, a new transaction on-chain query request for the transaction with the account root is generated, and the new transaction on-chain query request is sent to the first-layer network node so that the first-layer network node can determine the new transaction on-chain result of the transaction with the account root based on the new transaction on-chain query request.

4. The method according to claim 1, characterized in that, The second world state includes a Layer 2 network account address and a first account state root hash corresponding to the Layer 2 network account address; the Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network; the transaction-related account belongs to a business account registered in the Layer 2 network; the committed transaction account root includes a committed account address; the committed account address refers to the account address of the transaction-related account; When the transaction with the account root is detected to have been confirmed by the first-layer network node, the process of obtaining the real transaction account root includes: When it is detected that the transaction with the account root has been confirmed by the first-layer network node, a status root query request is sent to the first-layer network node. Receive the target second-layer world state root sent by the first-layer network node according to the state root query request, and obtain the second world state corresponding to the target second-layer world state root; The promised account address is determined as the real account address, and the first account state root hash corresponding to the Layer 2 network account address that is the same as the real account address in the second world state is determined as the real account state root hash. A real transaction account root is generated based on the real account address and the real account status root hash.

5. The method according to claim 1, characterized in that, The process of generating a challenge transaction for the transaction with the account root and sending the challenge transaction to the first-layer network node includes: Obtain the transaction status information of the transaction with the account root in the second world state, and generate a Merkel proof for the transaction status information based on the second world state; Based on the real transaction account root, the transaction status information, and the Merkel proof, a challenge transaction is generated and sent to the first-layer network node. The first-layer network node is used to perform Merkel verification calculation on the transaction status hash and the Merkel proof through the second-layer network management contract to obtain the world state root to be verified. When the world state root to be verified is the same as the target second-layer world state root, the committed transaction account root contained in the transaction with account root is obtained. It is also used to revert the latest recorded second-layer world state root to the target second-layer world state root when the obtained committed transaction account root is different from the real transaction account root.

6. A data processing method based on a multi-layer blockchain network, characterized in that, The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network. The Layer 2 network nodes in the Layer 2 network include sequencer nodes and challenger nodes; The method is executed by the sequencer node, and the method includes: The system receives an account root query request sent by a business terminal for an original transaction, generates transaction commitment information based on the account root query request and a first world state, and sends the transaction commitment information to the business terminal. The first world state refers to the Layer 2 network world state when the account root query request is received. The transaction commitment information includes a committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first world state. The transaction commitment information is used to instruct the business terminal to add the committed transaction account root to the original transaction, resulting in a transaction with an account root. The system receives the transaction with account root sent by the service terminal, performs transaction verification processing on the transaction with account root according to the third world state, and obtains the transaction verification result; the third world state refers to the Layer 2 network world state when the transaction with account root is received. If the transaction verification result is a successful transaction verification result, the transaction with account root is submitted to the first-layer network node, and a transaction acceptance message is sent to the business terminal, so that the business terminal generates a transaction detection request based on the transaction acceptance message and the transaction commitment information, and sends the transaction detection request to the challenger node; the transaction detection request is used to instruct the challenger node to perform network confirmation detection processing on the transaction with account root. The challenger node sends a challenge transaction to the first-layer network node when it detects that the transaction with the account root has been confirmed by the first-layer network node and that the real transaction account root is inconsistent with the committed transaction account root. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with the account root. The challenge transaction is used to instruct the first-layer network node to perform confirmation and revocation processing on the transaction with the account root based on the second-layer network management contract.

7. The method according to claim 6, characterized in that, The first world state includes a Layer 2 network account address and a second account state root hash corresponding to the Layer 2 network account address; the Layer 2 network account address refers to the account address of a business account registered in the Layer 2 network; the account root query request includes the account address of the transaction-associated account and the hash value of the original transaction; the transaction-associated account refers to a business account whose account state is changed during the execution of the original transaction; The step of generating transaction commitment information based on the account root query request and the first-world state, and sending the transaction commitment information to the business terminal, includes: In the first world state, obtain the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the transaction-related account, and use it as the root hash of the committed account state; Generate a commitment transaction account root based on the account address and the commitment account state root hash; The hash value of the original transaction and the root of the committed transaction account are signed using the private key of the sequencer node to obtain the commitment signature information; Transaction commitment information is generated based on the committed transaction account root, the hash value of the original transaction, and the commitment signature information, and the transaction commitment information is sent to the business terminal. The business terminal is used to verify the commitment signature information based on the committed transaction account root, the hash value of the original transaction, and the public key of the sequencer node. When the verification is successful, the committed transaction account root is added to the original transaction to obtain a transaction with account root. The business terminal is also used to send the transaction with account root to the sequencer node.

8. The method according to claim 6, characterized in that, The third world state includes the Layer 2 network account address and the third account state root hash corresponding to the Layer 2 network account address. The step of performing transaction verification processing on the transaction with account root based on the third-world state to obtain the transaction verification result includes: The committed transaction account root is obtained from the transaction with the account root; the committed transaction account root includes the account address and the committed account state root hash; In the third world state, the root hash of the account state corresponding to the Layer 2 network account address that is the same as the account address of the transaction-related account is obtained and used as the root hash of the transaction verification account state. If the root hash of the transaction verification account status is the same as the root hash of the commitment account status, then the transaction verification result is determined to be a successful transaction verification result. If the root hash of the transaction verification account state is different from the root hash of the commitment account state, then the transaction verification result is determined to be a transaction verification failure result.

9. The method according to claim 8, characterized in that, Also includes: If the transaction verification result is a transaction verification failure, a new commitment transaction account root is generated based on the account address and the transaction verification account state root hash. Account state update information is generated based on the new commitment transaction account root, and the account state update information is sent to the business terminal. The account state update information is used to instruct the business terminal to add the new commitment transaction account root to the original transaction to obtain a new transaction with account root, and the new transaction with account root is sent to the sequencer node.

10. The method according to claim 1, characterized in that, Also includes: If the transaction verification result is a transaction verification failure result, a transaction rejection message is sent to the business terminal, so that the business terminal generates a new account root query request for the original transaction based on the transaction rejection message, and sends the new account root query request to the sequencer node.

11. The method according to claim 6, characterized in that, The first-layer network has registered sequencer node accounts corresponding to the sequencer nodes and business accounts of business objects corresponding to the business terminals. The sequencer node accounts include the business resources of the sequencer nodes. The method further includes: A guarantee transaction is sent to the first-layer network so that the first-layer network transfers the guaranteed resources in the business resources of the sequencer node to the second-layer network management contract based on the guarantee transaction; the second-layer network management contract is used to calculate the loss compensation amount of the transaction with account root when it is determined that the confirmation and cancellation of the transaction with account root is successful, and transfer the business resources corresponding to the loss compensation amount to the business account based on the guaranteed resources.

12. A data processing device based on a multi-layer blockchain network, characterized in that, The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network. The Layer 2 network nodes in the Layer 2 network include sequencer nodes and challenger nodes; The device is operated by the challenger node, and the device includes: The detection module is used to receive transaction detection requests sent by business terminals and perform network confirmation detection processing on transactions with account roots according to the transaction detection requests. The transaction detection request includes a committed transaction account root. The committed transaction account root is used to identify the account status of the transaction-related account in the first world state. The first world state refers to the Layer 2 network world state when the sequencer node receives an account root query request for the original transaction. The transaction with account root is generated based on the original transaction and the committed transaction account root. The acquisition module is used to acquire the real transaction account root when the transaction with the account root is confirmed by the first-layer network node. The real transaction account root is used to identify the account status of the transaction-related account in the second world state. The second world state refers to the second-layer network world state corresponding to the target second-layer world state root. The target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with the account root. The challenge module is used to generate a challenge transaction for the transaction with the account root if it is determined that the real transaction account root is inconsistent with the committed transaction account root, and send the challenge transaction to the first-layer network node; the challenge transaction is used to instruct the first-layer network node to perform confirmation and cancellation processing on the transaction with the account root based on the second-layer network management contract.

13. A data processing device based on a multi-layer blockchain network, characterized in that, The multi-layer blockchain network includes a first-layer network and a second-layer network; a second-layer network management contract is deployed on the first-layer network nodes in the first-layer network. The Layer 2 network nodes in the Layer 2 network include sequencer nodes and challenger nodes; The method is executed by the sequencer node, and the apparatus includes: The transaction commitment module is used to receive an account root query request sent by a business terminal for an original transaction, generate transaction commitment information based on the account root query request and a first world state, and send the transaction commitment information to the business terminal; the first world state refers to the Layer 2 network world state when the account root query request is received; the transaction commitment information includes a committed transaction account root; the committed transaction account root is used to identify the account status of the transaction-related account in the first world state; the transaction commitment information is used to instruct the business terminal to add the committed transaction account root to the original transaction, resulting in a transaction with an account root; The transaction verification module is used to receive the transaction with account root sent by the service terminal, perform transaction verification processing on the transaction with account root according to the third world state, and obtain the transaction verification result; the third world state refers to the Layer 2 network world state when the transaction with account root is received. The transaction acceptance module is used to submit the transaction with account root to the first-layer network node if the transaction verification result is a successful transaction verification result, and send a transaction acceptance message to the business terminal so that the business terminal generates a transaction detection request based on the transaction acceptance message and the transaction commitment information, and sends the transaction detection request to the challenger node; the transaction detection request is used to instruct the challenger node to perform network confirmation detection processing on the transaction with account root; the challenger node is used to send a challenge transaction to the first-layer network node when it detects that the transaction with account root has been confirmed by the first-layer network node and the real transaction account root is inconsistent with the committed transaction account root; the real transaction account root is used to identify the account status of the transaction-related account in the second world state; the second world state refers to the second-layer network world state corresponding to the target second-layer world state root; the target second-layer world state root refers to the latest second-layer world state root recorded by the first-layer network node when confirming the transaction with account root; the challenge transaction is used to instruct the first-layer network node to perform confirmation and revocation processing on the transaction with account root based on the second-layer network management contract.

14. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-11.

16. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they can perform the method described in any one of claims 1-11.

Images