Method for implementing layer 2 network rollup, layer 2 network, and prover

Abstract

A method for implementing layer 2 network rollup. An executor and prover of a layer 2 network are implemented by adopting a trusted execution environment. The method comprises: a sequencer of a layer 2 network pulls transactions from a transaction pool, sequences and packages the transactions, reads to the prover an SPV proof of an initial state / read set before execution of a packaged transaction, and sends the initial state / read set and the packaged transaction to an executor; on the basis of the initial state / read set, the executor executes the packaged transaction, adopts a private key of the executor to generate a first signature for a generated write set, and sends the write set and the first signature to a prover; after the prover verifies that the first signature passes, on the basis of the SPV of the initial state / read set, the prover constructs a Merkle tree and uses a tree root as a pre-state root, updates the write set to a leaf node of the Merkle tree, and updates a Merkle root and uses the Merkle root as a post-state root; and the prover adopts a private key of the prover to generate a second signature for the pre-state root and the post-state root, uses the second signature as a proof, and sends the second signature along with the pre-state root and the post-state root to a rollup contract on the mainnet by means of a second mainnet transaction.

Description

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

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

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

[0003] Distributed systems have the classic CAP theorem: consistency, availability, and partition tolerance. The three cannot be achieved simultaneously, known as the "impossible triangle." Blockchains also face an impossible triangle: efficiency, decentralization, and security. While this blockchain "impossible triangle" hasn't been clearly theoretically demonstrated, it serves as a summary of existing blockchains. Efficiency, decentralization, and security are defined as follows:

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

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

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

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

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

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

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

[0011] Summary of the Invention

[0012] This specification provides a method, a layer 2 network, and a prover for implementing layer 2 network convolution, which are implemented by:

[0013] A method for implementing a two-layer network convolution, wherein both an executor and a prover in the two-layer network are implemented using a trusted execution environment, the method comprising:

[0014] The orderer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and reads the SPV proof of the entire initial state / packaged transaction read set before the packaged transaction is executed from the data availability to the prover, and sends the entire initial state / read set before the packaged transaction is executed and the packaged transaction to the executor;

[0015] The executor executes the packaged transactions in sequence based on all initial states / read sets before the packaged transactions are executed, and generates a first signature using the write set generated by the private key in its own trusted execution environment; and sends the write set and the first signature to the prover;

[0016] After the prover verifies the first signature, it constructs a Merkle tree based on the SPV of the entire initial state / read set, uses the tree root as the previous state root, updates the write set sent by the executor to the leaf node of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the next state root;

[0017] The prover uses the private key in its own trusted execution environment to generate a second signature for the previous state root and the next state root, and uses the second signature as proof and sends it together with the previous state root and the next state root to the wrapping contract on the main network through a second main network transaction.

[0018] A layer 2 network includes a transaction pool, a sequencer, an executor, and a prover, wherein the executor and the prover are both implemented using a trusted execution environment, wherein:

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

[0020] The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions. The sorter reads the SPV proof of the entire initial state / packaged transaction read set before the packaged transaction is executed from the data availability to the prover, and sends the entire initial state / read set before the packaged transaction is executed and the packaged transaction to the executor;

[0021] The executor executes the packaged transactions in order based on all initial states / read sets before the packaged transactions are executed, generates a first signature for the write set generated using the private key in its own trusted execution environment, and sends the write set and the first signature to the prover.

[0022] After verifying the first signature, the prover constructs a Merkle tree based on the SPV of the entire initial state / read set, updates the write set sent by the executor to the leaf node of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root; and uses the private key in its own trusted execution environment to generate a second signature for the post-state root. The second signature is used as proof and sent together with the post-state root to the wrapper contract on the main network through a second main network transaction.

[0023] A prover is implemented using a trusted execution environment and includes:

[0024] The receiving unit is used to receive the SPV proof of the entire initial state / read set of the packaged transaction before execution from the sequencer, and the write set and first signature sent by the executor;

[0025] a verification unit, configured to verify the first signature;

[0026] The execution unit, after the verification unit passes the verification, constructs a Merkle tree based on the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root;

[0027] The signing unit generates a second signature on the post-state root using a private key in its own trusted execution environment;

[0028] The sending unit uses the second signature as proof and sends it together with the post-state root to the blockchain ledger of the main network through a second main network transaction.

[0029] As mentioned above, the executor and prover in the second-layer network are both implemented using a trusted execution environment. The executor generates the write set generated by the packaged transaction execution and signs it through the TEE, and the prover generates the post-state root after the packaged transaction execution. This can further reduce the verification burden of the Prover, thereby improving the verification efficiency of the Prover, and thus can bring lower latency. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

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

[0040] FIG10 is a schematic diagram showing the principle of Layer 2 in one embodiment. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0061] Table 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0095] Table 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0117] Event:

[0118] [topic][msg]

[0119] [topic][msg]

[0120] ......

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0169] [Corrected 18.12.2024 according to Rule 91] As shown in the example in Figure 6, an SPV proof consists of the states corresponding to two leaf nodes (represented in gray) and a Merkle path (represented in black).

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

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

[0172] As mentioned above, state_root is the hash value of the root of the MPT tree, which comprises the states of all accounts in the current block. That is, the state trie pointing to state_root is an MPT-style state trie. The root node of this MPT tree is typically an extension node or a branch node, and state_root typically stores the hash value of this root node. As shown in Figure 7, the root node can be connected to one or more layers of extension nodes / branch nodes below it. These multiple layers of tree nodes are collectively referred to as internal nodes. A portion of the values ​​in each node from the root to the leaf nodes of this MPT are sequentially concatenated to form an account address, which serves as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a portion of sha3(address), that is, a portion of the hash value of the account address (the hash algorithm, for example, uses the sha3 algorithm). The stored value can be rlp(account), the rlp encoding of the account information. Account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. As mentioned earlier, external accounts typically only have the nonce and balance fields, while the storageRoot and codeHash fields default to empty strings or strings containing all zeros. This means that external accounts do not store contracts or the state variables generated after contract execution. Contract accounts typically include nonce, balance, storage root, and codeHash. Nonce is the transaction counter for the contract account; balance is the account balance; the storage root corresponds to another MPT and can be linked to contract-related state information; and codeHash is the hash value of the contract code. Whether it's an external account or a contract account, its account information is generally located in a single leaf node. From the root node's extension node / branch node to each account's leaf node, there may be several branch nodes and extension nodes involved.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0192] Tx_21: Alice → Bob 20

[0193] Tx_22: Bob → Alice 10

[0194] Tx_23: Alice → Bob 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0223] In the above solution, the TEE-integrated Prover must re-execute all transactions, which is quite costly. Furthermore, the transaction execution portion of the Sequencer can be decoupled, for example, into the Executor, as shown in Figure 10. In Figure 10, the TxPool, Sequencer, and Executor in Layer 2 are likely the same party, while the Prover is likely a separate party. The former party typically also maintains a database, referred to here as Data Availability (DA), for persistent storage of Layer 2 data. This data typically includes raw transactions and status, and often also receipts. These receipts are similar to those on the mainnet. Each transaction (including standard transfers and those involving smart contracts) generates a corresponding receipt upon execution, including the transaction's execution results or related information. Specifically, for standard transfers, this includes the transaction status (success or failure), the total gas consumption, transaction logs, and a list of events with log information. For another example, the contract execution result / related information can be expressed as an event in the receipt. The event structure is, for example, in the following format:

[0224] Event:

[0225] [topic][msg]

[0226] [topic][msg]

[0227] ......

[0228] In the above example, the number of events can be one or more, and each event can include fields such as a topic and data.

[0229] After initiating a Layer2 transaction, a Layer2 client can maintain a connection with Layer2 through the SDK (e.g., a TCP persistent connection) to query the execution results or related information of the transaction of interest. After initiating a Layer2 transaction, a Layer2 client generally hopes to query the Layer2 receipt for information about the transaction's execution results as soon as possible, thereby confirming that the transaction has been accepted on Layer2.

[0230] Figure 10 uses colors to indicate the participants in this situation. Furthermore, the Executor can also be implemented using TEE. In this way, the Executor and Prover belonging to different participants in Layer 2 are both implemented using TEE. Two TEE devices can confirm each other's TEE attributes by challenging each other. For example, the remote authentication process described in detail above, including the EPID and DCAP schemes, can then be used to confirm the correctness of the TEE signature within the validity period based on the corresponding IAS certificate and certificate chain (including the IAS certificate + DCAP certificate).

[0231] Under this premise, since the legitimate identities of two authenticated TEE devices can be confirmed, the verification burden of the Prover can be reduced through process optimization based on the establishment of trust in the TEE devices. This application provides an embodiment of a method for implementing a two-layer network convolution, wherein both the executor and the prover in the two-layer network are implemented using a trusted execution environment, and the method includes the following:

[0232] S310: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and the sorter reads the SPV proof of all initial states / packaged transaction read sets before the packaged transaction is executed from the data availability to the prover, and sends all initial states / read sets before the packaged transaction is executed and the packaged transaction to the executor.

[0233] Similar to the previous example, a Rollup Contract can be deployed on Layer 1. On Layer 2, the TxPool receives transactions initiated by clients on Layer 2. The Sequencer pulls transactions from the TxPool and, for example, sorts and packages them according to their timestamps.

[0234] On the other hand, the sequencer can pull the entire state before the current packaged transaction is executed from the DA. In turn, the sequencer can send the entire initial state before the packaged transaction is executed to the prover; or, to reduce the amount of data sent to the prover, the SPV of the current packaged transaction read set can be sent to the prover instead of sending the entire initial state before the packaged transaction is executed.

[0235] The read set of the packaged transaction can be obtained by parsing the packaged transaction. For example, for an ordinary transfer transaction, it can be the account address involved in the transfer. The account address and its account balance constitute a key-value pair. The database (DA) generally stores the account address and its balance in a key-value manner, and also stores the state address and its value in the smart contract involved in the same key-value manner. In this way, the sorter can use the account in the transaction as a key to query the value corresponding to the key in the DA before the packaged transaction is executed. The key-value before the execution of the queried transaction is also called a read set. Similarly, for transactions involving smart contracts, the key of the state variable can be obtained by parsing the contract code, and then the corresponding value can be queried in the DA based on this key. This is also a read set.

[0236] For example, for 100 transactions in a batch after packaging and sorting, assume there are 5,000 states before execution (assuming this includes external accounts, contract accounts, and state variables in contract storage). These 100 transactions involve reads or writes to 800 of these states. This means that the remaining 4,200 states do not involve reads or writes. Therefore, to reduce the amount of data sent to the prover, SPV proofs can be used. A simplified example of an SPV proof, such as the one in Figure 6, omits the contents of leaf nodes that do not involve reads (write operations also involve a read operation, so they can be collectively referred to as the read set). While retaining leaf nodes that do involve reads, the hash values ​​of as few intermediate nodes or leaf nodes in the Merkle tree as possible are taken. This allows the SPV of the current packaged transaction read set to be sent to the prover, rather than the entire initial state before the packaged transaction is executed.

[0237] Furthermore, if, for example, the executor executes 100 transactions in a batch, it only needs to execute the transactions based on the read set involved to generate a write set. Therefore, the sequencer can send the read set to the executor instead of sending the entire initial state to the executor. Of course, this is an optimized implementation; in contrast, sending the entire initial state before executing the packaged transactions to the executor is also possible.

[0238] In addition, the sequencer can send the packaged transaction to the Rollup contract on the mainnet via the first mainnet transaction, specifically by sending it through a Relayer. The packaged transaction can be stored in calldata, similar to the above and not repeated here. Furthermore, the sequencer can also send the first transaction root to the Rollup contract on the mainnet via the first mainnet transaction, or the sequencer can send the first transaction root together with the packaged transaction to the Rollup contract on the mainnet via the first mainnet transaction. The first transaction root can then be stored in the contract state of the Rollup Contract, similar to the above and not repeated here.

[0239] Moreover, the sequencer may construct a Merkle tree based on the SPV of all the initial states / read sets, use the tree root as the previous state root, and send the previous state root to the rollup contract on the main network through the first main network transaction. The previous state root may be stored in the contract state of the Rollup Contract.

[0240] S320: The executor executes the packaged transaction in sequence based on all initial states / read sets before the packaged transaction is executed, and generates a first signature for the write set generated by the private key pair in its own trusted execution environment; and sends the write set and the first signature to the prover.

[0241] The executor can receive the received read set and the packaged transaction. The read set can specifically include the read set key and corresponding value. Since the read set is the read set involved in the packaged transaction, that is, the read and write operations involved in the packaged transaction are performed based on this read set. Therefore, the executor can sequentially execute the packaged transaction based on the read set involved in the packaged transaction to generate a write set. The write set can specifically include the write set key and corresponding value.

[0242] Continuing with the above example, the 100 transactions in a batch, after being packaged and sorted, involve a total of 800 state reads (or writes), that is, read / write operations involving these 800 read sets. Therefore, the executor can execute these 100 transactions sequentially based on these 800 read sets, generating the corresponding transaction-by-transaction write sets.

[0243] For example, the write sets generated by executing these 100 transactions in sequence are as follows:

[0244] tx2001: {write set key1-write set value1, write set key2-write set value2, ...};

[0245] tx2002: {write set key1-write set value1, write set key2-write set value2, ...};

[0246] ......

[0247] tx2100: {write set key1-write set value1, write set key2-write set value2, ...}.

[0248] The executor may use the private key in its own trusted execution environment to generate a first signature for the write set, and then may send the write set and the first signature to the prover.

[0249] Alternatively, the executor can execute the 100 transactions sequentially based on the 800 read sets to generate a summarized write set. For example, the summarized write set generated by executing the 100 transactions sequentially is as follows:

[0250] {write set key1-write set value1, write set key2-write set value2, write set key3-write set value3, ...}

[0251] In other words, a value in a later write set may overwrite a value in an earlier write set for the same key. The final write set only contains the result of the last write, not the results of intermediate writes. This significantly reduces the number of elements in the write set.

[0252] Similarly, the executor can use the private key in its own trusted execution environment to generate a first signature for the above-mentioned aggregated write set, and then send the aggregated write set and the first signature to the prover.

[0253] Alternatively, the executor can execute the 100 transactions sequentially based on the initial state of all transactions before the packaged transactions are executed, generating a write set for each transaction or a summarized write set. The result is similar to the above, and the generation of the first signature is also similar, which will not be repeated here.

[0254] In addition to the sequencer sending the packaged transaction to the Rollup contract on the mainnet via the first mainnet transaction, the executor may also send the packaged transaction to the Rollup contract on the mainnet via the first mainnet transaction, specifically via a Relayer. The packaged transaction may be stored in calldata, similar to the above description and not further elaborated. Furthermore, the executor may also send the first transaction root to the Rollup contract on the mainnet via the first mainnet transaction. For example, if the first transaction root is sent to the Rollup contract on the mainnet along with the packaged transaction via the first mainnet transaction, the first transaction root may be stored in the Rollup Contract's contract state, similar to the above description and not further elaborated.

[0255] Moreover, the executor may construct a Merkle tree based on the SPV of the entire initial state / read set, use the tree root as the previous state root, and send the previous state root to the rollup contract on the main network through the first main network transaction. The previous state root may be stored in the contract state of the Rollup Contract.

[0256] However, it should be noted that since the executor utilizes a trusted execution environment (TEE), which can store a private key proving its own identity, the executor can use its own private key within the TEE to sign the content of the first mainnet transaction and send the signature to the rollup contract on the mainnet via the first mainnet transaction. Specifically, for example, the executor may use the private key within the TEE to sign the packaged transaction and send the packaged transaction and signature to the rollup contract on the mainnet via the first mainnet transaction. Alternatively, the executor may use the private key within the TEE to sign the packaged transaction and the first transaction root and send the packaged transaction, the first transaction root, and the signature to the rollup contract on the mainnet via the first mainnet transaction. Alternatively, the executor may use the private key within the TEE to sign the packaged transaction, the first transaction root, and the previous state root and send the packaged transaction, the first transaction root, the previous state root, and the signature to the rollup contract on the mainnet via the first mainnet transaction. Furthermore, the executor may use the private key within the TEE to sign the packaged transaction, the first transaction root, the previous state root, and the signature to the rollup contract on the mainnet via the first mainnet transaction. Of course, if the sorter and executor belong to the same party, the sorter can send part of the content, while the executor sends another part. In addition to the obvious method of sending them through different mainnet transactions, in order to reduce gas consumption on Layer 1, the Relayer can send them all through the same mainnet transaction, such as the first mainnet transaction. The advantage of using the executor to send the mainnet transaction to the Rollup contract on the mainnet is that it can include the signature of the executor's own trusted execution environment, which can be verified in the Layer 1 Rollup Contract.

[0257] S330: After the prover verifies the first signature, it constructs a Merkle tree based on the SPV of the entire initial state / read set, updates the write set sent by the executor to the leaf node of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root.

[0258] If the initial state sent is the entirety of the transaction before it is packaged, including the key and its corresponding value, the prover can construct a Merkle tree (such as the aforementioned MPT or SMT tree) using all of these initial states as leaf nodes, with the root of the resulting Merkle tree serving as the pre-state root. Furthermore, based on these initial states, the prover can sequentially update the write sets of each transaction to the leaf nodes of the Merkle tree and update the Merkle root until all packaged transactions are updated in order. The updated Merkle root then serves as the post-state root.

[0259] Furthermore, the prover can update the aggregate writeset to the leaf nodes of the Merkle tree based on the entire initial state and update the Merkle root, with the updated Merkle root serving as the post-state root. This approach significantly speeds up the process of updating all involved leaf nodes at once, rather than requiring transaction-by-transaction updates.

[0260] In addition, the prover can construct a Merkle tree (such as the aforementioned MPT or SMT tree) based on the read-set SPV, and use the root of the obtained Merkle tree as the pre-state root. Furthermore, the prover can sequentially update the write sets of each transaction to the leaf nodes of the Merkle tree based on the entire initial state, and update the Merkle root until all packaged transactions are updated in order. The updated Merkle root is then used as the post-state root.

[0261] Similarly, the prover can update the aggregated write set to the leaf nodes of the Merkle tree based on the read set SPV and update the Merkle root until all the packaged transactions are updated in order. The updated Merkle root is then used as the post-state root. Similarly, this method can update all involved leaf nodes at once, which is faster, rather than requiring the previous method to update leaf nodes transaction by transaction.

[0262] S340: The prover generates a second signature for the post-state root using the private key in its own trusted execution environment, and uses the second signature as proof and sends it together with the post-state root to the wrapping contract on the main network through a second main network transaction.

[0263] After the prover completes S330 , it uses the private key in its own trusted execution environment to sign the post-state root to obtain a second signature.

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

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

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

[0267] As mentioned above, the prover can construct a Merkle tree (such as the aforementioned MPT or SMT tree) based on the read set SPV, and the root of the obtained Merkle tree is used as the previous state root. Accordingly, the prover here can also send the previous state root to the wrapper contract on the main network through a second main network transaction, and the signature includes a signature on the previous state root.

[0268] As mentioned above, both the executor and the prover in the second-layer network are implemented using a trusted execution environment. The executor generates the write set generated by the packaged transaction execution and signs it through the TEE, while the prover generates the post-state root after the packaged transaction execution. This can further reduce the verification burden of the prover, thereby improving the verification efficiency of the prover and thus bringing lower latency.

[0269] In order to reduce the gas consumption on Layer 1, the previous and next state roots of multiple consecutive batches can be sent through a second mainnet transaction. The solution is as follows:

[0270] S410: The orderer of the Layer 2 network pulls transactions from the transaction pool, sorts and packages the pulled transactions. The orderer reads the SPV proof of the entire initial state / packaged transaction read set before the packaged transaction is executed from the data availability to the prover, and sends the entire initial state / read set before the packaged transaction is executed and the packaged transaction to the executor; the packaged transaction includes at least two consecutive batches;

[0271] S420: The executor executes the packaged transactions in sequence based on all initial states / read sets before the packaged transactions are executed, and generates a first signature for at least two consecutive batches of write sets generated using a private key pair in its own trusted execution environment; and sends the write set and the first signature to the prover.

[0272] S430: After the prover verifies the first signature, it constructs a Merkle tree based on the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree for each batch, and updates the Merkle root. The updated Merkle root is used as the post-state root of the batch.

[0273] S440: The prover generates a second signature for each post-state root of the at least two consecutive batches using the private key in its own trusted execution environment, and uses the second signature as proof and sends it together with the post-state root to the wrapping contract on the main network through a second main network transaction.

[0274] Except that when a packaged transaction includes at least two consecutive batches, the first transaction root may include the transaction root of each batch or the total transaction root of multiple batches, and the front and back state roots may include the front and back state roots of each batch or the total front and back state roots of the at least two consecutive batches. Other implementation details are similar to the above and are not repeated here.

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

[0276] The following describes a Layer 2 network embodiment of the present application, including a transaction pool, a sequencer, an executor, and a prover. The executor and the prover are both implemented using a trusted execution environment, wherein:

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

[0278] The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions. The sorter reads the SPV proof of the entire initial state / packaged transaction read set before the packaged transaction is executed from the data availability to the prover, and sends the entire initial state / read set before the packaged transaction is executed and the packaged transaction to the executor;

[0279] The executor executes the packaged transactions in order based on all initial states / read sets before the packaged transactions are executed, generates a first signature for the write set generated using the private key in its own trusted execution environment, and sends the write set and the first signature to the prover.

[0280] After verifying the first signature, the prover constructs a Merkle tree based on the SPV of the entire initial state / read set, updates the write set sent by the executor to the leaf node of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root; and uses the private key in its own trusted execution environment to generate a second signature for the post-state root. The second signature is used as proof and sent together with the post-state root to the wrapper contract on the main network through a second main network transaction.

[0281] There may be at least two provers that are executed in parallel.

[0282] The following describes a prover implemented in a trusted execution environment (TEE) and comprising:

[0283] A receiving unit, configured to receive the SPV proof of the entire initial state / read set of the packaged transaction before execution from the sequencer, and to receive the write set and first signature from the executor and send them to the prover;

[0284] a verification unit, configured to verify the first signature;

[0285] The execution unit, after verification by the verification unit, constructs a Merkle tree based on the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root;

[0286] The signing unit generates a second signature on the post-state root using a private key in its own trusted execution environment;

[0287] The sending unit uses the second signature as proof and sends it together with the post-state root to the blockchain ledger of the main network through a second main network transaction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for implementing a two-layer network convolution, wherein both an executor and a prover in the two-layer network are implemented using a trusted execution environment, the method comprising: The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and the sorter reads the SPV proof of all initial states / read sets of packaged transactions before the execution of the packaged transactions from the data availability to the prover, and sends all initial states / read sets before the execution of the packaged transactions and the packaged transactions to the executor; The executor executes the packaged transaction in sequence based on all initial states / read sets before the packaged transaction is executed, and generates a first signature using a write set generated by a private key pair in its own trusted execution environment; and sends the write set and the first signature to the prover; After the prover verifies the first signature, it constructs a Merkle tree based on the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root; The prover generates a second signature for the post-state root using a private key in its own trusted execution environment, and uses the second signature as proof and sends it together with the post-state root to the wrapping contract on the main network through a second main network transaction.

2. The method of claim 1, further comprising: The sequencer sends the packaged transaction to the rollup contract on the main network through the first main network transaction.

3. The method of claim 2, further comprising: The sequencer generates a first transaction root for the packaged transaction, and sends the packaged transaction to the wrapping contract on the main network through the first main network transaction.

4. The method of claim 2, further comprising: The sequencer constructs a Merkle tree based on the SPV of all the initial states / read sets, uses the tree root as the previous state root, and sends the previous state root to the wrapping contract on the main network through the first main network transaction.

5. The method of claim 1, further comprising: The executor sends the packaged transaction to the rollup contract on the main network through the first main network transaction.

6. The method of claim 5, further comprising: The executor generates a first transaction root for the packaged transaction, and sends the packaged transaction to the wrapping contract on the main network through a first main network transaction.

7. The method of claim 5, further comprising: The executor constructs a Merkle tree based on the SPV of all the initial states / read sets, uses the tree root as the previous state root, and sends the previous state root to the wrapping contract on the main network through the first main network transaction.

8. The method according to any one of claims 5 to 7, further comprising: The executor uses the private key in its own trusted execution environment to sign the content in the first main network transaction and sends the signature to the wrapping contract on the main network through the first main network transaction.

9. The method of claim 1, wherein the executor sequentially executes the packaged transaction based on all initial states / read sets before the packaged transaction is executed, and generates a first signature using a write set generated by a private key pair in its own trusted execution environment, comprising: The executor executes the packaged transactions in order based on all initial states / read sets before the packaged transactions are executed, and generates write sets for each transaction; The executor generates a first signature for each transaction write set generated by a private key pair in its own trusted execution environment.

10. The method of claim 1, wherein the executor sequentially executes the packaged transaction based on all initial states / read sets before the packaged transaction is executed, and generates a first signature using a write set generated by a private key pair in its own trusted execution environment, comprising: The executor executes the packaged transactions in order based on all initial states / read sets before the packaged transactions are executed, and generates a summarized write set; The executor generates a first signature by using a summary write set generated by a private key pair in its own trusted execution environment.

11. The method of claim 1, wherein the prover updates the write set sent by the executor to the leaf node of the Merkle tree and updates the Merkle root, comprising: The prover updates the write sets of each transaction to the leaf nodes of the Merkle tree in sequence based on the entire initial state / the read set SPV, and updates the Merkle root until the packaged transactions are updated in sequence.

12. The method of claim 1, wherein the prover updates the write set sent by the executor to the leaf node of the Merkle tree and updates the Merkle root, comprising: The prover updates the aggregated write set to the leaf nodes of the Merkle tree based on the entire initial state / the read set SPV, and updates the Merkle root.

13. The method of claim 1, wherein the prover further uses the root of the SPV Merkle tree constructed of the entire initial state / read set as the previous state root.

14. According to the method of claim 13, the prover also sends the previous state root to the wrapping contract on the main network through a second main network transaction, and accordingly, the signature includes a signature on the previous state root.

15. The method according to any one of claims 1 to 14, wherein the packaged transaction comprises at least two consecutive batches.

16. The method according to claim 15, wherein the first transaction root comprises a transaction root of each batch or a total transaction root of multiple batches; and / or, The previous and next state roots include the previous and next state roots of each batch or the total previous and next state roots of the at least two consecutive batches.

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

18. A layer 2 network, comprising a transaction pool, a sequencer, an executor and a prover, wherein: The transaction pool is used to receive transactions sent by users on the second-layer network; The sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions, and reads the SPV proof of all initial states / read sets of packaged transactions before the execution of the packaged transactions from the data availability to the prover, and sends all initial states / read sets before the execution of the packaged transactions and the packaged transactions to the executor; The executor executes the packaged transaction in order based on all initial states / read sets before the packaged transaction is executed, and generates a first signature using a write set generated by a private key pair in its own trusted execution environment; and sends the write set and the first signature to the prover; The prover, after verifying that the first signature is passed, constructs a Merkle tree according to the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree, and updates the Merkle root, using the updated Merkle root as the post-state root; and uses the private key in its own trusted execution environment to generate a second signature for the post-state root, uses the second signature as proof and sends it together with the post-state root to the wrapping contract on the main network through a second main network transaction.

19. The two-layer network as claimed in claim 18, wherein the number of the provers is at least two and they are executed in parallel.

20. A prover, implemented using a trusted execution environment, comprising: A receiving unit, used to receive the SPV proof of all initial states / read sets of packaged transactions before the execution of the packaged transactions sent by the sorter, and the write set and the first signature sent by the executor; A verification unit, configured to verify the first signature; The execution unit, after the verification unit passes the verification, constructs a Merkle tree according to the SPV of all the initial states / read sets, updates the write sets sent by the executor to the leaf nodes of the Merkle tree, and updates the Merkle root, and uses the updated Merkle root as the post-state root; The signing unit generates a second signature on the post-state root using a private key in its own trusted execution environment; The sending unit uses the second signature as proof and sends it together with the post-state root to the blockchain ledger of the main network through a second main network transaction.

Images