Method for implementing rollup of layer-2 network, and layer-2 network

Abstract

A method for implementing the rollup of a layer-2 network. The method comprises: a sequencer of a layer-2 network pulling transactions from a transaction pool, sequencing and packaging the pulled transactions, generating a first transaction root of the packaged transactions, executing the packaged transactions in sequence on the basis of an initial state before the packaged transactions are executed, and generating a first post-state root; the sequencer sending, to a prover of the layer-2 network, the packaged transactions, the first transaction root, the initial state before the packaged transactions are executed, a first pre-state root corresponding to the initial state, and the first post-state root, wherein the prover is implemented by using a trusted execution environment; the prover verifying the first transaction root and the first pre-state root; and after the two roots pass the verification, executing the packaged transactions in sequence on the basis of the initial state, so as to generate a second post-state root, after it is verified that the second post-state root is equal to the first post-state root, signing information of the packaged transactions by using a private key in the trusted execution environment, using the signature as proof, and sending the signature to a blockchain ledger of a main network by means of a second main network transaction.

Description

Method for realizing two-layer network convolution and two-layer network

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 16, 2023, with application number 202311537959.4 and application name “Method for Implementing Two-Layer Network Convolution and Two-Layer Network”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a method for implementing a two-layer network rollup and a two-layer network. Background Art

[0003] Distributed systems face the classic CAP theorem: consistency, availability, and partition tolerance. The three cannot be achieved simultaneously, often referred to as the "impossible triangle." Blockchain also faces an impossible triangle: efficiency, decentralization, and security. While this blockchain "impossible triangle" hasn't been definitively theoretically demonstrated, it serves as a summary of existing blockchain systems. Efficiency, decentralization, and security are defined as follows: Efficiency is measured in terms of the number of transactions processed per second, or TPS (Transaction Per Second).

[0004] Decentralization: The threshold for participating nodes is low enough to ensure that there are a large number of distributed nodes in the system.

[0005] Security: It is difficult to attack the blockchain.

[0006] To address the aforementioned blockchain "impossible triangle," Ethereum (also known as "Mainnet" or "Layer 1"; other popular public blockchain projects, such as Binance's BSC and TRON, also fall under the Layer 1 / Mainnet category) has chosen security and decentralization at the expense of efficiency, currently boasting only approximately 12-15 transactions per second. Layer 1 becomes congested when a large number of transactions need to be processed, especially those with complex operations. In addition to standard transfers, Layer 1 also serves as the primary platform for popular applications such as DeFi (decentralized finance) and NFTs (non-fungible tokens). When transactions are prevalent, Layer 1 congestion becomes severe, resulting in significant transaction delays that can impact user experience.

[0007] Furthermore, high gas fees (or transaction fees) often become a barrier to transactions. Despite the shift from Proof-of-Work (PoW) to Proof-of-Stake (PoS), this merely changes the way blockchain recordkeeping is obtained, while the transaction fees paid to nodes that obtain recordkeeping rights have not significantly decreased. This is because gas fees are designed to target the costs of executing transactions (including executing smart contract code) by nodes. If these costs remain unchanged, gas fees will not decrease. For example, the transaction fee for a currency exchange on a decentralized exchange can exceed $100 during periods of congestion, making it prohibitive for many users.

[0008] Layer 2 technology is a scalability solution built on Layer 1, aiming to address Layer 1's low efficiency and high transaction fees. As shown in Figure 1, transactions can be executed quickly on Layer 2, which then synchronizes the final state back to Layer 1 at regular intervals. Layer 2 is dedicated to providing high-speed transaction processing, while Layer 1 ensures security and decentralization. This reduces pressure on Layer 1 while significantly reducing gas fees for executing transactions on Layer 2. The gas fees required to synchronize the final state of Layer 2 transactions (rather than the entire state on Layer 2) back to Layer 1 can also be significantly reduced. Building Layer 2 on Layer 1 effectively separates the execution of transactions or contracts from the storage of their final state, moving the execution process to Layer 2, while Layer 1 only needs to store the final state. This design ensures the correctness of the execution of transactions or contracts on Layer 2, and ensures that the state written to Layer 1 is consistent with the results of correct execution on Layer 2.

[0009] Ethereum's Layer 2 includes a mechanism called Rollup. The core idea of ​​Rollup, as shown in Figure 1, is to store credentials that can verify the transaction process on Layer 1, while running the transaction process (computation process) and state storage on Layer 2. The so-called transaction process credentials, including a set of pre-transaction states (Pre-State) and post-transaction states (Post-State), as well as the transaction itself, can be used to verify the correctness of the state transitions corresponding to this set of transactions. They can also be used to restore the execution process of all transactions and the status of all accounts on Layer 2, thereby eliminating security risks caused by data availability on Layer 2.

[0010] Summary of the Invention

[0011] This specification provides a method and a layer 2 network for implementing layer 2 network convolution, which is implemented by:

[0012] A method for implementing a layer 2 network rollup, comprising:

[0013] The sequencer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transactions, and executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed to generate a first post-state root;

[0014] The sequencer sends the packaged transaction, the first transaction root, the SPV proof of the pre-execution read set of the packaged transaction, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented using a trusted execution environment;

[0015] The prover verifies the first transaction root and verifies the first previous state root based on the SPV proof of the packaged transaction read set; after both verifications are passed, the packaged transaction is executed in sequence and a second subsequent state root is generated; after verifying that the second subsequent state root is equal to the first subsequent state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0016] A method for implementing a layer 2 network rollup, comprising:

[0017] The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0018] The executor and prover execute S1 and S2 in parallel:

[0019] S1: The executor generates a first transaction root for a subsequent packaged transaction, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transaction, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the execution of the subsequent packaged transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the Layer 2 network; the prover is implemented in a trusted execution environment;

[0020] S2: The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0021] A method for implementing a layer 2 network rollup, comprising:

[0022] The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0023] The executor and prover execute S3 and S4 in parallel:

[0024] S3: The executor generates a first transaction root for subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before execution of the subsequent packaged transactions, and generates a first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;

[0025] S4: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after both verifications are passed, the previous packaged transaction is executed in sequence and a second subsequent state root is generated; after verifying that the second subsequent state root is equal to the first subsequent state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0026] A method for implementing a layer 2 network rollup, comprising:

[0027] The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0028] The executor participant uses an executor to generate a first transaction root for the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and the executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0029] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0030] A method for implementing a layer 2 network rollup, comprising:

[0031] The Layer 2 network’s sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0032] The executor participant uses an executor to generate the first transaction root of the packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the second-layer network; the prover is implemented using a trusted execution environment;

[0033] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0034] A method for implementing a layer 2 network rollup, comprising:

[0035] The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0036] The executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each sequentially execute different transaction groups in the subsequent packaged transaction based on the initial state before execution of the subsequent packaged transaction, and the executor combines the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0037] The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0038] A method for implementing a layer 2 network rollup, comprising:

[0039] The Layer 2 network’s sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0040] Execute S5 and S6 in parallel:

[0041] S5: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;

[0042] S6: The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0043] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0044] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0045] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root for the packaged transactions, executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed, and generates a first post-state root; the sequencer sends the packaged transactions, the first transaction root, the SPV proof of the packaged transaction read set before the packaged transactions are executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network;

[0046] The prover is used to verify the first transaction root and the first pre-state root based on the SPV proof of the packaged transaction read set; after both verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the packaged transaction information is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the main network blockchain ledger through a second main network transaction.

[0047] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0048] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0049] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0050] The executor and prover execute S1 and S2 in parallel:

[0051] S1: The executor generates a first transaction root for a subsequent packaged transaction, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transaction, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the execution of the subsequent packaged transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the Layer 2 network; the prover is implemented in a trusted execution environment;

[0052] S2: The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0053] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0054] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0055] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0056] The executor and prover execute S3 and S4 in parallel:

[0057] S3: The executor generates a first transaction root for subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before execution of the subsequent packaged transactions, and generates a first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;

[0058] S4: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after both verifications are passed, the previous packaged transaction is executed in sequence and a second subsequent state root is generated; after verifying that the second subsequent state root is equal to the first subsequent state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0059] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0060] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0061] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0062] The executor participant uses an executor to generate a first transaction root for the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and the executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0063] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0064] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0065] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0066] The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0067] The executor participant uses an executor to generate the first transaction root of the packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the second-layer network; the prover is implemented using a trusted execution environment;

[0068] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0069] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0070] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0071] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0072] The executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each sequentially execute different transaction groups in the subsequent packaged transaction based on the initial state before execution of the subsequent packaged transaction, and the executor combines the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0073] The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0074] A second-layer network, including a transaction pool, a sequencer, and a prover, wherein:

[0075] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0076] The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0077] The executor and prover execute S5 and S6 in parallel:

[0078] S5: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;

[0079] S6: The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0080] Through the above-mentioned embodiments of the present application, TEE is used as a prover on the second-layer network. Since the transaction replay and verification in TEE are close to the speed of native execution, lower latency can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0082] FIG1 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0083] FIG2 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0084] FIG3 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0085] FIG4 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0086] FIG5 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0087] FIG6 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0088] FIG7 is a schematic diagram of the principle of an MPT tree in one embodiment;

[0089] FIG8 is a schematic diagram of the principle of an MPT tree in one embodiment;

[0090] FIG9 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0091] FIG10 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0092] FIG11 is a schematic diagram of the principle of Layer 2 in one embodiment;

[0093] FIG12 is a schematic diagram of the principle of DAG in one embodiment. DETAILED DESCRIPTION

[0094] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0095] The principle of Rollup can be specifically shown in Figures 2 and 3 (Figure 3 mainly refers to the OP-Rollup mentioned below).

[0096] The transaction creating a smart contract is sent to Layer 1. After Layer 1 consensus, each Layer 1 node can execute the transaction, completing the contract deployment. Specifically, the EVM / WASM of the blockchain node executes the transaction. The EVM is a Turing-complete virtual machine, meaning it can implement a wide range of complex logic. This is one of the greatest improvements of Ethereum, the representative of Blockchain 2.0, over Blockchain 1.0. Users can publish and call smart contracts in Ethereum on the EVM. After the smart contract deployment transaction executes, a contract account corresponding to the smart contract is generated on Layer 1. This contract account has an on-chain address and includes a balance, a counter nonce, a hash of the contract code, and the contract storage root, Storage_Root. Codehash and Storage_Root store the contract code and account storage in the contract account. The behavior of a smart contract is controlled by the contract code, while the smart contract account storage stores the contract state. In other words, smart contracts create virtual accounts on the blockchain that contain contract code and account storage. Subsequently, nodes on Layer 1 can receive transaction requests to invoke deployed smart contracts. These transaction requests may include the address of the contract being invoked, the function within the contract being invoked, and the input parameters. Generally, after consensus is reached on the transaction request, each blockchain node can independently execute the designated smart contract.

[0097] In Ethereum, the Storage_root is the hash of the root node of an MPT tree. This MPT tree organizes the storage of contract account states. MPT stands for Merkle Patricia Tree, a tree structure that combines the Merkle Tree and the Patricia Tree (a compressed prefix tree, a more space-efficient Trie). The Merkle Tree algorithm calculates a hash value for each transaction, then hashes each transaction pairwise until the top-level Merkle root is reached. Ethereum uses a modified MPT tree, such as a hexadecimal tree structure, often referred to as an MPT tree. In fact, the Ethereum block header includes three MPT tree roots: Transaction_Root (abbreviated as Tx_Root), State_Root, and Receipt_Root. State_Root is the hash value of the root of the MPT tree, which consists of the states of all accounts in the current block. The state trie pointing to State_Root is an MPT-style state trie. From the root to the leaf nodes of the MPT, a portion of the value of each node is sequentially concatenated to form an account address, which serves as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. Specifically, the key can be sha3(Address), which is the hash value of the account address (the hash algorithm used is, for example, the sha3 algorithm), and the stored value can be rlp(Account), which is the rlp (Recursive Length Prefix) encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. For externally owned accounts (EOA), only the nonce and balance are typically present, while the storageRoot and codeHash fields default to empty strings or all zeros. In other words, external accounts do not store contracts or state variables generated after contract execution. Contract accounts generally include nonce, balance, storage root, and codeHash. Whether it is an external account or a contract account, its account information is generally located in a separate leaf node.

[0098] For a Contract Account (CA) in the state trie, its storage_Root points to another MPT-formatted tree, which stores data related to state variables involved in contract execution. The MPT-formatted tree pointed to by this storage_Root is the Storage Trie, where the storage_Root stores the hash value of the Storage Trie's root node. Generally, this Storage Trie also stores key-value pairs. The key represents the address of the state variable. Its value can be the result of processing the location of the state variable declaration in the contract (a value starting from 0) using certain rules, such as sha3 (state variable declaration location) or sha3 (contract name + state variable declaration location). The value stores the value of the state variable (e.g., an RLP-encoded value). The data stored along the path from the root node to the leaf node is concatenated to form the key, and the leaf node stores the value. In the State trie and its associated Storage trie, the root and intermediate nodes, excluding the leaf nodes, are represented by the cloud-like structure shown in Figure 3 to represent their flexible and complex structure.

[0099] As shown in Figure 2, the Rollup Contract can be deployed on Layer 1 in Rollup. In Layer 2, initiated transactions can be received, such as Tx_21, Tx_22, etc. in the figure. A batch of transactions is called a Batch, which is executed in sequence as a whole and updates the status. As shown in Figures 1 and 2, Batch 1 is assumed to include three transactions: Tx_21, Tx_22, and Tx_23, and Batch 2 is assumed to include three transactions: Tx_24, Tx_25, and Tx_26. In Layer 2, these transactions can be sorted according to a rule, and then these sorted transactions can be executed in sequence, for example, according to the timestamps in the transactions. After the transactions in a Batch are executed in sequence, the resulting states may include several, for example, the transactions in Batch 1 are:

[0100] Tx_21: Alice→Bob 20; indicates that Alice transfers 20 units of assets, such as Ether, to Bob;

[0101] Tx_22: Alice→Charlie 10; indicates that Alice transfers 10 units of assets, such as Ether, to Charlie;

[0102] Tx_23: Bob→Charlie 10; indicates that Bob transfers 10 units of assets, such as Ether, to Charlie;

[0103] Before the execution of transactions in Batch 1, there are four states, which are referred to as the initial states of Batch 1, that is, the state values ​​locked by the Pre State Root in Figure 3, respectively:

[0104] Alice: 50, Bob: 100, Charlie: 150, David: 200

[0105] After the transactions in Batch 1 are executed, these four states are updated to the final state of Batch 1, that is, the state values ​​locked by the Post State Root in Figure 3, which are:

[0106] Alice: 20, Bob: 110, Charlie: 170, David: 200

[0107] Layer 2 can use a Merkle tree to organize the states of transactions in Batch 1 before and after their sequential execution. As shown in Figure 3, Layer 2 can organize the transactions in a batch and their associated state changes. For example, the Merkle root obtained by organizing the hash values ​​of transactions in Batch 1 according to the Merkle tree is locked in the batch header. This header is similar to the block header in Layer 1, and this Merkle root is the Tx_Root in the batch header. Similarly, as mentioned above, the Merkle root obtained by organizing all the state values ​​of transactions in Batch 1 before execution according to the Merkle tree can be locked in the batch header, namely the Pre-State Root. The Merkle root obtained by organizing the hash values ​​of all the state values ​​of transactions in Batch 1 after their sequential execution according to the Merkle tree can be locked in the batch header, namely the Post-State Root. In addition, for Batch M, a timestamp can be set in its header to record the time when the batch was generated, and other fields can also be set. For the M+1th batch, the Pre State Root in its block header is equal to the Post State Root in the block header of the Mth batch, as shown by the line connecting these two roots in Figure 3. In this way, a chain structure is formed between batches.

[0108] Layer 2 Rollup mechanisms can be divided into two types: Optimistic Rollup (OP-Rollup) and ZK-Rollup (Zero-Knowledge Rollup). Both of these Rollup mechanisms utilize the aforementioned smart contracts, Rollup Contracts, deployed on Ethereum.

[0109] In OP-Rollup, at least TxPool (transaction pool), Relayer (relay), and Sequencer (sequencer) can be set in Layer 2.

[0110] As shown in Figure 3, assume that transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24 are collected in TxPool. Sequencer sorts and packages these transactions according to the timestamps in these transactions, for example, packing Tx21, Tx22, and Tx23 into Batch M, and organizing the hash values ​​of these transactions into Merkle to generate a Merkle Root, and then fill the hash value of the Merkle Root into Tx_Root in the Header of the generated Batch M. It should be noted that when calculating the root of the Merkle tree, generally for a number less than 2 n In the case of , the last transaction can be assigned multiple copies to make up 2 n , and thus calculate the root of the 2-fork Merkle tree. As shown in Figure 3, Tx23, which is the last transaction in chronological order, is repeated once to complete 4 transactions, even if the number of transactions reaches 2 2 , and then the root of the two-pronged Merkle tree can be calculated. Similarly, the Sequencer sorts the transactions according to their timestamps and packages Tx21, Tx22, and Tx23 into Batch M+1. This will not be repeated here.

[0111] Before Batch M executes, the states include Alice: 50, Bob: 100, Charlie: 150, and David: 200, as described above. The Sequencer can organize these states into a Merkle tree and store the hash of the Merkle tree root in the Pre-State Root field of the Batch M Header. Furthermore, the Sequencer can execute transactions Tx21, Tx22, and Tx23 in sequence. The execution of these three transactions generates a new state, as described above: Alice: 20, Bob: 110, Charlie: 170, and David: 200. The Sequencer can organize these updated states into a Merkle tree and store the hash of the Merkle tree root in the Post-State Root field of the Batch M Header.

[0112] Furthermore, the Sequencer can send a Rollup Contract call transaction 1 to Layer 1 through the Relayer. This transaction 1 includes the fields in the Batch M Header as well as compressed Tx21, Tx22, and Tx23. After compression, Tx21, Tx22, and Tx23 significantly reduce their space. The interface in the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas fee) location called calldata. In Ethereum smart contracts, calldata is a special data location used to store input data for function calls. Specifically, calldata is typically stored directly in Ethereum transaction data, which generally saves more gas than other data locations (such as memory and storage).

[0113] Regarding compression, a simple Ethereum transaction (sending ETH) is approximately 110 bytes in size. However, with the current design, ETH transfers can be reduced to approximately 12 bytes after maximum compression. The following table shows an example of the size occupied by various fields (parameters) in an Ethereum transaction and the fields in a Rollup transaction:

[0114] Table 1

[0115] The implementation details of compression are omitted here. It's worth noting that in an Ethereum transaction, the signature accounts for approximately half of the total transaction size, and its From field can be 0 bytes, as it can be recovered from the signature. In Rollup, however, BLS aggregation can be used, compressing the signature of each transaction to approximately 0.5 bytes on average. Accordingly, in Rollup transactions, since the From field cannot be recovered from this aggregated signature, it must be represented separately using 4 bytes.

[0116] In cryptography, public-key cryptography, also known as asymmetric cryptography, uses a public-private key pair (denoted as PK-SK, where PK stands for public key and SK stands for secret key). This contrasts with cryptography that uses only a single private key. Public-key cryptography encompasses encryption algorithms and digital signature algorithms. Public-private key pairs are the cornerstone of modern cryptographic security. Many applications are based on PK-SK, such as the HTTPS (Hypertext Transfer Protocol Secure) application-layer encrypted transmission protocol and blockchain.

[0117] A private key typically represents the identity of the party that possesses it. It can only be held by the owner and cannot be made public. The corresponding public key, however, can be made public. Signing with a private key signifies the owner's approval of certain digital information. The signed information in a protocol message can also represent the owner's actions. Generally, a single owner possesses a private key. This owner can use their private key to sign a message and send it to another party. Upon receiving the signature, the recipient can verify it using the corresponding public key. If verification is successful, the recipient can confirm that the owner signed the message and that the signed message has not been tampered with.

[0118] The BLS signature scheme, originally proposed by Stanford University Professor Dan Boneh and others in 2001, is based on a bilinear mapping construction. Generally, a user controls their account by signing a transaction with their private key. As shown in the table above, a single signature can be up to 68 bytes, occupying a relatively large size. For multiple transactions initiated by multiple accounts, each account must sign its own transaction separately. Signature aggregation can combine multiple signatures into a single signature, significantly saving signature space. This aggregation can include signatures of the same message from different signers or signatures of different messages. Public key aggregation can aggregate multiple public keys into a single aggregate public key, which can then be used to verify the aggregate signature, eliminating the need for individual public keys to participate in the computation of the aggregate signature. Signature aggregation is commonly implemented using the Schnorr signature algorithm or the BLS signature algorithm. Compared to the Schnorr signature algorithm, the BLS signature algorithm achieves a smaller aggregate signature size, approximately half that of the Schnorr signature algorithm.

[0119] The compression scheme and BLS signature aggregation described above represent ideal designs. However, in several current Rollup implementations, a compressed transaction still occupies 40-50 bytes, not including the signature, meaning BLS signature aggregation is not yet implemented.

[0120] Continuing from the previous section, after receiving Transaction 1, which calls the Rollup Contract, Layer 1 executes Transaction 1 on some nodes through consensus. This Transaction 1 and its execution results, along with other transactions and their execution results, are combined to form a block, as shown in Block N in Figure 3. These other transactions can include ordinary transfers and transactions involving other smart contracts. Both ordinary transfers and transactions involving other smart contracts can involve transaction execution. In particular, transactions involving other smart contracts may involve relatively complex execution logic. Transaction 1, however, calls a function stored in the Rollup Contract's calldata location. This primarily involves storing data in a specific location and does not involve executing complex contract logic. In other words, the Rollup Contract in Layer 1 primarily stores the content specified in the transaction sent from Layer 2 in a specific location; it does not involve any other complex execution logic. For example, Tx21, Tx22, and Tx23 are stored in Tx_12 in the transaction tree, which is locked by Tx_Root in the Block N header. In addition, as an implementation, the Pre State Root and Post State Root in the Batch M Header in Transaction 1 can be stored in State 1 and State 2 in the contract state on Layer 1 respectively through the Rollup Contract. As mentioned above, State 1 and State 2 are contained in the state trie locked by State_Root in the Block N Header, specifically in the storage trie. To distinguish them, State 1 and State 2 in the contract state on Layer 1 are respectively referred to as Last State root and Current State root. In addition, for simplicity, only the Current State root can be saved in the contract state on Layer 1 without saving the Last State root, as shown in the following code example. In other implementations, the Last State root and Current State root can also be stored in the calldata in Layer 1, just like the transactions in Layer 2, which will not be repeated here. For the former, for example, the commitBatch() contract interface in Layer 1 is called as follows:

[0121] function CommitBatch(bytes[]calldata_transactions,bytes32 _preStateRoot,bytes32_postStateRoot)

[0122] In the CommitBatch() contract interface, you can set basic verification logic, such as verifying whether the Pre State Root in the current transaction 1 is equal to the Current State Root in the contract storage. If they are equal, the Layer 2 transaction passed in transaction 1 is stored in calldata, and the Current State Root in the contract storage is updated to the Post State Root. The sample code is as follows:

[0123] Through the above approach, OP-Rollup can execute individual transactions on Layer 2 and bundle dozens, hundreds, or even more Layer 2 transactions into a single batch, while publishing only minimal information to Layer 1. This minimal information includes the compressed Layer 2 transactions described above and the hash values ​​of the state root before and after the batch's execution. As shown above, this can be sent via a single Layer 1 transaction, such as Transaction 1 in Figure 3. This effectively executes a batch of transactions on Layer 2 at once, but only a single transaction on Layer 1. Furthermore, OP-Rollup does not include any proof. This assumes that the submitted Layer 2 information is free of fraud or malicious intent, hence its "optimistic" name. Despite this assumption, for preventive and deterrent purposes, traders submitting Layer 2 information are still required to stake a portion of Layer 1 assets (typically native on-chain tokens, such as Ethereum's Ether) in the OP-Rollup's Rollup Contract. Although OP-Rollup is optimistic, a challenge period can still be set on Layer 1, during which anyone can submit a challenge using a fraud proof. Typical reasons include the challenger proving that a transaction within the batch was not executed correctly, that is, the execution of the transaction did not produce the correct state. If a transaction within a batch is proven to be invalid, the batch is also invalid. The Rollup contract on Layer 1 can roll back the Layer 2 batch chain, and the invalid batch and all subsequent batches will become orphaned blocks. If the fraud proof is successful, a portion of the security deposit will be paid to the challenger, and the remainder will be destroyed. Conversely, if no one submits a fraud proof by the end of the challenge period, the Rollup contract can confirm the batch.

[0124] Fraud proofs are a method used by the Optimistic Rollup solution to verify data validity. Currently, fraud proofs can be categorized into two types: single-round interactive and multi-round interactive.

[0125] In a single-round interactive fraud proof implementation, the disputed transactions are replayed on Layer 1, checked for invalid states, and then submitted. For example, Alice, as a validator, synchronizes the compressed OP-Rollup data to Layer 1 and deposits a security deposit. If the challenger Bob disputes this data, he must initiate a challenge within a window period (the challenge period) and also deposit a security deposit. The OP-Rollup's Rollup Contract will recalculate the transactions in the block on Layer 1 to determine whether the correct party is correct. The security deposit of the party in error will be forfeited, and the party in error will receive a reward.

[0126] For example, the Sequencer on Layer 2 previously packaged and executed Tx21, Tx22, and Tx23, generating the Batch M header, which includes the Merkle roots of the global state before and after the sequential execution of Tx21, Tx22, and Tx23 (Pre-State Root and Post-State Root, among other things). The Sequencer can send a Rollup Contract-invoking Transaction 1 to Layer 1 through the Relayer. This Transaction 1, for example, calls the CommitBatch() contract interface of the Rollup Contract on Layer 1, including the fields in the Batch M header and the compressed Tx21, Tx22, and Tx23. Bob is a user on Layer 2. Assume that he participates in some transactions in Batch M on Layer 2, such as the aforementioned Tx_21: Alice→Bob 20 and Tx_23: Bob→Charlie10.

[0127] Assuming Bob believes that the state obtained by the Sequencer after executing Tx_23, which Bob transferred to Charlie10, is incorrect, Bob can initiate a challenge on Layer 1 during the challenge period for Batch M. As a user on Layer 2, Bob has access to the full state of each batch on Layer 2 before and after execution, as well as all transactions within each batch. This is the premise. Furthermore, Bob can initiate a challenge to the Rollup Contract on Layer 1, for example by calling the Challenge() contract interface. Through this Challenge() contract interface, Bob can send the challenged batch index (batchIndex), the transaction sequence number (txIndex), and the proof. The proof can include the original text of all transactions in the challenged Batch M (including the signature of each transaction; here, the compressed transactions stored in calldata without signatures are used as an example) and the global state before Batch M was executed. Thus, when the Rollup Contract on Layer 1 is executed, it can execute a verification function. The execution logic of this verification function, for example, includes:

[0128] 1. Verify that the signatures of all original transactions in the challenge initiated by Bob are correct;

[0129] 2. Verify that the root hash of the Merkle tree formed by compressing all the original transactions after removing the transaction signatures in the challenge initiated by Bob is the same as the Tx_Root in the Batch M Header sent by the Sequencer through the Relayer's call to CommitBatch() (i.e., the root hash of the Merkle tree formed by all the transactions in Batch M).

[0130] 3. Verify that the root hash of the global state before Batch M in Bob's challenge is organized into a Merkle tree is the same as the Pre State Root sent by the Sequencer through the Relayer's call to CommitBatch();

[0131] 4. If 1, 2, and 3 all pass verification, further simulate Layer 2 to sequentially execute all transactions in Batch M in the challenge initiated by Bob, generate the Post State Root after Batch M is executed, and verify whether it is the same as the Post State Root sent by the Sequencer through the Relayer calling CommitBatch();

[0132] If the results of step 4 are different, it means that the Sequencer has committed fraud and a portion of the deposit can be paid to the challenger through the Rollup Contract.

[0133] It's important to note that although Layer 1's calldata contains all compressed transactions from Layer 2, during the fraud proof verification process, the compressed transactions in Batch M within the calldata are not directly retrieved and executed. Instead, they are simulated based on the original transactions in Batch M passed in by the challenger. This is because the compressed Batch M transactions in the calldata are generally only used to restore the execution process of all transactions on Layer 2 and the status of all accounts, thereby eliminating the security risks posed by data availability on Layer 2. Furthermore, the authenticity of the compressed Batch M transactions in the calldata, without signatures, remains uncertain, while the transactions passed in by the challenger are complete transactions, allowing for verification of their validity. Furthermore, because the initial state cannot be verified, the contract only stores the state root, not the state. This requires re-executing all transactions sequentially from Batch 0 to obtain the full state after executing Batch M-1, which is clearly inefficient and uneconomical.

[0134] The above-mentioned single-round interactive fraud proof increases the data that must be published on the chain and requires re-executing all transactions in Batch M on Layer 1. Replaying these transactions also incurs huge fuel costs. Therefore, OP-Rollup is turning to multi-round interactive proofs to achieve the same goal with higher efficiency.

[0135] In a multi-round interactive fraud proof, when Bob challenges the data synchronized by the Sequencer, the Sequencer must divide the disputed batch range into two equal ranges, the front and back, and return them through a contract interface such as the dispute() interface. Bob then selects a range after the second division to challenge, and the Sequencer divides the disputed range into two equal ranges again, and so on, until the disputed range is narrowed down to a specific transaction. Here, Bob will send the original text of the challenged transaction (including the signature of each transaction) and the global state before the transaction is executed. The Sequencer will send the pre-state root (also called the state commitment) and the post-state root after the challenge transaction is executed, which will be handed over to the Layer 1 Rollup Contract for calculation and judgment. Specifically, for example, the Rollup Contract verifies the global state before the challenge transaction is executed based on the Pre-State Root before the challenge transaction is executed. It then executes the challenge transaction based on the pre-challenge global state to generate the post-execution state. Based on the post-challenge global state, it generates the Post-State Root. If the Post-State Root is different from the Post-State Root sent by the Sequencer, the challenge is successful; otherwise, the challenge fails. In practice, Arbitrum uses a K-based approach instead of a binary approach, which divides N instructions into N / K groups each time to identify fraudulent instructions, resulting in higher efficiency.

[0136] Therefore, compared to single-round interaction, multi-round interaction can resolve disputes at a lower cost. For example, the bisection protocol can reduce the amount of data published on the chain (no need to publish status submissions for each transaction), and it is easier to support complex smart contracts and handle more demanding disputes. However, as the number of interactions increases, its dispute window will also be longer.

[0137] Overall, because the OP-Rollup design requires all state update and verification data to be stored on Layer 1, its scalability and throughput improvements are limited, and it requires a waiting period of seven days or even longer. This means that withdrawing assets from the OP-Rollup will be delayed and require waiting until the window has expired.

[0138] ZK-Rollup differs from Optimistic Rollup in that it utilizes zero-knowledge proof technology. ZK refers to the ability to prove something (a transaction or state) to another party without revealing necessary information. Similar to OP-Rollup, in ZK-Rollup, Tx21, Tx22, and Tx23 are packaged into Batch M. The hash values ​​of these transactions are organized into a Merkle tree to generate a Merkle Root. The hash value of this Merkle Root is then added to the Tx_Root field in the generated Batch M header. Furthermore, the Pre-State Root, Post-State Root, and Timestamp fields are generated and added to the Batch M header. Moreover, Layer2 will also generate a proof (including proof) for this batch (for example, using cryptographic proof algorithms such as ZK-SNARK). The proof in this proof can prove that the Post State Root is obtained after the transactions in the batch are correctly executed in sequence based on the Pre State Root. This can be confirmed by simply verifying the proof, without the need to re-execute the transactions in the batch for verification.

[0139] Before generating a proof, a computational circuit can be created. This circuit is essentially a specific algorithm, pre-written for the logic behind verifying transactions and status. This pre-written process is included in a process called trusted setup, which also generates a Proving Key and a Verifying Key. The created circuit can be set up in a proposer (or prover) on Layer 2. It should be noted that the circuit created for the logic behind verifying transactions and status is bound to its Proving Key and Verifying Key. Both the Proving Key and the Verifying Key are publicly available and are bound to the circuit.

[0140] The proof generation process can involve the sequencer packaging all transactions in a Layer 2 batch (including sender, receiver, and amount), as well as the pre- and post-State Roots, post-State Roots, and proving keys for the transactions before and after the batch's execution, and sending them to a prover on Layer 2. The prover converts this information into a special form called a witness (selecting a portion as public input and another portion as private input). The prover then verifies the validity and correctness of the public and private inputs using its internal zero-knowledge proof computation circuit (a specific algorithm). If the circuit is verified correctly, the execution succeeds; otherwise, the circuit fails. If the circuit succeeds, the prover outputs a proof that proves the validity and correctness of the packaged data. Furthermore, this proof is relatively small, typically only a few dozen bytes. This proof generation process is similar to the re-execution process, but involves a significant amount of circuit computation, making it more complex and, therefore, generally time-consuming.

[0141] It's important to note that the private input cannot be deduced from the proof itself. Only a party with knowledge of the zk-SNARK's verification key can verify the proof encrypted with the corresponding creation key. The public input can be used to verify the validity and correctness of the packaged data, but it cannot be used to obtain the specific content of the packaged data.

[0142] Using zero-knowledge proofs, the prover can publish smaller proofs to Layer 1 through the Relayer, which can be quickly verified by the Rollup Contract. The smaller proof size further reduces gas consumption on Layer 1. Furthermore, in a ZK-Rollup, this verification process is typically automated by the smart contract, eliminating the need for a set window period like in OP-Rollup. This also makes asset withdrawals faster, a key difference between OP-Rollup and ZK-Rollup.

[0143] The specific verification process is as follows: first, the public input (which can be calculated from transaction 1 submitted in Block N, for example, it is calculated by the automatic execution calculation logic in the Rollup Contract when transaction 1 is submitted to the Rollup Contract of Layer 1), proof and verification key (the verification key can be saved and provided to the Rollup Contract through the governance contract on Layer 1) are input into the verification logic in the smart contract (for example, a verification algorithm including ZK-SNARK), and the verification logic uses the verification algorithm to check whether the proof is valid. If the proof is valid, the packaged data corresponding to the public input is considered valid and correct. If the verification is successful, the verification algorithm will output a confirmation message proving that the packaged data corresponding to the public input is valid and correct; otherwise, the verification algorithm will output an error message indicating the invalidity or error of the data.

[0144] However, zero-knowledge proofs like ZK-SNARKs require a significant amount of computation to generate proofs, which means proof generation is time-consuming. As shown in Figure 4, Transaction 1 stores the compressed Tx21, Tx22, and Tx23 in the calldata of Layer 1, and stores the Post State Root in the Current State Root of the contract state on Layer 1. This Transaction 1, as shown in Figure 4, is located in Block N of Layer 1. The complex computation required to generate the corresponding proof in Layer 2 may delay the transfer of Batch M's proof to Block N+412 on Layer 1 via Transaction 2. This delay from Block N to Block N+412 is significantly increased, potentially reaching hours.

[0145] To address the computational complexity and time required to generate proofs, the current industry's primary solutions include large-scale parallelization of proofs through engineering or acceleration through hardware optimization. However, this is not easy. Circuit implementation is relatively complex and lacks high-level language support, requiring handwritten R1CS (a common form of circuit design).

[0146] Furthermore, to leverage the ZK proof system and optimize circuit implementation, the entire Layer 2 state is often optimized to a circuit-friendly structure (a Merkle tree). Therefore, the ZK-kRollup system must consider the circuit structure, which constrains Layer 2 transactions and account models. ZK-Rollup solutions, including zksync, StarkNet, and Scroll, only implement specific transaction scenarios, making compatibility with the Ethereum Virtual Machine and support for Turing completeness even more challenging. This means they struggle to support complex contracts.

[0147] The following is a comparison of the characteristics of the two Layer 2 Rollup solutions: OP-Rollup and ZK-Rollup:

[0148] Table 2

[0149] The present application discloses a method for implementing a two-layer network convolution, and the architecture relied upon on Layer 2 is shown in FIG5 . This includes at least Relayer, TxPool, Sequencer, and Prover. As mentioned above, the main function of Relayer is to submit transactions or operations on Layer 2 to Layer 1, that is, to bridge Layer 1 and Layer 2. This can include submitting user transactions on Layer 2 packaged by Sequencer to Layer 1, and submitting the proof generated by Prover on Layer 2 to Layer 1. Of course, Relayer may not be included, but Sequencer may submit the packaged user transactions on Layer 2 to Layer 1, and Prover may submit the generated proof to Layer 1. In fact, the latter is to integrate the functions of Relayer into Sequencer and Prover. For the sake of brevity, the role of Relayer in the entire solution will no longer be emphasized.

[0150] TxPool is used to receive transactions sent by users on Layer 2.

[0151] The Sequencer pulls transactions from the TxPool, sorts and packages them according to their timestamps, organizes the hashes of these transactions into a Merkle tree, generates a Merkle root, and inserts the hash of this Merkle root into the Tx_Root field in the header of the generated Batch M. For example, as shown in Figure 4, Tx21, Tx22, and Tx23 are packaged into Batch M. Tx23, the last transaction in chronological order, is repeated once to complete the four transactions, thus calculating the root of the two-pronged Merkle tree. Furthermore, the Sequencer sequentially executes Tx21, Tx22, and Tx23 based on the pre-execution state of Batch M. The results of executing these three transactions generate a new state. The Sequencer organizes the state before execution into a Merkle tree and stores the hash value of the Merkle tree root node in the Pre State Root field of the Batch M Header. It also organizes the state after transaction execution in Batch M into a Merkle tree and stores the hash value of the Merkle tree root node in the Post State Root field of the Batch M Header.

[0152] Prover can be implemented using TEE (Trusted Execution Environment).

[0153] A TEE is a secure extension of CPU hardware, creating a completely isolated trusted execution environment (TEE). Currently, the industry is paying close attention to TEE solutions. Nearly all major chip and software alliances have their own TEE solutions, including the TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor) in hardware. A TEE acts as a black box, preventing even the operating system from intruding on the code and data executed within it. These operations can only be performed through predefined interfaces within the code. In terms of efficiency, due to the TEE's black box nature, operations within the TEE operate on plaintext data, rather than the complex cryptographic operations used in homomorphic encryption, resulting in virtually no loss in computational efficiency. Therefore, TEE technology can largely meet the trusted computing requirements of blockchain scenarios with relatively minimal performance loss.

[0154] The present application provides a method for implementing a two-layer network convolution, including the following:

[0155] S110: The sequencer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transactions, and executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed and generates a first post-state root.

[0156] S120: The sequencer sends the packaged transaction, the first transaction root, the initial state before the packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network.

[0157] Similar to the previous example, a Rollup Contract can be deployed on Layer 1. On Layer 2, the transaction pool TxPool can receive initiated Layer 2 transactions. Assume that TxPool collects Layer 2 transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24.

[0158] The Sequencer pulls transactions from the transaction pool and sorts and packages them according to their timestamps. For example, as shown in Figure 4, Tx21, Tx22, and Tx23 are sorted and packaged into Batch M. The hash values ​​of these transactions are organized into a Merkle tree to generate a Merkle Root. The hash value of this Merkle Root is then entered into the Tx_Root field in the header of the generated Batch M. This Merkle Root is the first transaction root of Batch M.

[0159] Before the packaged transaction is executed, for example, the status is:

[0160] Alice: 50, Bob: 100, Charlie: 150, David: 200

[0161] These states can be the initial states before the package transaction is executed.

[0162] The Sequencer can organize all state values ​​of transactions in Batch M before execution according to a Merkle tree and obtain a Merkle root, namely the first pre-state root. It can also lock the Merkle root obtained by organizing all state values ​​of transactions in Batch M before execution according to the Merkle tree in the header of Batch M, namely the Pre-State Root in Figure 4.

[0163] The Sequencer can execute the packaged transactions in sequence based on the initial state, thereby generating the state after execution, for example:

[0164] Alice: 20, Bob: 110, Charlie: 170, David: 200

[0165] The Sequencer can organize all states obtained after the transactions in Batch M are executed in sequence into a Merkle tree and obtain the Merkle root, which is the first post-state root. It can also organize the hash of all state values ​​of the transactions in Batch 1 into a Merkle tree and lock the resulting Merkle root in the Batch header, which is the Post-State Root.

[0166] Furthermore, the sequencer can send the packaged Layer 2 transaction, the first transaction root, the initial state before the execution of the packaged transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network.

[0167] Furthermore, in S110 or S120, the Sequencer (or through the Relayer) can send a Transaction 1 (the first mainnet transaction) to Layer 1 that calls the Rollup Contract. This Transaction 1 includes the fields in the Batch M Header and compressed Tx21, Tx22, and Tx23. Compression of Tx21, Tx22, and Tx23 significantly reduces the space occupied by these data. The interface within the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas fee) location called calldata. In Ethereum smart contracts, calldata is a special data location used to store input data for function calls. Specifically, calldata is typically stored within Ethereum transaction data. Once the data is formed into a block, it cannot be modified, meaning it is read-only. This generally saves gas compared to other data locations such as memory and storage.

[0168] Like other contracts, Rollup Contracts can be executed in a virtual machine (such as the Ethereum Virtual Machine (EVM)) or a container (such as Docker), though this is not a limitation. A Sequencer (or through a Relayer; the Sequencer / Relayer can initiate this through an external account on the mainnet) can initiate a transaction to the blockchain that calls a Rollup Contract on the mainnet, triggering the contract's execution. The transaction content includes, for example, a from field, a to field, a value field, and a data field. The from field can be the transaction initiator's account address (the Sequencer / Relayer's external account on the mainnet), the to field can represent the address of the smart contract being called, the value field can be the native token on the blockchain (for example, the value of Ether in Ethereum), and the data field can contain the method and parameters for calling the smart contract. By specifying the address of the smart contract being called in the to field, it indicates that a call is being made to a specific smart contract on the blockchain. Smart contracts typically include one or more functions, each of which can take input parameters. The data field in a transaction specifies the function within the smart contract to be called, and the parameters to be passed in are filled in the data field. As mentioned above, the data field can specify a call to the commitBatch() contract interface. This allows the Rollup Contract to store the compressed Tx21, Tx22, and Tx23 from the first mainnet transaction (Transaction 1) into calldata, update the Current State Root in the contract storage to the Post State Root, and pass in the parameters. This will not be further explained.

[0169] The result of contract execution can, on the one hand, change the contract's storage, that is, the contract's world state. On the other hand, the transaction's execution result or related information can be recorded in the blockchain's receipt. Specifically, the contract execution result / related information can be represented as an event in the receipt. The event structure is, for example, in the following format:

[0170] Event:

[0171] [topic][msg]

[0172] [topic][msg]

[0173] ......

[0174] In the above example, the number of events can be one or more. Each event can include fields such as topic and data. The format of the events output during transaction execution can be specified in the contract. Through the built-in SDK, blockchain clients or blockchain nodes can listen for events on specific topics and, when listening for events on specific topics, pull the corresponding message content. Furthermore, they can perform pre-defined processing after listening for specific topics or certain content in the corresponding message content.

[0175] Through this event mechanism, blockchain nodes on the mainnet can store execution results in the message corresponding to a topic, so that the sequencer / relayer can monitor the topic through its built-in blockchain client and obtain the corresponding execution results. In this case, the first mainnet transaction has been successfully executed on the mainnet Rollup Contract.

[0176] After the Rollup Contract on the main network is executed, events for specific topics can be generated.

[0177] After the Prover / Relayer monitors the corresponding topic, it can confirm that the transaction that previously called the Mainnet Rollup Contract has been executed on the Mainnet. This allows the Prover to proceed to step S130. This allows the Prover to confirm the execution result of the blockchain node on the Mainnet by monitoring specific events before performing verification in S130. This avoids verifying the transaction if the Mainnet transaction was not executed on the Mainnet for some reason, such as failure to send the transaction successfully or failure of the Mainnet Rollup Contract to verify the transaction itself. Alternatively, S130 can be executed directly after S120.

[0178] S130: The prover verifies the first transaction root and the first pre-state root; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed and the signature is sent as proof to the blockchain ledger of the main network through a second main network transaction.

[0179] The prover verifies the first transaction root, including generating a second transaction root for the packaged transaction and verifying whether the first transaction root is equal to the second transaction root. Specifically, the prover may organize the hash values ​​of the packaged transactions Tx21, Tx22, and Tx23 into a Merkle tree and then generate a Merkle Root. This Merkle Root is the second transaction root, similar to the sequencer. In this way, the prover can verify whether the second transaction root is equal to the first transaction root sent by the sequencer.

[0180] The prover generates and verifies the first previous state root, including: the prover generates a second previous state root of the initial state, and verifies whether the second previous state root is equal to the first state root. Specifically, the prover may organize the hash value of the initial state sent by the sequencer into a Merkle tree and generate a Merkle root, i.e., the second previous state root. In this way, the prover can verify whether the second previous state root is equal to the first previous state root sent by the sequencer.

[0181] If the prover verifies that the second transaction root is equal to the first transaction root sent by the Sequencer, and the second previous state root is equal to the first previous state root sent by the Sequencer, then it means that the first transaction root and the first previous state root sent by the Sequencer are correct, and the subsequent content can be executed.

[0182] The prover can sequentially execute the packaged transactions based on the initial state sent by the Sequencer, generate updated states, and organize these updated states into a Merkle tree, thereby obtaining the hash value of the Merkle tree root node of the updated state, namely the second post-state root. Furthermore, the prover can verify whether the second post-state root is equal to the first post-state root. If they are equal, it indicates that the Sequencer's execution process is correct, because starting from the same initial state, the Sequencer's sequential execution of the packaged transactions has the same result as the prover's independent execution of the same packaged transactions.

[0183] In this way, the prover can verify the signature of the packaged transaction information. Specifically, the prover can verify at least one of the packaged transaction's batch number, the packaged transaction's transaction root, and the packaged transaction's corresponding Post State Root. Signing at least one of these contents indicates the prover's approval of the results produced by the Sequencer's execution of this batch.

[0184] As mentioned earlier, a private key typically represents the identity of the party that possesses it. It can only be held by the owner and cannot be made public, whereas the corresponding public key can be made public. Signing with a private key can indicate the owner's approval of certain information in the digital world. The signed information in a protocol message can also represent the owner's actions. Generally, a single owner possesses a private key. This owner can use their private key to sign a message and send it to another party. Upon receiving this signature, the recipient can verify it using the corresponding public key. If verification is successful, the recipient can confirm that the owner signed the message and that the signed message has not been tampered with.

[0185] The prover can be implemented using a TEE. A TEE provides a completely isolated trusted execution environment, allowing it to maintain confidentiality regarding private keys. Thus, after verifying that the second post-state root is equal to the first post-state root, the prover can use its own private key to sign the packaged transaction information, indicating its approval of the signature.

[0186] TEE technologies include Intel SGX (Intel Software Guard Extension, hereinafter referred to as SGX) and AMD SEV. SGX technology is used as an example below for illustration. The Prover in Layer 2 can create an enclave (or enclave) based on SGX technology to serve as the TEE for performing verification. The Prover can utilize new processor instructions in the CPU to allocate a portion of the EPC (Enclave Page Cache) in memory to house the enclave. The memory area corresponding to the EPC is encrypted by the CPU's internal memory encryption engine (MEE). The contents of this memory area (code and data in the enclave) can only be decrypted within the CPU core, and the encryption and decryption keys are generated and stored in the CPU only when the EPC is started. As can be seen, the enclave's security boundary only includes itself and the CPU. No software, privileged or unprivileged, can access the enclave. Even the operating system administrator and the VMM (Virtual Machine Monitor, also known as the hypervisor) cannot affect the code and data within the enclave, thus ensuring extremely high security. With these security guarantees, the CPU can process data within the enclave with extremely high computational efficiency, thus balancing data security and computational efficiency.

[0187] Intel has supported SGX since its sixth-generation CPUs. Furthermore, before shipping, these SGX-enabled CPUs have the manufacturer burn a provisioning key and a sealing key into the CPU's fuse registers. A fuse register is a one-time programmable register. Once burned, the fuses blow, rendering the register's contents readable but no longer writable. Intel guarantees that the key burned into the fuse register is randomly generated. Furthermore, all backups of the burned-in key are destroyed after burning, meaning even Intel itself remains unaware of the key. The provisioning key can represent CPU information, such as the CPU code (e.g., 6th-generation Core, 7th-generation Core) or model (e.g., desktop, mobile). For security reasons, encryption and signing operations do not directly use the provisioning key. Instead, an attestation key derived from the provisioning key is used. Therefore, the provisioning key serves a deployment purpose.

[0188] Based on user instructions, a User Enclave can be created to execute user-specified program code (such as transaction execution code loaded into the TEE, including virtual machines and smart contracts). At the same time, due to the aforementioned isolation characteristics of the Enclave, the User Enclave created by the user often needs to first prove its trustworthiness to the outside world. This involves Enclave authentication, such as local authentication and remote authentication described below.

[0189] Before initiating remote attestation, the CPU can check for the presence of an attestation key. If not, it initiates initialization. This initialization process can be based on a key generation protocol, interacting with an Intel server (specifically, the Provisioning Enclave in SGX, an architectural-level enclave). The EPID (Enhanced Privacy IDentification) is generated according to the Provisioning Key generation rules. This EPID serves as the attestation key and is typically used as the private key in an asymmetric encryption key. The generated EPID can be stored in an enclave for subsequent signing, typically called the Quoting Enclave. Alternatively, the EPID can be stored in CPU registers, with only the architectural-level enclave having access to it. In this case, the Quoting Enclave can also obtain the EPID from the CPU registers. As mentioned above, during the EPID generation process, SGX (specifically, the Provisioning Enclave mentioned above) can interact with the Intel server, allowing Intel to obtain the public key corresponding to the EPID. Notably, the public key corresponding to the EPID is not publicly available and is maintained exclusively by the Intel server. This feature is suitable for subsequent remote authentication by Intel's server (also called IAS, i.e. Intel Attestation Server) to perform authentication.

[0190] The developer of the application (or the issuer as referred to below) can sign the code / data that needs to be loaded into the Enclave (such as the transaction execution code loaded into the TEE, including the virtual machine and smart contract) with the developer's private key and then pass it to SGX through the application. In addition, the issuer's public key can also be passed to SGX (or the issuer's certificate can be uploaded, and the certificate includes information signed by the issuer, which may include the issuer's public key; the information may also include the hash value of the code / data to be loaded into the Enclave, and the hash value can be used by SGX to verify the integrity of the loaded code / data). During the execution of the application, an application can be applied to SGX through the instruction set integrated in the CPU to create an Enclave. This Enclave is generally called an Application Enclave (equivalent to the above-mentioned User Enclave). When creating an Application Enclave, SGX needs to perform page allocation, copy program code / data and measurement operations. Specifically, the measurement can be measured by the CPU to measure the hash value of the code / data loaded into each page, so that after loading is completed, the hash value of the Application Enclave loaded with the code / data is obtained. This hash value is generally called MREnclave, and the hash algorithm generally uses SHA256. MREnclave can be stored in a structure called SECS (SGX enclave control structure). SECS is located in an EPC page of the Enclave to which it belongs and is used to record the metadata of the Enclave. The metadata includes sensitive information such as Enclave cryptographic measurement (i.e., MREnclave), so this structure can only be accessed and modified by the CPU's SGX management mechanism.

[0191] Due to the characteristics of hash algorithms, even minor changes in code / data, extra page allocation, or the copying of malicious code can significantly alter the MREnclave's results. Different Application Enclaves will have different MREnclave values. Due to these properties, the MREnclave can identify the enclave and verify the integrity of the Application Enclave. Through measurement operations, the hash value contained in the certificate can be used to verify the integrity of the Application Enclave (the hash value in the certificate follows the same generation rules as the MREnclave, so it should be consistent under normal circumstances). This allows the privileged software to determine whether it tampered with the program / data during creation, such as whether extra pages were allocated, malicious code was copied, or the copied data was tampered with.

[0192] Specifically, when SGX creates an Application Enclave, it uses an initialization instruction to compare the aforementioned MREnclave with the hash value in the certificate signed by the Application Enclave issuer. If they match, the code / data loaded into the Application Enclave is consistent with the expected code / data, that is, the issuer's code / data. Conversely, if they do not match, it indicates a problem with the creation process and returns a failure result. If they match, SGX also hashes the issuer's public key in the certificate to obtain the MRSigner. Similarly, the MRSigner can be used to identify the issuer. This MRSigner can also be stored in the aforementioned SECS.

[0193] In this way, the SECS structure is equivalent to the identity of the Enclave from a certain perspective. It has two Enclave identities at the same time: MREnclave is the measure of the Enclave, and MRSigner is the measure of the issuer.

[0194] The content within the Application Enclave requires remote attestation to prove that it is a legitimate, trusted enclave created within SGX. As previously mentioned, the content within the Application Enclave must be signed with the EPID in the Quoting Enclave before remote attestation. This requires interaction between the Application Enclave and the Quoting Enclave. Prior to this, the Application Enclave must prove to the Quoting Enclave that it is a trusted enclave within the same SGX. This process of the Application Enclave proving to the Quoting Enclave that it is a trusted enclave within the same SGX is known as local attestation.

[0195] The local proof process can use a message authentication code (MAC) algorithm. The Application Enclave can obtain the MREnclave of the Quoting Enclave and can generate a signed report structure (Report). Specifically, the Application Enclave can call the EREPORT instruction provided by the CPU. The CPU can use a root key and combine it with the MREnclave of the Quoting Enclave obtained by the Application Enclave to generate a symmetric key - the REPORT Key. At the same time, by calling the EREPORT instruction, the identity information and attributes of the Application Enclave and the platform hardware TCB information can be obtained as the content of the Report; in addition, the data that the user wants to interact with can be attached to the Report. When calling the EREPORT instruction, the MAC algorithm will also be used to calculate the REPORT Key and the above-mentioned Report to obtain the first MAC code. The first MAC code can be used as the signature of the Report for integrity verification. The Application Enclave calls the CPU's EREPORT instruction, allowing the CPU to directly obtain the Application Enclave's identity information and attributes, as well as the platform's hardware TCB information, ensuring that this information is protected from interference and tampering by the Application Enclave. Furthermore, the CPU uses the root key and the Quoting Enclave's MREnclave to generate a REPORT Key. This process is also performed internally by the CPU, preventing even the Application Enclave from knowing the root key and thus leaking it. After receiving the Report and the first MAC code, the Quoting Enclave can call the EGETKEY instruction provided by the CPU, passing its own MREnclave as an input parameter. The CPU then obtains the same REPORT Key based on the same root key and MREnclave as in the EREPORT instruction. Furthermore, the Quoting Enclave can use the same MAC algorithm to calculate the obtained REPORT Key and the received Report to obtain a second MAC code. If the second MAC code is the same as the received first MAC code, it means that the integrity of the Report sent by the Application Enclave has not been compromised, which means that the identity information and attributes of the Application Enclave and the platform hardware TCB information contained in the Report are complete.Since only two enclaves on the same SGX can generate the same Report Key through the EREPOR instruction and EGETKEY instruction provided by the CPU combined with the same CPU root key, when the verification MAC code passes, the Quoting Enclave can confirm that the Application Enclave is an enclave on the same SGX.

[0196] Through the above process, local attestation is completed, meaning the Quoting Enclave can confirm that the Application Enclave is an enclave within the same SGX. Based on this local attestation, software outside the SGX (also called a challenger) can challenge the Application Enclave, requiring it to prove to the challenger that it is a legitimate enclave and that it runs trusted programs. After remote attestation is complete, the challenger can use the services provided by the Application Enclave.

[0197] During remote attestation, the challenger can first challenge the Application Enclave, requiring it to prove that it is a legitimate enclave and that it runs trusted programs. After receiving the challenge, the Application Enclave can generate a report, generally called a Quote. This Quote report can include the hash value of the code / data loaded in the Application Enclave, namely the aforementioned MREnclave, and can also include the aforementioned MRSigner. After the aforementioned local attestation, the content of the Quote can be signed by the Quoting Enclave using EPID, for example, denoted as Signature1. This signature can be a signature of the MREnclave by the Quoting Enclave using EPID, or a signature of the MREnclave and MRSigner. The Application Enclave can then send the Quote report to the challenger. Since the challenger does not possess the public key corresponding to the EPID, it cannot verify the signature. The public key corresponding to the EPID is held by Intel Attestation Services (IAS). Therefore, the challenger sends the Quote to IAS for signature verification. After receiving the Quote, the IAS can use the public key corresponding to the EPID to verify the correctness of the signature in the Quote and return an Attestation Verification Report (AVR). The AVR report can include the Quote report and the verification results of the Quote's signature, such as whether the signature verification is correct or incorrect. The IAS can sign the contents of the AVR report with Intel's private key, attach the signature (e.g., Signature2) and the certificate to the AVR report, and return the AVR report to the challenger. After receiving the AVR report, the challenger can use the public key in the certificate (corresponding to Intel's private key) to verify Intel's signature. Alternatively, the AVR report can omit the certificate, and the challenger can download Intel's certificate (available for download from Intel's official website or other authoritative websites) and verify Signature2 using the public key in the downloaded certificate. Verifying Signature2 confirms that the AVR report was indeed issued by Intel and is complete. The verification results of the Quote's signature included in the AVR report can prove the legitimacy of the SGX represented by the Quote report after verification by the IAS.Furthermore, the challenger can verify the MREnclave and MRSigner in the Quote. For example, the challenger can obtain the MREnclave of the code / data loaded into the SGX and the MRSigner of the issuer in advance from the issuer, and then compare them with the MREnclave and MRSigner in the Quote to confirm that the code / data loaded in the SGX is credible and issued by a legitimate issuer.

[0198] Before the prover signs the packaged transaction information in S130, the initiator of the Layer 2 transaction can challenge the prover's TEE as a challenger. This process includes interaction between the prover's TEE and the IAS, and between the challenger and the IAS. Based on the AVR report returned by the IAS, the transaction initiator can confirm that the prover's TEE is legitimate and the code / data loaded in it is trustworthy. As a result, the initiator of the Layer 2 transaction can trust the prover's TEE.

[0199] In addition, after the prover signs the packaged transaction information in S130, other verifiers can also challenge the TEE in the prover as challengers, similar to the above process, which will not be repeated here. In addition, the TEE can hash and sign the input code / data, thereby using its own trustworthiness to guarantee the trustworthiness of the input executed; the TEE can also sign the hash value of the output (that is, the result of the execution), also using its own trustworthiness to guarantee the trustworthiness of the input executed.

[0200] In this way, after the prover verifies that the packaged transaction is executed independently (also called replaying) in sequence based on the initial state, it signs the information of the packaged transaction, using its own trustworthiness to guarantee the credibility of the output result. Furthermore, the prover can use the signature as proof to send it to the blockchain ledger of the main network through a second main network transaction. Anyone who questions the signature can verify it by challenging the TEE in the prover. As mentioned above, this process also requires interaction with the IAS, so that the report returned by the IAS confirms that the TEE and the code / data loaded therein are trustworthy. Based on the trust in the TEE, it is also certain that the transaction information signed by it is credible.

[0201] It should be noted that once remote authentication is passed, the CPU can process data in the enclave through the TEE mechanism, achieving extremely high computational efficiency, thus balancing data security and computational efficiency. This is much faster than the ZK-Rollup approach. For example, under the same circumstances, the time required for ZK-Rollup to generate a proof is shortened from 30 to 50 minutes (or hours) (Block N to Block N+412 in Figure 4) to 5 to 10 minutes (Block N to Block N+62 in Figure 5). Even if monitoring mode is not used and S130 is executed directly after S120, the time is shortened to even less. In addition, the generated proof is the size of a signature, about tens of bytes, similar to ZK-Rollup.

[0202] Verifying the signature involves using the TEE's public key to verify the signature. As long as the public key is trustworthy, the verification is reliable and fast. The prover can use the signature as proof and send it to the mainnet's blockchain ledger via a secondary mainnet transaction. This involves the prover using the signature as proof and sending it to the mainnet via a secondary mainnet transaction, invoking the Rollup contract on the mainnet. Upon receiving the transaction, the Rollup contract verifies the correctness of the signature using the verification logic within the contract.

[0203] The above scheme is also known as the EPID scheme. In the above EPID scheme, each challenge requires the challenger and TEE to communicate with the remote IAS, which will cause significant latency and even prevent many running entities from accessing Intel services during runtime. Therefore, the improved SGX DCAP authentication protocol provides for localization of the IAS. For example, some cloud service platforms and data centers localize the IAS on a control machine. The localized control machine is also called a localized verification service (Verify Service). SGX DCAP provides trust in the form of a certificate chain, and the only trust root is the Intel SGX Root CA.

[0204] Intel SGX DCAP, or Intel Software Guard Extensions Data Center Attestation Primitives, is a remote attestation technology designed specifically for data center environments. As mentioned earlier, Intel SGX provides hardware-based security protections by creating a secure enclave where data and code are protected by hardware encryption. This prevents theft or tampering of data within the enclave, even if the operating system, hypervisor, or BIOS are compromised. In Intel SGX, attestation is a mechanism used to prove that code is running in a genuine enclave and that the code and data have not been tampered with. In traditional SGX environments, this attestation process requires Intel's Remote Attestation Service (IAS). However, in data center environments, extensive attestation operations may be required. Therefore, Intel introduced DCAP, which allows data centers to host their own attestation services. DCAP decouples the attestation process from Intel services, allowing data centers to perform attestation locally, improving efficiency, enhancing controllability, and reducing reliance on Intel services. Simply put, SGX DCAP is a solution that uses SGX technology in a data center environment, which provides a more efficient and controllable verification mechanism.

[0205] The data center's authentication service (Verify Service) can obtain a certificate from Intel IAS, which generally has a validity period. During the validity period, the deployed SGX instance can complete the generation of remote reports by interacting with the local verification service (which is equivalent to the local IAS) without interacting with Intel. After the validity period, the data center's verification service needs to obtain a new certificate from Intel IAS. The certificate generally includes the public key of the verification service signed by Intel, and Intel's public key is used to verify Intel's signature to ensure the credibility of the verification service's public key in the certificate. The verification service can use its own private key to sign other content, and provide the verification service's public key to verify Intel's signature to ensure the credibility of the verification service's public key in the certificate. In addition, the certificate can include an validity period, and the role of the validity period is as described above.

[0206] The process of implementing the SGX DCAP authentication protocol can be briefly described as follows (see the above content for details):

[0207] First, the TEE in the prover creates a protected execution environment (User Enclave) locally and generates a key pair in it. This key pair consists of a public key and a private key, where the public key will be used to generate a proof report (Quote).

[0208] The TEE in the attestor then submits the public key and some information about the User Enclave (such as its measurement value) to the local Quoting Enclave (QE), requesting the generation of an attestation report. The QE will sign this information and package the signature and other information into the attestation report.

[0209] The TEE in the prover then submits this attestation report to the Verify Service, which verifies the report's validity and signs the public key contained in it, generating a certificate. This certificate contains the Verify Service's signature on the prover's TEE and can also include other content. Similar to the aforementioned remote attestation report, it can also be considered a remote attestation report generated by the Verify Service.

[0210] Finally, the generated certificate is returned to the attestor's TEE. The attestor can then sign the execution result with its own private key and provide the certificate. This allows others to verify the signature using the public key in the certificate to ensure the authenticity of the execution result. This certificate is issued by the attestation service, signed with its own private key. The authenticity of this certificate is further guaranteed by the certificate issued by Intel IAS to the attestation service. This trust relationship between multiple certificates and signatures is known as the certificate chaining principle.

[0211] In summary, the prover can send the certificate to the mainnet's blockchain ledger via a secondary mainnet transaction. In a typical approach, the prover can send the certificate and its signature to the mainnet's blockchain ledger via a secondary mainnet transaction. When using the aforementioned EPID solution, the certificate includes a remote attestation report generated by the IAS for the prover. This allows the verifier to verify the legitimacy of the prover's signature on the transaction information by verifying this certificate. When using the aforementioned DCAP solution, the certificate can include the certificate issued by the authentication service for the prover. If trust in the authentication service is established, this can be extended to the certificate issued by the authentication service for the prover, allowing the verifier to verify the prover's signature using the public key in this certificate. If a higher level of trust is required, in addition to the certificate issued by the authentication service for the prover, the remote attestation report generated by the IAS for the authentication service may also be required. This way, the authenticity of the authentication service's signature can be guaranteed through Intel's authoritative authentication (i.e., the remote attestation report, equivalent to the certificate issued by Intel for the authentication service). Combined with the certificate issued by the authentication service for the prover, this trust can be transmitted downward, thereby ensuring the authenticity of the prover's signature. This is how SGX DCAP provides trust in the form of certificate chains.

[0212] The verification logic executed by the aforementioned verifier can be embedded within the Rollup Contract and exposed externally via a contract interface, such as a verification interface. In this way, the prover uses the signature as proof and sends it to the mainnet via a secondary mainnet transaction. Specifically, this can be a blockchain ledger invoked in the transaction. This involves the prover sending the signature as proof to the mainnet via a secondary mainnet transaction, invoking the Rollup Contract's verification interface on the mainnet, which then passes the signature. The verification interface then executes verification logic, specifically verifying the validity of the signature. Verifying the validity of the signature primarily involves using the prover's public key to verify the validity of the signature.

[0213] In addition, the certificate of the certifier corresponding to the signature can also be transferred through the second main network transaction through the verification interface, and the certificate can include the public key of the certifier. In this way, in addition to using the public key of the certifier to verify the legitimacy of the signature, it can also include verifying the legitimacy of the certifier certificate. As mentioned above, the certificate can include the remote authentication report generated by the IAS for the certifier, or include the certificate issued by the authentication service for the certifier (it can also include the remote authentication report generated by the IAS for the authentication service). Accordingly, verifying the certificate can include using Intel's authoritative public key to verify the legitimacy of the certifier certificate, or it can include using Intel's authoritative public key to verify the legitimacy of the authentication service's certificate, and using the public key in the authentication service's certificate to verify the legitimacy of the certifier certificate.

[0214] As mentioned above, using TEE as a prover on the second-layer network can bring lower latency because the transaction replay and verification in TEE are close to the speed of native execution.

[0215] The above Figure 4 illustrates the case where there are four global states on Layer 2, namely, the four global states of Alice, Bob, Charlie, and David. In fact, a batch on Layer 2 may contain hundreds or even thousands of transactions, and these transactions may involve more states, such as tens of thousands of states. If the transactions in Layer 2 include transactions involving contracts on Layer 2, then a contract may involve more states, and the overall number of states in Layer 2 is more, such as tens of thousands of states. In this way, in S120, the sorter sends the initial states of all states to the prover in the second-layer network, and the amount of data is relatively large. Therefore, the present application provides a method for implementing a second-layer network convolution, including the following:

[0216] S210: The sequencer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transactions, and executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed and generates a first post-state root.

[0217] The specific process of S210 is similar to that of the aforementioned S110 and will not be repeated here.

[0218] S220: The sequencer sends the packaged transaction, the first transaction root, the SPV proof of the read set before the packaged transaction is executed, and the first pre-state root and the first post-state root to the prover of the second-layer network.

[0219] To illustrate, assume that, as shown in Figure 6, Layer 2 transactions (including both standard transfers and those involving contracts) involve a total of eight states, as shown in the lower left corner of Figure 6, corresponding to the eight hash values ​​8, 9, 10, 11, 12, 13, 14, and 15. Furthermore, assume that the transactions packaged into Batch M, before and after their execution, affect only the states of Alice and Bob corresponding to values ​​8 and 9, while not affecting the states corresponding to values ​​10, 11, 12, 13, 14, and 15. As shown in the figure, after the transactions packaged into Batch M are executed in sequence, only the balances of Alice and Bob are affected, while the balances of Charlie and David remain unchanged (that is, the hash values ​​of tree nodes 10 and 11 remain unchanged, and the contents of these nodes are shown here; the contents of nodes 12, 13, 14, and 15 are also unchanged and omitted here).

[0220] In addition to sending the packaged transaction, the first transaction root, the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network, the sequencer can also send the SPV proof of the packaged transaction read set before the execution of the packaged transaction to the prover of the second-layer network.

[0221] As shown in Figure 6, the sequencer can send the states corresponding to tree nodes 8 and 9, as well as the SPV proof consisting of the hash values ​​of nodes 5 and 3, to the prover on the layer 2 network. This avoids sending the states corresponding to the six leaf nodes 10, 11, 12, 13, 14, and 15 to the prover.

[0222] SPV, itself a concept from Bitcoin, stands for Simplified Payment Verification. SPV proofs work using Merkle trees. The states involved in Batch M form a Merkle tree, with the root of the tree (the Merkle root) contained in the Batch M header. The Merkle tree structure allows for a very short path (the Merkle path) to verify that any state exists under a specific Merkle root. This path only contains the necessary nodes, not all the state content corresponding to the leaf nodes.

[0223] As shown in the example in Figure 6, an SPV proof consists of the states corresponding to two leaf nodes (indicated in yellow) and a Merkle path (indicated in red).

[0224] The Merkel path in the SPV proof mentions Merkle, which is a tree-like data structure. It can be the Merkle tree in Bitcoin, the MPT tree in Ethereum, or SMT, etc.

[0225] MPT stands for Merkle Patricia Tree, a tree structure that combines the Merkle Tree and the Patricia Tree (a compressed prefix tree, a more space-efficient Trie). The Merkle Tree algorithm calculates a hash value for each transaction, then hashes each transaction pairwise until the top-level Merkle root is reached. Ethereum uses a modified MPT tree, such as a hexadecimal tree structure, often referred to as an MPT tree. For example, the aforementioned Ethereum state trie contains key-value pairs (also called key-value, or KV) corresponding to the storage content of each account in the Ethereum network. A "key" in the state trie can be a 160-bit identifier (such as an Ethereum account address or a portion of an address's hash value, collectively referred to as an account address). This account address is distributed throughout the state trie, from the root node to the leaf nodes. The "values" in the state tree are generated by encoding the Ethereum account information (using the Recursive-Length Prefix encoding (RLP) method). As mentioned earlier, for external accounts, the values ​​include nonce and balance; for contract accounts, the values ​​include nonce, balance, codehash, and storage_root.

[0226] As mentioned above, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state trie pointing to state_root is an MPT-style state tree. The root node of this MPT tree is generally an extension node (Extension Node) or a branch node (Branch Node), and the value stored in state_root is generally the hash value of this root node. As shown in Figure 7, the root node can be connected to one or more layers of Extension Node / Branch Node below. These multi-layer tree nodes can be collectively referred to as internal nodes. From the root node of this MPT to the leaf node, a part of the value in each node is sequentially connected to form an account address and used as a key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a part of sha3(Address), that is, a part of the hash value of the account address (the hash algorithm uses the sha3 algorithm, for example). The value stored can be rlp(Account), that is, the rlp encoding of the account information. The account information is

[0227] A four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned above, external accounts generally only have the nonce and balance fields, while the storageRoot and codeHash fields default to empty strings or strings of all zeros. In other words, external accounts do not store contracts or the state variables generated after contract execution. Contract accounts generally include nonce, balance, storage root, and codeHash. Nonce is the transaction counter for the contract account; balance is the account balance; the storage root corresponds to another MPT and can be linked to contract-related status information through the storage root; and codeHash is the hash value of the contract code. Whether it is an external account or a contract account, its account information is generally located in a single leaf node. From the extension node / branch node of the root node to each account's leaf node, there may be several branch nodes and extension nodes in between.

[0228] The state trie can be an MPT-style tree, typically a hexadecimal tree, meaning each layer can have up to 16 child nodes. Extension nodes, used to store common prefixes, typically have one child node, which can be a branch node. Branch nodes can have up to 16 child nodes, which may include extension nodes and / or leaf nodes.

[0229] For a contract account in the state trie, its storage_Root points to another MPT-formatted tree, which stores data related to state variables involved in contract execution. The MPT-formatted tree pointed to by storage_Root is the Storage Trie, which is the hash value of the Storage Trie's root node. Generally, this Storage Trie also stores key-value pairs. The key indicates the address of the state variable. Its value can be the result of processing the location of the state variable declaration in the contract (a value starting from 0) using certain rules, such as sha3 (location of the state variable declaration) or sha3 (contract name + location of the state variable declaration). The value is used to store the value of the state variable (for example, an RLP-encoded value). The key is formed by concatenating a portion of the data stored along the path from the root node through the intermediate nodes to the leaf nodes. The leaf nodes store the value. As mentioned earlier, the Storage trie can also be an MPT-style tree, typically a hexadecimal tree. This means a Branch Node can have up to 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. An Extension Node can typically have one child node, which can be either a Branch Node or a Leaf Node.

[0230] For example, the Leaf Node Account P of the state trie in Figure 7 is a contract account, and its Storage Root locks all states in the contract storage. These states are organized into an MPT tree, and the tree structure is like the Storage trie linked to the Storage Root. In this linked Storage trie, taking Leaf Node State Variable N as an example, for example, the value of storedData in the aforementioned contract code example, its key is sha3 (the declaration location of storedData, which will be detailed later), and its value is s (for the sake of simplicity, the encoding format of the value is omitted here, for example, RLP, which will be similar in the future and will not be repeated). Among them, the key values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0231] For another example, in the state trie of Figure 7, Leaf Node Account C is an external account, and its key is sha3(Address C), which is the hash value of the address of account C (the hash algorithm uses the sha3 algorithm, for example). The value stored can be (Account), where the account information Account is a tuple consisting of [nonce, balance]. As mentioned above, since Account C is an external account, its account information consists of two items: nonce and balance (codehash and storage root are omitted here, and the following are similar). For example, if an external account has a nonce of 20 and a balance of 4550, then the leaf node Leaf Node State Variable C stores nonce = 20 and balance = 4550. The address of Account C is the key, and its values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable C) of the state trie.

[0232] These states, including the key-values ​​of external accounts and contract accounts, are ultimately stored in the database. The database does not directly store the states of these accounts, that is, it does not directly store the key-values ​​of these accounts, but rather stores the key-value values ​​of each tree node itself.

[0233] As shown in the example of Figure 8 , in the previous-level MPT structure, for leaf node A1, the key of this leaf node is formed by sequentially combining a7 in the shared nibble of root node A8 (Extension Node), slot 1 of intermediate node A7 (Branch Node), and 1335 in the key-end of leaf node A1, i.e., a711335. Balance = 45.0 ETH and Nonce = n1 are stored in this leaf node. For leaf node A2, the key of this leaf node is formed by sequentially combining a7 in the shared nibble of root node A8 (Extension Node), slot 7 of intermediate node A7 (Branch Node), d3 in the shared nibble of node A6 (Extension Node), slot 3 of intermediate node A5 (Branch Node), and 7 in the key-end of leaf node A2, i.e., a77d337. Balance = 1.00 WEI and Nonce = n2 are stored in this leaf node. For leaf node A3, the key of the leaf node is formed by sequentially combining a7 of the shared nibble in root node A8 (Extension Node) - slot f of the intermediate node A7 (Branch Node) - 9365 of the key-end in leaf node A3, which is a7f9365. Balance = 1.1ETH, Nonce = n3 are stored in the leaf node. For leaf node A4, the key of the leaf node is formed by combining a7 of the shared nibble in root node A8 (Extension Node) - slot f of the intermediate node A7 (Branch Node) - 9365 of the key-end in leaf node A3, which is a7f9365. Balance = 1.1ETH, Nonce = n3 are stored in the leaf node.

[0234] The key of this leaf node is composed of the following: a7 in the shared nibble of the extension node, slot 7 in the intermediate node A7 (Branch Node), d3 in the shared nibble of the extension node, slot 9 in the intermediate node A5 (Branch Node), and 7 in the key-end of the leaf node A4. This sequence is combined to form the key of this leaf node, which is a77d397. This leaf node stores Balance = 0.12 ETH, Nonce = n4, CodeHash = c1, and Storage root = s1. s1 can be H(A10), the hash of the root node A10 in the next tree layer. The leaf nodes A1, A2, and A3 store information about external accounts, while the leaf node A4 stores information about contract accounts. For contract accounts, they contain the next-level MPT, forming a Storage Trie for storing the state variables of the contract account.

[0235] As shown in the example of Figure 8 , in the next-level MPT structure, for leaf node A11, the key of the leaf node is formed by sequentially combining slot 3 in root node A10 (Branch Node) and the key-end 35b2e4 in leaf node A11, which is 335b2e4. "Zhang San_A = 20" is stored in this leaf node, indicating, for example, that the share of type A digital assets belonging to Zhang San as defined in the contract is 20, that is, Zhang San's balance of type A assets is 20. For leaf node A12, the key of the leaf node is formed by sequentially combining slot 7 in root node A10 (Branch Node) and the key-end c25988 in leaf node A12, which is 7c25988. "Li Si_B = 20" is stored in this leaf node, indicating, for example, that the share of type B digital assets belonging to Li Si as defined in the contract is 50, that is, Li Si's balance of type B assets is 50. For leaf node A15, the key of the leaf node is composed of slot f in root node A10 (Branch Node), a in the shared nibble in intermediate node A13 (Extension Node), slot 6 in intermediate node A14 (Branch Node), and be33 in the key-end in leaf node A15. This is fa6be33, and "storedData=s" is stored in the leaf node. For leaf node A16, the key of the leaf node is composed of slot f in root node A10 (Branch Node), a in the shared nibble in intermediate node A13 (Extension Node), slot 9 in intermediate node A14 (Branch Node), and 9365 in the key-end of leaf node A16. This is fa99365, and "Wang Wu_A=35" is stored in the leaf node. For example, this means that the share of the type A digital asset defined in the contract that belongs to Wang Wu is 35, that is, the balance of Wang Wu's type A assets is 35.

[0236] In the node structure of the above MPT tree, the prefix prefix is ​​used to indicate the tree node type. For example, 0 indicates an Extension Node containing an even number of shared nibbles, 1 indicates an Extension Node containing an odd number of shared nibbles(s), 2 indicates a Leaf Node containing an even number of nibbles, and 3 indicates a Leaf Node containing an odd number of nibbles(s).

[0237] In the above node structure, the hash value of the entire content of the next tree node is filled in the corresponding position of the previous tree node. In fact, the database stores a key-value mapping for each tree node, where the value includes the content stored in this tree node and the corresponding key is the hash value of the entire content of this tree node. Thus, the actual tree node key value stored in the database is as follows:

[0238] Table 3. Tree node kv actually stored in the database

[0239] In Table 3 above, H() represents the hash calculation. This way, the hash value of the next tree node is anchored to the previous tree node. Through this layer-by-layer hashing, the root hash of the entire state trie is obtained and locked into the state root field of the block header.

[0240] In an ordinary MPT tree, specific content (state) is stored in the leaf nodes. However, with the above-mentioned specific structure, when a new state is generated, a new leaf node needs to be inserted into the tree, which will result in a series of changes in the path to the root node, including complex operations such as splitting and merging Branch Nodes and Extension Nodes, and recalculating and updating hash values. Similarly, when a state is deleted, it is necessary to delete the existing leaf nodes on the tree, which will also result in complex operations such as splitting and merging Branch Nodes and Extension Nodes, and recalculating and updating hash values. When a state changes, in addition to the change in the content of the leaf nodes, it will also affect the complex operations such as splitting and merging the Branch Nodes and Extension Nodes of the root node, and recalculating and updating hash values. In general, the depth of the tree and the specific structure of the Branch Nodes and Extension Nodes will change significantly with the change in the state of the leaf nodes.

[0241] The Merkle tree for Bitcoin transactions is similar. When a block contains four transactions, its Merkle tree's leaf nodes consist of these four transactions, meaning it will only have four leaf nodes and the tree will be two levels deep. If a block contains 1024 transactions, there will be 1024 leaf nodes and the tree will be 11 levels deep, which is obviously a much larger tree.

[0242] The SMT (Sparse Merkle Tree) proposed by Libra is also a Merkle-type data structure, but it also has its own particularities and is different from ordinary Merkle trees in some places. The main difference is that the number of leaf nodes, the depth and shape of the tree are fixed in advance. The transaction Merkle tree in Bitcoin and the MPT tree in Ethereum mentioned above have variable tree depth and scale, which means they are dynamic and not fixed. SMT, on the other hand, stores a predetermined number of states that will not change, using a fixed-size tree to store them. For example, the address length of an account in Ethereum is 20 bytes, with a total of 2 160 Different addresses, namely 2 160 Account. In fact, Ethereum accounts can be stored using SMT (although it does not do so). However, it is very likely that there will not be 2 160 Accounts may be significantly smaller than this number. Therefore, for vacant accounts, a default value (e.g., blank) can be used to fill in the blank account to indicate that it is an unused, blank account. In the underlying database, leaf nodes with blank (default value) values ​​can be omitted and only non-blank leaf nodes can be stored.

[0243] The advantage of using SMT is that the size of the Merkle path can often be compressed. For example, using 1 bit to represent a preset value is much smaller than using a complete hash value (for example, the hash value length in hash256 is 256 bits), thereby greatly reducing the size of the SPV proof.

[0244] S230: The prover verifies the first transaction root and verifies the first previous state root based on the SPV proof of the packaged transaction read set; after both verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0245] The prover verifies the first transaction root, similar to the aforementioned S130, and will not be repeated here.

[0246] The prover verifies the first previous state root based on the SPV proof, specifically including: the prover calculates the Merkle root based on the read set of the SPV proof and the Merkle path to obtain the second previous state root, and verifies whether the second previous state root is equal to the first state root. If they are equal, it means that the first previous state root sent by the prover is correct. The characteristics of hash calculation: a small change in the value in each calculation will result in a large difference in the final result. Based on this characteristic, the prover cannot falsify, that is, it cannot provide an incorrect state in the leaf node or provide an incorrect hash value of the Merkle tree node to produce a correct result, that is, it cannot produce a correct Merkle root. Specifically, the prover can calculate the hash value of the content corresponding to node 8 in the lower left corner of Figure 6 as the value of node 8, and calculate the hash value of the content corresponding to node 9 as the value of node 9; the two hash values ​​of node 8 and node 9 are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 4; the two hash values ​​of node 4 and node 5 in the SPV proof are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 2; the two hash values ​​of node 2 and node 3 are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 1, that is, as the second previous state root, so as to verify whether the second previous state root is equal to the first previous state root.

[0247] The prover executes the packaged transactions in sequence and generates the second post-state root. This can be done by the prover executing the packaged transactions in sequence based on the read set involved in the packaged transactions, updating the write set during the execution process, and recalculating the Merkle root based on the updated write set based on the SPV proof to generate the second post-state root. Specifically, as shown in Figure 9, assuming that a batch processed contains three transactions, namely:

[0248] Tx_21: Alice → Bob 20

[0249] Tx_22: Bob → Alice 10

[0250] Tx_23: Alice → Bob 20

[0251] The transactions in this batch involve states related to Alice and Bob. Therefore, the read set involved in this batch can include both accounts Alice and Bob. The SPV proof for this read set can include not only the read sets Alice:50 and Bob:100, but also the hash values ​​of node 5 and node 3 in the Merkle tree. This allows the prover to sequentially execute all transactions in the batch based on this read set, namely, Alice:50 and Bob:100.

[0252] For example, the read / write sets generated by executing Tx_21, Tx_22, and Tx_23 in sequence include the following:

[0253] The read set before Tx_21 is executed includes Alice:50 and Bob:100. After Tx_21 is executed, Alice's account balance changes to 30 and Bob's account balance changes to 120. The resulting write set is Alice:30 and Bob:120.

[0254] The read set before Tx_22 is executed includes Alice:30 and Bob:120. After Tx_22 is executed, Alice's account balance changes to 40 and Bob's account balance changes to 110. The resulting write set is Alice:40 and Bob:110.

[0255] The read set before Tx_23 is executed includes Alice:40 and Bob:110. After Tx_23 is executed, Alice's account balance changes to 20 and Bob's account balance changes to 130. The resulting write set is Alice:20 and Bob:130.

[0256] After the transactions in this batch are executed in order, the final state of this batch is two write sets: Alice: 20 and Bob: 130. The prover combines the hash value of node 5 and the hash value of node 3 in the Merkle tree where the write set is located to obtain the hash value of the root node of the Merkle tree where the updated state is located, that is, the second post-state root. Here, for example, the generated write set is still the content corresponding to nodes 8 and 9 in the Merkle tree. For example, the state corresponding to node 8 is that Alice's balance is changed from 50 to 20 compared to the initial state. The state corresponding to node 9 is that Bob's balance is changed from 100 to 130 compared to the initial state. The prover can recalculate the hash value of leaf node 8 based on Alice: 20 and recalculate the hash value of leaf node 9 based on Bob: 130 to generate new hash values. Similarly, the prover can calculate the hash value of the Merkle root based on the generated write set and the Merkle path in the SPV proof (i.e., the hash values ​​of the two red nodes 3 and 5), thereby serving as the second post-state root.

[0257] Specifically, the prover can calculate the hash value of the write set content corresponding to node 8 as the value of node 8, and calculate the hash value of the write set content corresponding to node 9 as the value of node 9; the two hash values ​​of node 8 and node 9 are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 4; the two hash values ​​of node 4 and node 5 in the SPV proof are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 2; the two hash values ​​of node 2 and node 3 are sequentially spliced, and the hash value is calculated again using the same hash algorithm as the hash value of node 1, that is, as the second post-state root, thereby verifying whether the second post-state root is equal to the first post-state root.

[0258] Furthermore, the prover can verify whether the second post-state root is equal to the first post-state root. If they are, the Sequencer's execution process is correct, because starting from the same initial state, the Sequencer's execution of the packaged transactions in sequence produces the same result as the prover's independent execution of the same packaged transactions in sequence.

[0259] In this way, the prover can verify the signature of the packaged transaction information. Specifically, the prover can verify at least one of the packaged transaction's batch number, the packaged transaction's transaction root, and the packaged transaction's corresponding Post State Root. Signing at least one of these contents indicates the prover's approval of the results produced by the Sequencer's execution of this batch.

[0260] As mentioned above, the prover can be implemented using a TEE. A TEE provides a completely isolated trusted execution environment, allowing the private key to be kept confidential. Thus, after verifying that the second post-state root is equal to the first post-state root, the prover can use its own private key to sign the packaged transaction information, indicating its approval of the signature.

[0261] The prover can be implemented using a TEE. A TEE provides a completely isolated trusted execution environment, allowing it to maintain confidentiality regarding private keys. Thus, after verifying that the second post-state root is equal to the first post-state root, the prover can use its own private key to sign the packaged transaction information, indicating its approval of the signature.

[0262] Before the prover signs the packaged transaction information in S230, the initiator of the Layer 2 transaction can challenge the prover's TEE as a challenger. If the challenge is successful, the initiator of the transaction can confirm that the prover's TEE is legitimate and the code / data loaded in it is trustworthy. As a result, the initiator of the Layer 2 transaction can trust the prover's TEE.

[0263] In addition, after the prover signs the packaged transaction information in S230, other verifiers can also challenge the TEE in the prover as challengers, similar to the above process, which will not be repeated here. In addition, the TEE can hash and sign the input code / data, thereby using its own trustworthiness to guarantee the trustworthiness of the input executed; the TEE can also sign the hash value of the output (that is, the result of the execution), also using its own trustworthiness to guarantee the trustworthiness of the input executed.

[0264] In this way, the prover verifies that the packaged transaction is independently executed (also known as replaying) in sequence based on the initial state and then signs the packaged transaction information, using its own trustworthiness to guarantee the credibility of the output result. Furthermore, the prover can use the signature as proof to send it to the mainnet blockchain ledger via a second mainnet transaction. Anyone who questions the signature can verify it by challenging the TEE in the prover; if the verification is successful, the prover can be confident that the signed transaction information is authentic based on trust in the TEE.

[0265] Verifying the signature involves using the TEE's public key to verify the signature. As long as the public key is trustworthy, the verification is reliable and fast. The prover can use the signature as proof and send it to the mainnet's blockchain ledger via a secondary mainnet transaction. This involves the prover using the signature as proof and sending it to the mainnet via a secondary mainnet transaction, invoking the Rollup contract on the mainnet. Upon receiving the transaction, the Rollup contract verifies the correctness of the signature using the verification logic within the contract.

[0266] In summary, the prover can send the certificate to the mainnet's blockchain ledger via a secondary mainnet transaction. In a typical approach, the prover can send the certificate and its signature to the mainnet's blockchain ledger via a secondary mainnet transaction. When using the aforementioned EPID solution, the certificate includes a remote attestation report generated by the IAS for the prover. This allows the verifier to verify the legitimacy of the prover's signature on the transaction information by verifying this certificate. When using the aforementioned DCAP solution, the certificate can include the certificate issued by the authentication service for the prover. If trust in the authentication service is established, this can be extended to the certificate issued by the authentication service for the prover, allowing the verifier to verify the prover's signature using the public key in this certificate. If a higher level of trust is required, in addition to the certificate issued by the authentication service for the prover, the remote attestation report generated by the IAS for the authentication service may also be required. This way, the authenticity of the authentication service's signature can be guaranteed through Intel's authoritative authentication (i.e., the remote attestation report, equivalent to the certificate issued by Intel for the authentication service). Combined with the certificate issued by the authentication service for the prover, this trust can be transmitted downward, thereby ensuring the authenticity of the prover's signature. This is how SGX DCAP provides trust in the form of certificate chains.

[0267] The verification logic executed by the aforementioned verifier can be embedded within the Rollup Contract and exposed externally via a contract interface, such as a verification interface. In this way, the prover uses the signature as proof and sends it to the mainnet via a secondary mainnet transaction. Specifically, this can be a blockchain ledger invoked in the transaction. This involves the prover sending the signature as proof to the mainnet via a secondary mainnet transaction, invoking the Rollup Contract's verification interface on the mainnet, which then passes the signature. The verification interface then executes verification logic, specifically verifying the validity of the signature. Verifying the validity of the signature primarily involves using the prover's public key to verify the validity of the signature.

[0268] In addition, the certificate of the certifier corresponding to the signature can also be transferred through the second main network transaction through the verification interface, and the certificate can include the public key of the certifier. In this way, in addition to using the public key of the certifier to verify the legitimacy of the signature, it can also include verifying the legitimacy of the certifier certificate. As mentioned above, the certificate can include the remote authentication report generated by the IAS for the certifier, or include the certificate issued by the authentication service for the certifier (it can also include the remote authentication report generated by the IAS for the authentication service). Accordingly, verifying the certificate can include using Intel's authoritative public key to verify the legitimacy of the certifier certificate, or it can include using Intel's authoritative public key to verify the legitimacy of the authentication service's certificate, and using the public key in the authentication service's certificate to verify the legitimacy of the certifier certificate.

[0269] As mentioned above, using TEE as the prover on the second-layer network can bring lower latency because the transaction replay and verification in TEE are close to the speed of native execution. Once the local TEE passes the remote authentication, through the TEE mechanism, the CPU can process the data in the enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency. This is much faster than the ZK-Rollup method. For example, under the same circumstances, generating proofs from ZK-Rollup requires an interval of 30 to 50 minutes (or hours) (Block N to Block N+412 in Figure 4), which is shortened to 5 to 10 minutes in this application (which can be called TEE-Rollup) (Block N to Block N+62 in Figure 6). Even if the monitoring mode is not adopted and S230 is executed directly after S220, the time will be shortened to even less. In addition, the generated proof is the size of a signature, about tens of bytes, similar to ZK-Rollup.

[0270] Similar to the above, the information signature of the packaged transaction can be a signature of at least one of the batch number of the packaged transaction, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction.

[0271] The information signature for the packaged transaction may be a signature for at least one of the numbers of several consecutive packaged batches, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction; or a signature for at least one of the batch number, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction in each group after the several consecutive packaged batches are grouped.

[0272] Before the prover verifies the first transaction root and the first previous state root, the process may further include: the sequencer sending a first mainnet transaction that calls the wrapping contract to the mainnet, where the first transaction includes the fields in the batch header of the packaged transaction, as well as a compressed transaction or a compressed read-write set (termed as a State Diff);

[0273] Furthermore, the prover can monitor the execution results of the contract on the main network. The details are similar to the previous embodiment and will not be repeated here.

[0274] Furthermore, the certifier may also transmit the certificate and signature together to the mainnet's blockchain ledger via a secondary mainnet transaction. The certificate may include a remote attestation report generated by the IAS for the certifier, a certificate issued by the authentication service for the certifier, or a remote attestation report generated by the IAS for the authentication service.

[0275] The prover uses the signature as proof and sends it to the mainnet's blockchain ledger via a second mainnet transaction. This includes the prover using the signature as proof and sending it to the mainnet via a second mainnet transaction, thereby invoking the Rollup contract on the mainnet. This may also include: upon receiving the transaction, the Rollup contract verifies the correctness of the signature using verification logic within the contract. Upon receiving the transaction, the Rollup contract verifies the correctness of the signature using verification logic within the contract. This may also include: verifying the legitimacy of a certificate containing the prover's public key.

[0276] The verification of the legitimacy of the certificate may specifically include:

[0277] Use Intel's authoritative public key to verify the legitimacy of the prover certificate; or,

[0278] Intel's authoritative public key is used to verify the legitimacy of the authentication service's certificate, and the public key in the authentication service's certificate is used to verify the legitimacy of the certifier's certificate.

[0279] To increase the TPS in Layer 2, transaction execution speed needs to be accelerated. Parallel computing can be used to speed up transaction execution. Parallel computing, as opposed to serial computing, is an algorithm that executes multiple instructions simultaneously. Its purpose is to increase computational speed and solve large and complex computational problems by expanding the scale of problem solving. Parallel computing can be categorized as temporal and spatial. Temporal parallelism refers to pipeline technology, while spatial parallelism involves the concurrent execution of computations by multiple processors. Furthermore, to improve efficiency, grouping or pipeline execution is often employed in the execution process. When Prover performance is high, the overall performance bottleneck lies in the Sequencer's transaction execution process. The transaction execution portion of the Sequencer can be decoupled, for example, into an Executor, as shown in Figure 10. This allows the aforementioned pipeline approach to improve overall execution speed. In addition, the Executor can be horizontally scaled (also called scaling out), that is, the Executor can be expanded into multiple entities (logical entities or physical entities), as shown in Figure 11; in this way, the aforementioned group execution method can be adopted to increase the execution speed of the execution link, thereby improving the utilization of Prover.

[0280] The following first uses FIG10 as an example to provide an embodiment of a method for implementing a two-layer network convolution in a pipeline manner, including:

[0281] S310: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor.

[0282] Subsequently, the executor and prover execute S320 and S330 in parallel:

[0283] S320: The executor generates a first transaction root for a subsequent packaged transaction, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transaction, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the execution of the subsequent packaged transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0284] The subsequent packaged transactions refer to the packages with later sequence numbers relative to the preceding packaged transactions in S330. For example, if the sequence number of the subsequent packaged transactions is N+1, then S320 specifically includes: the executor generating a first transaction root for the transactions in the N+1th package, sequentially executing the transactions in the N+1th package based on the initial state before the execution of the transactions in the N+1th package, and generating a first post-state root; the executor sending the transactions in the N+1th package, the first transaction root, the initial state before the execution of the transactions in the N+1th package, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the Layer 2 network; the prover is implemented using a trusted execution environment.

[0285] S330: The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0286] Accordingly, the preceding packaged transaction refers to the package with a sequence number that precedes the subsequent packaged transaction in S320. For example, if the sequence number of the preceding packaged transaction is N, then S330 described above specifically includes: the prover verifies the first transaction root and the first previous state root in the Nth package; after both verifications are successful, the prover executes the transactions in the Nth package in sequence based on the initial state to generate a second subsequent state root; after verifying that the second subsequent state root is equal to the first subsequent state root, the prover uses the private key in the trusted execution environment to sign the information of the transactions in the Nth package, and sends the signature as proof to the main network blockchain ledger via a second main network transaction.

[0287] Subsequent packaged transactions after the previous packaged transaction are not limited to the relationship between sequence numbers N and N+1, for example, they can be the relationship between N and N+2.

[0288] In this way, the executor can continuously execute the corresponding work of subsequent packaged transactions and send the results to the prover, while the prover can continuously execute the corresponding work of the previous packaged transactions, forming a pipelined operation. As a result, the computing power of the executor and prover can be efficiently utilized, enabling the continuous execution of transactions and the continuous generation of proofs.

[0289] In the case of SPV proof, the above scheme is as follows:

[0290] S410: The sequencer of the layer 2 network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0291] Subsequently, the executor and prover can execute S420 and S430 in parallel:

[0292] S420: The executor generates a first transaction root for subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the packaged transactions are executed, and generates a first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before the execution of the subsequent packaged transactions, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0293] S430: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after both verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0294] The following uses FIG11 as an example to provide an embodiment of a method for implementing a two-layer network convolution in a packet parallel manner, including:

[0295] S510: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependencies, and sends the different groups to the executor participants.

[0296] The at least two executors are at least two executor threads / coroutines or at least two executor processes. These at least two executors can be located in the same process; alternatively, the at least two executors can be located on the same physical machine / virtual machine or on different physical machines / virtual machines. When the at least two executor processes are located on different physical machines / virtual machines, these different physical machines / virtual machines can be physical machines / virtual machines of the same party. This eliminates trust issues between the physical machines / virtual machines of the same party.

[0297] For example, after the sorter sorts and packages the pulled transactions, it groups the packaged transactions. For ordinary transfer transactions, multiple transactions can be divided into multiple transaction groups based on the accounts accessed by the transactions. Each transaction group does not access the same account, so that each transaction group can be executed in parallel. When the transaction involves calling a smart contract, in some simple cases, static analysis of the smart contract code can be performed to obtain the accessed (including read / write) state variables; in addition, in some complex cases, the state variables accessed in the transaction cannot be predicted before the transaction is executed, so multiple transactions cannot be effectively grouped, and thus transactions cannot be executed in parallel. For the latter, multiple transactions can be pre-executed to obtain the pre-execution read-write set of each transaction, so that these transactions can be grouped according to the pre-execution read-write set. Of course, ordinary transfer transactions can also be pre-executed to obtain the read-write set.

[0298] Specifically, a transaction's pre-execution read-write set includes, for example, a pre-execution read set and a pre-execution write set. The pre-execution read set includes key-value pairs of variables read by the transaction during pre-execution, and the pre-execution write set includes key-value pairs of variables written by the transaction during pre-execution. The state variables include, for example, external accounts in Layer 2 or state variables defined in a contract account.

[0299] Multiple transactions can be grouped using different algorithms. In one embodiment, multiple transactions can be grouped using a directed acyclic graph (DAG) algorithm. Specifically, a DAG graph is first drawn between multiple transactions based on the dependencies between them. For example, assuming that the slave node executes multiple transactions according to the order in which the master node pre-executes the multiple transactions, the dependencies between the transactions can be determined based on the pre-execution read-write sets and pre-execution order of the multiple transactions. If the pre-execution read set of one transaction includes the same key as the pre-execution write set of another transaction, or if the write set of one transaction includes the same key as the write set of another transaction, then the later pre-executed transaction (e.g., transaction Tx2) of the two transactions needs to depend on the earlier pre-executed transaction (e.g., transaction Tx1). Therefore, in the DAG graph, transaction Tx1 can be drawn pointing to transaction Tx2. If transaction Tx2 depends on the execution of transaction Tx1, transactions Tx1 and Tx2 can be considered conflicting transactions and need to be executed serially, that is, transaction Tx2 is executed after transaction Tx1.

[0300] Figure 12 is a schematic diagram of a DAG graph for multiple transactions in one embodiment. Circles in the figure represent nodes in the DAG graph, numbers within the circles represent transaction numbers, and arrows between nodes represent directed edges connecting the nodes. After obtaining the DAG graph for multiple transactions, the transactions can be grouped according to the DAG graph so that the transactions in each two transaction groups appear as separate nodes in the DAG graph. That is, there are no edges connecting any transaction in one transaction group to any transaction in another transaction group.

[0301] As shown in Figure 12, the multiple transactions connected by arrows (i.e., transactions Tx1-Tx8) are conflicting transactions and need to be grouped together. When executing transactions Tx1-Tx8, transactions (Tx3, Tx5) and (Tx1, Tx2, Tx4) can be executed in parallel first. Transactions Tx3 and Tx5 are executed serially, while transactions Tx1, Tx2, and Tx4 need to be executed serially. Transaction Tx6 must wait for transactions Tx4 and Tx5 to complete before executing, and transactions T7 and T8 must wait for transactions T5 and T6 to complete before executing in parallel. Transactions Tx5 and Tx6 connect three or more nodes, also known as forks. When there are many forks in a DAG graph, subsequent transactions will have to wait longer for these forks. Furthermore, the DAG algorithm requires a larger state space. Therefore, when there are many conflicting transactions, the efficiency of the DAG grouping algorithm decreases.

[0302] In another implementation, multiple transactions can be grouped using a union-find algorithm. A union-find algorithm is a tree-like data structure used to merge and query disjoint sets. Union-find typically involves two operations: find, which queries whether two elements are in the same set; and union, which combines two disjoint sets into a single set. Using this algorithm, when two transactions' pre-execution read / write sets contain the same key, the two transactions can be merged into the same set, resulting in multiple sets. Transactions in each set will not access the same key, allowing for parallel processing of multiple sets. However, since the union-find algorithm does not consider whether transactions access keys for reads or writes, it groups two transactions together if they access the same key. This can potentially group two transactions that read the same key together. Therefore, compared to the grouping results obtained using the DAG algorithm, the multiple transaction groups generated using the union-find algorithm exhibit a lower degree of parallelism.

[0303] The executor participant may include multiple executors. The sorter may also read the value in the read set of each transaction set of the group in the storage, and send the read value to the corresponding executor.

[0304] S520: The executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0305] A Sequencer can connect to multiple Executors of a participant, such as the one shown in Figure 11, which connects to two Executors of a participant. A participant can use an Executor to generate the first transaction root of the packaged transaction. Furthermore, a participant can use the at least two Executors to sequentially execute different transaction groups within the packaged transaction. The "one Executor" here can be one of the two Executors or not.

[0306] After the at least two executors each sequentially execute different transaction groups in the packaged transaction, they may send the execution results to a "one executor," which then merges the execution results of all transaction groups and generates a first post-state root. The executor may then send the packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network. The "one executor" herein may be one of the "at least two executors" or none of them.

[0307] S530: The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0308] In this way, the executor can continuously execute the corresponding work of the next packaged transaction and send the results to the prover, while the prover can continuously execute the corresponding work of the previous packaged transaction. As a result, the computing power of the prover can be efficiently utilized, and the continuous and rapid generation of proofs can be achieved.

[0309] In addition, the grouping of packaged transactions can be done by the participant-executor instead of the sequencer. The embodiment of this situation is as follows:

[0310] S610: The sequencer of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants.

[0311] S620: The executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups transactions that have no dependencies and sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the packaged transaction, and an executor merges the execution results of all the transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0312] S630: The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0313] The following is an embodiment of a method for implementing Layer 2 network convolution using a packet parallelization + pipeline approach, including:

[0314] S710: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependencies, and sends different groups to executor participants.

[0315] Execute S720 and S730 in parallel:

[0316] S720: The executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0317] Specifically, it can be as follows: the executor participant uses an executor to generate the first transaction root of the N+1th packaged transaction; the at least two executors each execute different transaction groups in the N+1th packaged transaction in sequence based on the initial state before the execution of the N+1th packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the N+1th packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0318] S730: The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0319] Specifically, it can be as follows: the prover verifies the first transaction root and the first pre-state root in the Nth packaged transaction; after the two verifications are passed, the Nth packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the Nth package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0320] In the above example, the grouping of packaged transactions can also be performed by the participant-executor instead of the sequencer. The embodiment of this situation is as follows:

[0321] S810: The sequencer of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants.

[0322] Execute S820 and S830 in parallel:

[0323] S820: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependencies and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0324] Specifically: the executor participant uses an executor to generate the first transaction root of the N+1th packaged transaction, and groups transactions that have no dependencies and sends different groups to at least two executors; the at least two executors each executes different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the N+1th packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the N+1th packaged transaction, the first transaction root, the initial state before the transaction execution, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.

[0325] S830: The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0326] Specifically: the prover verifies the first transaction root and the first pre-state root in the Nth packaged transaction; after both verifications are passed, the Nth packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the Nth package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0327] In each of the above embodiments, when the overall performance of the executor is high, the overall performance bottleneck may lie in the Prover TEE verification process. In this case, multiple Prover TEEs can be expanded to execute the above process in parallel. Obviously, the parallel execution of multiple Prover TEEs can increase the speed of Layer 1 verification, thereby further reducing the latency of Layer 1 transaction confirmation.

[0328] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0329] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0330] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root for the packaged transactions, executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed, and generates a first post-state root; the sequencer sends the packaged transactions, the first transaction root, the SPV proof of the packaged transaction read set before the packaged transactions are executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network;

[0331] The prover is used to verify the first transaction root and the first pre-state root based on the SPV proof of the packaged transaction read set; after both verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the packaged transaction information is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the main network blockchain ledger through a second main network transaction.

[0332] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0333] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0334] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0335] The executor and prover execute S320 and S330 in parallel:

[0336] S320: The executor generates a first transaction root for a subsequent packaged transaction, executes the subsequent packaged transactions in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the subsequent packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to a prover in the Layer 2 network; the prover is implemented in a trusted execution environment;

[0337] S330: The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0338] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0339] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0340] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;

[0341] The executor and prover execute S420 and S430 in parallel:

[0342] S420: The executor generates a first transaction root for subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before execution of the subsequent packaged transactions, and generates a first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;

[0343] S430: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after both verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0344] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0345] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0346] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0347] The executor participant uses an executor to generate a first transaction root for the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and the executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0348] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0349] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0350] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0351] The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0352] The executor participant uses an executor to generate the first transaction root of the packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the second-layer network; the prover is implemented using a trusted execution environment;

[0353] The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after both verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0354] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0355] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0356] The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends the different groups to the executor participants;

[0357] The executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each sequentially execute different transaction groups in the subsequent packaged transaction based on the initial state before execution of the subsequent packaged transaction, and the executor combines the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover on the Layer 2 network; the prover is implemented using a trusted execution environment;

[0358] The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through a second main network transaction.

[0359] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:

[0360] The transaction pool is used to receive transactions sent by users on the second-layer network;

[0361] The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;

[0362] Execute S820 and S830 in parallel:

[0363] S820: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, groups transactions that do not have dependencies, and then sends the different groups to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to a prover in the Layer 2 network; the prover is implemented using a trusted execution environment;

[0364] S830: The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after both verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

[0365] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0366] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0367] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0368] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0369] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0370] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0371] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0372] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0373] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0374] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0375] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0376] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0377] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0378] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0379] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for implementing a layer 2 network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transaction, and executes the packaged transactions in sequence based on the initial state before the packaged transaction is executed and generates a first post-state root; The sequencer sends the packaged transaction, the first transaction root, the SPV proof of the read set before the packaged transaction is executed, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root, and verifies the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

2. The method of claim 1, wherein the prover verifies the first previous state root based on the SPV proof, comprising: The prover calculates a Merkle root based on the read set of the SPV proof and the Merkle path, obtains a second previous state root, and verifies whether the second previous state root is equal to the first previous state root.

3. The method of claim 1, wherein the step of executing the packaged transactions in order and generating a second post-state root comprises: The packaged transactions are executed in sequence based on the packaged transaction read set, and the write set is updated during the execution process, and the Merkle root is recalculated according to the updated write set based on the SPV proof to generate a second post-state root.

4. A method for implementing a two-layer network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor; The executor and prover execute S1 and S2 in parallel: S1: The executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the subsequent packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment; S2: The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

5. A method for implementing a two-layer network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor; The executor and prover execute S3 and S4 in parallel: S3: The executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the SPV proof of the read set before the transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment; S4: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

6. A method for implementing a layer 2 network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependency relationship, and sends different groups to the executor participants; The executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

7. A method for implementing a two-layer network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants; The executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

8. A method for implementing a two-layer network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependency relationship, and sends different groups to the executor participants; The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover The device is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

9. A method for implementing a two-layer network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants; Execute S5 and S6 in parallel: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

10. The method according to any one of claims 1 to 9, wherein there are at least two provers and the provers are executed in parallel.

11. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; A sequencer pulls transactions from a transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transaction, and executes the packaged transaction in sequence based on the initial state before the packaged transaction is executed and generates a first post-state root; the sequencer sends the packaged transaction, the first transaction root, the SPV proof of the packaged transaction read set before the packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; The prover is used to verify the first transaction root and verify the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

12. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor; The executor and prover execute S1 and S2 in parallel: S1: The executor generates the first transaction root of the subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed and generates the first post-state root; the executor sends the subsequent packaged transaction The prover of the packaged transaction, the first transaction root, the initial state before the execution of the subsequent packaged transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the second-layer network; the prover is implemented in a trusted execution environment; S2: The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

13. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor; The executor and prover execute S3 and S4 in parallel: S3: The executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the SPV proof of the read set before the transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment; S4: The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

14. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends different groups to the executor participants; The executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

15. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants; The executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups the transactions that do not have a dependency relationship and then sends the different groups to at least two executors; the at least two executors are each based on In the initial state before the packaged transaction is executed, different transaction groups in the packaged transaction are executed in sequence, and an executor merges the execution results of all the transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

16. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends different groups to the executor participants; The executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

17. A second-layer network, comprising a transaction pool, a sequencer, and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants; The executor and prover execute S5 and S6 in parallel: S5: The executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment; S6: The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.

Images