Blockchain system management method and blockchain node

Abstract

A blockchain system management method and a blockchain node, the method comprising: a first blockchain system receiving a first transaction, the first blockchain system deploying a first rollup contract comprising a first method function, and the contract state of the first rollup contract storing registration information of N second blockchain systems, the first transaction being used to call the first method function and request a third blockchain system as a corresponding upper layer blockchain system of an i-th blockchain system, wherein the third blockchain system belongs to the first blockchain system or the remaining N-1 second blockchain systems; the first blockchain system executing the first method function according to the first transaction, to generate a sovereignty migration event, wherein the sovereignty migration event comprises identification information of the i-th second blockchain system and the third blockchain system; and the third blockchain system setting a second rollup contract corresponding to the i-th second blockchain system by using the registration information of the i-th second blockchain system according to the sovereignty migration event.

Description

Technical Field

[0001] The embodiments in this specification pertain to the field of blockchain, and particularly relate to a management method for a blockchain system and a blockchain node. Background Technology

[0002] Blockchain systems are a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain systems are receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a management method for a blockchain system and a blockchain node.

[0004] In a first aspect, a management method for a blockchain system is provided, the method comprising: a first blockchain system receiving a first transaction, wherein the first blockchain system deploys a first roll-over contract including a first method function, the contract state of the first roll-over contract storing registration information of N second blockchain systems, the first transaction being used to call the first method function to request that a third blockchain system be designated as the upper-layer blockchain system corresponding to the i-th second blockchain system, wherein the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; the first blockchain system executing the first method function according to the first transaction to generate a sovereign migration event, wherein the sovereign migration event includes identification information of the i-th second blockchain system and the third blockchain system; and the third blockchain system, based on the sovereign migration event and utilizing the registration information of the i-th second blockchain system, setting up a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system.

[0005] Secondly, a management method for a blockchain system is provided. This method is executed by a first blockchain system with a first stacked contract deployed thereon. The first stacked contract includes a first method function, and its contract state stores registration information for N second blockchain systems. The method includes: receiving a first transaction for invoking the first method function, wherein the first transaction requests that a third blockchain system be designated as the upper-layer blockchain system corresponding to the i-th second 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 generate a sovereign migration event, wherein the sovereign migration event includes identification information of the i-th second blockchain system and the third blockchain system, enabling the third blockchain system to set up a second stacked contract corresponding to the i-th second blockchain system in the third blockchain system based on the sovereign migration event and the registration information of the i-th second blockchain system.

[0006] Thirdly, a blockchain node in a first blockchain system is provided. The first blockchain system deploys a first roll-over contract, which includes a first method function. The contract state of the first roll-over 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, wherein the first transaction request designates a third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; and a transaction execution unit configured to execute the first method function according to the first transaction, thereby generating a sovereign migration event, wherein the sovereign migration event includes identification information of the i-th second blockchain system and the third blockchain system, enabling the third blockchain system to set up a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system based on the sovereign migration event and the registration information of the i-th second blockchain system.

[0007] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the second aspect.

[0008] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, wherein when the computer program is executed in a computing device, the computing device performs the method described in the second aspect.

[0009] In the technical solutions provided in the embodiments of this specification, with the support of the first stacked contract in the first blockchain system located at Layer 1, blockchain systems located at Layer 2, Layer 3, or even lower layers can quickly complete the sovereignty migration, that is, quickly replace their corresponding upper-layer blockchain system without the need for offline communication between the blockchain systems, thus simultaneously ensuring efficiency and security. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is one of the schematic diagrams of Layer 2 in one embodiment;

[0012] Figure 2 This is the second schematic diagram of the principle of Layer 2 in one embodiment;

[0013] Figure 3 This is the third schematic diagram of the principle of Layer 2 in one embodiment;

[0014] Figure 4 This is the fourth schematic diagram of the principle of Layer 2 in one embodiment;

[0015] Figure 5 This is one of the schematic diagrams of a multilayer convolutional network using Rollup technology in one embodiment;

[0016] Figure 6 This is one of the schematic diagrams illustrating a method for transferring sovereignty in a blockchain system.

[0017] Figure 7 This is the second schematic diagram of a blockchain system sovereignty migration method in one embodiment;

[0018] Figure 8 This is the third schematic diagram of a blockchain system sovereignty migration method in one embodiment;

[0019] Figure 9 This is a flowchart of a method for implementing multi-layer network convolution provided in one embodiment;

[0020] Figure 10 This is a schematic diagram of the contract state storage of a smart contract provided in one embodiment;

[0021] Figure 11 This is a flowchart illustrating a management method for a blockchain system provided in one embodiment;

[0022] Figure 12 This is a schematic diagram of the structure of a blockchain node provided in one embodiment. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0024] In distributed systems, there exists the classic CAP theorem—Consistency, Availability, and Partition tolerance—and these three cannot be simultaneously achieved, a problem known as the "impossible triangle." A similar impossible triangle exists in blockchain systems: efficiency, decentralization, and security. While there is no definitive theoretical proof for this "impossible triangle" in blockchain systems, it is a summary of existing blockchain practices. Efficiency, decentralization, and security are defined as follows: Efficiency: the number of transactions processed per second, or TPS (Transactions per Second); Decentralization: a sufficiently low barrier to entry for participating nodes, ensuring a large number of distributed nodes in the system; Security: the difficulty of launching an attack on the blockchain system is sufficiently high.

[0025] To address the "blockchain trilemma" mentioned above, public blockchain projects, also known as Layer 1 / mainnet, have prioritized security and decentralization at the expense of efficiency, currently achieving only about 12-15 TPS. When a large number of transactions need to be processed, especially complex transactions, Layer 1 becomes congested. Besides ordinary transfer transactions, Layer 1 also serves as a major platform for popular applications such as DeFi (Decentralized Finance) and NFTs (Non-fungible tokens). During periods of high transaction volume, Layer 1 congestion becomes severe, leading to significant transaction delays.

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

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

[0028] Layer 1's Layer 2 includes a mechanism called Rollup.

[0029] The core idea of ​​Rollup is as follows: Figure 1 As shown, Layer 1 stores credentials that can verify the transaction process, while the transaction process (computation process) and state storage run in Layer 2. The credentials for the transaction process include a set of states before transaction execution (Pre-State) and after transaction execution (Post-State), as well as the transaction itself. These credentials can be used to verify the correctness of the state transitions corresponding to the transaction set, and can also be used to reconstruct the execution process of all transactions and the state of all accounts on Layer 2, thereby eliminating security risks arising from data availability on Layer 2.

[0030] The principle of Rollup can be explained as follows: Figure 2 and Figure 3 ( Figure 3 The main example is the OP-Rollup (described below).

[0031] The transaction to create a smart contract is sent to Layer 1. After consensus is reached on Layer 1, each node on Layer 1 can execute the transaction, thus completing the contract deployment. Specifically, this transaction can be executed by the EVM / WASM of the blockchain nodes. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented through it, which is one of the biggest improvements of Blockchain 2.0 compared to Blockchain 1.0. Users can publish and call smart contracts on Layer 1, which can run on the EVM. After executing the transaction to deploy the smart contract, 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 nonce counter, a hash value (Codehash) of the contract code, and a storage root (Storage_Root). Through Codehash and Storage_Root, the contract code and account storage can be stored in this contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, smart contracts enable the creation of virtual accounts on the blockchain that contain contract code and account storage (Storage). Subsequently, nodes on Layer 1 can receive transaction requests to invoke deployed smart contracts. These requests can include the address of the invoked contract, the functions within that contract, and the input parameters. Generally, after consensus is reached, each node on the blockchain can independently execute the specified smart contract.

[0032] In Layer 1, `Storage_root` is the hash of the root node of an MPT tree, which organizes the storage of contract account states. MPT stands for Merkle Patricia Tree, a tree structure combining Merkle Tree and Patricia Tree (a more space-efficient Trie tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins pairs of transactions and calculates the hash again, continuing until the top-level Merkle root. Layer 1 uses an improved MPT tree, such as a 16-ary tree structure, often simply referred to as an MPT tree. In fact, the Layer 1 block header includes three MPT tree roots: `Transaction_Root` (abbreviated as `Tx_Root`), `State_Root`, and `Receipt_Root`. `State_Root` is the hash value of the root of the MPT tree composed of the states of all accounts in the current block; that is, it points to a state trie in MPT form. The values ​​from each node in this MPT, from the root node to the leaf node, are concatenated sequentially 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 aforementioned key can be sha3(Address), which is the hash value of the account address (using a hash algorithm such as sha3), and the stored value can be rlp(Account), which is the rlp (Recursive Length Prefix) encoding of the account information. The account information is a four-tuple consisting of [nonce, balance, storageRoot, codeHash]. For external accounts (Externally Owned Accounts, EOAs), there are generally only two fields: nonce and balance, while the storageRoot and codeHash fields store empty strings / strings of all zeros by default. That is, external accounts do not store contracts or state variables generated after contract execution. Contract accounts include Nonce, Balance, Storage root, and CodeHash. Regardless of whether it is an external account or a contract account, its account information is generally located in a single leaf node.

[0033] For a contract account (CA) within a state trie, its storage_root points to another tree, also in MPT form, which stores data related to state variables involved in contract execution. This MPT-form tree pointed to by storage_root is a Storage Trie, meaning storage_root stores the hash value of the root node of the Storage Trie. Generally, this Storage Trie also stores key-value pairs. The key indicates the address of the state variable, and its value can be the result of processing the position of the state variable declaration in the contract (counting from 0) according to certain rules, such as SHA3 (position of state variable declaration) or SHA3 (contract name + position of state variable declaration). The value is used to store the value of the state variable (e.g., a value encoded using RLP). A portion of 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 storage trie, except for the leaf nodes, the root node and intermediate nodes use... Figure 3 The cloud-like shape is used to represent its flexible and complex structure.

[0034] like Figure 2 As shown, Rollup Contracts can be deployed on Layer 1 in Rollup. Layer 2 can receive initiated transactions, such as Tx_21 and Tx_22 in the diagram. A batch of transactions is called a transaction group (Batch), which is executed sequentially and its state updated as a whole. Figure 1 and 2 As shown, 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. Layer 2 can sort these transactions according to a rule, and then execute them sequentially, for example, by timestamps. After the transactions in a batch are executed in order, the resulting states can include several possibilities; for example, the transactions in Batch 1 are as follows:

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

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

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

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

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

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

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

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

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

[0044] In the OP-Rollup mechanism, TxPool (trading pool), Relayer (relay) and Sequencer (sequencer) can be set in Layer 2. In ZK-Rollup and TEE-Rollup mechanisms, Prover (provider) can also be set in Layer 2; for the TEE-Rollup mechanism, Prover (provider) can be set in TEE.

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

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

[0047] Furthermore, the Sequencer can send a transaction 1 calling the Rollup Contract to Layer 1 via the Relayer. This transaction 1 contains some or all fields from the Batch M Header, as well as the compressed transaction sequence Tx21, Tx22, and Tx23. The compression of Tx21, Tx22, and Tx23 significantly reduces their space requirements. The interface in the called RollupContract can include storing the compressed transaction data (Tx21, Tx22, and Tx23) in a cheaper (lower gas cost) location called data (calldata). In the Layer 1 smart contract, calldata is a special data location used to store input data from function calls. Specifically, calldata is generally stored directly in the Layer 1 transaction data, which is typically more gas-efficient than other data locations (such as memory and storage). Although the process of compressing the transaction sequence included in a transaction batch is omitted in this article, it is understood that any transaction batch mentioned below may include either an uncompressed transaction sequence or a compressed transaction sequence.

[0048] It's worth noting that in a Layer 1 transaction, the signature portion occupies about half the total size, and its From field can be 0 bytes because it can be recovered from the signature. However, in Rollup transactions, BLS or other aggregation schemes are typically used, compressing the signature of each transaction to approximately 0.5 bytes on average. Consequently, in Rollup transactions, since the From field cannot be recovered from such aggregated signatures, it needs to be represented by a separate 4-byte signature.

[0049] The BLS signature scheme was originally proposed in 2001 by Stanford University professor Dan Boneh and others, based on a bilinear mapping. Generally, a user's control over their own account is manifested in signing a transaction with their private key. A single signature, as shown in the table above, can reach 68 bytes, occupying a significant amount of space. For multiple transactions initiated by multiple accounts, each account needs to sign each of its own transactions separately. Signature aggregation, however, can combine multiple signatures into a single signature, thus greatly saving byte space. This aggregation can be an aggregation of the same message signed by different signers, or an aggregation of signatures from different messages. Public key aggregation can combine multiple different public keys into a single master public key, which can then be used to verify the aggregated signature without requiring each public key to participate in the computation during the verification of the master signature. Signature aggregation is typically implemented using the Schnorr signature algorithm and the BLS signature algorithm. Compared to the Schnorr signature algorithm, the aggregated signature implemented by the BLS signature algorithm is smaller, approximately half the size of the Schnorr signature.

[0050] The compression scheme described above, along with the use of BLS for signature aggregation, represents an ideal design. However, in several practical Rollup schemes, a single compressed transaction still occupies 40-50 bytes of space, and this does not include the signature; in other words, BLS signature aggregation is not yet employed.

[0051] Following the previous text, after Layer 1 receives Transaction 1, which calls the Rollup Contract, it reaches a consensus, executes Transaction 1 on some nodes, and generates a block together with Transaction 1 and its execution result, along with other transactions and their execution results. Figure 3Block N in the context of this document refers to several other transactions, including ordinary transfer transactions and transactions involving other smart contracts. Both ordinary transfer transactions and transactions involving other smart contracts involve transaction execution. Transactions involving other smart contracts, in particular, may involve more complex execution logic. Transaction 1, which calls the function in the RollupContract to store data at the `calldata` location, primarily involves storing data at a specified location; it does not involve the execution of complex contract logic. In other words, the Rollup Contract in Layer 1 mainly stores the specified content from the transaction sent from Layer 2 into a specified location, without involving 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. Furthermore, as an implementation, the Pre-State Root and Post-State Root in the Batch M Header of Transaction 1 can be stored in State 1 and State 2 of the contract state on Layer 1, respectively, using the Rollup Contract. As mentioned earlier, states 1 and 2 are contained in a state trie locked by the State_Root in Block NHeader, specifically, for example, a storage trie. For distinction, states 1 and 2 in the contract state on Layer 1 are referred to as the Last State root and Current State root, respectively. Furthermore, for simplicity, only the Current State root can be stored in the contract state on Layer 1, omitting the Last State root, as shown in the code example below. In some implementations, the Last State root and Current State root can also be stored in the calldata of Layer 1, just like transactions in Layer 2; this will not be elaborated upon here.For the former, for example, calling the commitBatch() contract interface in Layer1 as follows: function CommitBatch(bytes[] calldata _transactions, bytes32 _preStateRoot, bytes32 _postStateRoot). The CommitBatch() contract interface can set basic validation logic, such as verifying whether the PreState Root in the current transaction 1 is equal to the Current State Root in the contract storage. If they are equal, the transaction passed in from Layer2 in transaction 1 is stored in calldata, and the CurrentState Root in the contract storage is updated to the PostState Root.

[0052] In this way, OP-Rollup can execute individual transactions in Layer 2 and bundle dozens, hundreds, or even more Layer 2 transactions into a single batch, publishing only the minimum amount of information to Layer 1. This minimum amount of information includes, as previously described, the compressed transactions on Layer 2 and the hash values ​​of the state roots before and after the execution of these transactions. As shown earlier, this can be sent, for example, through a transaction on Layer 1, such as... Figure 3 Transaction 1 in the example. This is equivalent to executing a batch of transactions on Layer 2 at once, but only one transaction on Layer 1. Furthermore, OP-Rollup does not include any proof. This is based on the assumption that the submitted Layer 2 information is free from fraud or malicious activity, hence the name "Optimistic." Despite this assumption, for prevention and deterrence, traders submitting Layer 2 information are still required to stake a portion of their Layer 1 assets (typically on-chain native tokens) in the OP-Rollup's Rollup Contract. For the Layer 2 information submitted to Layer 1, although the transactions are compressed, as mentioned earlier, it can still be used to reconstruct the execution process of all transactions on Layer 2 and the status of all accounts, thereby eliminating security risks arising from data availability on Layer 2.

[0053] While OP-Rollup is optimistic, a challenge period can still be set on Layer 1, during which anyone can submit a fraud proof challenge. Typical reasons include a challenger proving that a transaction within the batch was not executed correctly, i.e., 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 Rollup contract on Layer 1 can roll back the Layer 2 batch chain, making the invalid batch and all subsequent batches orphans. Once the fraud proof is successful, a portion of the deposit is paid to the challenger, and the remainder is destroyed. Conversely, if no one submits a fraud proof by the end of the challenge period, the Rollup contract can invalidate the batch. Fraud proof is a data validity verification method used in Optimistic Rollup schemes. Currently, fraud proofs can be divided into single-round and multi-round interactive types.

[0054] In one implementation of a single-round interactive fraud proof, the disputed transaction is replayed on Layer 1 to check for invalid states before submission. For example, Alice, as a validator, synchronizes the OP-Rollup compressed data to Layer 1 and pledges a deposit. If challenger Bob disputes the data, he must initiate a challenge during the challenge window and also pledge a deposit. The OP-Rollup's Rollup Contract will recalculate the transactions in the block on Layer 1 to determine right or wrong. The deposit of the incorrect party will be forfeited, and the correct party will receive a reward.

[0055] It's important to note that while the calldata on Layer 1 contains all the compressed transactions from Layer 2, the fraud verification process doesn't directly extract and execute the compressed transactions from Batch M within the calldata. Instead, it simulates the execution of all transactions in the original text of Batch M provided by the challenger. This is because the compressed Batch M transactions in the calldata are generally only used to reconstruct the execution process of all transactions on Layer 2 and the state of all accounts, thus eliminating security risks arising from data availability on Layer 2. Furthermore, the authenticity of the compressed Batch M transactions in the calldata, without signatures, is uncertain, while the transactions provided by the challenger are complete and can verify their validity. Moreover, because the initial state cannot be verified—the contract storage only contains state roots, not the actual state—it would be uneconomical and inefficient to re-execute all transactions sequentially from Batch 0 until all states are obtained after Batch M-1 execution.

[0056] The aforementioned single-round interactive fraud proofs increase the amount of data that must be published on-chain and require re-execution of all transactions in Batch M on Layer 1. Furthermore, replaying these transactions incurs significant gas costs. Therefore, OP-Rollup is shifting towards multi-round interactive proofs to achieve the same goal more efficiently.

[0057] In multi-round interactive fraud proof, when Bob challenges the data synchronized by the Sequencer, the Sequencer needs to divide the disputed batch range into two equal parts, a pre- and post-partition range, and return the result via a contract interface such as `dispute()`. Bob then selects a further bipartition range to continue the challenge, and the Sequencer divides the disputed range into two equal parts again... This process repeats until the disputed range is reduced to a specific transaction. Here, Bob sends the original text of the challenged transaction (including the signature of each transaction) and the global state before the transaction is executed. The Sequencer sends the PreState Root (also known as the state commitment) before the challenged transaction is executed and the PostState Root after execution, which are then calculated and judged by the RollupContract contract of Layer 1. Specifically, for example, a Rollup Contract verifies the global state before the execution of the challenge transaction based on the Pre-State Root. It then executes the challenge transaction based on this pre-state, generating the post-state. A Post-State Root is generated based on this post-state and compared to the Post-State Root sent by the Sequencer. If they differ, the challenge is successful; otherwise, it fails. In practice, Arbitrum does not use binary search but rather K-partitioning, dividing N instructions into N / K groups to search for fraudulent instructions, resulting in higher efficiency.

[0058] Therefore, compared to single-round interactions, multi-round interactions can resolve disputes at a lower cost. For example, the bipartite protocol can reduce the amount of data published on-chain (no need to publish state commits for every transaction), and it is also 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.

[0059] Overall, because the design of OP-Rollup requires all data related to state updates and verification to be placed on Layer 1, OP-Rollup has the most limited scalability and throughput improvement, and requires a waiting period of 7 days or even longer. This means that retrieving assets from OP-Rollup will be delayed, requiring waiting until the window period has passed.

[0060] ZK-Rollup differs from Optimistic Rollup because it uses zero-knowledge proof techniques. ZK refers to the ability to prove something (a transaction or state) to another party without disclosing necessary information. Unlike OP-Rollup, Layer 2 in ZK-Rollup also generates a proof (including a proof) for each transaction batch (e.g., using cryptographic proof algorithms like ZK-SNARK). This proof demonstrates that the Post-State Root is obtained by correctly executing the transaction sequence in the corresponding transaction batch based on the Pre-State Root. Verifying the proof is sufficient to confirm this, without needing to re-execute the transactions in the batch for verification.

[0061] The process of generating a proof can involve a sequencer packaging all transactions (including sender, receiver, and amount) in a batch within Layer 2, along with information such as the Pre-State Root, Post-State Root, and Proving Key before and after the execution of these transactions. This package is then sent 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 circuitry (a specific algorithm) to verify the validity and correctness of the public and private inputs. If the verification is correct, the circuit execution succeeds; otherwise, it fails. In the case of successful circuit execution, the prover outputs a proof, which demonstrates that the packaged data is valid and correct. This proof is relatively small, typically only a few tens of bytes. This proof generation process is similar to a re-execution process and involves a large amount of circuit computation, making it more complex and generally time-consuming. It should be noted that the private input cannot be derived from the proof itself; only the party knowing the zk-SNARK verification key can verify the proof encrypted with the corresponding creation key. Public inputs can be used to verify the validity and correctness of packaged data, but cannot be used to obtain the specific content of the packaged data.

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

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

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

[0065] To address the issues of computational complexity and long time required to generate proofs, the TEE-Roll mechanism was proposed. The main difference between the TEE-Rollup mechanism and ZK-Rollup is that the Prover is implemented using a TEE (Trusted Execution Environment). Furthermore, after verifying the transaction root, previous state root, and next state root information of a transaction batch provided by the Sequencer, the Prover can use the private key in the TEE to sign the relevant information of that transaction batch. This signature is then used as proof and published to Layer 1 via the Relayer, where it can be quickly verified by the Rollup Contract.

[0066] Once the challenge period for any transaction batch submitted by Layer 2 ends, or once the proof corresponding to any transaction batch is verified in Layer 2's Rollup Contract, that arbitrary batch and its corresponding contract call transaction (such as transaction 1 mentioned above, which is used to call the Commit Batch() contract interface in the Rollup Contract) enter the finality state.

[0067] With the rise of Rollup technology, the design of modular application chains (AppChains) centered on Rollup technology is becoming increasingly diverse. An AppChain refers to a blockchain system designed to achieve independent business purposes or applications, such as games or DeFi applications. AppChains can run on public chains / main chains, but they also have independent consensus mechanisms, block generation, and transaction verification methods. In the development of decentralized applications (DApps), AppChains can solve the scalability problem of public chains and improve the speed and efficiency of transaction processing. At the same time, AppChains still inherit the advantages of public chains, including their security and decentralization characteristics. For example, Plasma in Layer 1 and Zone in Cosmos are examples of AppChains. They have the ability to operate independently and can interact with the main chain, using the main chain to achieve security and decentralization. In AppChains, the speed of block generation, transaction fees, and smart contract functionality can be customized according to specific application needs. This makes AppChains more flexible and adaptable to specific business requirements than public chains.

[0068] Any APPChain can be registered in a blockchain system located at Layer 1, while itself residing in Layer 2. The blockchain system in Layer 1 has sovereignty over the APPChain, meaning it is the upper-layer blockchain system corresponding to that APPChain. Similarly, any APPChain can be registered in a blockchain system located at Layer 2, while itself residing in Layer 3. The corresponding blockchain system in Layer 2 also has sovereignty over the APPChain, meaning it is the upper-layer blockchain system corresponding to that APPChain. Conversely, if any APPChain is located in Layer 2, it may have sovereignty over another APPChain located in Layer 3, meaning it may act as the upper-layer blockchain system corresponding to a blockchain system in Layer 3. It is understandable that multi-layered convolutional networks including multiple APPChains may even extend to Layer 4, Layer 5, and even more layers.

[0069] For example, see Figure 5 In a multi-layered rollup network employing Rollup technology, there may be a blockchain system B11 located in Layer 1, blockchain systems B21 and B22 located in Layer 2, and a blockchain system B31 located in Layer 3. B11 has sovereignty over B21 and B22, meaning B11 is the upper-layer blockchain system corresponding to B21 and B22; B21 has sovereignty over B31, meaning B21 is the upper-layer blockchain system corresponding to B31. Correspondingly, rollup can be achieved between B21 and B11, between B22 and B11, and between B31 and B21 using the aforementioned Rollup mechanisms.

[0070] If a blockchain system located at Layer 2, Layer 3, or even lower desires to undergo a sovereign migration—that is, if a blockchain system may wish to replace its corresponding upper-layer blockchain system, for example, if any blockchain system B31 wishes to replace its corresponding upper-layer blockchain system from B21 to B22—then the management members of blockchain systems B31, B21, and B22 typically need to communicate offline and transfer the corresponding data to achieve the sovereign migration. This process is relatively inefficient and has low security.

[0071] This specification provides at least one management method and blockchain system in its embodiments. It 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 deploys a first roll-over contract, which includes a first method function. The contract state of the first roll-over contract stores the registration information of each of the N second blockchain systems. When any management member of the i-th second blockchain system wishes to designate a third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, it can send a first transaction to the first blockchain system to invoke the first method function. The first blockchain system can then execute the first method function according to the first transaction, thereby generating a corresponding sovereignty migration event, which includes the identification information of the i-th second blockchain system and the third blockchain system. Correspondingly, the third blockchain system can, based on the sovereignty migration event and using the registration information of the i-th second blockchain system, set up a second roll-over contract corresponding to the i-th second blockchain system within the third blockchain system, thus becoming the upper-layer blockchain system corresponding to the i-th second blockchain system. Thus, with the support of the first stacked contract deployed by the first blockchain system located at Layer 1, blockchain systems located at Layer 2, Layer 3, or even lower layers can quickly complete the sovereign migration, that is, quickly replace their corresponding upper-layer blockchain system without the need for offline communication among the management members of each blockchain system, thus simultaneously ensuring efficiency and security.

[0072] For ease of description, this specification will use blockchain system B11 to represent the first blockchain system located in Layaer1, and smart contract Rollup Contract C1 to represent the first rollup contract deployed in the first blockchain system. The specification will also use N second blockchain systems, specifically blockchain systems B21, B22, and B31, as examples for illustrative description.

[0073] First, Rollup Contract C1 can include method functions to support N blockchain systems registering with blockchain system B11, such as the contract interface Identity register(). For example, a management member of blockchain system B31 can send a registration transaction to blockchain system B11 to call Identity register(). Blockchain system B11 can execute Identity register() based on this registration transaction, storing and activating its registration information in the contract state of Rollup Contract C1. The registration information of blockchain system B11 can come from this registration transaction and may include, but is not limited to, some or all of the following information from blockchain system B11: identification information, genesis block, set of management member addresses, set of sorter addresses, consensus algorithm, storage method of transaction batches, proof type / Rollup mechanism, and its corresponding verification algorithm.

[0074] Similarly, other second blockchain systems such as B21 and B22 can be registered to blockchain system B11, so that the contract state of Rollup Contract C1 stores and activates the registration information of various second blockchain systems such as B21, B22, and B31.

[0075] For example, the contract state of Rollup Contract C1 can store the status indicators corresponding to the registration information of blockchain systems such as B21, B22, and B31. This status information is used to indicate whether the corresponding registration information is effective. For example, if the status indicator is set to 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 blockchain system B11, that is, it indicates that the upper-level blockchain system corresponding to the blockchain system to which the registration information belongs is blockchain system B11. Conversely, if the status indicator is set to 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 blockchain system B11, that is, it indicates that the upper-level blockchain system corresponding to the blockchain system to which the registration information belongs is no longer blockchain system B11.

[0076] When blockchain systems B21, B22, and B31 complete their registration with blockchain system B11 located in Layer 1, all three systems are located in Layer 2. This means that the registration information of B21, B22, and B31 stored in the contract state of Rollup Contract C1 is in an effective state; for example, the status indicator value corresponding to the registration information of B21, B22, and B31 is all 1.

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

[0078] Migration Form 1: Sovereignty in blockchain system B31 is migrated from a higher layer to a lower layer. For example, please refer to... Figure 6 As shown, the sovereignty of B31 may be transferred from B11 located in Layer 1 to B21 located in Layer 2, and then it enters Layer 3.

[0079] Migration Format 2: Sovereignty in blockchain system B31 may be migrated within the same layer. For example, please refer to... Figure 7 As stated, sovereignty of B31 may be transferred from B21 located in Layer 2 to B22 located in Layer 2, while it itself remains in Layer 3.

[0080] Migration Form 3: Sovereignty in blockchain system B31 is migrated from a lower layer to a higher layer. For example, please refer to... Figure 8 As shown, the sovereignty of B31 may be transferred from B22 located in Layer 2 to B11 located in Layer 1, and then it enters Layer 2.

[0081] Similar to the solution for blockchain system B11 to have or terminate 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 (i.e., blockchain system B21 is the upper-layer blockchain system corresponding to blockchain system B31), then blockchain system B21 may deploy a 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 made effective in the contract state of Rollup Contract C2, for example, by setting the value of the corresponding state indicator, so that blockchain system B21 has or terminates its sovereignty over blockchain system B31.

[0082] Based on the aforementioned Layer1, Layer2, and Layer3, we first introduce a method for implementing multi-layer network convolution.

[0083] Figure 9This specification provides a method for implementing multi-layer network cascading in its embodiments. The method describes the process of implementing multi-layer network cascading using any i-th second blockchain system located in Layer 3 (e.g., blockchain system B31), another second blockchain system located in Layer 2 (e.g., blockchain system B21), and blockchain system B11 located in Layer 1; that is, it is described with B11 as the upper-layer blockchain system corresponding to B21 and B21 as the upper-layer blockchain system corresponding to B31.

[0084] The contract state of Rollup Contract C1 deployed on blockchain system B11 includes, in addition to registration information for N second blockchain systems, global management information for those N second blockchain systems. For example, it may also include global management information stored using the respective identifiers of blockchain systems B21, B22, and B31 as keys. RollupContract C1 may include the contract interface CommitBatch(), which allows calls from the Relayer / Sequencer of blockchain system B21.

[0085] The blockchain system B21 located in Layer 2 may include a Rollup Contract C2 set based on the registration information of the blockchain system B31. The Rollup Contract C2 may include, for example, 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.

[0086] Reference Figure 9 As shown, the method may include, but is not limited to, the following steps S901 to S907.

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

[0088] 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, forming a transaction sequence belonging to a certain transaction batch (e.g., transaction batch b3). Then, based on the world state of blockchain system B31 before the transaction sequence is executed, multiple user transactions in the transaction sequence are executed sequentially. Furthermore, information such as the batch number, transaction root, previous state root, and subsequent state root of transaction batch b31 can be obtained accordingly, and the Sequencer / Relayer can initiate transaction Tx1 to blockchain system B21.

[0089] 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 the state data S1 may also include only the aforementioned post-state root.

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

[0091] In step S903, blockchain system B21 executes CommitBatch() 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.

[0092] If transaction Tx1 also includes the batch number of transaction batch b3, when blockchain system B21 executes Commit Batch() in Rollup Contract C2 based on transaction Tx1, it can also achieve the following: In the management information G31 of blockchain system B31, a new position index is added based on the batch number of batch b3. This position index is used to indicate the storage location of the transaction sequence included in batch b3 in blockchain system B21.

[0093] Reference Figure 10As shown, 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, also in MPT form. This Storage Trie tree stores key-value pairs, using the identifier 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 indices. The second state data, for example, can use the Last State Root and Current State Root fields from the previous example to store the previous and next state roots corresponding to batch b3, respectively. To ensure that the management information of different blockchain systems is stored independently within the contract state of Rollup Contract C2, the second state data and all location indices included in management information G31 can be stored as a whole as a value with the identifier information of blockchain system B31 as the key.

[0094] In one possible implementation, the transaction sequence included in batch b3 can be directly stored in transaction Tx1. The position index corresponding to batch b3 may include the batch 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 in the block. In another possible implementation, the transaction sequence included in batch b3 can be stored in the management information G31 of blockchain system B31. The position index may include the batch number of batch b3 and the position information of the transaction sequence included in batch b3 in the management information G31.

[0095] In step S905, blockchain system B21 sends transaction Tx2 to blockchain system B11. Transaction Tx2 is used to call Commit Batch() 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 management information G31 in the Rollup Contract C2 contract state.

[0096] The contract interface Commit Batch() 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. The state data S2 corresponding to transaction batch b2 can include the previous state root and the next state root corresponding to the second transaction batch.

[0097] 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 (e.g., 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 sequentially; furthermore, the batch number, transaction root, previous state root, and subsequent state root of transaction batch b2 can be obtained accordingly, and the Sequencer / Relayer can initiate transaction Tx2 to blockchain system B21.

[0098] It is important to note that transaction Tx2 will only include the identification information and second state data of blockchain system B31 stored in the management information G31 within the contract state of Rollup Contract C2 if blockchain system B21 is the upper-layer blockchain system corresponding to blockchain system B31. If blockchain system B21 is not the upper-layer blockchain system corresponding to blockchain system B31, even if blockchain system B21 includes the 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 the management information G31.

[0099] In a typical example, the Sequencer of blockchain system B21 can query Rollup Contract C2 to find out which blockchain systems' registration information has been effective in blockchain system B21, that is, to find out other blockchain systems, such as blockchain system B31, that are currently using blockchain system B21 as the upper-layer blockchain system. Then, in 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 retrieved from Rollup Contract C2, and the identification information and second state data of blockchain system B31 stored in the management information G31 are added to transaction Tx2.

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

[0101] In step S907, blockchain system B11 executes the contract interface Commit Batch() in Rollup Contract C1 according to transaction Tx2, which implements: 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 according to the identification information and second state data of blockchain system B31.

[0102] If transaction Tx2 also includes the batch number of batch b2, blockchain system B11 executes the contract interface Commit Batch() in Rollup Contract C1 based on transaction Tx2. It can also add a location index to the global management information GZ2 of blockchain system B21. This location index is used to indicate the storage location of batch b2 in blockchain system B11.

[0103] Reference Figure 10As shown, 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, also in MPT form. This Storage Trie tree stores key-value pairs, using the identifiers of blockchain systems B21 and B31 as keys, and storing the global management information GZ21 and GZ31 of blockchain systems B21 and B31, respectively. The global management information G21 includes the third state data of blockchain system B21 and one or more position indices. For example, the third state data can use the Last State Root and Current State Root fields from the previous example to store the previous and next state roots corresponding to batch b2, respectively. Similarly, the fourth state data can use the Last State Root and Current State Root fields from the previous example to store the second state data. In order to store the global management information of different blockchain systems independently in the contract state of Rollup Contract C1, all sovereign migration records, all location indexes and fourth state data included in the global management information GZ31 can be stored as a value with the identification information of blockchain system B31 as the key; similarly, all location indexes and second state data included in the global management information GZ21 can be stored as a value with the identification information of blockchain system B31 as the key.

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

[0105] When any blockchain system uses a designated blockchain system as its 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 that time period through the management information or global management information of the arbitrary blockchain system. This allows the system to query the storage location of the transaction sequence included in the submitted transaction batch of the arbitrary blockchain system in the designated blockchain system when the arbitrary blockchain system fails, using the corresponding location index. Consequently, the system can be recovered, or a portion of the data in the arbitrary blockchain system, using the transaction sequence included in the submitted transaction batch.

[0106] It is necessary to understand that the aforementioned Figure 9 The method steps in the illustrated embodiment only describe the process of submitting a transaction batch through a prover / relay in a multi-layered convolutional network including Layer 1, Layer 2, and Layer 3. In reality, blockchain system B21 located in Layer 2 and blockchain system B31 located in Layer 3 may also submit proofs of relevant transaction batches to their respective upper-layer blockchain systems through their respective provers. After the proofs of relevant transaction batches are verified, the relevant transaction batches and their corresponding contract call transactions can enter the finality state.

[0107] Based on the aforementioned Layer 1, Layer 2, and Layer 3, a management method for a blockchain system will be introduced next.

[0108] Figure 11 This is a flowchart illustrating 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 sovereignty migration for any i-th second blockchain system (denoted as blockchain system B31) among the N second blockchain systems.

[0109] Reference Figure 11 As shown, the method may include, but is not limited to, some or all of the following steps S1101 to S1109.

[0110] Optionally, the Rollup Contract C1 deployed by blockchain system B11 includes a second method function, for example, represented by the contract interface Termination sovereignty(). If the current upper-layer blockchain system corresponding to blockchain system B31 is blockchain system B11 or the fourth blockchain system among the other N-1 second blockchain systems, and the management members of blockchain system B31 expect that the fourth blockchain system will no longer be the upper-layer blockchain system corresponding to blockchain system B31 after the first transaction batch submitted by blockchain system B31 enters the immutable state, then the management members of blockchain system B31 can initiate a second transaction (denoted as transaction Tx3) to blockchain system B11.

[0111] Correspondingly, blockchain system B11 can execute step S1101 to receive transaction Tx3. Transaction Tx3 is used to call the Termination sovereignty() function in Rollup Contract C1. Transaction Tx3 requests that after the first transaction batch submitted by blockchain system B31 enters the immutable state, the fourth blockchain system will no longer be the upper-level blockchain system corresponding to blockchain system B31.

[0112] The following description will primarily use N second blockchain systems, including blockchain systems B21, B22, and B31, as examples. Based on this, the aforementioned fourth blockchain system could be blockchain system B11, B21, or B22.

[0113] Transaction Tx3 may include, for example, 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.

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

[0115] The blockchain system B11 records the result or related information of the Termination Sovereignty() operation based on transaction Tx3 in the corresponding receipt. Specifically, the contract execution result / related information can be represented as an event in the receipt. An event typically includes a topic field and a data field. The topic field records the event's subject, and the data field records the corresponding information. The event format can be specified in the contract. Through the built-in SDK, clients or blockchain nodes can listen for events on specific topics and, upon detecting an event on a specific topic, retrieve the corresponding data. They can also execute pre-defined processing after listening for specific topics or certain content within the corresponding data.

[0116] Through this event mechanism, blockchain system B11 can store the execution result in the event corresponding to a certain topic. Thus, the fourth blockchain system can listen to the topic through the blockchain client built into its Sequencer / Relayer, obtain the corresponding sovereign termination event, and know through the sovereign termination event that it will no longer be the upper layer blockchain system corresponding to blockchain system B31 after the first transaction batch submitted by blockchain system B31 enters the immutable state.

[0117] Correspondingly, in step S1105, the fourth blockchain system, based on the sovereign termination event, invalidates the registration information of blockchain system B31 in its deployed third roll-over contract after confirming that the first transaction batch has entered an immutable state.

[0118] 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 still retains sovereignty over blockchain system B31, it or its management members can perceive whether the first transaction batch has entered an immutable state based on the batch sequence number of the first transaction batch. When the first transaction batch has entered an immutable state, the relevant infrastructure in blockchain system B11 can automatically initiate, or be initiated by the management members of blockchain system B11, a target transaction that calls a specific method function in Rollup Contract C1, such as the contract interface Indicate change(). Blockchain system B11 executes the contract interface Indicate change() according to the target transaction, thereby terminating blockchain system B11's sovereignty over blockchain system B31. For example, in the contract state of Rollup Contract C1, the status indicator corresponding to the registration information of blockchain system B31 is set from 1 to 0.

[0119] The preceding text used blockchain system B11 as an example to illustrate 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 initiate target transactions to invoke their own deployed third-layer contracts through similar strategies, thereby terminating sovereignty over B31 through similar methods.

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

[0121] Blockchain system B31 can also learn that the first transaction batch has entered an immutable state through other means. For example, when the fourth blockchain system is blockchain system B11, after the prover of blockchain system B31 submits the proof corresponding to the first transaction batch to blockchain system B11 through the relevant transaction and passes the verification, blockchain system B11 may generate a corresponding proof notification event for the relevant transaction. This allows blockchain system B31 and its management members to learn that the first transaction batch has entered an immutable state through the proof notification event corresponding to the relevant transaction.

[0122] When the management members of blockchain system B31 realize that the first transaction batch has entered an immutable state and wish to transfer the sovereignty of blockchain system B31 to a third blockchain system, they can initiate the first transaction (denoted as transaction Tx4).

[0123] Correspondingly, blockchain system B11 can then execute step S1107, receiving transaction Tx4 for invoking Sovereign transfer() in RollupContract C1. Transaction Tx4 requests that the third blockchain system be used as the upper-layer 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.

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

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

[0126] Referring to the previous example, the N second blockchain systems include blockchain systems B21, B22, and B31, and the aforementioned fourth blockchain system can be blockchain system B11, B21, or B22. Therefore, the aforementioned third blockchain system can be blockchain system B11, B21, or B22, where the third blockchain system differs from the fourth blockchain system.

[0127] Sovereign migration events may also include registration information from the blockchain system B31.

[0128] When blockchain system B11 executes the Sovereign transfer() function in Rollup Contract C1 based on transaction Tx4, it refers to... Figure 10 Furthermore, it is possible to add a sovereign migration record in the global management information GZ31 of the 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.

[0129] In step S1111, the third blockchain system, based on the sovereign migration event, uses the registration information of blockchain system 31 to set up a second roll-over contract corresponding to blockchain system 31 in the third blockchain system.

[0130] The third blockchain system can obtain sovereignty migration events through the aforementioned event listening mechanism, meaning that the Sequencer / Relayer and management members of the third blockchain system may be aware of sovereignty migration events. When no roll-up contract is deployed in the third blockchain system, the Sequencer / Relayer can automatically initiate a contract deployment transaction, or a management member can initiate such a transaction. The third blockchain system can then deploy the second roll-up contract by executing this transaction and call the contract interface, such as Identity register(), through the corresponding interface call transaction. Execution of this interface call transaction stores and activates the registration information of blockchain system 31 in the contract state of the second roll-up contract, thus making the third blockchain system the upper-layer blockchain system corresponding to blockchain system B31. Similarly, when a second roll-up contract is deployed in the third blockchain system, the Sequencer / Relayer can automatically initiate the aforementioned interface call transaction, or a management member can initiate such a transaction. The third blockchain system can then store and activate the registration information of blockchain system 31 in the contract state of the second roll-up contract by executing this transaction, thus becoming the upper-layer blockchain system corresponding to blockchain system B31.

[0131] The third blockchain system can obtain the registration information of blockchain system B31 from the sovereign migration event, or it can obtain the registration information of blockchain system B31 from Rollup Contract C1 through other means. This is so that in subsequent processes, Rollup Contract C1 can process contract call 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.

[0132] In step S1113, the third blockchain system stores the first state data corresponding to the first transaction batch that was last submitted by blockchain system B31 and has entered the immutable state in the contract state of the second stacked contract.

[0133] Refer to the previous text as follows Figure 9 According to the relevant content described in the illustrated embodiment, after blockchain system B31 submits transaction batch b3, the state data S1 corresponding to transaction batch b3 will be stored as the second state data in the smart contract Rollup Contract C2 deployed by the upper-layer blockchain system B21. This 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 in blockchain system B21 as the fourth state data.

[0134] Correspondingly, once the first transaction batch has entered an immutable state, the fourth state data of blockchain system B31 stored in blockchain system B21 is also the first state data corresponding to the first transaction batch. Therefore, the sovereign migration event can also include the fourth state data of blockchain system B31, which is also the first state data.

[0135] 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 the various blockchain systems that were previously the corresponding upper-layer blockchain systems, obtaining the transaction sequences and proofs included in each of the transaction batches submitted by blockchain system B31 and entering a state where no higher state is possible. By replaying the genesis block and the transaction sequences included in each of the transaction batches, the first state data corresponding to the first transaction batch can be obtained. Alternatively, the first state data corresponding to the first transaction batch can be obtained from a fourth blockchain system through decentralized infrastructure such as a relay.

[0136] The management members of blockchain system B31 may also wish to reuse the infrastructure of the corresponding upper-layer blockchain system, such as one or more of the infrastructure components like sequencers, provers, and relayers. Correspondingly, 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 can initiate a fourth transaction (denoted as transaction Tx5) to blockchain system B11 to invoke Facility management(). Transaction Tx5 requests blockchain system B31 to reuse the infrastructure in the third blockchain system used to execute 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 indication information, whereby the indication information indicates the infrastructure to be reused. Then, blockchain system B11 can execute Facility management() in Rollup Contract C1 according to 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 events through an event listening mechanism. Then, based on these events, it can execute predetermined transactions required in blockchain system B31 through its own infrastructure, which is indicated by corresponding instruction information. For example, the sequencer and prover in the third blockchain system can execute some of the transactions that need to be performed in blockchain system B31.

[0137] Based on the same concept as the aforementioned method embodiments, this specification also provides a blockchain node 120 in a first blockchain system. The first blockchain system deploys a first roll-over contract, which includes a first method function. The contract state of the first roll-over contract stores registration information of N second blockchain systems. See also... Figure 12As shown, the blockchain node 120 includes: a transaction receiving unit 1201, configured to receive a first transaction for calling the first method function, wherein the first transaction request uses the third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; and a transaction execution unit 1203, configured to execute the first method function according to the first transaction to achieve: generating a sovereign migration event, wherein the sovereign migration event 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 to set a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system.

[0138] This specification also provides a computer-readable storage medium storing a computer program / instruction, which, when executed in a computer, causes the computer to perform the method steps executed by the blockchain system B11, blockchain system B21, blockchain system B31, or the third or fourth blockchain system in the aforementioned embodiments.

[0139] This specification also provides a computing device in the embodiments, including a memory and a processor. The memory stores computer programs / instructions. When the processor executes the computer programs / instructions, it implements the method steps executed by the blockchain system B11, blockchain system B21, blockchain system B31, or the third or fourth blockchain system in the foregoing embodiments.

[0140] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0141] The controller can be implemented in any suitable manner. For example, it 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 Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0143] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0144] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0145] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0146] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0147] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0149] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0150] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

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

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

Claims

1. A management method for a blockchain system, the method comprising: The first blockchain system receives the first transaction. The first blockchain system deploys a first roll-up contract including a first method function. The contract state of the first roll-up contract stores the registration information of N second blockchain systems. 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 second 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 based on the first transaction to achieve: generating a sovereign migration event, wherein the sovereign migration event includes the identification information of the i-th second blockchain system and the third blockchain system; Based on the sovereign migration event, the third blockchain system uses the registration information of the i-th second blockchain system to set up a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system.

2. The method according to claim 1, further comprising: The third blockchain system stores the first state data corresponding to the first transaction batch that was most recently submitted by the i-th second blockchain system and has entered an unchangeable state in the contract state of the second stacked contract.

3. The method according to claim 1, wherein the third blockchain system, based on the sovereign migration event, uses the registration information of the i-th second blockchain system to set up a second volume contract corresponding to the i-th second blockchain system in the third blockchain system, comprising: The third blockchain system, based on the sovereign migration event, activates the registration information of the i-th second blockchain system in its deployed second roll-over contract.

4. The method according to claim 1, wherein the first roll-over contract further includes a second method function; in, The method further includes: The first blockchain system receives a second transaction for calling the second method function. The second transaction requests the fourth blockchain system to no longer be the upper-layer blockchain system corresponding to the i-th second blockchain system after the first transaction batch submitted by the i-th second blockchain system enters the immutable state. The fourth blockchain system is a blockchain system that is 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 to achieve: generating a sovereign termination event, wherein the sovereign 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; Based on the sovereign termination event, after confirming that the first transaction batch has entered an immutable state, the fourth blockchain system invalidates the registration information of the i-th second blockchain system in its deployed third roll-over contract.

5. The method according to claim 4, wherein the contract state of the first stacked contract includes global management information of the N second blockchain systems, the fourth blockchain system belongs to the remaining N-1 blockchain systems, and the first stacked contract further includes a third method function; wherein, The method further includes: The first blockchain system receives a third transaction from the fourth blockchain system for calling the third method function. 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 next state root corresponding to the second transaction batch, and the identification information and second state data of the i-th second blockchain system stored in the contract state of the third roll-up contract. The first blockchain system executes the third method function according to the third transaction to: store the transaction sequence included in the second transaction batch; update the third state data of the fourth blockchain system in the global management information of the fourth blockchain system according to the previous state root and the next state root corresponding to the second transaction batch; and update the fourth state data of the i-th second blockchain system in the global management information of the i-th second blockchain system according to the identification information and the second state data 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, The execution of the third method function based on the third transaction further includes: adding a batch position index in the global management information of the fourth blockchain system based on the batch number of the second transaction batch, which indicates the storage location of the second transaction batch in the first blockchain system.

7. The method according to claim 6, wherein the batch position index comprises: The batch number of the second transaction batch, the block number of the third transaction in the first blockchain system, and the transaction number.

8. The method according to claim 5, wherein the sovereign migration event further includes first state data, the first state data being the fourth state data included in the global management information of the i-th second blockchain system.

9. The method according to claim 8, wherein the contract state of the first stacked contract further includes the global management information of the N second blockchain systems; wherein, The execution of the first method function based on the first transaction further includes: adding a sovereignty migration record to 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 sovereign migration record further includes the first state data.

11. The method according to claim 1, wherein the sovereign migration event further includes the registration information of the i-th second blockchain system.

12. The method according to claim 1, wherein the third blockchain system belongs to the remaining N-1 second blockchain systems, and the first stacked contract further includes a fourth method function; wherein, The method further includes: The first blockchain system receives a fourth transaction from the i-th second blockchain system for invoking the fourth method function, and the fourth transaction requests reuse of the infrastructure in the third blockchain system used to execute the predetermined transaction; The first blockchain system executes the fourth method function according to the fourth transaction to achieve: generating a facility reuse event, which includes 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 of the third blockchain system based on the facility reuse event.

13. The method of claim 12, wherein the infrastructure of the third blockchain system includes at least one of the following: a sorter, 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: identification information, genesis block, set of management member addresses, set of sorter addresses, storage method of transaction batch, rollup mechanism and its corresponding verification algorithm.

15. A management method for a blockchain system, the method being executed by a first blockchain system having a first stacked contract deployed thereon, the first stacked contract including a first method function, the contract state of the first stacked contract storing registration information of N second blockchain systems, the method comprising: Receive a first transaction for invoking the first method function, wherein the first transaction request regards the third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems; The first method function is executed according to the first transaction to achieve: generating a sovereign migration event, wherein the sovereign migration event includes the identification information of the i-th second blockchain system and the third blockchain system, so that the third blockchain system, based on the sovereign migration event and using the registration information of the i-th second blockchain system, sets up a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system.

16. A blockchain node in a first blockchain system, wherein a first roll-over contract is deployed in the first blockchain system, the first roll-over contract includes a first method function, and the contract state of the first roll-over contract stores registration information of N second blockchain systems, the blockchain node comprising: The transaction receiving unit is configured to receive a first transaction for calling the first method function, wherein the first transaction request regards the third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system, and the third blockchain system is one of the first blockchain system and the remaining N-1 second blockchain systems. The transaction execution unit is configured to execute the first method function according to the first transaction to achieve: generating a sovereign migration event, wherein the sovereign migration event includes the identification information of the i-th second blockchain system and the third blockchain system, and enabling the third blockchain system to set up a second roll-over contract corresponding to the i-th second blockchain system in the third blockchain system according to the sovereign migration event and using the registration information of the i-th second blockchain system.

Images