WO2025139339A1 - Blockchain system and resource management method thereof - Google Patents

Abstract

A resource management method of a blockchain system, and a blockchain system. The method executed by a second blockchain system located in Layer 2 comprises: receiving a seventh transaction, the seventh transaction comprising a resource transfer share, a first account and a first rollup mode corresponding thereto, and a second account and a second rollup mode corresponding thereto; executing the seventh transaction, comprising: on the basis of the resource transfer share, transferring a second target resource from a first sub-account that belongs to the first rollup mode and corresponds to the first account to a first relay sub-account that belongs to the first rollup mode and corresponds to a relay account, and generating a cross-mode transfer event; on the basis of the cross-mode transfer event, generating an eighth transaction, the eighth transaction comprising the resource transfer share, the relay account, the second account and the second rollup mode; and executing the eighth transaction, comprising: on the basis of the resource transfer share, transferring the second target resource from a second relay sub-account that belongs to the second rollup mode and corresponds to the relay account to a second sub-account that belongs to the second rollup mode and corresponds to the second account.

Description

Blockchain system and resource management method thereof

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on December 29, 2023, with application number 202311869835.6 and application name “Blockchain system and its resource management method”, all contents of which are incorporated by reference in this application.

Technical Field

The embodiments of this specification belong to the field of blockchain technology, and more particularly to a blockchain system and a resource management method thereof.

Background Art

The blockchain system is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, the blockchain system has received more and more attention and application.

Summary of the invention

The purpose of the present invention is to provide a blockchain system and a resource management method thereof.

In a first aspect, a resource management method for a blockchain system is provided, the method being executed by a second blockchain system supporting M roll-up modes, the second blockchain system including a packaged transaction batch chain, the batch chain including a plurality of batches connected in sequence, the method including: receiving a seventh transaction, the sender field and the receiver field of the seventh transaction including a first account and a second account respectively, the seventh transaction also including a resource transfer share, a first roll-up mode corresponding to the sender field, and a second roll-up mode corresponding to the receiver field; packaging the seventh transaction into a first batch in the batch chain, the first batch corresponding to the first roll-up mode, executing the seventh transaction, and realizing: according to the resource transfer share, a transaction belonging to the first roll-up mode and corresponding to the The first sub-account corresponding to the first account transfers the second target resource to the first relay sub-account belonging to the first cascading mode and corresponding to the relay account, and generates a cross-mode transfer event; according to the cross-mode transfer event, an eighth transaction is generated, the sender field and the receiver field of the eighth transaction respectively include the relay account and the second account, and the eighth transaction also includes the resource transfer share and the second cascading mode; the eighth transaction is packaged into the second batch in the batch chain, the second batch corresponds to the second cascading mode, and the eighth transaction is executed to achieve: according to the resource transfer share, the second relay sub-account belonging to the second cascading mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second cascading mode and corresponding to the second account.

In a second aspect, a second blockchain system is provided, including: a receiver configured to receive a seventh transaction, wherein a sender field and a receiver field of the seventh transaction include a first account and a second account respectively, and the seventh transaction also includes a resource transfer share, a first rollup mode corresponding to the sender field, and a second rollup mode corresponding to the receiver field; a sorter configured to package the seventh transaction into the first in the batch chain a batch, the first batch corresponds to the first cascading mode, the seventh transaction is executed to achieve: according to the resource transfer share, the first sub-account belonging to the first cascading mode and corresponding to the first account transfers the second target resource to the first relay sub-account belonging to the first cascading mode and corresponding to the relay account, and generates a cross-mode transfer event; the shared bridge is configured to generate an eighth transaction according to the cross-mode transfer event, the sender field and the receiver field of the eighth transaction respectively include the relay account and the second account, and the eighth transaction also includes the resource transfer share and the second cascading mode; the sorter is configured to package the second transaction into the second batch in the batch chain, the second batch corresponds to the second cascading mode, and the eighth transaction is executed to achieve: according to the resource transfer share, the second relay sub-account belonging to the second cascading mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second cascading mode and corresponding to the second account.

According to a third aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

According to a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method described in the first aspect.

In the technical solution provided by the embodiments of this specification, since M types of rollup modes correspond to the same batch chain formed by connecting multiple batches in sequence, the batch submitted later is bound through the state root of the world state. If the batch submitted earlier with a relatively forward position is rolled back for some reason, the batch submitted later with a relatively backward position must be rolled back. Therefore, there is no need to wait for the batch submitted earlier to enter an unchangeable state before continuing to submit a new batch in the batch chain. Correspondingly, when the user initiates the seventh transaction through the first account and the second account, and expects to transfer the target resource between two sub-accounts belonging to different rollup modes and corresponding to the first account and the second account respectively, the second blockchain system does not need to wait for the first batch to which the seventh transaction belongs to enter an unchangeable state, and can continue to execute the eighth transaction corresponding to the seventh transaction in a second batch located after the first batch, thereby completing the resource transfer transaction expected to be completed by the seventh transaction, which is conducive to quickly completing the resource transfer in the second blockchain system according to the user's expectations.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG1 is one of the principle schematic diagrams of Layer 2 in one embodiment;

FIG2 is a second schematic diagram of the principle of Layer 2 in one embodiment;

FIG3 is a third schematic diagram of the principle of Layer 2 in one embodiment;

FIG4 is a fourth schematic diagram of the principle of Layer 2 in one embodiment;

FIG5 is a schematic diagram of a process of registering a Rollup mode in an embodiment;

FIG6 is one of the flow charts of a resource method of a blockchain system provided in an embodiment of this specification;

FIG7 is a schematic diagram of Layer 1 and Layer 2 cooperating to implement resource transfer in one embodiment;

FIG8 is a schematic diagram of a client of a blockchain system and a transaction initiated by the client in one embodiment;

FIG9 is a second flowchart of a resource management method for a blockchain system provided in an embodiment of this specification;

FIG10 is a flowchart of a resource management method for a blockchain system provided in an embodiment of this specification;

FIG11 is a fourth flowchart of a resource management method for a blockchain system provided in an embodiment of this specification;

FIG12 is a fifth flowchart of a resource management method for a blockchain system provided in an embodiment of this specification;

FIG13 is a schematic diagram of the structure of a batch chain provided in an embodiment of this specification;

FIG. 14 is a schematic diagram of an event relationship provided in an embodiment of this specification.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

There is a classic CAP theorem in distributed systems - Consistency, Availability, and Partition tolerance. You can't have all three at the same time, which is referred to as the "impossible triangle" problem. There is also an impossible triangle in the blockchain system: efficiency, decentralization, and security. Although there is no clear theoretical demonstration of the "impossible triangle" of the blockchain system here, it is a summary of the existing blockchain system. The efficiency, decentralization, and security here are defined as follows: Efficiency: the number of transactions processed per second, that is, TPS (Transaction per Second); Decentralization: the threshold for participating nodes is low enough to ensure that there are a large number of distributed nodes in the system; Security: It is difficult enough to launch attacks on the blockchain system.

In response to the "impossible triangle" problem of the above-mentioned blockchain 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. When there are a large number of transactions to be processed, especially when there are many complex transactions, Layer1 will be congested. In addition to ordinary transfer transactions, 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, resulting in large transaction delays.

High gas fees (gas fees, or transaction fees) often become an obstacle to transactions. Although it has shifted from PoW (proof of work) to PoS (proof of stake), this only changes the way of obtaining the right to record on the blockchain, and the transaction fees that need to be paid to the nodes that obtain the right to record have not decreased significantly. This is because 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. For example, 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. As shown in Figure 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. In this way, while reducing the pressure on 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 To save the final state, this design requires ensuring the correctness of the execution process of transactions or contracts on Layer2, and that 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 transaction (Post-State) and the transaction. It can be used to verify whether the state transfer corresponding to the transaction 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.

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

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 run smart contracts on EVM when publishing and calling them in Ethereum. 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 address on the chain and includes a balance, a counter nonce, a hash value of the contract code Codehash, and the root of the contract storage Storage_Root. Through Codehash and 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. In other words, the smart contract generates a virtual account containing contract code and account storage (Storage) on the blockchain. Subsequently, nodes on Layer 1 can receive transaction requests to call deployed smart contracts, which may include the address of the called contract, the function in the called contract, and the input parameters. Generally, after the transaction request reaches consensus, 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 Merkle root. Ethereum uses an improved MPT tree, such as a 16-way tree structure, which is usually referred to as an MPT tree. In fact, 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 state of all accounts in the current block, that is, the state trie pointing to State_Root is a state tree in the form of MPT. Part of the value of each node from the root node to the leaf node of this MPT is connected in sequence to form an account address and serve as a key. The account information stored in the leaf node is the value corresponding to this account address, forming a key-value pair. The aforementioned 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 stored value value 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]. For external accounts (Externally Owned Account, referred to as EOA), there are generally only two items, nonce and balance, and the storageRoot and codeHash fields store empty strings/all 0 strings by default. That is, external accounts do not store contracts, nor do they store state variables generated after the execution of contracts. Contract accounts include Nonce, Balance, Storage root, CodeHash. Regardless of whether it is an external account or a contract account, its account information is generally located in a separate leaf node.

For a contract account (CA) in the state trie, its storage_Root points to another tree in the form of MPT, which stores the data of the state variables involved in the contract execution. The MPT tree pointed to by this storage_Root is the Storage Trie, that is, the hash value of the root node of the Storage Trie is stored in the storage_Root. Generally, this Storage Trie tree also stores key-value pairs. The key indicates the address of the state variable, and its value can be the result obtained 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. In the State trie and the Storage trie therein, 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.

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

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;

Before the execution of transactions in Batch 1, it is assumed that there are 4 states in total, which are called the initial state of Batch 1, that is, the state value locked by Pre State Root in Figure 3, respectively:

Alice: 50, Bob: 100, Charlie: 150, David: 200

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

Alice: 20, Bob: 110, Charlie: 170, David: 200

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. Similarly, as mentioned above, 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, namely the 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, namely the Post State Root. For Batch M, a timestamp can also 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. For the M+1th batch, the Pre State Root in its header is equal to the Post State Root in the 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.

The Layer2 Rollup mechanism can include Optimistic-Rollup (OP-Rollup for short), ZK-Rollup (zero-knowledge proof Rollup, ZK refers to zero knowledge), TEE-Rollup mechanism, etc.

In the OP-Rollup mechanism, Layer2 can be set up with: receivers, repeaters and sequencers of the transaction pool (Txpool); in the ZK-Rollup and TEE-Rollup mechanisms, Prover can also be set up in Layer2; for the TEE-Rollup mechanism, Prover can be set up in TEE.

The OP-Rollup mechanism is described as an example below. As shown in Figure 3, assume that transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24 are collected in TxPool. Sequencer sorts and packages these transactions according to the timestamps in these transactions, for example, packs Tx21, Tx22, and Tx23 into Batch M, and organizes the hash values of these transactions into Merkle to generate Merkle Root (i.e., transaction 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 ²ⁿ , the last transaction can be assigned multiple copies to make up ²ⁿ , thereby calculating the root of the 2-fork Merkle tree. As shown in Figure 3, Tx23, which is the last transaction in chronological order, is repeated once to complete the four transactions, even if the number of transactions reaches 2 ² , and the root of the 2-fork Merkle tree can be calculated. The Sequencer sorts the transactions according to the timestamps in the transactions and packs Tx21, Tx22, and Tx23 into Batch M+1.

Before the transaction sequence Tx21, Tx22, and Tx23 in Batch M are executed, all the states include Alice: 50, Bob: 100, Charlie: 150, and David: 200 as mentioned above. The Sequencer can organize these states into a Merkle tree, and use the hash value of the root node of the Merkle tree as the pre-state root corresponding to Batch M, and store it in the Pre-State-Root field of the Batch-M-Header. Then the Sequencer can execute the three transactions Tx21, Tx22, and Tx23 in sequence; the results of executing these three transactions generate new states, as mentioned above, Alice: 20, Bob: 110, Charlie: 170, and David: 200. The Sequencer can organize these updated states into a Merkle tree, and use the hash value of the root node of the Merkle tree as the post-state root corresponding to Batch M, and store it in the Post-State-Root field of the Batch-MHeader.

Furthermore, Sequencer can send a transaction 1 that calls Rollup Contract to Layer1 through Relayer. Transaction 1 contains some or all fields in Batch M Header and compressed transaction sequences 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. In Ethereum smart contracts, 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). Although the process of compressing the transaction sequence included in the transaction batch is omitted in this article, it can be understood that the transaction sequence included in any transaction batch described below can be either an uncompressed transaction sequence or a compressed transaction sequence.

It is worth noting that in an Ethereum transaction, the signature part accounts for about half of the total volume, and its From field can be 0 bytes, because the From field can be recovered from the signature. In Rollup, BLS or other schemes can usually be used for aggregation, and the signature of each transaction is compressed to about 0.5 bytes on average. Correspondingly, in Rollup transactions, since the From field of the transaction cannot be recovered from this aggregated signature, it needs to be represented separately by 4 bytes.

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.

The above compression scheme and the use of BLS for signature aggregation are ideal designs. However, in the actual Rollup schemes, a compressed transaction still takes up 40-50 bytes of space, and does not include the signature, which means that BLS signature aggregation has not yet been adopted.

Continuing from the previous text, after receiving the transaction 1 that calls the Rollup Contract in Layer1, after consensus, 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. In other words, 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. For example, as an example, Tx21, Tx22, and Tx23 are stored in Tx_12 in the transaction tree locked by Tx_Root in the Block N Header. In addition, as an implementation, the Pre State Root and Post State Root in the Batch M Header in Transaction 1 can be stored in State 1 and State 2 in the contract state on Layer 1 through Rollup Contract, respectively. As mentioned above, State 1 and State 2 are contained in the state trie locked by State_Root in Block N Header, specifically, in the storage trie. To distinguish them, State 1 and State 2 in the contract state on Layer 1 are respectively referred to as Last State root and Current State root. In addition, for simplicity, only Current State root can be saved in the contract state on Layer 1 without saving Last State root, as shown in the following code example. In other implementations, Last State root and Current State root can also be stored in calldata in Layer 1 like transactions in Layer 2, which will not be repeated here. For the former, for example, the commitBatch() contract interface in Layer1 is called as follows: function CommitBatch(bytes[]calldata_transactions, bytes32_preStateRoot, bytes32_postStateRoot). The basic verification logic can be set inside the CommitBatch() contract interface, such as verifying whether the Pre State Root in the current transaction 1 is equal to the Current State Root in the contract storage. If they are equal, the transaction on Layer2 passed in in transaction 1 is stored in calldata, and the Current State Root in the contract storage is updated to Post State Root.

In this way, 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 and the hash value of the state root before and after the execution of this batch of transactions. As shown above, here, for example, a transaction on Layer1 can be sent, as shown in Figure 3. Transaction 1. As you can see, 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 information submitted on Layer2, so it is named "Optimistic". Although there is such an assumption, for the sake of prevention and deterrence, traders who submit Layer2 information will still be required to pledge a portion of Layer1 assets in the Rollup Contract of OP-Rollup (typically native tokens on the chain, such as Ethereum on Ethereum). For the Layer2 information submitted to Layer1, although the transactions therein are compressed, as mentioned above, it can still 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.

Although OP-Rollup is optimistic, a challenge period can still be set on Layer1, and anyone can use fraud proofs to challenge during the challenge period. Typical reasons include the challenger proving that a transaction in the Batch was not executed correctly, that is, the execution of the transaction did not produce the correct state. If a transaction in a Batch is proven to be invalid, the Batch is also invalid. The Rollup contract on Layer1 can roll back the Batch chain of Layer2, and the invalid Batch and all the batches behind it will become orphan blocks. Once the fraud proof is successful, part of the deposit will be paid to the challenger and the rest will be destroyed. On the contrary, if no one submits a fraud proof until the end of the challenge period, the Rollup contract can confirm the Batch. Fraud proof is a method of verifying data validity adopted by the Optimistic Rollup scheme. At present, fraud proofs can be divided into two types: single-round interactive type and multi-round interactive type.

In a single-round interactive fraud proof implementation, the disputed transaction is replayed on Layer1, and submitted after checking whether there is an invalid state. For example, 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.

It should be noted here that although 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 are simulated and executed based on the original text of all transactions in Batch M passed in by the challenger. This is because the compressed Batch M transactions in the calldata are generally only used to restore the execution process of all transactions on Layer2 and the status of all accounts, thereby eliminating the security risks caused by data availability on Layer2; and the authenticity of the compressed Batch M transactions in the calldata without signatures is yet to be determined, while the transactions passed in by the challenger are complete transactions, and the validity of the transactions can be verified; furthermore, because the initial state cannot be verified, the contract storage only contains the state root instead of the state, unless all transactions are re-executed in sequence from Batch 0 until the entire state is obtained after Batch M-1 is executed, which is obviously inefficient and uneconomical.

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

In a multi-round interactive fraud proof, when Bob challenges the data synchronized by the Sequencer, the Sequencer needs to divide the disputed Batch range into two equal ranges, the front and the back, and return them through the dispute() contract interface, for example. 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. Here, Bob will send the original text of the challenged transaction (including the signature of each transaction) and the global state before the transaction is executed, and the Sequencer will send the challenge The Pre State Root (also called state commitment) before the transaction is executed and the Post State Root after the execution are handed over to the Rollup Contract of Layer1 for calculation and judgment. Specifically, for example, the Rollup Contract verifies the global state before the challenge transaction is executed based on the Pre State Root before the challenge transaction is executed, 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. Compared with the Post State Root sent by the Sequencer, if they are different, it means that the challenge is successful, otherwise the challenge fails. In actual applications, Arbitrum does not use a binary search method, but a K search method, that is, N instructions are divided into N/K groups each time to find fraudulent instructions, which is more efficient.

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

In general, since the design of OP-Rollup requires that all data related to status updates and verification be placed on Layer 1, the scalability and throughput improvement of OP-Rollup are the most limited, and a waiting period of 7 days or even longer is required. This means that there will be a delay in extracting assets from OP-Rollup, and you need to wait until the window period has passed.

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. In ZK-Rollup, unlike OP-Rollup, Layer2 will also generate a proof (including proof) for the transaction Batch (for example, using cryptographic proof algorithms such as ZK-SNARK). The proof in this proof can prove that the Post State Root is obtained by correctly executing the transaction sequence in the corresponding transaction Batch in order based on the Pre State Root. This can be confirmed by verifying the proof without re-executing the transactions in the Batch to verify.

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, and the prover converts this information into a special form, called witness (witness; select part of it as public input and the other part as private input). Then, 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. Moreover, 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. It should be noted that 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.

With zero-knowledge proof, 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. Moreover, in ZK-Rollup, 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) is For example, when transaction 1 is submitted to the Rollup Contract of Layer1, the 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 (for example, the verification algorithm including ZK-SNARK) in the smart contract, 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 to prove 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.

However, the computational complexity of zero-knowledge proofs such as ZK-SNARK in the process of generating proofs is very large, which also means that generating proofs will be time-consuming. Assume that as shown in Figure 4, the compressed Tx21, Tx22, and Tx23 are stored in calldata in Layer1 through transaction 1, and the Post State Root is stored in the Current State Root in the contract state on Layer1. This transaction 1 is located in Block N of Layer1 as shown in Figure 4. The delay caused by the complex computation required to generate the corresponding proof in Layer2 may cause the proof of Batch M to be transferred to Block N+412 on Layer1 through transaction 2 for a period of time. From Block N to Block N+412, there is obviously a certain delay, which may be close to the hour level.

In order to solve the problem of complex calculation and long time required to generate proof, TEE-Roll mechanism is proposed. The difference between TEE-Rollup mechanism and ZK-Rollup is that Prover is implemented by TEE (Trusted Execution Environment), and Prover can use the private key in TEE to sign the relevant information of a transaction batch after verifying the transaction root, previous state root and post-state root of a transaction batch provided by Sequencer, and then use the signature as proof and publish it to Layer1 through Relayer, which can be quickly verified by Rollup Contract.

After the challenge period corresponding to any transaction Batch submitted by Layer2 ends, or after the proof corresponding to any transaction Batch is verified in the Rollup Contract of Layer2, the arbitrary Batch and its corresponding contract call transaction (such as transaction 1 used to call the Commit Batch() contract interface in the Rollup Contract) enter the finality state; it also means that all transactions belonging to the arbitrary Batch in Layer2 have entered the finality state.

With the development of Rollup technology, for management members of any blockchain system in Layer2, they may expect that the blockchain system in Layer2 and the blockchain system in Layer1 can support multiple Rollup modes (i.e., stacking modes) due to the needs of certain specific business purposes. Different Rollup modes do not necessarily mean that different Rollup mechanisms must be adopted. For example, two Rollup modes may adopt the same Rollup mechanism. The difference is that Layer1 may adopt different methods to store the packaged transactions submitted by Layer2. For example, the Rollup mechanism adopted by Rollup mode 1 and Rollup mode 2 is ZK-Rollup. Rollup mode 1 requires Layer1 to store the packaged transactions in Layer2 in Layer1 according to the original transaction text. However, Rollup mode 2 requires Layer1 to store the original transaction text of the transaction in Layer2, but requires Layer1 to store the transaction hash of the transaction in Layer2.

Although Layer 1 and Layer 2 are used to represent blockchain systems in the previous article, it should be understood that Layer 1 can usually include one blockchain system, while Layer 2 can include one or more blockchain systems. The one or more blockchain systems included in Layer 2 all use the blockchain system in Layer 1 as their corresponding upper-layer blockchain system.

If the Rollup modes use different Rollup mechanisms, it must mean that the Rollup modes are different. Based on this, in the embodiments of this specification, different Rollup modes will be distinguished mainly based on the differences in Rollup mechanisms. For example, If the Rollup mechanism used between Layer1 and Layer2 is ZK-Rollup, the corresponding Rollup mode is still recorded as ZK-Rollup; if the Rollup mechanism used between Layer1 and Layer2 is TEE-Rollup, the corresponding Rollup mode is still recorded as TEE-Rollup.

With the increase in Rollup modes, it is expected that there will be a resource management method for blockchain systems that supports users to manage Layer2-related resources more securely and conveniently through Layer1. For example, a Rollup mode can be started or terminated according to the needs of management members, and target resources held by multiple accounts belonging to multiple Rollup modes in Layer2 can be managed according to the needs of users.

In view of the above problems, in the solution provided by the embodiment of this specification, as shown in Figure 5, at least a rollup contract Rollup Contract is deployed in Layer1 (i.e., the first blockchain system), and the Rollup Contract includes a second method function for supporting the registration of the Rollup mode. The relay contract Bridge Contract and the management contract Governance Contract can also be deployed in the first blockchain system. Bridge Contract is mainly responsible for managing the blockchain system in Layer2, such as managing the accounts under the second blockchain system in Layer2 and the resources they hold; Governance Contract is mainly responsible for managing the registration information of various Rollup modes.

It should be noted that Bridge Contract and Governance Contract may not be deployed independently, but the method functions they contain to implement the corresponding functions are directly integrated into the contract code of Rollup Contract. The method functions included in Bridge Contract and Governance Contract and the specific functions they implement will be described in detail below.

Figure 6 is one of the flow charts of a resource method of a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of registering a new roll-up mode (referred to as the second roll-up mode) in the first blockchain system and the second blockchain system.

6 , the method may include but is not limited to the following steps S601 to S607 .

Step S601: The first blockchain system receives a fourth transaction, where the fourth transaction is used to call a second method function in the Rollup Contract. The fourth transaction includes registration information corresponding to a second rollup mode to be registered.

As mentioned above, the second method function is used to support the registration Rollup mode.

Take the second rollup mode to be registered including TEE-Rollup as an example, as shown in Figure 5. The management member of the second blockchain system can initiate a fourth transaction in the first blockchain system, the fourth transaction is used to call the second method function in the Rollup Contract, and the fourth transaction can include the registration information corresponding to the TEE-Rollup. The registration information corresponding to the TEE-Rollup may include, but is not limited to, one or more of the following information: identification information, transaction sorting model, verification method, and genesis block; the transaction sorting model may include, but is not limited to, a consensus algorithm and an upper limit on the number of transactions for packaged transactions.

Step S603, the first blockchain system executes the second method function in the Rollup Contract according to the fourth transaction, to achieve: according to the registration information corresponding to the second rollup mode, perform a first upgrade operation on the Rollup Contract and the Bridge Contract, and generate a rollup registration event, which includes at least part of the registration information corresponding to the second rollup mode.

Take the second rollup mode to be registered including TEE-Rollup as an example, as shown in Figure 5. The first upgrade operation on the Rollup Contract may include but is not limited to adding or enabling the verification method TEE verifier corresponding to TEE-Rollup in the Rollup Contract. The first upgrade operation on the Bridge Contract may include but is not limited to reconfiguring the contract interface Deposite() and the contract interface Withdraw() in the Bridge Contract, so that the account registered in the first blockchain system can realize the second blockchain system by calling the contract interface Deposite(). For a sub-account belonging to TEE-Rollup in the second blockchain system, a corresponding share of the second target resource is added; and for a second target resource held by a sub-account belonging to TEE-Rollup in the second blockchain system, the contract interface Withdraw() can be called according to the corresponding strategy to realize the addition of a corresponding share of the first target resource under the account corresponding to the sub-account in the first blockchain system.

When the first blockchain system executes the second method function in the Rollup Contract according to the fourth transaction, it can also store the registration information corresponding to the second rolling mode in the Governance Contract, such as storing the registration information of the TEE-Rollup.

The aforementioned at least part of the registration information may include, for example, but is not limited to, identification information, a transaction sorting model, and a genesis block.

The repeater in the second blockchain system, such as the shared bridge Bridge included in the repeater, can monitor the roll-up registration event in the first blockchain system, and then use at least part of the registration information included in the roll-up registration event to perform a second upgrade operation on the infrastructure of the second blockchain system, so that the first blockchain system after the first upgrade operation and the second blockchain system after the second upgrade operation can achieve network roll-up through the newly registered second roll-up mode.

The aforementioned shared bridge can be an independent service or exist in the form of SDK. The Bridge can hold the relay account of the management member of the second blockchain system registered in the first blockchain system, and the private key corresponding to the relay account; then the Bridge uses the relay account to generate transactions and send them to the first blockchain system according to certain rules, and generates transactions and sends them to the sequencer in the second blockchain system according to certain rules.

Exemplarily, the second blockchain system may, for example, perform the following steps S605 and 607 based on the wrap-up registration event.

Step S605: The second blockchain system generates a first upgrade transaction through its repeater using the roll-up registration event, where the first upgrade transaction includes at least part of the registration information corresponding to the second roll-up mode.

The first upgrade transaction may be a special transaction, which may not be packaged into the packaged transaction submitted by the second blockchain system. Exemplarily, the Bridge included in the repeater may make special settings for the sender field and the receiver field of the first upgrade transaction, such as setting the From field to the relay account and the To field to Null, so that the Sequencer of the second blockchain system can accurately know that the first upgrade transaction is a special transaction, execute the transaction that the first upgrade transaction expects to execute and does not package it into the batch; the Data field of the first upgrade transaction may include at least part of the registration information included in the rollup registration event.

Step S607: The second blockchain system executes the first upgrade transaction through its Sequencer to implement: using at least part of the registration information corresponding to the second rollup mode to perform a second upgrade operation on the infrastructure of the second blockchain system.

Take the second rollup mode to be registered including TEE-Rollup as an example, as shown in Figure 5. The shared bridge of the second blockchain system can, for example, send a first upgrade transaction to the Sequencer, and the first upgrade transaction includes at least part of the registration information included in the registration information of TEE-Rollup. When the Sequencer of the second blockchain system executes the first upgrade transaction, the second upgrade operation performed on the infrastructure of the second blockchain system may include but is not limited to: configuring the transaction pool TEE Txpool corresponding to TEE-Rollup in the receiver; reconfiguring the Sequencer so that the reconfigured Sequencer can process transactions in TEE Txpool according to the identification information, transaction sorting model and genesis block of TEE-Rollup; and deploying the prover TEE Prover corresponding to TEE-Rollup in the second blockchain system.

The foregoing text, in combination with Figures 5 and 6, exemplarily describes the process of registering TEE-Rollup. However, it is not difficult to understand that other Rollup modes can also be registered through a process similar to the foregoing text, such as registering ZK-Rollup or other Rollup modes, so that the first blockchain system and the second blockchain system can simultaneously support M types of Rollup modes greater than 1.

As shown in FIG7 , when the second blockchain system supports M rollup modes greater than 1, the second blockchain system can maintain M account sets for the M Rollup modes, that is, any user, such as user 1, may have one or more accounts not greater than M in the second blockchain system. Correspondingly, the state trie corresponding to the world state of the second blockchain system may include M sub-state trees corresponding to the M Rollup modes, and the state root corresponding to the world state of the second blockchain system (i.e., Global state root) can be calculated using the state roots corresponding to each of the M sub-state trees.

Based on this, on the basis of the aforementioned steps S601 to S607, the Sequencer can also initialize the sub-state tree corresponding to the second reeling mode in the second blockchain system, including registering a relay sub-account belonging to the second reeling mode and corresponding to the relay account in the sub-state tree corresponding to the second reeling mode, for example, performing a derived calculation based on the relay account corresponding to the second blockchain system and the second reeling mode, obtaining the relay sub-account belonging to the second reeling mode and corresponding to the relay account, and registering it in the sub-state tree corresponding to the second reeling mode through the system contract System Contract in the second blockchain system.

The algorithm used to perform the derived calculation on the account (including the relay account) registered in the first blockchain system may be predetermined, and the embodiments of this specification do not limit the algorithm used to perform the derived calculation. In a typical example, for the relay account A registered in the first blockchain system, for example, the hash value corresponding to the relay account A and the identification information of the second cascading mode may be calculated, and the first x bits of the hash value may be used as the relay sub-account belonging to the second cascading mode and corresponding to the relay account.

As shown in Figure 7, when the first blockchain system includes a relay account corresponding to the second blockchain system registered by the management member of the second blockchain system, which is account A, if the M rolling modes supported by the second blockchain system include ZK-Rollup and TEE-Rollup, the sub-state tree corresponding to ZK-Rollup may include the relay sub-account ZK-AA corresponding to account A, and the sub-state tree corresponding to TEE-Rollup may include the relay sub-account TEE-AA corresponding to account A.

Similarly, in order to reduce the number of accounts that users need to maintain in the first blockchain system and the second blockchain system, thereby improving user experience, any user, such as user 1, in any Rollup mode in the second blockchain system, is used as a sub-account corresponding to a certain account registered by user 1 in the first blockchain system. Exemplarily, as shown in FIG. 7 , similar to the aforementioned relay sub-account ZK-AA and relay sub-account TEE-AA, both correspond to account A, and account ZK-A1 belonging to ZK-Rollup and account TEE-A1 belonging to TEE-Rollup both correspond to account A1 registered by user 1 in Layer1.

Any user, such as user 1, with an account ZK-A1 under ZK-Rollup can be derived from account A1 and the rollup mode ZK-Rollup; similarly, user 1's account TEE-A1 under TEE-Rollup can be derived from account A1 and the rollup mode TEE-Rollup. Alternatively, the second blockchain system can also construct and store the corresponding relationship between any user, such as user 1's account A1 in the first blockchain system and its account in any Rollup mode in the second blockchain system by directly maintaining a mapping relationship table.

Since there is a corresponding relationship between the account A1 registered by user 1 in the first blockchain system and each account of user 1 in the second blockchain system, such as account ZK-A1 and account TEE-A1, user 1 can reuse the account A1 registered in the first blockchain system. Account A1 in the blockchain system and the corresponding public-private key pair can be used to initiate corresponding transactions in the second blockchain system on demand. Correspondingly, the client of the second blockchain system does not need to present its account ZK-A1 under ZK-Rollup and its account TEE-A1 under TEE-Rollup to user 1. It only needs to present to user 1: the share of the first target resource held by user 1's account under ZK-Rollup and the share of the first target resource held by user 1's account under ZK-Rollup.

Exemplarily, as shown in Figure 8, the client of the second blockchain system can only present to user 1 the account A1 registered in the first blockchain system; when user 1 holds the second target resource under any Rollup mode such as ZK-Rollup and TEE-Rollup, the client of the second blockchain system can also present to user 1 the share of the second target resource held by his sub-account under ZK-Rollup (i.e., the ZK account balance), and can also present to user 1 the share of the second target resource held by his sub-account under TEE-Rollup (i.e., the TEE account balance), but does not present to him the accounts ZK-A1 and TEE-A1.

When user 1 expects to initiate a transaction Tx in the second blockchain system to achieve a certain business purpose, he can use account A1 registered in the first blockchain system to initiate transaction Tx. Taking the case where user 1 needs to transfer the second target resource held by user 2 to user 2, the From field and To field in the transaction Tx can respectively include account A1 and account A2 registered by user 1 and user 2 in the first blockchain system; in addition, the transaction Tx can also include an indication field (denoted as FR) corresponding to the From field and an indication field (denoted as TR) corresponding to the To field. Among them: the field value under the FR field is used to indicate the Rollup mode to which the sub-account corresponding to account A1 and which needs to transfer out the second target resource through transaction Tx belongs; the field value under the TR field is used to indicate the Rollup mode to which the sub-account corresponding to account A2 and which needs to transfer in the second target resource through transaction Tx belongs.

Given that each of the M Rollup modes of user 1 in the second blockchain system corresponds to account A1 registered with the user in the first blockchain system, and each of the M Rollup modes of user 2 in the second blockchain system corresponds to account A2 registered with the user in the first blockchain system, the second blockchain system can learn, based on transaction Tx, the subaccounts that actually need to transfer out the second target resources and the subaccounts that actually need to transfer into the second target resources in the transaction Tx, thereby completing the resource transfer transaction that the transaction Tx expects to complete by executing the transaction Tx.

Figure 9 is a second flow chart of a resource management method for a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of adding a second target resource to a sub-account in the second blockchain system by any first user through the first account registered in the first blockchain system when the second blockchain system supports M types of cascading modes.

As shown in FIG. 9 , the method may include but is not limited to the following steps S901 to S907 .

In step S901, the first blockchain system receives a first transaction initiated by a first account, where the first transaction is used to call the Bridge Contract deployed by the first blockchain system. The first transaction indicates N types of cascading modes among the M types of cascading modes supported by the second blockchain system, and resource distribution shares corresponding to each of the N types of cascading modes.

The first user may initiate a first transaction through a first account registered in the first blockchain system.

The From field of the first transaction may include the first account, the To field may include the contract account corresponding to the Bridge Contract, and the Data field may include N rollup modes among the M rollup modes supported by the second blockchain system, and the resource distribution shares corresponding to each of the N rollup modes. In addition, the Data field of the first transaction may also include the identification information of the second blockchain system, and the identification information of the method function/contract interface in the Bridge Contract that the first transaction expects to call, such as the identification information of the contract interface Deposite() in the Bridge Contract.

Step S903, the first blockchain system executes the Bridge Contract according to the first transaction to achieve: transferring the first target resource to the relay account according to the resource distribution shares corresponding to the N folding modes, and generating a resource distribution event, wherein the resource distribution event includes the first account, N folding modes and their corresponding resource distribution shares.

The first blockchain system can, for example, execute Deposite() in Bridge Contract according to the first transaction to generate a resource distribution event. In a possible implementation, the resource distribution event can also include identification information of the second blockchain system.

In order to ensure the reliability of resource transfer, the management member of the second blockchain system can register a relay account corresponding to the second blockchain system, such as account A, in the first blockchain system.

Bridge Contract can also distribute events to storage resources through corresponding asset transfer event lists or other methods.

The repeater in the second blockchain system, such as the shared bridge Bridge included in the repeater, can monitor the resource distribution event generated by the first blockchain system, and execute the following step S905 based on the monitored resource distribution event.

To ensure security, the Bridge included in the repeater of the second blockchain system can also query the simplified payment verification (SPV) certificate corresponding to the resource distribution event from the first blockchain system, and only execute the following step S905 after determining through the SPV certificate that the block to which the first transaction belongs has been successfully submitted in the first blockchain system.

Step S905: The second blockchain system generates N sub-transactions according to the resource distribution event, and any i-th sub-transaction includes the first account, the i-th folding mode among the N folding modes, and its corresponding resource distribution share.

In the i-th sub-transaction, the From field may include the relay account, the To field may include the first account, the Data field may include the resource distribution share corresponding to the i-th rollup mode, and the Rollup mode included in the FR field corresponding to the From field and the TR field corresponding to the To field are both the i-th rollup mode. As shown in FIG7 , it is assumed that the N rollup modes include TEE-Rollup and ZK-Rollup, then Bridge can generate TEE sub-transactions and ZK sub-transactions based on resource distribution events: in the ZK sub-transaction, the FR field corresponding to the From field and the TR field corresponding to the To field include the rollup mode of ZK-Rollup; and in the TEE sub-transaction, the FR field corresponding to the From field and the TR field corresponding to the To field include the rollup mode of TEE-Rollup.

Step S907, the second blockchain system executes the i-th sub-transaction to achieve: determining the i-th first sub-account that belongs to the i-th cascading mode and corresponds to the first account, and transferring the second target resource to the i-th first sub-account from the relay sub-account that belongs to the i-th cascading mode and corresponds to the relay account according to the resource distribution share corresponding to the i-th cascading mode.

The second blockchain system can execute the ith sub-transaction through its Sequencer. In combination with the foregoing, it can be understood that when the Sequencer executes the ith sub-transaction: in one possible implementation, the first account included in the ith sub-transaction and the ith folding mode can be used to perform a derivative calculation to obtain the ith first sub-account; in another possible implementation, the ith first sub-account can be obtained by querying the mapping relationship table maintained in the second blockchain system.

After the Sequencer obtains the ith first sub-account, it can query the ith first sub-account in the sub-state tree corresponding to the ith roll-up mode. If the ith first sub-account cannot be queried from the sub-state tree corresponding to the ith roll-up mode, the ith first sub-account can be registered in the corresponding sub-state tree by calling the system contract of the second blockchain system.

As shown in FIG. 7 , it is assumed that the first account includes account A2, and the N types of Rollup modes include TEE-Rollup and ZK-Rollup.

If the Sequencer fails to find the sub-account ZK-A2 corresponding to account A2 from the sub-state tree corresponding to ZK-Rollup during the execution of the ZK sub-transaction, the Sequencer can call the System Contract of the second blockchain system to register the sub-account ZK-A2 in the sub-state tree corresponding to ZK-Rollup; if the Sequencer fails to find the sub-account TEE-A2 corresponding to account A2 from the sub-state tree corresponding to TEE-Rollup during the execution of the TEE sub-transaction, the Sequencer can call the System Contract of the second blockchain system to register the sub-account TEE-A2 in the sub-state tree corresponding to TEE-Rollup.

When the number of sub-states corresponding to the i-th cascading mode already includes the i-th first sub-account, the Sequencer of the second blockchain system can transfer the second target resource to the i-th first sub-account from the relay sub-account belonging to the i-th cascading mode and corresponding to the relay account based on the resource distribution share included in the i-th sub-transaction.

Continuing with the previous example, referring to Figure 7, the Sequencer can, for example, transfer the second target resource from ZK-AA to the sub-account ZK-A2 according to the resource distribution share included in the ZK sub-transaction, and transfer the second target resource from TEE-AA to the sub-account ZK-A2 according to the resource distribution share included in the TEE sub-transaction.

Alternatively, the second target resource may be deposited into the i-th first sub-account by other methods other than the aforementioned step 907. Exemplarily, when the second blockchain system executes the i-th sub-transaction, it may be implemented as follows: determining the i-th first sub-account that belongs to the i-th folding mode and corresponds to the first account, and casting the second target resource for the i-th first sub-account according to the resource distribution share corresponding to the i-th folding mode. That is, under this implementation, it is not necessary to transfer the second target resource from the relay sub-account that belongs to the i-th folding mode and corresponds to the relay account, but to cast the corresponding share of the second target resource for the i-th first sub-account.

Taking into account the possibility that the i-th sub-transaction may fail to execute, after the batch to which the i-th sub-transaction belongs is successfully submitted to the first blockchain system, for example, the proof data corresponding to the batch to which the i-th sub-transaction belongs is submitted to the first blockchain system and passed the verification, so that the i-th sub-transaction and the batch to which it belongs enter an unchangeable state, the Rollup Contract in the first blockchain system can perceive that the i-th sub-transaction has entered an unchangeable state. At this time, the Rollup Contract can also generate the i-th asset transfer completion event corresponding to the i-th sub-transaction by calling the Bridge Contract. The asset transfer completion event may include, for example, the first account, the i-th rollup mode and its corresponding resource distribution share; further, when the Bridge Contract collects N asset transfer completion events corresponding to N sub-exchanges, the Bridge Contract can confirm that the N asset transfer completion events are successfully matched with the aforementioned resource distribution events based on the contents included in the N asset transfer completion events and the aforementioned resource distribution events, thereby confirming that all the transactions expected to be executed by the first transaction have been successfully executed.

Correspondingly, if Bridge Contract fails to completely collect N asset transfer completion events corresponding to N sub-exchanges, it means that some or all of the sub-transactions have not been successfully executed in the second blockchain system. In this case, the management members of Bridge Contract can, for example, determine the compensation share of the first target resource that needs to be returned from the relay account to the first account based on the resource distribution event and the collected asset transfer completion events, and thus transfer the first target resource from the relay account to the first account based on the compensation share through the corresponding contract call transaction or other methods.

Figure 10 is a flowchart of a resource management method for a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of adding a corresponding share of the first target resource to the first account registered by the first user in the first blockchain system according to the second target resource held by the sub-account belonging to any first roll-up mode in the second blockchain system when the second blockchain system supports M roll-up modes.

As shown in FIG. 10 , the method may include but is not limited to the following steps S1001 to S1007 .

Step S1001: The second blockchain system receives a second transaction initiated by a first account, wherein the second transaction indicates a resource transfer share and a first roll-up mode. The first roll-up mode belongs to the M roll-up modes supported by the second blockchain system.

Combined with the data format of the transaction Tx initiated by the user in the second blockchain system described in the above example. The From field of the second transaction may include the first account, and the folding mode included in the FR field corresponding to the From field may be the first folding mode; the Data field of the second transaction may include the resource transfer share. In addition, the To field of the second transaction and its corresponding TR field may be set according to preset rules, for example: both the To field and the TR field are Null; or the To field and the From field include the same first account, and the TR field and the FR field include the same first folding mode.

After receiving the second transaction, the receiver of the second blockchain system can add the second transaction to the transaction pool corresponding to the first concatenation mode according to the first concatenation mode included in the FR field corresponding to the sender field in the second transaction.

Step S1003, the second blockchain system executes the second transaction to achieve: determining a second sub-account that belongs to the first cascading mode and corresponds to the first account, and transferring the second target resource from the second sub-account to a relay sub-account that belongs to the first cascading mode and corresponds to the relay account according to the resource transfer share.

The Sequencer of the second blockchain system can pull multiple transactions from the transaction pool corresponding to the first roll-up mode, sort them, execute them, and generate corresponding packaged transactions. In combination with the foregoing, it can be understood that when the Sequencer executes the second transaction: in one possible implementation, the first account and the first roll-up mode included in the second transaction can be used to perform a derivative calculation to obtain a second sub-account belonging to the first roll-up mode and corresponding to the first account; in another possible implementation, the second sub-account can be obtained by querying the mapping relationship table maintained in the second blockchain system.

It should be noted that when the Sequencer executes the second transaction, it can trigger the second blockchain system to generate a third transaction corresponding to the second transaction based on the special structure of the second transaction, for example: both the To field and the TR field are Null, or the To field and the From field include the same first account, and the TR field and the FR field include the same first folding mode. For example, when the Sequencer executes the second transaction, it can generate a resource extraction event based on the aforementioned special structure, which includes the first account and the resource transfer share, and can also include the batch number of the third batch to which the second transaction belongs in the second blockchain system; the Bridge of the second blockchain system can, for example, generate a third transaction based on the resource extraction event.

Correspondingly, in step S1005, the second blockchain system sends a third transaction to the first blockchain system, where the third transaction is used to call the first method function in the Rollup Contract, and the third transaction includes the first account and resource transfer share.

In order to ensure that the first blockchain system can determine whether the second transaction corresponding to the third transaction is successfully executed, the third transaction may also include the batch number of the third batch to which the second transaction belongs, and the third transaction may also include the transaction number of the second transaction in the third batch. Moreover, the Bridge of the second blockchain system may send the third transaction to the first blockchain system only after the Replayer has completed submitting the proof data corresponding to the third batch to the first blockchain system.

Correspondingly, in step S1007, the first blockchain system executes the first method function in the Rollup Contract according to the third transaction to achieve: transferring the first target resource from the relay account to the first account according to the resource transfer share; source.

When the third transaction includes the aforementioned batch number and transaction number, when the first blockchain system executes the first method function in the Rollup Contract according to the third transaction, it can be specifically implemented as follows: first, according to the batch number of the third batch included in the third transaction, determine whether the third batch has entered an unchangeable state; if so, query whether the third batch includes the second transaction corresponding to the third transaction according to the transaction number included in the third transaction; if so, transfer the first target resource from the relay account to the first account according to the resource transfer-out share. It can be understood that the second transaction and the third transaction match means that the second transaction and the third transaction both include the same first account and resource transfer-out share.

When the first blockchain system executes the third transaction, the third batch to which the second transaction belongs may not have entered an unchangeable state. In this case, when the first blockchain system executes the first method function in the Rollup Contract according to the third transaction, the trigger condition can be set in the Rollup Contract according to the batch number of the third batch to which the second transaction belongs and the transaction number of the second transaction in the third batch; when the second blockchain system completes submitting the proof data of the third batch to which the second transaction belongs to the Rollup Contract, and the proof data passes the verification and causes the third batch to which the second transaction belongs to enter an unchangeable state, the trigger condition set in the Rollup Contract is satisfied, thereby triggering the corresponding first method function to continue to query whether the third batch includes the second transaction corresponding to the third transaction according to the transaction number included in the third transaction, and if so, the first target resource is transferred from the relay account to the first account according to the resource transfer-out share.

In one possible implementation, when it is necessary to transfer the first target resource from the relay account to the first account, the first method function in the Rollup Contract can call the contract interface Withdraw() in the Bridge Contract, thereby completing the transfer of the first target resource from the relay account to the first account according to the resource transfer share through the contract interface Withdraw().

Figure 11 is a fourth flow chart of a resource method of a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of terminating the roll-up mode (referred to as the second roll-up mode) in the first blockchain system and the second blockchain system.

11 , the method may include but is not limited to the following steps S1101 to S1107 .

Step S1101, the first blockchain system receives the fifth transaction, the fifth transaction is used to call the third method function in the Rollup Contract, and the fifth transaction requests to terminate the second rollup mode.

The management member of the second blockchain system can initiate a fifth transaction in the first blockchain system, and the fifth transaction is used to call the third method function in the Rollup Contract, which can indicate that the second rollup mode needs to be terminated.

Step S1103: the first blockchain system executes the third method function according to the fifth transaction to achieve: generating a roll-up termination event, and performing a third upgrade operation on the roll-up contract and the relay contract according to the registration information of the second roll-up mode.

The third upgrading operation corresponds to the aforementioned first upgrading operation.

Take the case where the second rollup mode to be terminated includes TEE-Rollup. The third upgrade operation on the Rollup Contract may include, but is not limited to, deleting or disabling the verification method TEE verifier corresponding to TEE-Rollup in the Rollup Contract. The third upgrade operation on the Bridge Contract may include, but is not limited to, reconfiguring the contract interface Deposite() and the contract interface Withdraw() in the Bridge Contract, so that the account registered in the first blockchain system can no longer call the contract interface Deposite() to increase the corresponding share of the second target resource for a sub-account belonging to TEE-Rollup in the second blockchain system; and making the second blockchain system A sub-account belonging to TEE-Rollup in the system can no longer add the first target resource to the account corresponding to the sub-account in the first blockchain system through the contract interface Withdraw() based on its share of the second target resource.

The scroll termination event may indicate the second scroll mode to be terminated, for example, including identification information of the second scroll mode.

The repeater in the second blockchain system, such as the Bridge included in the repeater, can monitor the roll-up termination event, and then perform a fourth upgrade operation on the infrastructure of the second blockchain system according to the third roll-up mode indicated by the roll-up termination event, so that the first blockchain system after the third upgrade operation and the second blockchain system after the fourth upgrade operation no longer support the roll-up using the second roll-up mode.

Exemplarily, the second blockchain system may, for example, perform the following steps S1105 and 1107 based on the wrap-up registration event.

Step 1105: The second blockchain system generates a second upgrade transaction through its repeater using the roll-up termination event, and the second upgrade transaction indicates the second roll-up mode to be terminated.

The second upgrade transaction may be a special transaction, which may not be packaged into the packaged transaction submitted by the second blockchain system. Exemplarily, the Bridge included in the repeater may make special settings for the sender field and the receiver field of the first upgrade transaction, such as setting the From field to the relay account and the To field to Null, so that the Sequencer of the second blockchain system can accurately know that the second upgrade transaction is a special transaction, execute the transaction that it expects to execute in the second upgrade transaction and do not package it into the batch; the Data field of the second upgrade transaction may include identification information of the second folding mode.

Step S1007: The second blockchain system executes a second upgrade transaction through its Sequencer to implement: performing a fourth upgrade operation on the infrastructure of the second blockchain system according to the identification information of the second roll-up mode.

Take the second rollup mode to be terminated including TEE-Rollup as an example. The shared bridge of the second blockchain system, for example, can send a second upgrade transaction to the Sequencer, and the second upgrade transaction includes the identification information of TEE-Rollup. When the Sequencer of the second blockchain system executes the second upgrade transaction, the fourth upgrade operation performed on the infrastructure of the second blockchain system may include but is not limited to: deleting or disabling the transaction pool TEE Txpool corresponding to TEE-Rollup in the receiver; reconfiguring the Sequencer so that the reconfigured Sequencer no longer processes transactions in TEE Txpool; and deleting the prover TEE Prover corresponding to the disabled TEE-Rollup in the second blockchain system.

In a possible implementation, depending on the roll-up termination event corresponding to the second roll-up mode, the second blockchain system may further execute steps S1109 and S1111 to complete the transfer of the second target resource held by the first target sub-account belonging to the second roll-up mode and corresponding to any account (recorded as the target account) to the second target sub-account belonging to the third roll-up mode and corresponding to the target account, where the target account refers to an external account registered in the first blockchain system.

Step S1109: The second blockchain system generates a sixth transaction through its repeater according to the wrap-up termination event.

The second upgrade transaction may be a special transaction, which may not be packaged into the packaged transaction submitted by the second blockchain system. Exemplarily, the Bridge included in the repeater can make special settings for the sender field and the receiver field of the sixth transaction, such as setting both the From field and the To field to Null, and setting the FR field corresponding to the From field and the TR field corresponding to the To field to the second folding mode, so that the Sequencer of the second blockchain system can accurately know that the sixth transaction is a special transaction, execute the sixth transaction, and not execute the transaction it expects to execute. Package it into batch.

In step S1111, the second blockchain system executes the sixth transaction through its Sequencer to achieve: for any first target sub-account belonging to the second cascading mode, the second target resource held by it is transferred to the second target sub-account belonging to the third cascading mode, and the first target sub-account and the second target sub-account correspond to the same target account registered in the first blockchain system.

Referring to FIG. 7 , continuing with the previous example, assuming that the terminated second rollup mode is TEE-Rollup, and assuming that the third rollup mode includes ZK-Rollup, then the second target resource held by account TEE-A1 can be transferred to account ZK-A1, and the second target resource held by account TEE-A2 can be transferred to account ZK-A2.

When the second rollup mode is terminated, the target resource held by any first target sub-account belonging to the second rollup mode can be transferred by other methods other than the aforementioned step S1109 and step 1111. For example, the Bridge included in the repeater of the second blockchain system can generate a target transaction, and the target transaction is used to call a preset method function in the Rollup Contract deployed by the first blockchain system. When the first blockchain system executes the preset function according to the target transaction, for any first target sub-account belonging to the second rollup mode, according to the current share of the second target resource held by it, the first target resource is transferred from the relay account corresponding to the second blockchain system to the target account registered in the first blockchain system.

Figure 12 is a flowchart of a resource management method for a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of transferring resources from a first sub-account belonging to a first cascading mode and corresponding to a first account to a second sub-account belonging to a second cascading mode and corresponding to a second account in a second blockchain system supporting the M-folding mode.

First, in step S1201, the second blockchain system receives the seventh transaction, the sender field and the receiver field of the seventh transaction include the first account and the second account respectively, and the seventh transaction also includes a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field.

The following mainly describes by example that the first rolling mode includes ZK-Rollup, the second rolling mode includes TEE-Rollup, the first account includes account A1, the second account includes account A2, the relay account includes account A, and the resource transfer share is T.

The seventh transaction may be initiated by user 1 holding account A1 through the client of the second blockchain system.

Based on the previous examples, for the seventh transaction: the From field (i.e., the sender field) may include account A1, the To field (i.e., the receiver field) may include account A2, the FR field corresponding to the From field may include ZK-Rollup, the TR field corresponding to the To field may include TEE-Rollup, and the Data field may include the resource transfer share T.

The second blockchain system can not only receive transactions from its client, but it can also initiate transactions that need to be executed by the second blockchain system through the shared bridge Bridge included in the repeater. For example, Bridge may initiate the aforementioned ZK sub-transaction and TEE sub-transaction, etc. For transactions that need to be executed by the second blockchain system, the transaction can be added to the corresponding transaction pool according to the field value under the FR field corresponding to the From field in the transaction. For example, for the seventh transaction, the field value under the FR field corresponding to the From field is ZK-Rollup, which can be added to the corresponding ZK Txpool.

The M types of convolution modes in the second blockchain system can share a batch chain, which includes multiple batches connected in sequence. For multiple transactions belonging to the same batch, the convolution modes included in the FR field are Need to remain the same. In addition to the conventional Prev Hash, Nonce, Batch Num (batch number), Tx_Root, State_Root, and Receipt_Root information, the batch header of any batch can also include the Rollup mode corresponding to the batch. As shown in Figure 13, if the batch header of batch 1 includes ZK-Rollup, it means that for the multiple transactions included in batch 1, the FR field corresponding to the From field is all ZK-Rollup; if the batch header of batch 2 includes TEE-Rollup, it means that for the multiple transactions included in batch 2, the FR field corresponding to the From field is all TEE-Rollup.

It should be noted that when M kinds of convolution modes share a batch chain, the State_Root in the batch header is the state root of the entire world state of the second blockchain system calculated based on the state roots corresponding to each of the M convolution modes, that is, the Global state root, rather than the state root of the sub-state tree corresponding to a certain convolution mode. Correspondingly, the previous state root and the subsequent state described below correspond to the Global state root rather than the state root of a sub-state tree.

Because the M convolution modes share the same batch chain, when the Sequencer of the second blockchain system starts to execute transactions related to the next transaction batch, it needs to first determine the convolution mode corresponding to the next transaction batch to be packaged.

Accordingly, the second blockchain system may execute the following step S1203, determine the target stacking mode corresponding to the next batch to be packaged, and when the target stacking mode is the first stacking mode, pull multiple transactions from the transaction pool corresponding to the first stacking mode, sort and package the multiple transactions, and the multiple transactions include the seventh transaction.

The Sequencer of the second blockchain system may determine the target rollup mode corresponding to the next batch to be packaged according to at least one of the following information: the batch submission time interval corresponding to each of the M rollup modes, the reference number of transactions required to be included in the batch corresponding to each of the M rollup modes, and the number of transactions cached in each of the M transaction pools. For example, the Sequencer may count the number of transactions included in each of the M transaction pools at the current moment, and determine the rollup mode corresponding to the transaction pool with the largest number of transactions as the target rollup mode; for another example, when the number of transactions in the transaction pool is not less than the corresponding reference number, the rollup mode corresponding to the transaction pool is used as a candidate rollup mode, and then the target rollup mode is determined from several candidate rollup modes according to the batch submission time interval and/or the number of transactions in the transaction pool.

The following description takes the seventh transaction being packaged into batch k (i.e., the first batch) as an example.

If the Sequencer determines that the target rollup mode corresponding to the next batch to be packaged (batch k) is ZK-Rollup, the Sequencer may pull multiple transactions from the ZK Txpool for sorting and packaging, and execute the multiple transactions packaged into batch k in the order of the sorting results according to the world state corresponding to the previous batch of batch k.

When multiple transactions in batch k include the seventh transaction, the second blockchain system will execute step S1205.

Step S1205, executing the seventh transaction, to achieve: according to the resource transfer share, transferring the second target resource from the first sub-account belonging to the first cascading mode and corresponding to the first account to the first relay sub-account belonging to the first cascading mode and corresponding to the relay account, and generating a cross-mode transfer event.

During the process of executing the seventh transaction, the Sequencer may first determine the first sub-account that belongs to the first folding mode and corresponds to the first account, and determine the first relay sub-account that belongs to the first folding mode and corresponds to the relay account according to the pre-configured relay account. The first sub-account and the first relay sub-account are determined by calculation or mapping relationship table, which will not be described in detail here.

During the process of the Sequencer executing the seventh transaction, for example, after determining that the first sub-account belonging to ZK-Rollup and corresponding to account A1 is account ZK-A1, and determining that the first relay sub-account belonging to ZK-Rollup and corresponding to account A is account ZK-AA, the second target resource can be transferred from account ZK-A1 to account ZK-AA according to the resource transfer share T.

In the aforementioned cross-mode transfer event, the Data field may include but is not limited to: the second account under the To field in the seventh transaction, the second rollup mode under the TR field corresponding to the To field, and the resource transfer share under the Data field.

After the Sequencer completes the execution of multiple transactions belonging to batch k, the shared bridge Bridge included in the repeater of the second blockchain system can monitor the cross-mode transfer event, and then can continue to execute the following step S1207.

Step S1207: Generate an eighth transaction according to the cross-mode transfer event. The sender field and the receiver field of the eighth transaction include the relay account and the second account respectively. The eighth transaction also includes a resource transfer share and a second roll-up mode.

Continuing with the previous example. In the eighth transaction: the From field may include account A, the To field may include account A2, the FR field corresponding to the From field may include TEE-Rollup, the TR field corresponding to the To field may include TEE-Rollup, and the Data field may include resource transfer shares. Accordingly, since the field value under the FR field corresponding to the From field in the eighth transaction is TEE-Rollup, the eighth transaction will be added to the corresponding TEE Txpool.

After the Sequencer completes the execution of multiple transactions belonging to batch k, referring to the previous text, the Sequencer can obtain the pre-state root (Pre State Root), post-state root (Post State Root), batch number k, and the transaction sequence composed of the multiple transactions corresponding to batch k. It should be noted that the Pre State Root here refers to the state root (i.e., Global state root) corresponding to the world state of the second blockchain system before the multiple transactions in batch k are executed; Post State Root refers to the state root corresponding to the world state of the second blockchain system after the multiple transactions in batch k are executed.

Correspondingly, the second blockchain system may further execute step S1209 to send a ninth transaction to the first blockchain system, where the ninth transaction is used to call the fourth method function in the Rollup Contract deployed by the first blockchain system, and the ninth transaction includes the rolled-up data of the first batch to which the seventh transaction belongs.

The fourth method function in the Rollup Contract is, for example, the commitBatch() contract interface mentioned above.

Correspondingly, the first blockchain system can execute step S1211, execute the fourth method function in the Rollup Contract according to the ninth transaction, and process the rolled data of the first batch belonging to the seventh transaction.

Looking back to the previous text, the convoluted data of the first batch, batch k, may include: pre-state root, post-state root, batch number k, transaction sequence consisting of multiple transactions belonging to batch k, etc. The process of processing the convoluted data of batch k may include: verifying whether the Pre State Root in the ninth transaction is equal to the Current State Root in the Rollup Contract contract storage, if they are equal, storing the transaction sequence in the ninth transaction in calldata, and updating the Current State Root in the contract storage to Post State Root; and setting the position index of the transaction sequence in calldata according to the batch number k.

Back to the second blockchain system, after the second blockchain system completes submitting the first batch, i.e., batch k, through the aforementioned step S1209, similar to the aforementioned step S1203, the Sequencer needs to determine the target convolution mode corresponding to the next batch to be packaged.

Correspondingly, the second blockchain system may execute step S1213, determine the target stacking mode corresponding to the next batch to be packaged, and when the target stacking mode is the second stacking mode, pull multiple transactions from the transaction pool corresponding to the second stacking mode, sort and package the multiple transactions, and the multiple transactions include the eighth transaction.

The target convolution mode corresponding to the next batch of batch k, i.e., batch k+1, may not be the second convolution mode. Even if the target convolution mode corresponding to batch k+1 is the same, the eighth transaction may not be packaged into batch k+1 because the number of transactions in the transaction pool corresponding to the second convolution mode is large. Therefore, the batch to which the eighth transaction actually belongs may not be batch k+1, and it may actually be packaged into a second batch whose batch number is greater than k. However, in the embodiments of this specification, for the convenience of description, the second batch will still be described as batch k+1 for example.

After the eighth transaction is packaged into the second batch, for example, batch k+1, by the Sequencer, the second blockchain system may then execute the following step S1215 to execute the eighth transaction, thereby realizing: according to the resource transfer share, the second target resource is transferred from the second relay sub-account belonging to the second cascading mode and corresponding to the relay account to the second sub-account belonging to the second cascading mode and corresponding to the second account.

During the process of executing the eighth transaction, the Sequencer may first determine the second sub-account that belongs to the second folding mode and corresponds to the second account, and the second relay sub-account that belongs to the second folding mode and corresponds to the relay account. The manner in which the Sequencer determines the second sub-account and the second relay sub-account is the same as the manner in which the first sub-account and the first relay sub-account are determined, such as the derivative calculation or mapping relationship table described above, which will not be described in detail here.

During the process of Sequencer executing the eighth transaction, for example, after determining that the second subaccount belonging to TEE-Rollup and corresponding to account A2 is account TEE-A2, and determining that the second relay subaccount belonging to TEE-Rollup and corresponding to account A is account TEE-AA, the second target resource can be transferred from account TEE-AA to account TEE-A2 according to the resource transfer share.

After the sequencer completes the execution of multiple transactions belonging to the second batch, such as batch k+1, the sequencer can obtain the previous state root, the next state root, the batch number k+1, the transaction sequence composed of the multiple transactions, and other concatenated data corresponding to batch k+1. Similar to batch k, the previous state root here refers to the state root corresponding to the world state of the second blockchain system before the multiple transactions in batch k+1 are executed; the next state root refers to the state root corresponding to the world state of the second blockchain system after the multiple transactions in batch k+1 are executed. Then, the following step S1217 is executed to complete the submission of the second batch.

Step S1217: The second blockchain system sends an eleventh transaction to the first blockchain system. The eleventh transaction is used to call the fourth method function in the RollupContract deployed by the first blockchain system. The eleventh transaction includes the rolled-up data of the second batch to which the eighth transaction belongs.

Correspondingly, the first blockchain system can execute step S1219, execute the fourth method function in the Rollup Contract according to the eleventh transaction, and process the rolled data of the second batch belonging to the eighth transaction.

The process of processing the warped data of the second batch is similar to the process of processing the warped data of the first batch, and will not be described in detail.

In the above method embodiment, since the M types of concatenation modes correspond to the same batch chain formed by sequentially connecting multiple batches, the batch submitted later is bound through the state root of the world state. If the batch submitted earlier and at a relatively earlier position is rolled back for some reason, the batch submitted later and at a relatively later position must be rolled back. Therefore, there is no need to You need to wait until the previously submitted batch has entered an unchangeable state before submitting a new batch in the batch chain.

Correspondingly, after the first batch to which the seventh transaction belongs is submitted to the first blockchain system through the ninth transaction, the second blockchain system can continue to execute the eighth transaction corresponding to the seventh transaction in a second batch located after the first batch without waiting for the first batch to enter an unchangeable state, thereby completing the resource transfer transaction that the seventh transaction expects to complete, which is conducive to quickly completing the transfer in the second blockchain system as expected by the user.

However, referring to the ZK-Rollup mechanism and TEE-Rollup mechanism described in the previous example, after the second blockchain system completes submitting the corresponding batch to the first blockchain system, it also needs to submit the proof data corresponding to the batch to the first blockchain system. In addition, the following situation may also occur: after the first batch to which the seventh transaction belongs has entered an unchangeable state, the eighth transaction fails to be successfully executed for some reason, or even fails to successfully generate the eighth transaction corresponding to the seventh transaction for some reason. In this case, the resource transfer transaction expected to be completed by the seventh transaction may not be completed accurately.

In view of this, on the basis of the aforementioned steps S1201 to S1219, the first blockchain system and the second blockchain system may also jointly execute the following method steps S1221 to S1227.

In step S1221, the second blockchain system sends the tenth transaction to the first blockchain system through the first prover corresponding to the first rollup mode. The tenth transaction is used to call the fifth method function in the Rollup Contract deployed by the first blockchain system. The tenth transaction includes the first proof data corresponding to the first rollup mode and the first batch.

The data structure of the first proof data can be found in the previous description of the Rollup mechanism and will not be repeated here.

Step S1223, the first blockchain system executes the fifth method function according to the tenth transaction, to achieve: according to the verification method corresponding to the first roll-up mode, using the first proof data to verify whether the multiple transactions in the first batch are executed correctly, and generating an asset transfer event corresponding to the seventh transaction if the verification passes.

When the first rollup mode includes the ZK-Rollup mode, the fifth method function in the Rollup Contract can, for example, call the verification method ZK verifier corresponding to the ZK-Rollup in the contract according to the ZK-Rollup included in the tenth transaction, and process the first proof data included in the tenth transaction through the ZK verifier to complete the verification of whether the multiple transactions in the first batch are correctly executed. If the verification is passed, the first batch enters an unchangeable state; in addition, the fifth method function itself or by calling the Bridge Contract in the contract can realize the generation of asset pending transfer events for transactions in certain specific data formats, and the generation of asset transfer completion events for transactions in certain specific data formats.

In an exemplary rule, if the account under the From field in a transaction is not a relay account, and the FR field and the TR field have different wrapping modes, an asset pending transfer event can be generated for the transaction; if the account under the From field in a transaction is a relay account, an asset transfer completion event can be generated for the transaction. Based on this exemplary rule and the data structure of the seventh transaction, it is not difficult to understand that an asset pending transfer event can be generated for the seventh transaction.

The Bridge Contract can also maintain a collection of events that are allowed to be consumed. For asset transfer events, the fifth method function can be used to call the contract, or the Bridge Contract can enable the corresponding event monitoring mechanism to finally add the asset transfer event to the event collection maintained in the Bridge Contract.

In a typical example, as shown in Figure 14, for an asset pending transfer event corresponding to a transaction, the Topic field uses the field value E1 to indicate that the event belongs to an asset pending transfer event. In addition, the Data field of the asset pending transfer event may include: a subfield From, which is used to store the account under the From field of the corresponding transaction; a subfield To, which is used to store the account under the To field of the corresponding transaction; a subfield FR, which is used to store the FR field of the corresponding transaction. The subfield TR is used to store the folding mode under the TR field in the corresponding transaction; and the subfield FE is used to store the resource transfer share included in the Data field in the corresponding transaction.

As shown in FIG14 , for an asset transfer completion event corresponding to a transaction, the Topic field uses the field value E2 to indicate that the event belongs to an asset transfer completion event. In addition, the Data field of the asset transfer completion event may include: a subfield To, which is used to store the account under the To field in the corresponding transaction; a subfield TR, which is used to store the rollover mode under the TR field in the corresponding transaction; and a subfield FE, which is used to store the resource transfer share included in the Data field in the corresponding transaction.

The asset transfer completion event is used to support Bridge Contract to match it with the asset pending transfer event in the event set, so as to confirm the asset transfer transaction that the transaction corresponding to the asset pending transfer event has completed. For example, please continue to refer to the asset transfer completion event and the asset pending transfer event shown in Figure 14. If the Data fields of the two events are matched and it is found that the subfields included in their respective Data fields are: the accounts under the subfield To field are the same, the folding mode under the subfield TR field is the same, and the resource transfer shares included under the FE field are the same, then the match is successful.

Step S1225: The second blockchain system sends the twelfth transaction to the first blockchain system through the second prover corresponding to the second rolling mode. The twelfth transaction is used to call the fifth method function in the Rollup Contract deployed by the first blockchain system. The twelfth transaction includes the second proof data corresponding to the second rolling mode and the second batch.

The data structure of the second proof data can be found in the previous description of the Rollup mechanism and will not be repeated here.

Step S1227, the first blockchain system executes the fifth method function according to the twelfth transaction, to achieve: according to the verification method corresponding to the second roll-up mode, using the first proof data to verify whether the multiple transactions in the first batch are executed correctly, and generating an asset transfer completion event corresponding to the eighth transaction if the verification passes.

When the second rollup mode includes the TEE-Rollup mode, the fifth method function in the Rollup Contract can, for example, call the verification method TEE verifier corresponding to the TEE-Rollup in the contract according to the TEE-Rollup included in the twelfth transaction, and process the second proof data included in the twelfth transaction through the TEE verifier to complete the verification of whether the multiple transactions in the second batch are correctly executed. If the verification is passed, the second batch enters an unchangeable state; at the same time, the fifth method function itself, or by calling the Bridge Contract in the contract, generates asset pending transfer events for transactions in certain specific data formats, and generates asset transfer completion events for transactions in certain specific data formats.

Referring to the content under the aforementioned step S1223, the asset transfer completion event generated for the eighth transaction can be used to consume the asset pending transfer event corresponding to the seventh transaction in the event set maintained by Bridge Contrac, thereby confirming that the transaction expected to be completed by the seventh transaction is successfully executed. When the seventh transaction is successfully executed and the eighth transaction is successfully executed, the asset pending transfer event and the asset transfer completion event shown in Figure 14 can be generated accordingly, and the two events will be successfully matched.

Through the aforementioned steps S1221 to S1227, for the situation in which the seventh transaction is successfully executed but the eighth transaction is not successfully executed as mentioned above, the asset pending transfer event corresponding to the seventh transaction in the event set cannot be consumed, and the management member can confirm that the resource transfer transaction expected to be completed by the seventh transaction is not successfully executed by querying the event set, and based on the asset pending transfer event corresponding to the seventh transaction, return the corresponding second target resource to the sub-account belonging to the first cascading mode and corresponding to the first account.

The technical solutions described in the above method steps S1201 to S1227 mainly describe the following aspects: The process of transferring resources from a first sub-account in a rollover mode and corresponding to a first account to a second sub-account in a second rollover mode (different from the first rollover mode) and corresponding to a second account. However, in some technical scenarios, the FR field and the TR field of some transactions may include the same rollover mode. In this case, the transaction that is expected to be completed can be completed by other means.

In a possible implementation, the second blockchain system may receive the thirteenth transaction, the sender field and the receiver field of the thirteenth transaction include the first account and the second account respectively, and the thirteenth transaction also includes a resource transfer share, a first roll-up mode corresponding to the sender field, and a first roll-up mode corresponding to the receiver field; in this case, after the second blockchain system packages the thirteenth transaction into a batch corresponding to the first roll-up mode, such as the fourth batch, when executing the thirteenth transaction, the second target resource can be directly transferred from the first sub-account belonging to the first roll-up mode and corresponding to the first account to the third sub-account belonging to the first roll-up mode and corresponding to the second account according to the resource transfer share.

Correspondingly, when the fourth batch is submitted to the first blockchain system through the fourth method function, and when the proof data of the fourth batch is submitted to the first blockchain system through the fifth method function, there is no need to generate a corresponding asset transfer event.

Based on the same concept as the aforementioned method embodiment, a second blockchain system is also provided in the embodiment of the specification, wherein the second blockchain system supports M types of cascading modes, and the second blockchain system includes a packaged transaction batch chain, wherein the batch chain includes multiple batches connected in sequence. The second blockchain also includes: a receiver configured to receive a seventh transaction, wherein the sender field and the receiver field of the seventh transaction include a first account and a second account respectively, and the seventh transaction also includes a resource transfer share, a first cascading mode corresponding to the sender field, and a second cascading mode corresponding to the receiver field; a sorter configured to package the seventh transaction into the first batch in the batch chain, wherein the first batch corresponds to the first cascading mode, and execute the seventh transaction to achieve: according to the resource transfer share, the second target is transferred from the first subaccount belonging to the first cascading mode and corresponding to the first account to the first relay subaccount belonging to the first cascading mode and corresponding to the relay account resources, and generates a cross-mode transfer event; a shared bridge is configured to generate an eighth transaction according to the cross-mode transfer event, the sender field and the receiver field of the eighth transaction respectively include the relay account and the second account, and the eighth transaction also includes the resource transfer share and the second cascading mode; the sorter is configured to package the second transaction into a second batch in the batch chain, the second batch corresponds to the second cascading mode, execute the eighth transaction, and realize: according to the resource transfer share, the second relay sub-account belonging to the second cascading mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second cascading mode and corresponding to the second account.

A computer-readable storage medium is also provided in an embodiment of the present specification, on which a computer program/instruction is stored. When the computer program/instruction is executed in a computer, the computer is caused to execute the method steps performed by the first blockchain system or the second blockchain system in the aforementioned embodiments.

A computing device is also provided in an embodiment of the present specification, including a memory and a processor, wherein the memory stores a computer program/instruction, and when the processor executes the computer program/instruction, the method steps performed by the first blockchain system or the second blockchain system in the aforementioned embodiments are implemented.

In the 1990s, improvements to a technology could be clearly divided into hardware improvements (for example, improvements to circuit structures such as diodes, transistors, switches, etc.) and software improvements (improvements to method flows). However, with the development of technology, many improvements to method flows today can be considered hardware and software improvements. Direct improvement of the circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

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. It is also known to those skilled in the art that in addition to implementing the controller in a purely computer readable program code manner, 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. Of course, the present application does not exclude that with the development of computer technology in the future, 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.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is only one way of executing the steps among many steps, and does not represent the only execution order. When the actual device or terminal product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel. The terms "include", "comprising" or any other variation thereof are intended to cover non-exclusive inclusion, so that a process, method, product or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, product or device. In the absence of further restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device comprising the elements. For example, if the words first, second, etc. are used to represent names, they do not represent any particular order.

For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of 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. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection 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.

The present invention is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the embodiment of the present invention. It should be understood that 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.

In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and 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.

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. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that 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. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of mutual contradiction, a person skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims (16)

A resource management method for a blockchain system, the method being executed by a second blockchain system supporting M types of rollup modes, the second blockchain system including a packaged transaction batch chain, the batch chain including a plurality of batches connected in sequence, the method comprising: receiving a seventh transaction, wherein a sender field and a receiver field of the seventh transaction include a first account and a second account respectively, and the seventh transaction further includes a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; Packing the seventh transaction into the first batch in the batch chain, the first batch corresponding to the first roll-up mode, executing the seventh transaction to achieve: according to the resource transfer share, transferring the second target resource from the first sub-account belonging to the first roll-up mode and corresponding to the first account to the first relay sub-account belonging to the first roll-up mode and corresponding to the relay account, and generating a cross-mode transfer event; Generate an eighth transaction according to the cross-mode transfer event, wherein the sender field and the receiver field of the eighth transaction include the relay account and the second account respectively, and the eighth transaction also includes the resource transfer share and the second folding mode; The eighth transaction is packaged into a second batch in the batch chain, the second batch corresponds to the second cascading mode, and the eighth transaction is executed to achieve: according to the resource transfer share, the second relay sub-account belonging to the second cascading mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second cascading mode and corresponding to the second account. According to the method of claim 1, the batch chain includes batch headers of the multiple batches, and the batch header includes a convolution mode corresponding to the batch to which it belongs. According to the method of claim 1, a batch number of the first batch in the batch chain is smaller than a batch number of the second batch in the batch chain; for sender fields of multiple transactions included in the first batch, their respective corresponding stacking modes are all the first stacking mode; for sender fields of multiple transactions included in the second batch, their respective corresponding stacking modes are all the second stacking mode. According to the method according to claim 1, the receiver includes M transaction pools corresponding to the M types of folding modes; before the seventh transaction is executed, it is cached in the transaction pool corresponding to the first folding mode; before the eighth transaction is executed, it is cached in the transaction pool corresponding to the second folding mode. The method according to claim 4, further comprising: Before packaging the seventh transaction into the first batch in the batch chain, determine a target rollup mode corresponding to the first batch to be packaged, and if the target rollup mode is the first rollup mode, pull multiple transactions from a transaction pool corresponding to the first rollup mode, sort and package the multiple transactions, wherein the multiple transactions include the seventh transaction; After completing the execution of the first batch, sending a ninth transaction to the first blockchain system, the ninth transaction is used to call the fourth method function in the concatenated contract deployed by the first blockchain system, the ninth transaction includes the concatenated data of the first batch, so that the first blockchain system processes the concatenated data of the first batch. According to the method of claim 5, the second blockchain system further includes a first prover corresponding to the first convolution mode; wherein the method further includes: The first prover sends a tenth transaction to the first blockchain system, where the tenth transaction is used to call the fifth method function in the roll-up contract deployed by the first blockchain system. The tenth transaction includes the first roll-up mode and the first proof data corresponding to the first batch, so as to support the first blockchain system to verify whether multiple transactions in the first batch are correctly executed according to the verification method corresponding to the first roll-up mode by using the first proof data, and generate an asset transfer event corresponding to the seventh transaction if the verification is passed. The method according to claim 4, further comprising: Before packaging the second transaction into the second batch in the batch chain, determine a target rollup mode corresponding to the second batch to be packaged, and if the target rollup mode is the second rollup mode, pull multiple transactions from a transaction pool corresponding to the second rollup mode, sort and package the multiple transactions, wherein the multiple transactions include the eighth transaction; After completing the execution of the second batch, an eleventh transaction is sent to the first blockchain system, where the eleventh transaction is used to call the fourth method function in the concatenated contract deployed by the first blockchain system, and the eleventh transaction includes the concatenated data of the second batch, so that the first blockchain system processes the concatenated data of the second batch. According to the method of claim 7, the second blockchain system further includes a second prover corresponding to the second convolution mode; wherein the method further includes: The second prover sends a twelfth transaction to the first blockchain system, and the twelfth transaction is used to call the fifth method function in the cascade contract deployed by the first blockchain system. The twelfth transaction includes the second cascade mode and the second proof data corresponding to the second batch, which is used to support the first blockchain system to verify whether multiple transactions in the second batch are executed correctly according to the verification method corresponding to the second cascade mode, using the second proof data, and generate an asset transfer completion event corresponding to the eighth transaction if the verification passes. According to the method of claim 7, the determining the target stacking mode corresponding to the second batch to be packaged comprises determining the target stacking mode corresponding to the second batch to be packaged according to at least one of the following information: a batch submission time interval corresponding to each of the M stacking modes, a reference number of transactions required to be included in the batch corresponding to each of the M stacking modes, and a number of transactions cached in each of the M transaction pools. The method according to any one of claims 1 to 9, further comprising: Obtaining a resource distribution event from a first blockchain system, wherein the first blockchain system is deployed with a relay contract, wherein the resource distribution event is generated by the first blockchain system executing the relay contract according to a first transaction, wherein the first transaction is initiated by the first account, and wherein the first transaction indicates N types of roll-up modes among the M types of roll-up modes, and resource distribution shares corresponding to each of the N types of roll-up modes; Generate N sub-transactions according to the resource distribution event, wherein any i-th sub-transaction includes the first account, the i-th folding mode among the N folding modes, and the corresponding resource distribution share; Executing the i-th sub-transaction to achieve: according to the resource distribution share corresponding to the i-th roll-up mode, depositing the second target resource into the i-th first sub-account belonging to the i-th roll-up mode and corresponding to the first account. According to the method of claim 10, the i-th first sub-account is obtained by derivative calculation based on the first account and the i-th folding mode. According to the method of claim 10, the state tree corresponding to the world state of the second blockchain system includes M sub-state trees corresponding to the M roll-up modes; wherein the execution of the i-th sub-transaction further implements: in the sub-state tree corresponding to the i-th roll-up mode, query whether the i-th first sub-account exists, if not, in the sub-state tree corresponding to the i-th roll-up mode, register the i-th first sub-account. The method according to claim 10, further comprising: receiving a second transaction, wherein a sender field of the second transaction includes the first account, and the second transaction includes a resource transfer-out share and a first roll-up mode corresponding to the first account; Executing the second transaction to achieve: transferring out the second target resource from the second sub-account belonging to the first roll-up mode and corresponding to the first account according to the resource transfer-out share; A third transaction is sent to the first blockchain system, where the third transaction is used to call a first method function in the rolled contract deployed by the first blockchain system, and the third transaction includes the first account and the resource transfer share, so that the first blockchain system transfers a first target resource to the first account according to the resource transfer share. According to the method of claim 13, the third transaction also includes a batch number of a third batch to which the second transaction belongs in the second blockchain system, and a transaction number corresponding to the second transaction in the third batch; wherein the batch number and the transaction number are used to support the first blockchain system to transfer the first target resource to the first account according to the resource transfer-out share when it is determined that the third batch has entered an unchangeable state and the third batch includes the second transaction corresponding to the third transaction. The method according to any one of claims 1 to 9, further comprising: receiving a thirteenth transaction, wherein a sender field and a receiver field of the thirteenth transaction include a first account and a second account respectively, and the thirteenth transaction further includes a resource transfer share, a first roll-up mode corresponding to the sender field, and a first roll-up mode corresponding to the receiver field; The thirteenth transaction is packaged into a fourth batch in the batch chain, the fourth batch corresponds to the first cascading mode, and the thirteenth transaction is executed to achieve: according to the resource transfer share, the second target resource is transferred from the first sub-account belonging to the first cascading mode and corresponding to the first account to the third sub-account belonging to the first cascading mode and corresponding to the second account. A second blockchain system, the second blockchain system supports M types of cascading modes, the second blockchain system includes a packaged transaction batch chain, the batch chain includes multiple batches connected in sequence, including: a receiver configured to receive a seventh transaction, wherein a sender field and a receiver field of the seventh transaction include a first account and a second account respectively, and the seventh transaction further includes a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; a sequencer configured to package the seventh transaction into a first batch in the batch chain, the first batch corresponding to the first roll-up mode, execute the seventh transaction, and implement: according to the resource transfer share, transferring the second target resource from the first sub-account belonging to the first roll-up mode and corresponding to the first account to the first relay sub-account belonging to the first roll-up mode and corresponding to the relay account, and generating a cross-mode transfer event; The shared bridge is configured to generate an eighth transaction according to the cross-mode transfer event, and the sending of the eighth transaction The party field and the recipient field include the relay account and the second account respectively, and the eighth transaction also includes the resource transfer share and the second roll-up mode; The sequencer is configured to package the second transaction into a second batch in the batch chain, the second batch corresponds to the second cascading mode, and execute the eighth transaction to achieve: according to the resource transfer share, the second relay sub-account belonging to the second cascading mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second cascading mode and corresponding to the second account.