Method for realizing roll-up of two-layer network and two-layer network

Abstract

The invention discloses a method for realizing two-layer network rolling and a two-layer network. The method comprises the following steps: a sorter pulls transactions from a transaction pool, sorts the pulled transactions to obtain packaged transactions, executes the packaged transactions in sequence to obtain execution results, feeds back the execution results to a user and generates a first post-state root; the transaction execution information is sent to a track generation module; the track generation module obtains an execution track based on the transaction execution information, and provides the transaction execution information and the execution track to the certification module; the first prover generates a first proving based on the transaction execution information, and uploads the first proving to the roll contract of the main network; the second prover generates a second proving based on the execution track, the first previous state root and the first later state root, the second proving is uploaded to a rolling contract of the main network, and the first proving and the second proving are used for jointly determining whether the packaging transaction is correctly executed or not.

Description

Technical Field

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

[0002] There is a classic CAP theorem in distributed systems - Consistency, Availability, and Partition tolerance. It is impossible to achieve all three at the same time, which is abbreviated as the "impossible triangle" problem. There is also an impossible triangle in blockchain: efficiency, decentralization, and security. Although there is no clear theoretical argument for this blockchain "impossible triangle", it is a summary of existing blockchains. Efficiency, decentralization, and security are defined as follows:

[0003] Efficiency: The number of transactions processed per second, i.e., TPS (Transaction per Second).

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

[0005] Security: The difficulty of launching an attack on the blockchain is high enough.

[0006] To address the above blockchain "impossible triangle" problem, the blockchain system (also known as the "mainnet" or "layer 1", Mainnet or Layer1) has chosen security and decentralization at the expense of efficiency. Currently, it only has about 12 - 15 TPS. When there are a large number of transactions to be processed, especially many complex transactions, Layer1 will become congested. In addition to ordinary transfer transactions, Layer1 also serves as the main platform for popular applications such as DeFi (Decentralized Finance) and NFT (Non-Fungible Tokens). When transactions are prevalent, the congestion problem of Layer1 becomes very serious, resulting in significant transaction delays, which in turn affects user experience.

[0007] In addition, the high transaction fee (Gas fee) often becomes an obstacle to transactions. Although the consensus mechanism has changed from Proof of Work (PoW) to Proof of Stake (PoS), this only changes the way of obtaining the right to record transactions on the blockchain, and the transaction fee paid to the nodes that obtain the right to record transactions has not decreased significantly. This is because the design of the Gas fee targets the consumption of nodes for executing transactions (including executing smart contract code). Without changing this part of the consumption, the Gas fee will not decrease. For example, the transaction fee for a currency exchange transaction on a decentralized exchange may exceed $100 during congestion, which discourages many users.

[0008] Layer 2 technology is an extensibility solution built on top of Layer 1, aiming to address the issues of low efficiency and high transaction fees in Layer 1. As Figure 1 shown, transactions can be executed quickly on Layer 2, and Layer 2 synchronizes the final state back to Layer 1 at certain times. Layer 2 is specifically used to provide high-speed transaction processing, while the security and decentralization are ensured by Layer 1. In this way, while reducing the pressure on Layer 1, the Gas fee for executing transactions on Layer 2 can be significantly reduced, and the Gas fee required to synchronize the final state (instead of all states on Layer 2) of transaction execution on Layer 2 back to Layer 1 can also be significantly reduced. The technology of architecting Layer 2 on top of Layer 1 actually separates the execution process of transactions or contracts from the preservation of the final state. The execution process is placed on Layer 2, and Layer 1 only needs to preserve the final state. In this design, it is necessary to ensure the correctness of the execution process of transactions or contracts on Layer 2, and the state written to Layer 1 is consistent with the correct execution result on Layer 2.

[0009] Layer 2 includes a mechanism called Rollup. The core idea of Rollup is as Figure 1 shown, which is to save the vouchers that can verify the transaction process on Layer 1, while storing the transaction process (computation process) and state in Layer 2. The so-called vouchers for the transaction process include a set of pre-transaction states (Pre-State), the states after the execution of this set of transactions (Post-State), and this set of transactions, which can be used to verify whether the corresponding state transition of this set of transactions is correct, and can also be used to restore the execution process of all transactions on Layer 2 and the states of all accounts, thus eliminating the security risks brought by data availability on Layer 2.

[0010] The current mainstream Rollup mechanisms include TEE Rollup and zkRollup. Among them, TEE Rollup is a layer-2 expansion solution based on the Trusted Execution Environment (TEE). In this solution, transactions are processed in batches off-chain, and the TEE generates validity proofs for the execution of transactions. The TEE is a hardware-level secure isolation area that protects code and data from external attacks. zkRollup is a layer-2 scaling solution based on Zero-Knowledge Proof (ZKP). In this solution, transactions are processed in batches off-chain, and validity proofs for the execution of transactions are generated based on zero-knowledge proof algorithms, improving the transaction throughput of the blockchain network, reducing fees, and ensuring security at the same time. However, a significant problem with Layer 2 based on zkRollup is that the time for ZK proofs is too long and the computational cost is too high, which limits the performance improvement to a certain extent. And Layer 2 based on TEE Rollup may have security issues (backward security) after future technological advancements (such as the development of quantum computers).

[0011] In important application areas of blockchain, such as Real World Assets (RWA), as the scale of on-chain assets continues to grow and the transaction volume increases, it can be foreseen that the challenges to the blockchain system are comprehensive. RWA refers to the transformation of tangible or intangible assets in the real world (such as real estate, bonds, commodities, intellectual property rights, etc.) into digital assets that can be circulated and traded on-chain through blockchain technology. The core is to map the ownership or income rights of traditional assets in the form of digital assets to the blockchain network through technical means such as smart contracts, realizing the efficient transfer and value reconstruction of assets. As an innovative application area that combines traditional financial services and blockchain technology, RWA requires the infrastructure to provide performance requirements close to those of traditional financial trading systems on the premise of ensuring security and trust, including features such as low latency, high frequency, and high throughput. Currently, existing Layer 2 technologies often only focus on solving problems in one dimension and are difficult to fully adapt to the future development of RWA business. Summary of the Invention

[0012] The purpose of the present invention is to provide a method for implementing a two-layer network rollup to improve the security of the two-layer network while accelerating the feedback to users.

[0013] The first aspect of this specification provides a method for implementing a two-layer network rollup, including:

[0014] The sequencer of the layer-2 network pulls transactions from the transaction pool, sorts and packages the pulled transactions to obtain packaged transactions, sequentially executes the packaged transactions based on the initial state before the execution of the packaged transactions to obtain the execution results of each transaction, feeds back the execution results to the corresponding users, and generates a first post-state root corresponding to the packaged transactions; sends the packaged transactions, the initial state, and the first pre-state root and the first post-state root corresponding to the initial state to the trace generation module of the layer-2 network;

[0015] The trace generation module sequentially executes the packaged transactions based on the initial state to obtain the execution traces of the packaged transactions, and provides the packaged transactions, the initial state, the execution traces, the first pre-state root, and the first post-state root to the proof module, where the proof module includes a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm;

[0016] Based on the packaged transactions, the initial state, the first pre-state root, and the first post-state root, the first prover generates a first proof and uploads the first proof to the rollup contract of the mainnet through a first mainnet transaction;

[0017] Based on the execution traces, the first pre-state root, and the first post-state root, the second prover generates a second proof and uploads the second proof to the rollup contract of the mainnet through a second mainnet transaction. The first proof and the second proof are used to jointly determine whether the packaged transactions are correctly executed.

[0018] The second aspect of this specification provides a layer-2 network, including a sequencer, a trace generation module, and a proof module. The proof module includes a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm, where:

[0019] The sequencer is configured to pull transactions from the transaction pool, sort and package the pulled transactions to obtain packaged transactions, sequentially execute the packaged transactions based on the initial state before the execution of the packaged transactions to obtain the execution results of each transaction, feed back the execution results to the corresponding users, and generate a first post-state root corresponding to the packaged transactions; send the packaged transactions, the initial state, and the first pre-state root and the first post-state root corresponding to the initial state to the trace generation module of the layer-2 network;

[0020] The trajectory generation module is used to: execute the packaged transactions in sequence based on the initial state to obtain the execution trajectory of the packaged transactions, and provide the packaged transactions, the initial state, the execution trajectory, the first pre-state root, and the first post-state root to the proof module, where the proof module includes a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm;

[0021] The first prover is used to: generate a first proof based on the packaged transactions, the initial state, the first pre-state root, and the first post-state root, and upload the first proof to the rollup contract on the mainnet through a first mainnet transaction;

[0022] The second prover is used to: generate a second proof based on the execution trajectory, the first pre-state root, and the first post-state root, and upload the second proof to the rollup contract on the mainnet through a second mainnet transaction, where the first proof and the second proof are used to jointly determine whether the packaged transactions are correctly executed.

[0023] A third aspect of this specification provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute the method described in the first aspect.

[0024] A fourth aspect of this specification provides a computing device, including a memory and a processor. An executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0025] A fifth aspect of this specification provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

[0026] Through the solution for implementing rollups in the second-layer network in the embodiments of this specification, by adding a trajectory generation module in the second-layer network to generate the execution trajectory of the packaged transactions, and including a TEE prover and a ZK prover in the proof module, the ability to achieve low-latency return, high-throughput confirmation, and heterogeneous proof cross-verification to ensure data backward security can be realized, thereby supporting secure and efficient docking with the traditional financial system and providing a technical infrastructure for RWA-based innovative financial services. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] To more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0028] Figure 1 It is a schematic diagram of the principle of Layer2 in one embodiment;

[0029] Figure 2 It is a schematic diagram of the principle of MerkleTree in one embodiment;

[0030] Figure 3 It is a schematic diagram of the principle of MerkleTree in one embodiment;

[0031] Figure 4 It is a schematic diagram of the principle of Layer2 in one embodiment;

[0032] Figure 5 It is a schematic diagram of the OP-Rollup principle of Layer2 in one embodiment;

[0033] Figure 6 It is a schematic diagram of the ZK-Rollup principle of Layer2 in one embodiment;

[0034] Figure 7 It is a schematic diagram of the TEE-Rollup principle of Layer2 in one embodiment;

[0035] Figure 8 It is a schematic diagram of the structure of Layer2 in one embodiment of this specification;

[0036] Figure 9 It is a flowchart of the method for implementing a two-layer network rollup in an embodiment of this specification;

[0037] Figure 10 It is a schematic diagram of the process of processing multiple batches of transactions in a pipelined manner in Layer2 in an embodiment of this specification. Detailed implementation manners

[0038] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0039] First, introduce the relevant technical content of the blockchain system.

[0040] Blockchain systems are generally divided into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, and other different combinations. Among them, the public blockchain has the highest degree of decentralization. Participants joining the public blockchain can read the data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each participant (represented as a node of the participant on the blockchain) can freely join and exit the network and perform relevant operations. On the contrary, for private blockchains, the write permission of the network is controlled by a certain organization or institution, and the data read permission is subject to organizational regulations. Simply put, a private blockchain can be a weakly decentralized system with strictly restricted and few participating nodes. This type of blockchain is more suitable for internal use within a specific institution. A consortium blockchain is a blockchain between a public blockchain and a private blockchain, which can achieve "partial decentralization". Each node in a consortium blockchain usually has a corresponding entity organization or institution; participants join the network through authorization and form an interest-related consortium to jointly maintain the operation of the blockchain.

[0041] Regardless of whether it is a public blockchain, a private blockchain, or a consortium blockchain, in addition to supporting the transfer of digital assets on the blockchain between accounts, it can also provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0042] The core of a programmable blockchain is the virtual machine. Each blockchain node can run a Turing-complete virtual machine, which means that various complex logics can be implemented through it. Users publish and call smart contracts in the blockchain system by running them on the virtual machine. In fact, what the virtual machine directly runs is the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode" for short). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0043] Smart contracts can be independently executed at each node in the blockchain network in a prescribed manner, and all execution records and data are saved on the blockchain. Therefore, when such a transaction is completed, an immutable and non-lost transaction voucher is saved on the blockchain.

[0044] In various blockchain networks introducing smart contracts, accounts usually can include two types:

[0045] Contract accounts: Store the executed smart contract code and the values of the states in the smart contract code, and usually can only be activated by being called by an external account;

[0046] Externally owned account: The user's account.

[0047] The design of externally owned accounts and contract accounts is actually a mapping from account addresses to account states. The state of an account usually includes fields such as Nonce, Balance, Storage root, and CodeHash. Nonce and Balance exist in both externally owned accounts and contract accounts. The CodeHash and Storage root attributes are generally only valid for contract accounts.

[0048] Nonce: A counter. For an externally owned account, this number can represent the number of transactions sent from the account address; for a contract account, it can be the number of contracts created by the account.

[0049] Balance: The amount of digital assets owned by this address.

[0050] Storage root: The hash of the root node of an MPT tree that organizes the storage of the state variables of a contract account.

[0051] CodeHash: The hash value of the smart contract code. For a contract account, this is the hash value of the smart contract; for an externally owned account, since it does not include a smart contract, the CodeHash field can generally be an empty string / a string of all 0s.

[0052] MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (a more space-saving Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a Hash value for each transaction, then connects them in pairs and calculates the Hash again until the top-level Merkle root is obtained.

[0053] The data structure of the MPT tree includes a state trie. The state trie contains key-value pairs (also written as key-value, abbreviated as k-v or kv) of the storage content corresponding to each account in the blockchain system. The "key" in the state trie can be a 160-bit identifier (such as the address of a blockchain account or a part of the hash value of the address, hereinafter collectively referred to as the account address), and this account address is distributed in the storage from the root node to the leaf node of the state trie. The "value" in the state trie is generated by encoding the account information (using the Recursive-Length Prefix encoding (RLP) method). As mentioned above, for an external account, the value includes nonce and balance; for a contract account, the value includes nonce, balance, codehash, and storageroot.

[0054] Contract accounts are used to store the states related to smart contracts. After a smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and new values are generated when the smart contract is created and executed. The so-called smart contract usually refers to a contract that can automatically execute terms defined in code form in a blockchain environment. Once an event triggers the terms in the contract (meets the execution conditions), the code can be automatically executed. In the blockchain, the relevant states of the contract are stored in the storage trie, and the hash value of the root node of the storage trie is stored in the above-mentioned storageroot, so that all the states of the contract are locked under the contract account through the hash. The storage trie is also an MPT tree structure, which stores the key-value mapping from the state address to the state value. The partial information from the root node to the leaf node of the storage trie tree is arranged in sequence to store the address of a state, and the value of the state is stored in this leaf node.

[0055] As Figure 2In some of the blockchain data storages shown, the block header of each block includes several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), nonce (in some blockchain systems, this nonce is not random, or in some blockchain systems, the nonce in the block header is not enabled), timestamp, block number Block Num, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. Among them, the Prev Hash in the block header of the next block (such as block N + 1) points to the previous block (such as block N), which is the hash value of the previous block. In this way, the next block is locked to the previous block through the block header on the blockchain. Among them, State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set respectively. The state set, transaction set, and receipt set organize states, transactions, and receipts in the form of trees respectively. In the tree structure of the state set including smart contracts in some cases, there is a two-level MPT structure: the leaf nodes of the upper-level MPT structure include two types, external accounts and contract accounts; each of the contract accounts among them includes a lower-level MPT structure, and the leaf nodes of the lower level include the values of the states in the contract account.

[0056] Figure 3 is a schematic structural diagram of a blockchain data storage. It can be combined with Figure 2As shown, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state trie in the form of an MPT points to state_root. The root node of this MPT tree is generally an Extension Node or a Branch Node, and what is stored in state_root is generally the hash value of this root node. The root node can be connected to one or more layers of Extension Node / Branch Nodes below, and these multi-layer tree nodes can be collectively referred to as Internal Nodes. Part of the values in each node from the root node of this MPT to the leaf nodes can be concatenated in order to form an account address and serve as the key, and the account information stored in the leaf node is the value corresponding to this account address. In this way, a key-value pair is formed. This key can also be a part after sha3(Address), that is, a part of the hash value of the account address (the hash algorithm uses the sha3 algorithm for example), and the value it stores can be rlp(Account), that is, the rlp encoding of the account information. The account information is a quadruple composed of [nonce, balance, storageRoot, codeHash]. As mentioned above, for an external account, generally only the nonce and balance items exist, while the storageRoot and codeHash fields default to storing an empty string / all 0 strings. That is to say, the external account does not store contracts or the state variables generated after the contract execution. A contract account generally includes Nonce, Balance, Storageroot, CodeHash. Among them, Nonce is the transaction counter of this contract account; Balance is the account balance; Storageroot corresponds to another MPT, and the information related to the contract state can be linked through the Storage root; CodeHash is the hash value of the contract code. Whether it is an external account or a contract account, their account information is generally located in a separate Leaf Node. From the Extension Node / Branch Node of the root node to the Leaf Node of each account, there may be several branch nodes and extension nodes in between.

[0057] Among them, for a contract account in the state trie, its storage_Root points to another tree in the form of MPT, which stores the data of state variables involved in contract execution. The MPT-form tree pointed to by this storage_Root is the Storage Trie, that is, the hash value of the root node of the Storage Trie. Generally, this Storage Trie tree also stores key-value pairs. The key indicates the address of the state variable, and its value can be the result obtained after processing a certain rule on the position where the state variable is declared in the contract (the value starting from 0), for example, it is sha3(the position where the state variable is declared), or sha3(the contract name + the position where the state variable is declared). The value is used to store the value of the state variable (for example, the value encoded by RLP). Part of the data stored on the path from the root node through the intermediate nodes to the leaf nodes is connected to form the key, and the value is stored in the leaf node. This Storage trie can also be a tree in the form of MPT, generally also a 16-way tree, that is, for a Branch Node, it can have at most 16 child nodes, and these child nodes may include Extension Node and / or Leaf Node. For an Extension Node, it generally can have 1 child node, and this child node can be a Branch Node or a Leaf Node.

[0058] For example Figure 4 In the Leaf Node Account P of the state Trie in Figure 4 , this account is a contract account, and its Storage Root locks all the states in the contract storage. These states are organized as an MPT tree, and the tree structure is like the Storage trie linked by this Storage Root. In this linked Storage trie, taking Leaf Node StateVariable N as an example, if it is the value of storedData in the aforementioned contract code example, then its key is sha3(the declared position of storedData, that is, the second line of the code), and its value is s (for simplicity, the encoding format of the value is omitted here, such as RLP, and the same applies later and will not be elaborated). Among them, the values of the keys are distributed in sequence from the root node to the leaf node (that is, Leaf Node Variable N) of the storage Trie.

[0059] The following introduces the technical content related to Rollup.

[0060] The principle of Rollup can be specifically asFigure 4 and Figure 5 ( Figure 5 mainly shown as OP-Rollup in the following text.)

[0061] The transaction for creating a smart contract is sent to Layer1. After the consensus of Layer1, each node on Layer1 can execute this transaction to complete the deployment of the contract. Specifically, it can be executed by the virtual machine of the blockchain node (such as the EVM virtual machine or the WASM virtual machine). Taking EVM as an example, users can publish and call smart contracts in the blockchain system to run on the EVM. After executing the transaction for deploying the smart contract, a contract account corresponding to the smart contract is generated on Layer1. This contract account has an on-chain address and includes balance, nonce, the hash value Codehash of the contract code, and the root Storage_Root of the contract storage. Through Codehash and Storage_Root, the code and account storage of the contract can be saved in this contract account. The behavior of the smart contract is controlled by the contract code, while the account storage of the smart contract saves the state of the contract. In other words, the smart contract makes a virtual account containing contract code and account storage (Storage) generated on the blockchain. Subsequently, the nodes on Layer1 can receive the transaction requests for calling the deployed smart contract. These transaction requests can include the address of the called contract, the functions in the called contract, and the input parameters. Generally, after the consensus of these transaction requests, each node of the blockchain can independently execute the specified called smart contract.

[0062] As Figure 4 shown, a Rollup Contract can be deployed on Layer1 in Rollup. In Layer2, it can receive transactions initiated by users, such as Tx_21, Tx_22, etc. in the figure. A batch of transactions is called a Batch and is executed and updated in order as a whole. As Figure 1 and Figure 4 shown, Batch 1 is assumed to include 3 transactions: Tx_21, Tx_22, and Tx_23, and Batch 2 is assumed to include 3 transactions: Tx_24, Tx_25, and Tx_26. In Layer2, these transactions can be sorted according to a rule and then executed in order. For example, they can be sorted according to the timestamp in the transaction. After the transactions in a Batch are executed in order, the generated state can include several. For example, the transactions in Batch 1 are respectively:

[0063] Tx_21: Alice→Bob 20; indicating that Alice transfers 20 units of assets to Bob;

[0064] Tx_22: Alice -> Charlie 10; It means Alice transfers 10 units of assets to Charlie;

[0065] Tx_23: Bob -> Charlie 10; It means Bob transfers 10 units of assets to Charlie;

[0066] Before the transactions in Batch 1 are executed, assume there are 4 states, which are called the initial states of Batch 1, that is Figure 5 The state values locked by the Pre State Root in it are respectively:

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

[0068] After the transactions in Batch 1 are executed, these 4 states are updated to the final states of Batch 1, that is Figure 5 The state values locked by the PostState Root in it are respectively:

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

[0070] In Layer2, a Merkle tree can be used to organize the states before and after the sequential execution of the transactions in Batch 1. For example Figure 5As shown, in Layer2, a batch of transactions and their related state changes can be organized together. For example, the hash values of the transactions in Batch1 are organized into a Merkle tree, and the resulting Merkle root is locked in the header of the batch. This header is similar to the block header in Layer 1, and this Merkle root is the Tx_Root in the header of the batch. Similarly, as mentioned before, the Merkle root obtained by organizing all the state values of the transactions in Batch1 before execution into a Merkle tree can be locked in the header of the batch, which is the Pre State Root; the Merkle root obtained by organizing the hashes of all the state values of the transactions in Batch1 after sequential execution into a Merkle tree can be locked in the header of the batch, which is the Post StateRoot. In addition, for Batch M, a timestamp can be set in its Header to record the time when the batch is generated. Of course, other field information can also be set. For the (M + 1)-th batch, the Pre State Root in its block header is equal to the Post State Root in the block header of the M-th batch, as Figure 5 represented by the connection between these two roots in

[0071] In this way, a chained structure is formed between batches. The Rollup mechanism in Layer2 can include the following mechanisms: Optimistic-Rollup (abbreviated as OP-Rollup), ZK-Rollup, and TEE-Rollup. In these Rollup mechanisms, the smart contract - Rollup Contract described above is deployed on the blockchain system.

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

[0073] As Figure 5As shown, assume that transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24 are collected in the TxPool. The Sequencer sorts and packages these transactions according to the timestamps in these transactions. For example, Tx21, Tx22, and Tx23 are packaged into Batch M, and the hash values of these transactions are organized into a Merkle tree to generate a Merkle Root, and the hash value of this Merkle Root is filled into Tx_Root in the Header of the generated Batch M. It should be noted that when calculating the root of the Merkle tree, generally for cases less than 2 n , the last transaction can be duplicated multiple times to make up 2 n for calculating the root of the binary Merkle tree. As in Figure 5 , Tx23, which is sorted last in chronological order, is duplicated once to make up 4 transactions, so that the number of transactions reaches 2 2 , and then the root of the binary Merkle tree can be calculated. Similarly, the Sequencer sorts the transactions according to the timestamps in the transactions and packages Tx21, Tx22, and Tx23 into Batch M, which will not be elaborated here.

[0074] 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 this Merkle tree in the Pre State Root field of the Batch M Header. Furthermore, the Sequencer can execute the 3 transactions Tx21, Tx22, and Tx23 in sequence. The results of executing these 3 transactions generate 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 this Merkle tree in the Post State Root field of the Batch M Header.

[0075] Furthermore, the Sequencer can send a transaction 1 that calls the Rollup Contract to Layer 1 through the Relayer. This transaction 1 contains the fields in the Batch M Header and the compressed Tx21, Tx22, and Tx23. After being compressed, the space occupied by Tx21, Tx22, and Tx23 can be greatly reduced. The interfaces in the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, Tx23) at a cheaper location (lower Gas fee) called calldata. In the smart contract of the blockchain system, calldata is a special data location used to store the input data passed through function calls. Specifically, calldata data is generally directly stored in the transaction data of the blockchain system, and it usually saves more gas than other data locations (such as memory and storage).

[0076] Regarding compression, the size of a simple blockchain system transaction (sending ETH) is approximately 110 bytes, while for ETH transfers on Rollup, in the current design, the size can be reduced to approximately 12 bytes after maximum compression. The following table shows the volume occupied by each field (parameter) of a transaction in the blockchain system and each field of a transaction in Rollup in an example:

[0077] Parameter Blockchain System (Bytes) Rollup (Bytes) 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 (Recovered from Signature) 4 Total ～112 ～12

[0078] The implementation details of compression are omitted here. It should be noted that in a blockchain system transaction, the signature part accounts for approximately half of the overall volume, and its From field can be 0 bytes because the From field can be recovered from the signature. In Rollup, BLS aggregation can be used, and the signature of each transaction is compressed to approximately 0.5 bytes on average. Correspondingly, since the From field of the transaction cannot be recovered from this aggregated signature in the Rollup transaction, 4 bytes are separately used to represent it here.

[0079] In cryptography, public-key cryptography, also known as asymmetric cryptography, is a type of cryptography that 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 one private key. Public-key cryptography includes encryption algorithms and digital signature algorithms. The public-private key pair is the cornerstone of modern cryptographic security, and many applications are based on pk-sk, such as the application layer encryption transfer protocol based on https (Hypertext Transfer Protocol Secure) and blockchain, etc.

[0080] A private key usually represents the identity of the party that owns 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 made public. A signature made with a private key can indicate the approval of a certain piece of information in the digital world by the owner of the private key. The signed information can also represent a certain action of the private key owner in the protocol message. Generally, if an owner has a single private key, the owner can sign a certain piece of information with their own private key and send it to other parties. After receiving this signature, the receiving party can verify the signature using the corresponding public key. If the verification passes, the receiving party can confirm that the owner signed the information and that the signed information has not been tampered with.

[0081] The BLS signature scheme was initially proposed by Professor Dan Boneh of Stanford University and others in 2001. It is a signature scheme constructed based on bilinear mapping. Generally, a user's control over their own account is reflected in signing a transaction with their own private key. As shown in the above table, a single signature can be up to 68 bytes, taking up a relatively large volume. For multiple transactions initiated by multiple accounts, each account needs to sign each of its own transactions separately. Signature aggregation, however, can combine multiple signatures into one signature, thus greatly saving the byte space of the signature. This aggregation can be the aggregation of signatures of the same message by different signers, or the aggregation of signatures of different messages. Public key aggregation can combine multiple different public keys into a total public key, and this total public key can be used to verify the aggregated signature, without the need for each public key to participate in the calculation when verifying the total signature. Usually, the Schnorr signature algorithm and the BLS signature algorithm can be used to achieve signature aggregation. Compared with the Schnorr signature algorithm, the aggregated signature implemented by the BLS signature algorithm has a smaller volume, about half of that of Schnorr.

[0082] The above compression scheme and signature aggregation using BLS are ideal design schemes. Nevertheless, in several current Rollup schemes in practice, a compressed transaction still occupies 40 - 50 bytes of space, and this does not include the signature, that is, BLS signature aggregation has not been adopted yet.

[0083] Continuing from the previous text, after receiving Transaction 1 that calls the Rollup Contract in Layer 1, through consensus, this Transaction 1 is executed on some nodes, and Transaction 1 and its execution result, together with some other transactions and execution results, are combined to generate a block, as Figure 5Block N in it. Some of the other transactions can include ordinary transfer transactions and transactions involving other smart contracts. Among them, both ordinary transfer transactions and transactions involving other smart contracts can involve the execution of transactions. In particular, transactions involving other smart contracts may involve relatively complex execution logic. And Transaction 1 here calls the function stored in the calldata position in RollupContract, mainly involving storing in a specified position, that is, not involving the execution of complex contract logic. That is to say, the main function of the Rollup Contract in Layer1 is to store the specified content in the transactions sent from Layer2 in the specified position, and does not involve complex execution logic. For example, as an example, Tx21, Tx22, and Tx23 are stored in Tx_12 locked to the transaction tree by Tx_Root in Block N Header. In addition, as an implementation, the Pre State Root and Post State Root in Batch MHeader in Transaction 1 can be stored in State 1 and State 2 in the contract state on Layer1 through Rollup Contract respectively. As mentioned above, State 1 and State 2 are included in the state trie locked by State_Root in Block NHeader, specifically, for example, in the storage trie. For the sake of distinction, State 1 and State 2 in the contract state on Layer1 are called Last State root and Current State root respectively, for example. In addition, for simplicity, only Current State root can be saved in the contract state on Layer1, and Last State root is not saved, as shown in the following code example. In some other implementations, Last State root and Current State root can also be stored in the calldata in Layer1 in the same way as the transactions in Layer2, which will not be elaborated here. For the former, for example, call the commitBatch() contract interface in Layer1 as follows:

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

[0085] Inside the CommitBatch() contract interface, basic verification logic can be set. For example, it includes verifying whether the Pre State Root in the current transaction 1 is equal to the Current State Root in the contract storage. If they are equal, the Layer 2 transactions passed in transaction 1 are stored in the calldata, and the Current State Root in the contract storage is updated to the Post State Root. The sample code is as follows:

[0086]

[0087] In the above way, OP-Rollup can execute each transaction in Layer 2 and bundle dozens, hundreds, or even more Layer 2 transactions in a Batch, and only publish the minimum amount of information to Layer 1. The so-called minimum amount of information includes the compressed Layer 2 transactions as mentioned above and the hash values of the state roots before and after the execution of this batch of transactions. As shown before, for example, it can be sent through a transaction on Layer 1, such as Figure 5 transaction 1 in. It can be seen that this is equivalent to executing a batch of transactions on Layer 2 at one time, but only one transaction is executed on Layer 1. At the same time, OP-Rollup does not attach any proofs. This is because it is assumed that there is no fraud or malicious behavior in the information submitted on Layer 2, so it has the name "Optimistic". Although there is such an assumption, for prevention and deterrence, traders submitting Layer 2 information are still required to pledge a part of the assets on Layer 1 (typically the native token on the chain) in the Rollup Contract of OP-Rollup. Although OP-Rollup is optimistic, a challenge period can still be set on Layer 1, and anyone can use fraud proofs to raise challenges during the challenge period. Typical reasons include that the challenger proves that a certain transaction in the Batch was not executed correctly, that is, the execution of this transaction did not produce the correct state. If a certain transaction in a Batch is proven to be invalid, then the Batch is also invalid, and this Rollup contract on Layer 1 can roll back the Layer 2 Batch chain in it, and this invalid Batch and all subsequent Batches will become orphan blocks. Once the fraud proof is successful, a part of the margin will be paid to the challenger, and the remaining part will be destroyed. On the contrary, if no one submits a fraud proof until the end of the challenge period, the Rollup contract can determine this Batch.

[0088] Overall, due to the design of OP-Rollup which requires all data related to state updates and validations to be placed on Layer 1, the scalability of OP-Rollup and the degree of throughput improvement are the most limited, and a waiting period of 7 days or even longer is required. This means that there will be a delay in withdrawing assets from OP-Rollup and one has to wait until the window period has passed.

[0089] Different from Optimistic Rollup, ZK-Rollup uses zero knowledge prove (ZKP) technology. ZK refers to the ability to prove something (a transaction or a state) to another party without disclosing the necessary information. Zero knowledge prove (ZKP) technology may include zero knowledge prove circuits which transform complex computational problems into circuit models and achieve a privacy-protected verification process through a constraint system. Among them, the matrix structure recording the operation steps in the ZKP system serves as the operation trace (Trace), and a verifiable proof trace is generated based on this operation trace.

[0090] In ZK-Rollup, similar to OP-Rollup, Tx21, Tx22, and Tx23 are packed into Batch M, and the hash values of these transactions are organized into a Merkle tree to generate a Merkle Root. The hash value of this Merkle Root is filled into Tx_Root in the Header of the generated Batch M, and Pre State Root, Post State Root, Timestamp, etc. are generated and filled into the Batch M Header. Moreover, a proof (including proof) (such as a cryptographic proof algorithm like ZK-SNARK) is generated for this batch in Layer 2. The proof in this proof can prove that the PostState Root is obtained by correctly executing the transactions in the batch in sequence based on the Pre State Root. One only needs to verify the proof to confirm this, rather than re-executing the transactions in the Batch for verification.

[0091] Before generating a proof, a computing circuit can be created. This circuit is actually a specific algorithm that can be pre-written for the logic of verifying transactions and states. This pre-writing process includes generating a Proving Key and a Verifying Key through a process called trusted setup. The created circuit can be set in a proposer (or prover) on Layer 2. It should be noted that the circuit created for the logic of verifying transactions and states is bound to its Proving Key and Verifying Key. Both the Proving Key and the Verifying Key can be made public and are bound to the circuit.

[0092] The process of generating a proof can be that the Sequencer packs all the transactions (including the sender, receiver, and amount) in a Batch on Layer 2, as well as information such as the Pre State Root, Post State Root, and Proving Key before and after the execution of the transactions in this Batch, and sends them to a prover on Layer 2. The prover converts this information into a special form called a witness (selecting a part of it as public input and another part as private input). Then, the prover uses the zero-knowledge proof computing circuit (a specific algorithm) arranged inside it to verify the validity and correctness of the public input + private input. If the verification is correct, the circuit execution is successful; otherwise, the circuit execution fails. When the circuit execution is successful, the prover can output a proof, which is used to prove that the packed data is valid and correct. Moreover, the size of this proof is relatively small, usually only dozens of bytes. The above process of generating a proof is similar to the process of re-execution and involves a large number of circuit calculations, making it more complex and generally time-consuming.

[0093] It should be noted that the private input cannot be deduced from the proof itself. Only the party that knows the verification key of zk-SNARK can verify the proof encrypted with the corresponding creation key. The public input can be used to verify the validity and correctness of the packed data, but cannot be used to obtain the specific content of the packed data.

[0094] By using zero-knowledge proofs, the prover can publish smaller proofs to Layer 1 through the Relayer and they can be quickly verified by the Rollup Contract. The small size of the proofs further reduces the Gas consumption on Layer 1. Moreover, in ZK-Rollup, this verification process is usually automatically completed by smart contracts without the need to set a window period as in OP-Rollup, and asset extraction also becomes rapid, which is one of the main characteristic differences between OP-Rollup and ZK-Rollup.

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

[0096] However, zero-knowledge proofs such as ZK-SNARK have a very large amount of computation during the proof generation process, which also means that generating proofs will be time-consuming. Suppose as Figure 6 shown, through Transaction 1, the compressed Tx21, Tx22, and Tx23 are deposited into the calldata on Layer 1, and the Post State Root is deposited into the Current StateRoot in the contract state on Layer 1. This Transaction 1 is Figure 6 located in Block N on Layer 1. Then, the delay caused by the complex computation required to generate the corresponding proof in Layer 2 may be that, after a period of time, the proof of Batch M is passed into Block N+412 on Layer 1 through Transaction 2. From Block N to Block N+412, obviously, a certain delay is also brought, and this delay may be close to the hour level.

[0097] Regarding the problems of complex calculations and long time required to generate proofs, the main solutions in the current industry mainly include achieving them through large-scale parallelized proofs in engineering or accelerating through hardware optimization. However, this is not easy. The implementation of circuits is relatively complex, and without the support of high-level languages, in many cases, R1CS (a common form in circuits) is handwritten.

[0098] Furthermore, in order to utilize the ZK proof system and optimize the implementation of circuits, the entire state of Layer 2 is often optimized into a circuit-friendly structure (Merkle tree). Therefore, the ZK-kRollup system needs to consider the circuit structure, which restricts Layer 2 transactions and the account model. In ZK-Rollup, solutions such as zksync, zkswap, and loopring only implement specific transaction scenarios, and it is even more difficult to be compatible with the blockchain system virtual machine and support Turing completeness. That is to say, it is very difficult to support relatively complex contracts.

[0099] In TEE-Rollup, the architectures relied on at Layer 2 are as Figure 7 shown. Here, it includes at least Relayer, TxPool, Sequencer, and Prover. As mentioned before, the main role of the Relayer is to submit transactions or operations on Layer 2 to Layer 1, that is, to act as a bridge between Layer 1 and Layer 2. It can include submitting user transactions on Layer 2 packed by the Sequencer to Layer 1, and submitting the proofs generated by the Prover on Layer 2 to Layer 1. Of course, the Relayer can also be excluded, and instead, the Sequencer submits the packed user transactions on Layer 2 to Layer 1, and the Prover submits the generated proofs to Layer 1. In fact, the latter integrates the functions of the Relayer into the Sequencer and Prover. For simplicity, the role of the Relayer in the entire solution will not be emphasized subsequently.

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

[0101] The Sequencer pulls transactions from the TxPool, sorts and packs these transactions according to the timestamps in the pulled transactions, organizes the hash values of these transactions into a Merkle tree to generate a Merkle Root, and fills the hash value of this Merkle Root into Tx_Root in the Header of the generated Batch M. For example Figure 7As shown in the figure, Tx21, Tx22, and Tx23 are packaged into Batch M. After sorting them in chronological order, Tx23, which is the last one, is repeated once to complete 4 transactions, and then the root of the 2-ary Merkle tree is calculated. Moreover, the Sequencer sequentially executes the 3 transactions of Tx21, Tx22, and Tx23 based on the pre-execution state of the transactions in Batch M. As a result of executing these 3 transactions, a new state is generated. The Sequencer organizes the pre-execution state into a Merkle tree and stores the hash value of the root node of this Merkle tree in the PreState Root field of the Batch M Header. It also organizes the state after the execution of the transactions in Batch M into a Merkle tree and stores the hash value of the root node of this Merkle tree in the Post State Root field of the Batch M Header.

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

[0103] TEE is a trusted execution environment based on the security extension of the CPU hardware and completely isolated from the outside. Currently, the industrial community pays great attention to TEE solutions. Almost all mainstream chip and software alliances have their own TEE solutions, such as TPM (Trusted Platform Module) on the software side and SGX (SoftwareGuard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor) on the hardware side. TEE can act as a black box. The code and data executed in TEE cannot be peeked even by the operating system layer, and it can only be operated through the interfaces predefined in the code. In terms of efficiency, due to the black box nature of TEE, the data being calculated in TEE is plaintext data, rather than the complex cryptographic operations in homomorphic encryption, and there is almost no loss in the calculation process efficiency. Therefore, adopting TEE technology can largely meet the trusted computing requirements in the blockchain scenario with relatively little performance loss.

[0104] The TEE prover verifies the first transaction root and the first pre-state root; after both verifications pass, based on the initial state, the packaged transactions are executed in order 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 transactions is signed, and the signature is sent to the main network as a proof through the second main network transaction.

[0105] The prover verifies the first transaction root, including: the prover generates a second transaction root for the packaged transactions, and verifies 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 and then generate a Merkle Root, that is, organize the hash values of these transactions into a Merkle tree in the same way as the Sequencer and then generate a Merkle Root, and this Merkle Root 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.

[0106] The prover verifies the first pre-state root, including: the prover generates a second pre-state root for the initial state, and verifies 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 according to the Merkle tree and generate a Merkle root, that is, 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.

[0107] In one implementation, the prover can verify the first pre-state root based on the SPV proof.

[0108] Specifically, assume that as Figure 7 shown, the transactions in Layer 2 (including ordinary transfer transactions and transactions involving contracts) involve a total of 8 states, such as Figure 7 the 8 states corresponding to the 8 hash values 8, 9, 10, 11, 12, 13, 14, and 15 in the lower left corner. And assume that the transactions packed into Batch M, when executed in order, affect the states of Alice and Bob corresponding to 8 and 9, and do not involve the 6 states corresponding to the 6 hash values 10, 11, 12, 13, 14, and 15. As Figure 7 shown, in this way, what changes after the transactions packed into Batch M are executed in order are the balances of Alice and Bob, and the balances of Charlie and David do not change (that is, the hash values of the two tree nodes 10 and 11 do not change, and the content corresponding to the two nodes 10 and 11 is shown here; the content corresponding to 12, 13, 14, and 15 also does not change, and its content is omitted here).

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

[0110] AsFigure 7 In the example in , the sorter may send the states corresponding to tree nodes 8 and 9, as well as the SPV proof composed of the hash value of node 5 and the hash value of node 3, to the prover in the second-layer network. In this way, it is possible to avoid sending the states corresponding to the 6 leaf nodes 10, 11, 12, 13, 14, and 15 to the prover.

[0111] The full name of SPV is Simplified Payment Verification, that is, simple payment verification. The SPV proof uses a Merkle tree to work. Here, the states involved in Batch M form a Merkle tree, and the root of the tree (i.e., the Merkle root) is included in the Header of Batch M. The structure of the Merkle tree enables the verification of whether any state exists under a specific Merkle root through a very short path (the Merkle path). This path only contains some necessary nodes, rather than the state content corresponding to all leaf nodes.

[0112] As Figure 7 shown in the example in , an SPV proof includes the states corresponding to two leaf nodes (shown in yellow), as well as the Merkle path (shown in red).

[0113] The Merkle involved in the Merkel path in the SPV proof is a tree-like data structure, which can be a binary Merkle tree, or the above-mentioned MPT tree, and can also be an SMT, etc.

[0114] The prover verifies the first previous state root based on the SPV proof, specifically including: the prover calculates the Merkle root based on the read set of the SPV proof and the Merkle path to obtain the second previous state root, and verifies whether the second previous state root is equal to the first state root. If they are equal, it means that the first previous state root sent by the prover is correct. The characteristic of hash calculation: a small change in the value in each calculation will cause a large difference in the final result. Based on this characteristic, it is impossible for the prover to forge, that is, it is impossible to produce a correct result on the basis of providing the state in the wrong leaf node or the hash value of the wrong Merkle tree node, that is, it is impossible to produce a correct Merkle root. Specifically, the prover can calculate Figure 7The hash value of the content corresponding to the node 8 in the lower left corner is used as the value of node 8, and the hash value of the content corresponding to node 9 is calculated as the value of node 9; the two hash values of node 8 and node 9 are, for example, concatenated in sequence and then the hash value is calculated again using the same hash algorithm as the hash value of node 4; the hash value of node 4 and the hash value of node 5 in the SPV proof are, for example, concatenated in sequence and then the hash value is calculated again using the same hash algorithm as the hash value of node 2; the hash value of node 2 and the hash value of node 3 in the SPV proof are, for example, concatenated in sequence and then the hash value is calculated again using the same hash algorithm as the hash value of node 1, that is, as the second previous state root, so as to verify whether the second previous state root is equal to the first previous state root.

[0115] 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, it means that the first transaction root and the first previous state root sent by the Sequencer are correct, and then the subsequent content can be executed.

[0116] The prover can execute the packaged transactions in sequence based on the initial state sent by the Sequencer, generate the updated state, and organize these updated states into a Merkle tree, so as to obtain the hash value of the Merkle tree root node of the updated state, that is, the second subsequent state root. Furthermore, the prover can verify whether the second subsequent state root is equal to the first subsequent state root. If they are equal, it means 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.

[0117] In this way, the prover verification can sign the information of the packaged transaction. Specifically, the prover verification can sign at least one of the Batch number of the packaged transaction, the transaction root of the packaged transaction, and the Post State Root corresponding to the packaged transaction. Signing at least one of these contents indicates the prover's recognition of the results generated by the Sequencer for executing this Batch.

[0118] As mentioned above, the private key usually represents the identity of the party that owns the private key. It can only be held by the owner of the private key and cannot be made public, while the corresponding public key can be made public. A signature made with the private key can indicate the approval of the owner of the private key for certain information in the digital world. The signed information can also represent a certain action of the owner of the private key in the messages of the protocol. Generally, if an owner solely owns a private key, the owner can sign a piece of information with their own private key and send it to other parties. After receiving this signature, the receiving party can verify the signature using the corresponding public key. If the verification passes, the receiving party can confirm that the owner signed the information and that the signed information has not been tampered with.

[0119] The prover can be implemented using a TEE. The TEE has a trusted execution environment that is completely isolated from the outside world, so it can hold the private key in a confidential manner. In this way, after the prover verifies that the above-mentioned second post-state root is equal to the first post-state root, it can sign the information of the packaged transaction with its own private key to indicate approval of the signed content.

[0120] In addition, after the prover signs the information of the packaged transaction, other verifiers can also act as challengers to challenge the TEE in the prover to verify whether the TEE is trustworthy. Moreover, the TEE can sign the hash of 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 result of the execution), also using its own trustworthiness to guarantee that the executed input is also trustworthy.

[0121] In this way, after the TEE prover verifies and independently executes (which can also be called replaying) the packaged transaction in order based on the initial state, it signs the information of the packaged transaction, which is to use its own trustworthiness to guarantee that the output result is trustworthy. Furthermore, the prover can send the signature as a proof to the main network through the second main network transaction. If anyone questions this signature, they can verify it by challenging the TEE in the prover.

[0122] Through the mechanism of the TEE, the CPU can process data in the Enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency. This is much faster than the ZK-Rollup method. For example, in the same situation, the time required for ZK-Rollup to generate a proof is in the order of 30 - 50 minutes (or an hour level) ( Figure 6 from Block N to Block N+412 in []) is shortened to the order of 5 - 10 minutes (e.g., from Block N to Block N+62). And the generated proof is the size of a signature, about dozens of bytes, similar to ZK-Rollup.

[0123] The verification of the signature is a process of verifying the signature using the public key of the TEE. As long as the public key is guaranteed to be trustworthy, this verification will also be trustworthy and fast. The prover can send the signature as a proof to the main network through a second main network transaction, including the prover sending the signature as a proof to the main network through a second main network transaction and invoking the rollup contract on the main network; after receiving the transaction, the rollup contract verifies the correctness of the signature through the verification logic in the contract.

[0124] To improve the efficiency and backward security of Layer 2, an embodiment of this specification provides an architecture of Layer 2. As Figure 8 shown, Layer 2 includes a Sequencer, a Relayer, a trajectory generation module, and a proof module. Among them, the Sequencer includes an access service, a controller, a transaction processor, and a storage device (Storage). The access service can receive transactions from users and place the transactions in the transaction pool. The controller can include an ordering unit (Ordering), a batching unit (Batching), and a committing unit (Commiting). The ordering unit can obtain a batch of multiple transactions (Batch) from the transaction pool and sort the multiple transactions according to a preset rule (such as in the order of the transaction reception time). The batching unit can call the transaction processor to sequentially execute the multiple transactions. After completing the execution of the multiple transactions, the committing unit obtains the execution results of the multiple transactions, feeds back the execution results of the transactions to the users, updates the state tree in the storage device and stores the multiple transactions and the header (Header) data of the Batch, and provides the relevant execution information of the multiple transactions to the Relayer and the trajectory generation module for submitting the Batch to Layer 1 and generating a proof of the packaged transaction through the proof module. Among them, the state tree stored in the storage device can be similar to the state tree stored in the blockchain node, records the account status of each account in Layer 2 in the form of a Merkle tree, and generates the state root of the state tree. Similar to the accounts in the blockchain system, the accounts in Layer 2 can include external accounts and contract accounts. Correspondingly, the state tree can include a storage tree corresponding to the contract, and the storage tree records the variable values of each state variable. For example, in Layer 2, there can be a contract C1 for processing RWAs corresponding to each external account, and the asset balance of a specific type of RWA corresponding to each external account is stored in the contract state of the contract C1. The specific structures of the state tree and the storage tree in Layer 2 can refer to Figure 3 the state tree and the storage tree shown in

[0125] The proof module may include a ZK prover and a TEE prover. The TEE prover can generate a TEE proof at a relatively fast speed and store the TEE proof in Layer1. The ZK prover can generate a ZK proof with high security and store it in Layer1. In Layer1, cross-verification based on the TEE proof and the ZK proof improves the backward security of Layer2.

[0126] The following references Figure 9 to describe the flowchart of the method for implementing a two-layer network rollup in the embodiments of this specification.

[0127] As Figure 9 shown, in step S901, the sequencer of the two-layer network pulls transactions from the transaction pool, sorts the pulled transactions to obtain packaged transactions, sequentially executes the packaged transactions based on the initial state before the execution of the packaged transactions to obtain the execution results of each transaction, feeds the execution results back to the corresponding users, and generates a first post-state root corresponding to the packaged transactions; sends the basic execution information of the packaged transactions to the trace generation module of the two-layer network.

[0128] Among them, the basic execution information of the packaged transactions may include the transaction body of the packaged transactions, the transaction arrangement order, the initial state, and the first pre-state root and the first post-state root corresponding to the initial state.

[0129] Referring to Figure 8 , similar to the description of OP-Rollup above, the access service in the Sequencer can receive transactions from each user and deposit the transactions into the transaction pool. The transactions in the transaction pool include, for example, Tx21, Tx23, Tx25, Tx22, Tx26, Tx24, etc. The Sequencer may include a preprocessing module ( Figure 8 not shown in the figure), and the preprocessing module can preprocess each transaction in the transaction pool (such as pre-execution) to generate the read-write sets of each transaction for subsequent parallel grouped execution of the transactions.

[0130] Ordering can obtain a batch of transactions from the transaction pool. This batch of transactions includes, for example, Tx21, Tx22, and Tx23. It can be understood that three transactions are shown as an example for a batch of transactions, and the number of transactions in a batch is not limited in the embodiments of this specification. At the same time, Ordering can also obtain the read-write sets of each transaction in this batch of transactions from the preprocessing module. After obtaining this batch of transactions, Ordering can sort this batch of transactions according to a preset rule, and record the transaction information of this batch of transactions. The transaction information may include a batch identifier (or number), the transaction body of each transaction, the sorting of multiple transactions, etc. Then, Ordering sends this batch of transactions (or packaged transactions) and their read-write sets to Batching, and Ordering can also send the transaction information of this batch of transactions to Batching together.

[0131] Batching can group the multiple transactions according to the order of each transaction in the packaged transaction and the read-write sets of each transaction, and execute the multiple groups of transactions by calling the transaction processor. In addition, Batching can also record the grouping information of the multiple transactions in the transaction information. In addition, Batching can send the transaction information to Commiting.

[0132] The transaction processor can execute multiple groups of transactions in parallel through multiple virtual machines to quickly complete the execution of the packaged transaction. When executing each transaction, the virtual machine can read the corresponding state value (i.e., the initial state) from the state tree of the storage device and compare it with the read set. If the read set includes this state value, the transaction is executed based on the read initial state. Otherwise, it means that the read set of this transaction is incorrect, and the grouping of this transaction is also incorrect. Therefore, this transaction can be deleted from the packaged transaction and put back into the transaction pool to be repackaged and executed. In one implementation, the transaction processor may include a zk loop unit, which is used to record the total number of bytecodes included in this batch of transactions for evaluating the circuit scale of the subsequent zk circuit.

[0133] After the transaction processor completes the execution of the packaged transaction, it obtains the write sets and receipts of each transaction, and sends the write sets and receipts of each transaction to Commiting. The transaction processor can also send the updated transaction grouping information and the total number of bytecodes to Commiting.

[0134] After receiving the write sets and receipts of each transaction, Comitting can immediately feedback the execution results of each transaction to the corresponding user. The execution results include, for example, transaction receipts or information such as whether the transaction was executed successfully. By doing so, Comitting in the Sequencer can complete the execution of a transaction within a few hundred milliseconds and feedback the execution results to the user, achieving real-time feedback of execution results and improving the user experience.

[0135] Comitting can generate a new state tree corresponding to the packaged transaction based on the write sets of each transaction and store it in the storage device. This state tree includes a state root (hereinafter referred to as the first post-state root). Comitting also generates, for example, a Batch M Header based on the state root of the previous batch of transactions (i.e., the first pre-state root) and the first post-state root, and stores the Batch M Header, the transaction data and receipt data corresponding to the Header, etc. in the storage device. Subsequently, Comitting can generate basic execution information, which includes the packaged transaction (including the transaction body and transaction arrangement order of multiple transactions), the initial state read when executing this batch of transactions, the first pre-state root (i.e., the state root of the state tree corresponding to the previous batch of transactions), and the first post-state root, and send this basic execution information to the trajectory generation module. In one implementation, Comitting can also add the updated grouping information and the zk circuit scale to the basic execution information and send it to the trajectory generation module. Among them, the zk circuit scale is determined based on the total number of bytecodes mentioned above.

[0136] In one implementation, Ordering, Batching, and Comitting in the Sequencer process multiple batches of transactions in a pipeline manner and send the basic execution information of multiple batches of transactions to the trajectory generation module.

[0137] In one implementation, as Figure 8 shown by the arrow marked "Submit Batch" in, the Sequencer can send the Batch information related to this Batch to the Relayer to send a main network transaction Tx1 that invokes the Rollup Contract to Layer1 through the Relayer. The main network transaction Tx1 contains each field in the Batch M Header and the compressed Tx21, Tx22, Tx23, etc., to be used to mention the execution information of this batch of transactions (Batch) to Layer1.

[0138] Among them, the content of transaction Tx1 includes, for example, a from field, a to field, a value field, and a data field. The from field can be the account address of the transaction initiator (the main network external account address of the Sequencer / Relayer), the to field can represent the address of the smart contract to be called, the value field can be the native token on the blockchain, 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 can indicate a call to a certain smart contract on the blockchain. Generally, a smart contract can include one or more functions, and each function can include some input parameters. In the transaction, a certain function in the smart contract to be called can be specified through the data field, and the parameters to be passed in are filled in the data field. The data field can specify the call to the commitBatch() contract interface. In this way, when the Rollup Contract is executed normally, the compressed Tx21, Tx22, and Tx23 in the main network transaction Tx1 can be stored in the calldata, and the Current State Root in the contract storage can be updated to the Post State Root and the parameters are passed in.

[0139] In the main network (Layer1), the Rollup Contract can be executed in a virtual machine (such as the Ethereum Virtual Machine, EVM), or of course, it can also be executed in a container (such as docker), which is not limited here. The result of the contract execution can, on the one hand, change the storage of the contract, that is, the world state of the contract, and on the other hand, the execution result or related information of the transaction can be recorded in the receipt of the blockchain. Specifically, the contract execution result / related information can be manifested as an event in the receipt. The structure of the event is, for example, in the following format:

[0140] Event:

[0141] [topic][msg]

[0142] [topic][msg] ......

[0144] In the above example, the number of events can be one or more. Each event can include fields such as a topic and data. The format of the events output during transaction execution can be specified in the contract. Through the built-in SDK, a blockchain client or a blockchain node can listen for events of a specific topic, and when an event of a specific topic is detected, pull the content of the corresponding msg, and can also execute a preset process after detecting certain content in the specific topic or the corresponding msg.

[0145] Through this event mechanism, the blockchain nodes on the mainnet can store the execution results in the msg corresponding to a certain topic, so that the Prover / Relayer can listen for this topic through its built-in blockchain client, and thus can obtain the corresponding execution results. Here, for example, the mainnet transaction Tx1 has been successfully executed on the mainnet Rollup Contract.

[0146] In step S903, the trace generation module sequentially executes the packaged transactions based on the initial state to obtain the execution trace of the packaged transactions, and provides the basic execution information and the execution trace to the proof module.

[0147] After receiving the basic execution information, the trace generation module can first read the SPV proofs of each initial state from the state tree in the storage device and add the SPV proofs to the basic execution information. Then, the trace generation module can store the basic execution information in the TraceDB corresponding to the batch of the packaged transactions.

[0148] The trace generation module can also re-execute the packaged transaction based on the initial state through the virtual machine it includes, so as to obtain the execution trace of the packaged transaction.

[0149] The execution trace is the core prerequisite for generating zero-knowledge proofs (such as zk-SNARKs / STARKs). The execution trace needs to completely record every step of the state change when executing the transaction in the Layer2 virtual machine, so as to verify its legality through mathematical constraints. Specifically, the execution trace is a sequence of full-state snapshots when running the transaction in the Layer2 virtual machine, including:

[0150] The input and output of each instruction (such as ADD, JUMP, SSTORE) executed by the virtual machine when running the transaction;

[0151] The state of the stack / registers of the virtual machine, including the stack content and the intermediate values of the registers during the execution process;

[0152] And the state changes before and after the transaction execution.

[0153] The execution trace can be used to construct a mathematical constraint system in the ZK prover to prove that the state changes of the packed transactions all comply with the preset rules.

[0154] After generating the execution trace corresponding to the packed transaction, the trace generation module can store the execution trace in the trace database (TraceDB) corresponding to the batch of the packed transaction. In the case where the Sequencer executes multiple batches of packed transactions in a pipelined manner, the trace generation module can correspondingly generate execution traces for multiple batches of packed transactions in a pipelined manner and store the execution traces corresponding to each of the multiple batches of packed transactions in the TraceDB.

[0155] Figure 10 This is a schematic diagram of the process of processing multiple batches of transactions in a pipelined manner in the Layer2 of the embodiments of this specification. As Figure 10 shown, assume that Batch M, Batch M+1, and Batch M+2 are three consecutive batches of packed transactions processed in the Layer2. At time period t1, the Ordering unit starts to obtain multiple transactions corresponding to Batch M from the transaction pool and sort the multiple transactions. At time period t2, the Ordering unit sorts Batch M+1. At the same time, the Batching unit executes the transactions of Batch M. At time period t3, the Ordering unit sorts Batch M+2. At the same time, the Batching unit executes the transactions of Batch M+1, and the Commiting unit commits Batch M. At time period t4, the Batching unit executes the transactions of Batch M+2, the Commiting unit commits Batch M+1, and the trace generation module generates an execution trace for Batch M. And so on, the operations of each unit in Figure 10 time periods t5 and t6 can be obtained similarly. Through this pipelined manner, multiple processes or threads can process multiple batches of packed transactions in parallel at the same time, improving the transaction execution speed in the Sequencer, and thus accelerating the speed of feedback to the user.

[0156] When the proof module needs to generate a proof corresponding to the packed transaction, the trace generation module can provide the basic execution information and the execution trace corresponding to the packed transaction to the proof module.

[0157] In the embodiments of this specification, by independently generating the execution trace of the bundled transaction through the trace generation module, on the one hand, the computational cost of the transaction processor in the Sequencer can be reduced, so that the transaction processor does not need to generate the execution trace, accelerating the speed of feedback of the transaction execution result to the user. On the other hand, the execution trace of the bundled transaction can be pre-generated for the proof module to use. The ZK prover does not need to re-execute the bundled transaction after determining that the batch information is uploaded to Layer 1 for generating the execution trace, thereby accelerating the speed of the proof module generating the proof and overall improving the transaction processing efficiency of Layer 2.

[0158] In step S905, the TEE prover generates a TEE proof based on the bundled transaction, the initial state, the first pre-state root, and the first post-state root, and uploads the TEE proof to the rollup contract of the mainnet through the mainnet transaction Tx2.

[0159] As described above, after the proof module listens to the corresponding topic in the mainnet, it can determine that the transaction Tx1 that previously called the mainnet Rollup Contract has been executed on the mainnet. In this way, the provers (including the TEE prover and the ZK prover) in the proof module can verify the batch of bundled transactions after determining that the bundled transaction has been submitted to the mainnet, thus avoiding verification in the case where the mainnet transaction Tx1 has not been executed on the mainnet due to certain reasons, such as the mainnet transaction Tx1 not being sent successfully, or the verification of the mainnet transaction Tx1 itself by the mainnet Rollup Contract failing, etc.

[0160] Specifically, after the proof module determines that the bundled transaction has been submitted to the mainnet, it can pull the basic execution information and the execution trace corresponding to the batch of bundled transactions from the trace generation module. It can be understood that the proof module can also read the basic execution information and the execution trace corresponding to the batch of bundled transactions before determining that the bundled transaction is submitted to the mainnet.

[0161] Referring to the description of TEE Rollup above, the TEE prover verifies the transaction root of the bundled transaction and the first pre-state root. Among them, in one implementation, the prover can verify the first pre-state root based on the SPV proof. After passing the verification, the bundled transaction is executed in sequence based on the initial state to generate a second post-state root. After verifying that the second post-state root is equal to the first post-state root, the information of the bundled transaction is signed, and the signature is sent to the mainnet as the TEE proof through the mainnet transaction Tx2. In one implementation, in the TEE prover, multiple groups of transactions can be executed in parallel by the TEE cluster based on the transaction grouping information in the basic execution information to improve the proof generation speed.

[0162] Among them, the main network transaction Tx2 calls the Rollup contract. After the blockchain nodes in the main network execute the transaction Tx2, they verify the correctness of the signature and the legality of the TEE certificate through the verification logic in the Rollup contract. The TEE certificate includes the public key of the TEE prover.

[0163] The verification of the legality of the TEE certificate may specifically include:

[0164] Using the authoritative public key to verify the legality of the TEE prover certificate; or,

[0165] Using the authoritative public key to verify the legality of the certificate of the authentication service, and using the public key in the certificate of the authentication service to verify the legality of the prover certificate.

[0166] After the verification passes, the main network blockchain node can store the TEE proof corresponding to the identifier of the batch of packaged transactions into the contract state of the Rollup contract.

[0167] In this stage, based on the TEE trust root and trust chain mechanism, after the TEE prover verifies the execution result, it generates a signature for the transaction information of the batch of packaged transactions as the TEE proof, can determine the correctness of the execution result within seconds, and pushes the TEE proof to the main network.

[0168] In step S907, the ZK prover generates a ZK proof based on the execution trace, the first pre-state root, and the first post-state root, and uploads the ZK proof to the Rollup contract of the main network through the main network transaction Tx3. The first proof and the second proof are used to jointly determine whether the packaged transaction is correctly executed.

[0169] Referring to the above description of ZK Rollup, based on a specific zero-knowledge proof algorithm, the ZK prover can convert the execution trace into a mathematical proof constraint, and generate a verifiable ZK proof based on this mathematical proof constraint. Among them, in the case where the circuit scale of the zero-knowledge proof circuit is included in the above basic execution information, the ZK prover can set the corresponding zero-knowledge proof circuit according to this circuit scale. This ZK proof can be used to prove that the first post-state root is obtained by correctly executing the transactions in the packaged transaction in order based on the first pre-state root. It only needs to verify the ZK proof to confirm this, without having to re-execute the batch of packaged transactions for verification.

[0170] The ZK prover can send the ZK proof to the main network through the main network transaction Tx3. Among them, the main network transaction Tx3 calls the Rollup contract and includes the first pre-state root, the first post-state root, and the ZK proof.

[0171] At this stage, the ZK prover can confirm the correctness of the execution result within minutes and upload the generated ZK proof to the Rollup contract on the mainnet.

[0172] After the blockchain node on the mainnet executes the transaction Tx3, it verifies the correctness of the ZK proof through the verification logic corresponding to the ZK proof in the Rollup contract. Specifically, a VerifyingKey can be preset in the verification logic, and the blockchain node can verify the correctness of the ZK proof based on the Verifying Key, the first pre-state root, and the first post-state root.

[0173] When the blockchain node on the mainnet executes the transaction Tx3, if the verification of the ZK proof of this batch of packaged transactions passes, it can obtain the verification result of the TEE proof of this batch of packaged transactions from the contract state. If the TEE proof has passed the verification, it is determined that this batch of packaged transactions has been correctly executed. When the blockchain node fails to pass the verification of the TEE proof and / or ZK proof of this batch of packaged transactions, it is determined that this batch of packaged transactions has not been correctly executed. After the blockchain node executes the transaction Tx2 or the transaction Tx3, it can similarly store the verification results of the TEE proof and / or ZK proof as events in the form of a specific topic. The Relayer or proof module in Layer2 can listen to the verification results of the TEE proof and / or ZK proof on the mainnet. In the case where a verification failure is detected, this batch of packaged transactions can be put back into the transaction pool to re-execute these transactions.

[0174] After the TEE proof and ZK proof of the packaged transaction are uploaded to the mainnet, the verifier can determine the execution correctness of the packaged transaction by sending a transaction Tx4 that calls the verification interface of the Rollup Contract contract to the mainnet. When the mainnet blockchain node executes the transaction Tx4, it can read the TEE proof and ZK proof from the contract state of the Rollup Contract contract according to the logic of the verification interface, verify the TEE proof and ZK proof respectively as described above, and return the verification result to the verifier.

[0175] The embodiment of this specification can effectively adapt to multi-dimensional requirements such as high frequency and security of the financial trading system through a three-stage transaction confirmation mechanism. In the process of the Layer2 transaction processing system handling a large number of real-time transactions with high frequency, it can return the result of the transaction execution in real time without blocking the process of the external system; the prover of the second-stage TEE can return in seconds to achieve a fast return of asynchronous proof and support the fast status confirmation of the external system; the third-stage ZK prover returns in minutes to provide the highest level of security proof, cross-verify with the TEE proof, and can guarantee the security of transaction processing based on a heterogeneous proof system, enhancing the redundancy and robustness of the system.

[0176] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structures by programming the improved method flows into the hardware circuits. Therefore, it cannot be said that an improvement to a method flow cannot be implemented with a hardware entity module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. The designer can program by himself to "integrate" a digital system on a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL). And there is not only one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply making a little logical programming of the method flow with the above-mentioned several hardware description languages and programming it into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0177] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or the structures within the hardware component.

[0178] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the development of future computer technologies, the computers for implementing the functions of the above embodiments can be, for example, personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0179] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among many execution orders of steps and does not represent the only execution order. When actually executed by a device or terminal product, it may be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, product or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device comprising the said elements. For example, if terms such as first and second are used to denote names, they do not denote any particular order.

[0180] For convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed with each other may be through some interfaces. The indirect couplings or communication connections of the devices or units may be in electrical, mechanical or other forms.

[0181] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate a device for realizing the function specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0182] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one or more of the processes and / or blocks Figure 1 in one or more of the processes and / or blocks Figure 1 specified in one or more of the blocks or blocks.

[0183] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in one or more of the processes and / or blocks Figure 1 in one or more of the processes and / or blocks Figure 1 specified in one or more of the blocks or blocks.

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

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

[0186] Computer-readable media includes both permanent and non-permanent, removable and non-removable media implemented by any method or technology for storing information. The 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, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0187] Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of an all-hardware embodiment, an all-software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can 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.) that contain computer-usable program code.

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

[0189] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0190] The above is only the embodiments of one or more embodiments of this specification and is not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims.

Claims

1. A method for implementing a layer 2 network rollup, comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions to obtain packaged transactions, executes the packaged transactions in sequence based on the initial state before the packaged transactions are executed, obtains the execution results of each transaction, feeds back the execution results to the corresponding users, and generates a first post-state root corresponding to the packaged transaction; sends the packaged transaction, the initial state, and the first pre-state root and the first post-state root corresponding to the initial state to the trajectory generation module of the second-layer network; The trajectory generation module executes the packaged transaction in sequence based on the initial state to obtain an execution trajectory of the packaged transaction, and provides the packaged transaction, the initial state, the execution trajectory, the first pre-state root and the first post-state root to a proof module, wherein the proof module includes a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm; The first prover generates a first proof based on the packaged transaction, the initial state, the first pre-state root, and the first post-state root, and uploads the first proof to the rollup contract of the main network through a first main network transaction; The second prover generates a second proof based on the execution trace, the first pre-state root and the first post-state root, and uploads the second proof to the rollup contract of the main network through a second main network transaction. The first proof and the second proof are used to jointly determine whether the packaged transaction is executed correctly.

2. The method of claim 1, further comprising: When executing the packaged transaction, the sequencer determines the number of instructions corresponding to the packaged transaction, determines the parameters of the zero-knowledge proof circuit based on the number of instructions, and sends the parameters to the trajectory generation module to determine the circuit scale of the zero-knowledge proof circuit of the second prover.

3. The method of claim 1 further includes the trajectory generation module reading the SPV certificate corresponding to the initial state from the state tree corresponding to the initial state, and sending the SPV certificate to the certification module.

4. The method of claim 3, further comprising: The sequencer generates a first transaction root for the packaged transaction, and sends the first transaction root to the proof module through the trace generation module. The first prover generates a first proof based on the packaged transaction, the initial state, the first pre-state root, and the first post-state root, including: The first prover verifies the first transaction root and the first pre-state root; after the verification is passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the packaged transaction, and the signature is used as the first proof.

5. The method of claim 4, wherein the first prover verifies the first transaction root, comprising: The first prover generates a second transaction root for the packaged transaction and verifies whether the first transaction root is equal to the second transaction root.

6. The method of claim 4, wherein the first prover verifies the first previous state root, comprising: The first prover verifies the first pre-state root based on the SPV proof and the initial state.

7. The method according to claim 4, wherein the signing of the information of the packaged transaction comprises: Sign at least one of the batch number of the packaged transaction, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction.

8. The method of claim 4, before the first prover generates the first proof, further comprising: The sequencer sends a third mainnet transaction that calls the wrapping contract to the mainnet, where the third mainnet transaction includes the first transaction root, the first pre-state root, the first post-state root, and the compressed transaction; The first prover generates the first proof including: after the proof module monitors the main network and completes the execution of the third main network transaction, it obtains the packaged transaction, the initial state, the first pre-state root, the first post-state root, the execution trace and the first transaction root from the trace generation module; the first prover generates the first proof based on the packaged transaction, the first transaction root, the initial state, the first pre-state root and the first post-state root.

9. The method according to claim 8, wherein the second prover generates a second proof based on the execution trace, the first pre-state root and the first post-state root, comprising: After the proof module obtains the packaged transaction, the initial state, the first pre-state root, the first post-state root, the execution trace and the first transaction root from the trace generation module, the second prover generates the second proof based on the execution trace, the first pre-state root and the first post-state root.

10. The method according to claim 8, further comprising: The sequencer and the trace generation module process multiple batches of packaged transactions in a pipeline manner, so that multiple execution traces corresponding to the multiple batches of packaged transactions are stored in the trace generation module.

11. A two-layer network, comprising a sequencer, a trajectory generation module and a proof module, wherein the proof module comprises a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm, wherein: A sequencer is used to pull transactions from the transaction pool, sort the pulled transactions, obtain packaged transactions, execute the packaged transactions in sequence based on the initial state before the packaged transactions are executed, obtain the execution results of each transaction, feed back the execution results to the corresponding user, and generate a first post-state root corresponding to the packaged transaction; send the packaged transaction, the initial state, and the first pre-state root and the first post-state root corresponding to the initial state to the trajectory generation module of the second-layer network; The trajectory generation module is used to: execute the packaged transaction in sequence based on the initial state to obtain the execution trajectory of the packaged transaction, and provide the packaged transaction, the initial state, the execution trajectory, the first previous state root and the first subsequent state root to the proof module, the proof module includes a first prover and a second prover; the first prover is implemented using a trusted execution environment, and the second prover is implemented based on a zero-knowledge proof algorithm; The first prover is used to: generate a first proof based on the packaged transaction, the initial state, the first pre-state root and the first post-state root, and upload the first proof to the rollup contract of the main network through a first main network transaction; The second prover is used to: generate a second proof based on the execution trajectory, the first previous state root and the first subsequent state root, upload the second proof to the rollup contract of the main network through a second main network transaction, and the first proof and the second proof are used to jointly determine whether the packaged transaction is executed correctly.

12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 10 is implemented.

Images