Blockchain system and resource management method thereof

Abstract

A resource management method of a blockchain system and the blockchain system, the method executed by a second blockchain system in Layer2 includes: receiving a seventh transaction, wherein the seventh transaction includes a resource transfer share, a first account and a corresponding first stack mode, a second account and a corresponding second stack mode; executing the seventh transaction to achieve: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first stack mode and corresponding to the first account to a first relay sub-account belonging to the first stack mode and corresponding to a relay account, and generating a cross-mode transfer event; generating an eighth transaction according to the cross-mode transfer event, wherein the eighth transaction includes the resource transfer share, the relay account, the second account and the second stack mode; executing the eighth transaction to achieve: according to the resource transfer share, transferring the second target resource from a second relay sub-account belonging to the second stack mode and corresponding to the relay account to a second sub-account belonging to the second stack mode and corresponding to the second account.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a blockchain system and a resource management method thereof. BACKGROUND

[0002] A blockchain system is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. In the blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and a distributed ledger is ensured to be unalterable and unforgeable by means of cryptography. Due to the characteristics of decentralization, unalterable information, autonomy and the like, the blockchain system is paid more and more attention and applied. SUMMARY

[0003] The purpose of the present application is to provide a blockchain system and a resource management method thereof.

[0004] In a first aspect, a resource management method of a blockchain system is provided, the method is executed by a second blockchain system supporting M types of rollup modes, the second blockchain system includes a batch chain, and the batch chain includes a plurality of batches connected in sequence. The method comprises: receiving a seventh transaction, the sender field and the receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first rollup mode corresponding to the sender field and a second rollup 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 rollup mode, executing the seventh transaction, and realizing: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first rollup mode and corresponding to the first account to a first relay sub-account belonging to the first rollup mode and corresponding to a relay account, and generating a cross-mode transfer event; according to the cross-mode transfer event, generating an eighth transaction, the sender field and the receiver field of the eighth transaction comprising the relay account and the second account respectively, the eighth transaction further comprising the resource transfer share and the second rollup mode; packaging the eighth transaction into a second batch in the batch chain, the second batch corresponding to the second rollup mode, executing the eighth transaction, and realizing: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second rollup mode and corresponding to the relay account to a second sub-account belonging to the second rollup mode and corresponding to the second account.

[0005] In a second aspect, a second blockchain system is provided, comprising: a receiver configured to receive a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first roll mode corresponding to the sender field and a second roll mode corresponding to the receiver field; an orderer configured to package the seventh transaction into a first batch in the batch chain, the first batch corresponding to the first roll mode, execute the seventh transaction, and achieve: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first roll mode and corresponding to the first account to a first relay sub-account belonging to the first roll mode and corresponding to a relay account, and generating a cross-mode transfer event; a shared bridge configured to generate an eighth transaction according to the cross-mode transfer event, a sender field and a receiver field of the eighth transaction comprising the relay account and the second account respectively, the eighth transaction further comprising the resource transfer share and the second roll mode; and the orderer configured to package the second transaction into a second batch in the batch chain, the second batch corresponding to the second roll mode, execute the eighth transaction, and achieve: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second roll mode and corresponding to the relay account to a second sub-account belonging to the second roll mode and corresponding to the second account.

[0006] In a third aspect, a computing device is provided, comprising a memory and a processor, the memory storing executable code, and the processor executing the executable code to implement the method of the first aspect.

[0007] In a fourth aspect, a computer-readable storage medium is provided, storing a computer program, and when the computer program is executed in a computing device, the computing device executes the method of the first aspect.

[0008] In the technical solutions provided by the embodiments of the present specification, because the M rollup modes correspond to the same batch chain formed by a plurality of batches connected in sequence, the later-submitted batches are bound by the state root of the world state, and if the earlier-submitted batches that are relatively earlier in position are rolled back for some reason, the later-submitted batches that are relatively later in position must be rolled back, so there is no need to wait until the earlier-submitted batches have entered an unchangeable state before continuing to submit new batches in the batch chain. Correspondingly, when a user initiates a seventh transaction through a first account and a second account and expects to transfer target resources between two sub-accounts belonging to different rollup modes and respectively corresponding to the first account and the second account, the second blockchain system does not need to wait for the first batch to which the seventh transaction belongs to enter an unchangeable state, but can continue to execute an eighth transaction corresponding to the seventh transaction in a second batch located after the first batch, and then complete the resource transfer transaction expected to be completed by the seventh transaction, which is beneficial to completing the resource transfer according to the user's expectation in the second blockchain system. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings required in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0010] Figure 1 is one of the principle schematic diagrams of Layer2 in an embodiment;

[0011] Figure 2 is another principle schematic diagram of Layer2 in an embodiment;

[0012] Figure 3 is a third principle schematic diagram of Layer2 in an embodiment;

[0013] Figure 4 is a fourth principle schematic diagram of Layer2 in an embodiment;

[0014] Figure 5 is a process schematic diagram of registering a rollup mode in an embodiment;

[0015] Figure 6 is one of the flowcharts of a resource method of a blockchain system provided in the embodiments of the present specification;

[0016] Figure 7 is a schematic diagram of Layer1 and Layer2 cooperating to realize resource transfer in an embodiment;

[0017] Figure 8 is a schematic diagram of a blockchain system in an embodiment and a transaction initiated by the client thereof;

[0018] Figure 9 is a flowchart of a resource management method of a blockchain system provided in an embodiment of the present specification, part two;

[0019] Figure 10 is a flowchart of a resource management method of a blockchain system provided in an embodiment of the present specification, part three;

[0020] Figure 11 is a flowchart of a resource management method of a blockchain system provided in an embodiment of the present specification, part four;

[0021] Figure 12 is a flowchart of a resource management method of a blockchain system provided in an embodiment of the present specification, part five;

[0022] Figure 13 is a structural schematic diagram of a batch chain provided in an embodiment of the present specification;

[0023] Figure 14 is a schematic diagram of an event relationship provided in an embodiment of the present specification. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings. Obviously, the described embodiments are only part of the embodiments of the present specification, rather than all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present specification.

[0025] There is a classic CAP theorem in a distributed system: Consistency (consistency), Availability (availability), and Partition tolerance (partition tolerance), which cannot be achieved simultaneously, simply referred to as the "impossible triangle" problem. There is also an impossible triangle in the blockchain system: efficiency, decentralization, and security. Although the "impossible triangle" of the blockchain system here has not been explicitly theoretically demonstrated, it is a summary of existing blockchain systems. Here, efficiency, decentralization, and security are defined as follows: efficiency: the number of transactions processed per second, i.e., TPS (Transaction per Second); decentralization: the threshold of participating nodes is low enough to ensure a large number of distributed nodes in the system; security: the difficulty of launching an attack on the blockchain system is large enough.

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

[0027] High gas fees (or transaction fees) often become a barrier to transactions. Although the shift from PoW (Proof-of-Work) to PoS (Proof-of-Stake) has changed the way the right to record transactions on the blockchain is acquired, the transaction fees paid to the nodes that acquire this right haven't decreased significantly. This is because gas fees are designed to cover the costs incurred by nodes executing transactions (including executing smart contract code), and without changing these costs, gas fees won't decrease. For example, a cryptocurrency exchange transaction on a decentralized exchange might cost over $100 during congestion, deterring many users.

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

[0029] Ethereum's Layer 2 includes a mechanism called Rollup.

[0030] The core idea of Rollup is shown in Figure 1 , which is to save the proof of transaction process on Layer 1, and run the transaction process (computing process) and state storage on Layer 2. The proof of transaction process includes a set of pre-state, post-state and transactions before execution, which can be used to verify the correctness of the state transition corresponding to the set of transactions, and can also be used to restore the execution process of all transactions and the state of all accounts on Layer 2, thereby eliminating the security risks caused by data availability on Layer 2

[0031] The principle of Rollup can be shown in Figure 2 and Figure 3 ( Figure 3 OP-Rollup in the following).

[0032] The transaction of creating a smart contract is sent to Layer 1, and after the consensus of Layer 1, each node on Layer 1 can execute this transaction, thereby completing the deployment of the contract. Specifically, it 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, which is one of the biggest improvements of Ethereum as a representative of blockchain 2.0 over blockchain 1.0. The smart contract published and invoked by the user in Ethereum can run on EVM. After executing the transaction of deploying the smart contract, a contract account corresponding to the smart contract is generated on Layer 1, which has an address on the chain and includes balance, nonce, Codehash of contract code, and Storage_Root of contract storage. 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 causes the virtual account on the blockchain to contain the contract code and the account storage (Storage). Subsequently, the nodes on Layer 1 can receive transaction requests that call the deployed smart contract, which can include the address of the called contract, the function in the called contract, and the input parameters. Generally, after the consensus of the transaction request, each node of the blockchain can independently execute the specified called smart contract.

[0033] The Storage_root in Ethereum is the hash of the root node of an MPT tree, which organizes the storage of the state of a contract account. MPT stands for Merkle Patricia Tree, which is a combination of Merkle Tree and Patricia Tree (a more space-saving Trie tree, dictionary tree). The Merkle Tree algorithm calculates a Hash value for each transaction, then connects them two by two to calculate the Hash again, all the way to the top layer of the Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is usually referred to as MPT tree. In fact, the block header of Ethereum includes the roots of three MPT trees, namely Transaction_Root (Tx_Root for short), State_Root, and Receipt_Root. State_Root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, the state tree state trie in the form of an MPT points to State_Root. From the root node of this MPT to part of the value of each node in the leaf node, the addresses can be concatenated in order to form the account address as the key, and the account information stored in the leaf node is the value corresponding to the account address, which constitutes a key-value pair. The aforementioned key can be sha3(Address), that is, the hash value of the account address (the hash algorithm uses the sha3 algorithm), and the value stored can be rlp(Account), that is, the rlp (Recursive Length Prefix, recursive length prefix) encoding of the account information. The account information is a four-tuple of [nonce, balance, storageRoot, codeHash]. For externally owned accounts (Externally Owned Account, EOA for short), there are usually only nonce and balance, while storageRoot and codeHash fields store empty strings / strings of all 0s by default. That is, external accounts do not store contracts, nor do they store state variables generated after contract execution. Contract accounts include Nonce, Balance, Storage root, and CodeHash. Whether it is an external account or a contract account, the account information is generally located in a separate leaf node (Leaf Node).

[0034] For a contract account (CA) in the state trie, its storage_Root points to another tree in MPT form, in which the data of state variables involved in the contract execution is stored. The MPT form tree pointed to by the storage_Root is a storage trie, i.e., the root node of the storage trie is stored in the storage_Root. Generally, the storage trie also stores key-value pairs. The key indicates the address of the state variable, and its value can be the result of processing the position of the state variable declaration in the contract (counted from 0) according to certain rules, such as sha3(position of the state variable declaration) or sha3(contract name+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). The data stored on the path from the root node to the leaf node is concatenated to form the key, and the value is stored in the leaf node. In the state trie and the storage trie therein, the root node and the intermediate node other than the leaf node use Figure 3 Clouds are used to represent the flexible and complex structure therein.

[0035] As shown in Figure 2 , Rollup can deploy Rollup Contract on Layer 1. In Layer 2, transactions initiated 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 state. As shown in Figure 1 and 2 , Batch 1 can include Tx_21, Tx_22, Tx_23, and Batch 2 can include Tx_24, Tx_25, Tx_26. In Layer 2, these transactions can be sorted according to a rule, and then these sorted transactions can be executed in sequence, for example, according to the timestamp in the transaction. After the transactions in a Batch are executed in sequence, the resulting state can include several, for example, the transactions in Batch 1 are:

[0036] Tx_21: Alice→Bob 20; indicates that Alice transfers 20 units of assets such as ethers to Bob;

[0037] Tx_22: Alice→Charlie 10; indicates that Alice transfers 10 units of assets such as ethers to Charlie;

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

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

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

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

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

[0043] In Layer 2, a Merkle tree can be used to organize the states of transactions in Batch 1 before and after sequential execution. For example... Figure 3 As shown, in Layer 2, the transactions of a batch and their related state changes can be organized together. For example, the Merkle root obtained by organizing the hash values ​​of the transactions in Batch 1 according to a Merkle tree can be locked in the batch header. This header is similar to the block header in Layer 1, and this Merkle root is the Tx_Root in the batch header. Similarly, as mentioned earlier, the Merkle root obtained by organizing all the state values ​​of the transactions in Batch 1 before execution according to a Merkle tree can be locked in the batch header, i.e., the Pre-State Root; the Merkle root obtained by organizing the hash values ​​of all the state values ​​of the transactions in Batch 1 after sequential execution can be locked in the batch header, i.e., the Post-State Root. For Batch M, a timestamp can also be set in its header to record the time when the batch was generated, and other fields can also be set. For the (M+1)th batch, the PreState Root in its Header is equal to the PostState Root in the Header of the Mth batch, such as... Figure 3 The line connecting these two roots represents the structure. This creates a chain-like structure between batches.

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

[0045] In the OP-Rollup mechanism, the receiver including the transaction pool (Txpool), the relay and the sequencer can be set in Layer2. In the ZK-Rollup and TEE-Rollup mechanisms, the prover can also be set in Layer2. For the TEE-Rollup mechanism, the prover can be set in the TEE.

[0046] The OP-Rollup mechanism is described below. As shown in Figure 3 , it is assumed that the transactions Tx21, Tx23, Tx25, Tx22, Tx26 and Tx24 are collected in the TxPool. The sequencer sorts and packs these transactions according to the timestamps in the transactions, for example, packs Tx21, Tx22 and Tx23 into Batch M, organizes the hash values of these transactions into a Merkle tree to generate a 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 tree root of the Merkle tree, generally, for the case of less than 2 n , the last transaction can be assigned multiple times to complete 2 n , so as to calculate the tree root of the 2-ary Merkle tree. As shown in Figure 3 , the last Tx23 is repeated once to complete 4 transactions in time order, so that the number of transactions reaches 2 2 , and the tree root of the 2-ary 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.

[0047] Before the execution of the transaction sequence Tx21, Tx22, Tx23 in Batch M, all the states are as follows: Alice: 50, Bob: 100, Charlie: 150, David: 200. The sequencer can organize these states into a Merkle tree and store the hash value of the root node of the Merkle tree as the pre-state root corresponding to Batch M in the Pre State Root field of the Batch M Header. Then the sequencer can execute the three transactions Tx21, Tx22, Tx23 in sequence; the result of executing the three transactions generates new states, as follows: Alice: 20, Bob: 110, Charlie: 170, David: 200. The sequencer can organize these updated states into a Merkle tree and store the hash value of the root node of the Merkle tree as the post-state root corresponding to Batch M in the Post State Root field of the Batch M Header.

[0048] Then, the sequencer can send a transaction 1 to Layer 1 through the relayer, which calls the Rollup Contract. The transaction 1 includes some or all of the fields in the Batch M Header and the compressed transaction sequence Tx21, Tx22, Tx23. After compression, the space occupied by Tx21, Tx22, Tx23 can be greatly reduced. The interface in the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, Tx23) in the calldata, which is a cheaper (lower gas fee) location. In the Ethereum smart contract, calldata is a special data location used to store input data through function calls. Specifically, calldata data is generally stored directly in the transaction data of Ethereum, which is generally more gas-efficient 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 a non-compressed transaction sequence or a compressed transaction sequence.

[0049] It is worth noting that in an Ethereum transaction, the signature part accounts for about half of the overall volume, and the From field can be 0 bytes because the From field can be recovered from the signature. In Rollup, BLS or other schemes are usually used for aggregation, and the average signature of each transaction is compressed to about 0.5 bytes. Accordingly, the From field of the transaction cannot be recovered from the aggregated signature in the Rollup transaction, so 4 bytes are needed to represent it separately.

[0050] The BLS signature scheme was first proposed by Professor Dan Boneh of Stanford University in 2001, based on the bilinear mapping structure. Generally, a user's control over his own account is reflected in the signature of a transaction with his own private key. A single signature can reach 68 bytes as shown in the table above, occupying a large volume. Multiple accounts initiate multiple transactions, and each account needs to sign each transaction 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 signatures of different signers on the same message, or the aggregation of signatures of different messages. Public key aggregation can aggregate multiple different public keys into a total public key, which can be used to verify the aggregated signature without the need for each public key to participate in the calculation when verifying the total signature. Schnorr signature algorithm and BLS signature algorithm can be used to realize signature aggregation. Compared with Schnorr signature algorithm, BLS signature algorithm realizes smaller aggregated signature volume, about half of Schnorr.

[0051] The above compression scheme and BLS signature aggregation are ideal design schemes. However, in several Rollup schemes in practice, a compressed transaction still occupies 40-50 bytes of space, and the signature is not included, that is, BLS signature aggregation has not been used.

[0052] Following the foregoing, after Layer 1 receives transaction 1 that calls the Rollup Contract, it is executed on some nodes after consensus, and a block is generated containing transaction 1 and its execution result, as well as other transactions and execution results. Figure 3Block N. The other transactions can include normal transfer transactions and transactions involving other smart contracts. Among them, the normal transfer transactions and the transactions involving other smart contracts can involve the execution of transactions. In particular, the transactions involving other smart contracts can involve complex execution logic. Here, the transaction 1 calls the function stored in the calldata position of the RollupContract, which mainly involves storing the specified content in the specified position, i.e., does not involve the execution of complex contract logic. That is, the Rollup Contract in Layer 1 mainly functions to store the specified content in the transaction sent from Layer 2 in the specified position, and does not involve complex execution logic. For example, as an example, Tx21, Tx22, Tx23 are stored in Tx_12 locked in the transaction tree by Tx_Root in the Block N Header. In addition, as an implementation, the Pre State Root and the Post State Root in the Batch M Header in the transaction 1 can be stored in the state 1 and the state 2 in the contract state on Layer 1, respectively. As described previously, the state 1 and the state 2 are contained in the state trie locked by the State_Root in the Block N Header, for example, in the storage trie. In order to distinguish, the state 1 and the state 2 in the contract state on Layer 1 are referred to as the Last State root and the Current State root, respectively, for example. In addition, in order to simplify, only the Current State root can be saved in the contract state on Layer 1, and the Last State root can not be saved, as shown in the following code example. In other implementations, the Last State root and the Current State root can also be stored in the calldata in Layer 1 as the transactions in Layer 2, which will not be described herein again.For the former, for example, is to call the commitBatch() contract interface in Layer 1 as follows: function CommitBatch(bytes[] calldata_transactions, bytes32_preStateRoot, bytes32_postStateRoot), the CommitBatch() contract interface can set basic verification logic inside, for example, it can include verifying whether the Pre State Root in the current transaction 1 is equal to the Current State Root in the contract storage, if it is equal, then store the transactions on Layer 2 in calldata in transaction 1, and update the Current State Root in the contract storage to the Post State Root.

[0053] In the above manner, the OP-Rollup can execute each transaction in Layer 2, and can bundle dozens, hundreds or even more Layer 2 transactions in one batch, and only publish the minimum information to Layer 1. The so-called minimum information includes the compressed Layer 2 transactions and the hash values of the state roots before and after the execution of the batch of transactions as described above. As shown above, it can be sent by a transaction on Layer 1, for example, transaction 1 in Figure 3 It can be seen that this is equivalent to executing a batch of transactions on Layer 2 at one time, but only one transaction on Layer 1. At the same time, the OP-Rollup does not carry any proof. This is due to the assumption that there is no fraud or malicious behavior in the submitted Layer 2 information, so it is called "Optimistic". Although there is such an assumption, in order to prevent and deter, the submitter of Layer 2 information will still be required to pledge a part of the Layer 1 asset (typically the on-chain native token, such as Ethereum on Ethereum) in the Rollup Contract of OP-Rollup. For the Layer 2 information submitted to Layer 1, although the transactions therein are compressed, as described above, it can still be used to restore the execution process of all transactions on Layer 2 and the state of all accounts, thereby eliminating the security risks on Layer 2 due to data availability.

[0054] OP-Rollup, although optimistic, can still have a challenge period on Layer 1, during which anyone can challenge using a fraud proof. Typical reasons include the challenger proving that a certain transaction in the Batch was not executed correctly, i.e., the execution of the transaction did not produce the correct state. If a certain transaction in a Batch is proven to be invalid, then the Batch is also invalid, and the Rollup contract on Layer 1 can roll back the chain of Batch on Layer 2, and the invalid Batch and all Batch after it become orphaned blocks. Once the fraud proof is successful, part of the deposit is paid to the challenger, and the rest is destroyed. Conversely, if no one submits a fraud proof until the end of the challenge period, the Rollup contract can determine the Batch. Fraud proof is a way of verifying data validity adopted by the Optimistic Rollup scheme. Currently, fraud proof can be divided into single-round interaction and multi-round interaction.

[0055] In a single-round interaction fraud proof implementation, the disputed transaction is replayed on Layer 1, and the invalid state is detected before submission. For example, Alice, as a validator, synchronizes the compressed data of OP-Rollup to Layer 1 and pledges a deposit. If the challenger Bob disputes 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 recompute the transactions in the block on Layer 1 to determine right or wrong. The deposit of the wrong party will be confiscated, and the correct party will be rewarded.

[0056] It should be noted that although there are all compressed transactions on Layer 2 in the calldata on Layer 1, the compressed transactions in Batch M in the calldata are not directly executed during the fraud proof verification process. Instead, all transactions in Batch M are simulated based on the transactions transmitted by the challenger. This is because the compressed Batch M in the calldata is generally used to restore the execution process of all transactions on Layer 2 and the state of all accounts, thereby eliminating the security risks caused by data availability on Layer 2. Moreover, the authenticity of the compressed Batch M in the calldata without signature is to be determined, while the transactions transmitted by the challenger are complete transactions, which can verify the validity of the transactions. Furthermore, the initial state cannot be verified, and the contract storage only contains the state root instead of the state, unless all transactions are executed in sequence from Batch 0 to Batch M-1 to obtain the complete state, which is obviously not economical and efficient.

[0057] The single-round interactive fraud proof increases the data that must be published on-chain and requires all transactions in Batch M to be re-executed on Layer 1, and replaying these transactions also incurs significant fuel costs. As a result, OP-Rollups are moving toward multi-round interactive proofs to achieve the same goal with higher efficiency.

[0058] In a multi-round interactive fraud proof, after Bob challenges the data synchronized by the Sequencer, the Sequencer divides the disputed Batch range into two segments and returns them through a contract interface such as dispute(), and then Bob further selects one of the two divided segments to continue the challenge, and the Sequencer divides the disputed range again, and so on, until the disputed range is reduced to a specific transaction. Here, Bob sends the original text of the challenged transaction (including the signature of each transaction) and the global state before the execution of the transaction, and the Sequencer sends the PreState Root before the execution of the challenged transaction (also referred to as the state commitment here) and the Post State Root after the execution, which are submitted to the RollupContract contract on Layer 1 for calculation and judgment. Specifically, the Rollup Contract contract verifies the global state before the execution of the challenged transaction based on the Pre State Root before the execution of the transaction, executes the challenged transaction based on the global state before the execution of the transaction, generates the state after the execution, and generates the Post State Root based on the global state after the execution of the challenged transaction. If the Post State Root sent by the Sequencer is different, it means that the challenge is successful, otherwise the challenge fails. In actual applications, Arbitrum does not use the two-division method, but uses K-division, i.e., dividing N instructions into N / K groups to find fraudulent instructions, which is more efficient.

[0059] Therefore, compared with the single-round interactive type, the multi-round interactive type can solve disputes at a lower cost. For example, the two-division protocol can reduce the amount of data published on the chain (there is no need to publish the state commitment for each transaction), and it is easier to support complex smart contracts and handle higher requirements for disputes. However, as the number of interactions increases, its dispute window period will be longer.

[0060] Overall, since the design of OP-Rollup requires all data related to state updates and verification to be placed on Layer 1, the scalability and degree of throughput improvement of OP-Rollup are the most limited, and a waiting period of 7 days or even longer is required. This means that extracting assets from OP-Rollup will be delayed and requires waiting until the window period is over.

[0061] 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 the necessary information. In ZK-Rollup, unlike OP-Rollup, a proof (including proof) is also generated for the transaction Batch in Layer2 (e.g., cryptographic proof algorithm such as ZK-SNARK), which can prove that the Post State Root is obtained after the correct execution of the transaction sequence in the corresponding transaction Batch based on the Pre State Root. This can be confirmed by verifying the proof without re-executing the transactions in the Batch.

[0062] The process of generating a proof can be that the Sequencer packages all the transactions in a Batch in Layer2 (including sender, receiver, amount) and other information such as Pre State Root, Post State Root, and Proving Key before and after the execution of the transactions in this Batch in Layer2 and sends it to a prover on Layer2. The prover converts this information into a special form called witness (witness). Select a part as public input and another part as private input. Then, the prover uses the zero-knowledge proof computing circuit (a specific algorithm) arranged in 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. In the case of successful circuit execution, the prover can output a proof, which proves that the packaged data is valid and correct. Moreover, the volume of this proof is small, generally only a few dozen bytes. The above process of generating a proof is similar to the process of re-execution and contains a large amount of circuit calculation, which is more complex, 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 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 cannot be used to obtain the specific content of the packaged data.

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

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

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

[0066] To solve the problem of complex calculation and long time required for generating proof, the TEE-Roll mechanism is proposed. The main difference between TEE-Rollup mechanism and ZK-Rollup is that the Prover is implemented by TEE (Trusted Execution Environment), and the Prover can sign the information of a certain transaction Batch provided by the Sequencer after verification, using the private key in the TEE, and then publish the signature as proof to Layer1 through the Relayer, which can be quickly verified by the Rollup Contract.

[0067] After the end of the challenge period corresponding to any transaction Batch submitted by Layer2, 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 unchangeable (Finality) state; at the same time, it means that each transaction in Layer2 belonging to the arbitrary Batch has entered the unchangeable state.

[0068] With the development of Rollup technology, the management members of any blockchain system located in Layer2 may expect that the blockchain system in Layer2 and the blockchain system in Layer1 can support multiple Rollup modes (i.e. rollup modes) for some specific business purposes. Different Rollup modes do not necessarily mean different Rollup mechanisms, for example, two Rollup modes may use the same Rollup mechanism, the difference is that Layer1 may store the packaged transactions submitted by Layer2 in different ways, for example, Rollup mode 1 and Rollup mode 2 use the same Rollup mechanism ZK-Rollup, Rollup mode 1 requires Layer1 to store the packaged transactions in Layer2 according to the transaction text in Layer1, while Rollup mode 2 requires Layer1 to store the transaction hash of the transaction in Layer2 instead of the transaction text.

[0069] Although the foregoing uses Layer 1 and Layer 2 to represent the blockchain system, it should be understood that Layer 1 can generally include one blockchain system, while Layer 2 can include one or more blockchain systems. The one or more blockchain systems included in Layer 2 each take the blockchain system in Layer 1 as the corresponding upper-layer blockchain system.

[0070] If the Rollup mechanism adopted by the Rollup mode is different, it must mean that the Rollup mode is different. Based on this, the embodiments of the present specification will mainly distinguish different Rollup modes based on the difference in the Rollup mechanism. For example, if the Rollup mechanism adopted between Layer 1 and Layer 2 is ZK-Rollup, the corresponding Rollup mode is still recorded as ZK-Rollup; if the Rollup mechanism adopted between Layer 1 and Layer 2 is TEE-Rollup, the corresponding Rollup mode is still recorded as TEE-Rollup.

[0071] With the increase of Rollup modes, it is desirable to have a resource management method of a blockchain system to support users to more safely and conveniently manage Layer 2 related resources through Layer 1, such as starting or terminating a certain Rollup mode according to the needs of the management members, and managing the target resources held by the user in Layer 2 through multiple accounts belonging to multiple Rollup modes according to the needs of the user.

[0072] In view of the above problems, the solution provided by the embodiments of the present specification is as follows: Figure 5 As shown in the figure, at least a Rollup contract Rollup Contract is deployed in Layer 1 (i.e. the first blockchain system), and the Rollup Contract includes a second method function for supporting the registration of Rollup modes. A bridge contract Bridge Contract and a governance contract Governance Contract can also be deployed in the first blockchain system. The Bridge Contract is mainly responsible for managing the blockchain systems in Layer 2, such as managing the accounts and resources held by the accounts under the second blockchain system in Layer 2; the Governance Contract is mainly responsible for managing the registration information of various Rollup modes.

[0073] It should be noted that the Bridge Contract and the Governance Contract can also not be deployed independently, but the method functions included therein for implementing the corresponding functions are directly integrated into the contract code of the Rollup Contract. The method functions included in the Bridge Contract and the Governance Contract and the specific functions implemented thereby will be described in detail below.

[0074] Figure 6 FIG. 1 is a flowchart of a resource method of a blockchain system according to an embodiment of the present disclosure. The method exemplarily describes a process of registering a new rollup mode (denoted as a second rollup mode) in a first blockchain system and a second blockchain system.

[0075] Referring to Figure 6 The method can include, but is not limited to, the following steps S601-S607.

[0076] At step S601, the first blockchain system receives a fourth transaction for calling a second method function in the Rollup Contract, and the fourth transaction includes registration information corresponding to the second rollup mode to be registered.

[0077] As described above, the second method function is used to support the registration of the Rollup mode.

[0078] Taking the second rollup mode to be registered as an example, the second rollup mode includes a TEE-Rollup, and referring to Figure 5 The management member of the second blockchain system can initiate the 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 can include, but is not limited to, one or more of the following information: identification information, a transaction ordering model, a verification method, and a genesis block; the transaction ordering model can include, but is not limited to, a consensus algorithm and an upper limit value of the number of transactions packaged.

[0079] At step S603, the first blockchain system executes the second method function in the Rollup Contract according to the fourth transaction, to implement: performing a first upgrade operation on the Rollup Contract and the Bridge Contract according to the registration information corresponding to the second rollup mode, and generating a rollup registration event, the rollup registration event including at least part of the registration information in the registration information corresponding to the second rollup mode.

[0080] Taking the second rollup mode to be registered as an example, the second rollup mode includes a TEE-Rollup, and referring toFigure 5 The first upgrade operation on the Rollup Contract can include but is not limited to adding or enabling a verification method TEE verifier corresponding to the TEE-Rollup in the Rollup Contract. The first upgrade operation on the Bridge Contract can 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 increase the corresponding share of the second target resource in the second blockchain system by calling the contract interface Deposite(), and the second target resource held by the sub-account of the TEE-Rollup in the second blockchain system can be called according to the corresponding strategy to add the corresponding share of the first target resource in the account corresponding to the sub-account in the first blockchain system.

[0081] When the first blockchain system executes the second method function in the Rollup Contract according to the fourth transaction, the registration information corresponding to the second rollup mode can also be stored in the Governance Contract, for example, the registration information of the TEE-Rollup.

[0082] The at least part of the registration information mentioned above can include but is not limited to identification information, transaction ordering model and genesis block.

[0083] The relay in the second blockchain system, for example, the shared bridge Bridge included in the relay, can listen to the rollup registration event in the first blockchain system, and then use at least part of the registration information included in the rollup 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 realize network rollup through the newly registered second rollup mode.

[0084] The shared bridge Bridge mentioned above 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, and then the Bridge generates transactions using the relay account and sends 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.

[0085] Exemplarily, the second blockchain system may, for example, perform the following steps S605 and S607 based on the rollup registration event.

[0086] At step S605, the second blockchain system generates, through the relay, a first upgrade transaction using the rollup registration event, the first upgrade transaction including at least part of the registration information corresponding to the second rollup mode.

[0087] The first upgrade transaction may be a special transaction, which may not be packaged into a batch transaction submitted by the second blockchain system. Exemplarily, the Bridge included in the relay may set the From field to the relay account and the To field to Null in the first upgrade transaction, so that the Sequencer of the second blockchain system can accurately know that the first upgrade transaction is a special transaction, execute the transaction expected to be executed by the first upgrade transaction and not package it into a batch; the Data field of the first upgrade transaction may include at least part of the registration information included in the rollup registration event.

[0088] At step S607, the second blockchain system executes the first upgrade transaction through the Sequencer, so as to perform a second upgrade operation on the infrastructure of the second blockchain system using at least part of the registration information corresponding to the second rollup mode.

[0089] Taking the second rollup mode to be registered as a TEE-Rollup as an example, refer to Figure 5 The shared bridge Bridge of the second blockchain system may, for example, send the first upgrade transaction including at least part of the registration information included in the registration information of the TEE-Rollup to the Sequencer. 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 a transaction pool TEE Txpool corresponding to the TEE-Rollup in the receiver; reconfiguring the Sequencer so that the reconfigured Sequencer can process transactions in the TEE Txpool according to the identification information, transaction ordering model and genesis block of the TEE-Rollup; and deploying a prover TEE Prover corresponding to the TEE-Rollup in the second blockchain system.

[0090] The foregoing is described in combination with Figure 5 and Figure 6The process of registering a TEE-Rollup is exemplarily described, however, it is not difficult to understand that other Rollup modes can also be registered through a similar process as described above, for example, a ZK-Rollup or other Rollup modes are registered, so that the first blockchain system and the second blockchain system can support M Rollup modes greater than 1 at the same time.

[0091] Referring to Figure 7 When the second blockchain system supports M Rollup modes greater than 1, the second blockchain system can maintain M account sets for M Rollup modes, that is, any user, for example, user 1, can have one or more accounts in the second blockchain system, and the number of accounts is not greater than M. Correspondingly, the state tree (state trie) corresponding to the world state of the second blockchain system can include M sub-state trees corresponding to M Rollup modes, and the state root of the second blockchain system (i.e., Globalstate root) can be calculated using the state root of each of the M sub-state trees.

[0092] Based on the foregoing steps S601-S607, the Sequencer can also initialize a sub-state tree corresponding to the second Rollup mode in the second blockchain system, including registering a relay sub-account belonging to the second Rollup mode and corresponding to the relay account in the sub-state tree corresponding to the second Rollup mode, for example, based on the relay account corresponding to the second blockchain system and the second Rollup mode, a derivation calculation is performed to obtain a relay sub-account belonging to the second Rollup mode and corresponding to the relay account, and the relay sub-account is registered in the sub-state tree corresponding to the second Rollup mode through the system contract System Contract in the second blockchain system.

[0093] The algorithm for performing derivation calculation on the accounts (including relay accounts) registered in the first blockchain system can be predetermined, and the algorithm for performing derivation calculation is not limited in the embodiments of the present specification. In a typical example, for the relay account A registered in the first blockchain system, for example, the hash value corresponding to the identification information of the relay account A and the second Rollup mode can be calculated, and the first x bits in the hash value are used as the relay sub-account belonging to the second Rollup mode and corresponding to the relay account.

[0094] Referring to Figure 7As shown, when the first blockchain system includes the relay account corresponding to the second blockchain system registered by the management member of the second blockchain system as account A, if the M types of rollup modes supported by the second blockchain system include ZK-Rollup and TEE-Rollup, the ZK-Rollup corresponding sub-state tree may include the relay sub-account ZK-AA corresponding to account A, and the TEE-Rollup corresponding sub-state tree may include the relay sub-account TEE-AA corresponding to account A.

[0095] Similarly, in order to reduce the number of accounts that a user needs to maintain in the first blockchain system and the second blockchain system, thereby improving the user experience, the account of any user, for example, user 1, in the second blockchain system under any rollup mode corresponds to a sub-account registered by the user 1 in a certain account in the first blockchain system. For example, referring to Figure 7 As shown, similar to the aforementioned relay sub-account ZK-AA and relay sub-account TEE-AA corresponding to account A, 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 Layer 1.

[0096] The account ZK-A1 of any user, for example, user 1, under ZK-Rollup can be derived based on account A1 and rollup mode ZK-Rollup; similarly, the account TEE-A1 of user 1 under TEE-Rollup can be derived based on account A1 and rollup mode TEE-Rollup. Alternatively, the second blockchain system can also achieve the correspondence between account A1 of any user, for example, user 1, in the first blockchain system and its account under any rollup mode in the second blockchain system by directly maintaining a mapping relationship table.

[0097] Because there is a correspondence between account A1 registered by user 1 in the first blockchain system and each account of user 1 in the second blockchain system, for example, account ZK-A1 and account TEE-A1, user 1 can reuse the account A1 registered in the first blockchain system and the corresponding public and private key pair to initiate the corresponding transaction in the second blockchain system as needed. Correspondingly, the client of the second blockchain system can not present the account ZK-A1 of user 1 under ZK-Rollup and the account TEE-A1 of user 1 under TEE-Rollup to user 1, but only needs to present the share of the second target resource held by the account of user 1 under ZK-Rollup and the share of the second target resource held by the account of user 1 under TEE-Rollup to user 1.

[0098] For example, referring to Figure 8 As shown, the user 1 can only be presented with the account A1 registered in the first blockchain system in the client of the second blockchain system; when the user 1 holds the second target resource in any Rollup mode such as ZK-Rollup and TEE-Rollup, the user 1 can also be presented with the share of the second target resource held by the sub-account in the ZK-Rollup (i.e., the ZK account balance) and the share of the second target resource held by the sub-account in the TEE-Rollup (i.e., the TEE account balance) in the client of the second blockchain system, but not the accounts ZK-A1 and TEE-A1.

[0099] When the user 1 expects to initiate a transaction Tx in the second blockchain system to achieve a certain business purpose, he / she can initiate the transaction Tx by using the account A1 registered in the first blockchain system. For example, when the user 1 needs to transfer the second target resource held by him / her to the user 2, the From field and the To field in the transaction Tx can include the accounts A1 and A2 registered in the first blockchain system by the user 1 and the user 2 respectively; in addition, the transaction Tx can also include an indication field corresponding to the From field (denoted as FR) and an indication field corresponding to the To field (denoted as TR). Wherein: the field value under the FR field is used to indicate the Rollup mode to which the sub-account corresponding to the account A1 belongs and needs to be transferred out of the second target resource by the transaction Tx; the field value under the TR field is used to indicate the Rollup mode to which the sub-account corresponding to the account A2 belongs and needs to be transferred into the second target resource by the transaction Tx.

[0100] Since the user 1 belongs to the sub-accounts of the M Rollup modes in the second blockchain system, each of which has a corresponding relationship with the account A1 registered in the first blockchain system, and the user 2 belongs to the sub-accounts of the M Rollup modes in the second blockchain system, each of which has a corresponding relationship with the account A2 registered in the first blockchain system, the second blockchain system can learn, based on the transaction Tx, the sub-account actually needing to transfer out of the second target resource and the sub-account actually needing to transfer into the second target resource in the transaction Tx, so as to complete the resource transfer transaction expected to be completed by the transaction Tx by executing the transaction Tx.

[0101] Figure 9 FIG. 2 is a flowchart of a resource management method of a blockchain system provided in an embodiment of the present specification. The method exemplarily describes a process of adding a second target resource to a sub-account of any first user in a second blockchain system by using a first account of the first user registered in a first blockchain system.

[0102] Referring to Figure 9 As shown in FIG. 9, the method can include, but is not limited to, the following steps S901-S907.

[0103] In step S901, the first blockchain system receives a first transaction initiated by a first account, the first transaction being used to invoke a Bridge Contract deployed by the first blockchain system, the first transaction indicating N types of roll-up modes supported by a second blockchain system from M types of roll-up modes supported by the second blockchain system, and resource distribution shares corresponding to the N types of roll-up modes respectively.

[0104] The first user can initiate the first transaction through the first account registered in the first blockchain system.

[0105] The From field of the first transaction can include the first account, the To field can include a contract account corresponding to the Bridge Contract, and the Data field can include the N types of roll-up modes supported by the second blockchain system from the M types of roll-up modes supported by the second blockchain system, and resource distribution shares corresponding to the N types of roll-up modes respectively. In addition, the Data field of the first transaction can also include identification information of the second blockchain system, and identification information of a method function / contract interface in the Bridge Contract expected to be invoked by the first transaction, for example, identification information of a contract interface Deposite() in the Bridge Contract.

[0106] In step S903, the first blockchain system executes the Bridge Contract according to the first transaction, so as to achieve the following: transferring first target resources to a relay account according to the resource distribution shares corresponding to the N types of roll-up modes respectively, and generating a resource distribution event, wherein the resource distribution event includes the first account, the N types of roll-up modes, and the resource distribution shares corresponding to the N types of roll-up modes respectively.

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

[0108] In order to ensure the reliability of resource transfer, a management member of the second blockchain system can register a relay account corresponding to the second blockchain system, for example, account A, in the first blockchain system.

[0109] The Bridge Contract can also store the resource distribution event through a corresponding asset transfer event list or other means.

[0110] The relay in the second blockchain system, for example, the shared Bridge included in the relay, can listen to the resource distribution event generated by the first blockchain system, and perform the following step S905 based on the listened resource distribution event.

[0111] To ensure security, the Bridge included in the relay of the second blockchain system can also query the simplified payment verification (SPV) proof corresponding to the resource distribution event from the first blockchain system. Through the SPV proof, it is determined that the first transaction belongs to the block that has been successfully submitted in the first blockchain system, and then the following step S905 is performed.

[0112] Step S905, the second blockchain system generates N sub-transactions according to the resource distribution event, and any ith sub-transaction includes the first account, the ith rollup mode in the N rollup modes, and the corresponding resource distribution share.

[0113] In the ith sub-transaction, the From field can include the relay account, the To field can include the first account, and the Data field can include the resource distribution share corresponding to the ith rollup mode. The Rollup mode included in the FR field corresponding to the From field and the TR field corresponding to the To field is the ith rollup mode. Referring to Figure 7 As shown, it is assumed that the N rollup modes include TEE-Rollup and ZK-Rollup. The Bridge can generate TEE sub-transactions and ZK sub-transactions according to the resource distribution event: in the ZK sub-transaction, the Rollup mode included in the FR field corresponding to the From field and the TR field corresponding to the To field is ZK-Rollup; and in the TEE sub-transaction, the Rollup mode included in the FR field corresponding to the From field and the TR field corresponding to the To field is TEE-Rollup.

[0114] Step S907, the second blockchain system executes the ith sub-transaction to achieve: determining the ith first sub-account belonging to the ith rollup mode and corresponding to the first account, and transferring the second target resource from the relay sub-account belonging to the ith rollup mode and corresponding to the relay account to the ith first sub-account according to the resource distribution share corresponding to the ith rollup mode.

[0115] The i-th sub-transaction can be executed by the Sequencer of the second blockchain system. In combination with the foregoing, it can be understood that when the Sequencer executes the i-th sub-transaction: in one possible implementation, the i-th first sub-account can be obtained by performing a derivation calculation using the first account included in the i-th sub-transaction and the i-th rollup mode; in another possible implementation, the i-th first sub-account can be obtained by querying the mapping relationship table maintained in the second blockchain system.

[0116] After the Sequencer obtains the i-th first sub-account, the Sequencer can query the i-th first sub-account in the sub-state number corresponding to the i-th rollup mode. If the i-th first sub-account cannot be queried from the sub-state tree corresponding to the i-th rollup mode, the i-th first sub-account can be registered in the corresponding sub-state tree by invoking the system contract of the second blockchain system.

[0117] Referring to Figure 7 It is assumed that the first account includes account A2, and the N rollup modes include TEE-Rollup and ZK-Rollup. If the Sequencer fails to query the sub-account ZK-A2 corresponding to the account A2 from the sub-state tree corresponding to the ZK-Rollup in the process of executing the ZK sub-transaction, the Sequencer can invoke the System Contract of the second blockchain system to register the sub-account ZK-A2 in the sub-state tree corresponding to the ZK-Rollup; if the Sequencer also fails to query the sub-account TEE-A2 corresponding to the account A2 from the sub-state tree corresponding to the TEE-Rollup in the process of executing the TEE sub-transaction, the Sequencer can invoke the System Contract of the second blockchain system to register the sub-account TEE-A2 in the sub-state tree corresponding to the TEE-Rollup.

[0118] When the i-th first sub-account is already included in the sub-state number corresponding to the i-th rollup mode, the Sequencer of the second blockchain system can transfer the second target resource from the relay sub-account corresponding to the relay account and belonging to the i-th rollup mode to the i-th first sub-account based on the resource distribution share included in the i-th sub-transaction.

[0119] Continuing the example in the foregoing, referring again to Figure 7 It can be understood that the Sequencer can 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.

[0120] Or the deposit of the second target resource into the i-th first sub-account can also be implemented in other ways other than the foregoing step 907. For example, when the second blockchain system executes the i-th sub-transaction, the i-th first sub-account corresponding to the i-th rollup mode and the first account can be determined, and the second target resource can be minted for the i-th first sub-account according to the resource distribution share corresponding to the i-th rollup mode. That is, in this implementation manner, the second target resource does not need to be transferred out from the relay sub-account corresponding to the i-th rollup mode and the relay account, but the second target resource corresponding to the corresponding share is minted for the i-th first sub-account.

[0121] Considering that the i-th sub-transaction can fail to be executed, when 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 is verified, so that the i-th sub-transaction and the batch to which it belongs enter an unchangeable state, Rollup Contract in the first blockchain system can perceive that the i-th sub-transaction has entered the unchangeable state. At this time, Rollup Contract can also generate the i-th asset transfer completion event corresponding to the i-th sub-transaction by calling Bridge Contract. The asset transfer completion event may, for example, include the first account, the i-th rollup mode, and the resource distribution share corresponding thereto. Further, when Bridge Contract collects N asset transfer completion events corresponding to N sub-transactions, Bridge Contract can confirm that the N asset transfer completion events match the resource distribution event based on the contents included in the N asset transfer completion events and the resource distribution event, so as to confirm that all the transactions expected to be executed by the first transaction are successfully executed.

[0122] Correspondingly, if Bridge Contract fails to completely collect N asset transfer completion events corresponding to N sub-transactions, it means that part or all of the sub-transactions fail to be successfully executed in the second blockchain system. In this case, the management member of Bridge Contract may, for example, determine the compensation share of the first target resource that needs to be returned from the relay account to the first account according to the resource distribution event and the collected asset transfer completion event, so as to realize the transfer of the first target resource from the relay account to the first account according to the compensation share through a corresponding contract calling transaction or other ways.

[0123] Figure 10FIG. 3 is a flowchart illustrating a third method for managing resources of a blockchain system according to an embodiment of the present disclosure. The method illustrates a process of adding a share of first target resources to a first account of a first user in a first blockchain system, according to a second target resource held by a sub-account of the first user in a second blockchain system, in a case where the second blockchain system supports M folding modes.

[0124] Referring to Figure 10 As shown in FIG. 3, the method can include, but is not limited to, the following steps S1001-S1007.

[0125] In step S1001, the second blockchain system receives a second transaction initiated by the first account, the second transaction indicating a resource transfer-out share and a first folding mode. The first folding mode belongs to M folding modes supported by the second blockchain system.

[0126] The data format of the transaction Tx initiated by the user in the second blockchain system is described above. The From field of the second transaction can include the first account, for example, and the folding mode included in the FR field corresponding to the From field can be the first folding mode. The Data field of the second transaction can include the resource transfer-out share, for example. In addition, the To field of the second transaction and the TR field corresponding thereto can be set according to a preset rule, for example: the To field and the TR field are both 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.

[0127] 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 folding mode according to the first folding mode included in the FR field corresponding to the sender field in the second transaction.

[0128] In step S1003, the second blockchain system executes the second transaction to determine a second sub-account corresponding to the first folding mode and the first account, and transfer the second target resource from the second sub-account to a relay sub-account corresponding to a relay account and belonging to the first folding mode, according to the resource transfer-out share.

[0129] The Sequencer of the second blockchain system can pull multiple transactions from the transaction pool corresponding to the first rollup mode, sort, execute 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 rollup mode included in the second transaction can be used to derive the second sub-account that belongs to the first rollup mode and corresponds 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.

[0130] 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: the To field and the TR field are both 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 rollup mode. For example, the Sequencer can generate a resource extraction event based on the special structure described above when executing the second transaction, which includes the first account and the resource transfer-out 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 generate the third transaction according to the resource extraction event.

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

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

[0133] Correspondingly, in step S1007, the first blockchain system executes the first method function in the Rollup Contract according to the third transaction, so as to: according to the resource transfer-out share, transfer the first target resource from the relay account to the first account.

[0134] When the third transaction includes the aforementioned batch number and transaction number, the first blockchain system, when executing the first method function in the Rollup Contract based on the third transaction, can specifically achieve the following: First, based on the batch number of the third batch included in the third transaction, determine whether the third batch has entered an immutable state. If so, query whether the third batch includes a second transaction corresponding to the third transaction based on 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 share. It can be understood that matching the second and third transactions means that both the second and third transactions include the same first account and resource transfer share.

[0135] When the first blockchain system executes the third transaction, the third batch to which the second transaction belongs may not have entered an immutable state. In this case, when the first blockchain system executes the first method function in the Rollup Contract based on the third transaction, it can set a trigger condition in the Rollup Contract based on 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 the submission of proof data of the third batch to which the second transaction belongs to the Rollup Contract, and the proof data is verified, causing the third batch to which the second transaction belongs to enter an immutable state, the trigger condition set in the Rollup Contract is satisfied. This triggers the first method function to continue querying whether the third batch includes the second transaction corresponding to the third transaction based on the transaction number included in the third transaction. If so, the first target resource is transferred from the relay account to the first account according to the resource transfer share.

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

[0137] Figure 11 This is the fourth flowchart of a resource management method for a blockchain system provided in the embodiments of this specification. The method exemplarily describes the process of terminating a rollup mode (denoted as the second rollup mode) in a first blockchain system and a second blockchain system.

[0138] Reference Figure 11 As shown, the method may include, but is not limited to, the following steps S1101 to S1107.

[0139] Step S1101: The first blockchain system receives the fifth transaction, which is used to call the third method function in the Rollup Contract. The fifth transaction requests the termination of the second rollup mode.

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

[0141] In step S1103, the first blockchain system executes the third method function according to the fifth transaction to generate a rollover termination event and perform a third upgrade operation on the rollover contract and the relay contract according to the registration information of the second rollover mode.

[0142] The third upgrade operation corresponds to the first upgrade operation mentioned above.

[0143] Taking the second rollup mode to be terminated, including TEE-Rollup, as an example. The third upgrade operation on the Rollup Contract may include, but is not limited to, deleting or disabling the TEE verifier method 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 interfaces Deposite() and Withdraw() in the Bridge Contract, so that an account registered in the first blockchain system can no longer add a corresponding share of the second target resource to a sub-account belonging to TEE-Rollup in the second blockchain system by calling the contract interface Deposite(); and preventing a sub-account belonging to TEE-Rollup in the second blockchain system from adding the first target resource to the account corresponding to that sub-account in the first blockchain system based on its share of the second target resource held by using the contract interface Withdraw().

[0144] The rollover termination event can indicate the second rollover mode to be terminated, such as including identification information of the second rollover mode.

[0145] The relay in the second blockchain system, such as the Bridge included in the relay, can listen for the rollover termination event and then perform a fourth upgrade operation on the infrastructure of the second blockchain system according to the third rollover mode indicated by the rollover termination event. This will cause the first blockchain system after the third upgrade operation and the second blockchain system after the fourth upgrade operation to no longer support the use of the second rollover mode for rollover.

[0146] For example, the second blockchain system can perform the following steps S1105 and S1107 based on the rollup registration event.

[0147] At step S1105, the second blockchain system generates a second upgrade transaction via the relay, using the rollup termination event, the second upgrade transaction indicating that the second rollup mode is to be terminated.

[0148] The second upgrade transaction can be a special transaction, which can not be packaged into the batch transaction submitted by the second blockchain system. For example, the Bridge included in the relay can set the From field to the relay account and the To field to Null in the sender field and the receiver field of the first upgrade transaction, so that the Sequencer of the second blockchain system can accurately know that the second upgrade transaction is a special transaction, execute the transaction expected to be executed by the second upgrade transaction and not package it into the batch; the Data field of the second upgrade transaction can include identification information of the second rollup mode.

[0149] At step S1007, the second blockchain system executes the second upgrade transaction via its Sequencer, to implement a fourth upgrade operation on the infrastructure of the second blockchain system according to the identification information of the second rollup mode.

[0150] Taking the TEE-Rollup to be terminated as an example, the shared Bridge of the second blockchain system can send a second upgrade transaction to the Sequencer, the second upgrade transaction including identification information of the TEE-Rollup. When the Sequencer of the second blockchain system executes the second upgrade transaction, the fourth upgrade operation on the infrastructure of the second blockchain system can include but is not limited to: deleting or disabling the transaction pool TEETxpool corresponding to the TEE-Rollup in the receiver; reconfiguring the Sequencer so that the reconfigured Sequencer no longer processes transactions in the TEE Txpool; and deleting or disabling the prover TEE Prover corresponding to the TEE-Rollup in the second blockchain system.

[0151] In one possible implementation, depending on the rollup termination event corresponding to the second rollup mode, the second blockchain system can further perform steps S1109 and S1111 to complete the transfer of the second target resource held by the first target sub-account corresponding to the second rollup mode and any account (denoted as a target account) to the second target sub-account corresponding to the third rollup mode and the target account, the target account being an external account registered in the first blockchain system.

[0152] Step S1109, the second blockchain system generates a sixth transaction according to the rollup termination event through the relay thereof.

[0153] The second upgrade transaction can be a special transaction, which can not be packaged into the batch transaction submitted by the second blockchain system. Illustratively, the Bridge included in the relay can make the Sequencer of the second blockchain system accurately know that the sixth transaction is a special transaction by specially setting the sender field and the receiver field of the sixth transaction, for example, setting 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 rollup mode, and execute the transaction expected to be executed by the sixth transaction and not package it into the batch.

[0154] Step S1111, the second blockchain system executes the sixth transaction through the Sequencer thereof, so as to achieve: transferring the second target resource held by any first target sub-account belonging to the second rollup mode to the second target sub-account belonging to the third rollup mode, the first target sub-account and the second target sub-account corresponding to the same target account registered in the first blockchain system.

[0155] Referring to Figure 7 As shown, continuing the example in the preceding, it is assumed that the terminated second rollup mode is TEE-Rollup, and it is assumed that the third rollup mode includes ZK-Rollup. Then, the second target resource held by the account TEE-A1 can be transferred to the account ZK-A1, and the second target resource held by the account TEE-A2 can be transferred to the account ZK-A2.

[0156] When the second rollup mode is terminated, the transfer of the target resource held by any first target sub-account belonging to the second rollup mode can also be achieved by other ways in addition to the foregoing step S1109 and step 1111. For example, the Bridge included in the relay of the second blockchain system can generate a target transaction for calling a certain preset method function in the Rollup Contract deployed by the first blockchain system, and the first blockchain system executes the preset function according to the target transaction, and according to the current share of the second target resource held by any first target sub-account belonging to the second rollup mode, from the relay account corresponding to the second blockchain system to the target account registered in the first blockchain system.

[0157] Figure 12Figure 5 is a flowchart illustrating a method for resource management of a blockchain system according to an embodiment of the present specification. The method exemplarily describes a process of transferring resources from a first sub-account belonging to a first rollup mode and corresponding to a first account to a second sub-account belonging to a second rollup mode and corresponding to a second account in a second blockchain system supporting the second rollup mode.

[0158] Firstly, in step S1201, the second blockchain system receives a seventh transaction, the From field and the To field of the seventh transaction respectively including the first account and the second account, and the seventh transaction further including a resource transfer share, a first rollup mode corresponding to the From field and a second rollup mode corresponding to the To field.

[0159] Hereinafter, the first rollup mode is exemplarily described as including ZK-Rollup, the second rollup mode is exemplarily described as including TEE-Rollup, the first account is exemplarily described as including account A1, the second account is exemplarily described as including account A2, and the relay account is exemplarily described as including account A, and the resource transfer share is exemplarily described as T.

[0160] The seventh transaction can be initiated by a user 1 holding the account A1 through a client of the second blockchain system.

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

[0162] The second blockchain system not only can receive transactions from its clients, but also can initiate transactions that need to be executed by the second blockchain system through the shared bridge Bridge included in the relay, for example, the Bridge can initiate the foregoing ZK sub-transaction and the TEE sub-transaction, and the like. 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 in the FR field corresponding to the From field in the transaction. For example, for the seventh transaction, the field value in the FR field corresponding to the From field is ZK-Rollup, and the seventh transaction can be added to the corresponding ZKTxpool.

[0163] The M kinds of rollup modes in the second blockchain system can share a batch chain, and the batch chain includes a plurality of batches connected in sequence. The rollup modes included in the FR fields of the plurality of transactions belonging to the same batch need to remain the same. In the batch header of any batch, in addition to including the conventional Prev Hash, Nonce, Batch Num (batch serial number), Tx_Root, State_Root, and Receipt_Root and the like, the rollup mode corresponding to the batch can also be included. Referring to Figure 13 If the batch header of batch 1 includes ZK-Rollup, it means that the FR fields corresponding to the From fields of the plurality of transactions included in batch 1 are all ZK-Rollup; if the batch header of batch 2 includes TEE-Rollup, it means that the FR fields corresponding to the From fields of the plurality of transactions included in batch 2 are all TEE-Rollup.

[0164] It should be noted that when the M kinds of rollup 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, i.e., the Global state root, which is calculated based on the state roots of the M kinds of rollup modes corresponding to the respective state trees, rather than the state root of a sub-state tree corresponding to a certain rollup mode. Correspondingly, the pre-state root and the post-state described below both correspond to the Global state root rather than the state root of a sub-state tree.

[0165] Because the M kinds of rollup modes share the same batch chain, when the Sequencer of the second blockchain system starts to perform the transaction related to the next batch, it needs to first determine the rollup mode corresponding to the next batch to be packaged.

[0166] Correspondingly, the second blockchain system can perform the following step S1203: determining the target rollup mode corresponding to the next batch to be packaged, and in the case that the target rollup mode is the first rollup mode, pulling a plurality of transactions from the transaction pool corresponding to the first rollup mode, sorting and packaging the plurality of transactions, and the plurality of transactions include the seventh transaction.

[0167] The Sequencer of the second blockchain system can determine the target rollup mode corresponding to the next batch to be packaged according to at least one of the following pieces of 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 can count the number of transactions included in each of the M transaction pools at the current time, 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 a transaction pool is not less than the corresponding reference number, the rollup mode corresponding to the transaction pool is taken as a candidate rollup mode, and then the target rollup mode is determined from the candidate rollup modes according to the batch submission time interval and / or the number of transactions in the transaction pool.

[0168] Hereinafter, an example is described with the seventh transaction being packaged into batch k (i.e., the first batch).

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

[0170] When the multiple transactions in batch k include the seventh transaction, the second blockchain system performs step S1205.

[0171] In step S1205, the seventh transaction is executed to achieve: transferring the second target resource from the first sub-account belonging to the first rollup mode and corresponding to the first account to the first relay sub-account belonging to the first rollup mode and corresponding to the relay account according to the resource transfer share, and generating a cross-mode transfer event.

[0172] In the process of executing the seventh transaction by the Sequencer, the Sequencer can first determine the first sub-account belonging to the first rollup mode and corresponding to the first account, and determine the first relay sub-account belonging to the first rollup mode and corresponding to the relay account according to the pre-configured relay account. For example, the Sequencer can determine the first sub-account and the first relay sub-account through the derivation calculation or the mapping relationship table described above, and details are not described herein.

[0173] In the process of executing the seventh transaction, the sequencer can determine that the first sub-account belonging to the ZK-Rollup and corresponding to the account A1 is the account ZK-A1, and that the first relay sub-account belonging to the ZK-Rollup and corresponding to the account A is the account ZK-AA, for example, and then can transfer the second target resource from the account ZK-A1 to the account ZK-AA according to the resource transfer share T.

[0174] In the foregoing cross-mode transfer event, the Data field can 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.

[0175] After the sequencer completes execution of the plurality of transactions belonging to the batch k, the shared bridge Bridge included in the relay of the second blockchain system can listen to the cross-mode transfer event, and then can perform the following step S1207.

[0176] In step S1207, according to the cross-mode transfer event, an eighth transaction is generated, the sender field and the receiver field of the eighth transaction include the relay account and the second account respectively, and the eighth transaction further includes the resource transfer share and the second rollup mode.

[0177] Continuing with the foregoing example, in the eighth transaction: the From field can include the account A, the To field can include the account A2, the FR field corresponding to the From field can include the TEE-Rollup, the TR field corresponding to the To field can include the TEE-Rollup, and the Data field can include the resource transfer share, for example. Correspondingly, because the field value under the FR field corresponding to the From field in the eighth transaction is the TEE-Rollup, the eighth transaction will be added to the corresponding TEE Txpool.

[0178] After the sequencer completes execution of the plurality of transactions belonging to the batch k, referring to the foregoing, the sequencer can obtain the rollup data such as the pre-state root (Pre State Root), the post-state root (Post State Root), the batch number k, and the transaction sequence formed by the plurality of transactions corresponding to the 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 plurality of transactions in the batch k are executed; the Post State Root refers to the state root corresponding to the world state of the second blockchain system after the plurality of transactions in the batch k are executed.

[0179] Correspondingly, the second blockchain system can then perform step S1209, sending a ninth transaction to the first blockchain system, the ninth transaction being used to invoke a fourth method function in the Rollup Contract deployed by the first blockchain system, and the ninth transaction including the rollup data of the first batch to which the seventh transaction belongs.

[0180] The fourth method function in the Rollup Contract is, for example, the commitBatch() contract interface described above.

[0181] Correspondingly, the first blockchain system can perform step S1211, executing the fourth method function in the Rollup Contract according to the ninth transaction, to process the rollup data of the first batch to which the seventh transaction belongs.

[0182] Looking back, the rollup data of the first batch, batch k, can include the pre-state root, the post-state root, the batch number k, and a transaction sequence composed of multiple transactions belonging to batch k. The process of processing the rollup data of batch k can include: verifying whether the Pre State Root in the ninth transaction is equal to the Current State Root stored in the Rollup Contract, if so, storing the transaction sequence in the ninth transaction in the calldata, and updating the Current State Root in the contract storage to the Post State Root; and setting the position index of the transaction sequence in the calldata according to the batch number k.

[0183] Returning to the second blockchain system, after completing the submission of the first batch, batch k, through the foregoing step S1209, the Sequencer needs to determine the target rollup mode corresponding to the next batch to be packaged, similar to the foregoing step S1203.

[0184] Correspondingly, the second blockchain system can perform step S1213, determining the target rollup mode corresponding to the next batch to be packaged, and in the case that the target rollup mode is the second rollup mode, pulling multiple transactions from the transaction pool corresponding to the second rollup mode, sorting and packaging the multiple transactions, the multiple transactions including the eighth transaction.

[0185] The target rollup mode corresponding to the next batch of batch k, i.e., batch k+1, can not be the second rollup mode, and even if the target rollup mode corresponding to batch k+1, the eighth transaction can not be packaged into batch k+1 due to the large number of transactions in the transaction pool corresponding to the second rollup mode. Therefore, the actual batch to which the eighth transaction belongs can not be batch k+1, and it can actually be packaged into a second batch with a batch number greater than k, but for the convenience of description, the second batch is still exemplarily described as batch k+1 in the embodiments of the present specification.

[0186] When the eighth transaction is packaged into the second batch, e.g., batch k+1, by the Sequencer, the second blockchain system can then perform the following step S1215 to execute the eighth transaction, so as to achieve: transferring the second target resource from the second relay sub-account corresponding to the relay account and belonging to the second rollup mode to the second sub-account corresponding to the second account and belonging to the second rollup mode according to the resource transfer share.

[0187] In the process of executing the eighth transaction by the Sequencer, the second sub-account corresponding to the second account and belonging to the second rollup mode and the second relay sub-account corresponding to the relay account and belonging to the second rollup mode can be determined first. The Sequencer determines the second sub-account and the second relay sub-account in the same manner as determining the first sub-account and the first relay sub-account, for example, including the derivation calculation or the mapping relationship table described above, which will not be described here.

[0188] In the process of executing the eighth transaction by the Sequencer, for example, after determining that the second sub-account corresponding to account A2 and belonging to TEE-Rollup is account TEE-A2 and the second relay sub-account corresponding to account A and belonging to TEE-Rollup 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.

[0189] After the sequencer completes execution of the plurality of transactions belonging to the second batch, for example, batch k+1, the sequencer can obtain the pre-state root, the post-state root, the batch number k+1, and the transaction sequence of the plurality of transactions corresponding to batch k+1, and other rollup data. Similar to batch k, the pre-state root here refers to the state root corresponding to the world state of the second blockchain system before the plurality of transactions in batch k+1 are executed; the post-state root refers to the state root corresponding to the world state of the second blockchain system after the plurality of transactions in batch k+1 are executed. Then, the following step S1217 is performed to complete submission of the second batch.

[0190] In step S1217, the second blockchain system sends an eleventh transaction to the first blockchain system, where the eleventh transaction is used to call the fourth method function in the RollupContract deployed by the first blockchain system, and the eleventh transaction includes the rollup data of the second batch to which the eighth transaction belongs.

[0191] Correspondingly, the first blockchain system can perform step S1219 to execute the fourth method function in the RollupContract according to the eleventh transaction, so as to process the rollup data of the second batch to which the eighth transaction belongs.

[0192] The process of processing the rollup data of the second batch is similar to processing the rollup data of the first batch, and is not repeated here.

[0193] In the foregoing method embodiment, because the M rollup modes correspond to the same batch chain sequentially connected by a plurality of batches, the batches submitted later are bound by the state root of the world state. If the batches submitted earlier and located relatively in front are rolled back due to some reason, the batches submitted later and located relatively in back must be rolled back, so there is no need to wait until the batches submitted earlier enter an unchangeable state before continuing to submit new batches in the batch chain.

[0194] 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 does not need to wait for the first batch to enter an unchangeable state, but can continue to execute the eighth transaction corresponding to the seventh transaction in a second batch located after the first batch, and then complete the resource transfer transaction expected to be completed by the seventh transaction, which is beneficial to completing the transfer in the second blockchain system according to the user's expectation quickly.

[0195] However, referring to the exemplary description of the ZK-Rollup mechanism and the TEE-Rollup mechanism, after the second blockchain system completes the submission of the corresponding batch to the first blockchain system, the second blockchain system also needs to submit the proof data corresponding to the batch to the first blockchain system. Moreover, the following situation may also occur: after the first batch to which the eighth transaction belongs has entered an unchangeable state, the eighth transaction fails to be successfully executed due to some reasons, or even fails to successfully generate the eighth transaction corresponding to the seventh transaction due to some reasons, which may cause the resource transfer transaction expected to be completed by the seventh transaction not to be accurately completed.

[0196] In view of this, on the basis of the foregoing steps S1201-S1219, the first blockchain system and the second blockchain system can also jointly perform the following method steps S1221-S1227.

[0197] 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, and the tenth transaction is used to call the fifth method function in the Rollup Contract deployed by the first blockchain system. The first proof data corresponding to the first batch and the first rollup mode are included in the tenth transaction.

[0198] The data structure of the first proof data can refer to the foregoing description of the Rollup mechanism, which will not be described here again.

[0199] In step S1223, the first blockchain system executes the fifth method function according to the tenth transaction, so as to achieve the following: according to the verification method corresponding to the first rollup mode, the first proof data is used to verify whether the multiple transactions in the first batch are correctly executed, and in the case of passing the verification, the asset transfer event corresponding to the seventh transaction is generated.

[0200] When the first rollup mode includes the ZK-Rollup mode, the fifth method function in the Rollup Contract may, for example, call the verification method ZKverifier corresponding to the ZK-Rollup according to the ZK-Rollup included in the tenth transaction, process the first proof data included in the tenth transaction through the ZK verifier, and complete the verification of whether the multiple transactions in the first batch are correctly executed. If the verification passes, the first batch enters an unchangeable state; in addition, the fifth method function itself or through the contract internal call Bridge Contract, the asset transfer event is generated for some specific data format transaction, and the asset transfer completion event is generated for some specific data format transaction.

[0201] In an exemplary rule, if the account under the From field in a transaction is not a relay account and the roll-up modes included in the FR field and the TR field are different, an asset-to-be-transferred event can be generated for the transaction; if the account under the From field in a transaction is a relay account, an asset-transferred event can be generated for the transaction. Based on the exemplary rule and the data structure of the seventh transaction, it can be understood that an asset-to-be-transferred event can be generated for the seventh transaction.

[0202] The Bridge Contract can also maintain a set of events that are allowed to be consumed. For an asset-to-be-transferred event, an in-contract call can be made through the fifth method function, or the Bridge Contract can enable a corresponding event listening mechanism to ultimately add the asset-to-be-transferred event to the set of events maintained by the Bridge Contract.

[0203] In a typical example, as shown in Figure 14 For an asset-to-be-transferred event corresponding to a transaction, the field value E1 in the Topic field indicates that the event belongs to an asset-to-be-transferred event. In addition, the asset-to-be-transferred event can include the following subfields in the Data field: the subfield From for storing the account under the From field in the corresponding transaction; the subfield To for storing the account under the To field in the corresponding transaction; the subfield FR for storing the roll-up mode under the FR field in the corresponding transaction; the subfield TR for storing the roll-up mode under the TR field in the corresponding transaction; and the subfield FE for storing the resource transfer share included in the Data field in the corresponding transaction.

[0204] As shown in Figure 14 For an asset-transferred event corresponding to a transaction, the field value E2 in the Topic field indicates that the event belongs to an asset-transferred event. In addition, the asset-transferred event can include the following subfields in the Data field: the subfield To for storing the account under the To field in the corresponding transaction; the subfield TR for storing the roll-up mode under the TR field in the corresponding transaction; and the subfield FE for storing the resource transfer share included in the Data field in the corresponding transaction.

[0205] The asset-transferred event is used to support the Bridge Contract to match it with an asset-to-be-transferred event in the set of events, so as to confirm that the asset transfer transaction expected to be executed by the transaction corresponding to the asset-to-be-transferred event has been completed. For example, please continue to refer to Figure 14The asset transfer completion event and the asset to be transferred event shown in the figure are matched by matching the Data fields of the two events. If the account under the To field, the volume folding mode under the TR field, and the resource transfer share under the FE field included in the respective Data fields of the two events are the same, the matching is successful.

[0206] In step S1225, the second blockchain system sends a twelfth transaction to the first blockchain system through a second prover corresponding to the second volume folding mode. The twelfth transaction is used to call a fifth method function in the Rollup Contract deployed by the first blockchain system. The twelfth transaction includes second proof data corresponding to the second volume folding mode and the second batch.

[0207] The data structure of the second proof data can be referred to the description of the Rollup mechanism in the foregoing text, which will not be described here again.

[0208] In step S1227, the first blockchain system executes the fifth method function according to the twelfth transaction, which realizes that the first proof data is used to verify whether the multiple transactions in the first batch are correctly executed according to a verification method corresponding to the second volume folding mode, and generates an asset transfer completion event corresponding to the eighth transaction if the verification is passed.

[0209] When the second volume folding mode includes a TEE-Rollup mode, the fifth method function in the Rollup Contract may, for example, call a verification method TEE verifier corresponding to the TEE-Rollup in the contract according to the TEE-Rollup included in the twelfth transaction, process the second proof data included in the twelfth transaction through the TEE verifier, and 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 through the in-contract calling of the Bridge Contract, the asset to be transferred event is generated for some specific data format transaction, and the asset transfer completion event is generated for some specific data format transaction.

[0210] Referring to the content in the foregoing step S1223, the asset transfer completion event generated by the eighth transaction can be used to consume the asset to be transferred event corresponding to the seventh transaction in the event set maintained by the Bridge Contract, so as to confirm 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 Figure 14 The asset to be transferred event and the asset transfer completion event shown in the figure will be successfully matched.

[0211] In the case that the seventh transaction is successfully executed and the eighth transaction is not successfully executed, the asset 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 return the corresponding second target resource to the sub-account belonging to the first stack mode and corresponding to the first account based on the asset transfer event corresponding to the seventh transaction.

[0212] In the technical solutions described in the foregoing method steps S1201-S1227, the process of transferring resources from the first sub-account belonging to the first stack mode and corresponding to the first account to the second sub-account belonging to the second stack mode (different from the first stack mode) and corresponding to the second account is mainly described. However, in some technical scenarios, the FR field and the TR field of some transactions may include the same stack mode, and in this case, the transaction expected to be completed can be completed by other means.

[0213] In a possible implementation, the second blockchain system can receive a 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 further includes a resource transfer share, a first stack mode corresponding to the sender field, and a first stack mode corresponding to the receiver field; in this case, when the second blockchain system packages the thirteenth transaction into a batch corresponding to the first stack mode, for example, the fourth batch, the second target resource can be directly transferred from the first sub-account belonging to the first stack mode and corresponding to the first account to the third sub-account belonging to the first stack mode and corresponding to the second account according to the resource transfer share when the thirteenth transaction is executed.

[0214] Correspondingly, when the fourth batch is submitted to the first blockchain system by the fourth method function, and when the proof data of the fourth batch is submitted to the first blockchain system by the fifth method function, the corresponding asset transfer event does not need to be generated.

[0215] Based on the same idea as the foregoing method embodiments, the second blockchain system in the embodiments of the present specification also supports M folding modes, and the second blockchain system includes a batch chain, and the batch chain includes a plurality of batches connected in sequence. The second blockchain system includes: a receiver configured to receive a seventh transaction, the sender field and the receiver field of the seventh transaction including a first account and a second account respectively, and the seventh transaction further including a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; an orderer configured to package the seventh transaction into a first batch in the batch chain, the first batch corresponding to the first folding mode, execute the seventh transaction, and achieve: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first folding mode and corresponding to the first account to a first relay sub-account belonging to the first folding mode and corresponding to a relay account, and generating a cross-mode transfer event; a shared bridge configured to generate an eighth transaction according to the cross-mode transfer event, the sender field and the receiver field of the eighth transaction including the relay account and the second account respectively, and the eighth transaction further including the resource transfer share and the second folding mode; and the orderer configured to package the second transaction into a second batch in the batch chain, the second batch corresponding to the second folding mode, execute the eighth transaction, and achieve: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second folding mode and corresponding to the relay account to a second sub-account belonging to the second folding mode and corresponding to the second account.

[0216] The embodiments of the present specification also provide a computer-readable storage medium having computer programs / instructions stored thereon, which, when executed in a computer, cause the computer to perform the method steps executed by the first blockchain system or the second blockchain system in the foregoing various embodiments.

[0217] The embodiments of the present specification also provide a computing device including a memory and a processor, the memory having computer programs / instructions stored therein, and the processor implementing the method steps executed by the first blockchain system or the second blockchain system in the foregoing various embodiments when executing the computer programs / instructions.

[0218] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0219] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code form, the controller can perfectly well be implemented to perform the same functions in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. by means of logical programming of the method steps. Such a controller can thus be considered a hardware component, and the means comprised therein for performing the various functions can also be considered structures within the hardware component. Alternatively, or even, the means for performing the various functions can be considered both software modules implementing the method and structures within the hardware component.

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

[0221] Although the method operations of the embodiments of the present disclosure are described in a particular, sequential order, one or more of the method operations can be omitted, or the method operations can be performed in an order other than the described order. Additionally, one or more of the method operations can be performed concurrently, or with partial concurrence. Furthermore, one or more of the method operations can be performed by different entities, or over different time periods. The term "including" as used herein is intended to mean "comprising," such that the process, method, article, or apparatus that includes elements in addition to those specified. As used in this description, the term "coupled" means a direct or indirect connection, which can be physical or logical. The term "coupled" does not relate to a direct connection or wiring.

[0222] For the sake of description, the above-described apparatus is described as various modules to describe the apparatus in functional groups. Of course, when implementing one or more embodiments of the present disclosure, the functions of the modules can be implemented in one or more software and / or hardware, or the modules that implement the same function can be implemented by a combination of a plurality of sub-modules or sub-units. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed units can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0223] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The term "coupled" means a direct or indirect connection, which can be physical or logical. Figure 1 The term "coupled" means a direct or indirect connection, which can be physical or logical.

[0224] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0225] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

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

[0227] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0228] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

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

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

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

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

Claims

1. A resource management method for a blockchain system, the method being executed by a second blockchain system supporting M rollover modes, the second blockchain system including a transaction batch chain, the batch chain comprising multiple sequentially connected batches, the method comprising: The seventh transaction is received. The sender field and receiver field of the seventh transaction include a first account and a second account, respectively. The seventh transaction also includes a resource transfer share, a first rollover mode corresponding to the sender field, and a second rollover mode corresponding to the receiver field. The seventh transaction is packaged into the first batch in the batch chain, the first batch corresponds to the first rollover mode, and the seventh 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 rollover mode and corresponding to the first account to the first relay sub-account belonging to the first rollover mode and corresponding to the relay account, and a cross-mode transfer event is generated. Based on the cross-mode transfer event, an eighth transaction is generated. The sender field and receiver field of the eighth transaction include the relay account and the second account, respectively. The eighth transaction also includes the resource transfer share and the second rollover mode. The eighth transaction is packaged into the second batch in the batch chain, the second batch corresponding to the second rollover mode. The eighth transaction is executed to achieve the following: according to the resource transfer share, the second target resource is transferred from the second relay sub-account belonging to the second rollover mode and corresponding to the relay account to the second sub-account belonging to the second rollover mode and corresponding to the second account.

2. The method according to claim 1, wherein the batch chain includes the batch headers of the plurality of batches, and the batch header includes the rollover mode corresponding to its respective batch.

3. The method according to claim 1, wherein the batch number of the first batch in the batch chain is less than the batch number of the second batch in the batch chain; for the sender field of the multiple transactions included in the first batch, the corresponding rollover mode is the first rollover mode; for the sender field of the multiple transactions included in the second batch, the corresponding rollover mode is the second rollover mode.

4. The method according to claim 1, wherein the receiver of the second blockchain system includes M transaction pools corresponding to the M cascading modes; the seventh transaction is cached in the transaction pool corresponding to the first cascading mode before execution; and the eighth transaction is cached in the transaction pool corresponding to the second cascading mode before execution.

5. The method according to claim 4, further comprising: Before packaging the seventh transaction into the first batch in the batch chain, the target stacking mode corresponding to the first batch to be packaged is determined. If the target stacking mode is the first stacking mode, multiple transactions are pulled from the transaction pool corresponding to the first stacking mode, the multiple transactions are sorted and packaged, and the multiple transactions include the seventh transaction. After the execution of the first batch is completed, a ninth transaction is sent to the first blockchain system. The ninth transaction is used to call the fourth method function in the rollup contract deployed by the first blockchain system. The ninth transaction includes the rollup data of the first batch, so that the first blockchain system can process the rollup data of the first batch.

6. The method according to claim 5, wherein the second blockchain system further includes a first proof device corresponding to the first rollover mode; wherein, The method further includes: The first prover sends a tenth transaction to the first blockchain system. The tenth transaction is used to call the fifth method function in the roll-over contract deployed by the first blockchain system. The tenth transaction includes the first proof data corresponding to the first roll-over mode and the first batch. It is used 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-over mode and the first proof data. If the verification is successful, it generates an asset transfer event corresponding to the seventh transaction.

7. The method according to claim 4, further comprising: Before packaging the eighth transaction into the second batch in the batch chain, the target stacking mode corresponding to the second batch to be packaged is determined. If the target stacking mode is the second stacking mode, multiple transactions are pulled from the transaction pool corresponding to the second stacking mode, sorted and packaged, and the multiple transactions include the eighth transaction. After the execution of the second batch is completed, an eleventh transaction is sent to the first blockchain system. The eleventh transaction is used to call the fourth method function in the rollup contract deployed by the first blockchain system. The eleventh transaction includes the rollup data of the second batch, so that the first blockchain system can process the rollup data of the second batch.

8. The method according to claim 7, wherein the second blockchain system further includes a second prover corresponding to the second rollover mode; wherein, The method further includes: The second proof send a twelfth transaction to the first blockchain system. The twelfth transaction is used to call the fifth method function in the roll-over contract deployed by the first blockchain system. The twelfth transaction includes the second roll-over mode and the second proof data corresponding to the second batch. It is used to support the first blockchain system to verify whether multiple transactions in the second batch are correctly executed according to the verification method corresponding to the second roll-over mode and the second proof data. If the verification is successful, an asset transfer completion event corresponding to the eighth transaction is generated.

9. The method according to claim 7, wherein determining the target rollover mode corresponding to the second batch to be packaged includes determining the target rollover mode corresponding to the second batch to be packaged based on at least one of the following: the batch submission time interval corresponding to each of the M rollover modes, the reference number of transactions required to be included in the batch corresponding to each of the M rollover modes, and the number of transactions cached by each of the M transaction pools.

10. The method according to any one of claims 1-9, further comprising: Resource distribution events are obtained from a first blockchain system, which is equipped with a relay contract. The resource distribution events are generated by the first blockchain system executing the relay contract according to a first transaction. The first transaction is initiated by the first account and indicates N rollover modes out of the M rollover modes, as well as the resource distribution share corresponding to each of the N rollover modes. Based on the resource distribution event, N sub-transactions are generated, and any i-th sub-transaction includes the first account, the i-th rollup mode among the N rollup modes, and its corresponding resource distribution share. Execute the i-th sub-transaction to achieve: deposit the second target resource into the i-th first sub-account that belongs to the i-th cascading mode and corresponds to the first account, according to the resource distribution share corresponding to the i-th cascading mode.

11. The method according to claim 10, wherein the i-th first sub-account is obtained by derivation calculation based on the first account and the i-th rollover mode.

12. The method according to claim 10, wherein the state tree corresponding to the world state of the second blockchain system includes M sub-state trees corresponding to the M rollover modes; wherein, The execution of the i-th sub-transaction also includes: querying whether the i-th first sub-account exists in the sub-state tree corresponding to the i-th rollover mode; if not, registering the i-th first sub-account in the sub-state tree corresponding to the i-th rollover mode.

13. The method according to claim 10, further comprising: Receive a second transaction, wherein the sender field of the second transaction includes the first account, and the second transaction includes the resource transfer share and the first rollover mode corresponding to the first account; Execute the second transaction to achieve the following: Based on the resource transfer-out share, transfer out the second target resource from the second sub-account belonging to the first stacked mode and corresponding to the first account; A third transaction is sent to the first blockchain system. The third transaction is used to call the first method function in the rollover contract deployed by the first blockchain system. The third transaction includes the first account and the resource transfer share, so that the first blockchain system transfers the first target resource to the first account according to the resource transfer share.

14. The method according to claim 13, wherein the third transaction further includes the batch number of the third batch to which the second transaction belongs in the second blockchain system, and the 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 in transferring the first target resource to the first account according to the resource transfer 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.

15. The method according to any one of claims 1-9, further comprising: The thirteenth transaction is received. The sender field and receiver field of the thirteenth transaction include a first account and a second account, respectively. The thirteenth transaction also includes a resource transfer share, a first rollover mode corresponding to the sender field, and a first rollover mode corresponding to the receiver field. The thirteenth transaction is packaged into the fourth batch in the batch chain, and the fourth batch corresponds to the first stacked mode. The thirteenth transaction is executed to achieve the following: according to the resource transfer share, the second target resource is transferred from the first sub-account belonging to the first stacked mode and corresponding to the first account to the third sub-account belonging to the first stacked mode and corresponding to the second account.

16. A second blockchain system, the second blockchain system supporting M rollover modes, the second blockchain system including a transaction batch chain, the batch chain including multiple sequentially connected batches, including: The receiver is 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 rollover mode corresponding to the sender field and a second rollover mode corresponding to the receiver field; The sorter is configured to package the seventh transaction into the first batch in the batch chain, the first batch corresponding to the first rollover mode, and execute the seventh transaction to achieve: according to the resource transfer share, the second target resource is transferred from the first sub-account belonging to the first rollover mode and corresponding to the first account to the first relay sub-account belonging to the first rollover mode and corresponding to the relay account, and a cross-mode transfer event is generated. The shared bridge is configured to generate an eighth transaction based on the cross-mode transfer event. The sender field and receiver field of the eighth transaction include the relay account and the second account, respectively. The eighth transaction also includes the resource transfer share and the second rollover mode. The sorter is configured to package the eighth transaction into a second batch in the batch chain, the second batch corresponding to the second rollover mode, and execute the eighth transaction to achieve: according to the resource transfer share, the second target resource is transferred from the second relay sub-account belonging to the second rollover mode and corresponding to the relay account to the second sub-account belonging to the second rollover mode and corresponding to the second account.

Images