WO2025103147A1 - 实现二层网络卷叠的方法及二层网络 - Google Patents

实现二层网络卷叠的方法及二层网络 Download PDF

Info

Publication number
WO2025103147A1
WO2025103147A1 PCT/CN2024/128764 CN2024128764W WO2025103147A1 WO 2025103147 A1 WO2025103147 A1 WO 2025103147A1 CN 2024128764 W CN2024128764 W CN 2024128764W WO 2025103147 A1 WO2025103147 A1 WO 2025103147A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
root
state
packaged
post
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/128764
Other languages
English (en)
French (fr)
Inventor
胡文博
周晨辉
李育文
卓海振
魏长征
闫莺
蒋国飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Publication of WO2025103147A1 publication Critical patent/WO2025103147A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and more particularly to a method for implementing a two-layer network rollup and a two-layer network.
  • Decentralization The threshold for participating nodes is low enough to ensure that there are a large number of distributed nodes in the system.
  • Ethereum also known as “mainnet” or “layer”, Mainnet or Layer1; in addition, the more popular public chain projects such as Binance's BSC and TRON are also in the category of Layer1/mainnet) chose security and decentralization, sacrificing efficiency, and currently only has about 12 to 15 TPS.
  • Layer1 When there are a large number of transactions to be processed, especially when there are many complex transactions, Layer1 will be congested.
  • Layer1 is also the main platform for popular applications such as DeFi (decentralized finance) and NFT (non-homogeneous tokens). When transactions are prevalent, the problem of Layer1 congestion becomes very serious, causing large transaction delays, which affects user use.
  • gas fees gas fees, or transaction fees
  • PoW proof of work
  • PoS proof of stake
  • the transaction fees that need to be paid to the nodes that obtain the right to record have not decreased significantly.
  • the design of the gas fee targets the consumption of nodes executing transactions (including executing smart contract codes), and the gas fee will not be reduced if this part of the consumption does not change.
  • the transaction fee of a currency exchange transaction on a decentralized exchange may exceed $100 during congestion, which discourages many users.
  • Layer 2 technology is a scalability solution built on Layer 1, which aims to solve the problems of low efficiency and high transaction fees of Layer 1.
  • transactions can be executed quickly on Layer 2, and Layer 2 synchronizes the final state back to Layer 1 at a certain time.
  • Layer 2 is used to provide high-speed transaction processing, while security and decentralization are guaranteed by Layer 1.
  • the gas fee for executing transactions on Layer 2 can be greatly reduced, and the gas fee required to synchronize the final state of the transaction execution on Layer 2 (rather than all the states on Layer 2) back to Layer 1 can also be greatly reduced.
  • the technology of building Layer 2 on top of Layer 1 actually separates the execution process of transactions or contracts from the preservation of the final state. The execution process is placed on Layer 2, and Layer 1 only needs to save Final state. In this design, it is necessary to ensure the correctness of the execution process of transactions or contracts on Layer2, and the state written to Layer1 is consistent with the result of correct execution on Layer2.
  • Ethereum's Layer2 includes a mechanism called Rollup.
  • the core idea of Rollup is shown in Figure 1, which is to save the credentials that can verify the transaction process on Layer1, and run the transaction process (computation process) and state storage in Layer2.
  • the so-called transaction process credentials include a set of states before the execution of a transaction (Pre-State) and the state after the execution of the group of transactions (Post-State) and the group of transactions. It can be used to verify whether the state transfer corresponding to this group of transactions is correct, and can also be used to restore the execution process of all transactions on Layer2 and the status of all accounts, thereby eliminating the security risks caused by data availability on Layer2.
  • This specification provides a method and a layer 2 network for implementing layer 2 network convolution, which is implemented by:
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transaction, and executes the packaged transactions in sequence based on the initial state before the packaged transaction is executed and generates a first post-state root;
  • the sequencer sends the packaged transaction, the first transaction root, the SPV proof of the read set before the packaged transaction is executed, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root, and verifies the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • the executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the subsequent packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • S2 The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • S3 The executor generates a first transaction root of a subsequent packaged transaction, and executes the previous transaction based on the subsequent packaged transaction.
  • the initial state of the N+1th package executes the subsequent packaged transactions in sequence and generates a first post-state root; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before the transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • S4 The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependency relationship, and sends different groups to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependency relationship, and sends different groups to the executor participants;
  • the executor participant uses an executor to generate a first transaction root of a subsequent packaging transaction; the at least two executors each execute the subsequent packaging transaction in sequence based on the initial state before the execution of the subsequent packaging transaction
  • the executor combines the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a method for implementing a two-layer network rollup comprising:
  • the sorter of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • S6 The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • a sequencer pulls transactions from a transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transaction, and executes the packaged transaction in sequence based on the initial state before the packaged transaction is executed and generates a first post-state root; the sequencer sends the packaged transaction, the first transaction root, the SPV proof of the packaged transaction read set before the packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network;
  • the prover is used to verify the first transaction root and verify the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • the executor generates the first transaction root of the subsequent packaged transaction, and executes the previous transaction based on the subsequent packaged transaction.
  • the initial state of the subsequent packaged transactions is executed in sequence and a first post-state root is generated;
  • the executor sends the subsequent packaged transactions, the first transaction root, the initial state before the execution of the subsequent packaged transactions, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network;
  • the prover is implemented in a trusted execution environment;
  • S2 The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • the executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the SPV proof of the read set before the transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • S4 The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends different groups to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction, and will not have After grouping the transactions with dependent relationships, the different groups are sent to at least two executors; the at least two executors each execute the different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and one executor merges the execution results of all the transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends different groups to the executor participants;
  • the executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a two-layer network including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • S6 The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • TEE is used as a prover on the second-layer network. Since the transaction replay and verification in TEE are close to the speed of native execution, lower latency can be achieved.
  • FIG1 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG2 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG3 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG4 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG5 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG6 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG7 is a schematic diagram of the principle of an MPT tree in one embodiment
  • FIG8 is a schematic diagram of the principle of an MPT tree in one embodiment
  • FIG9 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG10 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG11 is a schematic diagram of the principle of Layer 2 in one embodiment
  • FIG. 12 is a schematic diagram of the principle of DAG in one embodiment.
  • the transaction to create a smart contract is sent to Layer1. After the consensus of Layer1, each node on Layer1 can execute this transaction to complete the deployment of the contract. Specifically, the transaction can be executed by the EVM/WASM of the blockchain node.
  • EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it. This is also one of the biggest improvements of Ethereum as a representative of blockchain 2.0 compared to blockchain 1.0. Users can publish and call smart contracts in Ethereum on EVM. After executing the transaction to deploy the smart contract, a contract account corresponding to the smart contract is generated on Layer1.
  • the contract account has an on-chain address and includes a balance, a counter nonce, a hash value of the contract code Codehash, and the root of the contract storage Storage_Root.
  • the code and account storage of the contract can be saved in the contract account.
  • the behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract.
  • smart contracts generate a storage containing contract code and account storage on the blockchain. A virtual account.
  • the nodes on Layer1 can receive transaction requests to call the deployed smart contract, which may include the address of the called contract, the function in the called contract, and the input parameters.
  • each node in the blockchain can independently execute the specified smart contract.
  • Storage_root in Ethereum is the hash of the root node of an MPT tree.
  • This MPT tree organizes the storage of the state of the contract account.
  • MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (compressed prefix tree, a more space-saving Trie tree, dictionary tree).
  • the Merkle Tree algorithm calculates a hash value for each transaction, and then connects two by two to calculate the hash again, all the way to the top-level Merkle root.
  • Ethereum uses an improved MPT tree, such as a 16-way tree structure, which is usually referred to as an MPT tree.
  • the Ethereum block header includes the roots of three MPT trees, namely Transaction_Root (abbreviated as Tx_Root), State_Root, and Receipt_Root.
  • State_Root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state tree state trie pointing to State_Root is an MPT form. Part of the value of each node from the root node to the leaf node of this MPT can be connected in sequence to form an account address and used as a key.
  • the account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair.
  • this key can be sha3(Address), that is, the hash value of the account address (the hash algorithm, for example, uses the sha3 algorithm), and the value stored can be rlp(Account), that is, the rlp (Recursive Length Prefix) encoding of the account information.
  • the account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash].
  • EOA External Account
  • the storageRoot and codeHash fields store empty strings/all zero strings by default.
  • 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.
  • this Storage Trie tree also stores key-value pairs.
  • the key indicates the address of the state variable, and its value can be the result obtained by processing the position of the state variable declaration in the contract (the value counting from 0) according to certain rules, such as sha3 (the position of the state variable declaration) or sha3 (the contract name + the position of the state variable declaration).
  • the value is used to store the value of the state variable (for example, the value encoded by RLP).
  • a part of the data stored on the path from the root node to the leaf node is connected to form the key, and the value is stored in the leaf node.
  • the root nodes and intermediate nodes except the leaf nodes are in the cloud shape as shown in Figure 3 to represent the flexible and complex structure.
  • Rollup Contract can be deployed on Layer 1 in Rollup.
  • 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.
  • Batch 1 is assumed to include three transactions, Tx_21, Tx_22, and Tx_23
  • Batch 2 is assumed to include three transactions, Tx_24, Tx_25, and Tx_26.
  • these transactions can be sorted according to a rule, and then these sorted transactions can be executed in order, for example, sorted according to the timestamp in the transaction.
  • the generated The status can include several, for example, the transactions in Batch 1 are:
  • Tx_21 Alice ⁇ Bob 20; indicates that Alice transfers 20 units of assets, such as ether, to Bob;
  • Tx_22 Alice ⁇ Charlie 10; indicates that Alice transfers 10 units of assets, such as ether, to Charlie;
  • Tx_23 Bob ⁇ Charlie 10; indicates that Bob transfers 10 units of assets, such as ether, to Charlie;
  • Merkle tree can be used in Layer2 to organize the states of transactions in Batch 1 before and after they are executed in sequence. As shown in Figure 3, in Layer2, the transactions of a Batch and their related state changes can be organized together. For example, the Merkle root obtained by organizing the hash value of the transaction in Batch 1 according to the Merkle tree is locked in the header of the Batch. This header is similar to the block header in Layer 1, and this Merkle root is the Tx_Root in the header of the Batch.
  • the Merkle root obtained by organizing all the state values of the transactions in Batch 1 before execution according to the Merkle tree can be locked in the header of the Batch, that is, Pre State Root; the Merkle root obtained by organizing the hash of all the state values of the transactions in Batch 1 after they are executed in sequence according to the Merkle tree can be locked in the header of the Batch, that is, Post State Root.
  • a timestamp can be set in its Header to record the time when the Batch was generated, and of course, information in other fields can also be set.
  • 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 between the two roots in Figure 3. In this way, a chain structure is formed between the batches.
  • Layer2's Rollup mechanism can include two types: one is Optimistic-Rollup (OP-Rollup for short), and the other is ZK-Rollup (Zero-knowledge Proof Rollup, ZK refers to zero knowledge).
  • OP-Rollup Optimistic-Rollup
  • ZK-Rollup Zero-knowledge Proof Rollup
  • Ethereum has deployed the aforementioned smart contract - Rollup Contract.
  • TxPool transformation pool
  • Relayer Relay
  • Sequencer sequencer
  • Sequencer sorts and packages these transactions according to the timestamps in these transactions, for example, packs Tx21, Tx22, and Tx23 into Batch M, organizes the hash values of these transactions into Merkle, generates Merkle Root, and fills 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 cases less than 2n , the last transaction can be assigned multiple copies to complete 2n , thereby calculating the root of the 2-fork Merkle tree.
  • Tx23 which is the last transaction in chronological order, is repeated once to complete 4 transactions, even if the number of transactions reaches 22 , and then the root of the 2-fork Merkle tree can be calculated.
  • the Sequencer sorts the transactions according to the timestamps in the transactions and packages Tx21, Tx22, and Tx23 into Batch M+1, which will not be repeated here.
  • all states include Alice: 50, Bob: 100, Charlie: 150, David: 200.
  • the Sequencer can organize these states into a Merkle tree and store the hash value of the root node of the Merkle tree in the Pre State Root field of the Batch M Header. Furthermore, the Sequencer can execute the three transactions Tx21, Tx22, and Tx23 in sequence. As a result of executing these three transactions, a new state is generated, as mentioned above, Alice: 20, Bob: 110, Charlie: 170, David: 200.
  • the Sequencer can organize these updated states into a Merkle tree and store the hash value of the root node of the Merkle tree in the Post State Root field of the Batch M Header.
  • Sequencer can send a transaction 1 that calls Rollup Contract to Layer1 through Relayer.
  • Transaction 1 includes the fields in Batch M Header and compressed Tx21, Tx22, and Tx23. After compression, the space occupied by Tx21, Tx22, and Tx23 can be greatly reduced.
  • the interface in the called Rollup Contract contract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas fee) location calldata.
  • calldata is a special data location (data location) used to store input data called by a function. Specifically, calldata data is generally stored directly in Ethereum's transaction data, which usually saves more gas than other data locations (such as memory and storage).
  • a simple Ethereum transaction (sending ETH) is about 110 bytes in size, while for ETH transfers on Rollup, the current design can reduce the size to about 12 bytes after maximum compression.
  • the following table shows an example of the size occupied by each field (parameter) of an Ethereum transaction and each field of a transaction in Rollup:
  • public key cryptography also known as asymmetric cryptography
  • pk-sk public key-private key
  • pk public key-private key
  • secret key secret key
  • public key cryptography includes encryption algorithms and digital signature algorithms.
  • the public-private key cryptographic pair is the cornerstone of modern cryptographic security.
  • Many applications are based on pk-sk, such as the https (Hypertext Transfer Protocol Secure) application layer encryption transmission protocol and blockchain.
  • a private key usually represents the identity of the party that owns the private key. It can only be held by the owner of the private key and cannot be made public.
  • the corresponding public key can be made public.
  • the signature made with the private key can indicate the private key owner's approval of certain information in the digital world.
  • the signed information can also indicate a certain behavior of the private key owner in the protocol message. Generally, an owner has a private key alone. Then the owner can use his own private key to sign a certain information and send it to other parties. After receiving the signature, the recipient can use the corresponding public key to verify the signature. If the verification is successful, the recipient can confirm that the owner has signed the information and the signed information has not been tampered with.
  • the BLS signature scheme was originally proposed by Dan Boneh, a professor at Stanford University, and others in 2001. It is based on a bilinear mapping structure. Generally, a user's control over his own account is reflected in signing a transaction with his own private key. As shown in the table above, a single signature may reach 68 bytes, which occupies a large volume. For multiple transactions initiated by multiple accounts, each account needs to sign each of its own transactions separately. Signature aggregation can aggregate multiple signatures into one signature, thus greatly saving the byte space of the signature. This aggregation can be the aggregation of the same message signed by different signers, or the aggregation of signatures of different messages.
  • Public key aggregation can aggregate multiple different public keys into a total public key, which can complete the verification of the aggregated signature without the need for each public key to participate in the calculation when verifying the total signature.
  • Signature aggregation can usually be implemented using the Schnorr signature algorithm and the BLS signature algorithm. Compared with the Schnorr signature algorithm, the aggregated signature implemented by the BLS signature algorithm is smaller in size, about half of Schnorr.
  • this transaction 1 is executed on some nodes, and this transaction 1 and its execution results are generated together with some other transactions and their execution results into a block, such as Block N in Figure 3.
  • the other transactions may include ordinary transfer transactions and transactions involving other smart contracts. Among them, ordinary transfer transactions and transactions involving other smart contracts can all involve the execution of transactions. In particular, transactions of other smart contracts may involve more complex execution logic. And the transaction 1 here, calling the function stored in the calldata position in the Rollup Contract, mainly involves storing in the specified position, that is, it does not involve the execution of complex contract logic.
  • the main function of the Rollup Contract in Layer1 is to store the specified content in the transaction sent from Layer2 into the specified position, and does not involve complex execution logic.
  • Tx21, Tx22, and Tx23 are stored in Tx_12 in the transaction tree locked by Tx_Root in the Block N Header.
  • the Pre State Root and Post State Root in the Batch M Header in Transaction 1 can be stored in the State 1 and State 2 in the contract state on Layer1 through the Rollup Contract.
  • State 1 and State 2 are contained in the state trie locked by State_Root in the Block N Header, for example, in the storage trie.
  • State 1 and State 2 in the contract state on Layer1 are respectively called Last State root and Current State root.
  • Last State root can be saved in the contract state on Layer1 without saving the Last State root, as shown in the following code example.
  • the Last State root and the Current State root can also be stored in the calldata in Layer1 like the transactions in Layer2, which will not be repeated here.
  • the commitBatch() contract interface in Layer1 is called as follows:
  • OP-Rollup can execute each transaction in Layer2, and can bundle dozens, hundreds or even more Layer2 transactions in a batch, and only publish the minimum information to Layer1.
  • the so-called minimum information includes the compressed Layer2 transactions as mentioned above and the hash value of the state root before and after the execution of this batch of transactions. As shown above, here, for example, it can be sent through a transaction on Layer1, such as transaction 1 in Figure 3. It can be seen that this is equivalent to executing a batch of transactions on Layer2 at one time, but only executing one transaction on Layer1. At the same time, OP-Rollup does not come with any proof. This is based on the assumption that there is no fraud or malicious behavior in the submitted Layer2 information, so it is named "Optimistic".
  • Fraud proof is a method of verifying data validity adopted by the Optimistic Rollup solution. Fraud proofs can be divided into single-round interactive and multi-round interactive types.
  • the disputed transaction is replayed on Layer1, and submitted after checking whether there is an invalid state.
  • Alice as a validator, synchronizes the compressed data of OP-Rollup to Layer1 and pledges a deposit. If the challenger Bob has a dispute over the data, he needs to initiate a challenge within the window period (challenge period) and also pledge a deposit.
  • the Rollup Contract of OP-Rollup will recalculate the transactions in the block on Layer1 to determine right and wrong. The deposit of the wrong party will be confiscated, and the correct party will be rewarded.
  • the Sequencer on Layer2 has previously packaged and executed Tx21, Tx22, and Tx23, and generated the header of Batch M, which includes the Merkle root Pre State Root and Post State Root of the global state before and after the sequential execution of Tx21, Tx22, and Tx23, as well as others.
  • the Sequencer can send a transaction 1 that calls the Rollup Contract to Layer1 through the Relayer.
  • This transaction for example, calls the CommitBatch() contract interface of the Rollup Contract in Layer1, which includes the fields in the Batch M Header and the compressed Tx21, Tx22, and Tx23.
  • Bob is a user on Layer2. Assume that he participates in some transactions in Batch M on Layer2, such as the aforementioned Tx_21: Alice ⁇ Bob 20 and Tx_23: Bob ⁇ Charlie10.
  • Bob can initiate a challenge on Layer1 during the challenge period of Batch M.
  • Bob can obtain all the states before and after the execution of each Batch on Layer2, as well as all the transactions in each Batch. This is the premise.
  • Bob can initiate a challenge to the Rollup Contract in Layer1, for example, by calling the Challenge() contract interface. Through the Challenge() contract interface, Bob can send the challenged Batch number 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 transaction stored in calldata without a signature is taken as an example) and the global state before the execution of Batch M.
  • the execution logic of this verification function includes, for example:
  • the root hash of the Merkle tree organized after removing the transaction signature and compressing the original transaction text is the same as the Tx_Root in the Batch M Header sent by the Sequencer through the Relayer calling CommitBatch() (that is, the root hash of the Merkle tree organized by all transactions in Batch M);
  • step 4 If the results of step 4 are different, it means that the Sequencer has committed fraud and part of the deposit can be paid to the challenger through the Rollup Contract.
  • the calldata on Layer1 contains all the compressed transactions on Layer2, in the process of verifying the fraud proof, the compressed transactions in Batch M in the calldata are not directly taken out for execution, but simulated execution based on the original text of all transactions in Batch M passed in by the challenger.
  • the compressed Batch M transactions in calldata are generally only used to restore the execution process of all transactions on Layer2 and the status of all accounts, thereby eliminating the security risks on Layer2 due to data availability.
  • the authenticity of the compressed Batch M transactions in calldata without signatures remains to be determined, while the transactions passed in by the challenger are complete transactions that can verify the validity of the transactions.
  • the contract stores only the state root instead of the state, unless all transactions are re-executed sequentially from Batch 0 until the entire state is obtained after Batch M-1 is executed, which is obviously uneconomical and inefficient.
  • the Sequencer needs to divide the disputed Batch range into two equal ranges, front and back, and return it through a contract interface such as dispute(). Then Bob further selects a range after the second division to challenge, and the Sequencer divides the disputed range into two equal ranges... This cycle repeats until the disputed range is reduced to a specific transaction.
  • 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 state commitment) before the challenged transaction is executed and the Post State Root after execution, which will be handed over to the Layer1 Rollup Contract for calculation and judgment.
  • 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, and executes the challenged transaction based on the global state before the challenge transaction is executed, generates the state after execution, and generates the Post State Root based on the global state after the challenge transaction is executed.
  • the Post State Root sent by the Sequencer if they are different, it means that the challenge is successful, otherwise the challenge fails.
  • Arbitrum does not use a binary method, but a K-point method, that is, each time N instructions are divided into N/K groups to find fraudulent instructions, which is more efficient.
  • the multi-round interaction type can resolve disputes at a lower cost.
  • 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.
  • its dispute window period will also be longer.
  • ZK-Rollup is different from Optimistic Rollup because ZK-Rollup uses zero knowledge proof technology.
  • ZK refers to the ability to prove something (a transaction or state) to another party without disclosing necessary information.
  • Tx21, Tx22, and Tx23 are packaged into Batch M, and the hash values of these transactions are organized into a Merkle tree to generate a Merkle Root, and the hash value of the Merkle Root is filled into the Tx_Root in the Header of the generated Batch M, and the Pre State Root, Post State Root, and Timestamp are generated and filled into the Batch M Header.
  • 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 the correct execution of the batch in sequence based on the Pre State Root. After the transaction, you only need to verify the proof to confirm this, without having to re-execute the transactions in the Batch to verify.
  • a computational circuit Before generating a proof, a computational circuit can be created. This circuit is actually a specific algorithm that can be pre-written for the logic of verifying transactions and states. This pre-written process is included in a process called trusted setup, through which the Proving Key and Verifying Key can also be generated. The created circuit can be set in a proposer (or prover) on Layer2. It should be noted that the circuit created for the logic of verifying transactions and states is bound to its Proving Key and Verifying Key. Both the Proving Key and the Verifying Key can be made public and are bound to the circuit.
  • the process of generating proof can be that the Sequencer packages all transactions in a batch in Layer2 (including sender, receiver, amount) and the Pre State Root, Post State Root and Proving Key before and after the execution of the transactions in this batch and sends them to a prover on Layer2.
  • the prover converts this information into a special form, called a witness (witness; select part of it as public input and the other part as private input).
  • the prover uses the zero-knowledge proof calculation circuit (a specific algorithm) arranged inside it to verify the validity and correctness of the public input + private input. If the verification is correct, the circuit execution is successful, otherwise the circuit execution fails. If the circuit execution is successful, the prover can output a proof, which is used to prove that the packaged data is valid and correct.
  • the size of this proof is small, generally only a few dozen bytes.
  • the above process of generating proof is similar to the process of re-execution, and contains a lot of circuit calculations, which is more complicated, so it is generally time-consuming
  • the private input cannot be deduced from the proof itself. Only the party who knows the verification key of the zk-SNARK can verify the proof encrypted with the corresponding creation key.
  • the public input can be used to verify the validity and correctness of the packaged data, but it cannot be used to obtain the specific content of the packaged data.
  • the prover can publish a smaller proof to Layer 1 through Relayer, and it can be quickly verified by the Rollup Contract.
  • the proof is small in size, which further reduces the consumption of Gas on Layer 1.
  • this verification process is usually completed automatically by the smart contract, and there is no need to set a window period like OP-Rollup, and asset withdrawal will also become fast, which is one of the main feature differences between OP-Rollup and ZK-Rollup.
  • the specific verification process is as follows: first, the public input (which can be calculated from transaction 1 submitted in Block N, for example, when transaction 1 is submitted to the Rollup Contract of Layer1, it is calculated by the automatic execution calculation logic in the Rollup Contract), proof, and verification key (the verification key can be saved and provided to the Rollup Contract through the governance contract on Layer1) are input into the verification logic in the smart contract (for example, the 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.
  • the public input which can be calculated from transaction 1 submitted in Block N, for example, when transaction 1 is submitted to the Rollup Contract of Layer1, it is calculated by the automatic execution calculation logic in the Rollup Contract
  • proof the verification key
  • the state of the entire Layer2 is often optimized to a circuit-friendly structure (merkle tree). Therefore, the ZK-kRollup system needs to consider the structure of the circuit, thereby constraining the Layer2 transaction and account model.
  • ZK-Rollup including zksync, StarkNet, Scroll and other solutions, only specific transaction scenarios are implemented, making it even more difficult to be compatible with the Ethereum virtual machine and support Turing completeness, that is, it is difficult to support more complex contracts.
  • the present application discloses a method for realizing a two-layer network convolution, and the architecture relied on on Layer2 is shown in FIG5 .
  • At least Relayer, TxPool, Sequencer, and Prover are included here.
  • the main function of Relayer is to submit transactions or operations on Layer2 to Layer1, that is, to bridge Layer1 and Layer2, which may include submitting user transactions on Layer2 packaged by Sequencer to Layer1, and submitting the proof generated by Prover on Layer2 to Layer1.
  • Relayer may not be included, but Sequencer may submit the packaged user transactions on Layer2 to Layer1, and Prover may submit the generated proof to Layer1.
  • the latter is to integrate the functions of Relayer into Sequencer and Prover.
  • the role of Relayer in the entire solution will no longer be emphasized in the following.
  • TxPool is used to receive transactions sent by users on Layer2.
  • the Sequencer pulls transactions from the TxPool, sorts and packages these transactions according to the timestamps in the pulled transactions, organizes the hash values of these transactions into a Merkle tree, generates a Merkle Root, and fills the hash value of the Merkle Root into the Tx_Root in the Header of the generated Batch M. For example, as shown in Figure 4, Tx21, Tx22, and Tx23 are packaged into Batch M, and the last Tx23 is sorted in chronological order and repeated once to complete the 4 transactions, and then the root of the 2-fork Merkle tree is calculated. In addition, the Sequencer also executes the three transactions Tx21, Tx22, and Tx23 in sequence based on the state before the execution of the transaction in Batch M.
  • the Sequencer organizes the state before execution into a Merkle tree, and stores the hash value of the root node of the Merkle tree in the Pre State Root field of the Batch M Header. It also organizes the state after the transaction execution in Batch M into a Merkle tree, and stores the hash value of the root node of the Merkle tree in the Post State Root field of the Batch M Header.
  • TEE Trusted Execution Environment
  • TEE is a trusted execution environment that is completely isolated from the outside and based on the security extension of CPU hardware.
  • the industry pays great attention to the TEE solution.
  • TEE solutions such as TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone and AMD PSP (Platform Security Processor) in hardware.
  • TEE can play the role of a black box.
  • the code and data executed in TEE cannot be peeped even at the operating system layer. They can only be operated through the pre-defined interfaces in the code.
  • TEE In terms of efficiency, due to the black box nature of TEE, the calculation in TEE is plain text data, not the complex cryptographic calculations in homomorphic encryption, and the efficiency of the calculation process is almost lost. Therefore, the use of TEE technology can largely meet the trusted computing needs in blockchain scenarios with relatively small performance losses.
  • the present application provides a method for implementing a two-layer network rollup, including the following:
  • 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 execution of the packaged transactions and generates a first post-state root.
  • 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.
  • Rollup Contract can be deployed on Layer1 in Rollup.
  • the transaction pool TxPool can receive the initiated Layer2 transactions. Assume that TxPool collects Layer2 transactions such as Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24.
  • the Sequencer can pull transactions from the transaction pool, sort and package these transactions according to the timestamps in these transactions. For example, as shown in Figure 4, Tx21, Tx22, and Tx23 are sorted and packaged into Batch M, and the hash values of these transactions are organized into a Merkle tree to generate a Merkle Root, and the hash value of the Merkle Root is filled into Tx_Root in the Header of the generated Batch M.
  • the Merkle Root is the first transaction root of Batch M.
  • the status is:
  • These states can be the initial states before the package transaction is executed.
  • Sequencer can organize all state values of transactions in Batch M before execution according to the Merkle tree and obtain the Merkle root, i.e., the first pre-state root. Sequencer 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, i.e., the Pre-State Root in Figure 4.
  • Sequencer can execute packaged transactions in sequence based on the initial state, thereby generating a state after execution, for example:
  • Sequencer can organize all states obtained after the transactions in Batch M are executed in sequence according to the Merkle tree and obtain the Merkle root, which is the first post-state root. It can also lock the Merkle root obtained by organizing the hash of all state values of transactions in Batch 1 after they are executed in sequence according to the Merkle tree in the header of the Batch, which is the Post-State Root.
  • sequencer can send the packaged Layer2 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.
  • Sequencer can (or through Relayer) send a transaction 1 (first mainnet transaction) calling Rollup Contract to Layer1, which contains the fields in Batch M Header and compressed Tx21, Tx22, and Tx23. After compression, the space occupied by Tx21, Tx22, and Tx23 can be greatly reduced.
  • the interface in the called Rollup Contract contract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas fee) location calldata.
  • calldata is a special data location (data location) used to store input data called by functions. Specifically, calldata data is generally stored in Ethereum transaction data. This data cannot be changed after Ethereum is blocked, that is, it is read-only, and it usually saves more gas than other data locations (such as memory and storage).
  • the Rollup Contract can be executed in a virtual machine (such as Ethereum Virtual Machine, EVM), or in a container (such as docker), but this is not limited here.
  • the Sequencer can (or through the Relayer; the Sequencer/Relayer initiates through an external account on the mainnet) initiate a transaction to the blockchain to call the Rollup Contract on the mainnet, which can trigger the execution of the contract.
  • the content of the transaction includes, for example, the from field, the to field, the value field, and the data field.
  • the from field can be the account address of the transaction initiator (the mainnet external account address of the Sequencer/Relayer), 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.
  • the address of the smart contract being called in the to field it can be indicated that a smart contract on the blockchain is being called.
  • a smart contract can generally include one or more functions, and each function can include some input parameters.
  • the data field can be used to specify a function in the smart contract to be called, and the parameters to be passed in the data field can be filled in. As mentioned above, the data field can specify the call to the commitBatch() contract interface.
  • the compressed Tx21, Tx22, and Tx23 in the first main network transaction can be stored in calldata, and the Current State Root in the contract storage can be updated to Post State Root and the parameters can be passed in. No more details.
  • the result of contract execution can change the storage of the contract, that is, the world state of the contract.
  • the execution result or related information of the transaction can be recorded in the receipt of the blockchain.
  • the contract execution result/related information can be expressed as an event in the receipt.
  • the structure of the event is, for example, in the following format:
  • the number of events can be one or more.
  • Each event can include fields such as topic and data.
  • the format of the event output when the transaction is executed can be specified in the contract.
  • the blockchain client or blockchain node can listen to events of a specific topic, and pull the content of the corresponding msg when listening to a specific topic event, and can perform preset processing after listening to a specific topic or certain content in the corresponding msg.
  • the blockchain nodes on the main network can store the execution results in the msg corresponding to a topic, so that the Sequencer/Relayer can listen to the topic through its own built-in blockchain client to perform The corresponding execution results can be obtained.
  • the first mainnet transaction has been successfully executed on the mainnet Rollup Contract.
  • Prover/Relayer After Prover/Relayer monitors the corresponding topic, it can be determined that the transaction that previously called the mainnet Rollup Contract has been executed on the mainnet. In this way, Prover can execute the following S130 step. In this way, Prover can confirm the execution result of the blockchain node on the mainnet by monitoring specific events, and then perform S130 verification, thereby avoiding verification when the first mainnet transaction may not be executed on the mainnet due to some reasons, such as the first mainnet transaction was not sent successfully, or the mainnet Rollup Contract failed to verify the first mainnet transaction itself. Of course, S130 can also be executed directly after S120.
  • S130 The prover verifies the first transaction root and the first pre-state root; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root. 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 the second main network transaction.
  • the prover verifies the first transaction root, including: the prover generates a second transaction root of the packaged transaction, and verifies whether the first transaction root is equal to the second transaction root.
  • the prover can organize the hash values of the packaged transactions Tx21, Tx22, and Tx23 into a Merkle tree and then generate a Merkle Root, that is, in the same way as the Sequencer, the hash values of these transactions are organized into a Merkle tree and then a Merkle Root is generated, and the Merkle Root is the second transaction root. In this way, the prover can verify whether the second transaction root is equal to the first transaction root sent by the Sequencer.
  • 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.
  • the prover can organize the hash value of the initial state sent by the sequencer according to the Merkle tree and generate a Merkle root, that is, the second 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.
  • the prover verifies that the second transaction root is equal to the first transaction root sent by the Sequencer, and the second previous state root is equal to the first previous state root sent by the Sequencer, it means that the first transaction root sent by the Sequencer and the first previous state root are correct, and the subsequent content can be executed.
  • the prover can execute the packaged transactions in sequence 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, that is, 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 means that the execution process of the Sequencer is correct, because starting from the same initial state, the execution result of the Sequencer executing the packaged transactions in sequence is the same as the execution result of the prover executing the same packaged transactions in sequence independently.
  • the prover verification can sign the information of the packaged transaction. Specifically, the prover verification can sign at least one of the Batch number of the packaged transaction, the transaction root of the packaged transaction, and the Post State Root corresponding to the packaged transaction. Signing at least one of these contents indicates that the prover recognizes the results generated by the Sequencer executing this Batch.
  • a private key usually represents the identity of the party that owns the private key. It can only be held by the owner of the private key and cannot be made public, while the corresponding public key can be made public.
  • Signing with a private key can indicate the private key owner's approval of certain information in the digital world. The signed information can also indicate the private key owner in the protocol message.
  • An act of signing Generally, an owner has a private key alone. The owner can use his private key to sign a message and send it to other parties. After receiving the signature, the recipient can use the corresponding public key to verify the signature. If the verification is successful, the recipient can confirm that the owner signed the message and the signed message has not been tampered with.
  • the prover can be implemented using TEE.
  • TEE has a trusted execution environment that is completely isolated from the outside, so the private key can be held in a confidential manner. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the information of the packaged transaction with its own private key to indicate approval of the signature content.
  • TEE technology includes Intel SGX (Intel Software Guard Extension, hereinafter referred to as SGX), AMD SEV, etc.
  • SGX Intelligent Software Guard Extension
  • Prover in Layer2 can create an Enclave (enclave or enclave) based on SGX technology as a TEE for performing verification.
  • Prover can use the newly added processor instructions in the CPU to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory to reside in the above-mentioned Enclave.
  • EPC Endclave Page Cache, enclave page cache or enclave page cache
  • the memory area corresponding to the above-mentioned EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU.
  • MEE Memory Encryption Engine
  • the content in this memory area can only be decrypted in the CPU core, and the key used for encryption and decryption is only generated and stored in the CPU when the EPC is started. It can be seen that the security boundary of Enclave only includes itself and the CPU. No privileged or non-privileged software can access Enclave. Even the operating system administrator and VMM (Virtual Machine Monitor, or Hypervisor) cannot affect the code and data in Enclave, so it has extremely high security. Under the premise of the above security guarantee, the CPU can process data in Enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency.
  • Intel has provided support for SGX since the sixth generation of CPUs. Moreover, before leaving the factory, the manufacturer will burn the Provisioning Key and Sealing Key into the fuse register in the CPU for such SGX-supporting CPUs.
  • the fuse register is a one-time programmable register. Once the data is burned in, the fuse will be blown, making the subsequent contents of the register only readable but no longer writable.
  • Intel promises that the key burned into the fuse register is randomly generated; in addition, it also promises that all backups of the burned-in key will be destroyed once burned, that is, even Intel itself does not know the burned-in key.
  • the Provisioning Key can represent some information in the CPU, such as the CPU code (such as the sixth generation Core, seventh generation Core, etc.), model (such as desktop, mobile, etc.).
  • the Provisioning Key is not used directly for encryption, signing and other operations, but an attestation key derived from the Provisioning Key is used for them, so the Provisioning Key plays a deployment role.
  • a User Enclave can be created to execute the program code specified by the user (such as the transaction execution code loaded into the TEE, including virtual machines and smart contracts).
  • the User Enclave created by the user often needs to prove itself to be trustworthy first, which involves the authentication of the Enclave, such as the local authentication and remote authentication mentioned below.
  • the CPU Before initiating remote authentication, the CPU can detect whether there is an attestation key. If not, it initiates initialization.
  • the initialization process can be based on the key generation protocol, through interaction with the Intel server (specifically, it can be the Provisioning Enclave in SGX, which is an architecture-level Enclave), and generate EPID (Enhanced Privacy IDentification) according to the generation rules of the Provisioning Key.
  • the EPID is used as an attestation key and is generally used as a private key in an asymmetric encryption key.
  • the generated EPID can be stored in an Enclave for subsequent signing. This Enclave is generally called a Quoting Enclave.
  • EPID can also be stored in In the CPU registers, only the architecture-level Enclave has the authority to obtain from the CPU, so the Quoting Enclave can also obtain the EPID from the CPU registers.
  • SGX specifically the Provisioning Enclave mentioned above
  • Intel can interact with the Intel server, so that Intel can obtain the public key corresponding to the EPID through the interaction process.
  • the public key corresponding to the EPID will not be made public and is only kept by the Intel server. This feature is suitable for authentication by Intel's server (also called IAS, Intel Attestation Server) in the subsequent remote authentication process.
  • the developer of the application can sign the code/data that needs to be loaded into the Enclave (for example, the transaction execution code loaded into the TEE, including the virtual machine and the smart contract) with the developer's private key and transmit it to SGX through the application.
  • the issuer's public key can also be transmitted to SGX (it can also be the certificate of the issuer that is uploaded, which 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).
  • an application can be submitted to SGX through the instruction set integrated in the CPU to create an Enclave.
  • This Enclave is generally called Application Enclave (equivalent to the User Enclave mentioned above).
  • 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 SGX management mechanism of the CPU.
  • MREnclave Based on the characteristics of the Hash algorithm, tampering with code/data, allocating extra pages, and copying malicious code in, any of these three, even if only a small change, will lead to a very different result of MREnclave; different Application Enclaves have different MREnclave values. Based on this property, MREnclave can identify the Enclave on the one hand, and can also be used to verify the integrity of the Application Enclave on the other hand.
  • the integrity of the Application Enclave can be verified using the hash value contained in the above certificate (the hash value contained in the certificate is the same as the generation rule of MREnclave, so it should be consistent under normal circumstances) to determine whether the privileged software has tampered with the program/data during the creation process, such as whether extra pages are allocated, whether malicious code is copied in, or whether the copied data is tampered with, etc.
  • SGX when SGX creates an Application Enclave, it can compare the aforementioned MREnclave with the hash value in the certificate signed by the Application Enclave issuer through an initialization instruction. If they match, it means that the code/data loaded into the Application Enclave is consistent with the expected one, that is, the code/data of the issuer; otherwise, if they do not match, it means that there is a problem in the creation process and a failure result is returned. If they match, SGX also hashes the issuer's public key in the certificate to obtain MRSigner. Similarly, MRSigner can be used to identify the issuer. The MRSigner can also be saved in the aforementioned SECS.
  • the SECS structure is equivalent to the identity of the Enclave from a certain perspective. It has two identities of the Enclave at the same time: MREnclave is the measurement of the Enclave, and MRSigner is the measurement of the issuer.
  • the content in the Application Enclave needs to be remotely authenticated to prove that it is a legitimate and trusted Enclave created in SGX.
  • the content in the Application Enclave needs to be authenticated by the Quoting Enclave.
  • remote authentication is performed, which requires the interaction between the Application Enclave and the Quoting Enclave.
  • the Application Enclave needs to prove to the Quoting Enclave that it is an Enclave on the same SGX and is trustworthy.
  • the process of the Application Enclave proving to the Quoting Enclave that it is an Enclave on the same SGX is called local authentication.
  • 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 - REPORT Key.
  • the identity information and attributes of the Application Enclave and the platform hardware TCB information can be obtained and used as the content of the Report; in addition, the data that the user wants to interact with can be attached to the Report.
  • the MAC algorithm When calling the EREPORT instruction, the MAC algorithm will also be used to calculate the REPORT Key and the above Report to obtain the first MAC code.
  • the first MAC code can be used as the signature of the Report for integrity verification.
  • the above-mentioned Application Enclave calls the CPU's EREPORT instruction, and the CPU can directly obtain the Application Enclave's identity information and attributes, and the platform hardware TCB information internally, thereby ensuring that this information will not be interfered with by the Application Enclave and will not be tampered with; moreover, the CPU uses the root key and combines the Quoting Enclave's MREnclave to generate a REPORT Key.
  • the Quoting Enclave can call the EGETKEY instruction provided by the CPU and use its own MREnclave as an input parameter, so that the CPU can obtain the same REPORT Key based on the same root key and the same MREnclave as in the EREPORT instruction. Furthermore, the Quoting Enclave can use the same MAC algorithm to calculate the second MAC code from the obtained REPORT Key and the received Report.
  • the second MAC code is the same as the first MAC code received, it means that the integrity of the Report sent by the Application Enclave has not been destroyed, 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 in combination with the same CPU root key, when the verification MAC code is passed, the Quoting Enclave can confirm that the Application Enclave is an Enclave on the same SGX.
  • the Quoting Enclave can confirm that the Application Enclave is an Enclave on the same SGX.
  • software outside the SGX can challenge the Application Enclave (the software outside the SGX is also called the challenger), requiring the Application Enclave to prove to the challenger that it is a legitimate Enclave and that a trusted program is running in it.
  • the challenger can use the services provided by the Application Enclave.
  • the challenger can first challenge the Application Enclave, requiring the Application Enclave to prove that it is a legitimate Enclave and that a trusted program is running in it.
  • the Application Enclave can generate a report, which is generally called a Quote.
  • This Quote report may include the hash value of the code/data loaded in the Application Enclave, that is, the aforementioned MREnclave, and may also include the aforementioned MRSigner.
  • 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 on the MREnclave using EPID, or a signature made on the MREnclave and MRSigner.
  • the Application Enclave can send the Quote report to the challenger. Since the challenger does not hold EPID The challenger cannot verify the signature of the public key corresponding to the EPID, and 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, IAS can verify the correctness of the signature in the Quote with the public key corresponding to the EPID, and return an Attestation Verification Report (AVR).
  • AVR Attestation Verification Report
  • the AVR report can include the Quote report and the verification result of the signature in the Quote, such as whether the signature verification is correct or wrong.
  • IAS can sign the content of the AVR report with Intel's private key, and attach the signature (for example, recorded as Signature2) and the certificate to the AVR report, and return the AVR report to the challenger.
  • the challenger can use the public key in the certificate (corresponding to Intel's private key) to verify Intel's signature.
  • the AVR report may not include the certificate, but the challenger can download Intel's certificate by himself (Intel's official website or other authoritative websites can provide the certificate for download), and use the public key in the downloaded certificate to verify Signature2.
  • the challenger can verify the MREnclave and MRSigner in Quote. For example, the challenger can obtain the MREnclave of the code/data loaded into SGX and the MRSigner of the issuer in advance from the issuer, and then compare them with the MREnclave and MRSigner in Quote to confirm that the code/data loaded in the SGX is credible and issued by a legitimate issuer.
  • the initiator of the transaction on Layer2 can challenge the TEE in the prover as a challenger. This process includes the interaction between the TEE in the prover and the IAS, and the interaction between the challenger and the IAS. According to the AVR report returned by the IAS, the initiator of the transaction can confirm that the TEE in the prover is legal and the code/data loaded in it is credible. Therefore, the initiator of the transaction on Layer2 can trust the TEE in the prover.
  • TEE can sign the input code/data after hashing, so as to use its own credibility to guarantee that the input of execution is also credible; TEE can also sign the hash value of the output (that is, the result of execution), also using its own credibility to guarantee that the input of execution is also credible.
  • the prover verifies that the packaged transaction is executed independently in sequence based on the initial state (also known as replay), it signs the information of the packaged transaction, that is, it uses its own credibility to guarantee that the output result is credible. Furthermore, the prover can send the signature as a proof to the blockchain ledger of the main network through the second main network transaction.
  • the prover can send the signature as a proof to the blockchain ledger of the main network through the second main network transaction.
  • anyone who questions the signature can verify it by challenging the TEE in the prover.
  • this process also needs to interact with IAS, so as to confirm from the report returned by IAS that the TEE and the code/data loaded therein are credible, and based on the trust in the TEE, it is confirmed that the transaction information signed by it is credible.
  • the CPU can process data in the Enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency.
  • This is much faster than the ZK-Rollup method.
  • the time required for ZK-Rollup to generate 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).
  • the generated proof is the size of a signature, which is about tens of bytes, similar to ZK-Rollup.
  • the verification of the signature is the process of using the public key of the TEE to verify the signature. As long as the public key is credible, the verification will be credible and fast.
  • the prover can use the signature as proof and send it to the blockchain account book of the main network through the second main network transaction, including the prover using the signature as proof and sending it to the main network through the second main network transaction, calling the roll-up contract on the main network; after receiving the transaction, the roll-up contract verifies the correctness of the signature through the verification logic in the contract.
  • the above scheme is also called the EPID scheme.
  • each challenge requires the challenger and TEE to communicate with the remote IAS, which will cause a large delay, and even many running entities cannot access Intel services during operation. Therefore, the improved SGX DCAP authentication protocol provides localization of IAS.
  • IAS IAS
  • cloud service platforms and data centers localize IAS on the control machine.
  • the localized control machine is also called a localized authentication service (Verify Service).
  • SGX DCAP provides trust in the form of a certificate chain, and the only root of trust is Intel SGX Root CA.
  • Intel SGX DCAP the full name of which is Intel Software Guard Extensions Data Center Attestation Primitives, is a remote attestation technology designed for data center environments.
  • Intel SGX provides security protection technology at the hardware level. It can create a secure area called an "enclave" where data and code are protected by hardware encryption. Even if the operating system, virtual machine manager or BIOS is attacked, the data in this area cannot be stolen or tampered with.
  • "attestation” is a mechanism used to prove that the code is running in a real enclave and that the code and data have not been tampered with. In a traditional SGX environment, this attestation process needs to be performed through Intel's Remote Attestation Service (IAS).
  • IAS Intel's Remote Attestation Service
  • DCAP decouples the attestation process from Intel's services, allowing data centers to perform attestation locally, thereby improving efficiency, enhancing controllability, and reducing dependence on Intel services.
  • SGX DCAP is a solution that uses SGX technology in a data center environment, which provides a more efficient and controllable verification mechanism.
  • the authentication service (Verify Service) of the data center can obtain a certificate from Intel IAS, which generally has a validity period.
  • the deployed SGX instance can complete the generation of remote reports by interacting with the local verification service (equivalent to the local IAS in this case) without interacting with Intel.
  • the verification service of the data center 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 signature is verified by Intel's public key to ensure the credibility of the public key of the verification service 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 public key of the verification service in the certificate.
  • the certificate can include an validity period, and the role of the validity period is as described above.
  • the TEE in the prover creates a protected execution environment (User Enclave) locally and generates a key pair in it.
  • This key pair includes a public key and a private key, where the public key will be used to generate a proof report (Quote).
  • the TEE in the attestor then submits the public key and some information about the User Enclave (such as its measurements) to the local Quoting Enclave (QE) to request a proof report.
  • the QE signs this information and packages the signature and other information into the proof report.
  • the TEE in the prover submits the proof report to the Verify Service, which The service will verify the validity of the report and sign the public key contained therein to generate a certificate.
  • This certificate contains the signature of the attestation service on the TEE in the prover and may also include other content, similar to the aforementioned remote attestation report, so it can also be regarded as a remote attestation report generated by the attestation service.
  • the generated certificate will be returned to the TEE of the prover.
  • the prover can then sign the execution result with its own private key and provide the certificate. In this way, others can verify the signature with the public key in the certificate to ensure that the execution result is credible.
  • the certificate is issued by the authentication service, that is, it is guaranteed by the authentication service using its own private key signature.
  • the credibility of the certificate can be further guaranteed by the certificate issued by Intel IAS to the authentication service.
  • the trust transfer relationship between the above multiple certificates and signatures is the principle of certificate chain.
  • the prover can send the certificate to the blockchain account book of the main network through the second main network transaction.
  • the prover can send the certificate and the signature of the prover to the blockchain account book of the main network through the second main network transaction.
  • the certificate includes the remote authentication report generated by IAS for the prover, so that the verifier can verify the certificate to determine that the signature of the prover on the transaction information is legal.
  • the certificate may include the certificate issued by the authentication service for the prover. If based on the trust in the authentication service, it can be extended to the certificate issued by the authentication service for the prover, so that the verifier can use the public key in the certificate to verify the signature of the prover.
  • the certificate issued by the authentication service for the prover may also be necessary to include the remote authentication report generated by IAS for the authentication service. In this way, the authenticity of the authentication service signature can be guaranteed through Intel's authoritative authentication (i.e., the remote authentication report, which is equivalent to the certificate issued by Intel for the authentication service).
  • the certificate issued by the authentication service for the prover can transmit trust downward, thereby ensuring the authenticity of the signature of the prover. This is how SGX DCAP provides trust in the form of certificate chains.
  • the verification logic executed by the above-mentioned verifier can be built into the Rollup Contract contract, and can be provided to the outside in the form of a contract interface, such as a verification interface.
  • the prover uses the signature as proof and sends it to the main network through a second main network transaction.
  • it can be a blockchain ledger called in the transaction, including the prover using the signature as proof and sending it to the main network through a second main network transaction, calling the verification interface of the Rollup Contract contract on the main network, and the signature can be passed in through the interface.
  • the verification logic can be executed inside the verification interface, specifically including verifying the legitimacy of the signature.
  • the process of verifying the legitimacy of the signature mainly includes using the public key of the prover to verify the legitimacy of the signature.
  • the certificate of the certifier corresponding to the signature can also be transmitted through the second main network transaction through the verification interface, and the certificate can include the public key of the certifier.
  • the certificate can include a remote authentication report generated by the IAS for the certifier, or include a certificate issued by the authentication service for the certifier (it can also include a remote authentication report generated by the IAS for the authentication service).
  • verifying the certificate can include using Intel's authoritative public key to verify the legitimacy of the certifier certificate, or 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.
  • TEE is used as the prover on the second-layer network. Since the transaction replay and verification in TEE is close to the speed of native execution, it can bring lower latency.
  • the above Figure 4 illustrates the case where there are four global states on Layer 2, namely, Alice, Bob, Charlie, David's four global states.
  • a batch on Layer2 may contain hundreds or even thousands of transactions, and these transactions may involve more states, such as tens of thousands of states.
  • the transactions in Layer2 include transactions involving contracts on Layer2, then a contract may involve more states, and there are more states in Layer2 as a whole, such as tens of thousands of states.
  • the sorter sends the initial states of all states to the prover in the second-layer network, and the amount of data is large. Therefore, the present application provides a method for realizing the convolution of the second-layer network, including the following:
  • 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 transaction, and executes the packaged transactions in sequence based on the initial state before the execution of the packaged transaction and generates a first post-state root.
  • 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.
  • the transactions in Layer2 involve a total of 8 states, such as the states corresponding to the 8 hash values 8, 9, 10, 11, 12, 13, 14, and 15 in the lower left corner of Figure 6.
  • the transactions packaged into Batch M affect the states corresponding to 8 and 9 for Alice and Bob before and after execution, and do not involve the states corresponding to the 6 hash values 10, 11, 12, 13, 14, and 15.
  • the sequencer can send the SPV certificate of the packaged transaction read set before the execution of the packaged transaction to the prover of the second-layer network.
  • the sequencer can send the states corresponding to tree nodes 8 and 9, as well as the SPV proof consisting of the hash value of node 5 and the hash value of node 3 to the prover of the second-layer network. In this way, it is possible to avoid sending the states corresponding to the six leaf nodes 10, 11, 12, 13, 14, and 15 to the prover.
  • SPV itself comes from the concept of Bitcoin, and its full name is Simplified Payment Verification.
  • SPV proof uses Merkle tree to work.
  • the states involved in Batch M form a Merkle tree, and the root of the tree (Merkle root) is contained in the Header of Batch M.
  • the structure of the Merkle tree makes it possible to verify whether any state exists under a specific Merkle root through a very short path (Merkle path). This path only contains some necessary nodes, rather than the state content corresponding to all leaf nodes.
  • an SPV proof includes the states corresponding to two leaf nodes (indicated in yellow) and a Merkle path (indicated in red).
  • the Merkel path in the SPV proof mentions Merkle, which is a tree-like data structure. It can be the Merkle tree in Bitcoin, the MPT tree in Ethereum, or SMT, etc.
  • MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (compressed prefix tree, a more space-saving Trie tree, dictionary tree).
  • Merkle Tree Merkle Tree algorithm calculates a hash value for each transaction, and then connects two by two to calculate the hash again until the top Merkle root.
  • Ethereum uses an improved MPT tree, such as a 16-way tree structure, which is usually referred to as MPT. Tree. Taking the state trie in Ethereum mentioned above as an example, the state trie contains the key and value pairs (also written as key-value, abbreviated as kv or kv) of the storage content corresponding to each account in the Ethereum network.
  • the "key” in the state trie can be a 160-bit identifier (such as the address of an Ethereum account or part of the hash value of an address, collectively referred to as an account address below), and this account address is distributed in the storage from the root node to the leaf node of the state trie.
  • the "value” in the state trie is generated by encoding the information of the Ethereum account (using the Recursive-Length Prefix encoding (RLP) method). As mentioned above, for external accounts, the values include nonce and balance; for contract accounts, the values include nonce, balance, codehash, and storage_root.
  • RLP Recursive-Length Prefix encoding
  • state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state_root points to a state tree state trie in the form of MPT.
  • the root node of this MPT tree is generally an extension node (Extension Node) or a branch node (Branch Node), and the hash value of this root node is generally stored in state_root.
  • Extension Node Extension Node
  • Branch Node branch node
  • the root node can be connected to one or more layers of Extension Node/Branch Node below, and these multi-layer tree nodes can be collectively referred to as intermediate nodes (Internal Node).
  • the account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair.
  • This key can also be a part of sha3(Address), that is, a part of the hash value of the account address (the hash algorithm, for example, uses the sha3 algorithm), and the stored value value can be rlp(Account), that is, the rlp encoding of the account information.
  • the account information is
  • a tuple consisting of [nonce, balance, storageRoot, codeHash].
  • Contract accounts generally include Nonce, Balance, Storage root, and CodeHash. Among them, Nonce is the transaction counter of the contract account; Balance is the account balance; Storage root corresponds to another MPT, through which Storage root can be linked to contract-related status information; CodeHash is the hash value of the contract code. Whether it is an external account or a contract account, its account information is generally located in a separate leaf node (Leaf Node). From the Extension Node/Branch Node of the root node to the Leaf Node of each account, there may be several branch nodes and extension nodes in the middle.
  • the state trie can be a tree in the form of MPT, generally a 16-way tree, that is, each layer can have up to 16 child nodes.
  • Extension Node it is used to store common prefixes, and it generally has 1 child node, which can be Branch Node.
  • Branch Node it can have up to 16 child nodes, which may include Extension Node and/or Leaf Node.
  • this Storage Trie tree also stores key-value pairs.
  • the key indicates the address of the state variable, and its value can be the result obtained after the position of the state variable declaration in the contract (the value counting from 0) is processed by certain rules, such as sha3 (the position of the state variable declaration), or sha3 (contract name + the position of the state variable declaration).
  • the Storage trie can also be a tree in the form of MPT, which is generally a 16-way tree, that is, for a Branch Node, it can have up to 16 child nodes, which may include Extension Node and/or Leaf Node. For an Extension Node, it can generally have 1 child node, which can be a Branch Node or a Leaf Node.
  • 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.
  • 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 position of storedData, which will be described in detail 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).
  • the key values are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage Trie.
  • Leaf Node Account C is an external account, and its key is sha3(Address C), which is the hash value of the address of account C (the hash algorithm uses the sha3 algorithm, for example).
  • the value stored in it can be (Account), where the account information Account is a tuple consisting of [nonce, balance].
  • Account C is an external account, its account information is two items, nonce and balance (codehash and storage root are omitted here, and the following are similar).
  • the address of Account C is the key, and its values are sequentially distributed from the root node to the leaf node (i.e., Leaf Node Variable C) of the state Trie.
  • states including the k-v of external accounts and the k-v of contract accounts, are ultimately stored in the database.
  • the storage in the database does not directly store the states of these accounts, that is, it does not directly store the k-v of these accounts, but stores the k-v value of each tree node itself.
  • leaf node A3 the key of the leaf node is composed of a7 in the shared nibble of root node A8 (Extension Node), slot f in the middle node A7 (Branch Node), and 9365 in the key-end of leaf node A3, which is a7f9365.
  • Balance 1.1ETH
  • the key of the leaf node is composed of a7f9365 in the shared nibble of root node A8 (Extension Node).
  • s1 are sequentially combined to form the key of the leaf node, which is a77d397.
  • s1 can be H(A10), which is the hash of the root node A10 of the next tree layer.
  • the leaf nodes of A1, A2 and A3 store the information of external accounts
  • the leaf node of A4 stores the information of contract accounts.
  • It contains the next level MPT, forming a Storage Trie, which is used to store the state variables in the contract account.
  • the key of the leaf node is composed of slot f in root node A10 (Branch Node) - a in shared nibble in intermediate node A13 (Extension Node) - slot 9 in intermediate node A14 (Branch Node) - 9365 in key-end in leaf node A16, which is fa99365.
  • 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 nibble(s), 2 indicates a Leaf Node containing an even number of nibbles, and 3 indicates a Leaf Node containing an odd number of nibble(s).
  • the hash value of the entire content of the next tree node is filled in the corresponding position of the previous tree node.
  • the key-value mapping of each tree node is actually stored, 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.
  • the tree node kv actually stored in the database is as follows:
  • H() is used to represent hash calculation. In this way, the hash value of the next tree node is anchored in the previous tree node. Through such layer-by-layer hashing, the root hash of the entire state trie tree is obtained, and the root hash is locked in the state root field of the block header.
  • the transaction Merkle tree in Bitcoin is similar. When a block contains 4 transactions, the leaf nodes of its Merkle tree are composed of these four transactions, that is, it will only have four leaf nodes and the depth of the tree is 2 layers. If a block contains 1024 transactions, there will be 1024 leaf nodes and the depth is 11 layers, which is obviously a larger tree.
  • 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 the general Merkle tree in some places. The main difference is that the number of leaf nodes, the depth and shape of the tree are fixed in advance.
  • the transaction Merkle tree in Bitcoin and the MPT tree in Ethereum mentioned above have variable tree depth and scale, that is, they are dynamic and unfixed.
  • SMT 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, and there are a total of 2,160 different addresses, that is, 2,160 accounts. In fact, Ethereum accounts can be stored using SMT (although it does not do so).
  • blank which is a preset value
  • leaf nodes may not be stored, and only non-blank leaf nodes may be stored.
  • the advantage of using SMT is that the size of the Merkle path can be compressed in many cases. For example, using 1 bit to represent the preset value is much smaller than using the full hash value (for example, the hash value length in hash256 is 256 bits). This greatly reduces the size of the SPV proof.
  • S230 The prover verifies the first transaction root, and verifies the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the prover verifies the first transaction root, similar to the aforementioned S130, which will not be repeated here.
  • 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, obtains 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.
  • Characteristics of hash calculation A small change in the value in each calculation will make a big difference in the final result. Based on this characteristic, the prover cannot falsify, that is, it cannot provide a wrong state in the leaf node or provide a wrong hash value of the Merkle tree node to produce a correct result, that is, it cannot produce a correct Merkle root.
  • 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 concatenated in sequence 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 concatenated in sequence 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 concatenated in sequence 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.
  • the prover executes the packaged transaction in order and generates the second post-state root.
  • the prover executes the packaged transaction in order based on the read set involved in the packaged transaction, updates the write set during the execution, and recalculates the Merkle root based on the updated write set based on the SPV proof to generate the second post-state root.
  • a processed Batch contains 3 transactions, namely:
  • Tx_21 Alice ⁇ Bob 20
  • Tx_23 Alice ⁇ Bob 20
  • the transactions in this Batch involve states of Alice and Bob, so the read set involved in this Batch can include the two accounts Alice and Bob.
  • the SPV proof of the read set in addition to the two read sets of Alice: 50 and Bob: 100, it can also include the hash value of node 5 and the hash value of node 3 in the Merkle tree. In this way, the prover executes all transactions in the Batch in order based on this Batch read set, that is, based on Alice: 50 and Bob: 100.
  • the read-write sets generated by executing Tx_21, Tx_22, and Tx_23 in sequence include the following:
  • 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.
  • 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.
  • 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.
  • the final state of this batch is Alice:
  • the prover combines the hash value of node 5 and the hash value of node 3 of the Merkle tree where the write set is located to obtain the hash value of the root node of the Merkle tree where the updated state is located, that is, the second post-state root.
  • the generated write set is still the content corresponding to the 8th and 9th nodes in the Merkle tree.
  • the state corresponding to node 8 Alice's balance is changed to 20 relative to the initial state of 50
  • the state corresponding to node 9 Bob's balance is changed to 130 relative to the initial state of 100.
  • the prover can recalculate the hash value of leaf node 8 based on Alice:20, and recalculate the hash value of leaf node 9 based on Bob:130, thereby generating a new hash value.
  • 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 (that is, the hash values of the two red nodes 3 and 5), thereby serving as the second post-state root.
  • 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, so as to verify whether the second post-state root is equal to the first post-state root.
  • the prover can verify whether the second post-state root is equal to the first post-state root. If they are equal, it means that the execution process of the Sequencer is correct, because starting from the same initial state, the execution result of the Sequencer executing the packaged transaction in sequence is the same as the execution result of the prover executing the same packaged transaction in sequence independently.
  • the prover verification can sign the information of the packaged transaction. Specifically, the prover verification can sign at least one of the Batch number of the packaged transaction, the transaction root of the packaged transaction, and the Post State Root corresponding to the packaged transaction. Signing at least one of these contents indicates that the prover recognizes the results generated by the Sequencer executing this Batch.
  • the prover can be implemented using TEE.
  • TEE has a trusted execution environment that is completely isolated from the outside, so the private key can be held in a confidential manner. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the information of the packaged transaction with its own private key to indicate approval of the signature content.
  • the prover can be implemented using TEE.
  • TEE has a trusted execution environment that is completely isolated from the outside, so the private key can be held in a confidential manner. In this way, after verifying that the second post-state root is equal to the first post-state root, the prover can sign the information of the packaged transaction with its own private key to indicate approval of the signature content.
  • the initiator of the transaction on Layer2 can challenge the TEE in the prover as a challenger. If the challenge is successful, the initiator of the transaction can confirm that the TEE in the prover is legal and the code/data loaded in it is credible. Thus, the initiator of the transaction on Layer2 can trust the TEE in the prover.
  • TEE can sign the input code/data after hashing, so as to use its own credibility to guarantee the input of execution is also credible; TEE can also sign the hash value of the output (that is, the result of execution), also using its own credibility to guarantee the execution. The input is also credible.
  • the prover verifies that the packaged transaction is executed independently in sequence based on the initial state (also known as replay), it signs the information of the packaged transaction, that is, it uses its own credibility to guarantee that the output result is credible. Furthermore, the prover can send the signature as proof to the blockchain account book of the main network through the second main network transaction.
  • the prover can send the signature as proof to the blockchain account book of the main network through the second main network transaction.
  • anyone who questions the signature can verify it by challenging the TEE in the prover; if the verification is successful, it can be trusted that the transaction information signed by it is credible based on the trust in the TEE.
  • the verification of the signature is the process of using the public key of the TEE to verify the signature. As long as the public key is credible, the verification will be credible and fast.
  • the prover can use the signature as proof and send it to the blockchain account book of the main network through the second main network transaction, including the prover using the signature as proof and sending it to the main network through the second main network transaction, calling the roll-up contract on the main network; after receiving the transaction, the roll-up contract verifies the correctness of the signature through the verification logic in the contract.
  • the prover can send the certificate to the blockchain account book of the main network through the second main network transaction.
  • the prover can send the certificate and the signature of the prover to the blockchain account book of the main network through the second main network transaction.
  • the certificate includes the remote authentication report generated by IAS for the prover, so that the verifier can verify the certificate to determine that the signature of the prover on the transaction information is legal.
  • the certificate may include the certificate issued by the authentication service for the prover. If based on the trust in the authentication service, it can be extended to the certificate issued by the authentication service for the prover, so that the verifier can use the public key in the certificate to verify the signature of the prover.
  • the certificate issued by the authentication service for the prover may also be necessary to include the remote authentication report generated by IAS for the authentication service. In this way, the authenticity of the authentication service signature can be guaranteed through Intel's authoritative authentication (i.e., the remote authentication report, which is equivalent to the certificate issued by Intel for the authentication service).
  • the certificate issued by the authentication service for the prover can transmit trust downward, thereby ensuring the authenticity of the signature of the prover. This is how SGX DCAP provides trust in the form of certificate chains.
  • the verification logic executed by the above-mentioned verifier can be built into the Rollup Contract contract, and can be provided to the outside in the form of a contract interface, such as a verification interface.
  • the prover uses the signature as proof and sends it to the main network through a second main network transaction.
  • it can be a blockchain ledger called in the transaction, including the prover using the signature as proof and sending it to the main network through a second main network transaction, calling the verification interface of the Rollup Contract contract on the main network, and the signature can be passed in through the interface.
  • the verification logic can be executed inside the verification interface, specifically including verifying the legitimacy of the signature.
  • the process of verifying the legitimacy of the signature mainly includes using the public key of the prover to verify the legitimacy of the signature.
  • the certificate of the certifier corresponding to the signature can also be transmitted through the second main network transaction through the verification interface, and the certificate can include the public key of the certifier.
  • the certificate can include a remote authentication report generated by the IAS for the certifier, or include a certificate issued by the authentication service for the certifier (it can also include a remote authentication report generated by the IAS for the authentication service).
  • verifying the certificate can include using Intel's authoritative public key to verify the legitimacy of the certifier certificate, or 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.
  • TEE is used as the prover on the second-layer network. Since the transaction replay and verification in TEE is close to the original The execution speed can therefore bring lower latency.
  • 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, in the same case, it takes 30 to 50 minutes (or hours) to generate proof from ZK-Rollup (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, but S230 is executed directly after S220, the time will be shortened to less. In addition, the generated proof is the size of a signature, which is about tens of bytes, similar to ZK-Rollup.
  • the information signature of the packaged transaction may 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.
  • the information signature for the packaged transaction may be at least one signature of the numbers of several consecutive batches packaged, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction; or at least one signature of the batch number in each group after the several consecutive batches packaged are grouped, the transaction root of the packaged transaction, and the post-state root corresponding to the packaged transaction.
  • the process may further include: the sequencer sends a first mainnet transaction that calls the wrapping contract to the mainnet, where the first transaction contains the fields in the Batch Header of the packaged transaction, as well as a compressed transaction or a compressed read-write set (termed as State Diff);
  • the prover can monitor the execution results of the contract on the main network.
  • the details are similar to the above embodiment and will not be repeated here.
  • the prover may also send the certificate and the signature together to the blockchain account book of the main network through the second main network transaction.
  • the certificate may include a remote authentication report generated by the IAS for the prover, or include the certificate including the certificate issued by the authentication service for the prover, or also include a remote authentication report generated by the IAS for the authentication service.
  • the prover uses the signature as proof and sends it to the blockchain account book of the main network through the second main network transaction, including the prover uses the signature as proof and sends it to the main network through the second main network transaction, calling the roll-up contract on the main network. It may also include: after the roll-up contract receives the transaction, the correctness of the signature is verified through the verification logic in the contract. After the roll-up contract receives the transaction, the correctness of the signature is verified through the verification logic in the contract, and it may also include: verifying the legitimacy of the certificate, and the certificate includes the public key of the prover.
  • the verification of the legitimacy of the certificate may specifically include:
  • parallel computing can be used to speed up the execution speed of transactions.
  • Parallel computing is relative to serial computing. It is an algorithm that can execute multiple instructions at a time. The purpose is to increase the computing speed and solve large and complex computing problems by expanding the scale of problem solving.
  • the so-called parallel computing can be divided into temporal parallelism and spatial parallelism.
  • Temporal parallelism refers to pipeline technology
  • spatial parallelism refers to the concurrent execution of calculations by multiple processors.
  • the execution process can generally use group execution or pipeline methods to improve efficiency. When the performance of Prover is high, the overall performance bottleneck lies in the process of Sequencer executing transactions.
  • the part of Sequencer that executes transactions can be decoupled, for example, decoupled into Executor, as shown in Figure 10; in this way, the aforementioned pipeline method can be used to improve the overall execution speed.
  • the Executor can be horizontally scaled (also called scaling out), that is, the Executor can be expanded into multiple entities (logical entities or physical entities), as shown in Figure 11; in this way, the aforementioned group execution method can be used to improve the execution speed of the execution link, thereby improving the utilization of Prover.
  • FIG. 10 The following first takes FIG. 10 as an example to provide an embodiment of a method for implementing a two-layer network convolution in a pipeline manner, including:
  • S310 The sequencer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, and sends them to the executor.
  • S320 The executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the execution of the subsequent packaged transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • the post-order packaged transaction refers to the package with a later sequence number relative to the pre-order packaged transaction in S330.
  • the sequence number of the post-order packaged transaction is N+1
  • the above S320 specifically includes: the executor generates the first transaction root of the transaction in the N+1th package, executes the transaction in the N+1th package in sequence based on the initial state before the execution of the transaction in the N+1th package and generates the first post-state root; the executor sends the transaction in the N+1th package, the first transaction root, the initial state before the execution of the transaction in the N+1th package, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • S330 The prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the preceding packaged transaction refers to the package with the preceding sequence number relative to the subsequent packaged transaction in S320.
  • the sequence number of the preceding packaged transaction is N
  • the above S330 specifically includes: the prover verifies the first transaction root and the first pre-state root in the Nth package; after the two verifications are passed, the transactions in the Nth package are executed in sequence based on the initial state to generate the second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the Nth package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the subsequent packaged transactions after the previous packaged transactions are not limited to the relationship between sequence numbers N and N+1, for example, they can be the relationship between N and N+2.
  • the executor can continuously perform the corresponding work of the subsequent packaged transactions and send the results to the prover, while the prover can continuously perform the corresponding work of the previous packaged transactions, forming a pipeline-style work.
  • the computing power of the executor and the prover can be efficiently utilized, and the continuous execution of transactions and the continuous generation of proofs can be achieved.
  • S410 The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions Send to the actuator;
  • the executor and the prover may execute S420 and S430 in parallel:
  • the executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transactions in sequence based on the initial state before the execution of the packaged transaction and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the SPV proof of the read set before the execution of the subsequent packaged transaction, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • S430 The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following is an example of a method for implementing a two-layer network convolution in a group parallel manner, including:
  • S510 The sequencer of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependencies, and sends different groups to executor participants.
  • the at least two executors are at least two executor threads/coroutines or at least two executor processes.
  • the at least two executors are at least two executor threads/coroutines and may be located in the same process; or, the at least two executors are at least two executor processes and may be located on the same physical machine/virtual machine or on different physical machines/virtual machines.
  • these different physical machines/virtual machines may be physical machines/virtual machines of the same participant. In this way, there is no trust issue between the physical machines/virtual machines of the same participant.
  • the packaged transactions are grouped.
  • multiple transactions can be divided into multiple transaction groups according to the accounts accessed by the transactions, and the transaction groups do not access the same accounts, so that the transaction groups can be executed in parallel.
  • the smart contract code can be statically analyzed to obtain the state variables accessed (including read/write); in addition, for some complex cases, the state variables accessed in the transaction cannot be predicted before the transaction is executed, so that multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.
  • multiple transactions can be pre-executed to obtain the pre-execution read-write set of each transaction, so that these transactions can be grouped according to the pre-execution read-write set.
  • ordinary transfer transactions can also be pre-executed to obtain read-write sets.
  • the pre-execution read-write set of a transaction includes, for example, a pre-execution read set and a pre-execution write set, wherein the pre-execution read set includes the key-value pairs of the variables read by the transaction in pre-execution, and the pre-execution write set includes the key-value pairs of the variables written by the transaction in pre-execution.
  • the state variables include, for example, external accounts in Layer2, or state variables defined in contract accounts.
  • Multiple transactions can be grouped by different algorithms.
  • multiple transactions can be grouped by a directed acyclic graph (DAG) algorithm.
  • DAG directed acyclic graph
  • a DAG graph between multiple transactions is first drawn based on the dependencies between the transactions. For example, assuming that the slave node executes multiple transactions according to the order in which the master node pre-executes the multiple transactions, the dependencies between the transactions can be determined based on the pre-execution read-write sets and pre-execution order of the multiple transactions. If the pre-execution read set of one transaction is the same as the pre-execution read set of another transaction, the dependencies between the transactions can be determined based on the pre-execution read set of the multiple transactions.
  • transaction Tx1 can be drawn to point to transaction Tx2.
  • transaction Tx1 and transaction Tx2 can be considered as conflicting transactions and need to be executed serially, that is, transaction Tx2 is executed after executing transaction Tx1.
  • FIG12 is a schematic diagram of a DAG graph of multiple transactions in an embodiment, in which circles represent nodes in the DAG graph, numbers in the circles represent transaction numbers, and arrows between nodes represent directed connection edges between nodes.
  • the multiple transactions can be grouped according to the DAG graph, so that transactions in every two transaction groups are separate nodes in the DAG graph, that is, there is no connection edge between any transaction in one transaction group and any transaction in another transaction group.
  • transactions Tx1 to Tx8 are conflicting transactions and need to be grouped into one transaction group.
  • transactions Tx3, Tx5) and (Tx1, Tx2, Tx4) can be executed in parallel first, where transactions Tx3 and Tx5 are executed serially, and transactions Tx1, Tx2, and Tx4 need to be executed serially.
  • Transaction Tx6 needs to wait for transactions Tx4 and Tx5 to be executed before it can be executed, and transactions Tx7 and Tx8 need to wait for transactions Tx5 and Tx6 to be executed before they can be executed in parallel.
  • transactions Tx5 and Tx6 connect more than three nodes, which can also be called bifurcation points.
  • bifurcation points When there are more bifurcation points in the DAG graph, the subsequent transactions will have a longer waiting time for the bifurcation point.
  • the DAG algorithm requires more state space. Therefore, in the case of more conflicting transactions between multiple transactions, the efficiency of using the DAG grouping algorithm is reduced.
  • multiple transactions can be grouped by a union-find algorithm.
  • Union-find is a tree-type data structure used to handle the merging and querying of some disjoint sets. Union-find usually includes two operations: Find, which is used to query whether two elements are in the same set; and Union, which is used to merge two disjoint sets into one set.
  • Find which is used to query whether two elements are in the same set
  • Union which is used to merge two disjoint sets into one set.
  • the union-find algorithm does not consider whether the transaction accesses the key for reading or writing, as long as two transactions access the same key, the two transactions are grouped into one group, so it is possible to group two transactions that read the same key into the same group. Therefore, compared with the grouping result obtained by the DAG algorithm, the parallelism of the multiple transaction groups obtained by grouping through the union-find algorithm is lower.
  • the executor participant may include multiple executors.
  • the sequencer may also read the value in the read set of each transaction set of the group in the storage, and send the read value to the corresponding executor.
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • a Sequencer can be connected to multiple Executors of a participant, such as two Executors of a participant as shown in FIG11.
  • a participant can use an executor to generate the first transaction root of the packaged transaction.
  • the participant can use the at least two executors to execute different transactions in the packaged transaction in sequence. Grouping.
  • the "one executor" here can be one of the two Executors or not.
  • the execution results can be sent to the "one executor", so that the "one executor” merges the execution results of all the transaction groups and generates the first post-state root, and then the executor participant can send the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network.
  • the "one executor” can be one of the "at least two executors" or not.
  • S530 The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the executor can continuously perform the corresponding work of the next packaged transaction and send the result to the prover, while the prover can continuously perform the corresponding work of the previous packaged transaction.
  • the computing power of the prover can be efficiently utilized, and the continuous and rapid generation of proofs can be achieved.
  • the packaged transactions can be grouped by the participant-executor instead of the sequencer.
  • the implementation example of this situation is as follows:
  • S610 The sequencer of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants.
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups transactions that have no dependencies and then sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • S630 The prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following is an embodiment of a method for implementing a two-layer network convolution in a group parallel + pipeline manner, including:
  • S710 The sorter of the second-layer network pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that have no dependencies, and sends different groups to executor participants.
  • the executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • the executor participant uses an executor to generate the first transaction root of the N+1th packaged transaction; the at least two executors each execute different transaction groups in the N+1th packaged transaction in sequence based on the initial state before the execution of the N+1th packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the N+1th packaged transaction, the first transaction root, the initial state before the execution of the transaction, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • S730 The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the prover verifies the first transaction root and the first pre-state root in the Nth packaged transaction; after the two verifications are passed, the Nth packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the Nth package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the packaged transactions may be grouped by the participant-executor instead of the sequencer.
  • the implementation example of this case is as follows:
  • S810 The sequencer of the second-layer network pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants.
  • the executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependencies and then sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • the executor participant uses an executor to generate the first transaction root of the N+1th packaged transaction, and groups transactions that have no dependencies and then sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the N+1th packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the N+1th packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment.
  • S830 The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the prover verifies the first transaction root and the first pre-state root in the Nth packaged transaction; after the two verifications are passed, the Nth packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the Nth package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the overall performance bottleneck may be in the process of Prover TEE verification.
  • Prover TEE can be expanded to multiple, so as to execute the above process in parallel.
  • the parallel execution of multiple Prover TEEs can increase the speed of proof on Layer 1, thereby further reducing the delay of transaction confirmation on Layer 1.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • a sequencer pulls transactions from a transaction pool, sorts and packages the pulled transactions, generates a first transaction root of the packaged transaction, and executes the packaged transaction in sequence based on the initial state before the packaged transaction is executed and generates a first post-state root; the sequencer sends the packaged transaction, the first transaction root, the SPV proof of the packaged transaction read set before the packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network;
  • the prover is used to verify the first transaction root and verify the first pre-state root based on the SPV proof of the packaged transaction read set; after the two verifications are passed, the packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • the executor and prover execute S320 and S330 in parallel:
  • S320 The executor generates a first transaction root of a subsequent packaged transaction, executes the subsequent packaged transaction in sequence based on the initial state before the subsequent packaged transaction is executed, and generates a first post-state root; the executor sends the subsequent packaged transaction, the first transaction root, the initial state before the subsequent packaged transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • S330 The prover verifies the first transaction root and the first pre-state root of the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, and then sends them to the executor;
  • the executor generates a first transaction root of a subsequent packaged transaction, and executes the transaction based on the subsequent packaged transaction.
  • the executor executes the subsequent packaged transactions in order and generates a first post-state root according to the initial state before execution; the executor sends the subsequent packaged transactions, the first transaction root, the SPV proof of the read set before the transaction execution in the N+1th package, and the first pre-state root and the first post-state root to the prover of the second-layer network; the prover is implemented in a trusted execution environment;
  • S430 The prover verifies the first transaction root of the previous packaged transaction, and verifies the first previous state root based on the SPV proof of the previous packaged transaction read set; after the two verifications are passed, the previous packaged transaction is executed in sequence and a second post-state root is generated; after verifying that the second post-state root is equal to the first post-state root, the information of the packaged transaction is signed using the private key in the trusted execution environment, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts and packages the pulled transactions, groups transactions that do not have dependencies, and sends different groups to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the packaged transaction is executed, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the packaged transaction; after the two verifications are passed, the packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the transaction in the package, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sorter pulls transactions from the transaction pool, sorts and packages the pulled transactions, and will not have dependencies Grouping of transactions of a relationship and sending different groups to executor parties;
  • the executor participant uses an executor to generate a first transaction root for a subsequent packaged transaction; the at least two executors each execute different transaction groups in the subsequent packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and the one executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • the prover verifies the first transaction root and the first pre-state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • the following introduces a second-layer network embodiment of the present application, including a transaction pool, a sequencer, and a prover, wherein:
  • the transaction pool is used to receive transactions sent by users on the second-layer network
  • the sequencer pulls transactions from the transaction pool, sorts the pulled transactions, packages them, and sends them to the executor participants;
  • the executor participant uses an executor to generate the first transaction root of the subsequent packaged transaction, and groups transactions that have no dependency relationship and sends different groups to at least two executors; the at least two executors each execute different transaction groups in the packaged transaction in sequence based on the initial state before the execution of the subsequent packaged transaction, and an executor merges the execution results of all transaction groups and generates a first post-state root; the executor participant sends the subsequent packaged transaction, the first transaction root, the initial state before the transaction is executed, and the first pre-state root and the first post-state root corresponding to the initial state to the prover of the second-layer network; the prover is implemented using a trusted execution environment;
  • S830 The prover verifies the first transaction root and the first previous state root in the previous packaged transaction; after the two verifications are passed, the previous packaged transaction is executed in sequence based on the initial state to generate a second post-state root, and after verifying that the second post-state root is equal to the first post-state root, the private key in the trusted execution environment is used to sign the information of the previous packaged transaction, and the signature is used as proof and sent to the blockchain ledger of the main network through the second main network transaction.
  • a programmable logic device such as a field programmable gate array (FPGA)
  • FPGA field programmable gate array
  • HDL Hardware Description Language
  • HDL high-density circuit Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal Joint CHDL
  • JHDL Java Hardware Description Language
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer readable medium storing a computer readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory.
  • a computer readable program code e.g., software or firmware
  • the controller may be implemented in the form of a logic gate, a switch, an application specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the means for implementing various functions included therein may also be considered as a structure within the hardware component. Or even, the means for implementing various functions may be considered as both a software module for implementing the method and a structure within the hardware component.
  • 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.
  • the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted 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.
  • one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less 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.
  • 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).
  • each module can be implemented in the same or more software and/or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc.
  • the device embodiments described above are only schematic.
  • the division of the units is only a logical function division. There may be other division methods in actual implementation.
  • 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 coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
  • each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box 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 boxes in the block diagram.
  • 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 work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby 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.
  • a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • 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 disk read-only memory (CD-ROM), digital versatile disk (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.
  • computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
  • one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. In the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • 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.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network.
  • program modules may be located in local and remote computer storage media, including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种实现二层网络卷叠的方法，包括：二层网络的排序器从交易池中拉取交易，对拉取的交易排序并打包，生成打包交易的第一交易根，基于打包交易执行前的初始状态按序执行打包的交易并生成第一后状态根；排序器发送打包的交易、第一交易根、打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；证明器采用可信执行环境实现；证明器验证第一交易根与第一前状态根；两个验证通过后，基于初始状态按序执行打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。

Description

实现二层网络卷叠的方法及二层网络
本申请要求于2023年11月16日提交中国国家知识产权局、申请号为202311537959.4、申请名称为“实现二层网络卷叠的方法及二层网络”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种实现二层网络卷叠的方法及二层网络。
背景技术
分布式系统中存在经典的CAP定理——Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)，三者不可兼得，简称“不可能三角”问题。区块链中也存在一个不可能三角：效率、去中心化、安全。尽管这里的区块链“不可能三角”还没有明确的理论论证，但是是对现有区块链的总结。这里的效率、去中心化和安全，分别定义如下：效率：每秒处理交易的数量，即TPS(Transaction per Second)。
去中心化：参与节点门槛足够低，保证系统中有大量分布式的节点。
安全：对区块链发动攻击的难度足够大。
针对上述区块链“不可能三角”的问题，Ethereum(也就是以太坊，也称为“主网”或“一层”，Mainnet或Layer1；此外，目前较为流行的还有币安的BSC、波场TRON等的公链项目，也是Layer1/主网的范畴)选择了安全性和去中心化，牺牲了效率，目前只有大约12～15TPS。当有大量交易需要处理时，尤其是很多操作复杂的交易时，Layer1就会拥堵。除了普通的转账交易外，Layer1还作为DeFi(去中心化金融)和NFT(非同质化代币)等火爆应用的主要平台，在交易盛行时，Layer1拥堵的问题就变得十分严重，带来较大的交易延迟，以致于影响到用户的使用。
此外，高昂的Gas fee(汽油费，或交易费)很多时候成为交易的障碍。尽管已从PoW(工作量证明)转向了PoS(权益证明)，但这只是改变了区块链上记账权的获取方式，而需要支付给获得记账权的节点的交易费没有明显减少。这是因为Gas费的设计针对的是节点执行交易(包括执行智能合约代码)的消耗，这部分消耗不改变的情况下Gas费并不会降低。例如，一笔去中心化交易所的货币兑换交易的交易费在拥堵时可能会超过100美元，这让很多用户望而却步。
Layer 2技术是构建在Layer1之上的扩展性解决方案，旨在解决Layer1的效率低和交易费用高的问题。如图1所示，交易可以在Layer2上快速执行，Layer2按照一定的时机将最终状态同步回Layer1。Layer2用于专门提供高速的交易处理，而安全性和去中心化交由Layer1去保障。这样，减轻Layer1压力的同时，Layer2上执行交易的Gas费可以大幅下降，将Layer2上交易执行的最终状态(而不是Layer2上所有的状态)同步回Layer1所需的Gas费也可以大幅下降。在Layer1之上架构Layer 2的技术，实际上是将交易或合约的执行过程与最终状态的保存分离开，执行过程放到了Layer2，Layer1只需要保存 最终的状态。这个设计中，需要保证Layer2上交易或合约的执行过程的正确性，并且写入Layer1的状态与Layer2上正确执行的结果是一致的。
Ethereum的Layer2包括一种称为Rollup的机制。Rollup的核心思路如图1所示，是在Layer1上保存能够验证交易过程的凭证，而将交易过程(计算过程)还有状态存储运行在Layer2中。所谓交易过程的凭证，包括一组交易执行前的状态(Pre-State)和该组交易执行后的状态(Post-State)以及该组交易，可以用于验证这组交易对应的状态转移是否正确，还可以用于还原出Layer2上所有交易的执行过程和所有账户的状态，从而消除Layer2上由于数据可用性带来的安全风险。
发明内容
本说明书在于提供一种实现二层网络卷叠的方法及二层网络，通过以下方式实现：
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根；
所述排序器发送打包的交易、第一交易根、所述打包交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S1和S2：
S1：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S2：所述证明器验证前序打包交易的第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S3和S4：
S3：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前 的初始状态按序执行所述后序打包交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述第N+1个包中交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S4：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中 的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种实现二层网络卷叠的方法，包括：
二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
并行执行S5和S6：
S5：所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S6：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根；所述排序器发送打包的交易、第一交易根、所述打包交易执行前该打包交易读集的SPV证明以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；
证明器，用于验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S1和S2：
S1：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前 的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S2：所述证明器验证前序打包交易的第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S3和S4：
S3：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述第N+1个包中交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S4：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依 赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
一种二层网络，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
所述执行器和证明器并行执行S5和S6：
S5：所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S6：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
通过上述本申请的实施例，采用TEE作为二层网络上的证明器，由于TEE中重放交易并验证接近于原生执行的速度，因此可以带来更低的延迟。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是一实施例中Layer2的原理示意图；
图2是一实施例中Layer2的原理示意图；
图3为一实施例中Layer2的原理示意图；
图4为一实施例中Layer2的原理示意图；
图5为一实施例中Layer2的原理示意图；
图6为一实施例中Layer2的原理示意图；
图7为一实施例中MPT树的原理示意图；
图8为一实施例中MPT树的原理示意图；
图9为一实施例中Layer2的原理示意图；
图10为一实施例中Layer2的原理示意图；
图11为一实施例中Layer2的原理示意图；
图12为一实施例中DAG的原理示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
Rollup的原理具体可以如图2和图3(图3中主要是下文中的OP-Rollup)所示。
创建智能合约的交易发送到Layer1上，经过Layer1的共识之后，Layer1上各节点可以执行这个交易，从而完成合约的部署。具体的，可以是由区块链节点的EVM/WASM来执行这个交易。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑，这也是以太坊作为区块链2.0的代表相对于区块链1.0的最大改进之一。用户在以太坊中发布和调用智能合约可以在EVM上运行。执行该部署智能合约的交易之后，Layer1上产生一个与该智能合约对应的合约账户，该合约账户具有链上的地址，并且包括余额balance、计数器nonce、合约代码的hash值Codehash，合约存储的根Storage_Root。通过Codehash和Storage_Root，该合约的代码和账户存储可以保存在该合约账户中。智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储(Storage) 的虚拟账户。后续，Layer1上的节点可以接收调用部署的智能合约的交易请求，该交易请求可以包括调用的合约的地址、调用的合约中的函数和输入的参数。一般的，该交易请求经过共识后，区块链各个节点可以各自独立执行指定调用的智能合约。
以太坊中的Storage_root是一个MPT树根节点的哈希，这个MPT树对合约账户的状态的存储进行组织。MPT全称为Merkle Patricia Tree，是结合了Merkle Tree(默克尔树)和Patricia Tree(压缩前缀树，一种更节省空间的Trie树，字典树)的一种树形结构。Merkle Tree算法对每个交易都计算一个Hash值，然后两两连接再次计算Hash，一直到最顶层的Merkle根。以太坊中采用改进的MPT树，例如是16叉树的结构，通常也简称为MPT树。实际上，以太坊区块头中包括三颗MPT树的树根，分别是Transaction_Root(简写为Tx_Root)、State_Root、Receipt_Root。State_Root当前区块中所有账户的状态组成的MPT树的根的哈希值，即指向State_Root的为一颗MPT形式的状态树state trie。从这个MPT的根节点到叶子节点中每个节点的一部分值按照顺序串联起来可以构成账户地址并作为key，叶子节点中存储的账户信息为这个账户地址对应的value，这样，构成了key-value键值对。具体的，这个key可以是sha3(Address),即账户地址的hash值(hash算法例如采用sha3算法)，其存储的值value可以为rlp(Account)，即账户信息的rlp(Recursive Length Prefix，递归长度前缀)编码。其中账户信息是[nonce,balance,storageRoot,codeHash]构成的四元组。对于外部账户(Externally Owned Account，简称EOA)来说，一般只有nonce和balance两项，而storageRoot、codeHash字段默认存储空字符串/全0字符串。也就是说，外部账户不存储合约，也不存储合约执行后的产生的状态变量。合约账户一般包括Nonce,Balance,Storage root,CodeHash。不论是外部账户还是合约账户，其账户信息一般都位于一个单独的叶子节点(Leaf Node)中。
其中，对于state trie中的一个合约账户(Contract Account，简写为CA)来说，其storage_Root指向另一颗同为MPT形式的树，其中存储了合约执行涉及的状态变量(state variable)的数据。这个storage_Root指向的MPT形式的树为Storage Trie，即storage_Root中存储Storage Trie的根节点的hash值。一般的，这个Storage Trie树存储的也是key-value键值对。key表明状态变量的地址，其取值可以是合约中的状态变量声明的位置(从0开始计数的值)经过一定规则处理后得到的结果，例如是sha3(状态变量声明的位置)，或者是sha3(合约名称+状态变量声明的位置)。value用于存储状态变量的取值(例如是经RLP编码的值)。从根节点到叶子节点的路径上存储的一部分数据连起来构成key，叶子节点中存储value。State trie和其中的Storage trie中，除了叶子节点外的根节点、中间节点采用图3中云朵状来表示其中灵活和复杂多变的结构。
如图2所示，Rollup中可以在Layer1上部署Rollup Contract。Layer2中，可以接收发起的交易，如图中的Tx_21、Tx_22等。一个批次的交易称为一个Batch，作为一个整体按序执行并更新状态。如图1和2中所示，Batch 1假设可以包括Tx_21、Tx_22、Tx_23这3笔交易，Batch 2假设可以包括Tx_24、Tx_25、Tx_26这3笔交易。Layer2中可以按照一种规则对这些交易进行排序，进而可以按照顺序执行排序后的这些交易，例如按照交易中的时间戳排序。一个Batch中的交易在按序执行后，产生的 状态可以包括若干，例如Batch 1中的交易分别为：
Tx_21：Alice→Bob 20；表示Alice转给Bob 20个单位的资产，如以太币；
Tx_22：Alice→Charlie 10；表示Alice转给Charlie 10个单位的资产，如以太币；
Tx_23：Bob→Charlie 10；表示Bob转给Charlie 10个单位的资产，如以太币；
Batch 1中的交易执行前，假设共有4个状态，这里称为Batch 1的初始状态，即图3中由Pre State Root锁定的状态值，分别是：
Alice：50，Bob：100，Charlie：150，David：200
Batch 1中的交易执行后，这4个状态更新为Batch 1的终局状态，即图3中由Post State Root锁定的状态值，分别是：
Alice：20，Bob：110，Charlie：170，David：200
Layer2中可以采用Merkle树来组织Batch 1中的交易按序执行前、后的状态。如图3所示，在Layer2中可以将一个Batch的交易及其相关的状态变化组织在一起，例如将Batch 1中的交易的hash值按照Merkle树组织后得到的Merkle根锁定在Batch的头(Header)中，这个头类似Layer 1中的区块头，这个Merkle根即Batch的头中的Tx_Root。同样的，如前所述，可以将Batch 1中的交易在执行前的所有状态值按照Merkle树组织后得到的Merkle根锁定在Batch的头中，即Pre State Root；可以将Batch 1中的交易在按序执行后的所有状态值的hash按照Merkle树组织后得到的Merkle根锁定在Batch的头中，即Post State Root。此外，对于Batch M来说，在其Header中还可以设置一个时间戳(Timestamp)用于记录该Batch生成的时间，当然还可以设置其它字段的信息。对于第M+1个Batch来说，其区块头中的Pre State Root，与第M个Batch的区块头中的Post State Root相等，如图3中这两个根之间的连线所表示。这样，Batch之间形成了一个链式的结构。
Layer2的Rollup机制，可以包括两种：一种是Optimistic-Rollup(乐观Rollup，简称OP-Rollup)，另一种是ZK-Rollup(零知识证明Rollup，ZK指的是zero knowledge，即零知识)。这两种Rollup机制，以太坊上都部署有如前所述的智能合约——Rollup Contract。
OP-Rollup中，在Layer2里可以至少设置TxPool(交易池)、Relayer(中继器)、Sequencer(定序器)。
如图3中所示，假设TxPool中收集到Tx21、Tx23、Tx25、Tx22、Tx26、Tx24这些交易。Sequencer按照这些交易中的时间戳对这些交易排序并打包，例如将Tx21、Tx22、Tx23打包到Batch M中，并将这些交易的hash值组织为Merkle后生成Merkle Root，并将该Merkle Root的hash值填入生成的Batch M中Header内的Tx_Root中。需要说明的是，在计算Merkle树的树根时，一般对于小于2n的情况，可以将最后一个交易赋值多份以用于补齐2n，从而计算2叉的Merkle树的树根。如图3中，按照时间顺序排序为最末的Tx23重复一次后补齐了4个交易，即使交易的数量达到22，进而可以计算得到2叉的Merkle树的树根。类似的，Sequencer按照交易中的时间戳对交易排序后将Tx21、Tx22、Tx23打包到Batch M+1中，不再赘述。
在Batch M执行前，所有的状态包括如前所述，Alice：50，Bob：100，Charlie： 150，David：200。Sequencer可以将这些状态组织成Merkle树，并将该Merkle树根节点的hash值存储于Batch M Header的Pre State Root字段中。进而，Sequencer可以按照顺序执行Tx21、Tx22、Tx23这3笔交易。执行这3笔交易的结果，生成了新的状态，如前所述，Alice：20，Bob：110，Charlie：170，David：200。Sequencer可以将这些更新后的状态组织成Merkle树，并将该Merkle树根节点的hash值存储于Batch M Header的Post State Root字段中。
进而，Sequencer可以通过Relayer发送一笔调用Rollup Contract的交易1至Layer1，该交易1中包含了Batch M Header中的各字段以及经过压缩的Tx21、Tx22、Tx23。Tx21、Tx22、Tx23经过压缩后，所占空间可以大大降低。调用的Rollup Contract合约中的接口，可以包括将压缩后的交易数据(Tx21、Tx22、Tx23)存储于较便宜(Gas费用较低)的位置calldata上。在以太坊智能合约中，calldata是一种特殊的数据位置(data location)，用于存储通过函数调用的输入数据。具体的，calldata数据一般直接存储在以太坊的交易数据中，其通常比其它数据位置(如memory和storage)更加节省gas。
关于压缩，一笔简单的以太坊交易(发送ETH)大小约为110字节，而在Rollup上进行ETH转账，目前的设计中经最大压缩后大小可以降至约12字节。下表是一个例子中以太坊的一笔交易各字段(参数)所占体积与Rollup中一笔交易的各字段：
表1
这里略去压缩的实现细节。值得注意的是，在一笔以太坊交易中，签名部分占了整体的约一半的体积，其From字段可以是0字节，因为该From字段可以从签名中恢复出来。而在Rollup中，可以采用BLS聚合，平均每笔交易的签名被压缩到约0.5字节，相应的，Rollup交易中由于无法从这种聚合签名中恢复出交易的From字段，因此这里需要单独采用4字节来表示。
在密码学中，公开钥匙密码学，简称公钥密码学，又称非对称密码学，是使用一对公钥和私钥(公钥-私钥记为pk-sk，其中pk表示public key，sk表示secret key)的密码学，与只用一个私钥的密码学相对应。公钥密码学包括加密算法和数字签名算法。公钥-私钥密码对是现代密码学安全的基石，很多的应用都是基于pk-sk，例如基于https(Hypertext Transfer Protocol Secure，安全的超文本传输协议)应用层加密传输协议以及区块链等。
私钥通常代表拥有该私钥的一方的身份，其只能由私钥的拥有者持有，不能公开， 而对应的公钥可以公开出去。使用私钥进行的签名可以表示私钥拥有者对数字世界的某种信息进行的认可，签名的信息在协议的消息中也可以表示私钥拥有者的某种行为。一般的，一个拥有者单独拥有一个私钥，则这个拥有者可以采用自身私钥对某个信息进行签名后发给其它方。接收方收到这个签名后，可以采用对应的公钥对该签名进行验证。验证通过，则接收方可以确认是拥有者对该信息进行了签名，且所签名的信息没有被篡改。
BLS签名方案最初是由斯坦福大学教授DanBoneh等人于2001年提出的一种签名方案，基于双线性映射构造。一般一个用户对自身账户的控制，体现在用自身私钥对一笔交易进行签名。单个签名如上表格中所示，可能达到68字节，占用较大体积。多个账户发起的多笔交易，则每个账户需要对自身的每笔交易分别签名。而签名聚合，可以把多个签名聚合成一个签名，因此大大节省了签名的字节空间。这种聚合可以是同一个消息由不同签名者签名的聚合，也可以是不同消息的签名聚合。公钥聚合，可以将多个不同公钥聚合成一个总的公钥，由该总公钥即可对聚合签名完成验证，而不需要在验证总签名时由每个公钥参与计算。通常可以采用Schnorr签名算法、BLS签名算法实现签名聚合。相对于Schnorr签名算法来说，BLS签名算法实现的聚合签名体积更小，约是Schnorr的二分之一。
上述压缩方案和采用BLS进行签名聚合，是理想中的设计方案。尽管如此，实际中的几种Rollup方案中，目前一笔压缩后的交易仍然占用40-50字节的空间，且其中尚不包括签名，也就是说还未采用BLS签名聚合。
接前文，Layer1中接收到该调用Rollup Contract的交易1后，经过共识，在一些节点上执行这个交易1，并将该交易1及其执行结果连同其它一些交易及执行结果一并生成一个区块，如图3中的Block N。所述其它一些交易，可以包括普通转账交易和涉及其它智能合约的交易。其中，普通转账交易和涉及其它智能合约的交易都可以涉及交易的执行。特别是其它智能合约的交易，可能涉及较为复杂的执行逻辑。而这里的交易1，调用Rollup Contract中存入calldata位置的函数，主要涉及存入指定位置，即不涉及复杂合约逻辑的执行。也就是说，Layer1里的Rollup Contract，主要作用是将Layer2上发来的交易中指定的内容存入指定位置，此外不涉及复杂的执行逻辑。例如，作为一个例子，Tx21、Tx22、Tx23存入由Block N Header中Tx_Root锁定到交易树中的Tx_12中。此外，作为一种实现，交易1中的Batch M Header中的Pre State Root、Post State Root可以通过Rollup Contract分别存入Layer1上合约状态中的状态1和状态2中。如前所述，状态1和状态2包含在由Block N Header中State_Root锁定的state trie中，具体例如是storage trie中。为了加以区分，Layer1上合约状态中的状态1和状态2例如分别称为Last State root和Current State root。此外，为了简化，也可以在Layer1上合约状态中仅保存Current State root，而不保存Last State root，如下面的代码示例所示。在另一些实现中，Last State root和Current State root也可以与Layer2中的交易一样存入Layer1中的calldata内，这里不再赘述。对于前者，例如是调用如下的Layer1中的commitBatch()合约接口：
function CommitBatch(bytes[]calldata_transactions,bytes32 _preStateRoot,bytes32_postStateRoot)
CommitBatch()合约接口内部，可以设置基本的校验逻辑，例如包括验证当前交易1中的Pre State Root是否与合约存储中的Current State Root相等，如果相等则将交易1中传入的Layer2上的交易存入calldata中，并将合约存储中的Current State Root更新为Post State Root，示例代码如下：
通过上述方式，OP-Rollup可以在Layer2中执行各个交易，并且可以在一个Batch中捆绑几十、数百甚至更多的Layer2交易，且只发布最低限度的信息至Layer1上。所谓最低限度的信息，包括如前所述的压缩后的Layer2上的交易和这批交易执行前后的状态根的hash值。如前所示，这里例如可以通过一个Layer1上的交易发送，如图3中的交易1。可见，这相当于一次性在Layer2上执行了一批交易，但是在Layer1上只执行了一个交易。同时，OP-Rollup并不附带任何证明。这是出于假设提交的Layer2上的信息不存在欺诈或恶意行为，因此其是“Optimistic”(乐观)这样的名字。虽然存在这样的假设，为了预防和震慑，仍然会要求提交Layer2信息的交易者在OP-Rollup的Rollup Contract中质押一部分Layer1上的资产(典型的是链上原生的token，如以太坊上的以太币)。OP-Rollup尽管是乐观的，但Layer1上仍然可以设置一个挑战期，任何人都可以在挑战期内使用欺诈证明提出挑战。典型的原因包括挑战者证明该Batch内的某个交易没有被正确的执行，即该交易的执行没有产生正确的状态。如果一个Batch内的某个交易被证明是无效的，则该Batch也是无效的，Layer1上的这个Rollup合约可以将其中的Layer2的Batch链进行回滚，该无效Batch及其后面的所有Batch都会变成孤块。一旦欺诈证明成功，保证金中的一部分会支付给挑战者，剩余部分则销毁。反之，如果直到挑战期结束都没有人提交欺诈证明，Rollup合约可以确定这个Batch。
欺诈证明是Optimistic Rollup方案采用的一种数据有效性的验证方式。目前， 欺诈证明可分为单轮交互型和多轮交互型两种。
一种单轮交互型欺诈证明的实现中，在Layer1上重放一遍有争议的交易，检测是否存在无效状态后进行提交。例如，Alice作为验证人将OP-Rollup压缩后的数据同步到Layer1，同时质押保证金。如果挑战者Bob对该数据存在争议，则需在窗口期(挑战期)内发起挑战且同样质押保证金。OP-Rollup的Rollup Contract将会在Layer1上重新计算该区块中交易来判定对错。错误方的保证金将被罚没，正确方将获得奖励。
例如，Layer2上的Sequencer此前打包并执行了Tx21、Tx22、Tx23，并生成了Batch M的头Heaer，其中包括按序执行Tx21、Tx22、Tx23前后的全局状态的Merkle根Pre State Root和Post State Root，以及其它。Sequencer可以通过Relayer发送一笔调用Rollup Contract的交易1至Layer1，该交易1例如是调用Layer1中Rollup Contract合约的CommitBatch()合约接口，其中包含了Batch M Header中的各字段以及经过压缩的Tx21、Tx22、Tx23。Bob是Layer2上的一位用户，假设其参与了Layer2上Batch M中的一些交易，例如前述的Tx_21：Alice→Bob 20和Tx_23：Bob→Charlie10。
假设Bob认为Sequencer执行Tx_23中Bob转给Charlie10之后得到的Bob的状态有误，那么Bob可以在Layer1上在Batch M的挑战期内发起挑战。Bob作为Layer2上的用户，其可以获得Layer2上的每个Batch执行前的全部状态以及执行后的全部状态，以及每个Batch中的所有交易，这是前提。进而，Bob可以向Layer1中Rollup Contract合约发起挑战，例如调用的是Challenge()合约接口。通过该Challenge()合约接口，Bob可以发送挑战的Batch编号batchIndex、其中的交易序号txIndex、证明。证明可以包括挑战的Batch M中的全部交易的原文(包括每个交易的签名；这里以存入calldata中的压缩后的交易不带签名为例)和Batch M执行前的全局状态。这样，Layer1上的Rollup Contract合约在执行时，可以执行一个验证函数，这个验证函数的执行逻辑例如包括：
1、验证Bob发起的挑战中，全部交易原文的签名是否正确；
2、验证Bob发起的挑战中，基于全部交易原文去除交易签名并压缩后组织成Merkle树的根hash与之前Sequencer通过Relayer调用CommitBatch()发来的Batch M Header中的Tx_Root(即Batch M中的全部交易组织成Merkle树的根hash)相同；
3、验证Bob发起的挑战中的Batch M执行前的全局状态组织成Merkle树后得到的根hash与之前Sequencer通过Relayer调用CommitBatch()发来的Pre State Root相同；
4、如果1、2、和3都通过验证，进一步模拟Layer2按序执行Bob发起的挑战中的Batch M中的全部交易，生成Batch M执行后的Post State Root，并与之前Sequencer通过Relayer调用CommitBatch()发来的Post State Root验证是否相同；
第4步执行的结果如果不同，则说明Sequencer有欺诈，可以通过Rollup Contract合约将保证金中的一部分会支付给挑战者。
这里需要说明的是，Layer1上的calldata中尽管有Layer2上所有的压缩后的交易，但在验证欺诈证明过程中，并不直接将calldata中Batch M中压缩后的交易直接取出执行，而是基于挑战者传入的Batch M中的所有交易原文模拟执行。这是因为， calldata中的压缩后Batch M的交易一般仅用于还原出Layer2上所有交易的执行过程和所有账户的状态，从而消除Layer2上由于数据可用性带来的安全风险；且calldata中的压缩后Batch M的交易，不带签名的情况下本身的真实性是有待确定的，而挑战者传入的交易是完整交易，可以验证交易的有效性；再者，还因为无法验证初始状态，合约存储中只是状态根而不是状态，除非从Batch 0开始重新顺序执行所有的交易直至Batch M-1执行后得到的全部状态，而这显然是不经济不高效的。
上述单轮交互型欺诈证明，增加了必须在链上发布的数据，且需要在Layer1上重新执行Batch M中的全部交易，并且重放这些交易还会产生巨大的燃料成本，因此，OP-Rollup正在转向多轮交互式证明，以更高的效率实现相同的目标。
多轮交互型欺诈证明中，当Bob对Sequencer同步的数据提出挑战后，Sequencer需将争议的Batch范围二等分为前、后两段范围并通过例如dispute()合约接口返回，然后由Bob进一步选择继续挑战的二分后的一个范围，再由Sequencer将争议范围二等分……如此循环，直至将争议范围缩减到一个具体的交易。这里Bob会发送挑战的交易的原文(包括每个交易的签名)及该交易执行前的全局状态，Sequencer会发送挑战的交易执行前的Pre State Root(这里也称为状态承诺)和执行后的Post State Root，交由Layer1的Rollup Contract合约进行计算和判定。具体的，例如Rollup Contract合约基于所挑战交易执行前的Pre State Root验证挑战交易执行前的全局状态，并在该挑战交易执行前的全局状态基础上执行挑战的交易，生成执行后的状态，在挑战交易执行后的全局状态的基础上生成Post State Root，与Sequencer发送的Post State Root相比，如果不同，则说明挑战成功，反之挑战失败。在实际应用中，Arbitrum不是使用二分的方式，而是使用了K分，即每次将N个指令分为N/K组去寻找欺诈指令，效率更高。
因此，相比单轮交互型，多轮交互型能以更低的成本来解决争议，例如二等分协议可以减少发布在链上的数据量(无需为每笔交易发布状态提交)，也更容易支持复杂的智能合约和处理更高要求的争议。不过，随着交互次数的增加，它的争议窗口期也会更长一些。
整体来说，由于OP-Rollup的设计中需要把与状态更新和验证相关的数据都放到Layer1上，因此OP-Rollup的拓展性和对吞吐量的提升程度最为有限，且需要7天甚至更长的等待期。这意味着，从OP-Rollup中提取资产会产生延迟，需要等待窗口期过后。
ZK-Rollup不同于Optimistic Rollup，因为ZK-Rollup使用零知识(zero knowledge)证明技术。ZK指的是在不披露必要信息的情况下向另一方证明某事(一项交易或状态)的能力。ZK-Rollup中，与OP-Rollup类似的，将Tx21、Tx22、Tx23打包到Batch M中，并将这些交易的hash值组织为Merkle树后生成Merkle Root，并将该Merkle Root的hash值填入生成的Batch M中Header内的Tx_Root中，以及生成Pre State Root、Post State Root和Timestamp等并填入到Batch M Header中。而且，Layer2中还会为这个batch生成一个证明(包括proof)(例如采用ZK-SNARK等的密码学证明算法)，这个证明中的proof可以证明Post State Root是在Pre State Root基础上按序正确执行batch中的 交易后得到的，只需要验证proof即可以确认这一点，而不需要重新执行Batch中的交易来验证。
在生成证明前可以创建计算电路，该电路实际上是一种特定的算法，可以预先针对验证交易及状态的逻辑编写。这个预先编写的过程包括在称为可信设置的过程中，通过该可信设过程还可以生成创建密钥(Proving Key)和证明密钥(Verifying Key)。创建的电路可以设置在Layer2上的一个proposer(或称为prover，证明器)中。需要说明的是，针对验证交易及状态的逻辑创建的电路，与其Proving Key和Verifying Key是绑定的。Proving Key、Verifying Key都是可以公开的，且是与电路是绑定的。
生成证明的过程，可以是由Sequencer将Layer2中一个Batch中所有交易(包括发送方、接收方、金额)以及这个Batch中的交易执行前后的Pre State Root、Post State Root和和Proving Key等信息打包发送至Layer2上的一个证明器，由证明器将这些信息转换为一种特殊的形式，称为witness(见证者；选择其中的一部分作为公共输入，另一部分作为隐私输入)。进而，证明器采用其内布置的零知识证明的计算电路(一种特定的算法)对公共输入+隐私输入的有效性和正确性进行验证。如果验证正确，电路执行成功，否则电路执行失败。电路执行成功的情况下，证明器可以输出一个proof，该proof用以证明打包的数据是有效且正确的。而且，这个proof的体积较小，一般只有几十字节。上述生成证明的过程，类似于重新执行的过程，并且包含大量的电路计算，更为复杂，所以一般比较耗时。
需要说明的是，由proof本身无法倒推出隐私输入。只有知道zk-SNARK的验证密钥的一方才能验证用对应创建密钥加密的proof。而公共输入可以用来验证打包的数据的有效性和正确性，但无法用来获取打包的数据的具体内容。
采用零知识证明，证明器可以通过Relayer将较小的proof发布到Layer1上，并可以由Rollup Contract快速验证。proof体积较小，这进一步降低了Layer1上Gas的消耗。而且，在ZK-Rollup中这个验证过程通常由智能合约自动完成，且不用像OP-Roll那样再设置窗口期，提取资产也会变得迅速，这是OP-Rollup和ZK-Rollup之间的主要特性差异之一。
具体的验证过程，首先，将公共输入(可以从Block N中提交的交易1计算得到，例如是在交易1提交至Layer1的Rollup Contract时由Rollup Contract中的自动执行计算逻辑计算得到)、proof和验证密钥(验证密钥可以通过Layer1上的治理合约保存并提供至Rollup Contract)输入到智能合约中的验证逻辑(例如包括ZK-SNARK的验证算法)，由验证逻辑使用验证算法检查proof是否有效。如果proof有效，那么公共输入对应的打包数据就被认为是有效且正确的。如果验证成功，验证算法会输出一个确认信息，证明公共输入对应的打包数据是有效且正确的；否则，验证算法会输出一个错误信息，标示数据的无效性或错误性。
然而，ZK-SNARK这类的零知识证明在生成proof过程中的计算量非常大，也意味着生成proof将比较耗时。假设如图4中所示，通过交易1将经过压缩的Tx21、Tx22、Tx23存入Layer1中calldata中，并将Post State Root存入Layer1上合约状态中的Current State Root。这个交易1如图4位于Layer1的Block N中。则Layer2中生成对应proof所需要的复杂计算量带来的延迟，可能在一段时间通过交易2将Batch M的proof传入 Layer1上的Block N+412中。从Block N到Block N+412，显然也带来了一定的延迟，这个延迟可能接近小时级。
针对计算复杂、生成证明所需时间久这个问题，目前行业里主要的解决方案主要包括通过工程上的大规模并行化证明来实现，或通过硬件优化来加速。但是这并不容易。电路的实现相对复杂，且没有高级语言支持，很多情况下都是手写R1CS(电路中的一种常用形式)。
进一步，为了利用ZK证明系统，为了优化电路的实现，整个Layer2的状态经常优化为电路友好结构(merkle树)。所以，ZK-kRollup的系统需要考虑电路的结构，从而约束了Layer2交易以及账户模型。ZK-Rollup中，包括zksync、StarkNet、Scroll等方案，都只实现了特定交易场景，做到兼容以太坊虚拟机和支持图灵完备就更困难，也就是说，很难支持较为复杂的合约。
以下是OP-Rollup和ZK-Rollup两种Layer2中的Rollup方案的特点对比：
表2
本申请一种实现二层网络卷叠的方法，在Layer2上所依赖的架构如图5所示。这里至少包括Relayer、TxPool、Sequencer、Prover。如前所述，Relayer的主要作用是将Layer2上的交易或操作提交到Layer1上，即起到桥接Layer1和Layer2的作用，可以包括将Sequencer打包的Layer2上的用户交易提交到Layer1上，以及将Layer2上Prover生成的证明提交到Layer1上。当然，也可以不包括Relayer，而是由Sequencer将打包的Layer2上的用户交易提交到Layer1上，以及由Prover将生成的证明提交到Layer1上。实际上，后者是将Relayer的功能集成在Sequencer、Prover中。为了简略，后续不再着重提及Relayer在整个方案中的作用。
TxPool用于接收Layer2上用户发送的交易。
Sequencer从TxPool中拉取交易，并按照拉取交易中的时间戳对这些交易排序并打包，并将这些交易的hash值组织为Merkle树后生成Merkle Root，并将该Merkle Root的hash值填入生成的Batch M中Header内的Tx_Root中。例如图4中所示，将Tx21、Tx22、Tx23打包到Batch M中，按照时间顺序排序为最末的Tx23重复一次后补齐了4个交易，进而计算得到2叉的Merkle树的树根。并且，Sequencer还在Batch M中交易执行前状态的基础上顺序执行Tx21、Tx22、Tx23这3笔交易。执行这3笔交易的结果，生成了新的状态。Sequencer将执行前的状态组织成Merkle树，并将该Merkle树根节点的hash值存储于Batch M Header的Pre State Root字段，还将Batch M中交易执行后的状态组织成Merkle树，并将该Merkle树根节点的hash值存储于Batch M Header的Post State Root字段中。
Prover可以采用TEE(Trusted Execution Environment，可信执行环境)实现。
TEE是基于CPU硬件的安全扩展，且与外部完全隔离的可信执行环境。目前工业界十分关注TEE的方案，几乎所有主流的芯片和软件联盟都有自己的TEE解决方案，比如软件方面的TPM(Trusted Platform Module，可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor，平台安全处理器)等。TEE可以起到黑箱作用，在TEE中执行的代码和数据即便是操作系统层都无法偷窥，只有通过代码中预先定义的接口才能对其进行操作。在效率方面，由于TEE的黑箱性质，在TEE中进行运算的是明文数据，而不是同态加密中复杂的密码学运算，计算过程效率几乎没有损失。因此，采用TEE技术可以在性能损失相对较小的前提下很大程度上满足区块链场景下的可信计算需求。
本申请一种实现二层网络卷叠的方法，包括如下：
S110：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根。
S120：所述排序器发送打包的交易、第一交易根、所述打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器。
与前述类似，Rollup中可以在Layer1上部署Rollup Contract。Layer2中，交易池TxPool可以接收发起的Layer2交易。假设TxPool收集到Tx21、Tx23、Tx25、Tx22、Tx26、Tx24这些Layer2交易。
Sequencer可以从交易池中拉取交易，并按照这些交易中的时间戳对这些交易排序并打包。例如如图4所示，将Tx21、Tx22、Tx23排序并打包到Batch M中，并将这些交易的hash值组织为Merkle树后生成Merkle Root，并将该Merkle Root的hash值填入生成的Batch M中Header内的Tx_Root中。该Merkle Root即为Batch M的第一交易根。
打包的交易执行前，例如状态为：
Alice：50，Bob：100，Charlie：150，David：200
这些状态即可以为打包交易执行前的初始状态。
Sequencer可以将Batch M中的交易在执行前的所有状态值按照Merkle树组织并得到Merkle根，即第一前状态根。还可以将Batch M中的交易在执行前的所有状态值按照Merkle树组织后得到的Merkle根锁定在Batch M的头中，即图4中的Pre State Root。
Sequencer可以在初始状态的基础上按序执行打包的交易，从而产生执行后的状态，例如：
Alice：20，Bob：110，Charlie：170，David：200
Sequencer可以将Batch M中的交易按序执行后得到的所有状态按照Merkle树组织并得到Merkle根，即第一后状态根。还可以将Batch 1中的交易在按序执行后的所有状态值的hash按照Merkle树组织后得到的Merkle根锁定在Batch的头中，即Post State Root。
进而，所述排序器可以发送打包的Layer2交易、第一交易根、所述打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器。
此外，在S110或S120中，Sequencer可以(或通过Relayer)发送一笔调用Rollup Contract的交易1(第一主网交易)至Layer1，该交易1中包含了Batch M Header中的各字段以及经过压缩的Tx21、Tx22、Tx23。Tx21、Tx22、Tx23经过压缩后，所占空间可以大大降低。调用的Rollup Contract合约中的接口，可以包括将压缩后的交易数据(Tx21、Tx22、Tx23)存储于较便宜(Gas费用较低)的位置calldata上。在以太坊智能合约中，calldata是一种特殊的数据位置(data location)，用于存储通过函数调用的输入数据。具体的，calldata数据一般存储在以太坊的交易数据中，这些数据在以太坊成块后无法更改，即是只读的，其通常比其它数据位置(如memory和storage)更加节省gas。
像其它合约一样，Rollup Contract合约可以在虚拟机(例如Ethereum Virtual Machine，EVM)中执行，当然也可以是在容器(例如docker)中执行，这里并不限定。Sequencer可以(或通过Relayer；Sequencer/Relayer通过主网上的外部账户发起)向区块链发起一笔调用主网上Rollup Contract的交易，可以触发该合约的执行。交易的内容例如包括from字段、to字段、value字段、data字段。from字段可以是交易发起方的账户地址(Sequencer/Relayer的主网外部账户地址)，to字段可以代表被调用的智能合约的地址，value字段可以是区块链上原生的通证(例如在以太坊中是以太币的值)，data字段可以包含的调用智能合约的方法和参数。通过在to字段指明调用的智能合约的地址，可以表明是对区块链上某个智能合约的调用。智能合约中一般可以包括一个或多个函数，每个函数可以包括一些输入的参数。交易中通过data字段可以指明所要调用的智能合约中的某个函数，并在data字段中填入需要传入的参数。如前所述，data字段中可以指明调用commitBatch()合约接口。这样，在Rollup Contract合约正常执行时，可以实现将第一主网交易(交易1)中经压缩的Tx21、Tx22、Tx23存入calldata中，并将合约存储中的Current State Root更新为Post State Root并传入参数，不再赘述。
合约执行的结果，一方面可以改变合约的存储，即合约的世界状态，另一方面，该交易的执行结果或相关信息可以记录在区块链的收据(receipt)中。具体的，合约执行结果/相关信息可以表现为收据中的事件(event)。事件的结构例如为如下格式：
Event：
[topic][msg]
[topic][msg]
......
在上述示例中，事件的数量可以为一个或多个。每个事件可以包括主题(topic)和数据(data)等字段。交易执行时输出的事件的格式，可以在合约中指定。通过内置的SDK，区块链客户端或区块链节点可以监听特定topic的事件，并在监听到特定topic事件的情况下，拉取相应的msg的内容，以及可以监听到特定topic或对应msg中的某些内容后执行预设的处理。
通过这种事件机制中，主网上的区块链节点可以将执行结果存放到某个topic对应的msg中，从而Sequencer/Relayer可以通过自身内置的区块链客户端监听该topic，进 而可以获得相应的执行结果，这里例如是第一主网交易在主网Rollup Contract合约上已成功执行。
上述主网上的Rollup Contract合约执行后，可以生成特定topic的事件。
Prover/Relayer监听到相应topic后，可以确定之前调用主网Rollup Contract合约的交易已在主网上执行。这样，Prover可以执行下面的S130步骤。这样，Prover可以通过监听特定事件确认主网上的区块链节点的执行结果，之后再进行S130的验证，从而避免可能由于某些原因第一主网交易并没有在主网上执行的情况下进行验证，例如是第一主网交易没有发送成功，或者是主网Rollup Contract合约对第一主网交易本身的验证失败等。当然，也可以是在S120后直接执行S130。
S130：所述证明器验证第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，对所述打包交易的信息签名，并将签名作为证明通过第二主网交易发送至主网的区块链账本。
所述证明器验证第一交易根，包括：所述证明器生成打包交易的第二交易根，验证第一交易根是否与第二交易根相等。具体的，所述证明器可以将打包的交易Tx21、Tx22、Tx23的hash值组织为Merkle树后生成Merkle Root，即与Sequencer相同的方式将这些交易的hash值组织为Merkle树后生成Merkle Root，该Merkle Root即为第二交易根。这样，所述证明器可以验证第二交易根是否与Sequencer发来的第一交易根相等。
所述证明器生验证第一前状态根，包括：所述证明器生成初始状态的第二前状态根，验证第二前状态根是否与第一状态根相等。具体的，所述证明器可以将Sequencer发来的初始状态的hash值按照Merkle树组织并生成Merkle根，即第二前状态根。这样，所述证明器可以验证第二前状态根是否与Sequencer发来的第一前状态根相等。
如果所述证明器验证第二交易根与Sequencer发来的第一交易根相等，且第二前状态根与Sequencer发来的第一前状态根相等，则说明Sequencer发来的第一交易根与第一前状态根是正确的，进而可以执行后续的内容。
所述证明器可以基于所述Sequencer发来的初始状态按序执行所述打包的交易，生成更新后的状态，并将这些更新后的状态组织成Merkle树，从而得到更新后的状态的Merkle树根节点的hash值，即第二后状态根。进而，所述证明器可以验证第二后状态根与第一后状态根是否相等。如果相等，则说明Sequencer的执行过程是正确的，因为从相同的初始状态开始，Sequencer按序执行打包交易的执行结果与所述证明器独立按序执行相同打包交易的执行结果是相同的。
这样，所述证明器验证可以对所述打包交易的信息签名。具体的，所述证明器验证可以对打包交易的Batch编号、打包交易的交易根、打包交易对应的Post State Root中的至少一个签名。对这些内容中的至少一个进行签名，表明证明器对Sequencer执行本Batch所产生结果的认可。
如前所述，私钥通常代表拥有该私钥的一方的身份，其只能由私钥的拥有者持有，不能公开，而对应的公钥可以公开出去。使用私钥进行的签名可以表示私钥拥有者对数字世界的某种信息进行的认可，签名的信息在协议的消息中也可以表示私钥拥有者 的某种行为。一般的，一个拥有者单独拥有一个私钥，则这个拥有者可以采用自身私钥对某个信息进行签名后发给其它方。接收方收到这个签名后，可以采用对应的公钥对该签名进行验证。验证通过，则接收方可以确认是拥有者对该信息进行了签名，且所签名的信息没有被篡改。
所述证明器可以采用TEE实现。TEE具有与外部完全隔离的可信执行环境，因此可以以保密的方式持有私钥。这样，证明器在验证上述第二后状态根与第一后状态根相等后，可以用自身私钥对所述打包交易的信息签名，以表示对签名内容的认可。
TEE技术中，包括Intel SGX(Intel Software Guard Extension，以下简称SGX)、AMD SEV等。下面以SGX技术为例加以说明。Layer2中的Prover可以基于SGX技术创建Enclave(围圈或飞地)，以作为用于执行验证的TEE。其中，Prover可以利用CPU中新增的处理器指令，在内存中可以分配一部分区域EPC(Enclave Page Cache，围圈页面缓存或飞地页面缓存)，以用于驻留上述的Enclave。上述EPC对应的内存区域被CPU内部的内存加密引擎MEE(Memory Encryption Engine)加密，该内存区域中的内容(Enclave中的代码和数据)只有在CPU内核中才能够被解密，且用于加解密的密钥只有在EPC启动时生成并存储在CPU中。可见，Enclave的安全边界只包含其自身和CPU，无论是特权软件或非特权软件都无法访问Enclave，即便是操作系统管理员和VMM(Virtual Machine Monitor，虚拟机监视器；或称为Hypervisor)也无法影响Enclave中的代码和数据，因而具有极高的安全性。在上述安全性保障的前提下，CPU能够在Enclave中对数据进行处理，具有极高的运算效率，从而兼顾了数据安全性和计算效率。
Intel从第六代CPU开始提供对SGX的支持。而且，这类支持SGX的CPU在出厂前，会由厂商将部署秘钥(Provisioning Key)和信封秘钥(Sealing Key)烧录在CPU中的熔丝(fuse)寄存器内。熔丝寄存器是一种一次性编程的寄存器，一经烧入数据后即熔断熔丝，使得后续该寄存器中的内容仅可读而不再可写。Intel承诺烧录至熔丝寄存器内的秘钥是随机生成的；此外，还承诺一经烧录后关于烧入的秘钥的所有备份都会被销毁，即连Intel自身都不知道烧入的秘钥。Provisioning Key可以代表CPU中的部分信息，例如CPU的代号(例如第六代酷睿、第七代酷睿等)、型号(如桌面型、移动型等)之类。出于安全考虑，关于加密、签名等操作，并不直接使用Provisioning Key，而是采用由Provisioning Key衍生出的一个证明秘钥(attestation key)来进行，因此Provisioning Key起部署作用。
基于用户的指令，可以创建User Enclave，以执行用户指定的程序代码(例如载入TEE中的交易执行代码，包括虚拟机及智能合约)。同时，由于上述Enclave的隔离特性，用户创建的User Enclave很多时候需要首先对外证明自身是可信的，这就涉及Enclave的认证，如下面所说的本地认证和远程认证。
发起远程认证前，CPU可以检测是否存在attestation key。如果没有，则发起初始化。初始化的过程，可以基于秘钥生成协议，通过与Intel服务器的交互(具体可以是SGX中的Provisioning Enclave，是一种架构级的Enclave)，并根据Provisioning Key的生成规则生成EPID(Enhanced Privacy IDentification)，该EPID作为attestation key，一般用作非对称加密秘钥中的私钥。生成的该EPID可以存放于一个Enclave中用于后续的签名，这个Enclave一般称为Quoting Enclave。此外，EPID也可以是存储在 CPU的寄存器中，只有架构级别的Enclave才有权限从CPU中获取，这样，Quoting Enclave也可以是从CPU的寄存器中获取该EPID。上述提到，生成EPID的过程中，SGX(具体如上述提到的的Provisioning Enclave)可以与Intel服务器进行交互，从而，Intel可以通过交互过程得到该EPID对应的公钥。特别的是，该EPID对应的公钥并不会公开，仅由Intel服务器保管。这样的特性适于后续远程认证过程中由Intel的服务器(也称为IAS，即Intel Attestation Server)进行认证。
应用程序的开发者(或后文所称的颁发者)可以将需要载入Enclave的代码/数据(例如载入TEE中的交易执行代码，包括虚拟机及智能合约)用开发者的私钥签名后通过应用程序传至SGX。此外，还可以将颁发者的公钥传至SGX(也可以是上传颁发者的证书，该证书中包括用颁发者签名的信息，该信息中可以包括颁发者的公钥；所述信息还可以包括要载入Enclave的代码/数据的hash值，该hash值可以用于SGX对所载入代码/数据的完整性校验)。所述应用程序执行的过程中，可以通过CPU中集成的指令集向SGX申请创建一个Enclave，这个Enclave一般称为Application Enclave(相当于上述的User Enclave)。SGX在创建Application Enclave时,需要进行页面分配、复制程序代码/数据和度量操作。所述度量，具体的，可以由CPU度量加载到每个页面的代码/数据的hash值，从而在加载完毕后，得到加载了代码/数据的Application Enclave的hash值，这个hash值一般称为MREnclave，哈希算法一般采用SHA256。MREnclave可以存放于称为SECS(SGX enclave control structure)的结构体中。SECS位于所属Enclave的一个EPC页中，用于记录所述Enclave的元数据。所述元数据包括如Enclave密码学测度(即MREnclave)等敏感信息，因此这段结构体只能被CPU的SGX管理机制访问修改。
基于Hash算法的特性，篡改代码/数据，分配多余的页，将恶意代码复制进来，这三者中任一项的发生，哪怕只是改变了一点，都会导致MREnclave的结果产生很大的不同；不同的Application Enclave，该MREnclave值也不同。基于这样的性质，MREnclave一方面可以标识这个Enclave，另一方面也可以用于Application Enclave的完整性验证。通过度量操作，可以采用上述证书中包含的hash值对Application Enclave的完整性进行验证(证书中包含的hash值与MREnclave的生成规则相同，因此正常情况下应当是一致的)，以判断特权软件在创建过程中是否篡改了程序/数据,如是否分配了多余的页、是否将恶意代码复制进来,或是否篡改了复制的数据等。
具体的，SGX创建Application Enclave时可以通过一条初始化指令将前述提到的MREnclave与Application Enclave颁发者签名的证书中的hash值进行比较，如果匹配，则说明载入Application Enclave的代码/数据与预期的一致，即是颁发者的代码/数据；反之，如果不匹配,则说明创建过程存在问题,返回失败结果。如果匹配，SGX还将所述证书中的颁发者公钥进行哈希,从而得到MRSigner。类似的，MRSigner可以用于标识颁发者。该MRSigner也可以保存在前述SECS中。
这样，SECS结构体从某种角度来说相当于Enclave的身份，它同时拥有两种Enclave的身份：MREnclave为Enclave的测度，MRSigner为颁发者的测度。
Application Enclave中的内容需要进行远程认证，以证明自身是合法的SGX中创建的可信的Enclave。如前所述，Application Enclave中的内容需要经Quoting Enclave 中的EPID签名后进行远程认证，这就需要Application Enclave与Quoting Enclave的交互。在此之前，Application Enclave需要向Quoting Enclave证明自身是同一SGX上的Enclave，是可信的。Application Enclave向Quoting Enclave证明自身是同一SGX上的Enclave的过程，即是本地证明。
本地证明的过程可以采用消息认证码(Message Authentication Code，MAC)算法。Application Enclave可以获得Quoting Enclave的MREnclave，并可以生成签名的报告结构(Report)。具体的，Application Enclave可以调用CPU提供的EREPORT指令，CPU可以用一个根秘钥并结合Application Enclave获得的Quoting Enclave的MREnclave来生成一个对称秘钥——REPORT Key。同时，通过调用EREPORT指令，可以获得Application Enclave的身份信息和属性、平台硬件TCB信息，并作为Report的内容；此外，Report中还可以附加用户希望交互的数据。调用EREPORT指令，还将采用MAC算法将REPORT Key和上述Report计算得到第一MAC码，第一MAC码可以作为Report的签名，以用于完整性验证。上述Application Enclave调用CPU的EREPORT指令，CPU可以在内部直接获取Application Enclave的身份信息和属性、平台硬件TCB信息，从而保证这些信息不会受Application Enclave的干预，从而不会被篡改；而且，CPU用根秘钥并结合Quoting Enclave的MREnclave生成REPORT Key，这个过程也是在CPU内部执行的，即使Application ENClave也不会得知该根秘钥，因此不会泄露根秘钥。Quoting Enclave接收到所述Report和第一MAC码后，可以调用CPU提供的EGETKEY指令，并将自身的MREnclave作为输入参数，从而由CPU根据与EREPORT指令中相同的根秘钥和相同的MREnclave得到相同的REPORT Key。进而，Quoting Enclave可以采用相同的MAC算法将该得到的REPORT Key和接收到的Report计算得到第二MAC码，如果该第二MAC码与收到的第一MAC码相同，说明Application Enclave发来的Report的完整性没有被破坏，也就说明Report中包含的Application Enclave的身份信息和属性、平台硬件TCB信息是完整的。由于只有同一SGX上的两个Enclave才能分别通过CPU提供的EREPOR指令和EGETKEY指令结合相同的CPU根秘钥生成相同的Report Key，因此，当验证MAC码通过后，Quoting Enclave可以确认Application Enclave是同一SGX上的Enclave。
通过上述过程，完成本地证明，即Quoting Enclave可以确认Application Enclave是同一SGX上的Enclave。在本地证明基础之上，SGX外部的软件可以向Application Enclave发起挑战(该SGX外部的软件也称为挑战者)，要求该Application Enclave向所述挑战者证明自身是合法的Enclave，且其中运行的是可信的程序。在完成远程认证之后，挑战者可以使用Application Enclave提供的服务。
远程认证中，挑战者可以首先向Application Enclave发起挑战，要求该Application Enclave证明其自身是合法的Enclave，且其中运行的是可信的程序。Application Enclave接收到挑战后，可以生成一个报告，这个报告一般称为Quote。这个Quote报告中可以包括Application Enclave中加载的代码/数据的Hash值，即前述MREnclave，还可以包括前述MRSigner。通过前述的本地证明后，Quote中的内容可以由Quoting Enclave采用EPID签名，例如记为Signature1。这个签名可以是Quoting Enclave采用EPID对所述MREnclave所做的签名，或对MREnclave和MRSigner所做的签名。之后，Application Enclave可以将Quote报告发送至挑战者。由于挑战者并不持有EPID 对应的公钥，挑战者无法验证签名，而所述EPID对应的公钥由英特尔认证服务(Intel Attestation Services，IAS)持有，因此，挑战者将Quote发送至IAS，由IAS进行验签。IAS收到所述Quote后，可以用EPID对应的公钥验证Quote中的签名的正确性，并返回认证验证报告(Attestation Verification Report，AVR)。AVR报告中，可以包括Quote报告和对Quote中的签名的验证结果，例如签名验证是正确或错误的。IAS可以对该AVR报告的内容用Intel的私钥进行签名，并将该签名(例如记为Signature2)和证书附加在AVR报告中，将AVR报告返回至挑战者。挑战者收到AVR报告后，可以采用证书中的公钥(与Intel的私钥对应)对Intel的签名进行验证。此外，AVR报告中也可以不包括证书，而是由挑战者自行下载Intel的证书(Intel的官方网站后其他权威网站可以提供该证书的下载)，并用下载的证书中的公钥对Signature2进行验证。通过对Signature2的验证，可以确认该AVR报告确实是由Intel发出，且是完整的。AVR报告中包括的对Quote中的签名的验证结果，可以证明经由IAS验证后Quote报告所代表的SGX是否合法。进一步的，挑战者可以验证Quote中的MREnclave与MRSigner，例如挑战者可以预先从颁发者处获得加载入SGX中的代码/数据的MREnclave以及颁发者的MRSigner，从而分别与Quote中的MREnclave与MRSigner进行比较，以确认所述SGX中加载的代码/数据是可信的，且是由合法的颁发者颁发的。
在S130中证明器对所述打包交易的信息签名之前，Layer2上交易的发起方可以作为挑战者对证明器中的TEE发起挑战，这个过程中包括证明器中的TEE与IAS交互，以及挑战者与IAS的交互。根据IAS返回的AVR报告，交易的发起方可以确认证明器中的TEE是合法的，且中加载的代码/数据是可信的。从而，Layer2上交易的发起方可以信任证明器中的TEE。
此外，在S130中证明器对所述打包交易的信息签名之后，其它验证者也可以作为挑战者对证明器中的TEE发起挑战，类似上述过程，不再赘述。而且，TEE可以对输入的代码/数据进行hash后签名，从而用自身的可信来担保执行的输入也是可信的；TEE还可以对输出(也就是执行的结果)的hash值签名，也是用自身的可信来担保执行的输入也是可信的。
这样，所述证明器验证基于所述初始状态按序独立执行(也可以称为重放)所述打包交易后，对所述打包交易的信息签名，即是用自身的可信来担保输出结果是可信的。进而，所述证明器可以将签名作为证明通过第二主网交易发送至主网的区块链账本。任何人对该签名产生质疑，可以通过对证明器中的TEE发起挑战来验证，这个过程如上所述也需要与IAS交互，从而从IAS返回的报告确认TEE及其中加载的代码/数据是可信的，并基于对TEE的信任，确信其签名的交易信息是可信的。
需要说明的是，一旦通过远程认证，通过TEE的机制，CPU能够在Enclave中对数据进行处理，具有极高的运算效率，从而兼顾了数据安全性和计算效率。这就比ZK-Rollup的方式还要快很多，例如同样情况下，ZK-Rollup生成proof需要间隔30～50分钟量级(或称小时级)的时间(图4中Block N到Block N+412)缩短到5～10分钟量级的时间(图5中Block N到Block N+62)，甚至在不采用监听模式，而是在S120后直接执行S130的情况下，时间将缩短到更少。并且，生成的证明是一个签名的大小，约为几十字节，与ZK-Rollup类似。
对签名的验证即是采用TEE的公钥进行验证签名的过程，只要保证公钥是可信的，这个验证也将是可信且快速的。所述证明器可以将签名作为证明并通过第二主网交易发送至主网的区块链账本，包括证明器将签名作为证明并通过第二主网交易发送至主网，调用主网上的卷叠合约；所述卷叠合约接收到所述交易后，通过合约中的验证逻辑验证所述签名的正确性。
上述方案也称为EPID方案。在上述EPID方案中，每次挑战都需要挑战者及TEE与远程的IAS通信，这会带来较大延迟，甚至很多运行实体无法在运行时接入Intel服务。因此，改进的SGX DCAP认证协议提供将IAS本地化，例如一些云服务平台、数据中心将IAS本地化在管控机器上，本地化的管控机器也称为本地化的认证服务(Verify Service)。SGX DCAP以证书链的方式提供信任，唯一的信任根为Intel SGX Root CA。
Intel SGX DCAP，全名为Intel Software Guard Extensions Data Center Attestation Primitives，是一种专为数据中心环境设计的远程校验(attestation)技术。如前所述，Intel SGX在硬件层面上提供安全保护的技术，它能够创建一个被称为"enclave"的安全区域，在这个区域内的数据和代码都被硬件加密保护，即使操作系统、虚拟机管理器或者BIOS遭到攻击，也无法窃取或篡改这个区域内的数据。在Intel SGX中，"attestation"是一种机制，用于证明代码正在一个真实的enclave中运行，并且代码和数据没有被篡改。在传统的SGX环境中，这种校验过程需要通过Intel的远程认证服务(IAS)来进行。然而，在数据中心环境中，可能需要进行大量的校验操作，因此Intel引入了DCAP，它允许数据中心自行承载校验服务。DCAP将校验过程从Intel的服务中解耦出来，使得数据中心可以在本地进行校验，从而提高效率，增强可控性，并降低对Intel服务的依赖。简单来说，SGX DCAP就是一种在数据中心环境中使用SGX技术的解决方案，它提供了一种更高效和可控的校验机制。
数据中心的认证服务(Verify Service)可以从Intel IAS获得证书，该证书一般具有一个有效期。在有效期内，部署的SGX实例可以在不与Intel交互的情况下，通过与本地的验证服务(这时相当于本地的IAS)通过交互完成远程报告的生成。当过了有效期之后，数据中心的验证服务需要从Intel IAS获得新的证书。证书中一般包括Intel签名的验证服务的公钥，提供由Intel的公钥验证Intel的签名来保证证书中验证服务的公钥的可信。而验证服务可以采用自身私钥对其它内容签名，并提供由验证服务的公钥验证Intel的签名来保证证书中验证服务的公钥的可信。此外，证书中可以包括有效期，有效期的作用如前所述。
实现SGX DCAP认证协议的过程简略来说可以包括如下(详细部分请参见上述内容)：
首先，证明器中的TEE在本地创建一个受保护的执行环境(User Enclave)，并在其中生成一个密钥对。这个密钥对包括一个公钥和一个私钥，其中公钥将被用来生成一个证明报告(Quote)。
然后，证明器中的TEE将公钥和一些关于User Enclave的信息(例如其度量值)一起提交给本地的Quoting Enclave(QE)，请求生成一个证明报告。QE会对这些信息进行签名，并将签名和其他信息打包到证明报告中。
接着，证明器中的TEE将这个证明报告提交给认证服务(Verify Service)，此服 务将验证报告的有效性，并对其中包含的公钥进行签名，生成一个证书。这个证书包含认证服务对证明器中TEE的签名外，还可以包括其它内容，与前述远程认证报告类似，因此也可以视为一种由认证服务生成的远程认证报告。
最后，生成的证书将被返回给证明器的TEE，后续证明器可以采用自身私钥对执行结果签名，并可以提供该证书。这样，其他人可以通过证书中公钥对签名进行验证以确保执行结果是可信的。而该证书是由认证服务颁发的，即由认证服务采用自身私钥的签名来保证的，该证书的可信可以由Intel IAS为认证服务颁发的证书进一步来保证。上述多个证书和签名的信任传递关系即证书链原理。
总之，证明器可以将证书通过第二主网交易发送至主网的区块链账本。一种典型的方式中，证明器可以将证书与所述证明器的签名一并通过第二主网交易发送至主网的区块链账本。当采用上述EPID方案时，所述证书包括IAS为所述证明器生成的远程认证报告，这样，验证者可以通过验证该证书来确定证明器对交易信息的签名是合法的。当采用上述DCAP方案时，所述证书可以包括认证服务为所述证明器颁发的证书。如果基于对认证服务的信任，则可以延伸到认证服务为证明器颁发的证书，从而验证者可以采用该证书中的公钥对证明器的签名进行验证。如果需要更高层次的信任，除了需要认证服务为证明器颁发的证书外，可能还需要包括IAS为所述认证服务生成的远程认证报告，这样，通过Intel权威的认证(即远程认证报告，相当于Intel为认证服务颁发的证书)可以保证认证服务签名的可信，加上认证服务为证明器颁发的证书，可以将信任向下传导，从而保证证明器签名的可信。这即是SGX DCAP以证书链的方式提供信任。
上述验证者执行的验证逻辑可以内置于Rollup Contract合约中，对外可以以合约接口的方式提供，如验证接口。这样，所述证明器将签名作为证明并通过第二主网交易发送至主网，具体可以是在交易中调用的区块链账本，包括证明器将签名作为证明并通过第二主网交易发送至主网，调用主网上的Rollup Contract合约的验证接口，通过该接口可以将所述签名传入。这样，验证接口内部可以执行验证逻辑，具体包括验证所述签名的合法性。验证签名合法性的过程，主要包括采用证明器的公钥验证签名的合法性。
此外，通过验证接口还可以将所述签名对应的证明器的证书一并通过第二主网交易传入，所述证书中可以包括所述证明器的公钥。这样，除了采用证明器的公钥验证签名的合法性之外，还可以包括验证证明器证书的合法性。所述证书，如前所述，可以包括IAS为所述证明器生成的远程认证报告，或包括认证服务为所述证明器颁发的证书(还可以包括IAS为所述认证服务生成的远程认证报告)。相应的，验证证书，可以包括采用Intel的权威公钥验证证明器证书的合法性，或者可以包括采用Intel的权威公钥验证认证服务的证书的合法性，并采用认证服务的证书中的公钥验证证明器证书的合法性。
如上，采用TEE作为二层网络上的证明器，由于TEE中重放交易并验证接近于原生执行的速度，因此可以带来更低的延迟。
上述图4中例举了Layer2上的全局状态为4个的情况，即包含Alice、Bob、Charlie、 David四个全局状态的情况。实际上，Layer2上的一个Batch中可能包含数百甚至上千笔的交易，这些交易可能涉及更多的状态，例如上万个状态。如果Layer2中的交易包括涉及Layer2上合约的交易，则一个合约可能涉及更多的状态，则整体上Layer2中的状态更多，例如数万个状态。这样，在S120中，排序器将全部的状态的初始状态发送至二层网络中的证明器，数据量较大。因此，本申请一种实现二层网络卷叠的方法，包括如下：
S210：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根。
S210具体过程与前述S110类似，不再赘述。
S220：所述排序器发送打包的交易、第一交易根、所述打包交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器。
为了加以说明，假设如图6所示，Layer2中的交易(包括普通转账交易和涉及合约的交易)共涉及8个状态，如图6左下角中8、9、10、11、12、13、14、15这8个hash值对应的状态。并假设打包到Batch M中的交易，按序执行前后影响到的状态是8、9对应的Alice和Bob，而不涉及10、11、12、13、14、15这6个hash值对应的状态。如图所示，这样，打包到Batch M中的交易按序执行后发生改变的是Alice和Bob的余额，Charlie和David的余额并未改变(也就是10、11两个树节点的hash值没有改变，这里示出了10和11两个节点对应的内容；12、13、14、15对应的内容也没有改变，这里省略其内容)。
所述排序器除了发送打包的交易、第一交易根、初始状态对应的第一前状态根和第一后状态根至二层网络的证明器以外，可以发送所述打包交易执行前该打包交易读集的SPV证明至二层网络的证明器。
如图6中的例子，所述排序器可以发送树节点8、9对应的状态，以及由节点5的hash值、节点3的hash值组成的SPV证明至二层网络的证明器。这样，可以避免把10、11、12、13、14、15这6个叶子节点对应的状态发送至证明器。
SPV，本身来自于比特币中的概念，全称是Simplified Payment Verification，即简单支付验证。SPV证明使用Merkle树来工作。这里，Batch M中涉及的状态组成一颗Merkle树，树的根(即Merkle根)包含在Batch M的Header中。Merkle树的结构使得可以通过一个很短的路径(Merkle路径)来验证任何状态是否存在于某个特定的Merkle根下。这个路径仅包含一些必要的节点，而不是所有的叶子节点对应的状态内容。
如图6中例子所示，一个SPV证明包括两个叶子节点(用黄色表示)对应的状态，一个Merkle路径(用红色表示)。
SPV证明中的Merkel路径，提到的Merkle是一种树形的数据结构，可以是比特币中的Merkle树，也可以是以太坊中的MPT树，此外还可以是SMT等。
MPT全称为Merkle Patricia Tree，是结合了Merkle Tree(默克尔树)和Patricia Tree(压缩前缀树，一种更节省空间的Trie树，字典树)的一种树形结构。Merkle Tree，默克尔树算法对每个交易都计算一个Hash值，然后两两连接再次计算Hash，一直到最顶层的Merkle根。以太坊中采用改进的MPT树，例如是16叉树的结构，通常也简称为MPT 树。以前述提到的以太坊中的状态树(state trie)为例，状态树中包含以太坊网络中每个账户所对应的存储内容的键值对(key and value pair，也写作key-value，简称k-v或kv)。状态树中的“键”(key)可以是一个的160bits的标识符(例如以太坊账户的地址或地址的hash值的一部分，下面统称为账户地址)，这个账户地址分布于从状态树的根节点开始到叶子节点的存储中。状态树中的“值”是通过对以太坊账户的信息进行编码(使用递归长度字典编码(Recursive-Length Prefix encoding，RLP)方法)生成的。如前所述，对于外部账户来说，值包括nonce和balance；对于合约账户来说，值包括nonce、balance、codehash和storage_root。
如前所述，state_root是当前区块中所有账户的状态组成的MPT树的根的哈希值，即指向state_root的为一颗MPT形式的状态树state trie。这个MPT树的根节点一般为一个扩展节点(Extension Node)或一个分支节点(Branch Node)，state_root中存储的一般为这个根节点的hash值。如图7所示，根节点可以与下面一层或多层的Extension Node/Branch Node相连，这些多层的树节点可以统称为中间节点(Internal Node)。从这个MPT的根节点到叶子节点中每个节点中的一部分值按照顺序串联起来可以构成账户地址并作为key，叶子节点中存储的账户信息为这个账户地址对应的value，这样，构成了key-value键值对。这个key也可以是sha3(Address)后取一部分,即账户地址的hash值(hash算法例如采用sha3算法)的一部分，其存储的值value可以为rlp(Account)，即账户信息的rlp编码。其中账户信息是
[nonce,balance,storageRoot,codeHash]构成的四元组。如前所述，对于外部账户来说，一般只有nonce和balance两项，而storageRoot、codeHash字段默认存储空字符串/全0字符串。也就是说，外部账户不存储合约，也不存储合约执行后的产生的状态变量。合约账户一般包括Nonce,Balance,Storage root,CodeHash。其中Nonce是该合约账户的交易计数器；Balance是账户余额；Storage root对应另外一个MPT，通过Storage root能链接到合约相关的状态的信息；CodeHash是合约代码的hash值。不论是外部账户还是合约账户，其账户信息一般都位于一个单独的叶子节点(Leaf Node)中。从根节点的Extension Node/Branch Node到每个账户的Leaf Node，可能中间会经过若干个分支节点以及扩展节点。
state trie可以是MPT形式的树，一般是16叉树，即每一层最多可以有16个孩子节点。对于Extension Node，用于存储共同前缀，其一般有1个孩子节点，这个孩子节点可以是Branch Node。对于Branch Node，其最多可以有16个孩子节点，其中可能包括Extension Node和/或Leaf Node。
其中，对于state trie中的一个合约账户来说，其storage_Root指向另一颗同为MPT形式的树，其中存储了合约执行涉及的状态变量(state variable)的数据。这个storage_Root指向的MPT形式的树为Storage Trie，即Storage Trie的根节点的hash值。一般的，这个Storage Trie树存储的也是key-value键值对。key表明状态变量的地址，其取值可以是合约中的状态变量声明的位置(从0开始计数的值)经过一定规则处理后得到的结果，例如是sha3(状态变量声明的位置)，或者是sha3(合约名称+状态变量声明的位置)。value用于存储状态变量的取值(例如是经RLP编码的值)。从根节点经中间节点到叶子节点的路径上存储的一部分数据连起来构成key，叶子节点 中存储value。前面提到，这个Storage trie也可以是MPT形式的树，一般也是16叉树，即对于Branch Node，其最多可以有16个孩子节点，这些孩子节点可能包括Extension Node和/或Leaf Node。而对于Extension Node，其一般可以有1个孩子节点，这个孩子节点可以是Branch Node或Leaf Node。
例如图7中的state Trie的Leaf Node Account P，该账户是一个合约账户，其Storage Root锁定了该合约存储中的所有状态。这些状态组织为MPT树，树形结构如该Storage Root链接的Storage trie。这个链接的Storage trie中，以Leaf Node State Variable N为例，例如为前述合约代码示例的storedData的值，则其key为sha3(storedData的声明位置，后面将详述)，其value值为s(为了简洁，这里省略了对value的编码格式，例如是RLP，后续类似，不再赘述)。其中，key的值顺序的分布于storage Trie的根节点到叶子节点(即Leaf Node Variable N)中。
再例如，图7中的state Trie中的Leaf Node Account C，该账户是一个外部账户，其key为sha3(Address C)，即账号C的地址的hash值(hash算法例如采用sha3算法)，其存储的值value可以为(Account)，其中账户信息Account是[nonce,balance]构成的二元组。如前所述，由于Account C为外部账户，因此其账户信息是nonce和balance两项(这里省略了codehash和storage root，以下类似)。例如一个外部账户，其nonce为20，Balance为4550，则Leaf Node State Variable C这个叶子节点中即存储nonce＝20，balance＝4550。而Account C的地址为key，其值顺序的分布于state Trie的根节点到叶子节点(即Leaf Node Variable C)中。
这些状态，包括外部账户的k-v和合约账户的k-v，最终存储于数据库中。数据库中的存储，并不是直接存储这些账户的状态，即不是直接存储这些账户的k-v，而是存储每个树节点本身的k-v值。
如图8的示例中所示，上一级的MPT结构中，对于叶子节点A1，通过根节点A8(Extension Node)中shared nibble的a7—中间节点A7(Branch Node)的槽位1—叶子节点A1中key-end的1335，顺序组合起来构成该叶子节点的key，即为a711335，在该叶子节点中存储Balance＝45.0ETH，Nonce＝n1。对于叶子节点A2，通过根节点A8(Extension Node)中shared nibble的a7—中间节点A7(Branch Node)的槽位7—节点A6(Extension Node)中shared nibbles的d3—中间节点A5(Branch Node)中的槽位3-叶子节点A2中key-end的7，顺序组合起来构成该叶子节点的key，即为a77d337，在该叶子节点中存储Balance＝1.00WEI，Nonce＝n2。对于叶子节点A3，通过根节点A8(Extension Node)中shared nibble的a7—中间节点A7(Branch Node)的槽位f—叶子节点A3中key-end的9365，顺序组合起来构成该叶子节点的key，即为a7f9365，在该叶子节点中存储Balance＝1.1ETH，Nonce＝n3。对于叶子节点A4，通过根节点A8
(Extension Node)中shared nibble的a7—中间节点A7(Branch Node)的槽位7—节点A6(Extension Node)中shared nibbles的d3—中间节点A5(Branch Node)中的槽位9-叶子节点A4中key-end的7，顺序组合起来构成该叶子节点的key，即为a77d397，在该叶子节点中存储Balance＝0.12ETH，Nonce＝n4，CodeHash＝c1，Storage root＝s1。s1可以为H(A10)，即下一层树的根节点A10的hash至。其中，A1、A2和A3的叶子节点中存储的是外部账户的信息，A4的叶子节点中存储的是合约账户的信息。对于合约账户， 其包含下一级MPT，构成Storage Trie，用于存储该合约账户中的状态变量。
如图8的示例中所示，下一级的MPT结构中，对于叶子节点A11，通过根节点A10(Branch Node)中的槽位3—叶子节点A11中key-end的35b2e4，顺序组合起来构成该叶子节点的key，即为335b2e4，在该叶子节点中存储“张三_A＝20”，例如表示在合约中定义的A类型数字资产归属于张三的份额为20，即张三的A类资产的余额为20。对于叶子节点A12，通过根节点A10(Branch Node)中的槽位7—叶子节点A12中key-end的c25988，顺序组合起来构成该叶子节点的key，即为7c25988，在该叶子节点中存储“李四_B＝20”，例如表示在合约中定义的B类型数字资产归属于李四的份额为50，即李四的B类资产的余额为50。对于叶子节点A15，通过根节点A10(Branch Node)中的槽位f—中间节点A13(Extension Node)中shared nibble的a—中间节点A14(Branch Node)的槽位6—叶子节点A15中key-end的be33，顺序组合起来构成该叶子节点的key，即为fa6be33，在该叶子节点中存储“storedData＝s”。对于叶子节点A16，通过根节点A10(Branch Node)中的槽位f—中间节点A13(Extension Node)中shared nibble的a—中间节点A14(Branch Node)的槽位9—叶子节点A16中key-end的9365，顺序组合起来构成该叶子节点的key，即为fa99365，在该叶子节点中存储“王五_A＝35”，例如表示在合约中定义的A类型数字资产归属于王五的份额为35，即王五的A类资产的余额为35。
上述MPT树的节点构成中，用前缀prefix表示树节点类型，例如0表示包含偶数个shared nibbles(共享的半字节)的Extension Node，用1表示包含奇数个shared nibble(s)的Extension Node，用2表示包含偶数个nibbles的Leaf Node，用3表示包含奇数个nibble(s)的Leaf Node。
上述节点构成中，下一个树节点的整体内容的hash值，填入上一个树节点的对应位置中。数据库中，实际上存储每个树节点的key-value的映射，其中value包括这个树节点中存储的内容，对应的key是这个树节点整体内容的hash值。这样，数据库中实际存储的树节点k-v如下表：

表3、数据库中实际存储的树节点k-v
上表3中，用H()表示hash计算。这样，下一个树节点的hash值锚定在了上一个树节点中。通过这样的层层hash，得到整颗state trie树的根hash，并将该根hash锁定到了区块头的state root字段中。
普通的MPT树，叶子节点里存储具体的内容(状态)。而采用上述的具体结构，在有新的状态产生时，需要在树上插入新的叶子节点，随之产生到根节点的路径上的一系列变化，包括Branch Node和Extension Node的分裂、合并以及hash值重新计算并更新等复杂操作。类似的，有状态删除时，需要在树上删除已有的叶子节点，也会产生Branch Node和Extension Node的分裂、合并以及hash值重新计算并更新等复杂操作。有状态发生改变时，除了叶子节点中内容的改变，其也会影响到根节点的Branch Node和Extension Node的分裂、合并以及hash值重新计算并更新等复杂操作。总体来说，树的深度和具体的Branch Node和Extension Node的结构，会随着叶子节点中状态的变化而发生较多的改变。
比特币中的交易Merkle树也是类似的，当一个区块打包有4笔交易时，它的Merkle树的叶子节点就由这四笔交易组成，即它的叶子节点只会有四个，树的深度是2层。如果一个区块打包有1024笔交易，那就有1024个叶子节点，深度是11层，这显然是一棵规模更大的树。
Libra提出的SMT(Sparse Merkle Tree，稀疏默克尔树)也是一种Merkle类型的数据结构，但也具有其特殊性，有些地方与一般的Merkle树不同。最主要的区别点在于，叶子节点的数量、树的深度和形状预先就固定了。前述比特币中的交易Merkle树和以太坊中的MPT树，树的深度、规模等是变化的，即是动态、不固定的。而SMT是存预先确定的数量且数量不会改变的状态，用一个固定大小的树来存。例如，以太坊中账户的地址长度是20字节，总计有2160个不同的地址，即2160个Account。实际上，Ethereum的账户是可以用SMT来存的(尽管它没有这么做)。但是，SMT中很可能不会存在2160个Account，可能明显小于这个数量。那么，对于空缺的账户，可以用预设值(例如空白)来填充，以表示这是个未启用的空白账户。在底层数据库中，可以不存储空白(是预设值)的叶子节点，而只存储非空白的叶子节点。
采用SMT的好处在于，很多时候可以压缩Merkle路径的大小，例如采用1bit来表示预设值，这就比用完整的hash值(例如hash256中的hash值长度是256bit)小很多，从 而使得SPV证明的大小大大降低。
S230：所述证明器验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
所述证明器验证第一交易根，类似前述S130，不再赘述。
所述证明器在所述SPV证明基础上验证第一前状态根，具体包括：所述证明器基于SPV证明的读集以及Merkle路径计算Merkle根，得到第二前状态根，验证第二前状态根是否与第一状态根相等。如果相等，则说明所述证明器发来的第一前状态根是正确的。Hash计算的特性：每个计算中的值发生一点小的改变，都会使得最终的结果产生很大的不同。基于这个特性，使得证明器无法造假，即无法提供错误的叶子节点中的状态或是提供错误的Merkle树节点的hash值的基础上产生一个正确的结果，即无法产生正确的Merkle根。具体的，所述证明器可以计算图6中左下角节点8对应内容的hash值作为节点8的值，计算节点9对应内容的hash值作为节点9的值；将节点8和节点9的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点4的hash值；将节点4和SPV证明中节点5的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点2的hash值；将节点2和节点3的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点1的hash值，即作为第二前状态根，从而验证第二前状态根是否与第一前状态根相等。
所述证明器按序执行所述打包交易并生成第二后状态根，可以是所述证明器基于所述该打包交易涉及的读集按序执行所述打包交易，并在执行过程中更新写集，以及在所述SPV证明基础上根据更新的写集重算Merkle根，以生成第二后状态根。具体的，如图9所示，并假设处理的一个Batch中包含3个交易，分别是：
Tx_21：Alice→Bob 20
Tx_22：Bob→Alice 10
Tx_23：Alice→Bob 20
这个Batch中的交易涉及的状态是Alice和Bob，因此，这个Batch涉及的读集可以包括Alice和Bob这两个账户。读集的SPV证明中，除了可以包括Alice：50和Bob：100这两个读集之外，还可以包括所在Merkle树的节点5的hash值，节点3的hash值。这样，证明器在这个Batch读集的基础上，也就是在Alice：50和Bob：100基础上，按序执行Batch中的所有交易。
例如，Tx_21、Tx_22、Tx_23按序执行后产生的读写集包括如下：
Tx_21执行前的读集包括Alice：50和Bob：100，Tx_21执行后Alice的账户余额变化为30，Bob的账户余额变化为120，则产生的写集为Alice：30和Bob：120。
Tx_22执行前的读集包括Alice：30和Bob：120，Tx_22执行后Alice的账户余额变化为40，Bob的账户余额变化为110，则产生的写集为Alice：40和Bob：110。
Tx_23执行前的读集包括Alice：40和Bob：110，Tx_23执行后Alice的账户余额变化为20，Bob的账户余额变化为130，则产生的写集为Alice：20和Bob：130。
这个Batch中的交易按序执行完毕后，产生的这个Batch的终局状态是Alice： 20和Bob：130这两个写集。所述证明器结合该写集所在Merkle树的节点5的hash值，节点3的hash值，可以得到更新后的状态所在Merkle树根节点的hash值，即第二后状态根。这里，例如产生的写集仍然是Merkle树中第8、9两个节点对应的内容，例如节点8对应的状态，Alice的余额相对于初始状态的50修改为20，节点9对应的状态，Bob的余额相对于初始状态的100修改为130。所述证明器可以基于Alice:20重新计算叶子节点8的hash值，并基于Bob:130重新计算叶子节点9的hash值，从而产生新的hash值。则类似的，所述证明器可以在产生的写集基础之上，结合所述SPV证明中Merkle路径(即红色3、5两个节点的hash值)计算得到Merkle根的hash值，从而作为第二后状态根。
具体的，所述证明器可以计算节点8对应的写集内容的hash值作为节点8的值，计算节点9对应写集内容的hash值作为节点9的值；将节点8和节点9的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点4的hash值；将节点4和SPV证明中节点5的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点2的hash值；将节点2和节点3的两个hash值例如做顺序拼接后再次以相同的hash算法计算hash值，作为节点1的hash值，即作为第二后状态根，从而验证第二后状态根是否与第一后状态根相等。
进而，所述证明器可以验证第二后状态根与第一后状态根是否相等。如果相等，则说明Sequencer的执行过程是正确的，因为从相同的初始状态开始，Sequencer按序执行打包交易的执行结果与所述证明器独立按序执行相同打包交易的执行结果是相同的。
这样，所述证明器验证可以对所述打包交易的信息签名。具体的，所述证明器验证可以对打包交易的Batch编号、打包交易的交易根、打包交易对应的Post State Root中的至少一个签名。对这些内容中的至少一个进行签名，表明证明器对Sequencer执行本Batch所产生结果的认可。
如前所述，所述证明器可以采用TEE实现。TEE具有与外部完全隔离的可信执行环境，因此可以以保密的方式持有私钥。这样，证明器在验证上述第二后状态根与第一后状态根相等后，可以用自身私钥对所述打包交易的信息签名，以表示对签名内容的认可。
所述证明器可以采用TEE实现。TEE具有与外部完全隔离的可信执行环境，因此可以以保密的方式持有私钥。这样，证明器在验证上述第二后状态根与第一后状态根相等后，可以用自身私钥对所述打包交易的信息签名，以表示对签名内容的认可。
在S230中证明器对所述打包交易的信息签名之前，Layer2上交易的发起方可以作为挑战者对证明器中的TEE发起挑战。如果挑战成功，交易的发起方可以确认证明器中的TEE是合法的，且中加载的代码/数据是可信的。从而，Layer2上交易的发起方可以信任证明器中的TEE。
此外，在S230中证明器对所述打包交易的信息签名之后，其它验证者也可以作为挑战者对证明器中的TEE发起挑战，类似前述过程，不再赘述。而且，TEE可以对输入的代码/数据进行hash后签名，从而用自身的可信来担保执行的输入也是可信的；TEE还可以对输出(也就是执行的结果)的hash值签名，也是用自身的可信来担保执行的 输入也是可信的。
这样，所述证明器验证基于所述初始状态按序独立执行(也可以称为重放)所述打包交易后，对所述打包交易的信息签名，即是用自身的可信来担保输出结果是可信的。进而，所述证明器可以将签名作为证明通过第二主网交易发送至主网的区块链账本。任何人对该签名产生质疑，可以通过对证明器中的TEE发起挑战来验证；如果验证通过，则可以基于对TEE的信任，确信其签名的交易信息是可信的。
对签名的验证即是采用TEE的公钥进行验证签名的过程，只要保证公钥是可信的，这个验证也将是可信且快速的。所述证明器可以将签名作为证明并通过第二主网交易发送至主网的区块链账本，包括证明器将签名作为证明并通过第二主网交易发送至主网，调用主网上的卷叠合约；所述卷叠合约接收到所述交易后，通过合约中的验证逻辑验证所述签名的正确性。
总之，证明器可以将证书通过第二主网交易发送至主网的区块链账本。一种典型的方式中，证明器可以将证书与所述证明器的签名一并通过第二主网交易发送至主网的区块链账本。当采用上述EPID方案时，所述证书包括IAS为所述证明器生成的远程认证报告，这样，验证者可以通过验证该证书来确定证明器对交易信息的签名是合法的。当采用上述DCAP方案时，所述证书可以包括认证服务为所述证明器颁发的证书。如果基于对认证服务的信任，则可以延伸到认证服务为证明器颁发的证书，从而验证者可以采用该证书中的公钥对证明器的签名进行验证。如果需要更高层次的信任，除了需要认证服务为证明器颁发的证书外，可能还需要包括IAS为所述认证服务生成的远程认证报告，这样，通过Intel权威的认证(即远程认证报告，相当于Intel为认证服务颁发的证书)可以保证认证服务签名的可信，加上认证服务为证明器颁发的证书，可以将信任向下传导，从而保证证明器签名的可信。这即是SGX DCAP以证书链的方式提供信任。
上述验证者执行的验证逻辑可以内置于Rollup Contract合约中，对外可以以合约接口的方式提供，如验证接口。这样，所述证明器将签名作为证明并通过第二主网交易发送至主网，具体可以是在交易中调用的区块链账本，包括证明器将签名作为证明并通过第二主网交易发送至主网，调用主网上的Rollup Contract合约的验证接口，通过该接口可以将所述签名传入。这样，验证接口内部可以执行验证逻辑，具体包括验证所述签名的合法性。验证签名合法性的过程，主要包括采用证明器的公钥验证签名的合法性。
此外，通过验证接口还可以将所述签名对应的证明器的证书一并通过第二主网交易传入，所述证书中可以包括所述证明器的公钥。这样，除了采用证明器的公钥验证签名的合法性之外，还可以包括验证证明器证书的合法性。所述证书，如前所述，可以包括IAS为所述证明器生成的远程认证报告，或包括认证服务为所述证明器颁发的证书(还可以包括IAS为所述认证服务生成的远程认证报告)。相应的，验证证书，可以包括采用Intel的权威公钥验证证明器证书的合法性，或者可以包括采用Intel的权威公钥验证认证服务的证书的合法性，并采用认证服务的证书中的公钥验证证明器证书的合法性。
如上，采用TEE作为二层网络上的证明器，由于TEE中重放交易并验证接近于原生 执行的速度，因此可以带来更低的延迟。一旦本地的TEE通过远程认证，通过TEE的机制，CPU能够在Enclave中对数据进行处理，具有极高的运算效率，从而兼顾了数据安全性和计算效率。这就比ZK-Rollup的方式还要快很多，例如同样情况下，从ZK-Rollup生成proof需要间隔30～50分钟量级(或称小时级)的时间(图4中Block N到Block N+412)，缩短到本申请(可以称为TEE-Rollup)5～10分钟量级的时间(图6中Block N到Block N+62)，甚至在不采用监听模式，而是在S220后直接执行S230的情况下，时间将缩短到更少。并且，生成的证明是一个签名的大小，约为几十字节，与ZK-Rollup类似。
与前述类似的，所述对所述打包交易的信息签名，可以是对打包交易的Batch编号、打包交易的交易根、打包交易对应的后状态根中的至少一个签名。
所述对所述打包交易的信息签名，可以是对打包的若干个连续Batch的编号、打包交易的交易根、打包交易对应的后状态根中的至少一个签名；或是对打包的若干个连续Batch分组后的每个组中Batch编号、打包交易的交易根、打包交易对应的后状态根中的至少一个签名。
所述证明器验证第一交易根与第一前状态根之前，还可以包括：所述排序器发送一笔调用卷叠合约的第一主网交易至主网，该第一交易中包含所述打包交易的Batch Header中的各字段，以及经过压缩的交易或经过压缩的读写集(术语称为State Diff)；
进而，所述证明器可以监听主网上的合约执行执行结果。具体与前述实施例类似，不再赘述。
而且，所述证明器还可以将所述证书与所述签名一并通过第二主网交易发送至主网的区块链账本。所述证书中可以包括IAS为所述证明器生成的远程认证报告，或包括所述证书包括认证服务为所述证明器颁发的证书，或还包括IAS为所述认证服务生成的远程认证报告。
所述证明器将签名作为证明并通过第二主网交易发送至主网的区块链账本，包括证明器将签名作为证明并通过第二主网交易发送至主网，调用主网上的卷叠合约。并还可以包括：所述卷叠合约接收到所述交易后，通过合约中的验证逻辑验证所述签名的正确性。所述卷叠合约接收到所述交易后，通过合约中的验证逻辑验证所述签名的正确性，还可以包括：验证证书的合法性，所述证书中包括所述证明器的公钥。
所述验证证书的合法性，具体可以包括：
采用Intel的权威公钥验证证明器证书的合法性；或者，
采用Intel的权威公钥验证认证服务的证书的合法性，并采用认证服务的证书中的公钥验证证明器证书的合法性。
为了提高Layer2中的TPS，需要加快交易的执行速度。为此，可以采用并行计算的方式来加快交易的执行速度。并行计算是相对于串行计算来说的，它是一种一次可执行多个指令的算法，目的是提高计算速度，及通过扩大问题求解规模，从而解决大型而复杂的计算问题。所谓并行计算可分为时间上的并行和空间上的并行。时间上的并行就是指流水线技术，而空间上的并行则是指用多个处理器并发的执行计算。另外，为了提高效率，一般对于执行过程可以采用分组执行或流水线方式来提升效率。当 Prover性能较高时，整体的性能瓶颈在于Sequencer执行交易的过程时，可以将Sequencer中执行交易的部分解耦，例如解耦为Executor，如图10所示；这样，可以采用前述的流水线方式提升整体的执行速度。此外，可以对Executor做水平扩展(horizontal scaling，也称为scaling out)，即将Executor扩展为多个实体(逻辑实体或物理实体)，如图11所示；这样，可以采用前述分组执行方式，从而提高执行环节的执行速度，进而提升对Prover的利用率。
以下先以图10为例给出流水线方式实现二层网络卷叠的方法实施例，包括：
S310：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器。
后续，执行器和证明器并行执行S320和S330：
S320：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
所述后序打包交易，指相对于S330中前序打包交易靠后序号的打包。例如后序打包交易的序号是N+1，则上述S320，具体包括：所述执行器生成第N+1个包中交易的第一交易根，基于所述第N+1个包中交易执行前的初始状态按序执行所述第N+1个包中的交易并生成第一后状态根；所述执行器发送第N+1个包中交易、第一交易根、所述第N+1个包中交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
S330：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
相应的，所述前序打包交易，指相对于S320中后序打包交易靠前序号的打包。例如前序打包交易的序号是N，则上述S330，具体包括：所述证明器验证第N个包中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述第N个包中交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述第N个包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
前序打包交易后后续打包交易，不限于序号是N和N+1的关系，例如可以是N和N+2的关系之类。
这样，执行器可以不断执行后续打包交易的相应工作，并将结果发送至证明器，而证明器可以不断执行前序打包交易的相应工作，形成流水线式的工作。从而，执行器、证明器的算力可以被高效利用，能实现交易的持续执行和证明持续生成。
在采用SPV证明的情况下，上述方案为如下：
S410：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后 发送至执行器；
后续，执行器和证明器可以并行的执行S420和S430：
S420：所述执行器生成后序打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
S430：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下以图11为例给出分组并行方式实现二层网络卷叠的方法实施例，包括：
S510：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方。
所述至少两个执行器，是至少两个执行器线程/协程或至少两个执行器进程之类。所述至少两个执行器是至少两个执行器线程/协程，可以位于同一进程中；或者，所述至少两个执行器是至少两个执行器进程，可以位于位于同一物理机/虚拟机上或不同物理机/虚拟机上。当至少两个执行器进程位于不同物理机/虚拟机上，这些不同物理机/虚拟机可以是同一参与方的物理机/虚拟机。这样，同一参与方的物理机/虚拟机之间不存在信任问题。
例如，所述排序器对所述拉取的交易排序并打为包后，对打包的交易进行分组。对于普通转账交易，可以根据交易访问的账户将多个交易划分为多个交易组，各个交易组之间不访问相同的账户，从而可以并行执行各个交易组。对于交易涉及调用智能合约时，一些简单情况下可以是对智能合约代码进行静态分析，从而得到访问(包括读/写)的状态变量；此外对于一些复杂情况，在执行该交易之前不能预知该交易中访问的状态变量，从而无法对多个交易进行有效的分组，也就无法并行执行交易。对于后者，可以对多个交易进行预执行，得到各个交易的预执行读写集，从而可以根据预执行读写集对这些交易进行分组。当然，也可以对普通转账交易进行预执行从而得到读写集。
具体的，交易的预执行读写集中例如包括预执行读集和预执行写集，所述预执行读集包括该交易在预执行中读取的变量的键值对，所述预执行写集包括该交易在预执行中写入的变量的键值对。所述状态变量例如包括Layer2中的外部账户、或者为合约账户中定义的状态变量。
可通过不同的算法对多个交易进行分组。在一种实施方式中，可通过有向无环图(Directed Acyclic Graph，DAG)算法对多个交易进行分组。具体是，首先根据交易之间的依赖关系绘制多个交易之间的DAG图。例如，假设从节点根据主节点预执行多个交易的顺序来执行该多个交易，因此，可根据多个交易的预执行读写集和预执行顺序来确定交易之间的依赖关系。其中，如果一个交易的预执行读集与另一个交易的预执 行写集中包括相同的Key，或者一个交易的写集和另一个交易的写集中包括相同的Key，那么该两个交易中的在后预执行的交易(例如交易Tx2)需要依赖在前预执行的交易(例如交易Tx1)，因此，在DAG图中可绘制交易Tx1指向交易Tx2，在交易Tx2依赖交易Tx1的执行的情况中，可认为交易Tx1和交易Tx2为冲突交易，需要串行执行，即在执行交易Tx1之后执行交易Tx2。
图12为一实施例中多个交易的DAG图的示意图，图中圆圈表示DAG图中的节点，圆圈中的数字表示交易编号，节点之间的箭头表示节点之间的有向连接边。在得到多个交易的DAG图之后，可根据DAG图对多个交易进行分组，使得每两个交易组中的交易在DAG图中为分离的节点，即一个交易组中的任一交易与另一个交易组中的每个交易之间没有连接边。
如图12中所示，通过箭头连接的多个交易(即交易Tx1～Tx8)为冲突交易，需要分到一个交易组中。在执行交易Tx1～Tx8时，可首先并行执行交易(Tx3、Tx5)和(Tx1、Tx2、Tx4)，其中，交易Tx3、Tx5串行执行，交易Tx1、Tx2、Tx4需要串行执行。交易Tx6需要等待交易Tx4和交易Tx5都执行完成之后再执行，交易Tx7和交易Tx8需要等待交易Tx5和交易Tx6都执行完成之后才能并行执行。其中，交易Tx5和交易Tx6连接三个以上节点，又可以称为分叉点，当DAG图中的分叉点较多的情况中，造成后续交易对该分叉点的等待时间较长。同时，DAG算法需要的状态空间较多。因此，多个交易之间的冲突交易较多的情况中，使用DAG分组算法的效率降低。
在另一种实施方式中，可通过并查集算法对多个交易进行分组。并查集是一种树型的数据结构，用于处理一些不相交集合(disjoint sets)的合并及查询问题。并查集通常包含两种操作：查找(Find)，用于查询两个元素是否在同一个集合中；合并(Union)，用于把两个不相交的集合合并为一个集合。通过该算法，当两个交易的预执行读写集中包括相同的Key时，就可以将该两个交易合并到同一个集合中，从而获得多个集合，每两个集合中的交易不会访问相同的Key，从而可以并行处理多个集合。然而，由于并查集算法不考虑交易对Key的访问是读还是写，只要两个交易访问了相同的Key，就将该两个交易分到一个组中，因此有可能将读取相同key的两个交易分到同一个组中。因此，相比于DAG算法得到的分组结果，通过并查集算法进行分组得到的多个交易组的并行度较低。
所述执行器参与方可以包括多个执行器。所述排序器还可以读取存储中所述分组的各组交易集合的读集中的value值，并将读取的value值发送至对应的执行器。
S520：所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
一个Sequencer可以与一参与方的多个Executor相连，如图11中所示，与一个参与方的两个Executor相连。参与方可以采用一执行器生成所述打包交易的第一交易根。此外，参与方可以采用所述至少两个执行器各自按序执行所述打包交易中的不同交易 分组。这里的“一执行器”可以是两个Executor中的一个，也可以不是。
所述至少两个执行器各自按序执行所述打包交易中的不同交易分组后，可以将执行结果发送至“一执行器”，从而该“一执行器”合并所述所有交易分组的执行结果并生成第一后状态根，进而可以由该执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器。这里的“一执行器”可以是“所述至少两个执行器”中的一个或不是。
S530：所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
这样，执行器可以不断执行下一打包交易的相应工作，并将结果发送至证明器，而证明器可以不断执行上一打包交易的相应工作。从而，证明器的算力可以被高效利用，能实现证明的持续快速生成。
此外，可以由参与方一执行器对打包后的交易进行分组，而不是由排序器分组。则该情况的实施例为如下：
S610：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方。
S620：所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
S630：所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下给出分组并行+流水线方式实现二层网络卷叠的方法实施例，包括：
S710：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方。
并行执行S720和S730：
S720：所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
具体的，可以是如下：所述执行器参与方采用一执行器生成所述第N+1个打包交易的第一交易根；所述至少两个执行器各自基于所述第N+1个打包交易执行前的初始状态按序执行所述第N+1个打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送第N+1个打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
S730：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
具体的，可以是如下：所述证明器验证第N个打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述第N个打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述第N个包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
上述例子中，也可以改为由参与方一执行器对打包后的交易进行分组，而不是由排序器分组，则该情况的实施例为如下：
S810：二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方。
并行执行S820和S830：
S820：所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
具体的：所述执行器参与方采用一执行器生成所述第N+1个打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述第N+1个打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送第N+1个打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现。
S830：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
具体的：所述证明器验证第N个打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述第N个打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述第N个包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
上述各个实施例中，当执行器整体的性能较高时，整体的性能瓶颈可能在于Prover TEE验证的过程。这时，可以将Prover TEE扩充为多个，从而并行执行上述过程。显然的，多个Prover TEE并行执行可以提升Layer1上证明的速度，从而进一步降低Layer1上交易确认的延迟。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根；所述排序器发送打包的交易、第一交易根、所述打包交易执行前该打包交易读集的SPV证明以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；
证明器，用于验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S320和S330：
S320：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S330：所述证明器验证前序打包交易的第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
执行器和证明器并行执行S420和S430：
S420：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行 前的初始状态按序执行所述后序打包交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述第N+1个包中交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S430：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖 关系的交易分组并将不同分组发送至执行器参与方；
所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
以下介绍本申请一种二层网络实施例，包括交易池、排序器、证明器，其中：
交易池，用于接收二层网络上用户发送的交易；
排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
并行执行S820和S830：
S820：所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
S830：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代 码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如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)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施 本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采 用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内请中。

Claims (17)

  1. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根；
    所述排序器发送打包的交易、第一交易根、所述打包交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  2. 如权利要求1所述的方法，所述证明器在所述SPV证明基础上验证第一前状态根，包括：所述证明器基于SPV证明的读集以及Merkle路径计算Merkle根，得到第二前状态根，验证第二前状态根是否与第一前状态根相等。
  3. 如权利要求1所述的方法，所述按序执行所述打包交易并生成第二后状态根，包括：
    基于所述该打包交易读集按序执行所述打包交易，并在执行过程中更新写集，以及在所述SPV证明基础上根据更新的写集重算Merkle根，以生成第二后状态根。
  4. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
    执行器和证明器并行执行S1和S2：
    S1：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    S2：所述证明器验证前序打包交易的第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  5. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
    执行器和证明器并行执行S3和S4：
    S3：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述第N+1个包中交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    S4：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  6. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
    所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  7. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
    所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  8. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
    所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明 器采用可信执行环境实现；
    所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  9. 一种实现二层网络卷叠的方法，包括：
    二层网络的排序器从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
    并行执行S5和S6：
    所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  10. 如权利要求1-9中任一项所述的方法，所述证明器为至少两个且并行执行。
  11. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打包，生成打包交易的第一交易根，基于所述打包交易执行前的初始状态按序执行所述打包的交易并生成第一后状态根；所述排序器发送打包的交易、第一交易根、所述打包交易执行前该打包交易读集的SPV证明以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；
    证明器，用于验证第一交易根，并在打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  12. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
    执行器和证明器并行执行S1和S2：
    S1：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包的交易并生成第一后状态根；所述执行器发送后序 打包交易、第一交易根、所述后序打包交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    S2：所述证明器验证前序打包交易的第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  13. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后发送至执行器；
    执行器和证明器并行执行S3和S4：
    S3：所述执行器生成后序打包交易的第一交易根，基于所述后序打包交易执行前的初始状态按序执行所述后序打包交易并生成第一后状态根；所述执行器发送后序打包交易、第一交易根、所述第N+1个包中交易执行前读集的SPV证明以及第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    S4：所述证明器验证前序打包交易的第一交易根，并在前序打包交易读集的SPV证明基础上验证第一前状态根；两个验证通过后，按序执行所述前序打包交易并生成第二后状态根；验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  14. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
    所述执行器参与方采用一执行器生成所述打包交易的第一交易根；所述至少两个执行器各自基于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  15. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
    所述执行器参与方采用一执行器生成所述打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基 于所述打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送打包的交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述打包的交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述打包中交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  16. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打包后，将不具有依赖关系的交易分组并将不同分组发送至执行器参与方；
    所述执行器参与方采用一执行器生成后续打包交易的第一交易根；所述至少两个执行器各自基于所述第后续打包交易执行前的初始状态按序执行所述后续打包交易中的不同交易分组，由所述一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后续打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
  17. 一种二层网络，包括交易池、排序器、证明器，其中：
    交易池，用于接收二层网络上用户发送的交易；
    排序器，从交易池中拉取交易，对所述拉取的交易排序并打为包后发送至执行器参与方；
    所述执行器和证明器并行执行S5和S6：
    S5：所述执行器参与方采用一执行器生成所述后序打包交易的第一交易根，并将不具有依赖关系的交易分组后将不同分组发送至至少两个执行器；所述至少两个执行器各自基于所述后序打包交易执行前的初始状态按序执行所述打包交易中的不同交易分组，由一执行器合并所述所有交易分组的执行结果并生成第一后状态根；所述执行器参与方发送后序打包交易、第一交易根、所述交易执行前的初始状态以及初始状态对应的第一前状态根和第一后状态根至二层网络的证明器；所述证明器采用可信执行环境实现；
    S6：所述证明器验证前序打包交易中第一交易根与第一前状态根；两个验证通过后，基于所述初始状态按序执行所述前序打包交易，生成第二后状态根，验证第二后状态根与第一后状态根相等后，采用可信执行环境中的私钥对所述前序打包交易的信息签名，将签名作为证明并通过第二主网交易发送至主网的区块链账本。
PCT/CN2024/128764 2023-11-16 2024-10-31 实现二层网络卷叠的方法及二层网络 Pending WO2025103147A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202311537959.4 2023-11-16
CN202311537959.4A CN117439728A (zh) 2023-11-16 2023-11-16 实现二层网络卷叠的方法及二层网络

Publications (1)

Publication Number Publication Date
WO2025103147A1 true WO2025103147A1 (zh) 2025-05-22

Family

ID=89551441

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/128764 Pending WO2025103147A1 (zh) 2023-11-16 2024-10-31 实现二层网络卷叠的方法及二层网络

Country Status (2)

Country Link
CN (1) CN117439728A (zh)
WO (1) WO2025103147A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117439728A (zh) * 2023-11-16 2024-01-23 蚂蚁区块链科技(上海)有限公司 实现二层网络卷叠的方法及二层网络
CN119946056B (zh) * 2025-01-24 2025-11-04 上海焜耀网络科技有限公司 基于去中心化Sequencer的OptimisticRollup架构的实现方法及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190164153A1 (en) * 2017-11-30 2019-05-30 Shashank Agrawal Blockchain system for confidential and anonymous smart contracts
CN114385756A (zh) * 2021-06-17 2022-04-22 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法和区块链节点
CN114780640A (zh) * 2022-04-28 2022-07-22 蚂蚁区块链科技(上海)有限公司 一种区块链中的数据处理方法及区块链节点
CN115293901A (zh) * 2022-08-15 2022-11-04 中国工商银行股份有限公司 区块链扩容方法和装置
CN116561740A (zh) * 2023-04-28 2023-08-08 蚂蚁区块链科技(上海)有限公司 区块链中的交易执行方法、节点和系统
CN117439728A (zh) * 2023-11-16 2024-01-23 蚂蚁区块链科技(上海)有限公司 实现二层网络卷叠的方法及二层网络

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190164153A1 (en) * 2017-11-30 2019-05-30 Shashank Agrawal Blockchain system for confidential and anonymous smart contracts
CN114385756A (zh) * 2021-06-17 2022-04-22 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法和区块链节点
CN114780640A (zh) * 2022-04-28 2022-07-22 蚂蚁区块链科技(上海)有限公司 一种区块链中的数据处理方法及区块链节点
CN115293901A (zh) * 2022-08-15 2022-11-04 中国工商银行股份有限公司 区块链扩容方法和装置
CN116561740A (zh) * 2023-04-28 2023-08-08 蚂蚁区块链科技(上海)有限公司 区块链中的交易执行方法、节点和系统
CN117439728A (zh) * 2023-11-16 2024-01-23 蚂蚁区块链科技(上海)有限公司 实现二层网络卷叠的方法及二层网络

Also Published As

Publication number Publication date
CN117439728A (zh) 2024-01-23

Similar Documents

Publication Publication Date Title
CN115152177B (zh) 提供机密知识的专门证明的系统和方法
JP6955026B2 (ja) 並列処理ブロックチェーントランザクションのためのシステムおよび方法
CN114175035B (zh) 用于核实区块链交易有效的协议
US12355862B1 (en) Method and system for utilizing the infrastructure of a blockchain to enhance the degree of security and veracity of another blockchain
JP7157348B2 (ja) ブロックチェーンシステム、承認端末、スマートコントラクト登録方法、および、スマートコントラクト登録プログラム
Wang et al. Exploring unfairness on proof of authority: Order manipulation attacks and remedies
CN114175036B (zh) 使用区块链交易提供链下功能
CN110245942B (zh) 结合用户类型和判断条件的收据存储方法和节点
CN110264198B (zh) 结合代码标注与交易类型的有条件的收据存储方法和节点
WO2025103146A1 (zh) 实现二层网络卷叠的方法、二层网络和证明器
Tate et al. Multi-user dynamic proofs of data possession using trusted hardware
CN113874839B (zh) 区块链交易内的脚本内函数
JP2024542873A (ja) データの不変性、合意性及び可用性を生成及び維持するシステム及び方法
US20200250655A1 (en) Efficient, environmental and consumer friendly consensus method for cryptographic transactions
Krishnamurthi et al. A brief analysis of blockchain algorithms and its challenges
CN117439728A (zh) 实现二层网络卷叠的方法及二层网络
WO2025139339A1 (zh) 区块链系统及其资源管理方法
WO2025139340A1 (zh) 区块链系统的资源管理方法、区块链节点和区块链系统
Park et al. Beyond the blockchain address: Zero-knowledge address abstraction
CN112187475A (zh) 基于可信计算进行多中心记账的方法、装置及相关产品
JP7575651B2 (ja) 分散台帳ネットワークにおけるセキュアな更新のための新しいデータコンテンツパケット、システム及び方法
Davidson State machine replication and consensus with Byzantine adversaries
WO2025139342A1 (zh) 区块链系统的管理方法和区块链节点
WO2025139343A1 (zh) 区块链系统的管理方法和区块链节点
WO2025139341A1 (zh) 区块链系统的资源管理方法、区块链节点和区块链系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24890504

Country of ref document: EP

Kind code of ref document: A1