Blockchain system management method and blockchain node

Abstract

A blockchain system management method and a blockchain node. The method comprises: a first blockchain system receives a first transaction from a client, wherein the first transaction is used for calling a first method function in a first rollup contract, and comprises identification information of an i-th second blockchain system; and the first blockchain system executes the first method function on the basis of the first transaction to implement the following: determining at least one sovereignty migration record from global management information of the i-th second blockchain system, wherein the at least one sovereignty migration record comprises identification information of a third blockchain system; and returning the at least one sovereignty migration record to the client, wherein the at least one sovereignty migration record is used for supporting the client to obtain at least one transaction sequence from the third blockchain system, and the transaction sequence belongs to a transaction batch submitted during a period when the i-th second blockchain system takes the third blockchain system as a corresponding upper-layer blockchain system thereof.

Description

Blockchain system management method and blockchain nodes

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

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

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

[0004] Summary of the Invention

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

[0006] In a first aspect, a sovereignty management method for a blockchain system is provided, the method comprising: a first blockchain system receiving a first transaction from a client, a first rollup contract including a first method function being deployed in the first blockchain system, global management information of N second blockchain systems being stored in the contract state of the first rollup contract, the first transaction being used to call the first method function, including identification information of the i-th second blockchain system; the first blockchain system executing the first method function according to the first transaction to implement: determining at least one sovereignty transfer record from its global management information according to the identification information of the i-th second blockchain system, the sovereignty transfer record including identification information of a third blockchain system, and returning the at least one sovereignty transfer record to the client; the third blockchain system receiving a second transaction from the client, the A second rollup contract including a second method function is deployed in the third blockchain system, the contract state of the second rollup contract includes management information of the i-th second blockchain system, the second transaction is used to call the second method function, and the second transaction includes identification information of the i-th second blockchain system; the third blockchain system executes the second function according to the second transaction, thereby: determining at least one location index from its management information based on the identification information of the i-th second blockchain system, and determining at least one transaction sequence stored in the third blockchain system based on the at least one location index, wherein the transaction sequence belongs to a transaction batch submitted by the i-th second blockchain system during the period when the third blockchain system is used as its corresponding upper-layer blockchain system, and returning the at least one transaction sequence to the client.

[0007] In a second aspect, a blockchain system management method is provided, the method being executed by a first blockchain system having a first rollup contract deployed thereon, wherein the contract state of the first rollup contract stores global management information of N second blockchain systems, and the first rollup contract includes a first method function; the method comprising: receiving a first transaction from a client for invoking the first method function, wherein the transaction includes identification information of an i-th second blockchain system; executing the first method function according to the first transaction, thereby: determining, based on the identification information of the i-th second blockchain system, at least one sovereignty transfer record from the global management information of the i-th second blockchain system, wherein the record includes identification information of a third blockchain system; and returning the at least one sovereignty transfer record to the client, so that the client obtains at least one transaction sequence from the third blockchain system, wherein the transaction sequence belongs to a transaction batch submitted by the i-th second blockchain system during a period in which the third blockchain system is used as its corresponding upper-layer blockchain system.

[0008] According to a third aspect, a blockchain node in a first blockchain system is provided. A first rollup contract is deployed in the first blockchain system, the first rollup contract includes a first method function, and the contract state of the first rollup contract stores global management information of N second blockchain systems. The blockchain node includes: a transaction receiving unit configured to receive a first transaction for invoking the first method function from a client, the first transaction including identification information of an i-th second blockchain system; and a transaction executing unit configured to execute the first method function according to the first transaction, thereby: determining, based on the identification information of the i-th second blockchain system, at least one sovereignty transfer record from the global management information of the i-th second blockchain system, including identification information of a third blockchain system, and returning the at least one sovereignty transfer record to the client, so that the client obtains, based on the at least one sovereignty transfer record, at least one transaction sequence from the third blockchain system, the transaction sequence belonging to a transaction batch submitted by the i-th second blockchain system during a period in which the third blockchain system is used as its corresponding upper-layer blockchain system.

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

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

[0011] In the technical solution provided by the embodiments of this specification, global management information of N second blockchain systems located at Layer 2, Layer 3, or even lower layers is maintained in a first blockchain system located at Layer 1. The global management information records the sovereignty transfer status of the corresponding blockchain system through sovereignty transfer records. Therefore, the sovereignty transfer records can be used to support any i-th second blockchain system when data recovery is required for some reason. The transaction sequence included in the transaction batch used for data recovery can be obtained from each blockchain system that was once the blockchain system of the upper layer corresponding to the i-th second blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0074] In order to support blockchain systems located at Layer 2, Layer 3, and even lower layers to complete sovereignty transfer efficiently and securely, a first rollup contract (represented by Rollup Contract C1 in the following) can be deployed in the first blockchain system located at Layer 1 (represented by Blockchain System B11 in the following). Rollup Contract C1 provides a method function for supporting registration of any second blockchain system (represented by the contract interface Identity register() in the following).

[0075] First, for any i-th second blockchain system among the N blockchain systems located at Layer 2, Layer 3 or even lower layers, such as blockchain system B31. The management member of blockchain system B31 can send a registration transaction for calling the contract interface Identity register() to blockchain system B11. Blockchain system B11 can execute Identity register() according to the registration transaction to store and take effect the registration information of blockchain system B11 in the contract state of Rollup Contract C1. The registration information of blockchain system B31 can come from the registration transaction, which may include but is not limited to part or all of the following information of blockchain system B31: identification information, genesis block, management member address set, sorter address set, consensus algorithm, transaction batch storage method, proof type / Rollup mechanism and its corresponding verification algorithm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0090] Because blockchain system B21 is the upper-layer blockchain system corresponding to blockchain system B31, blockchain system B21 is equivalent to a third blockchain system corresponding to blockchain system B31; Rollup Contract C2 is equivalent to the second rollup contract in the third blockchain system; Commit Batch() in Rollup Contract C2 is equivalent to the fourth method function in the second rollup contract; transaction Tx1 is equivalent to the fourth transaction used to call the fourth method function, and transaction batch b3 is equivalent to the second transaction batch.

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

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

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

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

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

[0096] In step S905, blockchain system B21 sends transaction Tx2 to blockchain system B11. Transaction Tx2 is used to call CommitBatch() in Rollup Contract C1. Transaction Tx2 includes the transaction sequence included in transaction batch b2 submitted by blockchain system B21, the batch number of transaction batch b2, and the status data S2 corresponding to transaction batch b2.

[0097] Commit Batch() in Rollup Contract C1 is the third method function, and transaction Tx2 is the third transaction.

[0098] In some embodiments, transaction Tx2 may also include identification information and second state data of blockchain system B31 stored in the contract state of Rollup Contract C2 through management information G31.

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

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

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

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

[0103] In step S907, blockchain system B11 executes Commit Batch() in Rollup Contract C1 according to transaction Tx2, thereby storing the transaction sequence included in transaction batch b2, adding a position index based on the batch number of transaction batch b2 to the global management information GZ21 of blockchain system B21, and indicating the storage location of the transaction sequence included in batch b2 in blockchain system B11. The third state data of blockchain system B21 is then updated to state data S2.

[0104] When transaction Tx2 also includes the identification information and the second state data of the blockchain system B31, when executing Commit Batch() in Rollup Contract C1 according to transaction Tx2, it can also be achieved: in the global management information GZ3 of the blockchain system B31, the fourth state data of the blockchain system B31 is updated to the second state data.

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

[0106] Based on a similar process, if the upper-layer blockchain system corresponding to blockchain system B31 within a certain time period includes blockchain system B11, the global management information GZ31 of blockchain system B31 will also include one or more location indexes corresponding to a part of the transaction batch submitted by blockchain system B31.

[0107] When any blockchain system uses a designated blockchain system as its corresponding upper-layer blockchain system within a certain time period, the designated blockchain system can maintain the location indexes corresponding to the respective transaction batches submitted by the arbitrary blockchain system within the time period through the management information or global management information of the arbitrary blockchain system. This can support the storage location of the transaction sequence included in the transaction batch submitted by the arbitrary blockchain system in the designated blockchain system through the corresponding location index when the arbitrary blockchain system needs to recover data for some reason. Furthermore, the transaction sequence included in the submitted transaction batch can be used to restore the arbitrary blockchain system or part of the data in the arbitrary blockchain system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0125] Correspondingly, blockchain system B11 can then execute step S1107 and receive transaction Tx4 for calling Sovereign transfer() in Rollup Contract 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 belongs to blockchain system B11 or the remaining N-1 second blockchain systems.

[0126] It can be understood that Sovereign transfer() represents the fifth method function included in Rollup Contract C1.

[0127] Transaction Tx4 may, for example, include the identification information of the third blockchain system. It may also include the batch number of the third transaction batch or the batch number of the next transaction batch after the third transaction batch. The batch number of the next transaction batch after the third transaction batch is the first batch number corresponding to the transaction batch first submitted by blockchain system B31 during the period when blockchain system B31 used the third blockchain system as its corresponding upper-layer blockchain system. Transaction Tx4 may also include the identification information of blockchain system B31 and the identification information of the fourth blockchain system.

[0128] In step S1109, blockchain system B11 executes Sovereign transfer() in Rollup Contract C1 according to transaction Tx4, thereby adding a new sovereignty transfer record to the global management information GZ31 of blockchain system B31, which includes the identification information of the third blockchain system and the batch number corresponding to the next transaction batch of the third transaction batch, and generates a sovereignty transfer event, which includes the identification information of blockchain system B31 and the third blockchain system.

[0129] The batch number corresponding to the next transaction batch of the third transaction batch, that is, the first batch number corresponding to the first transaction batch submitted during the period when blockchain system B31 uses the third blockchain system as its corresponding upper-layer blockchain system.

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

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

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

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

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

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

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

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

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

[0139] The method embodiment shown in FIG11 above exemplarily describes the process of blockchain system B31 performing a sovereignty transfer. However, it is understandable that blockchain system B31 may perform multiple sovereignty transfers.

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

[0141] In the method embodiments shown in Figures 9 and 11 above, although exemplary descriptions are provided of how to maintain the sovereignty transfer record of blockchain system B31 in blockchain system B11, maintain the position index corresponding to the transaction sequence included in the transaction batch submitted by blockchain system B21 in blockchain system B11, and maintain the position index corresponding to the transaction sequence included in the transaction batch submitted by blockchain system B31 in blockchain system B21, it is understood that other methods may also be used to maintain the sovereignty transfer record and position index corresponding to each second blockchain system.

[0142] For example, when blockchain system B21 uses a third blockchain system as its corresponding upper-layer blockchain system, management members of blockchain system B31 can directly register blockchain system B31 with the third blockchain system without the involvement of blockchain system B11. Management members of blockchain system B31 can then initiate a contract call transaction for Rollup Contract C1, ultimately adding a corresponding sovereignty transfer record to blockchain system B31's global management information. Similarly, blockchain system B31 may also include, in transaction Tx2, the transaction sequence, batch number, and status data corresponding to one or more transaction batches submitted by blockchain system B31, in addition to transaction batch b2.

[0143] Any i-th second blockchain system, such as blockchain system B31, may experience loss or anomalies in its world state data due to maintenance stoppage by management members or other failures. In this case, users of blockchain system B31 or management members of blockchain system B31 may desire to obtain the transaction sequences included in some or all transaction batches submitted by blockchain system B31 in order to restore blockchain system B31's world state data through transaction replay.

[0144] Figure 12 is a flowchart of a blockchain system management method provided in an embodiment of this specification. This method involves blockchain system B11 located in Layer 1 and N secondary blockchain systems located in Layer 2, Layer 3, or even lower layers. Rollup Contract C1 deployed by blockchain system B11 includes a first method function, hereinafter represented by the contract interface Data management(). The contract state of Rollup Contract C1 includes global management information for the N secondary blockchain systems, for example, using the identification information of the N secondary blockchains as a key to store this global management information.

[0145] As described above, the global management information of any i-th second blockchain system may include one or more sovereignty transfer records corresponding to the i-th second blockchain system, and may also include one or more corresponding location indexes.

[0146] As shown in FIG. 12 , the method may include but is not limited to part or all of the following steps S1201 to S1207 .

[0147] When the management member of any i-th second blockchain system (for example, blockchain system B31) wishes to obtain the transaction sequence included in part or all of the transaction batches submitted by blockchain system B31 and restore the world state data of blockchain system B3, the user in blockchain system B31 or the management member of blockchain system B31 can initiate the first transaction (denoted as transaction Tx6) for calling the contract interface Data management() in Rollup Contract C1 through the corresponding client.

[0148] Correspondingly, blockchain system B11 may execute step S1201 to receive transaction Tx6 from the client. Transaction Tx6 is used to call Data management() in Rollup Contract C1, which includes identification information of blockchain system B31.

[0149] When a user or management member of blockchain system B31 holds the world state data corresponding to a target transaction batch submitted by blockchain system B31, the transaction batches submitted by blockchain system B31 after the target transaction batch are the transaction batches to be recovered; the batch sequence number corresponding to the next transaction batch after the target transaction batch is the starting batch sequence number corresponding to the transaction batches to be recovered, and the starting batch sequence number may be included in transaction Tx6.

[0150] When holding the world state data corresponding to a target transaction batch submitted by blockchain system B31, all transaction batches submitted by blockchain system B31 are transaction batches to be restored, and the genesis block is required.

[0151] In step S1203, blockchain system B11 executes Data management() in Rollup Contract C1 according to transaction Tx6, thereby: determining at least one sovereignty transfer record from the global management information of blockchain system B31 based on the identification information of blockchain system B31, including the identification information of the third blockchain system, and returning at least one sovereignty transfer record to the client.

[0152] As previously mentioned, when blockchain system B31 transfers sovereignty to a third blockchain system, making it its corresponding parent blockchain system, a new sovereignty transfer record will be added to blockchain system B31's global management information. This sovereignty transfer record will include at least the identification information of the third blockchain system. Furthermore, this sovereignty transfer record may also include the first batch number corresponding to the first transaction batch submitted by blockchain system B31 during the period when blockchain system B31 used the third blockchain system as its corresponding parent blockchain system. Therefore, after one or more sovereignty transfers occur within blockchain system B31, its global management information may include one or more corresponding sovereignty transfer records.

[0153] If transaction Tx6 includes the starting batch numbers corresponding to several transaction batches to be restored, when executing Data management() in Rollup Contract C1 based on transaction Tx6, since the subsequent process does not need to use the transaction sequence included in the transaction batches with batch numbers smaller than the starting batch number to restore the world state data, for each sovereignty transfer record included in the global management information of blockchain system B31, if the first batch number in the sovereignty transfer record is not smaller than the starting batch number, it will be returned to the client; otherwise, the sovereignty transfer record does not need to be returned to the client.

[0154] If the starting batch number is not included in transaction Tx6, when blockchain system B11 executes Data management() in Rollup Contract C1 according to transaction Tx6, it can also return the genesis block of blockchain system B31 to the corresponding client.

[0155] Users or management members of blockchain system B31 can learn which blockchain systems the transaction batch to be restored is stored in through the identification information of the third blockchain system included in at least one sovereignty transfer record received by the corresponding client, and can then initiate a second transaction (recorded as transaction Tx7) to each third blockchain system through the client.

[0156] In conjunction with the method embodiments shown in Figures 9 and 11 above, it can be understood that the third blockchain system may be provided with a second rollup contract corresponding to blockchain system B31 (hereinafter referred to as Rollup Contract X). Rollup Contract X may, for example, include a second method function that can be called by the client, such as the contract interface Data management(). The contract state in Rollup Contract X stores management information or global management information of blockchain system B31. Moreover, the third blockchain system may be blockchain system B11 or one of the remaining N-1 second blockchain systems. Furthermore, it is not difficult to understand that when the third blockchain system includes blockchain system B11, the second rollup contract may be Rollup Contract C1; when the third blockchain system includes blockchain system B21, the second rollup contract may be Rollup Contract C2.

[0157] In step S1205, the third blockchain system receives transaction Tx7 from the client. Transaction Tx7 is used to call Data management() in Rollup Contract X. Transaction Tx7 includes identification information of blockchain system B31.

[0158] When the transaction Tx6 can include the starting batch number, the transaction Tx7 also includes the starting batch number.

[0159] In step S1207, the third blockchain system executes Data management() in Rollup Contract X according to transaction Tx7, thereby: determining at least one location index from the management information of blockchain system B31 based on the identification information of blockchain system B31, and determining at least one transaction sequence stored in the third blockchain system based on the at least one location index. The at least one transaction sequence belongs to the transaction batch submitted by blockchain system B31 during the period when the third blockchain system was used as its corresponding upper-layer blockchain system, and returning the at least one transaction sequence to the client.

[0160] The position index is used to indicate the storage location of the transaction sequence included in the relevant transaction batch in the blockchain system B21.

[0161] Referring to the previous description of location indexes, any location index determined from the management information of blockchain system B31 may include a batch number, a block number, and a transaction number. Accordingly, for a single location index within the at least one aforementioned location index, the corresponding target block can be determined from the third blockchain system based on the block number and transaction number, and the corresponding target transaction can be determined from the target block based on the transaction number. Furthermore, a corresponding transaction sequence can be obtained from the target transaction. This transaction sequence belongs to the transaction batch corresponding to the batch number included in the location index.

[0162] Referring to the previous description of location indexes, any location index determined from the management information of blockchain system B31 may include a batch number and the storage location of a transaction sequence in the management information of blockchain system B31. Accordingly, for a single location index in the at least one aforementioned location index, the corresponding transaction sequence can be determined from the management information of blockchain system B31 based on the location information included in the location index.

[0163] If transaction Tx7 includes the starting batch sequence number corresponding to several transaction batches to be restored, when executing Data management() in Rollup Contract X based on transaction Tx7, since the subsequent process does not need to use the transaction sequence included in the transaction batch with a batch sequence number less than the starting batch sequence number to restore the world state data, for each location index included in the management information of blockchain system B31, if the batch sequence number in the location index is not less than the starting batch sequence number, the corresponding transaction sequence is queried in the third blockchain system based on the location index and returned to the client. Otherwise, there is no need to query the corresponding transaction sequence in the third blockchain system based on the location index.

[0164] If transaction Tx7 does not include the starting batch sequence number corresponding to the several transaction batches to be restored, the aforementioned at least one piece of location information can be all the location indexes included in the management information of the blockchain system B31.

[0165] When the third blockchain system includes blockchain system B11, Rollup Contract X may be Rollup Contract C1 in blockchain system B11, and the management information of blockchain system B31 stored in the contract state of Rollup Contract X may specifically be the global management information of blockchain system B31 stored in the contract state of Rollup Contract C1.

[0166] Because blockchain system B31 may undergo multiple sovereignty transfers, multiple sovereignty transfer records are generated. A single sovereignty transfer record includes not only the identification information of a third blockchain system, but also the first batch number corresponding to the first transaction batch submitted by the blockchain system after the third blockchain system is used as its corresponding upper-layer blockchain system. In this way, each sovereignty transfer record can be independently used as a checkpoint, allowing users or management members of blockchain system B31 to more quickly complete the query of several transaction batches used to restore world state data from the large number of transaction batches they have submitted.

[0167] After obtaining the at least one transaction sequence, the user or management member of the blockchain system B31 can re-execute the at least one transaction sequence based on the genesis block of the blockchain system B31 or the world state data corresponding to a target transaction batch submitted by the blockchain system, and the at least one transaction sequence, thereby restoring the at least one transaction batch submitted by the blockchain system B31 and corresponding to the at least one transaction sequence, and obtaining the corresponding world state data.

[0168] Based on the same concept as the aforementioned method embodiment, embodiments of this specification also provide a blockchain node 130 in a first blockchain system. A first rollup contract is deployed in the first blockchain system, the first rollup contract including a first method function, and the contract state of the first rollup contract stores global management information of N second blockchain systems. As shown in FIG13 , the blockchain node 130 includes: a transaction receiving unit 131 configured to receive a first transaction from a client for invoking the first method function, the first transaction including identification information of an i-th second blockchain system; and a transaction executing unit 133 configured to execute the first method function based on the first transaction, thereby: determining, based on the identification information of the i-th second blockchain system, at least one sovereignty transfer record from the global management information of the i-th second blockchain system, including identification information of a third blockchain system, and returning the at least one sovereignty transfer record to the client, so that the client, based on the at least one sovereignty transfer record, obtains at least one transaction sequence from the third blockchain system, the transaction sequence belonging to a transaction batch submitted by the i-th second blockchain system during the period when the third blockchain system was used as its corresponding upper-layer blockchain system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A management method for a blockchain system, the method comprising: The first blockchain system receives a first transaction from a client. A first stacked contract including a first method function is deployed in the first blockchain system. Global management information of N second blockchain systems is stored in the contract state of the first stacked contract. The first transaction is used to call the first method function, which includes the identification information of the i-th second blockchain system; The first blockchain system executes the first method function according to the first transaction, and realizes: determining at least one sovereignty migration record from its global management information according to the identification information of the i-th second blockchain system. The sovereignty migration record includes the identification information of a third blockchain system, and returning the at least one sovereignty migration record to the client; The third blockchain system receives a second transaction from the client. A second stacked contract including a second method function is deployed in the third blockchain system. The management information of the i-th second blockchain system is included in the contract state of the second stacked contract. The second transaction is used to call the second method function, and the identification information of the i-th second blockchain system is included in the second transaction; The third blockchain system executes the second function according to the second transaction, and realizes: determining at least one position index from the management information of the i-th second blockchain system according to the identification information of the i-th second blockchain system, and determining at least one transaction sequence stored in the third blockchain system according to the at least one position index. The transaction sequence belongs to the transaction group batch submitted during the period when the i-th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system, and returning the at least one transaction sequence to the client.

2. The method according to claim 1, wherein registration information of the N second blockchain systems is stored in the contract state of the first stacked contract, and the registration information of the i-th second blockchain system includes a genesis block; Among them, The first blockchain system executes the first method function according to the first transaction, and further realizes: returning the genesis block of the i-th second blockchain system to the client.

3. The method according to claim 1, wherein the sovereignty migration record further includes the first batch number corresponding to the first transaction batch submitted for the first time during the period when the i-th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system; the first transaction further includes the starting batch numbers corresponding to a plurality of transaction batches to be restored; the first batch numbers included in each of the at least one sovereignty migration record are not less than the starting batch numbers.

4. The method according to claim 1, wherein the position index includes the batch number of the transaction batch to which the corresponding transaction sequence belongs; the second transaction further includes the starting batch numbers corresponding to a plurality of transaction batches to be restored; and the batch numbers included in each of the at least one position index are not less than the starting batch numbers.

5. According to the method described in claim 1, the first roll-up contract further includes a third method function, and the third blockchain system belongs to the remaining N-1 second blockchain systems; wherein, The method further includes: The first blockchain system receives a third transaction from the third blockchain system, the third transaction being used to invoke the third method function, which includes the transaction sequences included in the first transaction batch submitted by the third blockchain system, the batch number of the first transaction batch, and the previous state root and the subsequent state root corresponding to the first transaction batch; The first blockchain system executes the third method function according to the third transaction, to achieve: storing the transaction sequences included in the first transaction batch, adding a position index in the global management information of the third blockchain system according to the batch number of the first transaction batch, the position index being used to indicate the storage location of the transaction sequences included in the first transaction batch in the first blockchain system, and updating the fourth state data of the third blockchain system according to the previous state root and the subsequent state root corresponding to the first transaction batch.

6. The method according to claim 1, wherein the second volume contract further includes a fourth method function, and the third blockchain system belongs to the remaining N-1 second blockchain systems; wherein, The method further includes: The third blockchain system receives a fourth transaction from the i-th second blockchain system, the fourth transaction being used to invoke the fourth method function, which includes the transaction sequences included in the second transaction batch submitted by the i-th second blockchain system, the batch number of the second transaction batch, and the previous state root and the subsequent state root of the second transaction batch; The third blockchain system executes the fourth method function according to the fourth transaction, to achieve: storing the transaction sequences included in the second transaction batch, adding a position index in the management information of the i-th second blockchain system according to the batch number of the second transaction batch, the position index being used to indicate the storage location of the transaction sequences included in the second transaction batch in the third blockchain system, and updating the second state data of the i-th second blockchain system according to the previous state root and the subsequent state root corresponding to the second transaction batch.

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

8. The method according to any one of claims 1-7, wherein the registration information of the N second blockchain systems is stored in the contract state of the first roll-up contract, and the first roll-up contract further includes a fifth method function; Among them, The method further includes: The first blockchain system receives a fifth transaction for invoking the fifth method function, and the fifth transaction requests to use the third blockchain system as the upper-layer blockchain system corresponding to the \(i\)th second blockchain system; The first blockchain system executes the fifth method function according to the fifth transaction, and realizes: in the global management information of the \(i\)th second blockchain system, a sovereignty migration record is newly added and a sovereignty migration event is generated, where the sovereignty migration record includes the identification information of the third blockchain system, and the sovereignty migration event includes the identification information of the \(i\)th second blockchain system and the third blockchain system; The third blockchain system, according to the sovereignty migration event, uses the registration information of the \(i\)th second blockchain system to set a second roll-up contract corresponding to the \(i\)th second blockchain system in the third blockchain system.

9. The method according to claim 8, wherein the fifth transaction and the sovereignty migration record include the first batch number corresponding to the first transaction batch submitted for the first time during the period when the \(i\)th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system.

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

11. A management method for a blockchain system, which is executed by a first blockchain system deployed with a first roll-up contract. The contract state of the first roll-up contract stores the global management information of \(N\) second blockchain systems, and the first roll-up contract includes a first method function. The method includes: Receiving a first transaction for invoking the first method function from a client, where the first transaction includes the identification information of the \(i\)th second blockchain system; ​ Execute the first method function according to the first transaction, and achieve: determine at least one sovereignty migration record from the global management information of the i-th second blockchain system according to the identification information of the i-th second blockchain system, where the identification information of the third blockchain system is included, and return the at least one sovereignty migration record to the client, so that the client obtains at least one transaction sequence from the third blockchain system according to the at least one sovereignty migration record, and the transaction sequence belongs to the transaction batch submitted during the period when the i-th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system.

12. The method according to claim 11, wherein the registration information of N second blockchain systems is stored in the contract state of the first roll-up contract, and the registration information of the target blockchain system includes a genesis block; wherein executing the first method function according to the first transaction further achieves: returning the genesis block of the i-th second blockchain system to the client.

13. The method according to claim 11, wherein the sovereignty migration record further includes the first batch number corresponding to the first transaction batch submitted for the first time during the period when the i-th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system; the first transaction further includes the starting batch numbers corresponding to a number of transaction batches to be restored; and the first batch number in the at least one sovereignty migration record is not less than the starting batch number.

14. According to the method described in claim 11, the first roll-up contract further includes a third method function, and the third blockchain system belongs to the remaining N-1 second blockchain systems; wherein, The method further includes: Receiving a third transaction from the third blockchain system, the third transaction being used to call the third method function, which includes the transaction sequences included in the first transaction batch submitted by the third blockchain system, the batch number of the first transaction batch, and the previous state root and the subsequent state root corresponding to the first transaction batch; Executing the third method function according to the third transaction, and achieving: storing the transaction sequences included in the first transaction batch, adding a position index in the global management information of the third blockchain system according to the batch number of the first transaction batch, the position index being used to indicate the storage position of the transaction sequences included in the first transaction batch in the first blockchain system, and updating the fourth state data of the third blockchain system according to the previous state root and the subsequent state root corresponding to the first transaction batch.

15. The method according to any one of claims 11-14, wherein the registration information of the N second blockchain systems is stored in the contract state of the first roll-up contract, and the first roll-up contract further includes a fifth method function; Among them, The method further includes: Receiving a fifth transaction for calling the fifth method function, the fifth transaction requesting to use the third blockchain system as the upper-layer blockchain system corresponding to the i-th second blockchain system; Execute the fifth method function according to the fifth transaction, and achieve: in the global management information of the i-th second blockchain system, add a sovereignty migration record and generate a sovereignty migration event, where the sovereignty migration record includes the identification information of the third blockchain system, so the sovereignty migration event includes the identification information of the i-th second blockchain system and the third blockchain system, and enable the third blockchain system to use the registration information of the i-th second blockchain system to set a second roll-up contract corresponding to the i-th second blockchain system in the third blockchain system.

16. A blockchain node in a first blockchain system, where a first roll-up contract is deployed in the first blockchain system, the first roll-up contract includes a first method function, and the contract state of the first roll-up contract stores the global management information of N second blockchain systems. The blockchain node includes: A transaction receiving unit configured to receive a first transaction for invoking the first method function from a client, where the first transaction includes the identification information of the i-th second blockchain system; A transaction execution unit configured to execute the first method function according to the first transaction, and achieve: determine at least one sovereignty migration record from the global management information of the i-th second blockchain system according to the identification information of the i-th second blockchain system, where the sovereignty migration record includes the identification information of the third blockchain system, and return the at least one sovereignty migration record to the client, so that the client can obtain at least one transaction sequence from the third blockchain system according to the at least one sovereignty migration record, and the transaction sequence belongs to the transaction batch submitted during the period when the i-th second blockchain system uses the third blockchain system as its corresponding upper-layer blockchain system.

Images