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

Abstract

Provided in the description are resource management methods for a blockchain system. A resource management method comprises: a first blockchain system receiving a first transaction initiated by a first account, wherein the first transaction is used for calling a bridge contract, and the first transaction indicates N rollup modes and resource distribution shares respectively corresponding thereto; the first blockchain system executing the bridge contract on the basis of the first transaction, so as to: generate a resource distribution event, which comprises the first account, the N rollup modes and the resource distribution shares respectively corresponding thereto; a second blockchain system generating N sub-transactions on the basis of the resource distribution event, wherein an ith sub-transaction comprises the first account, an ith rollup mode among the N rollup modes, and a resource distribution share corresponding to the ith rollup mode; and the second blockchain system executing the ith sub-transaction, so as to: determine an ith first sub-account which belongs to the ith rollup mode and corresponds to the first account, and transfer a second target resource to the ith first sub-account on the basis of the resource distribution share corresponding to the ith rollup mode.

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 202311863173.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 resource management method for a blockchain system is provided. The method includes: a first blockchain system receiving a first transaction initiated by a first account, the first transaction being used to invoke a relay contract deployed by the first blockchain system, the first transaction indicating N rollup modes and their corresponding resource distribution shares; the first blockchain system executing the relay contract based on the first transaction to: transfer a first target resource to the relay account based on the resource distribution shares corresponding to the N rollup modes, and generating a resource distribution event including the first account, the N rollup modes, and their corresponding resource distribution shares; a second blockchain system generating N sub-transactions based on the resource distribution event, wherein any i-th sub-transaction includes the first account, an i-th rollup mode among the N rollup modes, and its corresponding resource distribution share; and the second blockchain system executing the i-th sub-transaction to: determine an i-th first sub-account belonging to the i-th rollup mode and corresponding to the first account, and deposit a second target resource into the i-th first sub-account based on the resource distribution share corresponding to the i-th rollup mode.

[0007] In a second aspect, a resource management method for a blockchain system is provided. The method is executed by a first blockchain system, wherein a relay contract is deployed in the first blockchain system. The method includes: receiving a first transaction initiated by a first account, the first transaction being used to invoke the relay contract, the first transaction indicating N rollup modes and their respective corresponding resource distribution shares; executing the relay contract based on the first transaction to: transfer a first target resource to the relay account based on the resource distribution shares corresponding to the N rollup modes, and generating a resource distribution event, the resource distribution event including the first account, the N rollup modes, and their respective corresponding resource distribution shares; the resource distribution event being used to support a second blockchain system in generating N sub-transactions, and by executing any i-th sub-transaction to: determine an i-th first sub-account corresponding to the first account and belonging to an i-th rollup mode among the N rollup modes, and deposit a second target resource into the i-th first sub-account based on the resource distribution share corresponding to the i-th rollup mode.

[0008] In a third aspect, a resource management method for a blockchain system is provided, the method being executed by a second blockchain system, the method comprising: obtaining a resource distribution event from a first blockchain system, wherein a relay contract is deployed in the first blockchain system, the resource distribution event being generated by the first blockchain system executing the relay contract according to a first transaction, the first transaction being initiated by a first account, the first transaction indicating N roll-up modes and their respective corresponding resource distribution shares; generating N sub-transactions based on the resource distribution event, wherein any i-th sub-transaction includes the first account, an i-th roll-up mode among the N roll-up modes, and its corresponding resource distribution share; executing the i-th sub-transaction to achieve: determining an i-th first sub-account belonging to the i-th roll-up mode and corresponding to the first account, and depositing a second target resource into the i-th first sub-account based on the resource distribution share corresponding to the i-th roll-up mode.

[0009] In a fourth aspect, a blockchain node in a first blockchain system is provided, wherein a relay contract is deployed in the first blockchain system, and the blockchain node includes: a transaction receiving unit, configured to receive a first transaction initiated by a first account, the first transaction is used to call the relay contract, and the first transaction indicates N folding modes and their respective corresponding resource distribution shares; a transaction execution unit, configured to execute the relay contract according to the first transaction, to achieve: transferring a first target resource to the relay account according to the resource distribution shares corresponding to the N folding modes, and generating a resource distribution event, the resource distribution event including the first account, the N folding modes, and their respective corresponding resource distribution shares; the resource distribution event is used to support a second blockchain system to generate N sub-transactions, and by executing any i-th sub-transaction, to achieve: determining an i-th first sub-account belonging to the i-th folding mode among the N folding modes and corresponding to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding mode.

[0010] In a fifth aspect, a second blockchain system is provided, including: a repeater, configured to obtain a resource distribution event from a first blockchain system, a relay contract being deployed in the first blockchain system, the resource distribution event being generated by the first blockchain system executing the relay contract according to a first transaction, the first transaction being initiated by a first account, and the first transaction indicating N types of folding modes and their respective corresponding resource distribution shares; the repeater is further configured to generate N sub-transactions according to the resource distribution event, and any i-th sub-transaction includes the first account, the i-th folding mode among the N types of folding modes, and its corresponding resource distribution share; a sorter is configured to execute the i-th sub-transaction to achieve: determining the i-th first sub-account belonging to the i-th folding mode and corresponding to the first account, and depositing the second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding mode.

[0011] In a sixth 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 second or third aspect is implemented.

[0012] In a seventh 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 second or third aspect.

[0013] In the technical solutions provided by the embodiments of this specification, the second blockchain system located at Layer 2 supports multiple rollup modes. Any user's multiple subaccounts in these multiple modes correspond to the user's first account in the first blockchain system located at Layer 1. The user simply initiates a first transaction in the first blockchain system using the first account and specifies in the first transaction the N rollup modes to which the N subaccounts in the second blockchain system to which the first target resource is to be transferred belong, as well as the resource distribution shares corresponding to each of the N rollup modes. The first blockchain system and the second blockchain system then collaborate to transfer the corresponding shares of the first target resource to the user's N subaccounts in the second blockchain system. This facilitates users to securely and conveniently manage the resources held by their multiple accounts in various rollup modes in the second blockchain system located at Layer 2 through their accounts registered in the first blockchain system located at Layer 1. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

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

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

[0025] FIG11 is a fourth flowchart of a resource method of a blockchain system provided in an embodiment of this specification. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

[0037] 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:

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

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

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

[0041] 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:

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

[0043] 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:

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

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

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

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

[0048] 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). The hash value of the Merkle Root is then filled into 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 transactions less than 2 n In the case of , the last transaction can be assigned multiple copies to make up 2 n , and thus calculate the root of the 2-fork Merkle tree. As shown in Figure 3, Tx23, which is the last transaction in chronological order, is repeated once to complete 4 transactions, even if the number of transactions reaches 2 2 , and then the root of the 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.

[0049] 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 for 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 for Batch M in the Post-State Root field of the Batch M header.

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

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

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

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

[0054] Continuing from the previous section, after receiving Transaction 1, which calls the Rollup Contract, Layer 1, through consensus, executes Transaction 1 on some nodes and combines Transaction 1 and its execution results with other transactions and their results to form a block, such as 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 and 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: function CommitBatch(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.

[0055] 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 is equivalent to executing a batch of transactions on Layer 2 at once, but only a single transaction on Layer 1. Furthermore, OP-Rollup does not include any proof. This assumes that the submitted Layer 2 information is free of fraud or malicious intent, hence its "optimistic" name. Despite this assumption, for preventive and deterrent purposes, traders submitting Layer 2 information are still required to stake a portion of Layer 1 assets (typically native on-chain tokens, such as Ethereum's Ether) in the OP-Rollup's Rollup Contract. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0082] Taking the second rollup mode to be registered 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 verification method TEE verifier corresponding to 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 interface Deposite() and the contract interface Withdraw() in the Bridge Contract, so that the account registered in the first blockchain system can increase the corresponding share of the second target resource for a sub-account belonging to TEE-Rollup in the second blockchain system by calling the contract interface Deposite(); and for the second target resource held by a sub-account belonging to TEE-Rollup in the second blockchain system, the contract interface Withdraw() can be called according to the corresponding policy to add the corresponding share of the first target resource to the account corresponding to the sub-account in the first blockchain system.

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

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

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

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

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

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

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

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

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

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

[0093] 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 state subtrees 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 state subtrees.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0107] 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 distribution shares corresponding to each of the N rollup modes. In addition, the Data field of the first transaction may also include the identification information of the second blockchain system and the identification information of the method function / contract interface in the Bridge Contract that the first transaction intends to call, such as the identification information of the contract interface Deposite() in the Bridge Contract.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0153] For example, in the case of a second rollup mode to be terminated that 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.

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

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

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

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

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

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

[0160] Based on the same concept as the aforementioned method embodiment, embodiments of this specification also provide a blockchain node in a first blockchain system, wherein a relay contract is deployed in the first blockchain system. The blockchain node includes: a transaction receiving unit configured to receive a first transaction initiated by a first account, the first transaction being used to invoke the relay contract, the first transaction indicating N rollup modes and their respective corresponding resource distribution shares; a transaction execution unit configured to execute the relay contract based on the first transaction to: transfer a first target resource to the relay account based on the resource distribution shares corresponding to the N rollup modes, and generate a resource distribution event, wherein the resource distribution event includes the first account, the N rollup modes, and their respective corresponding resource distribution shares; the resource distribution event is used to support a second blockchain system in generating N sub-transactions, and by executing any i-th sub-transaction, to: determine an i-th first sub-account corresponding to the first account and belonging to the i-th rollup mode among the N rollup modes, and deposit a second target resource into the i-th first sub-account based on the resource distribution share corresponding to the i-th rollup mode.

[0161] Based on the same concept as the aforementioned method embodiment, a second blockchain system is also provided in the embodiment of this specification, which includes: a repeater, configured to obtain a resource distribution event from the first blockchain system, a relay contract being deployed in the first blockchain system, and the resource distribution event being generated by the first blockchain system executing the relay contract according to a first transaction, the first transaction being initiated by a first account, and the first transaction indicating N types of roll-up modes and their respective corresponding resource distribution shares; the repeater is further configured to generate N sub-transactions based on the resource distribution event, and any i-th sub-transaction includes the first account, the i-th roll-up mode of the N types of roll-up modes, and its corresponding resource distribution share; a sorter is configured to execute the i-th sub-transaction to achieve: determining the i-th first sub-account belonging to the i-th roll-up mode and corresponding to the first account, and depositing the second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th roll-up mode.

[0162] A computer-readable storage medium is also provided in an embodiment of the present specification, on which a computer program / instruction is stored. When the computer program / instruction is executed in a computer, the computer executes the method steps performed by the computing device or data storage system in the aforementioned embodiments.

[0163] A computing device is also provided in an embodiment of this specification, including a memory and a processor, wherein the memory stores a computer program / instruction, and when the processor executes the computer program / instruction, the method steps performed by the computing device or data storage system in the aforementioned embodiments are implemented.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0178] 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, the method comprising: The first blockchain system receives a first transaction initiated by a first account, the first transaction being used to invoke a relay contract deployed by the first blockchain system, and the first transaction indicates N folding patterns and their respective corresponding resource distribution shares; The first blockchain system executes the relay contract according to the first transaction, and realizes: according to the resource distribution shares corresponding to the N folding patterns, transferring a first target resource to a relay account, and generating a resource distribution event, which includes the first account, the N folding patterns, and their respective corresponding resource distribution shares; The second blockchain system generates N sub-transactions according to the resource distribution event, and any i-th sub-transaction includes the first account, the i-th folding pattern among the N folding patterns, and its corresponding resource distribution share; The second blockchain system executes the i-th sub-transaction, and realizes: determining an i-th first sub-account belonging to the i-th folding pattern and corresponding to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding pattern.

2. The method according to claim 1, wherein the i-th first sub-account is obtained by derivative calculation based on the first account and the i-th folding pattern.

3. According to the method described in claim 1, depositing the second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th rolling and folding mode specifically includes: A relay sub-account subordinate to and corresponding to the relay account transfers the second target resource to the i-th first sub-account.

4. According to the method described in claim 1, the state tree corresponding to the world state of the second blockchain system includes M sub-state trees corresponding to M folding patterns, where M is not less than N; wherein, The second blockchain system executing the i-th sub-transaction further realizes: querying whether the i-th first sub-account exists in the sub-state tree corresponding to the i-th folding pattern, and if not, registering the i-th first sub-account in the sub-state tree corresponding to the i-th folding pattern.

5. The method according to claim 1, the method further comprising: The second blockchain system receives a second transaction initiated by the first account, and the second transaction indicates a resource transfer-out share and a first folding pattern; The second blockchain system executes the second transaction, and realizes: determining a second sub-account belonging to the first folding pattern and corresponding to the first account, and transferring the second target resource from the second sub-account to a relay sub-account belonging to the first folding pattern and corresponding to the relay account according to the resource transfer-out share; The second blockchain system sends a third transaction to the first blockchain system, the third transaction being used to invoke a first method function in a folding contract deployed by the first blockchain system, and the third transaction includes the first account and the resource transfer-out share; The first blockchain system executes the first method function according to the third transaction, and realizes: transferring the first target resource from the relay account to the first account according to the resource transfer-out share.

6. According to the method described in claim 5, the third transaction further includes the batch number of the third packaging transaction batch to which the second transaction belongs in the second blockchain system, and the transaction number of the second transaction in the third batch; wherein, The first blockchain system executes the first method function according to the third transaction, and specifically implements: according to the batch number, determine whether the third batch has entered an immutable state. If so, query whether the third batch includes the second transaction corresponding to the third transaction according to the transaction number. If so, transfer the first target resource from the relay account to the first account according to the resource transfer share.

7. The method according to claim 5, wherein the step of transferring the second target resource from the second sub-account according to the resource transfer share comprises: Transfer the second target resource from the second sub-account to the relay sub-account belonging to the first stacking mode according to the resource transfer share.

8. The method according to any one of claims 1-7, the method further comprising: The first blockchain system receives a fourth transaction, the fourth transaction is used to call a second method function in the stacking contract deployed by the first blockchain system, and the fourth transaction includes registration information corresponding to a second stacking mode to be registered; The first blockchain system executes the second method function according to the fourth transaction, and realizes: perform a first upgrade operation on the stacking contract and the relay contract according to the registration information, and generate a stacking registration event, where the stacking registration event includes at least part of the registration information in the registration information; The second blockchain system performs a second upgrade operation on the infrastructure of the second blockchain system according to the stacking registration event by using the at least part of the registration information; Among them, between the first blockchain system after the first upgrade operation and the second blockchain system after the second upgrade operation, stacking is supported to be implemented by using the second stacking mode.

9. The method according to claim 8, the method further comprising: The first blockchain system receives a fifth transaction, the fifth transaction is used to call a third method function in the stacking contract deployed by the first blockchain system, and the fifth transaction requests to terminate the second stacking mode; The first blockchain system executes the third method function according to the fifth transaction, and realizes: generate a stacking termination event, and perform a third upgrade operation on the stacking contract and the relay contract according to the registration information of the second stacking mode; The second blockchain system performs a fourth upgrade operation on the infrastructure of the second blockchain system according to the stacking termination event. Among them, between the first blockchain system after the third upgrade operation and the second blockchain system after the fourth upgrade operation, stacking by using the second stacking mode is no longer supported.

10. The method according to claim 9, the method further comprising: The second blockchain system generates a sixth transaction according to the stacking termination event; The second blockchain system executes the sixth transaction, and realizes: transfer the second target resource held by any first target sub-account belonging to the second stacking mode to a second target sub-account belonging to the third stacking mode, where the first target sub-account and the second target sub-account are correspondingly registered in the same target account in the first blockchain system.

11. A resource management method for a blockchain system, which is executed by a first blockchain system, and a relay contract is deployed in the first blockchain system. The method includes: Receiving a first transaction initiated by a first account, where the first transaction is used to invoke the relay contract, and the first transaction indicates N folding patterns and their respective corresponding resource distribution shares; Executing the relay contract according to the first transaction, to achieve: transferring a first target resource to a relay account according to the resource distribution shares corresponding to the N folding patterns respectively, and generating a resource distribution event, where the resource distribution event includes the first account, the N folding patterns, and their respective corresponding resource distribution shares; the resource distribution event is used to support the second blockchain system in generating N sub-transactions, and by executing any i-th sub-transaction, it is achieved that: determining the i-th first sub-account that belongs to the i-th folding pattern among the N folding patterns and corresponds to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding pattern.

12. A resource management method for a blockchain system, which is executed by a second blockchain system. The method includes: Obtaining a resource distribution event from a first blockchain system, where a relay contract is deployed in the first blockchain system, and 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 a first account, and the first transaction indicates N folding patterns and their respective corresponding resource distribution shares; Generating N sub-transactions according to the resource distribution event, and any i-th sub-transaction includes the first account, the i-th folding pattern among the N folding patterns, and its corresponding resource distribution share; Executing the i-th sub-transaction, to achieve: determining the i-th first sub-account that belongs to the i-th folding pattern and corresponds to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding pattern.

13. A blockchain node in a first blockchain system, where a relay contract is deployed in the first blockchain system. The blockchain node includes: A transaction receiving unit, configured to receive a first transaction initiated by a first account, where the first transaction is used to invoke the relay contract, and the first transaction indicates N folding patterns and their respective corresponding resource distribution shares; A transaction execution unit, configured to execute the relay contract according to the first transaction, and implement: transferring a first target resource to a relay account according to the resource distribution shares corresponding to the N folding patterns respectively, and generating a resource distribution event, where the resource distribution event includes the first account, the N folding patterns, and their respective corresponding resource distribution shares; the resource distribution event is used to support a second blockchain system to generate N sub-transactions, and by executing any i-th sub-transaction, it is implemented: determining the i-th first sub-account that belongs to the i-th folding pattern among the N folding patterns and corresponds to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding pattern.

14. A second blockchain system, comprising: A repeater, configured to obtain a resource distribution event from a first blockchain system, where a relay contract is deployed in the first blockchain system, the resource distribution event is generated by the first blockchain system according to a first transaction to execute the relay contract, the first transaction is initiated by a first account, and the first transaction indicates N folding patterns and their respective corresponding resource distribution shares; The repeater is further configured to generate N sub-transactions according to the resource distribution event, and any i-th sub-transaction includes the first account, the i-th folding pattern among the N folding patterns, and its corresponding resource distribution share; An orderer, configured to execute the i-th sub-transaction, and implement: determining the i-th first sub-account that belongs to the i-th folding pattern and corresponds to the first account, and depositing a second target resource into the i-th first sub-account according to the resource distribution share corresponding to the i-th folding pattern.

Images