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

Abstract

A method executed by a second blockchain system located at Lyaer2, comprising: by executing a seventh transaction received thereby, transferring a target resource from a first sub-account belonging to a first stack mode and corresponding to a first account to a first relay sub-account belonging to the first stack mode and corresponding to a relay account according to a resource transfer share; sending an eighth transaction to a first blockchain system, so that the first blockchain system processes stack data of a first batch to which the seventh transaction belongs; sending a ninth transaction to the first blockchain system, so that the first blockchain system verifies whether a plurality of transactions in the first batch are executed correctly, and generates an asset to be transferred event corresponding to the seventh transaction if the verification is passed; generating and executing a tenth transaction according to the asset to be transferred event, so as to transfer the target resource from a second relay sub-account belonging to a second stack mode and corresponding to the relay account to a second sub-account belonging to the second stack model and corresponding to a second account according to the resource transfer share.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the technical field of blockchains, and particularly relate to a resource management method of a blockchain system, a blockchain node and a blockchain system. BACKGROUND

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

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

[0004] In a first aspect, a management method of a blockchain system is provided, the method is executed by a second blockchain system, the second blockchain system supports M types of rollup modes, and the method comprises: receiving a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first rollup mode corresponding to the sender field and a second rollup mode corresponding to the receiver field; executing the seventh transaction to achieve: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first rollup mode and corresponding to the first account to a first relay sub-account belonging to the first rollup mode and corresponding to a relay account; sending an eighth transaction to a first blockchain system to call a fourth method function in a rollup contract deployed by the first blockchain system, so that the first blockchain system processes rollup data of a first batch of transactions batch to which the seventh transaction belongs; sending a ninth transaction to the first blockchain system to call a fifth method function in the rollup contract, so that the first blockchain system generates an asset transfer event corresponding to the seventh transaction after verifying that a plurality of transactions in the first batch have been correctly executed; generating a tenth transaction according to the asset transfer event corresponding to the seventh transaction, and executing the tenth transaction to achieve: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second rollup mode and corresponding to the relay account to a second sub-account belonging to the second rollup model and corresponding to the second account.

[0005] In a second aspect, a resource management method of a blockchain system is provided, executed by a first blockchain system in which a rollup contract is deployed, the rollup contract including a fourth method function and a fifth method function, the method comprising: receiving an eighth transaction from a second blockchain system, the eighth transaction being used to call the fourth method function, the eighth transaction including rollup data of a first batch of transactions of a seventh transaction, a sender field and a receiver field of the seventh transaction including a first account and a second account respectively, the seventh transaction further including a resource transfer share, a first rollup mode corresponding to the sender field, and a second rollup mode corresponding to the receiver field, the eighth transaction being initiated after a second target resource is transferred from a first sub-account belonging to the first rollup mode and corresponding to the first account to a first relay sub-account belonging to the first rollup mode and corresponding to a relay account according to the resource transfer share, the second target resource being transferred by executing the seventh transaction by the second blockchain system; executing the fourth method function according to the eighth transaction to process the rollup data of the first batch; receiving a ninth transaction from the second blockchain system, the ninth transaction being used to call the fifth method function, the ninth transaction including first proof data corresponding to the first rollup mode and the first batch; executing the fifth method function according to the ninth transaction to: verify whether a plurality of transactions in the first batch are correctly executed according to a verification method corresponding to the first rollup mode using the proof data corresponding to the first batch, and generate an asset to be transferred event corresponding to the seventh transaction if the verification is passed; wherein the asset to be transferred event is used to support the second blockchain system to generate a tenth transaction, and the second target resource is transferred from a second relay sub-account belonging to the second rollup mode and corresponding to the relay account to a second sub-account belonging to the second rollup mode and corresponding to the second account according to the resource transfer share by executing the tenth transaction.

[0006] In a third aspect, a second blockchain system is provided, comprising: a receiver configured to receive a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first rollup mode corresponding to the sender field, and a second rollup mode corresponding to the receiver field; an orderer configured to execute the seventh transaction, to achieve: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first rollup mode and corresponding to the first account to a first relay sub-account belonging to the first rollup mode and corresponding to a relay account; a relay configured to send an eighth transaction to a first blockchain system, to call a fourth method function in a rollup contract deployed by the first blockchain system, to enable the first blockchain system to process rollup data of a first batch of transactions to which the seventh transaction belongs; and send a ninth transaction to the first blockchain system, to call a fifth method function in the rollup contract, to enable the first blockchain system to generate an asset transfer event corresponding to the seventh transaction after verifying that a plurality of transactions in the first batch have been correctly executed; the orderer is configured to generate a tenth transaction according to the asset transfer event corresponding to the seventh transaction, and execute the tenth transaction, to achieve: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second rollup mode and corresponding to the relay account to a second sub-account belonging to the second rollup model and corresponding to the second account.

[0007] In a fourth aspect, a blockchain node in a first blockchain system is provided, wherein a rollup contract is deployed in the first blockchain system, the rollup contract comprising a fourth method function and a fifth method function, the blockchain node comprising: a transaction receiving unit configured to receive an eighth transaction from a second blockchain system, the eighth transaction being used to invoke the fourth method function, the eighth transaction comprising rollup data of a first batch of transactions of a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first rollup mode corresponding to the sender field, and a second rollup mode corresponding to the receiver field, the eighth transaction being initiated after a second target resource is transferred from a first sub-account corresponding to the first rollup mode and the first account to a first relay sub-account corresponding to the first rollup mode and a relay account according to the resource transfer share by executing the seventh transaction in the second blockchain system; a transaction executing unit configured to execute the fourth method function according to the eighth transaction to process the rollup data of the first batch; the transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction being used to invoke the fifth method function, the ninth transaction comprising first proof data corresponding to the first rollup mode and the first batch; the transaction executing unit is further configured to execute the fifth method function according to the ninth transaction to verify whether a plurality of transactions in the first batch are correctly executed according to a verification method corresponding to the first rollup mode by using the proof data corresponding to the first batch, and generate an asset to be transferred event corresponding to the seventh transaction in a case where the verification is passed; wherein the asset to be transferred event is used to support the second blockchain system to generate a tenth transaction, and to transfer the second target resource from a second relay sub-account corresponding to the second rollup mode and the relay account to a second sub-account corresponding to the second rollup mode and the second account according to the resource transfer share by executing the tenth transaction.

[0008] In a fifth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method in the first or second aspect.

[0009] In a sixth aspect, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed in a computing device, the computing device executes the method in the first or second aspect.

[0010] In the technical solutions provided by the embodiments of the present specification, M types of roll-up modes correspond to M different batch chains, which is beneficial for the second blockchain system to realize efficient submission of batches belonging to the M batch chains through parallel technology. In addition, the second blockchain system needs to generate the tenth transaction and execute the tenth transaction based on the asset transfer event corresponding to the seventh transaction after the first batch to which the seventh transaction belongs has entered an unchangeable state, thereby completing the resource transfer transaction expected to be completed by the seventh transaction, and the second batch to which the tenth transaction belongs will not be rolled back due to the execution failure of the first batch to which the seventh transaction belongs. BRIEF DESCRIPTION OF DRAWINGS

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

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

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

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

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

[0016] Figure 5 is a process diagram of registering a roll-up mode in an embodiment;

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

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

[0019] Figure 8 is a diagram of a client of a blockchain system and transactions initiated by the client in an embodiment;

[0020] Figure 9 is another flowchart of a resource management method of a blockchain system provided in the embodiments of the present specification;

[0021] Figure 10FIG. 3 is a flowchart of a resource management method of a blockchain system according to an embodiment of the present specification;

[0022] Figure 11 FIG. 4 is a flowchart of a resource management method of a blockchain system according to an embodiment of the present specification;

[0023] Figure 12 FIG. 5 is a flowchart of a resource management method of a blockchain system according to an embodiment of the present specification;

[0024] Figure 13 FIG. 6 is a structural diagram of a batch chain according to an embodiment of the present specification;

[0025] Figure 14 FIG. 7 is a diagram of event relationships according to an embodiment of the present specification. DETAILED DESCRIPTION

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

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

[0028] Ethereum (also known as "Mainnet" or "Layer 1", Mainnet or Layer 1; in addition, the current popular public chain projects such as Binance's BSC, TRON, etc. are also in the category of Layer 1 / Mainnet) chooses security and decentralization, sacrificing efficiency, and currently only has about 12-15 TPS. When there are a large number of transactions to be processed, especially many complex transactions, Layer 1 will be congested. In addition to ordinary transfer transactions, Layer 1 also serves as the main platform for popular applications such as DeFi (decentralized finance) and NFT (non-fungible token), and when transactions are prevalent, the congestion problem of Layer 1 becomes very serious, causing significant transaction delays.

[0029] High gas fees (gas fees or transaction fees) often become a barrier to transactions. Although it has shifted from PoW (Proof of Work) to PoS (Proof of Stake), this only changes the way blockchains obtain accounting rights, and the transaction fees paid to nodes that obtain accounting rights do not significantly decrease. This is because the design of gas fees is aimed at the consumption of nodes executing transactions (including executing smart contract code), and gas fees will not decrease without changing this part of the consumption. For example, the transaction fee for a decentralized exchange currency exchange transaction may exceed $100 when congested, which makes many users hesitant.

[0030] Layer 2 technology is an extension solution built on Layer 1, aiming to solve the low efficiency and high transaction fees of Layer 1. As shown in Figure 1 , transactions can be quickly executed on Layer 2, and Layer 2 will synchronize the final state back to Layer 1 at certain times. Layer 2 is used to provide high-speed transaction processing, while security and decentralization are left to Layer 1. In this way, the pressure on Layer 1 is reduced, and the gas fee for executing transactions on Layer 2 can be greatly reduced. The gas fee required to synchronize the final state (not all states on Layer 2) of transaction execution on Layer 2 back to Layer 1 can also be greatly reduced. The technology of building Layer 2 on Layer 1 actually separates the execution process of transactions or contracts from the saving of the final state, and the execution process is placed on Layer 2, and Layer 1 only needs to save the final state. In this design, the correctness of the execution process of transactions or contracts on Layer 2 needs to be ensured, and the state written to Layer 1 is consistent with the correct execution result on Layer 2.

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

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

[0033] The principle of Rollup can be shown in Figure 2 and Figure 3 . Figure 3

[0034] The transaction for creating a smart contract is sent to Layer 1, and after the consensus of Layer 1, each node on Layer 1 can execute the transaction, thereby completing the deployment of the contract. Specifically, it can be executed by the EVM / WASM of the blockchain node. EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it, which is one of the biggest improvements of Ethereum as a representative of blockchain 2.0 over blockchain 1.0. The smart contract published and invoked by the user in Ethereum can run on EVM. After executing the transaction of deploying the smart contract, a contract account corresponding to the smart contract is generated on Layer 1, which has an address on the chain and includes balance, nonce, Codehash of contract code, and Storage_Root of contract storage. Through Codehash and Storage_Root, the code and account storage of the contract can be saved in the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract causes the virtual account on the blockchain to contain the contract code and the account storage (Storage). Subsequently, the nodes on Layer 1 can receive transaction requests for invoking the deployed smart contract, which can include the address of the invoked contract, the function in the invoked contract, and the input parameters. Generally, after the consensus of the transaction request, each node of the blockchain can independently execute the specified invocation of the smart contract.

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

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

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

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

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

[0040] Tx_23: Bob -> Charlie 10; means Bob transfers 10 units of asset, such as ether, to Charlie;

[0041] Before the transactions in Batch 1 are executed, suppose there are 4 states in total, which are referred to as the initial states of Batch 1, i.e. Figure 3 the state values locked by Pre State Root, are respectively:

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

[0043] After the transactions in Batch 1 are executed, the 4 states are updated to the final states of Batch 1, i.e. Figure 3 the state values locked by Post State Root, are respectively:

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

[0045] In Layer 2, a Merkle tree can be used to organize the states before and after the transactions in Batch 1 are executed in sequence. As shown in Figure 3 in Layer 2, the transactions in a Batch and their related state changes can be organized together, for example, the hash values of the transactions in Batch 1 are organized according to a Merkle tree to obtain a Merkle root, which is locked in the header (Header) of the Batch. This header is similar to the block header in Layer 1, and this Merkle root is Tx_Root in the header of the Batch. Similarly, as mentioned earlier, all state values before the execution of the transactions in Batch 1 can be organized according to a Merkle tree to obtain a Merkle root, which is locked in the header of the Batch, i.e. Pre State Root; all state values after the execution of the transactions in Batch 1 in sequence can be organized according to a Merkle tree to obtain a Merkle root, which is locked in the header of the Batch, i.e. Post State Root. For Batch M, a timestamp (Timestamp) can also be set in the Header of the Batch to record the time when the Batch is generated, and other fields of information can also be set. For the M+1th Batch, the PreState Root in its Header is equal to the Post State Root in the Header of the Mth Batch, as represented by the connection between the two roots in Figure 3 Thus, the Batch forms a chain structure.

[0046] Layer 2 rollup mechanisms can include Optimistic-Rollup (OP-Rollup), ZK-Rollup (ZK stands for zero knowledge), TEE-Rollup, and others.

[0047] In the OP-Rollup mechanism, Layer 2 can be configured to include receivers, relays, and sequencers for the transaction pool (Txpool). In the ZK-Rollup and TEE-Rollup mechanisms, Layer 2 can also be configured to set up a Prover. For the TEE-Rollup mechanism, the Prover can be set up in the TEE.

[0048] The OP-Rollup mechanism is described below as an example. Figure 3 As shown in the diagram, assume that TxPool collects transactions Tx21, Tx23, Tx25, Tx22, Tx26, and Tx24. The Sequencer sorts and packages these transactions according to their timestamps. For example, it packages Tx21, Tx22, and Tx23 into Batch M, organizes the hash values ​​of these transactions into Merkle trees to generate a Merkle Root (i.e., the transaction root), and fills the Tx_Root field in the Header of the generated Batch M with the hash value of this Merkle Root. It should be noted that when calculating the root of the Merkle tree, generally for values ​​less than 2... n In this case, the last transaction can be assigned multiple times to fill in the 2. n This allows us to calculate the root of the binary Merkle tree. For example... Figure 3 In the middle, Tx23, which is the last in chronological order, was repeated once to make up the 4 transactions, even though the number of transactions reached 2. 2 This allows us to calculate the root of the binary Merkle tree. After sorting the transactions according to their timestamps, Sequencer packs Tx21, Tx22, and Tx23 into Batch M+1.

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

[0050] Then, the sequencer can send a transaction 1 to Layer 1 through the relayer, which calls the Rollup Contract. The transaction 1 includes some or all of the fields in the Batch M Header and the compressed transaction sequence Tx21, Tx22, Tx23. After compression, the space occupied by Tx21, Tx22, Tx23 can be greatly reduced. The interface in the called Rollup Contract can include storing the compressed transaction data (Tx21, Tx22, Tx23) in the calldata, which is a cheaper (lower gas fee) location. In the Ethereum smart contract, calldata is a special data location used to store input data through function calls. Specifically, calldata data is generally stored directly in the transaction data of Ethereum, which is generally more gas-efficient than other data locations (such as memory and storage). Although the process of compressing the transaction sequence included in the transaction Batch is omitted in this article, it can be understood that the transaction sequence included in any transaction Batch described below can be either a non-compressed transaction sequence or a compressed transaction sequence.

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

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

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

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

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

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

[0057] In a single-round interaction fraud proof implementation, the disputed transaction is replayed on Layer 1, and the invalid state is detected before submission. For example, Alice, as a validator, synchronizes the compressed data of OP-Rollup to Layer 1 and pledges a deposit. If the challenger Bob disputes the data, he needs to initiate a challenge within the window period (challenge period) and also pledge a deposit. The Rollup Contract of OP-Rollup will re-calculate the transactions in the block on Layer 1 to determine right or wrong. The deposit of the wrong party will be confiscated, and the correct party will be rewarded.

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

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

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

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

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

[0063] ZK-Rollup is different from Optimistic Rollup because ZK-Rollup uses zero-knowledge proof technology. ZK refers to the ability to prove something (a transaction or state) to another party without disclosing the necessary information. In ZK-Rollup, unlike OP-Rollup, a proof (including proof) is also generated for the transaction Batch in Layer2 (e.g., cryptographic proof algorithm such as ZK-SNARK), which can prove that the Post State Root is obtained after the correct execution of the transaction sequence in the corresponding transaction Batch based on the Pre State Root. This can be confirmed by verifying the proof without re-executing the transactions in the Batch.

[0064] The process of generating a proof can be that the Sequencer packages all the transactions in a Batch in Layer2 (including sender, receiver, amount) and other information such as Pre State Root, Post State Root, and Proving Key before and after the execution of the transactions in this Batch in Layer2 and sends it to a prover on Layer2. The prover converts this information into a special form called witness (witness). Select a part as public input and another part as private input. Then, the prover uses the zero-knowledge proof computing circuit (a specific algorithm) arranged in it to verify the validity and correctness of the public input + private input. If the verification is correct, the circuit execution is successful, otherwise the circuit execution fails. In the case of successful circuit execution, the prover can output a proof, which proves that the packaged data is valid and correct. Moreover, the volume of this proof is small, generally only a few dozen bytes. The above process of generating a proof is similar to the process of re-execution and contains a large amount of circuit calculation, which is more complex, so it is generally time-consuming. It should be noted that the private input cannot be deduced from the proof itself, only the party who knows the verification key of zk-SNARK can verify the proof encrypted with the corresponding creation key. The public input can be used to verify the validity and correctness of the packaged data, but cannot be used to obtain the specific content of the packaged data.

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

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

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

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

[0069] After the end of the challenge period corresponding to any transaction Batch submitted by Layer2, or after the proof corresponding to any transaction Batch is verified in the Rollup Contract of Layer2, the arbitrary Batch and its corresponding contract call transaction (such as transaction 1 used to call the Commit Batch() contract interface in the Rollup Contract) enter the unchangeable (Finality) state; at the same time, it means that each transaction in Layer2 belonging to the arbitrary Batch has entered the unchangeable state.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0085] The relay in the second blockchain system, for example, the shared bridge Bridge included in the relay, can listen to the rollup registration event in the first blockchain system, and then use at least part of the registration information included in the rollup registration event to perform a second upgrade operation on the infrastructure of the second blockchain system, so that the first blockchain system after the first upgrade operation and the second blockchain system after the second upgrade operation can realize network rollup through the newly registered second rollup mode.

[0086] The foregoing shared bridge Bridge can be an independent service or exist in the form of SDK. The Bridge can hold the relay account of the management member of the second blockchain system registered in the first blockchain system and the private key corresponding to the relay account, and then generate transactions using the relay account and send them to the first blockchain system according to certain rules, and 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, perform the following steps S605 and S607 based on the rollup registration event.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0109] The first blockchain system may, for example, execute Deposite() in the Bridge Contract according to the first transaction, so as to achieve the generation of the resource distribution event. In a 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, a management member of the second blockchain system can register a relay account corresponding to the second blockchain system, such as account A, in the first blockchain system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0131] The Sequencer of the second blockchain system can pull multiple transactions from the transaction pool corresponding to the first rollup mode, sort, execute and generate corresponding packaged transactions. In combination with the foregoing, it can be understood that when the Sequencer executes the second transaction: in one possible implementation, the first account and the first rollup mode included in the second transaction can be used to derive the second sub-account that belongs to the first rollup mode and corresponds to the first account; in another possible implementation, the second sub-account can be obtained by querying the mapping relationship table maintained in the second blockchain system.

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

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

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

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

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

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

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

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

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

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

[0142] The management member of the second blockchain system can initiate the fifth transaction in the first blockchain system, and the fifth transaction is used to call the third method function in the Rollup Contract, wherein the second rollup mode to be terminated can be indicated.

[0143] Step S1103, the first blockchain system executes the third method function according to the fifth transaction, and realizes: generating a rollup termination event, and performing a third upgrade operation on the rollup contract and the relay contract according to the registration information of the second rollup mode.

[0144] The third upgrade operation corresponds to the first upgrade operation described above.

[0145] Taking the TEE-Rollup to be terminated as an example, the third upgrade operation on the Rollup Contract can include but is not limited to deleting or disabling the verification method TEE verifier corresponding to the TEE-Rollup in the Rollup Contract. The third upgrade operation on the Bridge Contract can include but is not limited to reconfiguring the contract interface Deposite() and the contract interface Withdraw() in the Bridge Contract, so that the account registered in the first blockchain system cannot add the second target resource to the certain sub-account belonging to the TEE-Rollup in the second blockchain system by calling the contract interface Deposite(), and the certain sub-account belonging to the TEE-Rollup in the second blockchain system cannot add the first target resource to the account corresponding to the sub-account in the first blockchain system based on the share of the second target resource held by the sub-account.

[0146] The rollup termination event can indicate the second rollup mode to be terminated, for example, including the identification information of the second rollup mode.

[0147] The relay in the second blockchain system, for example, the Bridge included in the relay, can listen to 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 the first blockchain system after the third upgrade operation and the second blockchain system after the fourth upgrade operation no longer support the rollup implemented by using the second rollup mode.

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

[0149] At step S1105, the second blockchain system generates a second upgrade transaction via the relay, the second upgrade transaction indicating the second rollup mode to be terminated.

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

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

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

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

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

[0155] The second upgrade transaction can be a special transaction, which can not be packaged into the batch transaction submitted by the second blockchain system. Illustratively, the Bridge included in the relay can make the Sequencer of the second blockchain system accurately know that the sixth transaction is a special transaction by specially setting the sender field and the receiver field of the sixth transaction, for example, setting the From field and the To field to Null, and setting the FR field corresponding to the From field and the TR field corresponding to the To field to the second rollup mode, and execute the transaction expected to be executed by the sixth transaction and not package it into the batch.

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

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

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

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

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

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

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

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

[0164] The second blockchain system not only can receive transactions from its clients, but also can initiate transactions that need to be executed by the second blockchain system through the shared bridge Bridge included in the relay, for example, the Bridge can initiate the foregoing ZK sub-transaction and the TEE sub-transaction, and the like. For transactions that need to be executed by the second blockchain system, the transaction can be added to the corresponding transaction pool according to the field value under the FR field corresponding to the From field in the transaction. For example, for the seventh transaction, the field value under the FR field corresponding to the From field is ZK-Rollup, and the seventh transaction can be added to the corresponding ZK Txpool.

[0165] The M kinds of rollup modes in the second blockchain system use M different batch chains, and each batch chain includes a plurality of batches connected in sequence. For a plurality of transactions belonging to the same batch, the rollup mode included in the FR field needs to remain the same. In the batch header of any batch, in addition to including the conventional Prev Hash, Nonce, Batch Num (batch serial number), Tx_Root, State_Root and Receipt_Root, the batch corresponding rollup mode can also be included. Referring to Figure 13 As shown in FIG. 9, for any batch in the batch chain corresponding to the ZK-Rollup, such as batch 2, the batch header of the batch 2 includes the ZK-Rollup, and the FR field corresponding to the From field of the plurality of transactions included in the batch 2 is the ZK-Rollup; for any batch in the batch chain corresponding to the TEE-Rollup, such as batch 2, the batch header of the batch 2 includes the TEE-Rollup, and the FR field corresponding to the From field of the plurality of transactions included in the batch 2 is the TEE-Rollup.

[0166] It should be noted that when the M kinds of rollup modes use M different batch chains, for any batch in the jth batch chain corresponding to the jth rollup mode, the State_Root included in the batch header of the batch is the state root of the sub-state tree corresponding to the jth rollup mode in the world state tree of the second blockchain system, rather than the state root of the entire world state of the second blockchain system, Global state root. For example, please refer to Figure 7 and Figure 13 For any batch included in the batch chain corresponding to the ZK-Rollup in Figure 13 , such as batch 2, the State_root included in the batch header can be Figure 7 the state root of the sub-state tree corresponding to the ZK-Rollup in the state tree corresponding to the world state of the second blockchain system as shown in FIG. 9; correspondingly, for any batch included in the batch chain corresponding to the TEE-Rollup in Figure 13 , such as batch 2, the State_root included in the batch header can be Figure 7 the state root of the sub-state tree corresponding to the TEE-Rollup in the state tree corresponding to the world state of the second blockchain system as shown in FIG. 9.

[0167] Since M different batch chains are used for M different rollup modes, the Sequencer of the second blockchain system can be implemented in parallel without interference: packaging and executing transactions in the M transaction pools corresponding to the M rollup modes. Obviously, the Sequencer can also sequentially package and execute transactions in the M transaction pools in a certain order by other means such as time slicing.

[0168] In summary, when the seventh transaction is added to the transaction pool corresponding to the first rollup mode, the Sequencer of the second blockchain system can perform the following steps S1203 at a certain time: pulling a plurality of transactions from the transaction pool corresponding to the first rollup mode, sorting and packaging the plurality of transactions, wherein the plurality of transactions include the seventh transaction.

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

[0170] The Sequencer sorts and packages a plurality of transactions pulled from the ZK Txpool, and executes the plurality of transactions packaged into batch k in order according to the state data corresponding to the previous batch of batch k. Therefore, when the plurality of transactions in batch k include the seventh transaction, the Sequencer of the second blockchain system will perform step S1205.

[0171] In step S1205, the second blockchain system executes the seventh transaction to achieve: transferring the second target resource from the first sub-account corresponding to the first account and belonging to the first rollup mode to the first relay sub-account corresponding to the relay account and belonging to the first rollup mode according to the resource transfer share.

[0172] During the execution of the seventh transaction by the Sequencer, the first sub-account corresponding to the first account and belonging to the first rollup mode can be determined first, and the first relay sub-account corresponding to the relay account and belonging to the first rollup mode can be determined according to the pre-configured relay account. For example, the Sequencer can determine the first sub-account and the first relay sub-account by using the derivation calculation or the mapping relationship table described above, and the details are not repeated here.

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

[0174] After the sequencer completes the execution of the plurality of transactions belonging to batch k, referring to the foregoing, the sequencer can obtain the pre-state root (Pre State Root), the post-state root (Post State Root), the batch number k, the transaction sequence composed of the plurality of transactions, and the like of the batch k. It should be noted that the Pre State Root here refers to the state root (e.g., ZK state root) of the sub-state tree corresponding to the first rollup mode in the state tree corresponding to the world state of the second blockchain system before the plurality of transactions in batch k are executed; the Post State Root refers to the state root of the sub-state tree corresponding to the first rollup mode in the state tree corresponding to the world state of the second blockchain system after the plurality of transactions in batch k are executed.

[0175] Moreover, in order to distinguish batches belonging to different batch chains, the rollup data of the first batch to which the seventh transaction belongs can further include the first rollup mode corresponding to the batch chain to which the first batch belongs.

[0176] Correspondingly, the second blockchain system can further perform step S1207, and send the eighth transaction to the first blockchain system, the eighth transaction being used to call the fourth method function in the Rollup Contract deployed by the first blockchain system, and the rollup data of the first batch to which the seventh transaction belongs being included in the eighth transaction.

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

[0178] Correspondingly, the first blockchain system can perform step S1209, execute the fourth method function in the Rollup Contract according to the eighth transaction, and realize processing of the rollup data of the first batch to which the seventh transaction belongs.

[0179] Referring back to the foregoing, the rollup data of the first batch, i.e., batch k, can include: the first rollup mode, the pre-state root, the post-state root, the batch sequence number k, a transaction sequence composed of a plurality of transactions belonging to batch k, and the like. The process of processing the rollup data of batch k can include: verifying whether the Pre State Root in the eighth transaction is equal to the Current State Root corresponding to the first rollup mode in the Rollup Contract contract storage, and if so, storing the transaction sequence in the eighth transaction in the calldata, and updating the Current State Root corresponding to the first rollup mode in the Rollup Contract contract storage to the Post State Root; and setting the position index of the transaction sequence in the calldata according to the first rollup mode and the batch sequence number k.

[0180] Referring back to the foregoing Rollup mechanism, after the second blockchain system completes the submission of the first batch, i.e., batch k, through the foregoing step S1209, the second blockchain system also needs to submit the first proof data corresponding to the first batch to the first blockchain system through the first prover corresponding to the first rollup mode. That is, the second blockchain system can also perform the following step S1211.

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

[0182] The data format of the first proof data can be referred to the foregoing description related to the Rollup mechanism, and will not be repeated here.

[0183] Correspondingly, in step S1213, the first blockchain system executes the fifth method function according to the ninth transaction, which realizes: according to the verification method corresponding to the first rollup mode, using the proof data corresponding to the first batch, verifying whether the plurality of transactions in the first batch are executed correctly, and generating an asset to be transferred event corresponding to the seventh transaction in the case of passing the verification.

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

[0185] In an exemplary rule, if the account under the From field in a transaction is not a relay account, and the rollup modes included in the FR field and the TR field are different, an asset to be transferred event can be generated for the transaction; if the account under the From field in a transaction is a relay account, an asset transfer completion event can be generated for the transaction. Based on the exemplary rule and the data structure of the seventh transaction described above, it is not difficult to understand that an asset to be transferred event can be generated for the seventh transaction.

[0186] The Bridge Contract can also maintain a set of events allowed to be consumed. For the asset to be transferred event, the intrac on call can be made through the fifth method function, or the Bridge Contract can enable the corresponding event listening mechanism to ultimately realize the addition of the asset to be transferred event to the set of events maintained in the Bridge Contract.

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

[0188] Referring to Figure 14As shown, for the asset transfer completion event corresponding to a certain transaction, the Topic field is indicated by the field value E2 that the event belongs to the asset transfer completion event. In addition, the Data field of the asset transfer completion event can also include: a sub-field To for storing the account in the To field of the corresponding transaction; a sub-field TR for storing the rollup mode in the TR field of the corresponding transaction; and a sub-field FE for storing the resource transfer share included in the Data field of the corresponding transaction.

[0189] The asset transfer completion event is used to support the Bridge Contract to match the asset transfer to be transferred event in the event set, so as to confirm that the asset transfer transaction expected to be executed by the transaction corresponding to the asset transfer to be transferred event has been completed. For example, please continue to refer to Figure 14 As shown in the asset transfer completion event and the asset transfer to be transferred event, if it is found through matching of the Data fields of the two events that the accounts in the sub-field To field, the rollup modes in the sub-field TR field, and the resource transfer shares included in the FE field of the respective Data fields are all the same, the matching is successful.

[0190] After the first blockchain system generates the asset transfer to be transferred event corresponding to the seventh transaction, the shared bridge Bridge included in the relay of the second blockchain system can listen to the asset transfer to be transferred event, and then can continue to perform the following step S1215.

[0191] Step S1215, the second blockchain system generates a tenth transaction according to the asset transfer to be transferred event corresponding to the seventh transaction, the sender field and the receiver field of the tenth transaction include the relay account and the second account respectively, and the tenth transaction further includes the resource transfer share and the second rollup mode.

[0192] The information in the tenth transaction other than the relay account can come from the asset transfer to be transferred event corresponding to the seventh transaction. Continuing the example in the preceding text, the From field of the tenth transaction can include account A, the To field can include account A2, the FR field corresponding to the From field can include TEE-Rollup, the TR field corresponding to the To field can include TEE-Rollup, and the Data field can include resource transfer share T. Correspondingly, because the field value in the FR field corresponding to the From field in the tenth transaction is TEE-Rollup, the tenth transaction will be added to the corresponding TEE Txpool.

[0193] When the tenth transaction is added to the transaction pool corresponding to the second rollup mode, the Sequencer of the second blockchain system can at some time perform the following steps S1217: pulling a plurality of transactions from the transaction pool corresponding to the second rollup mode, sorting and packaging the plurality of transactions, wherein the plurality of transactions includes the tenth transaction.

[0194] Taking that the tenth transaction is packaged into the batch b (i.e., the second batch) included in the batch chain corresponding to the TEE-Rollup as an example.

[0195] The Sequence pulls a plurality of transactions from the TEE Txpool for sorting and packaging, and according to the state data corresponding to the previous batch of the batch b, executes the plurality of transactions packaged into the batch b in the order of the sorting result. Therefore, when the plurality of transactions in the batch b includes the tenth transaction, the Sequence of the second blockchain system will perform step S1219.

[0196] In step S1219, the second blockchain system executes the tenth transaction to achieve: transferring the second target resource from the second relay sub-account belonging to the second rollup mode and corresponding to the relay account to the second sub-account belonging to the second rollup model and corresponding to the second account according to the resource transfer share.

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

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

[0199] In the foregoing method embodiments, since the M types of rollup modes correspond to M different batch chains, the blockchain system can use parallel technology to efficiently submit each batch belonging to the M batch chains. In addition, the second blockchain system needs to generate and execute the tenth transaction based on the asset transfer event corresponding to the seventh transaction after the first batch to which the seventh transaction belongs has entered an unchangeable state, thereby completing the resource transfer transaction expected to be completed by the seventh transaction, and the second batch to which the tenth transaction belongs will not be rolled back due to the failure of the execution of the first batch to which the seventh transaction belongs.

[0200] However, referring to the foregoing exemplary description of the ZK-Rollup mechanism and the TEE-Rollup mechanism, the second blockchain system needs to submit the corresponding batch and the proof data corresponding to the batch to the first blockchain system after completing the execution of the multiple transactions belonging to the batch. Moreover, the following situation can occur: after the first batch to which the seventh transaction belongs has entered an unchangeable state, the tenth transaction fails to be successfully executed due to some reasons, or even fails to be successfully generated due to some reasons, thereby causing the resource transfer transaction expected to be completed by the seventh transaction to be inaccurately completed.

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

[0202] In the foregoing, after the Sequencer completes the execution of the multiple transactions belonging to the batch b, the Sequencer can obtain the rollup data such as the pre-state root (Pre State Root) corresponding to the batch b, the post-state root (Post State Root), the batch number b, and the transaction sequence formed by the multiple transactions. It should be noted that the Pre State Root here refers to the state root of the sub-state tree corresponding to the second rollup mode in the state tree corresponding to the world state of the second blockchain system before the multiple transactions in the batch b are executed, and the Post State Root refers to the state root of the sub-state tree corresponding to the second rollup mode in the state tree corresponding to the world state of the second blockchain system after the multiple transactions in the batch k are executed.

[0203] Moreover, in order to distinguish between batches belonging to different batch chains, the rollup data of the second batch to which the tenth transaction belongs can further include the second rollup mode corresponding to the batch chain to which the second batch belongs.

[0204] Based on the rollup data of the second batch to which the tenth transaction belongs, the first blockchain system can further perform the following step S1221, and send an eleventh transaction to the first blockchain system, the eleventh transaction being used to call a fourth method function in the Rollup Contract deployed by the first blockchain system, and the rollup data of the second batch being included in the eleventh transaction.

[0205] Correspondingly, the first blockchain system can further perform step S1223, and execute the fourth method function in the Rollup Contract according to the eleventh transaction, so as to process the rollup data of the second batch to which the tenth transaction belongs.

[0206] As described above, the rollup data of the second batch, i.e., batch b, can include a second rollup mode, a pre-state root, a post-state root, a batch serial number b, and a transaction sequence composed of a plurality of transactions belonging to batch b. The process of processing the rollup data of batch b can include: verifying whether the Pre State Root in the tenth transaction is equal to the Current State Root corresponding to the second rollup mode in the Rollup Contract storage, equaling to store the transaction sequence in the eleventh transaction in the calldata, and updating the Current State Root corresponding to the second rollup mode in the Rollup Contract storage to the Post State Root; and setting the position index of the transaction sequence in the calldata according to the second rollup mode and the batch serial number b.

[0207] Referring to the Rollup mechanism described above, after the second batch, i.e., batch b, is submitted by the second blockchain system through the aforementioned step S1223, the second blockchain system further needs to submit second proof data corresponding to the second batch to the first blockchain system through a second prover corresponding to the second rollup mode. That is, the second blockchain system can further perform the following step S1225.

[0208] In step S1225, the second blockchain system sends a twelfth transaction to the first blockchain system through a second prover corresponding to the second rollup mode, the twelfth transaction being used to call a fifth method function in the Rollup, and the second rollup mode and the second proof data corresponding to the second batch being included in the twelfth transaction.

[0209] The data structure of the second proof data can refer to the description of the Rollup mechanism described above, and will not be described here again.

[0210] Correspondingly, in step S1227, the first blockchain system executes the fifth method function in the Rollup Contract according to the twelfth transaction, to achieve: according to the verification method corresponding to the second rollup mode, using the second proof data corresponding to the second batch, verifying whether the multiple transactions in the second batch are executed correctly, and generating the asset transfer completion event corresponding to the tenth transaction in the case of passing the verification.

[0211] When the second rollup mode includes the TEE-Rollup mode, the fifth method function in the Rollup Contract may, for example, according to the TEE-Rollup included in the twelfth transaction, call the verification method TEE verifier corresponding to the TEE-Rollup in the contract, process the second proof data included in the twelfth transaction through the TEE verifier, complete the verification of whether the multiple transactions in the second batch are executed correctly. If the verification passes, the second batch enters an unchangeable state; at the same time, the fifth method function itself, or through the in-contract call to the Bridge Contract, generates the asset transfer completion event for some specific data format of transaction, and generates the asset transfer completion event for some specific data format of transaction.

[0212] Referring to the content under the aforementioned step S1213, the asset transfer completion event generated by the tenth transaction can be used to consume the asset transfer pending event corresponding to the seventh transaction in the event set maintained by the Bridge Contract, thereby confirming that the transaction expected to be completed by the seventh transaction is successfully executed. When the seventh transaction is successfully executed and the tenth transaction is successfully executed, the asset transfer pending event and the asset transfer completion event shown in the above table can be correspondingly generated, and the two events will be successfully matched. Figure 14

[0213] Through the foregoing steps S1221-S1227, for the case that the seventh transaction described above is successfully executed and the tenth transaction is not successfully executed, the asset transfer pending event corresponding to the seventh transaction in the event set cannot be consumed, and the management member can confirm that the resource transfer transaction expected to be completed by the seventh transaction is not successfully executed by querying the event set, and return the corresponding second target resource to the sub-account belonging to the first rollup mode and corresponding to the first account based on the asset transfer pending event corresponding to the seventh transaction.

[0214] ​The technical solutions described in the foregoing method steps S1201-S1227 mainly describe the process of transferring resources from a first sub-account belonging to a first stacking mode and corresponding to a first account to a second sub-account belonging to a second stacking mode (different from the first stacking mode) and corresponding to a second account. However, in some technical scenarios, the FR field and the TR field of some transactions may include the same stacking mode, and in this case, the transaction desired to be completed can be completed through other ways.

[0215] In a possible implementation, the second blockchain system can receive a thirteenth transaction, the sender field and the receiver field of the thirteenth transaction including the first account and the second account respectively, and the thirteenth transaction further including a resource transfer share, a first stacking mode corresponding to the sender field, and a first stacking mode corresponding to the receiver field; in this case, when the second blockchain system packs the thirteenth transaction into a batch corresponding to the first stacking mode, for example, the fourth batch, and executes the thirteenth transaction, the second target resource can be directly transferred from a first sub-account belonging to the first stacking mode and corresponding to the first account to a third sub-account belonging to the first stacking mode and corresponding to the second account according to the resource transfer share.

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

[0217] Based on the same idea as the foregoing method embodiments, the present specification embodiments also provide a second blockchain system supporting M folding modes, comprising: a receiver configured to receive a seventh transaction, the sender field and the receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; an orderer configured to execute the seventh transaction, achieving: according to the resource transfer share, transferring a second target resource from a first sub-account belonging to the first folding mode and corresponding to the first account to a first relay sub-account belonging to the first folding mode and corresponding to a relay account; a relay configured to send an eighth transaction to a first blockchain system, for calling a fourth method function in a folding contract deployed by the first blockchain system, so that the first blockchain system processes folding data of a first batch transaction batch to which the seventh transaction belongs; and send a ninth transaction to the first blockchain system, for calling a fifth method function in the folding contract, so that the first blockchain system verifies whether a plurality of transactions in the first batch are correctly executed according to a verification method corresponding to the first folding mode, using first proof data corresponding to the first batch, and generates an asset to be transferred event corresponding to the seventh transaction in the case of passing the verification; the orderer is configured to generate a tenth transaction according to the asset to be transferred event corresponding to the seventh transaction, and execute the tenth transaction, achieving: according to the resource transfer share, transferring a second target resource from a second relay sub-account belonging to the second folding mode and corresponding to the relay account to a second sub-account belonging to the second folding mode and corresponding to the second account.

[0218] Based on the same idea as the foregoing method embodiments, the present specification embodiments also provide a blockchain node in a first blockchain system, wherein a rollup contract is deployed in the first blockchain system, the rollup contract comprises a fourth method function and a fifth method function, and the blockchain node comprises: a transaction receiving unit configured to receive an eighth transaction from a second blockchain system, the eighth transaction being used to call the fourth method function, the eighth transaction comprising rollup data of a first batch of transactions of a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first rollup mode corresponding to the sender field, and a second rollup mode corresponding to the receiver field, the eighth transaction being initiated after a second target resource is transferred from a first sub-account belonging to the first rollup mode and corresponding to the first account to a first relay sub-account belonging to the first rollup mode and corresponding to a relay account according to the resource transfer share, the second target resource being realized by executing the seventh transaction in the second blockchain system; a transaction execution unit configured to execute the fourth method function according to the eighth transaction to realize processing of the rollup data of the first batch; the transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction being used to call the fifth method function, the ninth transaction comprising first proof data corresponding to the first rollup mode and the first batch; the transaction execution unit is further configured to execute the fifth method function according to the ninth transaction to realize: verifying whether a plurality of transactions in the first batch are correctly executed according to a verification method corresponding to the first rollup mode by using the proof data corresponding to the first batch, and generating an asset to be transferred event corresponding to the seventh transaction in a case of passing the verification; wherein the asset to be transferred event is used to support the second blockchain system to generate a tenth transaction, and to realize transferring the second target resource from a second relay sub-account belonging to the second rollup mode and corresponding to the relay account to a second sub-account belonging to the second rollup mode and corresponding to the second account according to the resource transfer share by executing the tenth transaction.

[0219] The present specification embodiments also provide a computer readable storage medium having computer programs / instructions stored thereon, when the computer programs / instructions are executed in a computer, the computer is caused to execute the method steps performed by the first blockchain system or the second blockchain system in the foregoing various embodiments.

[0220] The embodiments of the present specification also provide a computing device, comprising a memory and a processor, wherein the memory stores computer programs / instructions, and the processor executes the computer programs / instructions to realize the method steps executed by the first blockchain system or the second blockchain system in the foregoing various embodiments.

[0221] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) such as a field programmable gate array (FPGA) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a piece of PLD by the designer programming it by himself, without having to ask a chip manufacturer to design and manufacture a special integrated circuit chip. Moreover, instead of manually fabricating an integrated circuit chip, this programming is now mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing a program, and the original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there are many types of HDL, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit that implements the logical method flow can be easily obtained.

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

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

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

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

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

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

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

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

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

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

[0232] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0233] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0234] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the use of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the specification. Illustrative descriptions of the above terms do not necessarily refer to the same embodiment or example in this specification. Moreover, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine the features of different embodiments or examples and characteristics of different embodiments or examples, without contradiction.

[0235] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. A resource management method of a blockchain system, the method being performed by a second blockchain system supporting M folding modes, the method comprising: receiving a seventh transaction, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field; executing the seventh transaction to achieve: transferring, according to the resource transfer share, a second target resource from a first sub-account belonging to the first folding mode and corresponding to the first account to a first relay sub-account belonging to the first folding mode and corresponding to a relay account; sending an eighth transaction to a first blockchain system to invoke a fourth method function in a folding contract deployed by the first blockchain system to cause the first blockchain system to process folding data of a first batch of transactions batch to which the seventh transaction belongs; sending a ninth transaction to the first blockchain system to invoke a fifth method function in the folding contract to cause the first blockchain system to generate an asset transfer event corresponding to the seventh transaction after verifying that a plurality of transactions in the first batch of transactions batch have been correctly executed; generating a tenth transaction according to the asset transfer event corresponding to the seventh transaction, and executing the tenth transaction to achieve: transferring, according to the resource transfer share, the second target resource from a second relay sub-account belonging to the second folding mode and corresponding to the relay account to a second sub-account belonging to the second folding mode and corresponding to the second account. 2.The method of claim 1, wherein the world state of the second blockchain system corresponds to a state tree including M sub-state trees corresponding to the M rollup modes. A state root included in a batch header of the first batch of transactions batch to which the seventh transaction belongs is a state root of a sub-state tree corresponding to the first folding mode.

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

4. The method of claim 1, wherein the second blockchain system comprises M transaction pools corresponding to the M folding modes; the seventh transaction is buffered in a transaction pool corresponding to the first folding mode before being executed; and the tenth transaction is buffered in a transaction pool corresponding to the second folding mode before being executed.

5. The method of claim 4, further comprising: Before executing the seventh transaction, a plurality of transactions belonging to the first batch of transactions batch are pulled from the transaction pool corresponding to the first folding mode, sorted and packed, the plurality of transactions including the seventh transaction.

6. The method of claim 4, further comprising: Before executing the tenth transaction, a plurality of transactions belonging to the second batch are pulled from the transaction pool corresponding to the second folding mode, sorted and packed, the plurality of transactions including the tenth transaction.

7. The method of claim 1, further comprising: sending a eleventh transaction to the first blockchain system, for invoking a fourth method function in a rollup contract deployed by the first blockchain system, so that the first blockchain system processes rollup data in a second batch to which the tenth transaction belongs; sending a twelfth transaction to the first blockchain system, for invoking a fifth method function in the rollup contract, so that the first blockchain system verifies whether the plurality of transactions in the second batch are executed correctly according to a verification method corresponding to the second rollup mode by using second proof data corresponding to the second batch, and generates an asset transfer completion event corresponding to the tenth transaction if the verification is passed.

8. The method of claim 7, wherein the asset transfer completion event corresponding to the tenth transaction and the asset to be transferred event corresponding to the seventh transaction are used to support the first blockchain system to determine that the resource transfer according to the seventh transaction is completed when the first blockchain system successfully matches the asset transfer completion event and the asset to be transferred event.

9. The method of any one of claims 1-8, further comprising: obtaining a resource distribution event from the first blockchain system, the first blockchain system deploying a relay contract, the resource distribution event being generated by the first blockchain system according to execution of the relay contract by a first transaction, the first transaction being initiated by the first account, the first transaction indicating N rollup modes of the M rollup modes and a resource distribution share corresponding to each of the N rollup modes; generating N sub-transactions according to the resource distribution event, any ith sub-transaction including the first account, an ith rollup mode of the N rollup modes, and a resource distribution share corresponding to the ith rollup mode; executing the ith sub-transaction to achieve depositing a second target resource into an ith first sub-account belonging to the ith rollup mode and corresponding to the first account according to the resource distribution share corresponding to the ith rollup mode.

10. The method of claim 9, wherein the ith first sub-account is derived based on the first account and the ith rollup mode. 11.The method of claim 9, wherein the world state of the second blockchain system corresponds to a state tree including M sub-state trees corresponding to the M rollup modes. The execution of the ith sub-transaction further achieves querying whether the ith first sub-account exists in a sub-state tree corresponding to the ith rollup mode, and registering the ith first sub-account in the sub-state tree corresponding to the ith rollup mode if the ith first sub-account does not exist.

12. A resource management method of a blockchain system, executed by a first blockchain system, the first blockchain system deploying a rollup contract, the rollup contract including a fourth method function and a fifth method function, the method comprising: receive, from the second blockchain system, an eighth transaction, the eighth transaction being used to invoke the fourth method function, the eighth transaction comprising folded data of a first batch of transactions to which the seventh transaction belongs, the sender field and the receiver field of the seventh transaction comprising the first account and the second account respectively, the seventh transaction further comprising a resource transfer share, a first folding mode corresponding to the sender field, and a second folding mode corresponding to the receiver field, the eighth transaction being initiated after the second target resource is transferred from a first sub-account belonging to the first folding mode and corresponding to the first account to a first relay sub-account belonging to the first folding mode and corresponding to a relay account according to the resource transfer share after the second blockchain system implements by executing the seventh transaction; execute the fourth method function according to the eighth transaction, to implement processing of the folded data of the first batch of transactions; receive, from the second blockchain system, a ninth transaction, the ninth transaction being used to invoke the fifth method function, the ninth transaction comprising first proof data corresponding to the first folding mode and the first batch of transactions; execute the fifth method function according to the ninth transaction, to implement: verifying, according to a verification method corresponding to the first folding mode, whether the plurality of transactions in the first batch of transactions are executed correctly by using the first proof data corresponding to the first batch of transactions, and generating an asset transfer pending event corresponding to the seventh transaction in a case where the verification is passed; wherein the asset transfer pending event is used to support the second blockchain system to generate a tenth transaction, and to implement, by executing the tenth transaction: transferring the second target resource from a second relay sub-account belonging to the second folding mode and corresponding to the relay account to a second sub-account belonging to the second folding mode and corresponding to the second account according to the resource transfer share.

13. The method of claim 12, further comprising: receiving, from the second blockchain system, an eleventh transaction, the eleventh transaction being used to invoke the fourth method function, the eleventh transaction comprising folded data of a second batch to which the tenth transaction belongs; executing the fourth method function according to the eleventh transaction, to implement processing of the folded data of the second batch; receiving, from the second blockchain system, a twelfth transaction, the twelfth transaction being used to invoke the fifth method function, the twelfth transaction comprising second proof data corresponding to the second folding mode and the second batch; executing the fifth method function according to the twelfth transaction, to implement: verifying, according to a verification method corresponding to the second folding mode, whether the plurality of transactions in the second batch are executed correctly by using the second proof data corresponding to the second batch, and generating an asset transfer completed event corresponding to the tenth transaction in a case where the verification is passed.

14. The method of claim 13, wherein the asset transfer completion event corresponding to the tenth transaction and the asset to be transferred event corresponding to the seventh transaction are used to determine that the resource transfer according to the seventh transaction is completed when the first blockchain system successfully matches them.

15. The method of any one of claims 12-14, wherein the first blockchain system has a relay contract deployed therein, and the method further comprises: receiving a first transaction initiated by the first account, the first transaction being used to invoke the relay contract, the first transaction indicating N folding modes among M folding modes supported by the second blockchain system and resource distribution shares corresponding to the N folding modes respectively; executing the relay contract according to the first transaction, so as to generate a resource distribution event including the first account, the N folding modes and resource distribution shares corresponding to the N folding modes respectively, the resource distribution event being used to support the second blockchain system to generate N sub-transactions, and by executing any ith sub-transaction, to deposit a second target resource into an ith first sub-account belonging to the ith folding mode and corresponding to the first account.

16. The method of claim 15, wherein the executing the relay contract according to the first transaction further implements transferring a first target resource from the first account to a relay account corresponding to the second blockchain system according to resource distribution shares corresponding to the N folding modes respectively.

17. A second blockchain system supporting M folding modes, comprising: a receiver configured to receive a seventh transaction, a sender field and a receiver field of the seventh transaction including a first account and a second account respectively, the seventh transaction further including a resource transfer share, a first folding mode corresponding to the sender field and a second folding mode corresponding to the receiver field; an orderer configured to execute the seventh transaction, so as to transfer a second target resource from a first sub-account belonging to the first folding mode and corresponding to the first account to a first relay sub-account belonging to the first folding mode and corresponding to a relay account according to the resource transfer share; a relay configured to send an eighth transaction to a first blockchain system, the eighth transaction being used to invoke a fourth method function in a folding contract deployed by the first blockchain system, so as to make the first blockchain system process folding data of a first batch transaction batch to which the seventh transaction belongs; and send a ninth transaction to the first blockchain system, the ninth transaction being used to invoke a fifth method function in the folding contract, so as to make the first blockchain system generate an asset to be transferred event corresponding to the seventh transaction after verifying that a plurality of transactions in the first batch transaction batch have been correctly executed. ​ The sequencer is configured to generate a tenth transaction according to an asset transfer event corresponding to the seventh transaction, and execute the tenth transaction to achieve: transferring a second target resource from a second relay sub-account belonging to the second stack model and corresponding to the second account to a second sub-account belonging to the second stack model and corresponding to the second account according to the resource transfer share.

18. A blockchain node in a first blockchain system, wherein a stack contract is deployed in the first blockchain system, the stack contract comprising a fourth method function and a fifth method function, and the blockchain node comprising: a transaction receiving unit configured to receive an eighth transaction from a second blockchain system, the eighth transaction being used to call the fourth method function, the eighth transaction comprising stack data of a first batch transaction batch to which a seventh transaction belongs, a sender field and a receiver field of the seventh transaction comprising a first account and a second account respectively, the seventh transaction further comprising a resource transfer share, a first stack model corresponding to the sender field, and a second stack model corresponding to the receiver field, the eighth transaction being initiated after the second target resource is transferred from a first sub-account belonging to the first stack model and corresponding to the first account to a first relay sub-account belonging to the first stack model and corresponding to a relay account according to the resource transfer share by executing the seventh transaction in the second blockchain system; a transaction execution unit configured to execute the fourth method function according to the eighth transaction to achieve processing of the stack data of the first batch transaction batch; the transaction receiving unit is further configured to receive a ninth transaction from the second blockchain system, the ninth transaction being used to call the fifth method function, the ninth transaction comprising first proof data corresponding to the first batch transaction batch and the first stack model; the transaction execution unit is further configured to execute the fifth method function according to the ninth transaction to achieve: verifying whether a plurality of transactions in the first batch transaction batch are correctly executed by using the first proof data corresponding to the first batch transaction batch according to a verification method corresponding to the first stack model, and generating an asset transfer event corresponding to the seventh transaction in the case of passing the verification; wherein the asset transfer event is used to support the second blockchain system to generate a tenth transaction, and achieve: transferring the second target resource from a second relay sub-account belonging to the second stack model and corresponding to the relay account to a second sub-account belonging to the second stack model and corresponding to the second account according to the resource transfer share by executing the tenth transaction.

Images