Method for implementing a two-layer network volume and two-layer network

Abstract

The specification provides a method for implementing a two-layer network volume stack, comprising: a sequencer of a two-layer network pulling transactions from a transaction pool, sequencing and packaging the pulled transactions, generating a first transaction root of the packaged transactions, and executing the packaged transactions in sequence based on an initial state before the execution of the packaged transactions and generating a first post-state root; the sequencer sends the packaged transactions, the first transaction root, the initial state before the execution of the packaged transactions, and the first pre-state root and the first post-state root corresponding to the initial state to a prover of the two-layer network; the prover is implemented using a trusted execution environment; the prover verifies the first transaction root and the first pre-state root; after two verifications, the packaged transactions are executed in sequence based on the initial state, a second post-state root is generated, and after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transactions is signed using a private key in the trusted execution environment, the signature is taken as proof, and is sent to the blockchain ledger of the main network through a second main network transaction.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for implementing a two-layer network and a two-layer network. Background Technology

[0002] In distributed systems, there exists the classic CAP theorem—Consistency, Availability, and Partition tolerance—and these three cannot be simultaneously achieved, a problem known as the "impossible triangle." A similar impossible triangle exists in blockchain: efficiency, decentralization, and security. While there is no definitive theoretical proof for this blockchain "impossible triangle," it is a summary of existing blockchain practices. Efficiency, decentralization, and security are defined as follows:

[0003] Efficiency: The number of transactions processed per second, or TPS (Transactions per Second).

[0004] Decentralization: The barrier to entry 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 enough to launch an attack on the blockchain.

[0006] To address the aforementioned "blockchain trilemma," Ethereum (also known as the "mainnet" or "Layer 1"; other popular public blockchain projects like Binance's BSC and TRON also fall under the Layer 1 / mainnet category) prioritized security and decentralization, sacrificing efficiency, currently achieving only about 12-15 TPS. When a large number of transactions need to be processed, especially complex transactions, Layer 1 becomes congested. Besides ordinary transfer transactions, Layer 1 also serves as a major platform for popular applications like DeFi (Decentralized Finance) and NFTs (Non-fungible tokens). During periods of high transaction volume, Layer 1 congestion becomes severe, leading to significant transaction delays and impacting user experience.

[0007] Furthermore, high gas fees (or transaction fees) often become an obstacle to transactions. Although the shift from PoW (Proof-of-Work) to PoS (Proof-of-Stake) has changed, this only alters the way the right to record transactions on the blockchain; the transaction fees paid to the nodes that gain this right have not significantly decreased. This is because gas fees are designed to cover the costs incurred by nodes executing transactions (including executing smart contract code), and without changing these costs, gas fees will not decrease. For example, the transaction fee for a cryptocurrency exchange on a decentralized exchange can exceed $100 during periods of congestion, deterring many users.

[0008] Layer 2 technology is a scalable solution built on top of Layer 1, designed to address the inefficiencies and high transaction fees of Layer 1. For example... Figure 1 As shown, transactions can be executed quickly on Layer 2, and Layer 2 synchronizes the final state back to Layer 1 at certain intervals. Layer 2 is dedicated to providing high-speed transaction processing, while security and decentralization are handled by Layer 1. This reduces the pressure on Layer 1 while significantly decreasing the gas fees for executing transactions on Layer 2, and also significantly reducing the gas fees required to synchronize the final state of transactions executed on Layer 2 (rather than all states on Layer 2) back to Layer 1. The technology of building Layer 2 on top of Layer 1 essentially separates the execution process of transactions or contracts from the storage of the final state; the execution process is placed on Layer 2, while Layer 1 only needs to store the final state. This design requires ensuring the correctness of the execution process of transactions or contracts on Layer 2, and that the state written to Layer 1 is consistent with the result of correct execution on Layer 2.

[0009] Ethereum's Layer 2 includes a mechanism called Rollup. The core idea of ​​Rollup is as follows: Figure 1 As shown, Layer 1 stores credentials that can verify the transaction process, while the transaction process (computation process) and state storage run in Layer 2. The credentials for the transaction process include a set of states before transaction execution (Pre-State) and after transaction execution (Post-State), as well as the transaction itself. These credentials can be used to verify the correctness of the state transitions corresponding to the transaction set, and can also be used to reconstruct the execution process of all transactions and the state of all accounts on Layer 2, thereby eliminating security risks arising from data availability on Layer 2. Summary of the Invention

[0010] This specification provides a method for implementing two-layer network convolution and a two-layer network, which is implemented in the following way:

[0011] A method for implementing two-layer network convolution includes:

[0012] The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates the first transaction root of the packaged transactions, and executes the packaged transactions in sequence based on the initial state before the execution of the packaged transactions and generates the first post-state root.

[0013] The sorter sends the packaged transactions, the first transaction root, the SPV proof of the pre-execution read set of the packaged transactions, and the first pre-state root and the first post-state root to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment.

[0014] 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 both verifications are passed, the packaged transactions are 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. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0015] A method for implementing two-layer network convolution includes:

[0016] 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;

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

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

[0019] S2: The prover verifies the first transaction root and the first pre-state root of the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0020] A method for implementing two-layer network convolution includes:

[0021] 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;

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

[0023] S3: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the 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 transaction in the (N+1)th packet, as well as the first pre-state root and the first post-state root to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0024] S4: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

[0025] A method for implementing two-layer network convolution includes:

[0026] 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 different groups to the executor participants.

[0027] The executor participants use one executor to generate the first transaction root of the packaged transaction; each of the at least two executors sequentially executes different transaction groups in the packaged transaction based on the initial state before the execution of the packaged transaction, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0028] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0029] A method for implementing two-layer network convolution includes:

[0030] The sorter in the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0031] The executor participants use one executor to generate the first transaction root of the packaged transaction, and group transactions that have no dependencies into different groups and send the different groups to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0032] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0033] A method for implementing two-layer network convolution includes:

[0034] 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 different groups to the executor participants.

[0035] The executor participants use one executor to generate the first transaction root of subsequent packaged transactions; each of the at least two executors executes different transaction groups in the subsequent packaged transactions sequentially based on the initial state before the execution of the subsequent packaged transactions, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants send the subsequent packaged transactions, 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 Layer 2 network; the prover is implemented using a trusted execution environment;

[0036] The proofer verifies the first transaction root and the first pre-state root in the preceding packaged transaction. After both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0037] A method for implementing two-layer network convolution includes:

[0038] The sorter in the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0039] Execute S5 and S6 in parallel:

[0040] S5: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the layer 2 network; the prover is implemented using a trusted execution environment;

[0041] S6: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0042] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0043] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0044] The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates the first transaction root of the packaged transactions, executes the packaged transactions in sequence based on the initial state before the execution of the packaged transactions, and generates the first post-state root; the sorter sends the packaged transactions, the first transaction root, the SPV proof of the packaged transaction read set before the execution of the packaged transactions, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the layer 2 network.

[0045] 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 both verifications are passed, the packaged transactions are 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 a private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0046] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0047] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0048] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor.

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

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

[0051] S2: The prover verifies the first transaction root and the first pre-state root of the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0052] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0053] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0054] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor.

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

[0056] S3: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the 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 transaction in the (N+1)th packet, as well as the first pre-state root and the first post-state root to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0057] S4: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

[0058] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0059] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0060] The sorter 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.

[0061] The executor participants use one executor to generate the first transaction root of the packaged transaction; each of the at least two executors sequentially executes different transaction groups in the packaged transaction based on the initial state before the execution of the packaged transaction, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0062] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0063] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0064] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0065] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0066] The executor participants use one executor to generate the first transaction root of the packaged transaction, and group transactions that have no dependencies into different groups and send the different groups to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0067] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0068] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0069] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0070] The sorter 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.

[0071] The executor participants use one executor to generate the first transaction root of subsequent packaged transactions; each of the at least two executors executes different transaction groups in the subsequent packaged transactions sequentially based on the initial state before the execution of the subsequent packaged transactions, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants send the subsequent packaged transactions, 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 Layer 2 network; the prover is implemented using a trusted execution environment;

[0072] The proofer verifies the first transaction root and the first pre-state root in the preceding packaged transaction. After both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0073] A two-layer network includes a transaction pool, a sorter, and a prover, wherein:

[0074] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0075] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0076] The actuator and the prover execute S5 and S6 in parallel:

[0077] S5: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the layer 2 network; the prover is implemented using a trusted execution environment;

[0078] S6: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0079] Through the embodiments of this application described above, TEE is used as a proof-maker on the Layer 2 network. Since the replay and verification of transactions in TEE is close to the speed of native execution, it can bring lower latency. Attached Figure Description

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

[0081] Figure 1 This is a schematic diagram of the principle of Layer 2 in one embodiment;

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

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

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

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

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

[0087] Figure 7 This is a schematic diagram of the principle of an MPT tree in one embodiment;

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

[0089] Figure 9 This is a schematic diagram of the principle of Layer 2 in one embodiment;

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

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

[0092] Figure 12 This is a schematic diagram of the principle of DAG in one embodiment. Detailed Implementation

[0093] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0094] The principle of Rollup can be explained as follows: Figure 2 and Figure 3 ( Figure 3 The main example is the OP-Rollup shown below.

[0095] The transaction to create a smart contract is sent to Layer 1. After consensus is reached on Layer 1, each node on Layer 1 can execute the transaction, thus completing the contract deployment. Specifically, this transaction can be executed by the EVM / WASM of the blockchain nodes. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented through it. This is one of the biggest improvements of Ethereum as a representative of blockchain 2.0 compared to blockchain 1.0. Users can publish and invoke smart contracts in Ethereum, which can run on the EVM. After executing the transaction to deploy the smart contract, 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 nonce counter, a hash value (Codehash) of the contract code, and a storage root (Storage_Root). Through Codehash and Storage_Root, the contract code and account storage can be stored in this contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, smart contracts enable the creation of a virtual account on the blockchain that contains contract code and account storage (Storage). Subsequently, nodes on Layer 1 can receive transaction requests to invoke deployed smart contracts. These requests can include the address of the invoked contract, the functions within that contract, and the input parameters. Generally, after consensus is reached, each node on the blockchain can independently execute the specified smart contract.

[0096] In Ethereum, `Storage_root` is the hash of the root node of an MPT tree, which organizes the storage of contract account states. MPT stands for Merkle Patricia Tree, a tree structure combining Merkle Tree and Patricia Tree (a more space-efficient Trie tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins pairs of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal tree structure, often simply 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 composed of the states of all accounts in the current block; that is, it points to a state trie in MPT form. The values ​​from each node in this MPT, from the root to the leaf nodes, can be concatenated sequentially to form an account address, which serves as the key. The account information stored in the leaf nodes is the value corresponding to this account address, thus forming a key-value pair. Specifically, the key can be sha3(Address), the hash value of the account address (using a hash algorithm such as sha3), and the stored value can be rlp(Account), the rlp (Recursive Length Prefix) encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. For external accounts (Externally Owned Accounts, EOAs), generally only nonce and balance are stored, while storageRoot and codeHash fields default to storing empty strings or strings of all zeros. That is, external accounts do not store contracts or state variables generated after contract execution. Contract accounts generally include Nonce, Balance, StorageRoot, and CodeHash. Whether it is an external account or a contract account, its account information is generally located in a separate leaf node.

[0097] In this context, for a contract account (CA) within the state trie, its storage_root points to another tree, also in MPT form, which stores data related to the state variables involved in contract execution. This MPT-form tree pointed to by storage_root is a Storage Trie, meaning that storage_root stores the hash value of the root node of the Storage Trie. Generally, this Storage Trie also stores key-value pairs. The key indicates the address of the state variable, and its value can be the result of processing the position of the state variable declaration in the contract (counting from 0) according to certain rules, such as SHA3(state variable declaration position) or SHA3(contract name + state variable declaration position). The value is used to store the value of the state variable (e.g., a value encoded using RLP). A portion of 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 Storage trie, except for the leaf nodes, the root node and intermediate nodes use... Figure 3 The cloud-like shape is used to represent its flexible and complex structure.

[0098] like Figure 2 As shown, Rollup Contracts can be deployed on Layer 1 in Rollup. Layer 2 can receive initiated transactions, such as Tx_21 and Tx_22 in the diagram. A batch of transactions is called a Batch, and they are executed sequentially as a whole, updating the state. Figure 1 and 2 As shown, 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. Layer 2 can sort these transactions according to a rule, and then execute them sequentially, for example, by timestamps. After the transactions in a batch are executed in order, the resulting states can include several possibilities; for example, the transactions in Batch 1 are as follows:

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

[0100] Tx_22: Alice→Charlie 10; This means Alice transfers 10 units of assets, such as Ether, to Charlie.

[0101] Tx_23: Bob→Charlie 10; This means Bob transfers 10 units of assets, such as Ether, to Charlie.

[0102] Before the transactions in Batch 1 are executed, there are 4 states, which are referred to as the initial states of Batch 1. Figure 3 The state values ​​locked by the Pre-State Root are as follows:

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

[0104] After the transactions in Batch 1 are executed, these four states are updated to the final states of Batch 1, i.e. Figure 3 The state values ​​locked by the PostState Root are:

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

[0106] In Layer 2, a Merkle tree can be used to organize the states of transactions in Batch 1 before and after sequential execution. For example... Figure 3 As shown, in Layer 2, the transactions of a batch and their related state changes can be organized together. For example, the Merkle root obtained by organizing the hash values ​​of the transactions in Batch 1 according to a Merkle tree can be 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 earlier, the Merkle root obtained by organizing all the state values ​​of the transactions in Batch 1 before execution according to a Merkle tree can be locked in the batch header, i.e., the Pre-State Root; the Merkle root obtained by organizing the hash values ​​of all the state values ​​of the transactions in Batch 1 after sequential execution can be locked in the batch header, i.e., 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+1)th batch, the PreState Root in its block header is equal to the PostState Root in the block header of the Mth batch, such as... Figure 3 The line connecting these two roots represents the structure. This creates a chain-like structure between batches.

[0107] Layer 2 Rollup mechanisms can include two types: Optimistic-Rollup (OP-Rollup) and ZK-Rollup (ZK stands for zero knowledge proof Rollup). Both of these Rollup mechanisms have smart contracts deployed on Ethereum, as described above—Rollup Contracts.

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

[0109] like Figure 3 As shown in the diagram, assume that TxPool collects transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24. The Sequencer sorts and packages these transactions according to their timestamps. For example, it packages Tx21, Tx22, and Tx23 into Batch M, organizes the hash values ​​of these transactions into Merkle trees to generate a Merkle Root, and fills the Tx_Root field in the Header of the generated Batch M with the hash value of this Merkle Root. It should be noted that when calculating the root of the Merkle tree, generally for values ​​less than 2... n In this case, the last transaction can be assigned multiple times to fill in the 2. n This allows us to calculate the root of the binary Merkle tree. For example... Figure 3 In the middle, Tx23, which is the last in chronological order, was repeated once to make up the 4 transactions, even though the number of transactions reached 2. 2 This allows us to calculate the root of the binary Merkle tree. Similarly, Sequencer sorts transactions by timestamp and packages Tx21, Tx22, and Tx23 into Batch M+1, which will not be elaborated further.

[0110] Before Batch M is executed, all states are as described above: Alice: 50, Bob: 100, Charlie: 150, David: 200. The Sequencer can organize these states into a Merkle tree and store the hash value of the root node of the Merkle tree in the Pre-State Root field of the Batch M Header. Then, the Sequencer can execute the three transactions Tx21, Tx22, and Tx23 in sequence. The result of executing these three transactions generates new states, as described above: Alice: 20, Bob: 110, Charlie: 170, David: 200. The Sequencer can organize these updated states into a Merkle tree and store the hash value of the root node of the Merkle tree in the Post-State Root field of the Batch M Header.

[0111] Furthermore, the Sequencer can send a transaction 1 calling the Rollup Contract to Layer 1 via the Relayer. This transaction 1 contains the fields from the Batch M Header and compressed Tx21, Tx22, and Tx23. The compression of Tx21, Tx22, and Tx23 significantly reduces their space requirements. 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 data (calldata). In Ethereum smart contracts, calldata is a special data location used to store input data from function calls. Specifically, calldata is typically stored directly within Ethereum's transaction data, usually saving more gas than other data locations (such as memory and storage).

[0112] Regarding compression, a simple Ethereum transaction (sending ETH) is approximately 110 bytes in size, while on Rollup, ETH transfers can be reduced to approximately 12 bytes with maximum compression in the current design. The table below shows the size of each field (parameter) in an Ethereum transaction compared to the size of each field in a Rollup transaction:

[0113] Nonce ～3 0 Gasprice ～8 0-0.5 Gas 3 0-0.5 To 21 4 Value ～9 ～3 Signature ～68(2+33+33) ～0.5 From 0 (Recover from signature) 4 Total ～112 ～12

[0114] Table 1

[0115] The implementation details of the compression are omitted here. It's worth noting that in an Ethereum transaction, the signature portion occupies about half the total size, and its From field can be 0 bytes because it can be recovered from the signature. However, in Rollup transactions, BLS aggregation can be used, compressing the signature of each transaction to approximately 0.5 bytes on average. Consequently, in Rollup transactions, since the From field cannot be recovered from this aggregated signature, it needs to be represented by a separate 4-byte signature.

[0116] In cryptography, public-key cryptography, also known as asymmetric cryptography, uses a pair of public and private keys (denoted as pk-sk, where pk represents the public key and sk represents the secret key), as opposed to cryptography that uses only a single private key. Public-key cryptography includes encryption algorithms and digital signature algorithms. Public-key-private key pairs are the cornerstone of modern cryptographic security, and many applications are based on pk-sk, such as application-layer encrypted transmission protocols like HTTPS (Hypertext Transfer Protocol Secure) and blockchain.

[0117] A private key typically represents the identity of the party possessing it. It can only be held by the owner and cannot be made public, while the corresponding public key can be shared. A signature using a private key indicates the owner's approval of certain information in the digital world. The signed information can also represent the owner's action within a protocol message. Generally, one owner possesses a single private key, which they can use to sign information and send it to other parties. Upon receiving the signature, the recipient can verify it using the corresponding public key. If the verification is successful, the recipient can confirm that the owner indeed signed the information and that the signed information has not been tampered with.

[0118] The BLS signature scheme was originally proposed in 2001 by Stanford University professor Dan Boneh and others, based on a bilinear mapping. Generally, a user's control over their own account is manifested in signing a transaction with their private key. A single signature, as shown in the table above, can reach 68 bytes, occupying a significant amount of space. For multiple transactions initiated by multiple accounts, each account needs to sign each of its own transactions separately. Signature aggregation can combine multiple signatures into a single signature, thus greatly saving byte space. This aggregation can be an aggregation of the same message signed by different signers, or an aggregation of signatures from different messages. Public key aggregation can combine multiple different public keys into a single master public key, which can then be used to verify the aggregated signature without requiring each public key to participate in the computation during the verification of the master signature. Signature aggregation is typically implemented using the Schnorr signature algorithm and the BLS signature algorithm. Compared to the Schnorr signature algorithm, the aggregated signature implemented by the BLS signature algorithm is smaller, approximately half the size of the Schnorr signature.

[0119] The compression scheme described above, along with the use of BLS for signature aggregation, represents an ideal design. However, in several practical Rollup schemes, a single compressed transaction still occupies 40-50 bytes of space, and this does not include the signature; in other words, BLS signature aggregation is not yet employed.

[0120] Following the previous text, after Layer 1 receives Transaction 1, which calls the Rollup Contract, it reaches a consensus, executes Transaction 1 on some nodes, and generates a block together with Transaction 1 and its execution result, along with other transactions and their execution results. Figure 3Block N in the Block N Header. Other transactions may include ordinary transfer transactions and transactions involving other smart contracts. Both ordinary transfer transactions and transactions involving other smart contracts involve transaction execution. Transactions involving other smart contracts, in particular, may involve more complex execution logic. Transaction 1 here, which calls the function in the RollupContract to store the calldata location, mainly involves storing the data in a specified location; it does not involve the execution of complex contract logic. In other words, the Rollup Contract in Layer 1 primarily stores the specified content from the transaction sent from Layer 2 into a specified location, without involving 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. Furthermore, as an implementation, the Pre-State Root and Post-State Root in the Batch MHeader of Transaction 1 can be stored in State 1 and State 2 of the contract state on Layer 1, respectively, using the Rollup Contract. As mentioned earlier, states 1 and 2 are contained in a state trie locked by the State_Root in Block NHeader, specifically, for example, a storage trie. For distinction, states 1 and 2 in the contract state on Layer 1 are referred to as the Last State root and Current State root, respectively. Furthermore, for simplicity, only the Current State root can be stored in the contract state on Layer 1, omitting the Last State root, as shown in the code example below. In other implementations, the Last State root and Current State root can also be stored in the calldata of Layer 1, just like transactions in Layer 2; this will not be elaborated upon here. For the former, for example, it involves calling the commitBatch() contract interface in Layer 1 as follows:

[0121] function CommitBatch(bytes[]calldata_transactions,bytes32_preStateRoot,bytes32_postStateRoot)

[0122] The CommitBatch() contract interface allows you to set basic validation 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 transaction on Layer 2 passed in from transaction 1 is stored in calldata, and the Current State Root in the contract storage is updated to the Post State Root. Example code is as follows:

[0123]

[0124] In this way, OP-Rollup can execute individual transactions in Layer 2 and bundle dozens, hundreds, or even more Layer 2 transactions into a single batch, publishing only the minimum amount of information to Layer 1. This minimum amount of information includes, as previously described, the compressed transactions on Layer 2 and the hash values ​​of the state roots before and after the execution of these transactions. As shown earlier, this can be sent, for example, through a transaction on Layer 1, such as... Figure 3 Transaction 1 in the example. This is equivalent to executing a batch of transactions on Layer 2 at once, but only one transaction on Layer 1. Furthermore, OP-Rollup does not come with any proof. This is based on the assumption that the submitted information on Layer 2 is free from fraud or malicious activity, hence the name "Optimistic." Despite this assumption, for prevention and deterrence, traders submitting Layer 2 information are still required to stake a portion of their assets on Layer 1 (typically on-chain native tokens, such as Ether on Ethereum) in the OP-Rollup Contract. Although OP-Rollup is optimistic, a challenge period can still be set on Layer 1, during which anyone can challenge it using proof of fraud. Typical reasons include the challenger proving that a transaction within the batch was not executed correctly, i.e., the execution of that transaction did not produce the correct state. If a transaction within a batch is proven invalid, the entire batch is invalid. The Rollup contract on Layer 1 can roll back the Layer 2 batch chain, rendering the invalid batch and all subsequent batches orphans. Once the fraud proof is successful, a portion of the deposit is paid to the challenger, and the remainder is destroyed. Conversely, if no one submits a fraud proof by the end of the challenge period, the Rollup contract can confirm the validity of that batch.

[0125] Fraud proof is a data validity verification method used in Optimistic Rollup schemes. Currently, fraud proof can be divided into two types: single-round interactive and multi-round interactive.

[0126] In one implementation of a single-round interactive fraud proof, the disputed transaction is replayed on Layer 1 to check for invalid states before submission. For example, Alice, as a validator, synchronizes the OP-Rollup compressed data to Layer 1 and pledges a deposit. If challenger Bob disputes the data, he must initiate a challenge during the challenge window and also pledge a deposit. The OP-Rollup's Rollup Contract will recalculate the transactions in the block on Layer 1 to determine right or wrong. The deposit of the incorrect party will be forfeited, and the correct party will receive a reward.

[0127] For example, the Sequencer on Layer 2 previously packaged and executed Tx21, Tx22, and Tx23, generating the Batch M header, which includes the Merkle root (Pre-StateRoot) and post-State root of the global state before and after executing Tx21, Tx22, and Tx23 in sequence, as well as others. The Sequencer can send a transaction 1 calling RollupContract to Layer 1 through the Relayer. This transaction 1, for example, calls the CommitBatch() contract interface of the Rollup Contract in Layer 1, which contains the fields in the Batch M header and the compressed Tx21, Tx22, and Tx23. Bob is a user on Layer 2, and it is assumed that he participated in some transactions in Batch M on Layer 2, such as the aforementioned Tx_21: Alice→Bob 20 and Tx_23: Bob→Charlie 10.

[0128] Suppose Bob believes that the state he receives after the Sequencer executes Tx_23 and transfers it to Charlie10 is incorrect. Bob can then initiate a challenge on Layer 1 during the challenge period of Batch M. As a user on Layer 2, Bob has access to all states before and after each batch execution, as well as all transactions within each batch—this is a prerequisite. Furthermore, Bob can challenge the Rollup Contract in Layer 1, for example, by calling the Challenge() contract interface. Through this Challenge() interface, Bob can send the challenge batch number (batchIndex), the transaction sequence number (txIndex), and proof. The proof can include the original text of all transactions in the challenge batch M (including the signature of each transaction; here, we take the compressed transactions stored in calldata without signatures as an example) and the global state before the execution of Batch M. Thus, when the Rollup Contract on Layer 1 executes, it can execute a verification function. The execution logic of this verification function includes, for example, the following:

[0129] 1. Verify that the signatures of all transaction transcripts in Bob's challenge are correct;

[0130] 2. In verifying Bob's challenge, the root hash of the Merkle tree formed by removing transaction signatures and compressing all original transactions is the same as the Tx_Root (i.e., the root hash of the Merkle tree formed by all transactions in Batch M) in the Batch MHeader sent by Sequencer through Relayer calling CommitBatch().

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

[0132] 4. If steps 1, 2, and 3 all pass verification, further simulate Layer 2 to execute all transactions in Batch M of Bob's challenge in sequence, generate the Post State Root after Batch M execution, and verify whether it is the same as the Post State Root sent by Sequencer through Relayer calling CommitBatch().

[0133] If the result of step 4 is different, it indicates that Sequencer has committed fraud, and a portion of the deposit can be paid to the challenger through a Rollup Contract.

[0134] It's important to note that while the calldata on Layer 1 contains all the compressed transactions from Layer 2, the fraud verification process doesn't directly extract and execute the compressed transactions from Batch M within the calldata. Instead, it simulates the execution of all transactions in the original text of Batch M provided by the challenger. This is because the compressed transactions in Batch M of the calldata are generally only used to reconstruct the execution process of all transactions on Layer 2 and the state of all accounts, thus eliminating security risks arising from data availability on Layer 2. Furthermore, the authenticity of the compressed transactions in Batch M of the calldata, without signatures, is uncertain, while the transactions provided by the challenger are complete and can verify their validity. Moreover, because the initial state cannot be verified—the contract storage only contains state roots, not the actual state—it would be uneconomical and inefficient to re-execute all transactions sequentially from Batch 0 until all states are obtained after Batch M-1 execution.

[0135] The aforementioned single-round interactive fraud proofs increase the amount of data that must be published on-chain and require re-execution of all transactions in Batch M on Layer 1. Furthermore, replaying these transactions incurs significant gas costs. Therefore, OP-Rollup is shifting towards multi-round interactive proofs to achieve the same goal more efficiently.

[0136] In multi-round interactive fraud proof, when Bob challenges the data synchronized by the Sequencer, the Sequencer needs to divide the disputed batch range into two equal parts, a pre- and post-partition range, and return the result via a contract interface such as `dispute()`. Bob then selects another bipartitioned range to continue the challenge, and the Sequencer further divides the disputed range into two equal parts... This process repeats until the disputed range is reduced to a specific transaction. Bob sends the original text of the challenged transaction (including the signature of each transaction) and the global state before the transaction's execution. The Sequencer sends the PreState Root (also called the state commitment) before the challenged transaction's execution and the PostState Root after execution, which are then calculated and judged by the Layer 1 RollupContract contract. Specifically, for example, a Rollup Contract verifies the global state before the execution of the challenge transaction based on the Pre-State Root. It then executes the challenge transaction based on this pre-state, generating the post-state. A Post-State Root is generated based on this post-state and compared to the Post-State Root sent by the Sequencer. If they differ, the challenge is successful; otherwise, it fails. In practice, Arbitrum does not use binary search but rather K-partitioning, dividing N instructions into N / K groups to search for fraudulent instructions, resulting in higher efficiency.

[0137] Therefore, compared to single-round interactions, multi-round interactions can resolve disputes at a lower cost. For example, the bipartite protocol can reduce the amount of data published on-chain (no need to publish state commits for every transaction), and it is also 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.

[0138] Overall, because the design of OP-Rollup requires all data related to state updates and verification to be placed on Layer 1, OP-Rollup has the most limited scalability and throughput improvement, and requires a waiting period of 7 days or even longer. This means that retrieving assets from OP-Rollup will be delayed, requiring waiting until the window period has passed.

[0139] ZK-Rollup differs from Optimistic Rollup because it uses zero-knowledge proof technology. ZK refers to the ability to prove something (a transaction or state) to another party without disclosing necessary information. Similar to OP-Rollup, ZK-Rollup packages Tx21, Tx22, and Tx23 into Batch M, organizes the hash values ​​of these transactions into a Merkle tree to generate a Merkle Root, and fills the Tx_Root in the header of the generated Batch M with the hash value of this Merkle Root. It also generates the Pre-State Root, Post-State Root, and Timestamp, which are then filled into the Batch M Header. Furthermore, Layer 2 will generate a proof (including a 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 by correctly executing the transactions in the batch in sequence based on the Pre State Root. This can be confirmed by verifying the proof, without having to re-execute the transactions in the batch to verify it.

[0140] Before generating proofs, a computational circuit can be created. This circuit is essentially a specific algorithm, pre-written to validate transaction and state logic. This pre-writing process includes a process called trusted setup, which also generates the Proving Key and Verifying Key. The created circuit can be set up within a proposer (or prover) on Layer 2. It's important to note that the circuit created for validating transaction and state logic is bound to its Proving Key and Verifying Key. Both the Proving Key and Verifying Key are publicly available and tied to the circuit.

[0141] The process of generating a proof can involve the Sequencer packaging all transactions (including sender, receiver, and amount) in a batch within Layer 2, along with information such as the Pre-State Root, Post-State Root, and Proving Key before and after the execution of these transactions, and sending it to a prover on Layer 2. The prover then 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 uses its internal zero-knowledge proof computation circuitry (a specific algorithm) to verify the validity and correctness of the public and private inputs. If the verification is correct, the circuit execution succeeds; otherwise, it fails. In the case of successful circuit execution, the prover outputs a proof that the packaged data is valid and correct. This proof is relatively small, typically only a few tens of bytes. This process of generating a proof is similar to a re-execution process and involves a large amount of circuit computation, making it more complex and generally time-consuming.

[0142] It's important to note that the private input cannot be derived from the proof itself. Only the party knowing the zk-SNARK's verification key can verify a proof encrypted with the corresponding creation key. 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.

[0143] Using zero-knowledge proofs, the prover can publish smaller proofs to Layer 1 via the Relayer, which can then be quickly verified by the Rollup Contract. The smaller proof size further reduces gas consumption on Layer 1. Moreover, in ZK-Rollups, this verification process is typically automated by the smart contract, without the need for a window period like in OP-Rollups, making asset withdrawals faster. This is one of the key differences between OP-Rollups and ZK-Rollups.

[0144] The specific verification process is as follows: First, the common input (which can be calculated from transaction 1 submitted in Block N, for example, by the automatic execution calculation logic in the Rollup Contract when transaction 1 is submitted to the Rollup Contract in Layer 1), the proof, and the verification key (the verification key can be stored in the governance contract on Layer 1 and provided to the Rollup Contract) are input into the verification logic in the smart contract (e.g., a verification algorithm including ZK-SNARK). The verification logic uses the verification algorithm to check if the proof is valid. If the proof is valid, then the packaged data corresponding to the common 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 common input is valid and correct; otherwise, the verification algorithm will output an error message indicating that the data is invalid or erroneous.

[0145] However, zero-knowledge proofs like ZK-SNARKs involve very high computational costs in generating proofs, meaning that proof generation is time-consuming. Assuming... Figure 4 As shown in the diagram, transaction 1 stores the compressed Tx21, Tx22, and Tx23 into the calldata field in Layer 1, and stores the Post State Root into the Current State Root field of the contract state on Layer 1. This transaction 1 is as follows: Figure 4 Located in Block N of Layer 1. The delay caused by the complex computation required to generate the corresponding proof in Layer 2 may occur over a period of time when the proof of Batch M is transferred to Block N+412 on Layer 1 via transaction 2. The transfer from Block N to Block N+412 obviously also introduces a certain delay, which may be close to an hour.

[0146] To address the issues of computational complexity and long proof generation times, current industry solutions primarily involve large-scale parallelization of proofs in engineering or acceleration through hardware optimization. However, this is not easy. Circuit implementation is relatively complex and lacks high-level language support, often requiring hand-written R1CS (a common form in circuits).

[0147] Furthermore, to utilize the ZK proof system and optimize circuit implementation, the entire Layer 2 state is often optimized into a circuit-friendly structure (Merkle tree). Therefore, ZK-kRollup systems need to consider the circuit structure, thus constraining Layer 2 transactions and account models. In ZK-Rollup, solutions such as zksync, StarkNet, and Scroll only implement specific transaction scenarios; achieving compatibility with the Ethereum Virtual Machine and Turing completeness is even more difficult, meaning it's hard to support more complex contracts.

[0148] The following is a comparison of the characteristics of OP-Rollup and ZK-Rollup, two Rollup schemes in Layer 2:

[0149] Proof Type Fraud Proof Valid proof On-chain computational complexity high Low TPS 100 (500 can be achieved with BLS signature) 2000 Off-chain computation complexity Low (as long as it can run EVM) Very high Turing complete It can be achieved Difficult to achieve Fund withdrawal time One to two weeks hourly

[0150] Table 2

[0151] This application discloses a method for implementing two-layer network convolution, the architecture on which Layer 2 depends is as follows: Figure 5 As shown. This includes at least Relayer, TxPool, Sequencer, and Prover. As mentioned earlier, the main function of Relayer is to submit transactions or operations on Layer 2 to Layer 1, acting as a bridge between Layer 1 and Layer 2. This can include submitting user transactions from Layer 2 packaged by Sequencer to Layer 1, and submitting proofs generated by Prover on Layer 2 to Layer 1. Alternatively, Relayer can be omitted, with Sequencer submitting packaged user transactions from Layer 2 to Layer 1, and Prover submitting the generated proofs to Layer 1. In fact, the latter integrates the functionality of Relayer into Sequencer and Prover. For simplicity, the role of Relayer in the overall scheme will not be emphasized further.

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

[0153] The Sequencer pulls transactions from the TxPool, sorts and packages these transactions according to their timestamps, organizes their hash values ​​into a Merkle tree to generate a Merkle Root, and then fills the Tx_Root in the Header of the generated Batch M with the hash value of the Merkle Root. For example... Figure 4As shown, Tx21, Tx22, and Tx23 are packaged into Batch M. Tx23, ordered chronologically, is repeated once to complete the four transactions, thus calculating the root of a binary Merkle tree. Furthermore, the Sequencer executes these three transactions sequentially based on the state before execution in Batch M. The result of executing these three transactions generates a new state. The Sequencer organizes the state before execution into a Merkle tree and stores the hash value of the root node in the PreState Root field of the Batch M Header. It also organizes the state after execution in Batch M into a Merkle tree and stores the hash value of the root node in the PostState Root field of the Batch M Header.

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

[0155] TEE (Trusted Execution Environment) is a secure extension of CPU hardware, completely isolated from the external environment. Currently, the industry is paying close attention to TEE solutions, with almost all mainstream chip and software alliances having their own TEE solutions. Examples include software-based TPM (Trusted Platform Module) and hardware-based solutions such as Intel SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor). TEE acts as a black box; code and data executed within it cannot be viewed even at the operating system level, and can only be manipulated through predefined interfaces in the code. In terms of efficiency, due to the black-box nature of TEE, computations are performed on plaintext data, rather than the complex cryptographic operations of homomorphic encryption, resulting in almost no loss of efficiency. Therefore, adopting TEE technology can largely meet the trusted computing requirements of blockchain scenarios with relatively small performance losses.

[0156] This application discloses a method for implementing two-layer network convolution, comprising the following:

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

[0158] S120: The sorter 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.

[0159] Similar to the above, Rollup Contracts can be deployed on Layer 1 in Rollup. In Layer 2, the transaction pool TxPool can receive initiated Layer 2 transactions. Suppose TxPool collects Layer 2 transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24.

[0160] Sequencer can pull transactions from the transaction pool, sort them according to their timestamps, and then package them together. For example... Figure 4 As shown, Tx21, Tx22, and Tx23 are sorted and packaged into Batch M. The hash values ​​of these transactions are then organized into a Merkle tree to generate a Merkle Root. The hash value of this Merkle Root is then filled into the Tx_Root field in the Header of the generated Batch M. This Merkle Root is the first transaction root of Batch M.

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

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

[0163] These states can be considered the initial states before the packaged transaction is executed.

[0164] The Sequencer can organize all the state values ​​of the transactions in Batch M before execution into a Merkle tree and obtain the Merkle root, i.e., the first pre-state root. It can also lock the Merkle root obtained by organizing all the state values ​​of the transactions in Batch M into a Merkle tree in the head of Batch M. Figure 4 The Pre-State Root in the context.

[0165] A Sequencer can execute packaged transactions sequentially based on an initial state, thus generating a post-execution state, for example:

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

[0167] The Sequencer can organize all the states obtained after executing the transactions in Batch M in sequence into a Merkle tree and obtain the Merkle root, which is the first post-state root. It can also lock the Merkle root obtained by organizing the hashes of all state values ​​of the transactions in Batch 1 after executing them in sequence into the header of the Batch, which is the Post-State Root.

[0168] Furthermore, the sorter can send the packaged Layer2 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 Layer 2 network.

[0169] Furthermore, in S110 or S120, the Sequencer can (or via the Relayer) send a transaction 1 (the first mainnet transaction) calling the RollupContract to Layer1. This transaction 1 contains the fields from the Batch M Header and compressed Tx21, Tx22, and Tx23. The compression of Tx21, Tx22, and Tx23 significantly reduces their space requirements. 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 from function calls. Specifically, calldata is typically stored within Ethereum's transaction data; this data cannot be modified after Ethereum blocks are formed (i.e., it is read-only) and is generally more gas-efficient than other data locations (such as memory and storage).

[0170] 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). The Sequencer can (or through the Relayer; the Sequencer / Relayer can initiate a transaction on the blockchain to call a Rollup Contract on the mainnet, triggering the contract's execution. The transaction content includes fields such as `from`, `to`, `value`, and `data`. The `from` field can be the account address of the transaction initiator (the Sequencer / Relayer's external mainnet account address), the `to` field can represent the address of the smart contract being called, the `value` field can be a native token on the blockchain (such as 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 to be called in the `to` field, it indicates that a call is being made to a specific smart contract on the blockchain. A smart contract typically includes one or more functions, each of which can include some input parameters. The `data` field in the transaction specifies the function in the smart contract to be called and contains the required parameters. As mentioned earlier, the `data` field can specify the call to the `commitBatch()` contract interface. Thus, during the normal execution of the Rollup Contract, the compressed Tx21, Tx22, and Tx23 from the first mainnet transaction (Transaction 1) can be stored in `calldata`, and the `CurrentState Root` in the contract storage can be updated to `PostState Root` with the passed parameters. Further details are omitted.

[0171] The outcome of contract execution can alter the contract's storage, i.e., its world state. Furthermore, the transaction's execution result or related information can be recorded in a blockchain receipt. Specifically, the contract execution result / related information can be represented as events within the receipt. An event's structure might look like this:

[0172] Event:

[0173] [topic][msg]

[0174] [topic][msg] ......

[0176] In the example above, there can be one or more events. 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 upon detecting events on a specific topic, retrieve the content of the corresponding message, and perform preset processing after listening for certain content from a specific topic or the corresponding message.

[0177] In this event mechanism, blockchain nodes on the mainnet can store the execution results in the msg corresponding to a certain topic. Sequencer / Relayer can then listen to that topic through its built-in blockchain client and obtain the corresponding execution results. For example, the first mainnet transaction has been successfully executed on the mainnet Rollup Contract.

[0178] After the Rollup Contract on the mainnet is executed, it can generate events for a specific topic. Once the Prover / Relayer listens to the corresponding topic, it can confirm that the transaction that previously called the mainnet Rollup Contract has been executed on the mainnet. Thus, the Prover can execute step S130 below. In this way, the Prover can confirm the execution result of the blockchain nodes on the mainnet by listening to specific events, and then perform the verification in S130. This avoids the possibility that the first mainnet transaction might not have been executed on the mainnet for some reason, such as the first mainnet transaction failing to be sent successfully, or the mainnet Rollup Contract failing to verify the first mainnet transaction itself. Alternatively, S130 can be executed directly after S120.

[0179] S130: The prover verifies the first transaction root and the first pre-state root; after both verifications are passed, the packaged transactions are executed sequentially based on the initial state to generate the 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 to the blockchain ledger of the mainnet through the second mainnet transaction as proof.

[0180] The prover verifies the first transaction root by generating a second transaction root for the packaged transactions and verifying whether the first transaction root is equal to the second transaction root. Specifically, the prover can organize the hash values ​​of the packaged transactions Tx21, Tx22, and Tx23 into a Merkle tree to generate a Merkle Root, that is, organize the hash values ​​of these transactions into a Merkle tree in the same way as the Sequencer to generate a Merkle Root, which is the second transaction root. In this way, the prover can verify whether the second transaction root is equal to the first transaction root sent by the Sequencer.

[0181] The prover verifies the first pre-state root by generating a second pre-state root for the initial state and verifying whether the second pre-state root is equal to the first state root. Specifically, the prover can 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 pre-state root. In this way, the prover can verify whether the second pre-state root is equal to the first pre-state root sent by the Sequencer.

[0182] 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.

[0183] The prover can execute the packaged transactions sequentially based on the initial state sent by the Sequencer, generating updated states and organizing these updated states into a Merkle tree to obtain the hash value of the root node of the Merkle tree of the updated states, i.e., 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 execution process of the Sequencer is correct, because starting from the same initial state, the execution result of the Sequencer executing the packaged transactions sequentially is the same as the execution result of the prover independently executing the same packaged transactions sequentially.

[0184] Thus, the prover verification can sign the information of the packaged transaction. Specifically, the prover verification can sign at least one of the following: the batch number of the packaged transaction, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction. Signing at least one of these contents indicates that the prover acknowledges the result produced by the Sequencer executing this batch.

[0185] As mentioned earlier, a private key typically represents the identity of the party possessing it. It can only be held by the owner of the private key and cannot be made public, while the corresponding public key can be published. A signature using the private key represents the owner's approval of certain information in the digital world. The signed information can also represent a certain action of the private key owner in the protocol message. Generally, one owner possesses a single private key, which can be used to sign information and send it to other parties. Upon receiving the signature, the recipient can verify it using the corresponding public key. If the verification is successful, the recipient can confirm that the owner did indeed sign the information and that the signed information has not been tampered with.

[0186] The prover can be implemented using a TEE (Trusted Execution Environment). A TEE has a trusted execution environment that is completely isolated from the outside world, thus allowing it to hold its private key confidentially. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the packaged transaction information using its own private key to indicate its acceptance of the signed content.

[0187] TEE technologies include Intel SGX (Intel Software Guard Extension, hereinafter referred to as SGX) and AMD SEV. The following explanation uses SGX technology as an example. In Layer 2, the Prover can create Enclaves (enclaves or enclaves) based on SGX technology to serve as the TEE for verification. The Prover can utilize new processor instructions in the CPU to allocate a region in memory called EPC (Enclave Page Cache) to house the aforementioned Enclaves. The memory region corresponding to the EPC is encrypted by the CPU's internal Memory Encryption Engine (MEE). The contents of this memory region (code and data in the Enclave) can only be decrypted within the CPU core, and the encryption / decryption keys are generated and stored in the CPU only when the EPC is started. As can be seen, the security boundary of an enclave only includes itself and the CPU. Neither privileged nor non-privileged software can access the enclave. Even operating system administrators and VMMs (Virtual Machine Monitors, or Hypervisors) cannot affect the code and data within the enclave, thus providing extremely high security. Given this security guarantee, the CPU can process data within the enclave with extremely high computational efficiency, thereby balancing data security and computational efficiency.

[0188] Intel began supporting SGX with its sixth-generation CPUs. Furthermore, before shipping these SGX-enabled CPUs, the manufacturer programs a provisioning key and a sealing key into the CPU's fuse register. The fuse register is a one-time programmable register; once data is programmed into it, the fuse blows, making the register read-only. Intel promises that the keys programmed into the fuse register are randomly generated; moreover, it promises that all backups of the programmed key are destroyed after programming, meaning even Intel itself is unaware of the programmed key. The provisioning key can represent partial information about the CPU, such as the CPU's codename (e.g., sixth-generation Core, seventh-generation Core), model (e.g., desktop, mobile). For security reasons, operations such as encryption and signing 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.

[0189] User Enclaves can be created based on user instructions to execute user-specified program code (such as loading transaction execution code from a TEE, including virtual machines and smart contracts). However, due to the isolation characteristics of these Enclaves, user-created Enclaves often need to prove their trustworthiness to external parties. This involves Enclave authentication, such as local authentication and remote authentication, as described below.

[0190] Before initiating remote authentication, the CPU can check if an attestation key exists. If not, it initiates initialization. The initialization process can be based on a key generation protocol, interacting with the Intel server (specifically, the Provisioning Enclave in SGX, an architecture-level enclave), and generating an EID (Enhanced Privacy IDentification) according to the Provisioning Key generation rules. This EID serves as the attestation key and is generally used as the private key in asymmetric encryption. The generated EID can be stored in an enclave for subsequent signing; this enclave is generally called the Quoting Enclave. Alternatively, the EID can be stored in the CPU's registers. Only architecture-level enclaves have permission to access the CPU, so the Quoting Enclave can also obtain the EID from the CPU's registers. As mentioned above, during EID generation, SGX (specifically, the Provisioning Enclave mentioned above) can interact with the Intel server, allowing Intel to obtain the public key corresponding to the EID through this interaction. Importantly, the public key corresponding to the EID is not publicly disclosed; it is only kept by the Intel server. This feature makes it suitable for subsequent remote authentication processes to be performed by Intel's servers (also known as IAS, or Intel Attestation Server).

[0191] The application developer (or issuer, hereinafter referred to as the issuer) can sign the code / data to be loaded into the Enclave (e.g., transaction execution code in the TEE, including virtual machines and smart contracts) with the developer's private key and then transmit it to SGX through the application. Additionally, the issuer's public key can be transmitted to SGX (or the issuer's certificate can be uploaded, which includes information signed by the issuer, including the issuer's public key; this information may also include the hash value of the code / data to be loaded into the Enclave, which can be used by SGX to verify the integrity of the loaded code / data). During the execution of the application, it can request the creation of an Enclave from SGX through the instruction set integrated in the CPU. This Enclave is generally called the Application Enclave (equivalent to the User Enclave mentioned above). When creating the Application Enclave, SGX needs to perform page allocation, copy program code / data, and measurement operations. Specifically, the metric can be the hash value of the code / data loaded onto each page by the CPU. After loading is complete, the hash value of the Application Enclave containing the loaded code / data is obtained. This hash value is generally called the MREnclave, and the hash algorithm typically uses SHA256. The MREnclave can be stored in a structure called SECS (SGX enclave control structure). SECS resides in an EPC page of the enclave and is used to record the enclave's metadata. This metadata includes sensitive information such as the enclave cryptographic measure (i.e., the MREnclave), therefore this structure can only be accessed and modified by the CPU's SGX management mechanism.

[0192] Based on the characteristics of hash algorithms, any one of the following three events—code / data tampering, allocation of redundant pages, or copying in malicious code—even with only a slight alteration, will lead to significant differences in the MREnclave's value; different Application Enclaves will also have different MREnclave values. Based on this property, the MREnclave can both identify the Enclave and be used for integrity verification of the Application Enclave. Through measurement operations, the integrity of the Application Enclave can be verified using the hash value contained in the certificate (the hash value contained in the certificate follows the same generation rules as the MREnclave, so it should normally be consistent), to determine whether privileged software tampered with the program / data during the creation process, such as allocating redundant pages, copying in malicious code, or modifying copied data.

[0193] Specifically, when creating an Application Enclave, SGX can use an initialization command to compare the aforementioned MRRenclave with the hash value in the certificate signed by the Application Enclave issuer. If they match, it means the code / data loaded into the Application Enclave is consistent with expectations, i.e., it is the issuer's code / data; otherwise, if they do not match, it indicates a problem in the creation process, and a failure result is returned. If they match, SGX will also hash 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.

[0194] Thus, the SECS structure is equivalent to the identity of an Enclave in a certain sense. It simultaneously possesses the identities of two Enclaves: MREnclave is the measure of an Enclave, and MRSigner is the measure of an issuer.

[0195] The content within the Application Enclave needs remote authentication to prove it is a trusted Enclave created within a legitimate SGX. As mentioned earlier, the content of the Application Enclave needs to be remotely authenticated after being signed by the EPID in the Quoting Enclave, which requires interaction between the Application Enclave and the Quoting Enclave. Before this, the Application Enclave needs to prove to the Quoting Enclave that it is an Enclave on the same SGX and is trustworthy. The process by which the Application Enclave proves to the Quoting Enclave that it is an Enclave on the same SGX is called local authentication.

[0196] The local authentication process can employ a Message Authentication Code (MAC) algorithm. The Application Enclave can obtain the Quoting Enclave's MREnclave and generate a signed report structure. Specifically, the Application Enclave can invoke the EREPORT instruction provided by the CPU. The CPU can use a root key combined with the Quoting Enclave's MREnclave obtained by the Application Enclave to generate a symmetric key—the REPORT Key. Simultaneously, by invoking the EREPORT instruction, the identity information and attributes of the Application Enclave, as well as the platform hardware TCB information, can be obtained and used as the content of the Report. Furthermore, the Report can also include data that the user wishes to interact with. Invoking the EREPORT instruction will also use a MAC algorithm to calculate a first MAC code from the REPORT Key and the aforementioned Report. This first MAC code can be used as the Report's signature for integrity verification. The ApplicationEnclave invokes the CPU's EREPORT instruction, allowing the CPU to directly obtain the Application Enclave's identity and attributes, as well as platform hardware TCB information. This ensures that the Application Enclave cannot interfere with or tamper with this information. Furthermore, the CPU generates a REPORT Key using the root key and the Quoting Enclave's MREnclave. This process is also performed internally by the CPU; even the Application Enclave will not know the root key, thus preventing its leakage. After receiving the Report and the first MAC code, the Quoting Enclave can invoke the CPU's EGETKEY instruction, using its own MREnclave as input. 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 a second MAC code from the obtained REPORT Key and the received Report. 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 by combining the same CPU root key with the EREPOR and EGETKEY instructions provided by the CPU, the Quoting Enclave can confirm that the Application Enclave is an Enclave on the same SGX after the MAC code verification is successful.

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

[0198] In remote authentication, a challenger can first challenge the Application Enclave, demanding that it prove itself as a legitimate enclave and that a trusted program runs within it. Upon receiving the challenge, the Application Enclave generates a report, typically called a Quote. This Quote report may include the hash value of the code / data loaded within the Application Enclave (i.e., the aforementioned MREnclave) and the aforementioned MRSigner. After passing the aforementioned local proof, the content of the Quote can be signed by the Quoting Enclave using an EPID, for example, denoted as Signature1. This signature can be a signature made by the Quoting Enclave using the EPID on the MREnclave, or a signature made on both the MREnclave and the 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, they 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 the IAS for signature verification. After receiving the Quote, IAS can verify the correctness of the signature in the Quote using the public key corresponding to the EPD and return an Attestation Verification Report (AVR). The AVR report can include the Quote itself and the verification result of the signature in the Quote, such as whether the signature verification is correct or incorrect. IAS can sign the content of the AVR report using Intel's private key and attach this signature (e.g., denoted as Signature2) and the certificate to the AVR report, then return the AVR report to the challenger. Upon receiving the AVR report, the challenger can verify Intel's signature using the public key in the certificate (corresponding to Intel's private key). Alternatively, the AVR report may not include the certificate; instead, the challenger can download Intel's certificate (available for download on Intel's official website or other authoritative websites) and verify Signature2 using the public key in the downloaded certificate. Verification of Signature2 confirms that the AVR report was indeed issued by Intel and is complete. The verification result of the signature in the Quote included in the AVR report proves whether the SGX represented by the Quote report is legitimate after verification by IAS.Furthermore, challengers can verify the MREnclave and MRSigner in the Quote. For example, challengers can obtain the MREnclave of the code / data loaded into the SGX and the issuer's MRSigner from the issuer in advance, 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.

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

[0200] Furthermore, 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 process described above, and will not be repeated here. Moreover, the TEE can hash and sign the input code / data, thus using its own trustworthiness to guarantee that the executed input is also trustworthy; the TEE can also sign the hash value of the output (i.e., the execution result), again using its own trustworthiness to guarantee that the executed input is also trustworthy.

[0201] In this way, the prover verifies the information signature of the packaged transactions after independently executing (or replaying) the packaged transactions in sequence based on the initial state. This means the prover uses its own credibility to guarantee the credibility of the output result. Furthermore, the prover can send the signature as proof to the mainnet's blockchain ledger via a second mainnet transaction. Anyone who questions the signature can verify it by challenging the TEE in the prover. This process, as described above, also requires interaction with the IAS, thereby confirming from the report returned by the IAS that the TEE and the code / data loaded within it are credible. Based on trust in the TEE, the prover is certain that the transaction information it signs is credible.

[0202] It's important to note that once remote authentication is successful, the CPU can process data within the Enclave via the TEE mechanism, achieving extremely high computational efficiency and thus balancing data security and computational efficiency. This is significantly faster than ZK-Rollup, which, under the same conditions, requires 30-50 minutes (or even hours) to generate a proof. Figure 4The time from Block N to Block N+412 has been reduced to the order of 5-10 minutes. Figure 5 In the case of Block N to Block N+62, and even without using the listening mode, but instead executing S130 directly after S120, the time will be reduced to even less. Furthermore, the generated proof is the size of a signature, approximately tens of bytes, similar to ZK-Rollup.

[0203] Signature verification is the process of verifying the signature using the TEE's public key. As long as the public key is trustworthy, this verification will be reliable and fast. The prover can send the signature as proof to the mainnet's blockchain ledger via a second mainnet transaction. This includes the prover sending the signature as proof to the mainnet via a second mainnet transaction and invoking a rollup contract on the mainnet. After receiving the transaction, the rollup contract verifies the correctness of the signature through its verification logic.

[0204] The above scheme is also known as the EPID scheme. In the EPID scheme, each challenge requires the challenger and TEE to communicate with the remote IAS, which can lead to significant latency, and many running entities may even be unable to access Intel services at runtime. Therefore, the improved SGX DCAP authentication protocol provides IAS localization. For example, some cloud service platforms and data centers localize the IAS on the management machine, which is also called a localized verification service. SGX DCAP provides trust through a certificate chain, with the only root of trust being the Intel SGX Root CA.

[0205] Intel SGX DCAP, short for 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-level security by creating a secure zone called an "enclave." Data and code within this zone are hardware-encrypted and protected, preventing theft or tampering even if the operating system, virtual machine manager, or BIOS is compromised. In Intel SGX, "attestation" is a mechanism 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 verification process requires Intel's Remote Authentication Service (IAS). However, in data center environments, a large number of verification operations may be required. Therefore, Intel introduced DCAP, which allows data centers to host the verification service themselves. DCAP decouples the verification process from Intel's services, enabling data centers to perform verification locally, thereby improving efficiency, enhancing controllability, and reducing reliance on Intel services. In simple terms, SGX DCAP is a solution that uses SGX technology in a data center environment, providing a more efficient and controllable verification mechanism.

[0206] The data center's Verify Service obtains a certificate from Intel IAS, which typically has an expiration date. Within this period, deployed SGX instances can generate remote reports by interacting with the local Verify Service (which acts as a local IAS) without directly interacting with Intel. After the expiration date, the data center's Verify Service needs to obtain a new certificate from Intel IAS. The certificate generally includes the Verify Service's public key signed by Intel, providing a verification of Intel's signature using Intel's public key to ensure the trustworthiness of the Verify Service's public key in the certificate. The Verify Service can sign other content using its own private key and provide a verification of Intel's signature using its public key to ensure the trustworthiness of its public key in the certificate. Additionally, the certificate may include an expiration date, the purpose of which is as described above.

[0207] In a simplified overview, the process of implementing the SGX DCAP authentication protocol can include the following (see the above for details):

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

[0209] Then, the TEE in the prover submits the public key along with some information about the User Enclave (such as its metric) to the local Quoting Enclave (QE) to request the generation of a proof report. The QE signs this information and packages the signature and other information into the proof report.

[0210] Next, the TEE in the proof provider submits this proof report to the Verify Service. This service verifies the validity of the report and signs the public key contained within it, generating a certificate. This certificate contains the Verify Service's signature on the TEE in the proof provider, and may also include other content. Similar to the aforementioned remote authentication report, it can therefore be considered a remote authentication report generated by the Verify Service.

[0211] Finally, the generated certificate is returned to the prover's TEE. Subsequent provers can then sign the execution result using their own private key and provide the certificate. This allows others to verify the signature using the public key in the certificate to ensure the execution result is trustworthy. This certificate is issued by the authentication service, meaning it is guaranteed by the authentication service using its own private key for signing. The trustworthiness of this certificate can be further guaranteed by certificates issued by Intel IAS for the authentication service. This trust transfer relationship between multiple certificates and signatures constitutes the certificate chain principle.

[0212] In summary, the prover can send the certificate to the mainnet's blockchain ledger via a second mainnet transaction. In a typical approach, the prover can send the certificate along with its signature to the mainnet's blockchain ledger via a second mainnet transaction. When using the EPID scheme described above, the certificate includes a remote authentication report generated by IAS for the prover, allowing verifiers to verify the validity of the prover's signature on transaction information. When using the DCAP scheme described above, the certificate can include a certificate issued by the authentication service for the prover. Based on trust in the authentication service, this can be extended to the certificate issued by the authentication service for the prover, allowing verifiers to verify the prover's signature using the public key in that certificate. For higher levels of trust, in addition to the certificate issued by the authentication service for the prover, a remote authentication report generated by IAS for the authentication service may also be required. This ensures the credibility of the authentication service's signature through authoritative Intel authentication (i.e., the remote authentication report, equivalent to a certificate issued by Intel for the authentication service), and the certificate issued by the authentication service for the prover further propagates trust downwards, thus guaranteeing the credibility of the prover's signature. This is how SGX DCAP provides trust through a certificate chain.

[0213] The verification logic executed by the aforementioned verifier can be built into the Rollup Contract and provided externally as a contract interface, such as a verification interface. In this way, the prover sends the signature as proof to the mainnet via a second mainnet transaction. Specifically, this could be a blockchain ledger invoked in the transaction. This includes the prover sending the signature as proof to the mainnet via the second mainnet transaction and invoking the verification interface of the Rollup Contract on the mainnet, through which the signature can be passed in. The verification interface can then execute verification logic, specifically verifying the legality of the signature. The process of verifying the signature's legality mainly involves verifying the signature's legality using the prover's public key.

[0214] Furthermore, the certificate of the prover corresponding to the signature can also be transmitted via the verification interface through the second mainnet transaction. This certificate may include the prover's public key. Thus, in addition to verifying the signature's legitimacy using the prover's public key, the verification can also include verifying the legitimacy of the prover's certificate. As mentioned above, the certificate may include a remote authentication report generated by IAS for the prover, or a certificate issued by an authentication service for the prover (which may also include a remote authentication report generated by IAS for the authentication service). Correspondingly, verifying the certificate may include verifying the legitimacy of the prover certificate using Intel's authoritative public key, or it may include verifying the legitimacy of the authentication service's certificate using Intel's authoritative public key and verifying the prover certificate's legitimacy using the public key in the authentication service's certificate.

[0215] As mentioned above, using TEE as a proof-maker on the Layer 2 network can result in lower latency because the replay and verification of transactions in TEE is close to the speed of native execution.

[0216] The above Figure 4 The example given is a case where there are four global states on Layer 2, namely Alice, Bob, Charlie, and David. In reality, a batch on Layer 2 may contain hundreds or even thousands of transactions, which may involve even more states, such as tens of thousands. If the transactions in Layer 2 include transactions involving contracts on Layer 2, then a single contract may involve even more states, resulting in an even larger number of states in Layer 2 overall, such as tens of thousands. Thus, in S120, the sorter sends the initial states of all states to the prover in the Layer 2 network, resulting in a large amount of data.

[0217] Therefore, this application provides a method for implementing two-layer network convolution, comprising the following:

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

[0219] The specific process of S210 is similar to that of S110 mentioned above, and will not be repeated here.

[0220] S220: The sorter sends the packaged transactions, the first transaction root, the SPV proof of the pre-read set of the packaged transactions, and the first pre-state root and the first post-state root to the prover of the second-layer network.

[0221] For the sake of illustration, let's assume... Figure 6 As shown, transactions in Layer 2 (including ordinary transfer transactions and transactions involving contracts) involve a total of 8 states, such as... Figure 6The bottom left corner shows the states corresponding to the eight hash values ​​8, 9, 10, 11, 12, 13, 14, and 15. Assume that the transactions packaged in Batch M, when executed sequentially, only affect the states corresponding to Alice and Bob (hash values ​​8 and 9), not the states corresponding to the six hash values ​​10, 11, 12, 13, 14, and 15. As shown in the diagram, after the transactions packaged in Batch M are executed sequentially, only the balances of Alice and Bob change; the balances of Charlie and David remain unchanged (that is, the hash values ​​of tree nodes 10 and 11 do not change; the content corresponding to nodes 10 and 11 is shown here; the content corresponding to nodes 12, 13, 14, and 15 also does not change, but is omitted here).

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

[0223] like Figure 6 In the example, the sorter can send the states corresponding to tree nodes 8 and 9, along with the SPV proof consisting of the hash values ​​of node 5 and node 3, to the prover in 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.

[0224] SPV, originating from the concept of Bitcoin, stands for Simplified Payment Verification. SPV proofs utilize Merkle trees. Here, the states involved in Batch M form a Merkle tree, with the root (the Merkle root) contained in the header of Batch M. The structure of the Merkle tree allows verification of the existence of any state under a specific Merkle root via a very short path (the Merkle path). This path only contains the necessary nodes, not the state contents corresponding to all leaf nodes.

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

[0226] The Merkel path in SPV proofs refers to a tree-like data structure, which can be a Merkel tree in Bitcoin, an MPT tree in Ethereum, or SMT, etc.

[0227] MPT stands for Merkle Patricia Tree, a tree structure combining Merkle Tree and Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each transaction pairwise and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal tree structure, often simply referred to as an MPT tree. Taking the Ethereum state trie as an example, the state tree contains key-value pairs (also written as key-value, or kv) representing the storage content corresponding to each account in the Ethereum network. The "key" in the state tree can be a 160-bit identifier (such as the address of an Ethereum account or part of the hash value of that address, hereinafter referred to as the account address), and this account address is distributed across the storage from the root node to the leaf node of the state tree. The "values" in the state tree are generated by encoding information from Ethereum accounts (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.

[0228] As mentioned earlier, `state_root` is the hash value of the root of the MPT tree composed of the states of all accounts in the current block. In other words, a state trie in MPT form points to `state_root`. The root node of this MPT tree is typically an extension node or a branch node, and `state_root` generally stores the hash value of this root node. Figure 7As shown, the root node can be connected to one or more Extension Nodes / Branch Nodes below it. These multi-level tree nodes can be collectively referred to as Internal Nodes. A portion of the values ​​from each node in this MPT, from the root node to the leaf node, can be concatenated sequentially to form an account address 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. This key can also be a portion of the SHA3 hash of the address (using a hash algorithm such as SHA3), and its stored value can be an RLP (Account) encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, for external accounts, generally only nonce and balance are present, while the storageRoot and codeHash fields default to storing empty strings / strings of all zeros. That is, external accounts do not store contracts or state variables generated after contract execution. Contract accounts generally include Nonce, Balance, Storage Root, and CodeHash. Nonce is the transaction counter for this contract account;

[0229] Balance represents the account balance; Storage root corresponds to another MPT, through which information related to the contract's state can be linked; CodeHash is the hash value of the contract code. Whether it's an external account or a contract account, its account information is generally located in a single leaf node. From the root node's Extension Node / Branch Node to each account's Leaf Node, there may be several branch nodes and extension nodes along the way.

[0230] The state trie can be an MPT-style tree, typically a 16-ary tree, meaning each level can have a maximum of 16 child nodes. An Extension Node, used to store a common prefix, typically has one child node, which can be a Branch Node. A Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes.

[0231] For a contract account within the state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to the contract's execution state variables. This `storage_root` points to an MPT-form tree called the Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. The key represents the address of the state variable, and its value can be the result of processing the state variable's declaration position (counting from 0) according to certain rules, such as SHA3(state variable declaration position) or SHA3(contract name + state variable declaration position). The value stores the state variable's value (e.g., an RLP-encoded value). A portion of the data stored along the path from the root node through intermediate nodes to the leaf node forms the key, and the leaf node stores the value. As mentioned earlier, this Storage trie can also be an MPT-type tree, typically a 16-ary tree. This means that a Branch Node can have a maximum of 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. An Extension Node typically has one child node, which can be either a Branch Node or a Leaf Node.

[0232] For example Figure 7 The Leaf Node Account P in the state trie is a contract account whose Storage Root locks all the states stored in that contract. These states are organized as an MPT tree, with a tree structure like the Storage trie linked by the Storage Root. In this linked Storage trie, taking Leaf Node StateVariable N as an example, if it is the value of storedData from the aforementioned contract code example, then its key is sha3 (the declaration location of storedData, which will be detailed later), and its value is s (for simplicity, the encoding format of the value is omitted here, such as RLP, and similarly, will not be elaborated further). The key values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0233] For example, Figure 7In the state Trie, Leaf Node Account C is an external account. Its key is sha3(Address C), which is the hash value of the address of account C (using a hash algorithm such as sha3). Its stored value can be (Account), where the account information Account is a tuple of [nonce, balance]. As mentioned earlier, since Account C is an external account, its account information consists of nonce and balance (codehash and storage root are omitted here, but similarly below). For example, for an external account with a nonce of 20 and a balance of 4550, the leaf node State Variable C will store 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.

[0234] These states, including the key-value pairs of external accounts and contract accounts, are ultimately stored in the database. However, the database does not directly store the states of these accounts (i.e., it does not directly store their key-value pairs), but rather stores the key-value values ​​of each tree node itself.

[0235] like Figure 8As shown in the example, in the upper-level MPT structure, for leaf node A1, the key of the leaf node is formed by sequentially combining a7 of the shared nibble in the root node A8 (Extension Node), slot 1 of the intermediate node A7 (Branch Node), and key-end 1335 in leaf node A1, which is a711335. Balance = 45.0ETH and Nonce = n1 are stored in this leaf node. For leaf node A2, the key of the leaf node is formed by sequentially combining a7 of the shared nibble in the root node A8 (Extension Node), slot 7 of the intermediate node A7 (Branch Node), d3 of the shared nibbles in node A6 (Extension Node), slot 3 of the intermediate node A5 (Branch Node), and key-end 7 in leaf node A2, which is a77d337. Balance = 1.00ETH and Nonce = n2 are stored in this leaf node. For leaf node A3, the key of this leaf node is formed by sequentially combining a7 from the shared nibble in root node A8 (Extension Node), slot f from intermediate node A7 (Branch Node), and key-end 9365 in leaf node A3, resulting in a7f9365. This leaf node stores Balance = 1.1 ETH and Nonce = n3. For leaf node A4, the key of this leaf node is formed by sequentially combining a7 from the shared nibble in root node A8 (Extension Node), slot 7 from intermediate node A7 (Branch Node), slot d3 from the shared nibbles in node A6 (Extension Node), slot 9 from intermediate node A5 (Branch Node), and key-end 7 in leaf node A4, resulting in a77d397. This leaf node stores Balance = 0.12 ETH, Nonce = n4, CodeHash = c1, and Storage root = s1. s1 can be H(A10), which is the hash of the root node A10 of the next level tree. The leaf nodes of A1, A2, and A3 store information about external accounts, while the leaf node of A4 stores information about contract accounts. For each contract account, there is a next-level MPT, forming a Storage Trie used to store the state variables of that contract account.

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

[0237] In the node composition of the above MPT tree, a 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 nibble(s), 2 indicates a Leaf Node containing an even number of nibbles, and 3 indicates a Leaf Node containing an odd number of nibble(s).

[0238] In the above node structure, the hash value of the entire content of the next tree node is filled into the corresponding position of the previous tree node. The database actually stores the key-value mapping for each tree node, where the value includes the content stored in that tree node, and the corresponding key is the hash value of the entire content of that tree node. Thus, the actual key-value pairs of the tree nodes stored in the database are shown in the following table:

[0239]

[0240] Table 3. Key-value pairs of tree nodes actually stored in the database.

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

[0242] In a typical MPT tree, leaf nodes store the actual content (state). However, with the structure described above, when a new state is generated, a new leaf node needs to be inserted into the tree, resulting in a series of changes along 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, an existing leaf node needs to be removed from the tree, also involving 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 changes in the content of the leaf nodes, it also affects the complex operations of splitting and merging Branch Nodes and Extension Nodes at the root node, as well as recalculating and updating hash values. Overall, the depth of the tree and the specific structure of Branch Nodes and Extension Nodes change significantly with changes in the state of the leaf nodes.

[0243] The Merkle tree in Bitcoin 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's depth is two levels. If a block contains 1024 transactions, then it will have 1024 leaf nodes, and the depth will be 11 levels, which is clearly a much larger tree.

[0244] Libra's SMT (Sparse Merkle Tree) is also a Merkle-type data structure, but it has its own unique characteristics, differing from a typical Merkle tree in some ways. The most significant difference lies in the fact that the number of leaf nodes, the depth of the tree, and its shape are predetermined. In contrast, the transaction Merkle tree in Bitcoin and the MPT tree in Ethereum have variable depths and sizes, meaning 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. For example, in Ethereum, an account address is 20 bytes long, totaling 2... 160 2 different addresses, i.e. 160 There are 2 accounts. In fact, Ethereum accounts can be stored using SMT (although it doesn't). However, it's very likely that there won't be 2 accounts in SMT. 160 The number of accounts may be significantly less than this. Therefore, for vacant accounts, a preset value (such as blank) can be used to fill in the blank to indicate that it is an inactive, empty account. In the underlying database, blank (preset value) leaf nodes can be omitted, and only non-blank leaf nodes can be stored.

[0245] The advantage of using SMT is that it can compress the size of the Merkle path in many cases. For example, using 1 bit to represent the preset value is much smaller than using the complete hash value (for example, the hash value in hash256 is 256 bits long), thus greatly reducing the size of the SPV proof.

[0246] S230: 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 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 mainnet through the second mainnet transaction.

[0247] The proof verifies the first transaction root in a manner similar to S130 described above, and will not be repeated here.

[0248] The prover verifies the first pre-state root based on the SPV proof. Specifically, the prover calculates the Merkle root based on the SPV proof's read set and the Merkle path to obtain the second pre-state root, and verifies whether the second pre-state root is equal to the first state root. If they are equal, it indicates that the first pre-state root sent by the prover is correct. The characteristic of hash calculation is that even a small change in the value of each calculation will result in a significantly different final result. Based on this characteristic, the prover cannot falsify, meaning it cannot produce a correct result based on incorrect states in leaf nodes or incorrect hash values ​​of Merkle tree nodes; that is, it cannot produce a correct Merkle root. Specifically, the prover can calculate... Figure 6 The hash value of the content corresponding to the bottom left node 8 is used as the value of node 8, and the hash value of the content corresponding to node 9 is used as the value of node 9. The two hash values ​​of node 8 and node 9 are concatenated in order and then the same hash algorithm is used to calculate the hash value, which is used as the hash value of node 4. The two hash values ​​of node 4 and node 5 in the SPV proof are concatenated in order and then the same hash algorithm is used to calculate the hash value, which is used as the hash value of node 2. The two hash values ​​of node 2 and node 3 are concatenated in order and then the same hash algorithm is used to calculate the hash value, which is used as the hash value of node 1, that is, as the second pre-state root, so as to verify whether the second pre-state root is equal to the first pre-state root.

[0249] The prover executes the packaged transactions sequentially and generates the second post-state root. This can be achieved by the prover executing the packaged transactions sequentially based on the read set involved in the packaged transactions, updating the write set during execution, and recalculating the Merkle root based on the updated write set according to the SPV proof to generate the second post-state root. Specifically, as follows... Figure 9 As shown, and assuming that a batch contains 3 transactions:

[0250] Tx_21: Alice → Bob 20

[0251] Tx_22: Bob → Alice 10

[0252] Tx_23: Alice → Bob 20

[0253] The transactions in this batch involve the states Alice and Bob; therefore, the read set involved in this batch can include the accounts Alice and Bob. The SPV proof for the read set can include not only the reads Alice:50 and Bob:100, but also the hash values ​​of node 5 and node 3 in the Merkle tree. Thus, the prover executes all transactions in the batch sequentially based on the reads in this batch, specifically Alice:50 and Bob:100.

[0254] For example, the read / write set generated after executing Tx_21, Tx_22, and Tx_23 in sequence includes the following:

[0255] Before Tx_21 is executed, the read set 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. Therefore, the resulting write set is Alice: 30 and Bob: 120.

[0256] Before Tx_22 is executed, the read set 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. Therefore, the resulting write set is Alice: 40 and Bob: 110.

[0257] Before Tx_23 is executed, the read set 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. Therefore, the resulting write set is Alice: 20 and Bob: 130.

[0258] After the transactions in this batch are executed sequentially, the final state of this batch is two write sets: Alice:20 and Bob:130. The prover, combining the hash values ​​of node 5 and node 3 in the Merkle tree containing these write sets, can obtain the hash value of the root node of the Merkle tree containing the updated state, i.e., the second post-state root. Here, for example, the generated write sets still correspond to the contents of nodes 8 and 9 in the Merkle tree. For instance, in the state corresponding to node 8, Alice's balance is modified from 50 to 20 relative to the initial state, and in the state corresponding to node 9, Bob's balance is modified from 100 to 130 relative 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, thereby generating 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 nodes in red 3 and 5), and use it as the second post-state root.

[0259] 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; for example, concatenate the two hash values ​​of node 8 and node 9 in order and calculate the hash value again using the same hash algorithm, and use it as the hash value of node 4; for example, concatenate the two hash values ​​of node 4 and node 5 in the SPV proof in order and calculate the hash value again using the same hash algorithm, and use it as the hash value of node 2; for example, concatenate the two hash values ​​of node 2 and node 3 in order and calculate the hash value again using the same hash algorithm, and use it 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.

[0260] 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 execution process of the Sequencer is correct, because starting from the same initial state, the execution result of the Sequencer executing the packaged transactions in sequence is the same as the execution result of the prover independently executing the same packaged transactions in sequence.

[0261] Thus, the prover verification can sign the information of the packaged transaction. Specifically, the prover verification can sign at least one of the following: the batch number of the packaged transaction, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction. Signing at least one of these contents indicates that the prover acknowledges the result produced by the Sequencer executing this batch.

[0262] As mentioned earlier, the prover can be implemented using a TEE. A TEE has a trusted execution environment that is completely isolated from the outside world, thus allowing it to hold its private key confidentially. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the packaged transaction information using its own private key to indicate its acceptance of the signed content.

[0263] The prover can be implemented using a TEE (Trusted Execution Environment). A TEE has a trusted execution environment that is completely isolated from the outside world, thus allowing it to hold its private key confidentially. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the packaged transaction information using its own private key to indicate its acceptance of the signed content.

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

[0265] Furthermore, 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 aforementioned process, which will not be repeated here. Moreover, the TEE can hash and sign the input code / data, thus using its own trustworthiness to guarantee that the executed input is also trustworthy; the TEE can also sign the hash value of the output (i.e., the execution result), again using its own trustworthiness to guarantee that the executed input is also trustworthy.

[0266] In this way, the prover verifies the information signature of the packaged transactions after independently executing (or replaying) the packaged transactions in sequence based on the initial state. This means the prover uses its own credibility to guarantee the credibility of the output result. Furthermore, the prover can send the signature as proof to the mainnet's 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 passes, the prover can be certain that the signed transaction information is credible based on trust in the TEE.

[0267] Signature verification is the process of verifying the signature using the TEE's public key. As long as the public key is trustworthy, this verification will be reliable and fast. The prover can send the signature as proof to the mainnet's blockchain ledger via a second mainnet transaction. This includes the prover sending the signature as proof to the mainnet via a second mainnet transaction and invoking a rollup contract on the mainnet. After receiving the transaction, the rollup contract verifies the correctness of the signature through its verification logic.

[0268] In summary, the prover can send the certificate to the mainnet's blockchain ledger via a second mainnet transaction. In a typical approach, the prover can send the certificate along with its signature to the mainnet's blockchain ledger via a second mainnet transaction. When using the EPID scheme described above, the certificate includes a remote authentication report generated by IAS for the prover, allowing verifiers to verify the validity of the prover's signature on transaction information. When using the DCAP scheme described above, the certificate can include a certificate issued by the authentication service for the prover. Based on trust in the authentication service, this can be extended to the certificate issued by the authentication service for the prover, allowing verifiers to verify the prover's signature using the public key in that certificate. For higher levels of trust, in addition to the certificate issued by the authentication service for the prover, a remote authentication report generated by IAS for the authentication service may also be required. This ensures the credibility of the authentication service's signature through authoritative Intel authentication (i.e., the remote authentication report, equivalent to a certificate issued by Intel for the authentication service), and the certificate issued by the authentication service for the prover further propagates trust downwards, thus guaranteeing the credibility of the prover's signature. This is how SGX DCAP provides trust through a certificate chain.

[0269] The verification logic executed by the aforementioned verifier can be built into the Rollup Contract and provided externally as a contract interface, such as a verification interface. In this way, the prover sends the signature as proof to the mainnet via a second mainnet transaction. Specifically, this could be a blockchain ledger invoked in the transaction. This includes the prover sending the signature as proof to the mainnet via the second mainnet transaction and invoking the verification interface of the Rollup Contract on the mainnet, through which the signature can be passed in. The verification interface can then execute verification logic, specifically verifying the legality of the signature. The process of verifying the signature's legality mainly involves verifying the signature's legality using the prover's public key.

[0270] Furthermore, the certificate of the prover corresponding to the signature can also be transmitted via the verification interface through the second mainnet transaction. This certificate may include the prover's public key. Thus, in addition to verifying the signature's legitimacy using the prover's public key, the verification can also include verifying the legitimacy of the prover's certificate. As mentioned above, the certificate may include a remote authentication report generated by IAS for the prover, or a certificate issued by an authentication service for the prover (which may also include a remote authentication report generated by IAS for the authentication service). Correspondingly, verifying the certificate may include verifying the legitimacy of the prover certificate using Intel's authoritative public key, or it may include verifying the legitimacy of the authentication service's certificate using Intel's authoritative public key and verifying the prover certificate's legitimacy using the public key in the authentication service's certificate.

[0271] As mentioned above, using a TEE as the proof-generator on the Layer 2 network offers lower latency due to the near-native execution speed of transaction replay and verification within the TEE. Once the local TEE passes remote authentication, the CPU can process the data within the Enclave through the TEE mechanism, achieving extremely high computational efficiency, thus balancing data security and computational efficiency. This is significantly faster than the ZK-Rollup method; for example, under the same conditions, generating a proof from ZK-Rollup requires an interval of 30-50 minutes (or even hours). Figure 4 From Block N to Block N+412, the time is shortened to the 5-10 minute range of this application (which can be called TEE-Rollup). Figure 6 In the case of Block N to Block N+62, and even without using the listening mode, but instead executing S230 directly after S220, the time will be reduced to even less. Furthermore, the generated proof is the size of a signature, approximately tens of bytes, similar to ZK-Rollup.

[0272] Similarly, the information signature of the packaged transaction can be at least one of the following: the batch number of the packaged transaction, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction.

[0273] The signature of the packaged transaction information can be at least one of the following: the number of the packaged consecutive batches, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction; or at least one of the following: 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 packaged consecutive batches are grouped.

[0274] Before the prover verifies the first transaction root and the first pre-state root, it may also include: the sorter sending a first mainnet transaction that calls the rollover contract to the mainnet, the first transaction containing each field in the BatchHeader of the packaged transaction, as well as the compressed transaction or the compressed read-write set (the term is called State Diff).

[0275] Furthermore, the prover can monitor the execution results of contracts on the mainnet. The specifics are similar to the aforementioned embodiments and will not be repeated here.

[0276] Furthermore, the proof-generator can also send the certificate and the signature together to the blockchain ledger of the mainnet via a second mainnet transaction. The certificate may include a remote authentication report generated by IAS for the proof-generator, or the certificate may include a certificate issued by the authentication service for the proof-generator, or it may also include a remote authentication report generated by IAS for the authentication service.

[0277] The prover sends the signature as proof to the mainnet's blockchain ledger via a second mainnet transaction. This includes the prover sending the signature as proof to the mainnet via a second mainnet transaction and invoking a rollup contract on the mainnet. It may also include: after receiving the transaction, the rollup contract verifies the correctness of the signature using its verification logic. Verifying the correctness of the signature using its verification logic may further include: verifying the legality of the certificate, which includes the prover's public key.

[0278] The verification of the certificate's legitimacy may specifically include:

[0279] The legitimacy of the proof-of-confirmation certificate is verified using Intel's authoritative public key; or,

[0280] The validity of the certificate for the authentication service is verified using Intel's authoritative public key, and the validity of the prover certificate is verified using the public key in the certificate for the authentication service.

[0281] To improve TPS in Layer 2, it's necessary to accelerate transaction execution. 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, aiming to increase computational speed and solve large and complex computational problems by scaling the problem-solving scope. Parallel computing can be divided into temporal parallelism and spatial parallelism. Temporal parallelism refers to pipelining techniques, while spatial parallelism refers to the concurrent execution of computations using multiple processors. Furthermore, to improve efficiency, grouping or pipelining methods can be used to enhance the execution process. When the Prover's performance is high, the overall performance bottleneck lies in the Sequencer's transaction execution process. This can be addressed by decoupling the transaction execution part of the Sequencer, for example, by decoupling it into an Executor. Figure 10 As shown; in this way, the aforementioned pipeline approach can be used to improve the overall execution speed. Furthermore, the Executor can be horizontally scaled (also known as scaling out), that is, the Executor can be expanded into multiple entities (logical entities or physical entities), such as... Figure 11 As shown; in this way, the aforementioned group execution method can be adopted, thereby improving the execution speed of the execution stage and thus increasing the utilization rate of Prover.

[0282] The following is a preliminary step. Figure 10 An example is given of a method embodiment for implementing two-layer network convolution using a pipeline approach, including:

[0283] S310: 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.

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

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

[0286] The subsequent packaged transaction refers to the package with a subsequent sequence number relative to the preceding packaged transaction in S330. For example, if the sequence number of the subsequent packaged transaction is N+1, then S320 specifically includes: the executor generating the first transaction root of the transaction in the N+1th package; executing the transactions in the N+1th package sequentially based on the initial state before the execution of the transactions in the N+1th package and generating the first subsequent 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 preceding state root and the first subsequent state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment.

[0287] S330: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0288] Correspondingly, the preceding packaged transaction refers to the package with the preceding sequence number relative to the subsequent packaged transaction in S320. For example, if the sequence number of the preceding packaged transaction is N, then the above-mentioned S330 specifically includes: the prover verifying the first transaction root and the first pre-state root in the Nth package; after both verifications pass, the transactions in the Nth package are executed sequentially 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 transaction in the Nth package is signed using the private key in the trusted execution environment, and the signature is sent to the blockchain ledger of the mainnet through the second mainnet transaction as proof.

[0289] The preceding packaged transaction is followed by a subsequent packaged transaction, and the sequence number is not limited to the relationship between N and N+1. For example, it can be the relationship between N and N+2, etc.

[0290] In this way, the executor can continuously perform the corresponding work for subsequent packaged transactions and send the results to the prover, while the prover can continuously perform the corresponding work for previous packaged transactions, forming a pipeline-like operation. As a result, the computing power of the executor and prover can be used efficiently, enabling continuous execution of transactions and continuous generation of proofs.

[0291] When using SPV proof, the above scheme is as follows:

[0292] S410: 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;

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

[0294] S420: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the packaged transactions, and generates the 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 layer 2 network; the prover is implemented using a trusted execution environment.

[0295] S430: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

[0296] The following is Figure 11 An example is given to implement a two-layer network convolution using a grouped parallel approach, including:

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

[0298] The at least two executors refer to at least two executor threads / coroutines or at least two executor processes. These at least two executors, being at least two executor threads / coroutines, can reside within the same process; alternatively, they can be at least two executor processes, residing on the same physical machine / virtual machine or different physical machines / virtual machines. When the at least two executor processes reside on different physical machines / virtual machines, these different physical machines / virtual machines can belong to the same participant. In this way, there are no trust issues between physical machines / virtual machines belonging to the same participant.

[0299] For example, after the sorter sorts and packages the retrieved 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 transaction. Each transaction group does not access the same account, thus allowing parallel execution of each transaction group. When a transaction involves calling a smart contract, in some simple cases, static analysis of the smart contract code can be performed to obtain the access (including read / write) state variables. However, in some complex cases, the accessed state variables in the transaction cannot be predicted before execution, making it impossible to effectively group multiple transactions and thus impossible to execute them in parallel. For the latter, multiple transactions can be pre-executed to obtain pre-execution read / write sets for each transaction, allowing for grouping of these transactions based on the pre-execution read / write sets. Of course, ordinary transfer transactions can also be pre-executed to obtain read / write sets.

[0300] Specifically, the pre-execution read / write set of a transaction 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 during the pre-execution of the transaction, and the pre-execution write set includes key-value pairs of variables written during the pre-execution of the transaction. The state variables include, for example, external accounts in Layer 2, or state variables defined in a contract account.

[0301] Multiple transactions can be grouped using different algorithms. In one implementation, a Directed Acyclic Graph (DAG) algorithm can be used to group multiple transactions. Specifically, a DAG graph is first drawn based on the dependencies between transactions. For example, suppose a slave node executes multiple transactions according to the order in which the master node pre-executes them. Therefore, the dependencies between transactions can be determined based on the pre-execution read / write sets and the 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-executed transaction (e.g., transaction Tx2) depends on the earlier-executed transaction (e.g., transaction Tx1). Therefore, in the DAG graph, transaction Tx1 can be drawn pointing to transaction Tx2. In the case where transaction Tx2 depends on the execution of transaction Tx1, transactions Tx1 and Tx2 can be considered conflicting transactions and need to be executed sequentially, i.e., transaction Tx2 is executed after transaction Tx1.

[0302] Figure 12This is a schematic diagram of a DAG (Directed Acyclic Graph) of multiple transactions in one embodiment. Circles represent nodes in the DAG, numbers within the circles represent transaction numbers, and arrows between nodes represent directed edges connecting them. After obtaining the DAG of multiple transactions, the transactions can be grouped according to the DAG, such that transactions in every two transaction groups are separate nodes in the DAG, meaning that no transaction in one group is connected to any transaction in another group.

[0303] like Figure 12 As shown, multiple transactions connected by arrows (i.e., transactions Tx1 to Tx8) are conflicting transactions and need to be grouped into a transaction group. When executing transactions Tx1 to Tx8, transactions (Tx3, Tx5) and (Tx1, Tx2, Tx4) can be executed in parallel first. Transactions Tx3 and Tx5 are executed sequentially, while transactions Tx1, Tx2, and Tx4 must be executed sequentially. Transaction Tx6 must wait for transactions Tx4 and Tx5 to complete before it can be executed, and transactions Tx7 and Tx8 must wait for transactions Tx5 and Tx6 to complete before they can be executed in parallel. Transactions Tx5 and Tx6 connect three or more nodes and can be called forks. When there are many forks in the DAG graph, subsequent transactions will have longer waiting times for these forks. Furthermore, the DAG algorithm requires a large state space. Therefore, the efficiency of the DAG grouping algorithm decreases when there are many conflicting transactions.

[0304] In another implementation, multiple transactions can be grouped using a disjoint-set data structure (DAG). A DAG is a tree-like data structure used to handle merging and querying disjoint sets. A DAG typically includes two operations: find, to check if two elements are in the same set; and union, to merge two disjoint sets into one. This algorithm allows two transactions to be merged into a single set if their pre-execution read / write sets contain the same key, resulting in multiple sets where transactions in each set do not access the same key, thus enabling parallel processing of multiple sets. However, because the DAG algorithm does not consider whether a transaction accesses a key for reading or writing, it groups two transactions that access the same key together, potentially resulting in two transactions reading the same key being grouped together. Therefore, compared to the grouping results obtained by the DAG algorithm, the parallelism of the multiple transaction groups obtained by the DAG algorithm is lower.

[0305] The executor participants may include multiple executors. The sorter may also read the value from the read set of each group of transactions in the storage and send the read value to the corresponding executor.

[0306] S520: The executor participant uses one 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 sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 layer 2 network; the prover is implemented using a trusted execution environment.

[0307] A Sequencer can be connected to multiple Executors of a participating party, such as... Figure 11 As shown, two Executors are connected to one participant. The participant can use one Executor to generate the first transaction root of the packaged transaction. Furthermore, the participant can use the at least two Executors to sequentially execute different transaction groups within the packaged transaction. Here, "one Executor" can be one of the two Executors, or it can be something else entirely.

[0308] After each of the at least two executors sequentially executes different transaction groups within the packaged transaction, the execution results can be sent to an "executor." This "executor" then merges the execution results of all transaction groups and generates a first post-state root. This executor participant can then send the packaged transaction, the first transaction root, the initial state before transaction execution, and the corresponding first pre-state root and first post-state root to the prover of the Layer 2 network. Here, the "executor" may or may not be one of the "at least two executors."

[0309] 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 transactions are executed sequentially based on the initial state to generate the 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 using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0310] In this way, the executor can continuously execute the corresponding work for the next packaged transaction and send the result to the prover, while the prover can continuously execute the corresponding work for the previous packaged transaction. Thus, the computing power of the prover can be used efficiently, enabling the continuous and rapid generation of proofs.

[0311] Furthermore, instead of a sorter, the grouping of the packaged transactions can be done by an executor from one of the participating parties. An example of this would be as follows:

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

[0313] S620: The executor participant uses one executor to generate the first transaction root of the packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 layer 2 network; the prover is implemented using a trusted execution environment.

[0314] 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 transactions are executed sequentially based on the initial state to generate the 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 using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0315] The following are examples of methods for implementing two-layer network convolution using a grouped parallel + pipelined approach, including:

[0316] S710: 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.

[0317] Parallel execution of S720 and S730:

[0318] S720: The executor participant uses one 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 executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the layer 2 network; the prover is implemented using a trusted execution environment.

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

[0320] S730: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0321] 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 both verifications pass, the Nth packaged transaction is executed sequentially 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 transaction in the Nth package is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0322] In the above example, it could also be changed so that the executor of the participant group the packaged transactions instead of the sorter grouping them. An example of this would be as follows:

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

[0324] Parallel execution of S820 and S830:

[0325] S820: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participant sends the subsequent 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 layer 2 network; the prover is implemented using a trusted execution environment.

[0326] Specifically: the executor participants use one executor to generate the first transaction root of the (N+1)th packaged transaction, and send the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the (N+1)th packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants send the (N+1)th packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment.

[0327] S830: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0328] Specifically: The prover verifies the first transaction root and the first pre-state root in the Nth packaged transaction; after both verifications pass, the Nth packaged transaction is executed sequentially 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 transaction in the Nth package is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0329] In 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, the Prover TEE can be expanded into multiple prover TEEs, thereby executing the above process in parallel. Clearly, the parallel execution of multiple prover TEEs can improve the speed of proof on Layer 1, thereby further reducing the transaction confirmation latency on Layer 1.

[0330] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0331] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0332] The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates the first transaction root of the packaged transactions, executes the packaged transactions in sequence based on the initial state before the execution of the packaged transactions, and generates the first post-state root; the sorter sends the packaged transactions, the first transaction root, the SPV proof of the packaged transaction read set before the execution of the packaged transactions, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the layer 2 network.

[0333] 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 both verifications are passed, the packaged transactions are 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 a private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0334] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0335] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0336] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor.

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

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

[0339] S330: The prover verifies the first transaction root and the first pre-state root of the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0340] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0341] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0342] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor.

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

[0344] S420: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the 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 transaction in the (N+1)th packet, and the first pre-state root and the first post-state root to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0345] S430: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

[0346] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0347] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0348] The sorter 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.

[0349] The executor participants use one executor to generate the first transaction root of the packaged transaction; each of the at least two executors sequentially executes different transaction groups in the packaged transaction based on the initial state before the execution of the packaged transaction, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0350] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0351] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0352] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0353] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0354] The executor participants use one executor to generate the first transaction root of the packaged transaction, and group transactions that have no dependencies into different groups and send the different groups to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants 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 the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0355] The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0356] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0357] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0358] The sorter 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.

[0359] The executor participants use one executor to generate the first transaction root of subsequent packaged transactions; each of the at least two executors executes different transaction groups in the subsequent packaged transactions sequentially based on the initial state before the execution of the subsequent packaged transactions, and the executor merges the execution results of all transaction groups to generate the first post-state root; the executor participants send the subsequent packaged transactions, 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 Layer 2 network; the prover is implemented using a trusted execution environment;

[0360] The proofer verifies the first transaction root and the first pre-state root in the preceding packaged transaction. After both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0361] The following describes a two-layer network embodiment of this application, including a transaction pool, a sorter, and a prover, wherein:

[0362] A transaction pool is used to receive transactions sent by users on a Layer 2 network.

[0363] The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them into packets, and sends them to the executor participants.

[0364] Parallel execution of S820 and S830:

[0365] S820: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment;

[0366] S830: The prover verifies the first transaction root and the first pre-state root in the preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

[0367] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0368] The controller can be implemented in any suitable manner. For example, it 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 Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0370] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0371] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0372] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0373] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0374] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0376] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0377] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0378] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. 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, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0379] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0380] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0381] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for implementing two-layer network convolution, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates the first transaction root of the packaged transactions, and executes the packaged transactions in sequence based on the initial state before the execution of the packaged transactions and generates the first post-state root. The sorter sends the packaged transaction, the first transaction root, the SPV proof of the packaged transaction read set 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 layer 2 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 both verifications are passed, the packaged transactions are 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. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

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

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

4. A method for implementing two-layer network convolution, 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; The executor and the prover execute S1 and S2 in parallel: S1: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the initial state before the execution of the subsequent packaged transactions, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment; S2: The prover verifies the first transaction root and the first pre-state root of the preceding packaged transaction; after both verifications are passed, the preceding packaged transaction is executed sequentially based on the initial state before the execution of the preceding packaged transaction, generating the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding 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 mainnet through the second mainnet transaction.

5. A method for implementing two-layer network convolution, 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; The executor and prover execute S3 and S4 in parallel: S3: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the 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 corresponding to the initial state to the prover of the layer 2 network; the prover is implemented using a trusted execution environment; S4: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

6. A method for implementing two-layer network convolution, comprising: 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 different groups to the executor participants. The executor participants use one executor to generate the first transaction root of the packaged transaction; at least two executors each execute different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and the executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants send 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 Layer 2 network; the prover is implemented using a trusted execution environment; The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

7. A method for implementing two-layer network convolution, comprising: The sorter in 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 participants use one executor to generate the first transaction root of the packaged transaction, and group transactions that have no dependencies into different groups and send the different groups to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants send the packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment; The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

8. A method for implementing two-layer network convolution, comprising: 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 different groups to the executor participants. The executor participants use one executor to generate the first transaction root of the subsequent packaged transaction; at least two executors each execute different transaction groups in the subsequent packaged transaction sequentially 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 the first post-state root; the executor participants send 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 Layer 2 network; the prover is implemented using a trusted execution environment. The proofer verifies the first transaction root and the first pre-state root in the preceding packaged transaction. After both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

9. A method for implementing two-layer network convolution, comprising: The sorter in 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: S5: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the layer 2 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 preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

10. The method of any one of claims 1-9, wherein the prover is at least two and executes in parallel.

11. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein the prover is implemented using a trusted execution environment, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates the first transaction root of the packaged transactions, executes the packaged transactions in sequence based on the initial state before the execution of the packaged transactions, and generates the first post-state root; the sorter sends the packaged transactions, the first transaction root, the SPV proof of the packaged transaction read set before the execution of the packaged transactions, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the layer 2 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 both verifications are passed, the packaged transactions are 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 a private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

12. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor. The executor and the prover execute S1 and S2 in parallel: S1: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the initial state before the execution of the subsequent packaged transactions, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment; S2: The prover verifies the first transaction root and the first pre-state root of the preceding packaged transaction; after both verifications are passed, the preceding packaged transaction is executed sequentially based on the initial state before the execution of the preceding packaged transaction, generating the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding 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 mainnet through the second mainnet transaction.

13. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor. The executor and prover execute S3 and S4 in parallel: S3: The executor generates the first transaction root of the subsequent packaged transactions, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the subsequent packaged transactions, and generates the 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 corresponding to the initial state to the prover of the layer 2 network; the prover is implemented using a trusted execution environment; S4: The prover verifies the first transaction root of the preceding packaged transaction and verifies the first pre-state root based on the SPV proof of the preceding packaged transaction read set; after both verifications are passed, the preceding packaged transactions are 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 mainnet through the second mainnet transaction.

14. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter 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. The executor participants use one executor to generate the first transaction root of the packaged transaction; at least two executors each execute different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and the executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants send 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 Layer 2 network; the prover is implemented using a trusted execution environment; The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

15. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants. The executor participants use one executor to generate the first transaction root of the packaged transaction, and group transactions that have no dependencies into different groups and send the different groups to at least two executors; each of the at least two executors executes the different transaction groups in the packaged transaction sequentially based on the initial state before the execution of the packaged transaction, and one executor merges the execution results of all transaction groups and generates the first post-state root; the executor participants send the packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and first post-state root corresponding to the initial state to the prover of the Layer 2 network; the prover is implemented using a trusted execution environment; The proofer verifies the first transaction root and the first pre-state root in the packaged transaction. After both verifications are passed, the packaged transactions are executed sequentially 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 using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

16. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter 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. The executor participants use one executor to generate the first transaction root of the subsequent packaged transaction; at least two executors each execute different transaction groups in the subsequent packaged transaction sequentially 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 the first post-state root; the executor participants send 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 Layer 2 network; the prover is implemented using a trusted execution environment. The proofer verifies the first transaction root and the first pre-state root in the preceding packaged transaction. After both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

17. A two-layer network, comprising a transaction pool, a sorter, and a prover, wherein: A transaction pool is used to receive transactions sent by users on a Layer 2 network. The sorter pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants. The actuator and the prover execute S5 and S6 in parallel: S5: The executor participant uses one executor to generate the first transaction root of the subsequent packaged transaction, and sends the different groups of transactions that do not have dependencies to at least two executors; each of the at least two executors executes the different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and one executor merges the execution results of all transaction groups and generates the 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 the first post-state root corresponding to the initial state to the prover of the layer 2 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 preceding packaged transaction; after both verifications are passed, the preceding packaged transactions are executed sequentially based on the initial state to generate the second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the preceding packaged transaction is signed using the private key in the trusted execution environment. The signature is used as proof and sent to the blockchain ledger of the mainnet through the second mainnet transaction.

Images