Blockchain system management method and blockchain node

Abstract

A blockchain system management method and a blockchain node. The method comprises: a first blockchain system receiving a first transaction, wherein a first rollup contract comprising a first method function is deployed in the first blockchain system, registration information of N second blockchain systems is stored in the contract state of the first rollup contract, the first transaction is used for calling the first method function and requesting the use of a third blockchain system as a previous-layer blockchain system corresponding to an ith second blockchain system, and the third blockchain system is the first blockchain system or one of the remaining N-1 second blockchain systems; the first blockchain system executing the first method function on the basis of the first transaction, so as to generate a sovereignty transfer event, wherein the sovereignty transfer event comprises identification information of the ith second blockchain system and identification information of the third blockchain system; and on the basis of the sovereignty transfer event, the third blockchain system using the registration information of the ith second blockchain system to set a second rollup contract corresponding to the ith second blockchain system.

Description

Blockchain system management method and blockchain nodes

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on December 29, 2023, with application number 202311862343.4 and application name “Management Method and Blockchain Node of Blockchain System”, the entire contents of which are incorporated by reference into this application. Technical Field

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

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

[0004] Summary of the Invention

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

[0006] In a first aspect, a method for managing a blockchain system is provided, the method comprising: a first blockchain system receiving a first transaction, wherein a first rollup contract including a first method function is deployed in the first blockchain system, and registration information of N second blockchain systems is stored in the contract state of the first rollup contract; the first transaction is used to call the first method function to request that a third blockchain system be used as the upper-layer blockchain system corresponding to the i-th blockchain system, where the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; the first blockchain system executes the first method function according to the first transaction to achieve: generating a sovereignty transfer event, wherein the sovereignty transfer event includes identification information of the i-th second blockchain system and the third blockchain system; and the third blockchain system uses the registration information of the i-th second blockchain system to set a second rollup contract corresponding to the i-th second blockchain system in the third blockchain system according to the sovereignty transfer event.

[0007] In a second aspect, a method for managing a blockchain system is provided, the method being executed by a first blockchain system having a first overlay contract deployed therein, the first overlay contract including a first method function, the contract state of the first overlay contract storing registration information of N second blockchain systems. The method comprises: receiving a first transaction for invoking the first method function, the first transaction requesting a third blockchain system as the upper-layer blockchain system corresponding to the i-th blockchain system, the third blockchain system being one of the first blockchain system and the remaining N-1 second blockchain systems; executing the first method function according to the first transaction to achieve: generating a sovereignty transfer event, the sovereignty transfer event including identification information of the i-th second blockchain system and the third blockchain system, so that the third blockchain system uses the registration information of the i-th second blockchain system according to the sovereignty transfer event to set a second overlay contract corresponding to the i-th second blockchain system in the third blockchain system.

[0008] According to a third aspect, a blockchain node in a first blockchain system is provided. A first rollup contract is deployed in the first blockchain system, the first rollup contract includes a first method function, and the contract state of the first rollup contract stores registration information of N second blockchain systems. The blockchain node includes: a transaction receiving unit configured to receive a first transaction for calling the first method function, the first transaction requesting a third blockchain system as the upper-layer blockchain system corresponding to the i-th blockchain system, the third blockchain system being one of the first blockchain system and the remaining N-1 second blockchain systems; and a transaction executing unit configured to execute the first method function according to the first transaction to achieve: generating a sovereignty transfer event, the sovereignty transfer event including identification information of the i-th second blockchain system and the third blockchain system, so that the third blockchain system uses the registration information of the i-th second blockchain system according to the sovereignty transfer event to set a second rollup contract corresponding to the i-th second blockchain system in the third blockchain system.

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

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

[0011] In the technical solution provided by the embodiments of this specification, with the support of the first overlay contract in the first blockchain system located at Layer 1, the blockchain systems located at Layer 2, Layer 3, and even lower layers can quickly complete sovereignty migration, that is, quickly replace their corresponding upper-layer blockchain systems, without the need for offline communication between the blockchain systems, and can take into account both efficiency and security. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0017] FIG5 is a schematic diagram of a multi-layer rollup network using the Rollup technology according to an embodiment;

[0018] FIG6 is a schematic diagram of a blockchain system sovereignty transfer method according to an embodiment;

[0019] FIG7 is a second schematic diagram of a blockchain system sovereignty migration method in one embodiment;

[0020] FIG8 is a third schematic diagram of a blockchain system sovereignty migration method in one embodiment;

[0021] FIG9 is a flow chart of a method for implementing multi-layer network convolution provided in one embodiment;

[0022] FIG10 is a schematic diagram of a contract state storage of a smart contract provided in one embodiment;

[0023] FIG11 is a flowchart of a method for managing a blockchain system provided in one embodiment;

[0024] FIG12 is a schematic diagram of the structure of a blockchain node provided in one embodiment. DETAILED DESCRIPTION

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

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

[0027] To address the aforementioned "impossible triangle" of blockchain systems, public blockchain projects, also known as Layer 1 / mainnet, have prioritized security and decentralization, sacrificing efficiency and currently only achieving approximately 12-15 transactions per second. Layer 1 becomes congested when processing a large number of transactions, especially those with complex operations. In addition to standard transfers, Layer 1 also serves as the primary platform for popular applications such as DeFi (decentralized finance) and NFTs (non-fungible tokens). When these transactions are prevalent, Layer 1 congestion becomes particularly severe, leading to significant transaction delays.

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

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

[0030] Layer 2 of Layer 1 includes a mechanism called Rollup.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] In the OP-Rollup mechanism, TxPool (transaction pool), Relayer (relay) and Sequencer (sequencer) can be set in Layer 2. In the ZK-Rollup and TEE-Rollup mechanisms, Prover (prover) can also be set in Layer 2. For the TEE-Rollup mechanism, Prover (prover) can be set in TEE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0069] After the challenge period corresponding to any transaction batch submitted by Layer2 ends, or after the proof corresponding to any transaction batch is verified in the Rollup Contract of Layer2, the arbitrary batch and its corresponding contract call transaction (for example, the aforementioned transaction 1 for calling the CommitBatch() contract interface in the Rollup Contract) enter the finality state.

[0070] With the rise of Rollup technology, modular application chains (AppChains) centered around Rollup are becoming increasingly diverse. AppChains are blockchain systems designed to achieve independent business purposes or applications, such as gaming or DeFi applications. AppChains can operate on a public blockchain / mainchain, but they maintain independent consensus mechanisms, block generation, and transaction verification. In the development of decentralized applications (DApps), AppChains can address the scalability issues of public chains and improve transaction processing speed and efficiency. At the same time, AppChains inherit the advantages of public chains, including security and decentralization. For example, Plasma in Layer 1 and Zones in Cosmos are examples of AppChains. They operate independently and can interact with the mainchain, leveraging the mainchain for security and decentralization. Within an AppChain, block generation speed, transaction fees, smart contract functionality, and other features can be customized to meet specific application requirements. This makes AppChains more flexible than public chains and more adaptable to specific business needs.

[0071] Any AppChain can be registered in a blockchain system located in Layer 1 and itself located in Layer 2. The blockchain system in Layer 1 has sovereignty over the AppChain, that is, the blockchain system in Layer 1 is the blockchain system on the upper layer corresponding to the AppChain. Any AppChain can be registered in a blockchain system located in Layer 2 and itself located in Layer 3. The corresponding blockchain system in Layer 2 has sovereignty over the AppChain, that is, the corresponding blockchain system in Layer 2 is the blockchain system on the upper layer corresponding to the AppChain. Correspondingly, if any AppChain is located in Layer 2, it may have sovereignty over another AppChain located in Layer 3, that is, it may itself serve as the blockchain system on the upper layer corresponding to a blockchain system located in Layer 3. It is understandable that a multi-layer convolutional network including multiple AppChains may even continue to expand to Layer 4, Layer 5, or even more layers.

[0072] For example, referring to Figure 5, a multi-layered rollup network using Rollup technology can include blockchain system B11 located in Layer 1, blockchain systems B21 and B22 located in Layer 2, and blockchain system B31 located in Layer 3. B11 has sovereignty over B21 and B22, meaning it is the blockchain system in the layer above B21 and B22. B21 has sovereignty over B31, meaning it is the blockchain system in the layer above B31. Accordingly, the various aforementioned Rollup mechanisms can be used to implement rollups between B21 and B11, between B22 and B11, and between B31 and B21.

[0073] If a blockchain system at Layer 2, Layer 3 or even a lower layer expects to transfer sovereignty, that is, a blockchain system may expect to replace its corresponding upper-layer blockchain system, for example, any blockchain system B31 expects to replace its corresponding upper-layer blockchain system from B21 to B22, then the management members of the blockchain systems B31, B21 and B22 are usually required to communicate offline and then transfer corresponding data to realize the sovereignty transfer, which is relatively inefficient and low in security.

[0074] The embodiments of this specification provide at least one blockchain system management method and blockchain system. The method involves a first blockchain system (i.e., a blockchain system located at Layer 1) and N second blockchain systems (i.e., blockchain systems located at Layer 2, Layer 3, or even lower layers). The first blockchain system is deployed with a first overlay contract, which includes a first method function. The contract state of the first overlay contract stores the registration information of each of the N second blockchain systems. When a management member of any i-th second blockchain system desires to use a third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, the management member may send a first transaction to the first blockchain system to invoke the first method function. The first blockchain system may execute the first method function based on the first transaction, thereby generating a corresponding sovereignty transfer event, which includes identification information of the i-th second blockchain system and the third blockchain system. Accordingly, the third blockchain system may, based on the sovereignty transfer event, use the registration information of the i-th second blockchain system to set up a second overlay contract corresponding to the i-th second blockchain system within the third blockchain system, thereby becoming the upper-layer blockchain system corresponding to the i-th second blockchain system. In this way, with the support of the first rollup contract deployed by the first blockchain system at Layer 1, blockchain systems at Layer 2, Layer 3, and even lower layers can quickly complete sovereignty migration, that is, quickly replace their corresponding upper-layer blockchain systems, without the need for offline communication between the management members of each blockchain system, and can take into account both efficiency and security.

[0075] For the convenience of description in the embodiments of this specification, the blockchain system B11 will be used to represent the first blockchain system located in Layaer1, the smart contract Rollup Contract C1 will be used to represent the first rollup contract deployed in the first blockchain system, and the N second blockchain systems will be mainly used as examples to specifically include blockchain systems B21, B22 and B31.

[0076] First, Rollup Contract C1 may include method functions for supporting N blockchain systems to register with blockchain system B11, such as the contract interface Identity register(). For example, a management member of blockchain system B31 may send a registration transaction to blockchain system B11 to call Identity register(). Blockchain system B11 may then execute Identity register() based on the registration transaction, thereby storing and validating the registration information of blockchain system B11 in the contract state of Rollup Contract C1. The registration information of blockchain system B11 may come from the registration transaction and may include, but is not limited to, some or all of the following information about blockchain system B11: identification information, genesis block, management member address set, sequencer address set, consensus algorithm, transaction batch storage method, proof type / Rollup mechanism, and its corresponding verification algorithm.

[0077] Similarly, other second blockchain systems such as B21 and B22 can be registered in the blockchain system B11, so that the registration information of each second blockchain system such as B21, B22, and B31 is stored and effective in the contract status of Rollup Contract C1.

[0078] Illustratively, the contract status of Rollup Contract C1 may store status indications corresponding to the registration information of blockchain systems such as B21, B22, and B31, and the status information is used to indicate whether the corresponding registration information is effective. For example, if the value of the status indication is a predetermined value of 1, it indicates that the corresponding registration information is in an effective state, and the sovereignty of the blockchain system to which the registration information belongs is still in the blockchain system B11, that is, it indicates that the upper-layer blockchain system corresponding to the blockchain system to which the registration information belongs is the blockchain system B11. Correspondingly, if the value of the status indication is a predetermined value of 0, it indicates that the corresponding registration information is in an invalid state, and the sovereignty of the blockchain system to which the registration information belongs is no longer in the blockchain system B11, that is, it indicates that the upper-layer blockchain system corresponding to the blockchain system to which the registration information belongs is no longer the blockchain system B11.

[0079] When blockchain systems B21, B22, and B31 complete their registration with blockchain system B11 in Layer 1, they are all located in Layer 2. This means that the registration information for B21, B22, and B31 stored in the contract state of Rollup Contract C1 is in effect. For example, the status indicator corresponding to each of the registration information for B21, B22, and B31 is set to 1.

[0080] After any blockchain system, such as blockchain system B31, completes registration with blockchain system B11 located in Layer 1, it may perform sovereignty transfer in various ways, such as migration form 1 to migration form 3, according to the requirements of its management members.

[0081] Migration form 1: The sovereignty of blockchain system B31 migrates from a higher layer to a lower layer. For example, as shown in Figure 6, B31's sovereignty may migrate from B11 on Layer 1 to B21 on Layer 2, and then B31 itself enters Layer 3.

[0082] In migration form 2, the sovereignty of blockchain system B31 may be migrated within the same layer. For example, referring to Figure 7, the sovereignty of B31 may be transferred from B21 on Layer 2 to B22 on Layer 2, while B31 itself remains on Layer 3.

[0083] Migration form 3: The sovereignty of blockchain system B31 migrates from a lower layer to a higher layer. For example, as shown in Figure 8, B31's sovereignty may migrate from B22 on Layer 2 to B11 on Layer 1, and B31 itself enters Layer 2.

[0084] Similar to the solution in which blockchain system B11 has or terminates its sovereignty over other second blockchain systems, if a blockchain system, such as blockchain system B21, has sovereignty over another blockchain system, such as blockchain system B31, that is, blockchain system B21 is the upper-layer blockchain system corresponding to blockchain system B31, then blockchain system B21 may deploy the rollup contract Rollup Contract C2 corresponding to blockchain system B31 based on the registration information of blockchain system B31; the registration information of blockchain system B31 can be stored and validated in the contract state of Rollup Contract C2, for example, by setting the value of the corresponding status indication, so that blockchain system B21 has or terminates its sovereignty over blockchain system B31.

[0085] Based on the aforementioned Layer 1, Layer 2, and Layer 3, we first introduce a method for implementing multi-layer network stacking.

[0086] Figure 9 illustrates a method for implementing multi-layer network stacking, as provided in an embodiment of this specification. This method describes the process of implementing a multi-layer network stacking using any second blockchain system (e.g., blockchain system B31) located at Layer 3, another second blockchain system (e.g., blockchain system B21) located at Layer 2, and blockchain system B11 located at Layer 1. Specifically, B11 is described as the blockchain system above B21, and B21 as the blockchain system above B31.

[0087] The contract state of Rollup Contract C1, deployed on blockchain system B11, includes not only the registration information of N second blockchain systems but also global management information for these N second blockchain systems. For example, this global management information is stored using the identification information of blockchain systems B21, B22, and B31 as the key. Rollup Contract C1 may include the contract interface CommitBatch(), which allows the Relayer / Sequencer of blockchain system B21 to call.

[0088] The blockchain system B21 located in Layer 2 may include a rollup contract Rollup Contract C2 set based on the registration information of the blockchain system B31. The Rollup Contract C2, for example, includes a contract interface Commit Batch() that allows the Relayer / Sequencer of the blockchain system B31 to call. The contract state of the Rollup Contract C2 may also include management information G31 stored with the identification information of the blockchain system B31 as the key.

[0089] 9 , the method may include but is not limited to the following steps S901 to S907 .

[0090] In step S901, blockchain system B21 receives transaction Tx1 from blockchain system B31. Transaction Tx1 is used to call CommitBatch() in Rollup Contract C2. Transaction Tx1 includes the transaction sequence included in transaction batch b3 submitted by blockchain system B31 and the status data S1 corresponding to transaction batch b3.

[0091] The Sequencer of blockchain system B31 can obtain one or more user transactions initiated by various external accounts in blockchain system B31 from the TxPool of blockchain system B31 to form a transaction sequence belonging to a certain transaction batch (for example, transaction batch b3); then, based on the world state of blockchain system B31 before the transaction sequence is executed, the multiple user transactions in the transaction sequence are executed in sequence; furthermore, the batch number, transaction root, previous state root, and next state root of the transaction batch b31 can be obtained accordingly, and the Sequencer / Relayer initiates transaction Tx1 to blockchain system B21.

[0092] The state data S1 corresponding to transaction batch b3 may include: the state root corresponding to the world state of blockchain system B31 before the transaction sequence included in transaction batch b3 is executed, i.e., the pre-state root corresponding to transaction batch b3; and the state root corresponding to the world state of blockchain system B31 after the transaction sequence included in transaction batch b3 is executed, i.e., the post-state root corresponding to transaction batch b3. It should be noted that state data S1 may also include only the post-state root.

[0093] In some embodiments, transaction Tx1 may also include the batch number of transaction batch b3.

[0094] In step S903, blockchain system B21 executes Commit Batch() in Rollup Contract C2 according to transaction Tx1, thereby storing the transaction sequence included in batch b3 and updating the second state data of blockchain system B31 to state data S1 in the management information G31 of blockchain system B31.

[0095] When transaction Tx1 also includes the batch number of transaction batch b3, when blockchain system B21 executes Commit Batch() in Rollup Contract C2 according to transaction Tx1, it can also be achieved: in the management information G31 of blockchain system B31, a new position index is added according to the batch number of batch b3. The position index is used to indicate the storage location of the transaction sequence included in batch b3 in blockchain system B21.

[0096] As shown in Figure 10, the contract account (CA_2) corresponding to Rollup Contract C2 can include Nonce, Balance, Storage Root, and CodeHash. The Storage Root points to another tree in the MPT format. This Storage Trie stores key-value pairs and can use the identification information of blockchain system B31 as the key to store the management information G31 of blockchain system B31. Management information G31 includes the second state data of blockchain system B31 and one or more location indexes. In the second state data, for example, the previous state root and the next state root corresponding to batch b3 can be stored using the two fields of Last State Root and Current State Root in the above example, respectively. In order to store the management information of different blockchain systems independently in the contract state of Rollup Contract C2, the second state data and all location indexes included in management information G31 can be stored as a value with the identification information of blockchain system B31 as the key.

[0097] In one possible implementation, the transaction sequence included in batch b3 can be directly stored in transaction Tx1. The location index corresponding to batch b3 can include the batch sequence number of batch b3, the block number of the block to which transaction Tx1 belongs in blockchain system B11, and the transaction sequence number of transaction Tx1 within the block to which it belongs. In another possible implementation, the transaction sequence included in batch b3 can be stored in management information G31 of blockchain system B31. The location index can include the batch sequence number of batch b3 and the location information of the transaction sequence included in batch b3 in management information G31.

[0098] In step S905, blockchain system B21 sends transaction Tx2 to blockchain system B11. Transaction Tx2 is used to call CommitBatch() in Rollup Contract C1. Transaction Tx2 includes the transaction sequence included in transaction batch b2 submitted by blockchain system B21, the state data S2 corresponding to transaction batch b2, and the identification information and second state data of blockchain system B31 stored in the contract state of Rollup Contract C2 through management information G31.

[0099] The contract interface CommitBatch() in Rollup Contract C1 is the third method function included in Rollup Contract C1, transaction Tx2 is the third transaction used to call the third method function, transaction batch b2 is the second transaction batch, and the state data S2 corresponding to transaction batch b2 may include the previous state root and the next state root corresponding to the second transaction batch.

[0100] The Sequencer of blockchain system B21 can first obtain multiple user transactions initiated by various external accounts in blockchain system B21 from the TxPool of blockchain system B21, forming a transaction sequence belonging to a certain transaction batch (for example, transaction batch b2); then, based on the world state of blockchain system B21 before the transaction sequence is executed, the multiple user transactions in the transaction sequence are executed in sequence; further, the batch number, transaction root, previous state root, and next state root of transaction batch b2 can be correspondingly obtained, and the Sequencer / Relayer can initiate transaction Tx2 to blockchain system B21.

[0101] It should be noted that only when blockchain system B21 is the upper-layer blockchain system corresponding to blockchain system B31 will transaction Tx2 include the identification information and second state data of blockchain system B31 stored in the contract state of Rollup Contract C2 through management information G31. If blockchain system B21 is not the upper-layer blockchain system corresponding to blockchain system B31, even if blockchain system B21 includes management information G31 of blockchain system B31, transaction Tx2 will not include the identification information and second state data of blockchain system B31 stored in management information G31.

[0102] In a typical example, the Sequencer of blockchain system B21 can query Rollup Contract C2 to find out which blockchain systems' registration information has taken effect in blockchain system B21, that is, to know other blockchain systems that currently use the blockchain system as the upper-layer blockchain system, such as blockchain system B31; furthermore, in the transaction Tx2 initiated by the Sequencer of blockchain system B21 to call the contract interface Commit Batch() in Rollup Contract C1, the management information G31 of the aforementioned other blockchain systems, such as blockchain system B31, can be queried from Rollup Contract C2, and the identification information and second state data of blockchain system B31 stored in the management information G31 can be added to transaction Tx2.

[0103] In some embodiments, transaction Tx2 may also include the batch number of transaction batch b2.

[0104] In step S907, blockchain system B11 executes the contract interface Commit Batch() in Rollup Contract C1 according to transaction Tx2, thereby storing the transaction sequence included in transaction batch b2, updating the third state data of blockchain system B21 to state data S2 in the global management information GZ2 of blockchain system B21, and updating the fourth state data of blockchain system B31 to the second state data in the global management information GZ31 of blockchain system B31 based on the identification information and second state data of blockchain system B31.

[0105] When transaction Tx2 also includes the batch number of batch b2, blockchain system B11 executes the contract interface CommitBatch() in Rollup Contract C1 according to transaction Tx2, and can also achieve: adding a location index to the global management information GZ2 of blockchain system B21. The location index is used to indicate the storage location of batch b2 in blockchain system B11.

[0106] As shown in Figure 10, the contract account (CA_1) corresponding to Rollup Contract C1 can include Nonce, Balance, Storage Root, and CodeHash. The Storage Root points to another tree in the MPT format. This Storage Trie stores key-value pairs, using the identification information of blockchain systems B21 and B31 as keys to store the global management information GZ21 and GZ31 of blockchain systems B21 and B31, respectively. Global management information G21 includes the third state data of blockchain system B21 and one or more location indexes. The third state data can, for example, use the Last State Root and Current State Root fields in the aforementioned example to store the previous state root and the next state root corresponding to batch b2, respectively. Similarly, the fourth state data can, for example, use the Last State Root and Current State Root fields in the aforementioned example to store the second state data, respectively. In order to store the global management information of different blockchain systems independently in the contract state of Rollup Contract C1, all sovereignty transfer records, all location indexes and then the fourth state data included in the global management information GZ31 can be stored as a value with the identification information of the blockchain system B31 as the key; similarly, all location indexes and then the second state data included in the global management information GZ21 can be stored as a value with the identification information of the blockchain system B31 as the key.

[0107] If the upper-layer blockchain system corresponding to blockchain system B31 within a certain time period includes blockchain system B11, its global management information GZ31 may also include the location index corresponding to the partial transaction batch submitted by blockchain system B31.

[0108] When any blockchain system uses a designated blockchain system as its corresponding upper-layer blockchain system within a certain time period, the designated blockchain system can maintain the location indexes corresponding to each transaction batch submitted by the arbitrary blockchain system within the time period through the management information or global management information of the arbitrary blockchain system. This can support the storage location of the transaction sequence included in the transaction batch submitted by the arbitrary blockchain system in the designated blockchain system through the corresponding location index when a failure occurs in the arbitrary blockchain system, and then the transaction sequence included in the submitted transaction batch can be used to restore the arbitrary blockchain system or part of the data in the arbitrary blockchain system.

[0109] It should be understood that the method steps in the method embodiment shown in Figure 9 above only describe the process of submitting transaction batches through the prover / repeater in the multi-layer convolution network including Layer 1, Layer 2 and Layer 3. In fact, the blockchain system B21 located in Layer 2 and the blockchain system B31 located in Layer 3 may also submit proof of the relevant transaction batches to their respective corresponding upper-layer blockchain systems through their respective corresponding provers. After the proof of the relevant transaction batch is verified, the relevant transaction batch and its corresponding contract call transaction can enter the finality state.

[0110] Based on the aforementioned Layer 1, Layer 2, and Layer 3, we will now introduce a management method for a blockchain system.

[0111] Figure 11 is a flow chart of a management method provided in an embodiment of this specification. The method involves a first blockchain system (denoted as blockchain system B11) and N second blockchain systems. The method exemplarily describes the process of transferring sovereignty for any i-th second blockchain system (denoted as blockchain system B31) among the N second blockchain systems.

[0112] 11 , the method may include but is not limited to part or all of the following steps S1101 to S1109 .

[0113] Optionally, the Rollup Contract C1 deployed by blockchain system B11 includes a second method function, for example, the second method function is represented by the contract interface Termination sovereignty(). If the upper-layer blockchain system currently corresponding to blockchain system B31 is blockchain system B11 or a fourth blockchain system among the remaining N-1 second blockchain systems, and the management member of blockchain system B31 expects that the fourth blockchain system will no longer serve as the upper-layer blockchain system corresponding to blockchain system B31 after the first transaction batch submitted by blockchain system B31 enters an unchangeable state, then the management member of blockchain system B31 can initiate a second transaction (recorded as transaction Tx3) to the corresponding blockchain system B11.

[0114] Correspondingly, blockchain system B11 may execute step S1101 and receive transaction Tx3. Transaction Tx3 is used to call Termination sovereignty() in Rollup Contract C1. Transaction Tx3 requests that the fourth blockchain system no longer serve as the upper-layer blockchain system corresponding to blockchain system B31 after the first transaction batch submitted by blockchain system B31 enters an unchangeable state.

[0115] The following description will mainly use N second blockchain systems including blockchain systems B21, B22, and B31 as an example. On this basis, the aforementioned fourth blockchain system can be blockchain system B11, B21, or B22.

[0116] Transaction Tx3 may, for example, include the batch number of the first transaction batch submitted by blockchain system B31, as well as the respective identification information of blockchain system B31 and the fourth blockchain system.

[0117] In step S1103, blockchain system B11 executes Termination sovereignty() in Rollup Contract C1 according to transaction Tx3, thereby generating a sovereignty termination event. The sovereignty termination event includes the batch number of the first transaction batch, and the identification information of blockchain system B31 and the fourth blockchain system.

[0118] The result or related information of the execution of Termination sovereignty() by blockchain system B11 according to transaction Tx3 can be recorded in the receipt corresponding to transaction Tx3. Specifically, the contract execution result / related information can be expressed as an event in the receipt. The event can generally include a topic field and a data field, where the topic field is used to record the subject of the event and the data field is used to record the corresponding information. The format of the event can be specified in the contract. Through the built-in SDK, the client or blockchain node can listen for events on a specific topic and, when listening to a specific topic event, pull the content in the corresponding data. It can also perform preset processing after listening to a specific topic or certain content in the corresponding data.

[0119] Through this event mechanism, blockchain system B11 can store the execution results in the event corresponding to a certain topic, so that the fourth blockchain system can monitor the topic through the blockchain client built into its sequencer / relayer itself, obtain the corresponding sovereignty termination event, and know through the sovereignty termination event that it needs to submit the first transaction batch to blockchain system B31 to enter an unchangeable state, and no longer serve as the upper-layer blockchain system corresponding to blockchain system B31.

[0120] Correspondingly, in step S1105, the fourth blockchain system invalidates the registration information of blockchain system B31 in the third rolled-up contract deployed by it after confirming that the first transaction batch has entered an unchangeable state based on the sovereignty termination event.

[0121] The fourth blockchain system is, for example, blockchain system B11. In this case, the third rollup contract can be Rollup Contract C1. Because blockchain system B11 currently still holds sovereignty over blockchain system B31, it or a member of B11's management can detect whether the first transaction batch has entered an immutable state based on the batch number of the first transaction batch. When the first transaction batch has entered an immutable state, the relevant infrastructure within blockchain system 11 can automatically initiate, or a member of blockchain system B11 can initiate, a target transaction that calls a specific method function within Rollup Contract C1, such as the contract interface Indicate change(). Blockchain system B11 executes the contract interface Indicate change() based on the target transaction, terminating blockchain system B11's sovereignty over blockchain system B31. For example, in the contract status of Rollup Contract C1, the status indicator corresponding to the registration information of blockchain system B31 is set from 1 to 0.

[0122] The preceding description uses the example of blockchain system B11 as the fourth blockchain system. However, it is understandable that other blockchain systems, such as blockchain systems B21 and B22, when serving as the fourth blockchain system, can use similar strategies to initiate a target transaction for invoking their own deployed third convoluted contracts, and thus terminate sovereignty over B31 through similar methods.

[0123] When the fourth blockchain system executes the target transaction, it not only terminates its sovereignty over the blockchain system B31, but also generates a corresponding sovereignty response event. The sovereignty response event includes, for example, the corresponding topic and the identification information of the blockchain system B31, so that the blockchain system B31 and its management members know that the first transaction batch has entered an unchangeable state.

[0124] The blockchain system B31 may also learn that the first transaction batch has entered an unchangeable state through other means. For example, when the fourth blockchain system is the blockchain system B11, the prover of the blockchain system B31 submits the proof corresponding to the first transaction batch to the blockchain system B11 through a related transaction and after verification, the blockchain system B11 may generate a corresponding proof notification event for the related transaction, thereby enabling the blockchain system B31 and its management members to learn that the first transaction batch has entered an unchangeable state through the proof notification event corresponding to the related transaction.

[0125] When the management members of blockchain system B31 perceive that the first transaction batch has entered an unchangeable state and expect to transfer the sovereignty of blockchain system B31 to a third blockchain system, they can initiate a first transaction (recorded as transaction Tx4) accordingly.

[0126] Accordingly, blockchain system B11 can then execute step S1107 and receive transaction Tx4 for invoking Sovereign transfer() in Rollup Contract C1. Transaction Tx4 requests that a third blockchain system be established as the upper-level blockchain system corresponding to blockchain system 31. The third blockchain system is one of blockchain system B11 and the remaining N-1 second blockchain systems. It can be understood that Sovereign transfer() represents the first method function included in Rollup Contract C1.

[0127] Transaction Tx4 may, for example, include the identification information of the third blockchain system, and may also include the batch number of the first transaction batch, the identification information of the blockchain system B31, and the identification information of the fourth blockchain system.

[0128] In step S1109, blockchain system B11 executes Sovereign transfer() in Rollup Contract C1 according to transaction Tx4, thereby generating a sovereignty transfer event, which includes the identification information of blockchain system B31 and the third blockchain system.

[0129] In the example above, the N second blockchain systems include blockchain systems B21, B22, and B31. The aforementioned fourth blockchain system can be blockchain systems B11, B21, or B22. Then, the aforementioned third blockchain system can be blockchain systems B11, B21, or B22, where the third blockchain system is different from the fourth blockchain system.

[0130] The sovereignty transfer event may also include the registration information of the blockchain system B31.

[0131] When blockchain system B11 executes Sovereign transfer () in Rollup Contract C1 according to transaction Tx4, referring to Figure 10, it can also add a new sovereignty transfer record in the global management information GZ31 of blockchain system B31, which includes the identification information of the third blockchain system and the batch number corresponding to the next transaction batch of the first transaction batch.

[0132] In step S1111, the third blockchain system uses the registration information of blockchain system 31 according to the sovereignty transfer event to set a second cascade contract corresponding to blockchain system 31 in the third blockchain system.

[0133] The third blockchain system can obtain sovereignty transfer events through the aforementioned event monitoring mechanism, meaning that the sequencer / relayer and management members of the third blockchain system may perceive sovereignty transfer events. When the third blockchain system has not deployed an overlay contract, the sequencer / relayer of the third blockchain system can automatically initiate a contract deployment transaction, or a management member of the third blockchain system can initiate a contract deployment transaction. The third blockchain system can complete the deployment of the second overlay contract by executing the contract deployment transaction and call a contract interface, such as Identity register(), through a corresponding interface call transaction. By executing the interface call transaction, the registration information of blockchain system 31 is stored and validated in the contract state of the second overlay contract, thereby making the third blockchain system the upper-level blockchain system corresponding to blockchain system B31. It is understood that when the second overlay contract is already deployed in the third blockchain system, the sequencer / relayer of the third blockchain system can automatically initiate the aforementioned interface call transaction, or a management member of the third blockchain system can initiate an interface call transaction. The third blockchain system can complete the storage and validation of the registration information of blockchain system 31 in the contract state of the second overlay contract by executing the interface call transaction, thereby becoming the upper-level blockchain system corresponding to blockchain system B31.

[0134] The third blockchain system can obtain the registration information of blockchain system B31 from the sovereignty transfer event, or it can obtain the registration information of blockchain system B31 from Rollup Contract C1 through other means. This allows Rollup Contract C1 to subsequently process contract invocation transactions initiated by the Sequencer / Relayer and / or Prover / Relayer of blockchain system B31 to invoke Rollup Contract C1 according to the registration information of blockchain system B31.

[0135] In step S1113, the third blockchain system stores, in the contract state of the second rolled-up contract, the first state data corresponding to the first transaction batch that was recently submitted by blockchain system B31 and has entered an unchangeable state.

[0136] Referring to the relevant content recorded in the embodiment shown in Figure 9 above, after blockchain system B31 submits transaction batch b3, the state data S1 corresponding to transaction batch b3 will be stored as second state data in the smart contract Rollup Contract C2 deployed by the upper-layer blockchain system B21. The second state data will also be transmitted to blockchain system B21 through transaction Tx2 initiated by blockchain system B21 to blockchain system B11, and stored as fourth state data in blockchain system B21.

[0137] Correspondingly, after the first transaction batch enters an unchangeable state, the fourth state data of blockchain system B31 stored in blockchain system B21 is the first state data corresponding to the first transaction batch. Therefore, the sovereignty transfer event can also include the fourth state data of blockchain system B31, which also includes the first state data.

[0138] The third blockchain system can also obtain the first state data corresponding to the first transaction batch through other means. For example, the third blockchain system can obtain the genesis block from the registration information of blockchain system B31 and, from each blockchain system that served as the upper-layer blockchain system corresponding to the blockchain system, obtain the transaction sequences and proofs included in each of the transaction batches submitted by blockchain system B31 and entering a state that cannot be upgraded. By replaying the transaction sequences included in the genesis block and all transaction batches, the first state data corresponding to the first transaction batch can be obtained. For another example, the first state data corresponding to the first transaction batch can be obtained from the fourth blockchain system through decentralized infrastructure, such as a relayer.

[0139] The management members of blockchain system B31 may also wish to reuse the infrastructure of the blockchain system corresponding to the upper-level blockchain system, such as one or more of the various infrastructures, such as the sequencer, certifier, and relayer. Accordingly, in some embodiments, Rollup Contract C1 may also include a fourth method function, for example, represented by the contract interface Facility management(). Based on this, the management members of blockchain system B31 may initiate a fourth transaction (denoted as transaction Tx5) to blockchain system B11 to invoke Facility management(). Transaction Tx5 requests that blockchain system B31 reuse the infrastructure of the third blockchain system for executing a predetermined transaction. For example, transaction Tx5 may include the identification information of blockchain system B31, the identification information of the third blockchain system, and an indication indicating the infrastructure to be reused. Blockchain system B11 may then execute Facility management() in Rollup Contract C1 based on transaction Tx5, thereby generating a facility reuse event, which includes the identification information of blockchain system B31 and the third blockchain system, and may also include the aforementioned indication information. The third blockchain system can obtain the aforementioned facility reuse event through an event monitoring mechanism. Based on the facility reuse event, the third blockchain system can execute the predetermined transactions required to be executed in blockchain system B31 using its own infrastructure and the corresponding instruction information. For example, the sequencer and prover in the third blockchain system can execute some of the transactions required to be executed in blockchain system B31.

[0140] Based on the same concept as the aforementioned method embodiment, embodiments of this specification also provide a blockchain node 120 in a first blockchain system. A first overlay contract is deployed in the first blockchain system, the first overlay contract includes a first method function, and the contract state of the first overlay contract stores registration information of N second blockchain systems. As shown in FIG12 , the blockchain node 120 includes: a transaction receiving unit 1201 configured to receive a first transaction for invoking the first method function, the first transaction requesting a third blockchain system as the upper-layer blockchain system corresponding to the i-th blockchain system, the third blockchain system being one of the first blockchain system and the remaining N-1 second blockchain systems; and a transaction executing unit 1203 configured to execute the first method function based on the first transaction, thereby generating a sovereignty transfer event, the sovereignty transfer event including identification information of the i-th second blockchain system and the third blockchain system, causing the third blockchain system to utilize the registration information of the i-th second blockchain system to set a second overlay contract corresponding to the i-th second blockchain system in the third blockchain system.

[0141] The embodiments of this specification also provide a computer-readable storage medium on which a computer program / instruction is stored. When the computer program / instruction is executed in a computer, the computer is caused to execute the method steps performed by the blockchain system B11, the blockchain system B21, the blockchain system B31, the third or fourth blockchain system in the aforementioned embodiments.

[0142] A computing device is also provided in an embodiment of this specification, including a memory and a processor, wherein the memory stores a computer program / instruction, and when the processor executes the computer program / instruction, it implements the method steps performed by the blockchain system B11, the blockchain system B21, the blockchain system B31, the third or fourth blockchain system in the aforementioned embodiments.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A management method for a blockchain system, the method comprising: The first blockchain system receives a first transaction. A first roll-up contract including a first method function is deployed in the first blockchain system. Registration information of N second blockchain systems is stored in the contract state of the first roll-up contract. The first transaction is used to call the first method function. The first transaction requests that the third blockchain system be used as the upper-layer blockchain system corresponding to the i-th blockchain system. The third blockchain system is one of the first blockchain system and the remaining N - 1 second blockchain systems; The first blockchain system executes the first method function according to the first transaction, and realizes: generating a sovereignty migration event, where the sovereignty migration event includes the identification information of the i-th second blockchain system and the third blockchain system; The third blockchain system, according to the sovereignty migration event, uses the registration information of the i-th second blockchain system to set a second roll-up contract corresponding to the i-th second blockchain system in the third blockchain system.

2. The method according to claim 1, wherein the method further comprises: The third blockchain system stores, in the contract state of the second roll-up contract, the first state data corresponding to the first transaction group batch that is the latest submitted by the i-th blockchain system and has entered an immutable state.

3. According to the method described in claim 1, the third blockchain system sets a second roll-up contract corresponding to the i-th second blockchain system in the third blockchain system according to the sovereignty migration event and by using the registration information of the i-th second blockchain system, including: The third blockchain system, according to the sovereignty migration event, validates the registration information of the i-th second blockchain system in the second roll-up contract that has been deployed.

4. The method according to claim 1, wherein the first roll-up contract further includes a second method function; Among them, The method further includes: The first blockchain system receives a second transaction for calling the second method function. The second transaction requests that the fourth blockchain system no longer be used as the upper-layer blockchain system corresponding to the i-th blockchain system after the first transaction batch submitted by the i-th blockchain system enters an immutable state. The fourth blockchain system is a blockchain system different from the third blockchain system among the first blockchain system and the remaining N - 1 second blockchain systems; The first blockchain system executes the second method function according to the second transaction, and realizes: generating a sovereignty termination event, where the sovereignty termination event includes the batch number of the first transaction batch, the identification information of the i-th second blockchain system, and the fourth blockchain system; The fourth blockchain system, according to the sovereignty termination event, invalidates the registration information of the i-th second blockchain system in the third roll-up contract deployed by it after confirming that the first transaction batch has entered an immutable state.

5. According to the method described in claim 4, the contract state of the first roll-up contract includes the global management information of the N second blockchain systems, the fourth blockchain system belongs to the remaining N-1 blockchain systems, and the first roll-up contract further includes a third method function; wherein, The method further includes: The first blockchain system receives a third transaction for calling the third method function from the fourth blockchain system. The third transaction includes the transaction sequence included in the second transaction batch submitted by the fourth blockchain system, the previous state root and the subsequent state root corresponding to the second transaction batch, and the third roll-up contract The identification information and second status data of the i-th second blockchain system stored in the contract status; The first blockchain system executes the third method function according to the third transaction, and realizes: storing the transaction sequence included in the second transaction batch, updating the third status data of the fourth blockchain system according to the previous state root and the subsequent state root corresponding to the second transaction batch in the global management information of the fourth blockchain system, and updating the fourth status data of the i-th second blockchain system according to the identification information and second status data of the i-th second blockchain system in the global management information of the i-th second blockchain system.

6. The method according to claim 5, wherein the third transaction further includes the batch number of the second transaction batch; wherein, Executing the third method function according to the third transaction further realizes: adding a batch position index in the global management information of the fourth blockchain system according to the batch number of the second transaction batch, for indicating the storage position of the second transaction batch in the first blockchain system.

7. According to the method of claim 6, the batch position index includes: The batch number of the second transaction batch, the block number and transaction number of the block to which the third transaction belongs in the first blockchain system.

8. The method according to claim 5, wherein the first status data is further included in the sovereignty migration event, and the first status data is the fourth status data included in the global management information of the i-th second blockchain system.

9. According to the method described in claim 1, the contract state of the first roll-up contract further includes the global management information of the N second blockchain systems; wherein, Executing the first method function according to the first transaction further realizes: adding a sovereignty migration record in the global management information of the i-th second blockchain system, including the identification information of the third blockchain system and the batch number corresponding to the next transaction batch of the first transaction batch.

10. The method according to claim 9, wherein the first status data is further included in the sovereignty migration record.

11. The method according to claim 1, wherein the registration information of the i-th second blockchain system is further included in the sovereignty migration event.

12. According to the method described in claim 1, the third blockchain system belongs to the remaining N - 1 second blockchain systems, and the first roll-up contract further includes a fourth method function; wherein, The method further includes: The first blockchain system receives a fourth transaction for invoking the fourth method function from the i-th second blockchain system, and the fourth transaction request reuses the infrastructure for executing a predetermined transaction in the third blockchain system; The first blockchain system executes the fourth method function according to the fourth transaction, and realizes: generating a facility reuse event, including the identification information of the i-th second blockchain system and the third blockchain system; The third blockchain system executes the predetermined transaction required to be executed in the i-th second blockchain system through the infrastructure in the third blockchain system according to the facility reuse event.

13. The method according to claim 12, wherein the infrastructure in the third blockchain system includes at least one of the following: an orderer, a prover, and a relayer.

14. The method according to any one of claims 1-13, wherein the registration information of the i-th second blockchain system includes at least one of the following items of information: identification information, genesis block, set of management member addresses, set of sequencer addresses, storage method of transaction batches, Rollup mechanism, and its corresponding verification algorithm.

15. A management method for a blockchain system, which is executed by a first blockchain system deployed with a first Rollup contract. The first Rollup contract includes a first method function, and the registration information of N second blockchain systems is stored in the contract state of the first Rollup contract. The method includes: Receiving a first transaction for invoking the first method function, where the first transaction requests to use a third blockchain system as the upper-layer blockchain system corresponding to the i-th blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; Executing the first method function according to the first transaction to achieve: generating a sovereignty migration event, which includes the identification information of the i-th second blockchain system and the third blockchain system, and enabling the third blockchain system to use the registration information of the i-th second blockchain system according to the sovereignty migration event to set a second Rollup contract corresponding to the i-th second blockchain system in the third blockchain system.

16. A blockchain node in a first blockchain system, where a first Rollup contract is deployed in the first blockchain system. The first Rollup contract includes a first method function, and the registration information of N second blockchain systems is stored in the contract state of the first Rollup contract. The blockchain node includes: A transaction receiving unit configured to receive a first transaction for invoking the first method function, where the first transaction requests to use a third blockchain system as the upper-layer blockchain system corresponding to the i-th blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; A transaction execution unit configured to execute the first method function according to the first transaction to achieve: generating a sovereignty migration event, which includes the identification information of the i-th second blockchain system and the third blockchain system, and enabling the third blockchain system to use the registration information of the i-th second blockchain system according to the sovereignty migration event to set a second Rollup contract corresponding to the i-th second blockchain system in the third blockchain system.

Images