Resource management method for blockchain system, blockchain node, and blockchain system

Abstract

A method performed by a second blockchain system located in Layer2, comprising: by executing a seventh transaction received by the second blockchain system, on the basis of a resource transfer share, transferring a target resource from a first sub-account which belongs to a first rollup mode and corresponds to a first account to a first relay sub-account which belongs to the first rollup mode and corresponds to a relay account; sending an eighth transaction to a first blockchain system, such that the first blockchain system processes rollup data of a first batch to which the seventh transaction belongs; sending a ninth transaction to the first blockchain system, such that the first blockchain system verifies whether a plurality of transactions in the first batch are correctly executed, and under the condition that the verification is passed, generating an asset-transfer-pending event corresponding to the seventh transaction; and on the basis of the asset-transfer-pending event, generating and executing a tenth transaction, so as to transfer, on the basis of the resource transfer share, the target resource from a second relay sub-account which belongs to a second rollup mode and corresponds to the relay account to a second sub-account which belongs to the second rollup mode and corresponds to a second account.

Description

Resource management method of blockchain system, blockchain node and blockchain system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on December 29, 2023, with application number 202311866632.1 and application name “Resource management method, blockchain node and blockchain system of blockchain system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a resource management method, blockchain node, and blockchain system of a blockchain system. Background Art

[0003] The blockchain system is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptographically guaranteed to be tamper-proof and unforgeable. Due to its decentralized, tamper-proof, and autonomous nature, blockchain systems are gaining increasing attention and application.

[0004] Summary of the Invention

[0005] The purpose of the present invention is to provide a resource management method, blockchain node and blockchain system for a blockchain system.

[0006] In a first aspect, a management method for a blockchain system is provided, the method being executed by a second blockchain system, the second blockchain system supporting M rollup modes, the method comprising: receiving a seventh transaction, the sender field and the receiver field of the seventh transaction respectively including a first account and a second account, 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; executing the seventh transaction to: 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 the relay account according to the resource transfer share; and sending an eighth transaction to the first blockchain system for invoking the first block The fourth method function in the roll-up contract deployed by the chain system causes the first blockchain system to process the roll-up data of the first packaged transaction batch to which the seventh transaction belongs; a ninth transaction is sent to the first blockchain system to call the fifth method function in the roll-up contract, so that the first blockchain system generates an asset pending transfer event corresponding to the seventh transaction after verifying that multiple transactions in the first batch have been correctly executed; a tenth transaction is generated based on the asset pending transfer event corresponding to the seventh transaction, and the tenth transaction is executed, thereby achieving: according to the resource transfer share, the second relay sub-account belonging to the second roll-up model and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second roll-up model and corresponding to the second account.

[0007] In a second aspect, a resource management method for a blockchain system is provided, which is executed by a first blockchain system, wherein a roll-up contract is deployed in the first blockchain system, and the roll-up contract includes a fourth method function and a fifth method function. The method includes: receiving an eighth transaction from a second blockchain system, the eighth transaction being used to call the fourth method function, the eighth transaction including roll-up data of a first packaged transaction batch to which a seventh transaction belongs, the sender field and the receiver field of the seventh transaction respectively including a first account and a second account, the seventh transaction also including a resource transfer share, a first roll-up mode corresponding to the sender field, and a second roll-up mode corresponding to the receiver field, the eighth transaction being implemented by the second blockchain system by executing the seventh transaction, and being initiated after the second target resource is transferred from a first sub-account belonging to the first roll-up mode and corresponding to the first account to a first relay sub-account belonging to the first roll-up mode and corresponding to the relay account according to the resource transfer share; The eighth transaction executes the fourth method function to process the rolled data of the first batch; receives a ninth transaction from the second blockchain system, the ninth transaction is used to call the fifth method function, and the ninth transaction includes the first roll-up mode and the first proof data corresponding to the first batch; executes the fifth method function according to the ninth transaction to implement: according to the verification method corresponding to the first roll-up mode, using the proof data corresponding to the first batch, verifying whether the multiple transactions in the first batch are correctly executed, and generating an asset transfer event corresponding to the seventh transaction if the verification passes; wherein the asset transfer event is used to support the second blockchain system to generate the tenth transaction, and through the execution of the tenth transaction, implement: according to the resource transfer share, the second relay sub-account belonging to the second roll-up mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second roll-up model and corresponding to the second account.

[0008] According to a third aspect, a second blockchain system is provided, comprising: a receiver configured to receive a seventh transaction, wherein the sender field and the receiver field of the seventh transaction include a first account and a second account, respectively, and the seventh transaction further includes a resource transfer share, a first roll-up mode corresponding to the sender field, and a second roll-up mode corresponding to the receiver field; a sorter configured to execute the seventh transaction to implement: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first roll-up mode and corresponding to the first account to a first relay sub-account belonging to the first roll-up mode and corresponding to the relay account; and a relayer configured to send an eighth transaction to the first blockchain system for calling a fourth method in the roll-up contract deployed by the first blockchain system. function, causing the first blockchain system to process the rolled data of the first packaged transaction batch to which the seventh transaction belongs; and sending a ninth transaction to the first blockchain system for calling the fifth method function in the rolled contract, so that the first blockchain system generates an asset pending transfer event corresponding to the seventh transaction after verifying that multiple transactions in the first batch have been correctly executed; the sequencer is configured to generate a tenth transaction based on the asset pending transfer event corresponding to the seventh transaction, and execute the tenth transaction to achieve: according to the resource transfer share, the second relay sub-account belonging to the second rolled-up model and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second rolled-up model and corresponding to the second account.

[0009] In a fourth aspect, a blockchain node in a first blockchain system is provided, wherein a roll-up contract is deployed in the first blockchain system, wherein the roll-up contract includes a fourth method function and a fifth method function, and the blockchain node includes: a transaction receiving unit, configured to receive an eighth transaction from a second blockchain system, wherein the eighth transaction is used to call the fourth method function, wherein the eighth transaction includes roll-up data of a first packaged transaction batch to which the seventh transaction belongs, 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 roll-up mode corresponding to the sender field, and a second roll-up mode corresponding to the receiver field, wherein the eighth transaction is implemented by executing the seventh transaction in the second blockchain system, and is initiated after the second target resource is transferred from the first sub-account belonging to the first roll-up mode and corresponding to the first account to the first relay sub-account belonging to the first roll-up mode and corresponding to the relay account according to the resource transfer share; and a transaction execution unit, configured to execute the transaction according to the eighth transaction. The fourth method function processes the rolled-up data of the first batch; the transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction being used to call the fifth method function, the ninth transaction including the first proof data corresponding to the first rolling mode and the first batch; the transaction executing unit is further configured to execute the fifth method function according to the ninth transaction to implement: verifying whether the multiple transactions in the first batch are correctly executed according to the verification method corresponding to the first rolling mode and using the proof data corresponding to the first batch, and generating an asset transfer event corresponding to the seventh transaction if the verification passes; wherein the asset transfer event is used to support the second blockchain system in generating a tenth transaction, and by executing the tenth transaction, implement: transferring the second target resource from the second relay sub-account belonging to the second rolling mode and corresponding to the relay account to the second sub-account belonging to the second rolling model and corresponding to the second account according to the resource transfer share.

[0010] In a fifth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first or second aspect is implemented.

[0011] In a sixth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method described in the first or second aspect.

[0012] In the technical solutions provided by the embodiments of this specification, because the M convolution modes correspond to M different batch chains, the second blockchain system can efficiently submit batches belonging to the M batch chains through parallel technology. Furthermore, the second blockchain system will only generate and execute the tenth transaction based on the pending asset transfer event corresponding to the seventh transaction after the first batch belonging to the seventh transaction has entered an unchangeable state, thereby completing the resource transfer transaction intended by the seventh transaction. The second blockchain system will not roll back the second batch belonging to the tenth transaction due to the failure of the first batch belonging to the seventh transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0018] FIG5 is a schematic diagram of a process of registering a Rollup mode in one embodiment;

[0019] FIG6 is a flowchart of a resource method of a blockchain system provided in an embodiment of this specification;

[0020] FIG7 is a schematic diagram of Layer 1 and Layer 2 collaborating to implement resource transfer in one embodiment;

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

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

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

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

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

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

[0027] FIG14 is a schematic diagram of an event relationship provided in an embodiment of this specification. DETAILED DESCRIPTION

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

[0029] Distributed systems face the classic CAP theorem: consistency, availability, and partition tolerance. The three cannot be achieved simultaneously, known as the "impossible triangle." Blockchain systems also face an impossible triangle: efficiency, decentralization, and security. While this "impossible triangle" for blockchain systems hasn't been definitively theoretically demonstrated, it serves as a summary of existing blockchain systems. Efficiency, decentralization, and security are defined as follows: Efficiency refers to the number of transactions processed per second (TPS); decentralization refers to a sufficiently low threshold for participating nodes, ensuring a large number of distributed nodes in the system; and security refers to the difficulty of launching attacks on the blockchain system.

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

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

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

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

[0034] The core idea of ​​Rollup is shown in Figure 1. It is to save the credentials that can verify the transaction process on Layer 1, and run the transaction process (computation process) and state storage in Layer 2. The so-called transaction process credentials include a set of pre-transaction states (Pre-State) and post-transaction states (Post-State) as well as the set of transactions. They can be used to verify whether the state transfer corresponding to this set of transactions is correct. They can also be used to restore the execution process of all transactions and the status of all accounts on Layer 2, thereby eliminating the security risks brought by data availability on Layer 2.

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

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

[0037] Storage_root in Ethereum is the hash of the root node of an MPT tree. This MPT tree organizes the storage of the state of the contract account. MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree (Merkel Tree) and Patricia Tree (compressed prefix tree, a more space-saving Trie tree, dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, and then calculates the hash again in pairs until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal tree structure, which is usually referred to as the MPT tree. In fact, the Ethereum block header includes the roots of three MPT trees, namely

[0038] Transaction_Root (abbreviated as Tx_Root), State_Root, and Receipt_Root. State_Root is the hash value of the root of the MPT tree, which comprises the states of all accounts in the current block. This means that the state trie pointing to State_Root is an MPT-style state trie. Part of the values ​​of each node from the root to the leaf nodes of this MPT are sequentially concatenated to form an account address, which serves as the key. The account information stored in the leaf node is the value corresponding to this account address, forming a key-value pair. The key can be sha3(Address), which is the hash value of the account address (the hash algorithm used is, for example, sha3), and the stored value can be rlp(Account), which is the rlp (Recursive Length Prefix) encoding of the account information. Account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. For externally owned accounts (EOA), only nonce and balance are typically present, while the storageRoot and codeHash fields default to empty strings or all zeros. External accounts do not store contracts or state variables generated after contract execution. Contract accounts include Nonce, Balance, Storage root, and CodeHash. Whether external or contract accounts, their account information is generally located in a separate leaf node.

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

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

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

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

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

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

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

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

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

[0048] Layer 2 can use a Merkle tree to organize the states of transactions in Batch 1 before and after their sequential execution. As shown in Figure 3, Layer 2 can organize the transactions in a batch and their associated state changes. For example, the Merkle root obtained by organizing the hash values ​​of transactions in Batch 1 according to the Merkle tree is locked in the batch header. This header is similar to the block header in Layer 1, and this Merkle root is the Tx_Root in the batch header. Similarly, as mentioned above, the Merkle root obtained by organizing all the state values ​​of transactions in Batch 1 before execution according to the Merkle tree can be locked in the batch header, namely the Pre-State Root. The Merkle root obtained by organizing the hash values ​​of all the state values ​​of transactions in Batch 1 after their sequential execution according to the Merkle tree can be locked in the batch header, namely the Post-State Root. 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+1th batch, the Pre State Root in its header is equal to the Post State Root in the header of the Mth batch, as shown by the line connecting these two roots in Figure 3. This forms a chain structure between the batches.

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

[0050] In the OP-Rollup mechanism, Layer 2 can be set up with: receivers, relayers, and sequencers including the transaction pool (Txpool). In the ZK-Rollup and TEE-Rollup mechanisms, Prover can also be set up in Layer 2. For the TEE-Rollup mechanism, Prover can be set up in TEE.

[0051] The following is an example of the OP-Rollup mechanism. As shown in Figure 3, assume that transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24 are collected in TxPool. The Sequencer sorts and packages these transactions according to the timestamps in these transactions. For example, Tx21, Tx22, and Tx23 are packaged into Batch M, and the hash values ​​of these transactions are organized into Merkle to generate a Merkle Root (i.e., transaction root), and the hash value of the Merkle Root is filled in the Tx_Root in the Header of the generated Batch M. It should be noted that when calculating the root of the Merkle tree, generally for cases where the number of transactions is less than 2, multiple copies of the last transaction can be assigned to make up for the 2. n , and thus calculate the root of the 2-fork Merkle tree. As shown in Figure 3, Tx23, which is the last transaction in chronological order, is repeated once to complete 4 transactions, even if the number of transactions reaches 2 2 , and then the root of the 2-fork Merkle tree can be calculated. The Sequencer sorts the transactions according to the timestamps in the transactions and packages Tx21, Tx22, and Tx23 into Batch M+1.

[0052] Before executing transactions Tx21, Tx22, and Tx23 in Batch M, the states include Alice: 50, Bob: 100, Charlie: 150, and David: 200, as described above. The Sequencer can organize these states into a Merkle tree and store the hash of the Merkle tree root as the pre-state root corresponding to Batch M in the Pre-State Root field of the Batch M Header. The Sequencer can then execute transactions Tx21, Tx22, and Tx23 in sequence. The result of executing these three transactions is a new state, as described above: Alice: 20, Bob: 110, Charlie: 170, and David: 200. The Sequencer can organize these updated states into a Merkle tree and store the hash of the Merkle tree root as the post-state root corresponding to Batch M in the Post-State Root field of the Batch M Header.

[0053] Furthermore, the Sequencer can send a Rollup Contract call, Transaction 1, to Layer 1 through the Relayer. This Transaction 1 includes some or all fields from the Batch M header and the compressed transaction sequences Tx21, Tx22, and Tx23. Compression of Tx21, Tx22, and Tx23 significantly reduces the space occupied. The interface within the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas fee) location called calldata. In Ethereum smart contracts, calldata is a special data location used to store input data for function calls. Specifically, calldata is typically stored directly within Ethereum transaction data, which generally saves more gas than other data locations (such as memory and storage). Although this article omits the process of compressing the transaction sequences included in a transaction batch, it should be understood that the transaction sequences included in any transaction batch described below can be either uncompressed or compressed.

[0054] It's worth noting that in an Ethereum transaction, the signature accounts for approximately half of the total transaction size, and its From field can be 0 bytes because it can be recovered from the signature. In Rollup transactions, however, BLS or other aggregation schemes are typically used, compressing the signature of each transaction to approximately 0.5 bytes on average. Accordingly, in Rollup transactions, since the From field cannot be recovered from the aggregated signature, it must be represented separately using 4 bytes.

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

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

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

[0058] Through the above approach, OP-Rollup can execute individual transactions on Layer 2 and bundle dozens, hundreds, or even more Layer 2 transactions into a single batch, while publishing only minimal information to Layer 1. This minimal information includes the compressed Layer 2 transactions described above and the hash values ​​of the state root before and after the batch of transactions is executed. As shown above, this can be sent via a single Layer 1 transaction, such as Transaction 1 in Figure 3. This effectively executes a batch of transactions on Layer 2 at once, but only a single transaction on Layer 1. Furthermore, OP-Rollup does not include any proof. This assumes that the submitted Layer 2 information is free of fraud or malicious intent, hence its "optimistic" name. Despite this assumption, for preventive and deterrent purposes, traders submitting Layer 2 information are still required to stake a portion of Layer 1 assets (typically native on-chain tokens, such as Ethereum's Ether) in the OP-Rollup's RollupContract. For Layer 2 information submitted to Layer 1, although the transactions therein are compressed, as mentioned above, it can still be used to restore the execution process of all transactions on Layer 2 and the status of all accounts, thereby eliminating the security risks brought about by data availability on Layer 2.

[0059] Although OP-Rollup is optimistic, Layer 1 still has a challenge period during which anyone can submit a challenge using a fraud proof. Typical reasons include the challenger proving that a transaction within a batch was incorrectly executed, meaning that the execution of the transaction did not produce the correct state. If a transaction within a batch is proven invalid, the batch is also invalid. The Layer 1 Rollup contract can roll back the Layer 2 batch chain, orphaning the invalid batch and all subsequent batches. If the fraud proof is successful, a portion of the security deposit is paid to the challenger, and the remainder is destroyed. Conversely, if no fraud proof is submitted by the end of the challenge period, the Rollup contract can finalize the batch. Fraud proofs are a data validity verification method used in the Optimistic Rollup solution. Currently, fraud proofs can be divided into single-round interaction and multi-round interaction types.

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

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

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

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

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

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

[0066] ZK-Rollup differs from Optimistic Rollup because it uses zero-knowledge proof technology. ZK refers to the ability to prove something (a transaction or state) to another party without disclosing necessary information. In ZK-Rollup, unlike OP-Rollup, Layer 2 also generates a proof (including a proof) for the transaction batch (for example, using a cryptographic proof algorithm such as ZK-SNARK). The proof in this proof can prove that the Post State Root was obtained by correctly executing the transaction sequence in the corresponding transaction batch based on the Pre State Root. This can be confirmed by simply verifying the proof, without having to re-execute the transactions in the batch to verify.

[0067] The proof generation process can involve the sequencer packaging all transactions in a Layer 2 batch (including sender, receiver, and amount), as well as the pre- and post-State Roots, post-State Roots, and proving keys for the transactions before and after the batch's execution, and sending them to a prover on Layer 2. The prover converts this information into a special form called a witness (selecting a portion as public input and another portion as private input). The prover then uses its internal zero-knowledge proof computation circuit (a specific algorithm) to verify the validity and correctness of the public and private inputs. If the circuit is verified correctly, the execution succeeds; otherwise, the circuit fails. If the circuit succeeds, the prover outputs a proof that proves the validity and correctness of the packaged data. Furthermore, this proof is relatively small, typically only a few dozen bytes. The proof generation process described above is similar to re-execution, but involves a significant amount of circuit computation, making it more complex and time-consuming. It should be noted that the private input cannot be deduced from the proof itself. Only a party with knowledge of the zk-SNARK verification key can verify the proof encrypted with the corresponding creation key. 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.

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

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

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

[0071] To address the computational complexity and time-consuming proof generation issues, the TEE-Rollup mechanism was proposed. The TEE-Rollup mechanism differs from the ZK-Rollup in that the Prover is implemented using a TEE (Trusted Execution Environment). Furthermore, after verifying the transaction root, previous state root, and next state root of a transaction batch provided by the Sequencer, the Prover can use the private key in the TEE to sign the relevant information about the transaction batch. The signature is then published to Layer 1 via the Relayer as proof, and can be quickly verified by the Rollup Contract.

[0072] After the challenge period corresponding to any transaction batch submitted by Layer2 ends, or after the proof corresponding to any transaction batch is verified in the Rollup Contract of Layer2, the arbitrary batch and its corresponding contract call transaction (for example, the aforementioned transaction 1 for calling the CommitBatch() contract interface in the Rollup Contract) enter the finality state; it also means that all transactions belonging to the arbitrary batch in Layer2 have entered the finality state.

[0073] With the development of Rollup technology, management members of any blockchain system located in Layer 2 may, due to specific business purposes, expect the blockchain system in Layer 2 to support multiple Rollup modes (i.e., overlapping modes) with the blockchain system in Layer 1. Different Rollup modes do not necessarily require different Rollup mechanisms. For example, two Rollup modes may use the same Rollup mechanism, but the difference lies in that Layer 1 may use different methods to store the packaged transactions submitted by Layer 2. For example, the Rollup mechanism used in Rollup Mode 1 and Rollup Mode 2 is ZK-Rollup. Rollup Mode 1 requires Layer 1 to store the packaged transactions in Layer 2 in Layer 1 according to the original transaction text. However, Rollup Mode 2 requires Layer 1 to store the original transaction text of the Layer 2 transactions and instead requires Layer 1 to store the transaction hash of the Layer 2 transactions.

[0074] While Layer 1 and Layer 2 have been used to represent blockchain systems, it’s important to understand that Layer 1 typically includes one blockchain system, while Layer 2 can include one or more blockchain systems. Each of the one or more blockchain systems in Layer 2 uses the Layer 1 blockchain system as its corresponding upper-layer blockchain system.

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

[0076] With the increase in Rollup models, there is a desire for a resource management method for blockchain systems that supports users in managing Layer 2-related resources more securely and conveniently through Layer 1. For example, this method can start or terminate a certain Rollup model according to the needs of management members, and manage the target resources held by multiple accounts belonging to multiple Rollup models in Layer 2 according to the needs of users.

[0077] In view of the above issues, the solution provided in the embodiments of this specification, as shown in Figure 5, involves deploying at least a Rollup Contract in Layer 1 (i.e., the first blockchain system). The Rollup Contract includes a second method function for supporting the registration of Rollup models. The first blockchain system may also deploy a Bridge Contract and a Governance Contract. The Bridge Contract is primarily responsible for managing the blockchain system in Layer 2, such as managing accounts and the resources held by the second blockchain system in Layer 2; the Governance Contract is primarily responsible for managing registration information for various Rollup models.

[0078] It should be noted that the Bridge Contract and Governance Contract may not be deployed independently, but rather their methods and functions for implementing their corresponding functions may be directly integrated into the Rollup Contract's contract code. The methods and functions included in the Bridge Contract and Governance Contract, as well as the specific functions they implement, are described in detail below.

[0079] Figure 6 is a flowchart of a resource method for a blockchain system provided in an embodiment of this specification. The method exemplarily describes the process of registering a new rollup mode (referred to as the second rollup mode) in a first blockchain system and a second blockchain system.

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

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

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

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

[0084] In step S603, the first blockchain system executes the second method function in the Rollup Contract based on the fourth transaction, thereby performing a first upgrade operation on the Rollup Contract and the Bridge Contract based on the registration information corresponding to the second rollup mode, and generating a rollup registration event. The rollup registration event includes at least part of the registration information corresponding to the second rollup mode.

[0085] Taking the second rollup mode to be registered as including TEE-Rollup as an example, as shown in Figure 5 , the first upgrade operation performed on the Rollup Contract may include, but is not limited to, adding or enabling the TEE verifier verification method corresponding to the TEE-Rollup in the Rollup Contract. The first upgrade operation performed 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, by calling the contract interface Deposite(), add a corresponding share of the second target resource to a subaccount belonging to the TEE-Rollup in the second blockchain system; and, for a subaccount belonging to the TEE-Rollup in the second blockchain system, the contract interface Withdraw() can be called according to the corresponding policy to add a corresponding share of the first target resource to the account corresponding to the subaccount in the first blockchain system.

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

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

[0088] The repeater in the second blockchain system, such as the shared bridge included in the repeater, can monitor 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 achieve network rollup through the newly registered second rollup mode.

[0089] The aforementioned shared bridge can be a standalone service or exist in the form of an SDK. The Bridge can hold a relay account registered in the first blockchain system by an administrator of the second blockchain system, as well as the private key corresponding to the relay account. The Bridge can then use the relay account to generate transactions and send them to the first blockchain system according to certain rules, and also generate transactions and send them to the sequencer in the second blockchain system according to certain rules.

[0090] Exemplarily, the second blockchain system may, for example, execute the following steps S605 and 607 based on the rollup registration event.

[0091] In step S605, the second blockchain system generates a first upgrade transaction through its relay using the roll-up registration event, where the first upgrade transaction includes at least part of the registration information corresponding to the second roll-up mode.

[0092] The first upgrade transaction can be a special transaction and may not be packaged into the packaged transaction submitted by the second blockchain system. For example, the Bridge included in the relay can specifically set the sender and receiver fields of the first upgrade transaction, for example, setting the From field to the relay account and the To field to Null, so that the Sequencer of the second blockchain system can accurately know that the first upgrade transaction is a special transaction and execute the transaction intended by the first upgrade transaction without packaging it into the batch. The Data field of the first upgrade transaction may include at least part of the registration information included in the wrapped registration event.

[0093] In step S607, the second blockchain system executes the first upgrade transaction through its sequencer to implement 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.

[0094] Taking the example of a second rollup mode to be registered including a TEE-Rollup, as shown in FIG5 , the shared bridge of the second blockchain system can, for example, send a first upgrade transaction to the Sequencer, where the first upgrade transaction includes at least a portion of the registration information included in the TEE-Rollup registration information. 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 TEE-Rollup identification information, transaction sorting model, and genesis block; and deploying a prover TEE Prover corresponding to the TEE-Rollup in the second blockchain system.

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

[0096] As shown in FIG7 , when the second blockchain system supports M rollup modes (greater than 1), the second blockchain system can maintain M account sets for each of the M rollup modes. That is, any user, such as User 1, may have one or more accounts corresponding to no more than M in the second blockchain system. Accordingly, the state trie corresponding to the world state of the second blockchain system can include M sub-state trees corresponding to the M rollup modes. The state root corresponding to the world state of the second blockchain system (i.e., the global state root) can be calculated using the state roots corresponding to each of the M sub-state trees.

[0097] Based on this, on the basis of the aforementioned steps S601 to S607, the Sequencer can also initialize the sub-state tree corresponding to the second cascading mode in the second blockchain system, including registering a relay sub-account belonging to the second cascading mode and corresponding to the relay account in the sub-state tree corresponding to the second cascading mode. For example, based on the relay account corresponding to the second blockchain system and the second cascading mode, a derivative calculation is performed to obtain a relay sub-account belonging to the second cascading mode and corresponding to the relay account, and the relay sub-account is registered in the sub-state tree corresponding to the second cascading mode through the system contract in the second blockchain system.

[0098] The algorithm used to perform derivation calculations on accounts (including relay accounts) registered in the first blockchain system can be predetermined, and the embodiments of this specification do not limit the algorithm used for derivation calculations. In a typical example, for relay account A registered in the first blockchain system, for example, a hash value corresponding to relay account A and the identification information of the second cascading pattern can be calculated. The first x bits of the hash value are used to identify the relay sub-account belonging to the second cascading pattern and corresponding to the relay account.

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

[0100] Similarly, to reduce the number of accounts that users need to maintain in the first and second blockchain systems, thereby improving user experience, any user's account in any Rollup mode in the second blockchain system, such as User 1, is treated as a sub-account corresponding to an account registered by User 1 in the first blockchain system. For example, as shown in FIG7 , similar to the aforementioned relay sub-account ZK-AA and relay sub-account TEE-AA, both correspond to Account A. Account ZK-A1 belonging to the ZK-Rollup and account TEE-A1 belonging to the TEE-Rollup both correspond to Account A1 registered by User 1 in Layer 1.

[0101] Account ZK-A1 for any user, such as User 1, in ZK-Rollup can be derived from Account A1 and the Rollup-mode ZK-Rollup. Similarly, Account TEE-A1 for User 1 in TEE-Rollup can be derived from Account A1 and the Rollup-mode TEE-Rollup. Alternatively, the second blockchain system can directly maintain a mapping table to construct and store the corresponding relationship between any user, such as User 1's Account A1 in the first blockchain system, and their account in any Rollup mode in the second blockchain system.

[0102] Because there is a correspondence between User 1's account A1 registered in the first blockchain system and User 1's various accounts in the second blockchain system, such as account ZK-A1 and account TEE-A1, User 1 can reuse Account A1 and the corresponding public-private key pair registered in the first blockchain system to initiate transactions on demand in the second blockchain system. Accordingly, the client of the second blockchain system need not present User 1 with its account ZK-A1 under ZK-Rollup or its account TEE-A1 under TEE-Rollup. Instead, it only needs to present to User 1 the share of the first target resource held by User 1's account under ZK-Rollup and the share of the first target resource held by User 1's account under ZK-Rollup.

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

[0104] When user 1 wishes to initiate a transaction Tx in the second blockchain system to achieve a business objective, they can use account A1 registered in the first blockchain system to initiate the transaction Tx. For example, if user 1 needs to transfer a second target resource held by user 2 to user 1, the From and To fields in the transaction Tx can include user 1's account A1 and user 2's account A2, respectively, registered in the first blockchain system. Furthermore, the transaction Tx may include an indicator field (denoted as FR) corresponding to the From field and an indicator field (denoted as TR) corresponding to the To field. The field value in the FR field indicates the rollup mode to which the subaccount corresponding to account A1, which needs to transfer the second target resource out through the transaction Tx, belongs. The field value in the TR field indicates the rollup mode to which the subaccount corresponding to account A2, which needs to transfer the second target resource into through the transaction Tx, belongs.

[0105] Given that each of the M Rollup sub-accounts of user 1 in the second blockchain system corresponds to account A1 registered with the user in the first blockchain system, and that each of the M Rollup sub-accounts of user 2 in the second blockchain system corresponds to account A2 registered with the user in the first blockchain system, the second blockchain system can obtain, based on transaction Tx, the sub-accounts that actually need to transfer out the second target resource and the sub-accounts that actually need to transfer in the second target resource in the transaction Tx, thereby completing the resource transfer transaction that the transaction Tx intends to complete by executing the transaction Tx.

[0106] Figure 9 is a second flowchart of a resource management method for a blockchain system provided in an embodiment of this specification. This method exemplifies the process of adding a second target resource to a sub-account in a second blockchain system using a first account registered in the first blockchain system, when the second blockchain system supports M rollup modes.

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

[0108] In step S901, the first blockchain system receives a first transaction initiated by a first account. The first transaction is used to call the Bridge Contract deployed by the first blockchain system. The first transaction indicates N of the M rollup modes supported by the second blockchain system, as well as the resource distribution shares corresponding to each of the N rollup modes.

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

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

[0111] In step S903, the first blockchain system executes the Bridge Contract based on the first transaction to transfer the first target resource to the relay account according to the resource distribution shares corresponding to the N rollup modes, and generates a resource distribution event, where the resource distribution event includes the first account, the N rollup modes, and the resource distribution shares corresponding to each of the N rollup modes.

[0112] For example, the first blockchain system can execute Deposite() in the Bridge Contract based on the first transaction to generate a resource distribution event. In one possible implementation, the resource distribution event can also include identification information of the second blockchain system.

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

[0114] The Bridge Contract can also distribute events to storage resources through a corresponding asset transfer event list or other means.

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

[0116] To ensure security, the Bridge included in the relay of the second blockchain system may also query the simplified payment verification (SPV) certificate corresponding to the resource distribution event from the first blockchain system. Only after confirming through the SPV certificate that the block to which the first transaction belongs has been successfully submitted to the first blockchain system does the following step S905 be executed.

[0117] In step S905, the second blockchain system generates N sub-transactions based on the resource distribution event, where any i-th sub-transaction includes the first account, the i-th folding mode among the N folding modes, and its corresponding resource distribution share.

[0118] In the i-th sub-transaction, the From field can include the relay account, the To field can include the first account, the Data field can include the resource distribution share corresponding to the i-th rollup mode, and the Rollup mode included in the FR field corresponding to the From field and the TR field corresponding to the To field are both the i-th rollup mode. As shown in Figure 7, assuming that the N rollup modes include TEE-Rollup and ZK-Rollup, the Bridge can generate TEE sub-transactions and ZK sub-transactions based on the resource distribution event: in the ZK sub-transaction, the FR field corresponding to the From field and the TR field corresponding to the To field both include the ZK-Rollup rollup mode; while in the TEE sub-transaction, the FR field corresponding to the From field and the TR field corresponding to the To field both include the TEE-Rollup rollup mode.

[0119] In step S907, the second blockchain system executes the i-th sub-transaction to: determine the i-th first sub-account that belongs to the i-th roll-up mode and corresponds to the first account; and transfer the second target resource from the relay sub-account that belongs to the i-th roll-up mode and corresponds to the relay account to the i-th first sub-account based on the resource distribution share corresponding to the i-th roll-up mode.

[0120] The second blockchain system can execute the i-th sub-transaction through its Sequencer. As can be understood from the foregoing, when executing the i-th sub-transaction, the Sequencer can, in one possible implementation, use the first account included in the i-th sub-transaction and the i-th convolution mode to perform a derivative calculation to obtain the i-th first sub-account. In another possible implementation, the i-th first sub-account can be obtained by querying a mapping relationship table maintained in the second blockchain system.

[0121] After the Sequencer obtains the i-th first sub-account, it can query the i-th first sub-account in the sub-state tree corresponding to the i-th rollup mode. If the i-th first sub-account cannot be found in 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 calling the system contract of the second blockchain system.

[0122] 7 , it is assumed that the first account includes account A2, and the N types of Rollup modes include TEE-Rollup and ZK-Rollup.

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

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

[0125] Continuing with the previous example and referring to FIG7 , the Sequencer may, for example, transfer the second target resource from ZK-AA to subaccount ZK-A2 based on the resource distribution share included in the ZK sub-transaction, and transfer the second target resource from TEE-AA to subaccount ZK-A2 based on the resource distribution share included in the TEE sub-transaction.

[0126] Alternatively, depositing the second target resource into the i-th first sub-account may be accomplished through methods other than the aforementioned step 907. For example, when executing the i-th sub-transaction, the second blockchain system may determine the i-th first sub-account that belongs to the i-th rollup mode and corresponds to the first account, and mint the second target resource for the i-th first sub-account based on the resource distribution share corresponding to the i-th rollup mode. In other words, in this implementation, the second target resource need not be transferred from the relay sub-account that belongs to the i-th rollup mode and corresponds to the relay account. Instead, the corresponding share of the second target resource is minted for the i-th first sub-account.

[0127] Considering the possibility that the i-th sub-transaction may fail to execute, after the batch to which the i-th sub-transaction belongs is successfully submitted to the first blockchain system, for example, after the proof data corresponding to the batch to which the i-th sub-transaction belongs is submitted to the first blockchain system and passes verification, thereby making the i-th sub-transaction and its batch enter an immutable state, the Rollup Contract in the first blockchain system can perceive that the i-th sub-transaction has entered an immutable state. At this time, the Rollup Contract can also call the Bridge Contract to generate the i-th asset transfer completion event corresponding to the i-th sub-transaction. The asset transfer completion event may, for example, include the first account, the i-th rollup mode, and its corresponding resource distribution share. Furthermore, after the Bridge Contract collects N asset transfer completion events corresponding to N sub-exchanges, the Bridge Contract can confirm that the N asset transfer completion events successfully match the aforementioned resource distribution events based on the content included in the N asset transfer completion events and the aforementioned resource distribution events, thereby confirming that all transactions expected to be executed by the first transaction have been successfully executed.

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

[0129] Figure 10 is a third flowchart of a resource management method for a blockchain system provided in an embodiment of this specification. This method exemplifies the process of increasing the corresponding share of a first target resource for a first account registered in the first blockchain system by any first user, based on the second target resource held by the first user's sub-account in any first rollup mode in the second blockchain system, when the second blockchain system supports M rollup modes.

[0130] As shown in FIG10 , the method may include but is not limited to the following steps S1001 to S1007 .

[0131] In step S1001, a second blockchain system receives a second transaction initiated by a first account, wherein the second transaction indicates a resource transfer quota and a first roll-up mode. The first roll-up mode is one of the M roll-up modes supported by the second blockchain system.

[0132] Consider the data format of a transaction Tx initiated by a user in the second blockchain system, as described above. The From field of the second transaction can, for example, include the first account, and the FR field corresponding to the From field can include the first folding mode. The Data field of the second transaction can, for example, include the resource transfer quota. Furthermore, the To field and its corresponding TR field of the second transaction can be set according to pre-set rules. For example, both the To field and the TR field can be null, or the To field and the From field can include the same first account, and the TR field and the FR field can include the same first folding mode.

[0133] After receiving the second transaction, the receiver of the second blockchain system may add the second transaction to a transaction pool corresponding to the first concatenation pattern according to the first concatenation pattern included in the FR field corresponding to the sender field in the second transaction.

[0134] In step S1003, the second blockchain system executes a second transaction to: determine a second sub-account that belongs to the first roll-up mode and corresponds to the first account; and transfer the second target resource from the second sub-account to a relay sub-account that belongs to the first roll-up mode and corresponds to the relay account based on the resource transfer quota.

[0135] The Sequencer of the second blockchain system can pull multiple transactions from the transaction pool corresponding to the first rollup pattern, sort them, execute them, and generate the corresponding packaged transaction. As can be understood from the foregoing, when executing the second transaction, the Sequencer can, in one possible implementation, use the first account and the first rollup pattern included in the second transaction to perform a derivative calculation to obtain a second sub-account belonging to the first rollup pattern and corresponding to the first account. In another possible implementation, the second sub-account can be obtained by querying a mapping relationship table maintained in the second blockchain system.

[0136] It's important to note 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, such as when both the To and TR fields are null, or when the To and From fields include the same first account, while the TR and FR fields include the same first wrapping pattern. For example, when the Sequencer executes the second transaction, it can generate a resource extraction event based on the special structure, which includes the first account and resource transfer quota, and may also include the batch number of the third batch to which the second transaction belongs in the second blockchain system. The Bridge of the second blockchain system can, for example, generate a third transaction based on this resource extraction event.

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

[0138] To ensure that the first blockchain system can determine whether the second transaction corresponding to the third exchange has been successfully executed, the third transaction may also include the batch number of the third batch to which the second transaction belongs. Furthermore, the third transaction may also include the transaction sequence number of the second transaction within the third batch. Furthermore, the Bridge of the second blockchain system may not send the third transaction to the first blockchain system until the Replayer has submitted the proof data corresponding to the third batch to the first blockchain system.

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

[0140] When the third transaction includes the aforementioned batch number and transaction number, the first blockchain system executes the first method function in the Rollup Contract based on the third transaction. Specifically, the system can first determine whether the third batch has entered an immutable state based on the batch number of the third batch included in the third transaction. If so, the system then checks 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 system then transfers the first target resource from the relay account to the first account based on the resource transfer quota. It will be understood that matching the second and third transactions means that both transactions include the same first account and resource transfer quota.

[0141] 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 within the third batch. When the second blockchain system completes submitting the proof data for the third batch to which the second transaction belongs to the Rollup Contract, and this proof data passes verification, 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, thereby triggering the corresponding first method function to continue to query 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 based on the resource transfer quota.

[0142] In one possible implementation, when the first target resource needs to be transferred 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 through the contract interface Withdraw() and transferring the first target resource from the relay account to the first account based on the resource transfer share.

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

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

[0145] In step S1101, the first blockchain system receives a fifth transaction, where the fifth transaction is used to call a third method function in the Rollup Contract, and the fifth transaction requests termination of the second rollup mode.

[0146] The management member 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 that the second rollup mode needs to be terminated.

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

[0148] The third upgrading operation corresponds to the aforementioned first upgrading operation.

[0149] Taking the example of a second rollup mode to be terminated, including a TEE-Rollup, as an example, the third upgrade operation performed on the Rollup Contract may include, but is not limited to, deleting or disabling the TEE-Rollup corresponding verification method, TEE Verifier, in the Rollup Contract. The third upgrade operation performed on the Bridge Contract may include, but is not limited to, reconfiguring the contract interfaces Deposite() and Withdraw() in the Bridge Contract to prevent accounts registered in the first blockchain system from adding a corresponding share of the second target resource to a subaccount belonging to the TEE-Rollup in the second blockchain system by calling the Deposite() contract interface; and to prevent a subaccount belonging to the TEE-Rollup in the second blockchain system from adding a corresponding share of the first target resource to the account corresponding to the subaccount in the first blockchain system by using the Withdraw() contract interface based on the share of the second target resource held by the subaccount.

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

[0151] A repeater in the second blockchain system, such as a Bridge included in the repeater, may monitor the rollup termination event, and then perform a fourth upgrade operation on the infrastructure of the second blockchain system according to the third rollup mode indicated by the rollup termination event, so that rollup using the second rollup mode is no longer supported between the first blockchain system after the third upgrade operation and the second blockchain system after the fourth upgrade operation.

[0152] Exemplarily, the second blockchain system may, for example, execute the following steps S1105 and S1107 based on the rollup registration event.

[0153] In step 1105, the second blockchain system generates a second upgrade transaction through its relay using the rollup termination event, where the second upgrade transaction indicates the second rollup mode to be terminated.

[0154] The second upgrade transaction can be a special transaction and may not be packaged into the packaged transaction submitted by the second blockchain system. For example, the Bridge included in the relay can make special settings for the sender and receiver fields of the first upgrade transaction, such as setting the From field to the relay account and the To field to Null. This allows the Sequencer of the second blockchain system to accurately identify the second upgrade transaction as a special transaction and execute the intended transaction without packaging it into the batch. The Data field of the second upgrade transaction may include identification information for the second wrapping mode.

[0155] In step S1007, the second blockchain system executes a second upgrade transaction through its sequencer to implement: performing a fourth upgrade operation on the infrastructure of the second blockchain system according to the identification information of the second rollup mode.

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

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

[0158] In step S1109, the second blockchain system generates a sixth transaction through its relay according to the wrap-up termination event.

[0159] The second upgrade transaction can be a special transaction and may not be packaged into the packaged transaction submitted by the second blockchain system. For example, the Bridge included in the relay can perform special settings on the sender and receiver fields of the sixth transaction, such as setting both the From and To fields to Null and setting both the FR field corresponding to the From field and the TR field corresponding to the To field to the second wrapping mode. This allows the Sequencer of the second blockchain system to accurately identify the sixth transaction as a special transaction and execute the intended transaction without packaging it into the batch.

[0160] In step S1111, the second blockchain system executes the sixth transaction through its sequencer to transfer the second target resource held by any first target sub-account belonging to the second roll-up mode to the second target sub-account belonging to the third roll-up mode, where the first target sub-account and the second target sub-account correspond to the same target account registered in the first blockchain system.

[0161] Continuing with the previous example, referring to Figure 7 , let's assume that the terminated second rollup mode is TEE-Rollup, and that the third rollup mode includes ZK-Rollup. Then, the second target resource held by account TEE-A1 can be transferred to account ZK-A1, and the second target resource held by account TEE-A2 can be transferred to account ZK-A2.

[0162] When the second rollup mode is terminated, the target resource held by any first target sub-account in the second rollup mode may be transferred using other methods other than the aforementioned steps S1109 and S1111. For example, a Bridge included in the relay of the second blockchain system may generate a target transaction, which is used to call a preset method function in the Rollup Contract deployed by the first blockchain system. When the first blockchain system executes the preset function according to the target transaction, the first target resource is transferred from the relay account corresponding to the second blockchain system to the target account registered in the first blockchain system for any first target sub-account in the second rollup mode, based on the first target sub-account's current share of the second target resource.

[0163] Figure 12 is a flowchart of a resource management method for a blockchain system provided in an embodiment of this specification. This method exemplifies the process of transferring resources from a first sub-account corresponding to a first account in a first roll-up mode to a second sub-account corresponding to a second account in a second roll-up mode in a second blockchain system supporting the M roll-up mode.

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

[0165] The following mainly uses the example description that the first rollup mode includes ZK-Rollup, the second rollup mode includes TEE-Rollup, the first account includes account A1, the second account includes account A2, the relay account includes account A, and the resource transfer share is T.

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

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

[0168] The second blockchain system not only receives transactions from its clients but may also initiate transactions that need to be executed by the second blockchain system through the shared bridge included in the relay. For example, the bridge may initiate the aforementioned ZK sub-transactions and TEE sub-transactions. Transactions that need to be executed by the second blockchain system can be added to the corresponding transaction pool based on the value of the FR field corresponding to the From field in the transaction. For example, if the value of the FR field corresponding to the From field in transaction 7 is ZK-Rollup, it can be added to the corresponding ZK Txpool.

[0169] The M rollup modes in the second blockchain system use M different batch chains, with a single batch chain containing multiple batches connected sequentially. For multiple transactions belonging to the same batch, the rollup mode included in the FR field must remain the same. In addition to the standard Prev Hash, Nonce, Batch Num (batch number), Tx_Root, State_Root, and Receipt_Root, the batch header of any batch can also include the corresponding Rollup mode. As shown in Figure 13, for any batch in the batch chain corresponding to ZK-Rollup, for example, batch 2, the batch header of batch 2 includes ZK-Rollup, and in the multiple transactions included in batch 2, the FR field corresponding to the From field is all ZK-Rollup; for any batch in the batch chain corresponding to TEE-Rollup, for example, batch 2, the batch header of batch 2 includes TEE-Rollup, and in the multiple transactions included in batch 2, the FR field corresponding to the From field is all TEE-Rollup.

[0170] It should be noted that when M roll-up modes use M different batch chains, for any batch in the j-th batch chain corresponding to any j-th roll-up mode, the State_Root included in the batch header of the batch is the state root of the sub-state tree corresponding to the j-th roll-up mode in the world state tree of the second blockchain system, rather than the global state root of the world state of the entire second blockchain system. For example, referring to Figure 7 and Figure 13, for any batch included in the batch chain corresponding to ZK-Rollup in Figure 13, such as batch 2, the State_root included in its batch header can be the state root ZK state root of the sub-state tree corresponding to ZK-Rollup in the state tree corresponding to the world state of the second blockchain system shown in Figure 7; correspondingly, for any batch included in the batch chain corresponding to TEE-Rollup in Figure 13, such as batch 2, the State_root included in its batch header can be the state root TEE state root of the sub-state tree corresponding to TEE-Rollup in the state tree corresponding to the world state of the second blockchain system shown in Figure 7.

[0171] Because the M convolution modes use M different batch chains, the sequencer of the second blockchain system can be implemented in parallel without interfering with each other: it packages and executes transactions from the M transaction pools corresponding to the M convolution modes. Obviously, the sequencer can also use other methods such as time slicing to package and execute transactions from the M transaction pools in a certain order.

[0172] In summary, after the seventh transaction is added to the transaction pool corresponding to the first rollup mode, the sequencer of the second blockchain system can execute the following step S1203 at a certain time, pulling multiple transactions from the transaction pool corresponding to the first rollup mode, sorting and packaging the multiple transactions, where the multiple transactions include the seventh transaction.

[0173] Take the seventh transaction being packaged into batch k (i.e., the first batch) included in the batch chain corresponding to ZK-Rollup as an example.

[0174] The Sequencer pulls multiple transactions from the ZK Txpool, sorts them, and packages them. Based on the state data corresponding to the previous batch of batch k, it executes the transactions packaged into batch k in the sorted order. Therefore, if the transactions in batch k include the seventh transaction, the Sequencer of the second blockchain system will execute step S1205.

[0175] In step S1205, the second blockchain system executes the seventh transaction to transfer the second target resource from the first sub-account corresponding to the first account and belonging to the first roll-up mode to the first relay sub-account corresponding to the relay account and belonging to the first roll-up mode according to the resource transfer quota.

[0176] During the execution of the seventh transaction, the Sequencer can first determine the first sub-account belonging to the first rollover mode and corresponding to the first account, and then, based on the pre-configured relay account, determine the first relay sub-account belonging to the first rollover mode and corresponding to the relay account. The Sequencer can, for example, determine the first sub-account and the first relay sub-account through the aforementioned derivative calculation or mapping table, which will not be further described here.

[0177] During the execution of the seventh transaction, for example, after determining that the first sub-account belonging to ZK-Rollup and corresponding to account A1 is account ZK-A1 and that the first relay sub-account belonging to ZK-Rollup and corresponding to account A is account ZK-AA, the sequencer may transfer the second target resource from account ZK-A1 to account ZK-AA based on the resource transfer share T.

[0178] After the Sequencer completes executing multiple transactions belonging to batch k, as previously described, it obtains the concatenated data corresponding to batch k, including the Pre-State Root (PSR), Post-State Root (PSR), batch number k, and the transaction sequence consisting of these transactions. It should be noted that the Pre-State Root here refers to the state root (e.g., ZK state root) of the sub-state tree corresponding to the first concatenation mode in the state tree corresponding to the world state of the second blockchain system before the multiple transactions in batch k are executed; the Post-State Root refers to the state root of the sub-state tree corresponding to the first concatenation mode in the state tree corresponding to the world state of the second blockchain system after the multiple transactions in batch k are executed.

[0179] Furthermore, in order to distinguish batches belonging to different batch chains, the convolution data of the first batch to which the seventh transaction belongs may further include a first convolution mode corresponding to the batch chain to which the first batch belongs.

[0180] Correspondingly, the second blockchain system may further execute step S1207 and send an eighth transaction to the first blockchain system. The eighth transaction is used to call the fourth method function in the Rollup Contract deployed by the first blockchain system. The eighth transaction includes the rolled-up data of the first batch to which the seventh transaction belongs.

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

[0182] Accordingly, the first blockchain system may execute step S1209 and execute the fourth method function in the Rollup Contract according to the eighth transaction to process the rolled-up data of the first batch to which the seventh transaction belongs.

[0183] As previously mentioned, the convolution data for the first batch, batch k, may include: the first convolution mode, the pre-state root, the post-state root, the batch number k, and the transaction sequence consisting of multiple transactions belonging to batch k. Processing the convolution data for batch k may include: verifying whether the pre-state root in the eighth transaction is equal to the current state root corresponding to the first convolution mode in the Rollup Contract storage; if so, storing the transaction sequence in the eighth transaction in calldata, updating the current state root corresponding to the first convolution mode in the Rollup Contract storage to the post-state root; and setting the position index of the transaction sequence in calldata based on the first convolution mode and batch number k.

[0184] Referring to the Rollup mechanism described above, after the second blockchain system completes submitting the first batch, batch k, in step S1209, it also needs to submit the first attestation data corresponding to the first batch to the first blockchain system via the first prover corresponding to the first rollup mode. In other words, the second blockchain system can also perform step S1211.

[0185] In step S1211, the second blockchain system sends a ninth transaction to the first blockchain system via the first certifier corresponding to the first rollup mode. The ninth transaction is used to call the fifth method function in the Rollup Contract. The ninth transaction includes the first certification data corresponding to the first rollup mode and the first batch.

[0186] The data format of the first proof data can be found in the description of the Rollup mechanism above and will not be repeated here.

[0187] Accordingly, in step S1213, the first blockchain system executes the fifth method function according to the ninth transaction to achieve: according to the verification method corresponding to the first stacking mode, using the proof data corresponding to the first batch, verify whether the multiple transactions in the first batch are executed correctly, and generate an asset transfer event corresponding to the seventh transaction if the verification is passed.

[0188] When the first rollup mode includes the ZK-Rollup mode, the fifth method function in the Rollup Contract can, for example, call the ZK verifier verification method corresponding to the ZK-Rollup within the contract based on the ZK-Rollup included in the ninth transaction. The ZK verifier then processes the first proof data included in the ninth transaction to verify the correct execution of multiple transactions in the first batch. If verification passes, the first batch enters an immutable state. Furthermore, the fifth method function itself, or by calling the Bridge Contract within the contract, can generate asset pending transfer events for transactions in certain specific data formats, as well as asset transfer completed events for transactions in certain specific data formats.

[0189] In one exemplary rule, if the account in the From field of a transaction is not a relay account, and the wrapping patterns in the FR and TR fields are different, an Asset Pending Transfer event can be generated for that transaction. If the account in the From field of a transaction is a relay account, an Asset Transfer Completed event can be generated for that transaction. Based on this exemplary rule and the data structure of the seventh transaction described above, it's easy to understand that an Asset Pending Transfer event can be generated for that seventh transaction.

[0190] The Bridge Contract can also maintain a collection of events that allow consumption. For asset transfer events, the fifth method function can be used to call the contract, or the Bridge Contract can enable the corresponding event listening mechanism to ultimately add the asset transfer event to the event collection maintained in the Bridge Contract.

[0191] In a typical example, as shown in Figure 14, for a corresponding asset pending transfer event, the Topic field value E1 indicates that the event is an asset pending transfer event. Furthermore, the Data field of the asset pending transfer event may include: a subfield From, which stores the account in the From field of the corresponding transaction; a subfield To, which stores the account in the To field of the corresponding transaction; a subfield FR, which stores the rollover mode in the FR field of the corresponding transaction; a subfield TR, which stores the rollover mode in the TR field of the corresponding transaction; and a subfield FE, which stores the resource transfer share included in the Data field of the corresponding transaction.

[0192] As shown in Figure 14, for an asset transfer completion event corresponding to a transaction, the Topic field value E2 indicates that the event is an asset transfer completion event. Furthermore, the Data field of the asset transfer completion event may include: a subfield To, which stores the account number in the To field of the corresponding transaction; a subfield TR, which stores the rollover mode in the TR field of the corresponding transaction; and a subfield FE, which stores the resource transfer share in the Data field of the corresponding transaction.

[0193] The Asset Transfer Completed event is used by the Bridge Contract to match it with the Asset Pending Transfer event in the event collection to confirm the asset transfer transaction that the transaction corresponding to the Asset Pending Transfer event has completed. For example, referring to the Asset Transfer Completed event and the Asset Pending Transfer event shown in Figure 14, a match is successful if the Data fields of the two events contain the same account in the To subfield, the same wrapping mode in the TR subfield, and the same resource transfer share in the FE field.

[0194] After the first blockchain system generates an asset pending transfer event corresponding to the seventh transaction, the shared bridge included in the relay of the second blockchain system can monitor the asset pending transfer event and then execute the following step S1215.

[0195] In step S1215, the second blockchain system generates a tenth transaction based on the asset pending transfer event corresponding to the seventh transaction. The sender field and the receiver field of the tenth transaction include the relay account and the second account, respectively. The tenth transaction also includes a resource transfer share and a second rollup mode.

[0196] The information in the tenth transaction, aside from the relay account, can come from the pending asset transfer event corresponding to the seventh transaction. Continuing with the previous example, in the tenth transaction, the From field can include account A, the To field can include account A2, the FR field corresponding to the From field can include TEE-Rollup, the TR field corresponding to the To field can include TEE-Rollup, and the Data field can include resource transfer quota T. Accordingly, because the value of the FR field corresponding to the From field in the tenth transaction is TEE-Rollup, the tenth transaction will be added to the corresponding TEE Txpool.

[0197] After the tenth transaction is added to the transaction pool corresponding to the second rollup mode, the sequencer of the second blockchain system may execute the following step S1217 at a certain moment: pull multiple transactions from the transaction pool corresponding to the second rollup mode, sort and package the multiple transactions, wherein the multiple transactions include the tenth transaction.

[0198] Take the example of the tenth transaction being packaged into batch b (i.e., the second batch) included in the batch chain corresponding to TEE-Rollup.

[0199] Sequence pulls multiple transactions from the TEE Txpool, sorts them, and packages them. It then executes the transactions packaged into batch B in the sorted order based on the state data corresponding to the previous batch of batch B. Therefore, if the multiple transactions in batch B include the tenth transaction, the Sequence of the second blockchain system will execute step S1219.

[0200] In step S1219, the second blockchain system executes the tenth transaction to transfer the second target resource from the second relay sub-account belonging to the second cascading model and corresponding to the relay account to the second sub-account belonging to the second cascading model and corresponding to the second account according to the resource transfer share.

[0201] During the execution of the tenth transaction, the Sequencer can first determine the second sub-account belonging to the second rollover mode and corresponding to the second account, as well as the second relay sub-account belonging to the second rollover mode and corresponding to the relay account. The Sequencer determines the second sub-account and the second relay sub-account using the same method as the first sub-account and the first relay sub-account, including, for example, the derivative calculation or mapping table described above, and will not be further described here.

[0202] During the process of the sequencer executing the tenth transaction, for example, after determining that the second sub-account belonging to the TEE-Rollup and corresponding to account A2 is account TEE-A2, and determining that the second relay sub-account belonging to the TEE-Rollup and corresponding to account A is account TEE-AA, the second target resource can be transferred from account TEE-AA to account TEE-A2 according to the resource transfer share T.

[0203] In the aforementioned method embodiment, since the M convolution modes correspond to M different batch chains, the blockchain system facilitates efficient submission of each batch belonging to the M batch chains through parallel technology. Furthermore, the second blockchain system will only generate and execute the tenth transaction based on the pending asset transfer event corresponding to the seventh transaction after the first batch belonging to the seventh transaction has entered an immutable state, thereby completing the resource transfer transaction intended by the seventh transaction. The second batch belonging to the tenth transaction will not be rolled back due to the failure of the first batch belonging to the seventh transaction.

[0204] However, referring to the exemplary ZK-Rollup and TEE-Rollup mechanisms described above, after the second blockchain system completes executing multiple transactions within a batch, it must submit the corresponding batch and the corresponding proof data to the first blockchain system. Furthermore, it is possible that after the first batch, to which the seventh transaction belongs, has entered an immutable state, the tenth transaction may fail to execute for some reason, or even fail to generate a corresponding tenth transaction for some reason, resulting in the failure to accurately complete the resource transfer transaction intended by the seventh transaction.

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

[0206] Continuing from the previous section, after the Sequencer completes executing multiple transactions belonging to batch b, it obtains the corresponding pre-state root (Pre State Root), post-state root (Post State Root), batch number b, and the transaction sequence consisting of these multiple transactions, along with other concatenated data. It should be noted that the pre-state root here refers to the state root (e.g., TEE state root) of the sub-state tree corresponding to the second concatenation mode in the state tree corresponding to the world state of the second blockchain system before the multiple transactions in batch b are executed. The post-state root refers to the state root of the sub-state tree corresponding to the second concatenation mode in the state tree corresponding to the world state of the second blockchain system after the multiple transactions in batch k are executed.

[0207] Furthermore, in order to distinguish batches belonging to different batch chains, the concatenation data of the second batch to which the tenth transaction belongs may further include a second concatenation mode corresponding to the batch chain to which the second batch belongs.

[0208] Based on the rolled-up data of the second batch to which the tenth transaction belongs, the first blockchain system may further execute step S1221, sending an eleventh transaction 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, and the eleventh transaction includes the rolled-up data of the second batch.

[0209] Accordingly, the first blockchain system may then execute step S1223, executing the fourth method function in the Rollup Contract according to the eleventh transaction, to process the rolled-up data of the second batch belonging to the tenth transaction.

[0210] As previously mentioned, the convolution data for the second batch, batch b, may include: the second convolution mode, the pre-state root, the post-state root, the batch number b, and the transaction sequence consisting of multiple transactions belonging to batch b. Processing the convolution data for batch b may include: verifying whether the pre-state root in the tenth transaction is equal to the current state root corresponding to the second convolution mode in the Rollup Contract storage; if so, storing the transaction sequence in the eleventh transaction in calldata, updating the current state root corresponding to the second convolution mode in the Rollup Contract storage to the post-state root; and setting the position index of the transaction sequence in calldata based on the second convolution mode and batch number b.

[0211] Referring to the Rollup mechanism described above, after the second blockchain system completes submission of the second batch, batch b, in step S1223, it also needs to submit the second attestation data corresponding to the second batch to the first blockchain system via the second attestor corresponding to the second rollup mode. In other words, the second blockchain system can also execute step S1225.

[0212] In step S1225, the second blockchain system sends a twelfth transaction to the first blockchain system through a second certifier corresponding to the second rolling mode. The twelfth transaction is used to call the fifth method function in the Rollup. The twelfth transaction includes second certification data corresponding to the second rolling mode and the second batch.

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

[0214] Correspondingly, in step S1227, the first blockchain system executes the fifth method function in the Rollup Contract according to the twelfth transaction, thereby verifying whether the multiple transactions in the second batch are correctly executed according to the verification method corresponding to the second rolling mode and using the second proof data corresponding to the second batch, and generating an asset transfer completion event corresponding to the tenth transaction if the verification passes.

[0215] When the second rollup mode includes the TEE-Rollup mode, the fifth method function in the Rollup Contract can, for example, call the TEE verifier verification method corresponding to the TEE-Rollup based on the TEE-Rollup included in the twelfth transaction. The TEE verifier processes the second proof data included in the twelfth transaction to verify whether the multiple transactions in the second batch have been correctly executed. If the verification passes, the second batch enters an unchangeable state. At the same time, the fifth method function itself, or by calling the Bridge Contract within the contract, generates an asset pending transfer event for transactions in certain specific data formats, and generates an asset transfer completed event for transactions in certain specific data formats.

[0216] Referring to the aforementioned step S1213, the Asset Transfer Completed event generated for the tenth transaction can be used to consume the Asset Pending Transfer event corresponding to the seventh transaction in the event set maintained by Bridge Contrac, thereby confirming the successful execution of the transaction intended for the seventh transaction. If both the seventh and tenth transactions are successfully executed, the Asset Pending Transfer and Asset Transfer Completed events shown in Figure 14 will be generated accordingly, and these two events will be successfully matched.

[0217] Through the aforementioned steps S1221 to S1227, in the case where the seventh transaction is successfully executed but the tenth transaction is not successfully executed, the asset pending transfer event corresponding to the seventh transaction in the event set cannot be consumed. The management member can confirm that the resource transfer transaction expected to be completed by the seventh transaction was not successfully executed by querying the event set, and based on the asset pending transfer event corresponding to the seventh transaction, return the corresponding second target resource to the sub-account belonging to the first roll-up mode and corresponding to the first account.

[0218] The technical solution described in steps S1201 through S1227 of the aforementioned method primarily describes the process of transferring resources from a first sub-account associated with a first account and belonging to a first rollup mode to a second sub-account associated with a second account and belonging to a second rollup mode (different from the first rollup mode). However, in some technical scenarios, the FR and TR fields of certain transactions may contain the same rollup mode. In such cases, the intended transaction can be completed through other means.

[0219] In one possible implementation, the second blockchain system may receive a thirteenth transaction, where the sender field and the receiver field of the thirteenth transaction include the first account and the second account, respectively. The thirteenth transaction also includes a resource transfer share, a first rollup mode corresponding to the sender field, and a first rollup mode corresponding to the receiver field. In this case, after the second blockchain system packages the thirteenth transaction into a batch corresponding to the first rollup mode, such as the fourth batch, when executing the thirteenth transaction, the second target resource can be directly transferred from the first sub-account belonging to the first rollup mode and corresponding to the first account to the third sub-account belonging to the first rollup mode and corresponding to the second account based on the resource transfer share.

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

[0221] Based on the same concept as the aforementioned method embodiment, a second blockchain system is further provided in the embodiment of this specification. The second blockchain system supports M types of folding modes, including: a receiver, configured to receive a seventh transaction, the sender field and the receiver field of the seventh transaction respectively including a first account and a second account, and the seventh transaction also including a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; a sorter, configured to execute the seventh transaction to achieve: according to the resource transfer share, from the first sub-account belonging to the first folding mode and corresponding to the first account, to the first relay sub-account belonging to the first folding mode and corresponding to the relay account to transfer the second target resource; a relayer, configured to send an eighth transaction to the first blockchain system for calling the fourth method function in the folding contract deployed by the first blockchain system, so that the The first blockchain system processes the concatenated data of the first packaged transaction batch to which the seventh transaction belongs; and sends a ninth transaction to the first blockchain system for calling the fifth method function in the concatenated contract, so that the first blockchain system verifies whether the multiple transactions in the first batch are correctly executed according to the verification method corresponding to the first concatenated mode and the first proof data corresponding to the first batch, and generates an asset pending transfer event corresponding to the seventh transaction if the verification passes; the sequencer is configured to generate a tenth transaction based on the asset pending transfer event corresponding to the seventh transaction, and execute the tenth transaction to achieve: according to the resource transfer share, the second relay sub-account belonging to the second concatenated mode and corresponding to the relay account transfers the second target resource to the second sub-account belonging to the second concatenated model and corresponding to the second account.

[0222] Based on the same concept as the aforementioned method embodiment, the embodiment of this specification further provides a blockchain node in a first blockchain system, wherein a roll-up contract is deployed in the first blockchain system, wherein the roll-up contract includes a fourth method function and a fifth method function, and the blockchain node includes: a transaction receiving unit, configured to receive an eighth transaction from a second blockchain system, wherein the eighth transaction is used to call the fourth method function, wherein the eighth transaction includes roll-up data of a first packaged transaction batch to which the seventh transaction belongs, wherein the sender field and the receiver field of the seventh transaction include a first account and a second account, respectively, wherein the seventh transaction also includes a resource transfer share, a first roll-up mode corresponding to the sender field, and a second roll-up mode corresponding to the receiver field, wherein the eighth transaction is implemented in the second blockchain system by executing the seventh transaction, and is initiated after the second target resource is transferred from the first sub-account belonging to the first roll-up mode and corresponding to the first account to the first relay sub-account belonging to the first roll-up mode and corresponding to the relay account according to the resource transfer share; and a transaction execution unit, configured to be root The fourth method function is executed according to the eighth transaction to process the rolled data of the first batch; the transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction being used to call the fifth method function, the ninth transaction including the first roll-up mode and the first proof data corresponding to the first batch; the transaction executing unit is further configured to execute the fifth method function according to the ninth transaction to implement: according to the verification method corresponding to the first roll-up mode, using the proof data corresponding to the first batch, verifying whether the multiple transactions in the first batch are correctly executed, and generating an asset transfer event corresponding to the seventh transaction if the verification passes; wherein the asset transfer event is used to support the second blockchain system in generating a tenth transaction, and by executing the tenth transaction, implement: according to the resource transfer share, transferring the second target resource from the second relay sub-account belonging to the second roll-up mode and corresponding to the relay account to the second sub-account belonging to the second roll-up model and corresponding to the second account.

[0223] The embodiments of this specification also provide a computer-readable storage medium having a computer program / instruction stored thereon. When the computer program / instruction is executed in a computer, the computer is caused to execute the method steps performed by the first blockchain system or the second blockchain system in the aforementioned embodiments.

[0224] An embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores a computer program / instruction, and when the processor executes the computer program / instruction, the method steps performed by the first blockchain system or the second blockchain system in the aforementioned embodiments are implemented.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0239] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A resource management method for a blockchain system, which is executed by a second blockchain system supporting M folding modes, and the method includes: Receiving a seventh transaction, where the sender field and the recipient field of the seventh transaction respectively include a first account and a second account, and the seventh transaction further includes a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the recipient field; 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 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; Sending an eighth transaction to a first blockchain system for invoking a fourth method function in a folding contract deployed by the first blockchain system, so that the first blockchain system processes the folding data of the first packaging transaction batch to which the seventh transaction belongs; Sending a ninth transaction to the first blockchain system for invoking a fifth method function in the folding contract, so that the first blockchain system generates an asset transfer event corresponding to the seventh transaction after verifying that multiple transactions in the first batch have been correctly executed; Generating a tenth transaction according to the asset transfer event corresponding to the seventh transaction and executing the tenth transaction to 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 model and corresponding to the second account.

2. The method according to claim 1, wherein the state tree corresponding to the world state of the second blockchain system includes M sub-state trees corresponding to the M folding patterns; wherein, The state root included in the batch header of the first batch to which the seventh transaction belongs is the state root of the sub-state tree corresponding to the first folding mode.

3. According to the method of claim 1, the M folding modes correspond to M batch chains; the first batch to which the seventh transaction belongs is located in the batch chain corresponding to the first folding mode; the second batch to which the tenth transaction belongs is located in the batch chain corresponding to the second folding mode.

4. According to the method of claim 1, the second blockchain system includes M transaction pools corresponding to the M folding modes; before the seventh transaction is executed, it is cached in the transaction pool corresponding to the first folding mode; before the tenth transaction is executed, it is cached in the transaction pool corresponding to the second folding mode.

5. The method according to claim 4, wherein the method further comprises: Before executing the seventh transaction, pulling multiple transactions belonging to the first batch from the transaction pool corresponding to the first folding mode, sorting and packaging the multiple transactions, and the multiple transactions include the seventh transaction.

6. The method according to claim 4, the method further comprising: Before executing the tenth transaction, pulling multiple transactions belonging to the second batch from the transaction pool corresponding to the second folding mode, sorting and packaging the multiple transactions, and the multiple transactions include the tenth transaction.

7. According to the method of claim 1, the method further includes: Send the eleventh transaction to the first blockchain system to call the fourth method function in the folding contract deployed by the first blockchain system, so that the first blockchain system processes the folding data of the second batch to which the tenth transaction belongs; Send the twelfth transaction to the first blockchain system to call the fifth method function in the folding contract so that the first blockchain system verifies whether multiple transactions in the second batch are correctly executed according to the verification method corresponding to the second folding mode, using the second proof data corresponding to the second batch, and generates an asset transfer completion event corresponding to the tenth transaction when the verification passes.

8. The method according to claim 7, the asset transfer completion event corresponding to the tenth transaction, and the asset transfer pending event corresponding to the seventh transaction, which are used to support the first blockchain system to determine that the resource transfer according to the seventh transaction has been completed when they are successfully matched.

9. The method according to any one of claims 1-8, the method further includes: Obtain a resource distribution event from the first blockchain system. The first blockchain system deploys a relay contract. The resource distribution event is generated by the first blockchain system executing the relay contract according to a first transaction. The first transaction is initiated by the first account. The first transaction indicates N folding modes among the M folding modes and the resource distribution shares corresponding to the N folding modes respectively; Generate N sub-transactions according to the resource distribution event. Any i-th sub-transaction includes the first account, the i-th folding mode among the N folding modes, and its corresponding resource distribution share; 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 folding mode and corresponds to the first account according to the resource distribution share corresponding to the i-th folding mode.

10. The method according to claim 9, the i-th first sub-account is obtained by derivative calculation based on the first account and the i-th folding mode.

11. According to the method described in claim 9, the state tree corresponding to the world state of the second blockchain system includes M sub-state trees corresponding to the M folding patterns; wherein, When the sequencer executes the i-th sub-transaction, it also achieves: query whether the i-th first sub-account exists in the sub-state tree corresponding to the i-th folding mode, and if not, register the i-th first sub-account in the sub-state tree corresponding to the i-th folding mode.

12. A resource management method for a blockchain system, executed by a first blockchain system. The first blockchain system deploys a folding contract, and the folding contract includes a fourth method function and a fifth method function. The method includes: Receive an eighth transaction from the second blockchain system. The eighth transaction is used to invoke the fourth method function. The eighth transaction includes the rolled-up data of the first packaging transaction batch to which the seventh transaction belongs. The sender field and the recipient field of the seventh transaction respectively include a first account and a second account. The seventh transaction further includes a resource transfer share, a first rolled-up mode corresponding to the sender field, and a second rolled-up mode corresponding to the recipient field. The eighth transaction is initiated after the second blockchain system realizes the transfer of a second target resource from a first sub-account belonging to the first rolled-up mode and corresponding to the first account to a first relay sub-account belonging to the first rolled-up mode and corresponding to the relay account according to the resource transfer share by executing the seventh transaction. Execute the fourth method function according to the eighth transaction to process the rolled-up data of the first batch. Receive a ninth transaction from the second blockchain system. The ninth transaction is used to invoke the fifth method function. The ninth transaction includes the first rolled-up mode and the first proof data corresponding to the first batch. Execute the fifth method function according to the ninth transaction to achieve: according to the verification method corresponding to the first rolled-up mode, Use the first proof data corresponding to the first batch to verify whether multiple transactions in the first batch are correctly executed, and generate an asset transfer pending event corresponding to the seventh transaction when the verification passes. The asset transfer event is used to support the second blockchain system to generate a tenth transaction and realize, by executing the tenth transaction: according to the resource transfer share, transfer the second target resource from a second relay sub-account belonging to the second rolled-up mode and corresponding to the relay account to a second sub-account belonging to the second rolled-up model and corresponding to the second account.

13. The method according to claim 12, wherein the method further comprises: Receive an eleventh transaction from the second blockchain system. The eleventh transaction is used to invoke the fourth method function. The eleventh transaction includes the rolled-up data of the second batch to which the tenth transaction belongs. Execute the fourth method function according to the eleventh transaction to process the rolled-up data of the second batch. Receive a twelfth transaction from the second blockchain system. The twelfth transaction is used to invoke the fifth method function. The twelfth transaction includes the second rolled-up mode and the second proof data corresponding to the second batch. Execute the fifth method function according to the twelfth transaction to achieve: according to the verification method corresponding to the second rolled-up mode, use the second proof data corresponding to the second batch to verify whether multiple transactions in the second batch are correctly executed, and generate an asset transfer completion event corresponding to the tenth transaction when the verification passes.

14. The method according to claim 13, when the asset transfer completion event corresponding to the tenth transaction and the asset to-be-transferred event corresponding to the seventh transaction are used to support the first blockchain system to successfully match them, it is determined that the resource transfer according to the seventh transaction has been completed.

15. The method according to any one of claims 12 - 14, wherein a relay contract is deployed in the first blockchain system, and the method further includes: Receiving a first transaction initiated by the first account, the first transaction is used to call the relay contract, and the first transaction indicates N folding patterns among the M folding patterns supported by the second blockchain system, and the resource distribution shares corresponding to the N folding patterns respectively; Executing the relay contract according to the first transaction, to achieve: generating a resource distribution event, the resource distribution event includes the first account, the N folding patterns and their corresponding resource distribution shares respectively; the resource distribution event is used to support the second blockchain system to generate N sub-transactions, and by executing any i-th sub-transaction, it is achieved that: depositing second target resources into the i-th first sub-account belonging to the i-th folding pattern and corresponding to the first account.

16. The method according to claim 15, when executing the relay contract according to the first transaction, it further achieves: transferring first target resources from the first account to the relay account corresponding to the second blockchain system according to the resource distribution shares corresponding to the N folding patterns respectively.

17. A second blockchain system, the second blockchain system supports M folding patterns, including: A receiver, configured to receive a seventh transaction, the sender field and the receiver field of the seventh transaction respectively include a first account and a second account, and the seventh transaction further includes a resource transfer share, a first folding pattern corresponding to the sender field, and a second folding pattern corresponding to the receiver field; An orderer, configured to execute the seventh transaction, to achieve: according to the resource transfer share, transferring second target resources from the first sub-account belonging to the First folding pattern and corresponding to the first account to the first relay sub-account belonging to the first folding pattern and corresponding to the relay account; A relay, configured to send an eighth transaction to the first blockchain system, for calling the fourth method function in the folding contract deployed by the first blockchain system, so that the first blockchain system processes the folding data of the first batch transaction batch to which the seventh transaction belongs; And sending a ninth transaction to the first blockchain system, for calling the fifth method function in the folding contract, so that the first blockchain system generates an asset to-be-transferred event corresponding to the seventh transaction after verifying that multiple transactions in the first batch have been correctly executed; The sorter is configured to generate a tenth transaction according to the asset transfer event to be transferred corresponding to the seventh transaction, and execute the tenth transaction, so as to achieve: according to the resource transfer share, transfer the second target resource from the second relay sub-account belonging to the second stacking mode and corresponding to the relay account to the second sub-account belonging to the second stacking model and corresponding to the second account.

18. A blockchain node in a first blockchain system, in which a stacking contract is deployed, the stacking contract includes a fourth method function and a fifth method function, and the blockchain node includes: A transaction receiving unit, configured to receive an eighth transaction from a second blockchain system, the eighth transaction is used to call the fourth method function, the eighth transaction includes the stacking data of the first packaging transaction batch to which the seventh transaction belongs, the sender field and the receiver field of the seventh transaction respectively include a first account and a second account, the seventh transaction further includes a resource transfer share, a first stacking mode corresponding to the sender field, and a second stacking mode corresponding to the receiver field, and the eighth transaction is initiated after the second blockchain system transfers the second target resource from the first sub-account belonging to the first stacking mode and corresponding to the first account to the first relay sub-account belonging to the first stacking mode and corresponding to the relay account according to the resource transfer share; A transaction execution unit, configured to process the stacking data of the first batch by executing the fourth method function according to the eighth transaction; The transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction is used to call the fifth method function, and the ninth transaction includes the first stacking mode and the first proof data corresponding to the first batch; The transaction execution unit is further configured to execute the fifth method function according to the ninth transaction, so as to achieve: according to the verification method corresponding to the first stacking mode, use the proof data corresponding to the first batch to verify whether multiple transactions in the first batch are correctly executed, and generate an asset transfer event corresponding to the seventh transaction in the case of successful verification; wherein, the asset transfer event is used to support the second blockchain system to generate a tenth transaction, and by executing the tenth transaction, it is achieved that: according to the resource transfer share, transfer the second target resource from the second relay sub-account belonging to the second stacking mode and corresponding to the relay account to the second sub-account belonging to the second stacking model and corresponding to the second account.

Images