Method for rolling back state data in block chain system

Abstract

A method for rollback state data in a block chain system is characterized in that the block chain system uses a plurality of logic pages to store a state Merck tree, and each logic page comprises a current memory page used for representing current version contents of all tree nodes and a basic page used for representing a plurality of historical version contents of all tree nodes, the incremental pages are used for representing content changes of all historical versions between the adjacent basic pages; the method comprises the following steps: reading a first basic page, corresponding to a rollback target version, of each logic page; and carrying out first rollback on any first logic page, wherein the first rollback comprises the following steps: recovering a first memory page corresponding to the target version based on the first basic page, updating the current memory page into the first memory page, and deleting the basic page and the increment page after the first basic page.

Description

Technical Field

[0001] The embodiments of this specification belong to the technical field of blockchain, and particularly relate to a method for rolling back state data in a blockchain system. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chained data structure in a sequential connection manner according to the time sequence, and a distributed ledger that is tamper-proof and forgery-proof is guaranteed by cryptographic means. Due to the characteristics of blockchain such as decentralization, information immutability, and autonomy, blockchain has received more and more attention and applications.

[0003] In the scenarios of applying blockchain systems, when encountering state data forks or failovers, it is often necessary to roll back the state data. In the traditional blockchain system architecture, the current version state tree and the historical version state tree are usually stored in different databases. Therefore, when rolling back state data, a series of complex data operations need to be performed, including but not limited to, reading the historical version database, comparing state trees of different versions, and persisting the data of the rolled-back state tree, and so on. This series of operations will not only cause frequent disk reads and writes, increasing the number of I / O operations, but also trigger serious read amplification and write amplification problems, thus affecting the performance of the rollback operation. Moreover, during this rollback process, the historical version state data is not deleted, and these invalid historical data are still retained in the storage medium, which not only occupies storage space but also increases the complexity of data management, forming a certain amount of space amplification. In addition, since the rollback process involves cross-database full-scale data comparison, state tree reconstruction, and persistence, in order to ensure data consistency and integrity, the entire rollback process often needs to be carried out in an offline state of the blockchain system, resulting in long-term service interruption and seriously affecting the continuity of foreground services.

[0004] Therefore, a technical solution is needed that can realize the rollback of state data while keeping the blockchain system online, and at the same time reduce the read amplification, write amplification, and space amplification during the rollback process, so as to improve the performance of the blockchain system in the state data rollback scenario and ensure the continuity of foreground services. Summary of the Invention

[0005] The purpose of the present invention is to provide a method for rolling back state data in a blockchain system, which is beneficial to improving the performance of rolling back state data in the blockchain system and realizing the online rollback of state data.

[0006] In a first aspect, a method for rolling back state data in a blockchain system is provided. The blockchain system uses multiple logical pages to store a state Merkle tree. The logical pages include a current memory page for representing the current version content of all its tree nodes, a base page for representing the content of several historical versions of all its tree nodes, and a delta page for representing the changes in the content of each historical version between adjacent base pages. The method includes:

[0007] Read the first base page corresponding to the rollback target version of each logical page;

[0008] Perform a first rollback on any first logical page. The first rollback includes: restoring the first memory page corresponding to the target version based on the first base page, updating the current memory page to the first memory page, and deleting the base pages and delta pages after the first base page.

[0009] In a second aspect, a computing device is provided, including a memory and a processor. A computer program is stored in the memory. When the processor executes the computer program, the method described in the first aspect is implemented.

[0010] According to the method provided in the embodiments of this specification, the state tree in the blockchain system is segmented into logical pages, and the current memory page for recording current data, the base page for recording historical change data, and the delta page are managed through the logical pages. On this basis, when rolling back state data, the base page corresponding to the rollback target version can be directly located, and based on this base page, the memory page can be restored without accessing the historical version state database, thereby realizing online data rollback, reducing the amount of data read and written required for the rollback operation, and improving the performance of the state data rollback in the blockchain system. At the same time, the base pages and delta pages corresponding to after the target version can be deleted to clear invalid state data and avoid the problem of space amplification. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0012] Figure 1 Shows a blockchain architecture diagram in an embodiment;

[0013] Figure 2 Shows a schematic diagram of the block storage structure in an embodiment;

[0014] Figure 3 Shows a schematic diagram of the block storage structure in an embodiment;

[0015] Figure 4 A schematic diagram showing an exemplary logical page for generating a base page and an incremental page including multiple tree nodes is shown;

[0016] Figure 5 It is a flowchart of a method for rolling back state data in a blockchain system provided according to an embodiment of the present specification. Detailed implementation manners

[0017] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0018] Figure 1 A blockchain architecture diagram in an embodiment is shown. In Figure 1 In the shown blockchain architecture diagram, the blockchain includes N nodes, Figure 1 Nodes 1 to 8 are schematically shown. The connections between the nodes schematically represent P2P (Peer to Peer) connections, and the connections can be, for example, TCP connections, etc., for transmitting data between the nodes. The full ledger can be stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.

[0019] Transactions in the blockchain field can refer to task units executed and recorded in the blockchain. A transaction usually includes at least a sending field (From), a receiving field (To), and a data field (Data). For example, in the case where the transaction is a transfer transaction, the From field represents the account address that sends the transaction (that is, initiates a transfer task to another account), the To field represents the account address that receives the transaction (that is, receives the transfer), and the transfer amount can be included in the Data field.

[0020] The blockchain can also provide the function of smart contracts. Smart contracts on the blockchain are a piece of code that can be triggered and executed by transactions on the blockchain system, and smart contracts are defined in the form of code. Invoking a smart contract in the blockchain is actually initiating a transaction pointing to the smart contract address, so that each node in the blockchain runs the smart contract code distributively.

[0021] In various blockchain networks that introduce smart contracts, such as Ethereum, accounts generally can include two types:

[0022] Contract Account: Stores the executed smart contract code and the values of the state in the smart contract code, and usually can only be activated by being called by an externally owned account.

[0023] Externally Owned Account: The account of a user, such as the account of an asset token owner.

[0024] The design of externally owned accounts and contract accounts is actually a mapping from the account address to the account state. The state of an account usually includes fields such as nonce, balance, storageRoot, codeHash, etc. Nonce and balance exist in both externally owned accounts and contract accounts; the codeHash and storageRoot attributes are generally only valid for contract accounts.

[0025] nonce: A counter. For an externally owned account, this number can represent the number of transactions sent from the account address; for a contract account, it can be the number of contracts created by the account.

[0026] balance: The number of asset tokens owned by the account address.

[0027] storageRoot: The hash of the root node of an MPT (Merkle Patricia Trie), and this MPT tree organizes the storage of the state variables of the contract account.

[0028] codeHash: The hash value of the smart contract code. For a contract account, it is the hash value of the smart contract; for an externally owned account, since it does not include a smart contract, the codeHash field can generally be an empty string / a string of all 0s.

[0029] The full name of MPT is Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (a compressed prefix tree, a more space-saving Trie tree, dictionary tree). The Merkle Tree algorithm calculates a Hash value for each transaction, and then connects them in pairs and calculates the Hash again until the top-level Merkle root. In Ethereum, an improved MPT tree is adopted, such as a 16-ary tree structure, which is usually simply referred to as the MPT tree.

[0030] The data structure of the Ethereum MPT tree includes the State Trie. The State Trie contains key-value pairs (also written as key-value, abbreviated as k-v or kv) of the storage content corresponding to each account in the Ethereum network. The "key" in the State Trie can be a 160-bit identifier (such as the address of an Ethereum account or a part of the hash value of the address, hereinafter collectively referred to as the account address), and this account address is distributed in the storage from the root node to the leaf node of the State Trie. The "value" in the State Trie is generated by encoding the information of the Ethereum account (using the Recursive-Length Prefix encoding (RLP) method). As mentioned above, for an external account, the value includes nonce and balance; for a contract account, the value includes nonce, balance, codeHash, and storageRoot.

[0031] Contract accounts are used to store the states related to smart contracts. After a smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and new values are generated when the smart contract is created and executed. The so-called smart contract usually refers to a contract that can automatically execute terms defined in code form in a blockchain environment. Once an event triggers the terms in the contract (meeting the execution conditions), the code can be automatically executed. In the blockchain, the relevant states of the contract are saved in the Storage Trie, and the Hash value of the root node of the Storage Trie is stored in the above-mentioned storageRoot, so as to lock all the states of the contract under this contract account through Hash. The Storage Trie is also an MPT tree structure, storing the key-value mapping from the state address to the state value. The partial information from the root node to the leaf node of the Storage Trie tree is arranged in order to store the address of a state, and the value of the state is stored in this leaf node.

[0032] As Figure 2In some of the blockchain data storages shown, the block header of each block includes several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), nonce (in some blockchain systems, this nonce is not a random number, or in some blockchain systems, the nonce in the block header is not enabled), timestamp, block number Block Num, state root hash State_Root, transaction root hash Transaction_Root, receipt root hash Receipt_Root, etc. Among them, the Prev Hash in the block header of the next block (such as block N+1) points to the previous block (such as block N), which is the Hash value of the previous block. In this way, the next block is locked to the previous block through the block header on the blockchain. Among them, State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set respectively. The state set, transaction set, and receipt set organize states, transactions, and receipts in the form of trees respectively. Generally, they can be the same tree structure or different tree structures. For example, in Ethereum, the same MPT structure is adopted. In the tree structure of the state set including smart contracts in some blockchains such as Ethereum, it includes a two-level MPT structure: the leaf nodes of the upper-level MPT structure include two types: external accounts and contract accounts; each of the contract accounts includes the lower-level MPT structure, and the leaf nodes of the lower level include the values of the states in the contract account.

[0033] Figure 3 is a schematic structural diagram of a blockchain data storage. Still taking Ethereum as an example, it can be combined with Figure 2As shown, state_root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, what points to state_root is a state tree State Trie in the form of an MPT. The root node of this MPT tree is generally an Extension Node or a Branch Node, and what is stored in state_root is generally the Hash value of this root node. The root node can be connected to one or more layers of Extension Node / Branch Node below, and these multi-layer tree nodes can be collectively referred to as Internal Node. Part of the values in each node from the root node of this MPT to the leaf node can be concatenated in order to form an account address and serve as the key, and the account information stored in the leaf node is the value corresponding to this account address. In this way, a key-value pair is formed. This key can also be a part after sha3(Address), that is, a part of the hash value of the account address (the hash algorithm uses the sha3 algorithm for example), and the value it stores can be RLP(Account), that is, the RLP encoding of the account information. Among them, the account information is

[0034] a quadruple composed of [nonce, balance, storageRoot, codeHash]. As mentioned above, for an external account, generally only the nonce and balance are available, while the storageRoot and codeHash fields default to storing an empty string / all 0 strings. That is to say, an external account does not store contracts or the state variables generated after contract execution. A contract account generally includes Nonce, Balance, Storage root, CodeHash. Among them, Nonce is the transaction counter of this contract account; Balance is the account balance; Storage root corresponds to another MPT, and the information related to the contract state can be linked through Storage root; CodeHash is the hash value of the contract code. Whether it is an external account or a contract account, its account information is generally located in a separate Leaf Node. From the Extension Node / BranchNode of the root node to the Leaf Node of each account, there may be several branch nodes and extension nodes in between.

[0035] The State Trie can be a tree in the form of an MPT, generally a 16-way tree, that is, each level can have up to 16 child nodes at most. For an Extension Node, which is used to store a common prefix, it generally has 1 child node, and this child node can be a Branch Node. For a Branch Node, it can have up to 16 child nodes, which may include Extension Nodes and / or Leaf Nodes.

[0036] As mentioned above, the essence of a blockchain is a chained structure composed of a series of data blocks (blocks) associated by hashes. All states in the current version, also known as the current state, many of which are likely to have been updated in a previous block and continue unchanged until the current block. The current version database (currentDB) is used to store the data of the latest "current state", such as the latest account state, contract code, and contract storage, etc. Moreover, as the blocks grow, the data in currentDB can be continuously modified. For the multiple blocks chained in the blockchain, it is redundant to build an MPT tree of all states globally for each block. Referencing the same leaf nodes and intermediate nodes that were last updated to this value in the previous block is an efficient data storage method. Moreover, the states changed in each block are likely to be part of the global state, also known as the history state, which is stored in the historical version database (historyDB). historyDB is used to store the data of the historical state, so as to provide a complete historical view of the entire chain.

[0037] In some implementations of current blockchain technology, there is a practice of storing the current state and the history state in currentDB and historyDB respectively, and these two databases are usually independent entities. In some implementation solutions, both of these databases will be independently persisted. However, this dual-database architecture has obvious defects: First, it leads to redundant storage of state data, thus increasing the storage overhead. For example, if currentDB occupies 10GB of disk space and historyDB occupies 100GB, then the total storage requirement reaches 110GB. Second, this architecture increases the complexity of the system. The usual operation process is to first update currentDB, then generate a binary log (Binlog), then synchronize the Binlog to historyDB, and finally historyDB executes the Binlog to generate the corresponding version of the state record. This mechanism for keeping the two databases synchronized not only increases the complexity of the system but also may introduce potential risks of data consistency.

[0038] On the other hand, some blockchain implementations adopt a scheme that only retains the currentDB without maintaining the historyDB. Although this method significantly reduces the storage requirements (e.g., only occupying 10GB of disk space), it also brings new problems. When it is necessary to restore to the state of a certain historical version, if the read-write set is saved, the system needs to start from the genesis block and replay the read-write set in version order until the required historical version state is reached; if the read-write set is not saved, all transactions need to be replayed starting from the genesis block until the target state is reached. This method is extremely inefficient, time-consuming, and computationally intensive when performing historical state restoration. Especially when dealing with long-running blockchain systems, this problem will become more prominent.

[0039] As mentioned above, in the multi-node architecture of the blockchain system, the Merkle state data provides the verifiability of the global state through a trie (such as MPT). However, when the blockchain system encounters network forks, node failures, or consensus anomalies, each node may need to roll back the state data due to inconsistent local state data, that is, through the version backtracking mechanism, all nodes synchronize the world state to a certain historical version that once reached consensus to reconstruct the consistency of the global state data. In related technologies represented by Ethereum, each block anchors the world state of a specific version through the state root hash. The rollback operation essentially redirects the state root hash of the latest / current block to the target version of the rollback.

[0040] Under this architecture, the current version state tree and the historical version state tree are located in different databases. Each time the state data is updated, not only the current state containing the full state data is generated and saved in the currentDB, but also the expired old version historical state needs to be migrated from the currentDB to the historyDB for storage. When performing a rollback of the state data, the blockchain system needs to perform multiple read-write operations, including but not limited to: loading the target historical state data corresponding to the rollback target version from the historyDB, recursively traversing and comparing the tree node differences between the current state and the target historical state data, reconstructing the MPT branches layer by layer, and finally persistently storing the corrected full state tree in the currentDB.

[0041] The above rollback operation process involves frequent I / O interactions across databases. For example, recursively traversing the state tree requires reading state tree node data one by one from the persistent storage medium, and the state tree reconstruction frequently triggers the compaction operation of the database, resulting in serious read amplification and write amplification. Especially when the blockchain system has been running for a long time and the state tree already contains a huge number of nodes, the loading of historical state data requires triggering a large number of data file reads from the storage medium, exacerbating the read amplification problem; at the same time, full-volume data persistence of the corrected state tree will also cause serious write amplification problems. In addition, after the rollback ends, the old version state data still occupies the space of the storage medium in the form of a full-volume snapshot, forming long-term resource / dirty data redundancy, further exacerbating the growth of storage costs and performance loss.

[0042] To solve the above technical problems, the inventor designed a method for rolling back state data in a blockchain system, which can divide the state tree in the blockchain system into logical pages, and manage and record the current memory page of the current data, the base page and the incremental page for recording historical change data through the logical page management; on this basis, when rolling back the state data, the base page corresponding to the rollback target version can be directly located, and based on this base page, the memory page can be restored without accessing the historical version state database, so as to achieve online data rollback, reduce the amount of read and write data required for the rollback operation, and improve the performance of the state data rollback in the blockchain system. At the same time, the base page and incremental page corresponding to after the target version can be deleted to achieve the clearing of invalid state data and avoid the problem of space amplification.

[0043] Next, in combination with the drawings and embodiments, a method for managing the state tree based on an index file and logical pages in a blockchain system will be introduced first, and then on this basis, a detailed description of the method for rolling back state data will be further given.

[0044] Based on the state tree structure described above, a data storage architecture that separates data and indexes can be implemented in the blockchain system, which helps improve the flexibility of the blockchain system. The basic concepts involved here include data files and index files. Among them, the values of state variables (including account addresses or state variables in smart contracts) are stored in the data files; index entries pointing to the data files (including the location information of the values of state variables) are stored in the index files. The implementation principle is as follows: write the data content (the value of the state variable or the key-value pair of the state variable) into a certain data file, and record the location information of the data content in the data file (such as file identifier, address offset, data length, etc.); furthermore, create an index entry in the index file, and the index entry contains the retrieval key related to the data content and the aforementioned location information. In this way, when querying the data content, after obtaining the retrieval key of the data content, the index entry containing the retrieval key can be found in the index file, the location information of the data content can be obtained from the index entry, and then the actual data content can be read from the corresponding data file according to the location information.

[0045] Based on the aforementioned state tree structure, the entire tree structure, i.e., the Merkle trie, can also be divided into multiple logical pages. Specifically, according to the node association relationship of the tree structure, several adjacent upper and lower tree nodes can be aggregated into a logical page. For example, 256 child nodes at the second level of the trie with 16 branches can be aggregated into one logical page. Among them, there are multiple logical pages from the root node to the leaf node of the tree structure, and there are parent-child and sibling relationships between the logical pages, thus forming a complete Merkle tree. In this way, the state tree can be divided into multiple logical pages. Each logical page contains at least one tree node, and the tree nodes contained in different logical pages are different. Moreover, the tree node content corresponding to the current latest version of the state data can be maintained in the logical page.

[0046] Figure 4An exemplary schematic diagram of generating a base page and a delta page for a logical page including multiple tree nodes is provided. Inside each Logical Page, a memory page (Memory Page) can be maintained to represent the content of all the tree nodes corresponding to the current latest version of the logical page. Further, the content of the tree nodes maintained in the logical page can be updated according to consecutive versions, and a base page (Base Page) and a delta page (Delta Page) can be generated according to the generation / modification behavior. Specifically, the Base Page and the Delta Page are generated according to the generation / modification behavior. For example, for consecutive state changes, such as including state variables a = 5, b = 8, c = 3 in the Nth version, the a = 5, b = 8, c = 3 can be used as the content in the base page Base Page. For a = 6 in the N + 1th version and a = 8 in the N + 2th version, and assuming that b and c remain unchanged, then the a = 6 in the N + 1th version and the a = 8 in the N + 2th version can be used as the Delta Page, such as DeltaPage1, on the basis of this Base Page, and the cases where b and c remain unchanged are not included in DeltaPage1. For a = 11 in the N + 3th version and a = 15 in the N + 4th version, then the a = 11 in the N + 3th version and the a = 15 in the N + 4th version can be used as the Delta Page, such as DeltaPage2, on the basis of this Base Page. Similarly, assuming that b and c remain unchanged, b and c are not included in DeltaPage2, and so on. It should be particularly noted that the Base Page and the Delta Page can be used as the smallest units of the in-memory structure of the tree structure. In addition, the Base Page can be used as the smallest unit of disk persistence for the tree structure. On this basis, the Delta Page can also be used as the smallest unit of disk persistence for the tree structure.

[0047] It should be noted that the Base Page here is a checkpoint of the entire Logical Page content, which can contain the full content of the Logical Page at that time, such as all the included tree node information. A checkpoint is generally a snapshot of a specific state saved in a computer system so that the system can resume execution from this saved state in case of system failure or crash. In many cases, checkpoints are used for long-running computing tasks, safety-critical systems, distributed systems, and database systems, etc.

[0048] For the Base Page, the status modification for every predetermined number of times (such as m times) can generate a Base Page once. In the aforementioned example, in version N, the status variable a = 5, and this a = 5 can be used as the content in the base page BasePage1. For version N+1 where a = 6, and in version N+2 where a = 8, the a = 6 in version N+1 and the a = 8 in version N+2 are used as DeltaPage1 based on this Base Page. For version N+3 where a = 11, and in version N+4 where a = 15, then the a = 11 in version N+3 and the a = 15 in version N+4 can be used as DeltaPage2 based on this Base Page. For version N+5 where a = 20, assuming the modification reaches the predetermined number of times 5, then the value a = 20, as well as b = 8 and c = 3 in version N+5, can be used as the content in the base page BasePage2.

[0049] Similarly, the Delta Page describes several version modifications of the Logical Page, aggregating multiple modifications into a set. For example, a Delta Page is generated every M times of modification, and a new Delta Page is created to collect subsequent version modification operations. In the aforementioned example, for version N+1 where a = 6, and in version N+2 where a = 8, the a = 6 in version N+1 and the a = 8 in version N+2 are used as DeltaPage1 based on this Base Page. For version N+3 where a = 11, and in version N+4 where a = 15, then the a = 11 in version N+3 and the a = 15 in version N+4 can be used as DeltaPage2 based on this Base Page. It can be seen that for each Delta Page, it is set to create an incremental page for every 2 times of version modification operations.

[0050] For each modification of the Base Page and the Delta Page, corresponding dirty data is generated in memory. When the memory occupied by the Base Page and the Delta Page reaches a predetermined amount, the Base Page and the Delta Page can be batch disk-persisted, thus avoiding persisting all dirty data for each modification and continuously occupying memory and CPU resources. The in-memory generation and disk persistence of the BasePage and the Delta Page can be carried out in the background.

[0051] The above is an elaboration of a method for managing a state tree based on an index file and logical pages in an exemplary blockchain system. Based on this architecture, it is possible to avoid switching between different databases and directly roll back the state tree based on logical pages, thereby completing the rollback of state data while keeping the blockchain system online.

[0052] Next, a method for rolling back state data in a blockchain system will be elaborated in detail in combination with the accompanying drawings and embodiments.

[0053] Based on the above blockchain technology architecture, in Figure 5 shows a method flow for rolling back state data in a blockchain system provided according to an embodiment of this specification. It can be understood that this method can be implemented by any device, equipment, platform, or device cluster with computing and processing capabilities. Refer to Figure 5 The method at least includes the following steps: S501: Read the first base pages corresponding to the rollback target version of each logical page. S503: Perform a first rollback on any first logical page. The first rollback includes: restoring the first memory page corresponding to the target version based on the first base page, updating the current memory page to the first memory page, and deleting the base pages and incremental pages after the first base page.

[0054] Specifically, in step S501, read the first base pages corresponding to the rollback target version of each logical page.

[0055] As described above, in a blockchain system, multiple logical pages are used to divide and store the state tree. For each logical page, there are corresponding memory pages, base pages, and incremental pages. Based on each version data change of the memory page in the logical page, a base page or an incremental page will be correspondingly generated. Therefore, in the base page or incremental page, there will be data corresponding to the rollback target version. That is to say, according to the target version, a base page or an incremental page can be determined in the logical page, which contains the data changes of the target version.

[0056] In a specific scenario, a base page (the first base page) can be found according to the target version, and the state data it contains is the target version data. For example, for a certain logical page, the target version to be rolled back is 100, and in this logical page, there is a base page whose stored state data version is 100, which is the same as the target version. Then this base page is the first base page.

[0057] In another specific scenario, according to the target version, the first base page and the first incremental page corresponding to the rollback target version can be found. The first incremental page includes the content changes of the target version. The first base page is the base page before the first incremental page. That is to say, the target version exists in a certain incremental page (the first incremental page) between two adjacent base pages. For example, for a certain logical page, the target version to be rolled back is 110. In this logical page, there is a base page whose stored status data version is 100, which is less than the target version. In the next base page after this base page, the stored status data version is 120, which is greater than the target version. Therefore, it can be known that the data changes corresponding to the target version exist in one or more incremental pages between these two base pages. Find the incremental page containing the target version 100 as the first incremental page, and the base page before the first incremental page (the base page storing the status data of version 100) is the first base page. It should be noted that there may be multiple incremental pages between two adjacent base pages (depending on the generation logic of the incremental page, that is, the number of data change versions included in a single incremental page), and the incremental page containing the target version may not be the next incremental page immediately adjacent to the first base page. Therefore, in this step, all incremental data changes between the first base page version and the target version need to be included in the reading range. That is to say, the first incremental page may contain one incremental page (the first incremental page is the next incremental page immediately adjacent to the first base page), or may contain multiple incremental pages (there are other incremental pages between the first incremental page and the first base page), including the incremental page containing the data changes of the target version and each incremental page between this incremental page and the first base page.

[0058] Through the above steps, the base page and incremental page corresponding to the target version can be found, and the status data corresponding to the target version can be read. Next, in step S503, a first rollback is performed for any first logical page. The first rollback includes: restoring the first memory page corresponding to the target version based on the first base page, updating the current memory page to the first memory page, and deleting the base pages and incremental pages after the first base page.

[0059] In this step, corresponding to the two different scenarios listed in step S501, different operations need to be performed on the restoration of the memory page, and the deletion of the base page and incremental page.

[0060] Corresponding to step S501, in the scenario where the version of the first base page is equal to the target version, since the base page already contains the full content of the logical page at the version corresponding to this base page (that is, the content of the first memory page), the first rollback can directly use the first base page to restore the current memory page of the first logical page, and roll back the first logical page to the status data of the target version.

[0061] After the current memory page of the first logical page is successfully restored, the base pages and delta pages after the first base page become invalid data / dirty data, and these base pages and delta pages can be deleted.

[0062] Corresponding to step S501, in the scenario where the delta page contains the target version, since the first delta page contains the state data of one or more consecutive version memory pages that have changed relative to the previous first base page, rather than the full amount of state data, when restoring the current memory page of the first logical page, it is necessary to restore the full amount of content corresponding to the target version (i.e., the content of the first memory page) based on the first base page and the first delta page, update the current memory page of the first logical page to the first memory page, and complete the rollback of the target version state data.

[0063] Based on the generation logic of the delta page, multiple data change versions may be aggregated in a single delta page. Therefore, when the target version of the rollback is included in the delta page, it may be necessary to trim the delta page containing the target version based on the target version. Specifically:

[0064] According to one implementation, the maximum version of the first delta page is the target version, and the first memory page corresponding to the target version can be restored based on the first base page and the first delta page. For example, for a certain logical page, the target version to be rolled back is 110, the state data version stored in the first base page is 100, and the maximum version of the first delta page is 110. Therefore, all delta data changes from version 100 to version 110 included in the first delta page can be merged with the first base page to obtain the full amount of state data content corresponding to the target version, that is, the content of the first memory page.

[0065] According to the above implementation, after the current memory page of the first logical page is successfully restored, the base pages and delta pages after the first delta page become invalid data / dirty data, and these base pages and delta pages can be deleted.

[0066] According to another implementation, if the maximum version of the first incremental page is greater than the target version, the first incremental page can be trimmed to obtain a first trimmed incremental page containing the target version and previous versions, and a second trimmed incremental page containing versions after the target version. For example, for a certain logical page, the target version to be rolled back is 110, the version of the status data stored in the first base page is 100, and the maximum version of the first incremental page is 120, which is greater than the target version. Therefore, the first incremental page can be trimmed and split into two parts. The first part contains the data changes from version 100 to 110, that is, the first trimmed incremental page, and the second part is the remaining data changes from version 110 to version 120, that is, the second trimmed incremental page.

[0067] Based on the first base page and the first trimmed incremental page, the first memory page corresponding to the target version is restored. That is to say, the incremental data changes contained in the first trimmed incremental page are merged with the first base page to obtain the full content of the status data corresponding to the target version, that is, the content of the first memory page.

[0068] According to the above implementation, after successfully restoring the current memory page of the first logical page, the second trimmed incremental page, as well as the base pages and incremental pages after the first incremental page, become invalid data / dirty data, and these base pages and incremental pages can be deleted.

[0069] Based on the descriptions of the above various implementations, in the first rollback operation, the base pages and incremental pages that have become dirty data are deleted, thus avoiding the problem of space amplification caused by data rollback. In some specific applications, the dirty data in the memory pages can also be cleared to further reduce space amplification. Specifically, after rolling back the status data of the target version of the first logical page, all data changes associated with memory pages with version numbers higher than the target version (i.e., the version of the first memory page) have become invalid changes and can also be classified as dirty data and cleared; these memory pages also contain data change caches for which no corresponding base pages or incremental pages have been generated. That is to say, the historical memory pages corresponding to the first logical page with versions greater than the first memory page can be cleared.

[0070] The above is a specific introduction to the first rollback in multiple implementation manners. It is not difficult to understand that since the base page and incremental page included in the logical page are used to restore the state data, cross-database data reading, comparison, and persistence are avoided, and the online state data rollback of the blockchain system can be achieved. Although in the first rollback, the state data corresponding to the target version is directly restored by using the historical full amount of data and / or incremental data changes to reduce the IO overhead and speed up the efficiency of the state data rollback; however, for the data rollback performed in the online scenario, the impact of the rollback operation on the foreground service still needs to be considered. To avoid data crossover generation and even deadlocks between the data rollback and the foreground service, in some embodiments, during the execution of the first rollback, the foreground IO of the blockchain system can be blocked, so that during the execution of the first rollback, the front-end service of the blockchain system is temporarily unavailable, so as to completely isolate the data resource competition between the rollback operation and the front-end service operation and avoid the generation of data deadlocks or dirty data with version mismatches caused by concurrent reading and writing. After the first rollback is completed, the blockchain system can quickly release the foreground IO blocking lock, resume the service, and minimize the impact on the online services of the end users.

[0071] After the first rollback operation is successfully executed, since all the base pages and incremental pages after the target version are deleted as dirty data, there is no data container in the first logical page that can carry the data changes of the next version. Therefore, in one implementation manner, a new incremental page can be created during the execution of the first rollback to carry the state data changes after the target version. In other words, in the first rollback, a second incremental page can be generated, and the second incremental page is used to record the data changes of the version after the target version.

[0072] In the state data rollback of the blockchain system, the cleaning of dirty data needs to comprehensively consider both the memory and the persistent storage medium levels. In some embodiments, the blockchain system stores the location information of the state data in multiple data files through an index file; the first rollback may further include: determining the corresponding deletion index information in the index file according to the deleted base pages and incremental pages. Deleting the state data corresponding to the deletion index information in the multiple data files. Based on the multiple data files after deleting the state data, regenerating and persisting the index file.

[0073] As mentioned above, the index file stores the association relationship between the data and its physical address in the storage medium. For the invalid data after the target version of the rollback, the blockchain system can synchronously clear the base pages and incremental pages in the memory with version numbers higher than the target version, and at the same time, it can also physically erase the same type of invalid data that has been written to the persistent storage medium to completely release the storage resources.

[0074] During the cleaning process of the above-mentioned dirty data, it is necessary to consider the concurrent scenario of rollback operations and data persistence (flush). That is to say, if the dirty data in memory is asynchronously written to the storage medium during the execution of the rollback, the blockchain system needs to extract this part of the data and clear it.

[0075] The above-mentioned dirty data cleaning process may involve multiple data reads and writes and the triggering of compaction operations. To achieve efficient dirty data cleaning, a pre-set compaction filter can be used to retrieve the corresponding index information in the index file according to the deleted base pages and incremental pages as the deleted index information. The deleted index information indicates the physical storage addresses corresponding to the deleted base pages and incremental pages in multiple data files of the storage medium. Together with the invalid base pages and incremental pages that need to be cleared in memory, they are deleted in one go through the Revert Compaction operation. After the deletion is completed, a new index file is regenerated and persisted based on the data file.

[0076] The Revert Compaction operation is a compaction mechanism specially designed for the state data rollback scenario. It can jointly scan the MemTable, Immutable MemTable in memory and the data files in the persistent storage medium through customized filtering rules (compaction filter), delete all invalid data in one go through a single clear operation, rewrite all valid data through a single compaction operation, and finally regenerate a new index file based on the reorganized data file. This avoids the performance loss caused by multiple and cross-level storage file IOs and compaction operations in traditional related solutions.

[0077] In addition, in each of the above embodiments of the blockchain system state data rollback method, to ensure the accuracy of state data management and the idempotency of rollback operations, the information of the state data related to the rollback operation can be further updated in the metadata file. According to one implementation, the metadata information corresponding to the rollback data involved in the first rollback can be marked in the metadata file of the blockchain system so that the rollback data will not be restored to the memory page during a failure recovery.

[0078] Specifically, metadata is generally used to describe some attributes and characteristics of data content, so it is also called "data about data". Generally speaking, the metadata of a file is much smaller in size than its complete data content. Moreover, although the metadata and the data content together constitute a complete file, usually only the metadata can be loaded / modified without accessing the actual data content, thereby reducing memory usage, decreasing IO throughput, and greatly improving processing speed and efficiency, especially when the data file is huge. Metadata can be set on the base page or the incremental page, containing the summary information of the corresponding Page; it can also be set on the blockchain database, containing the summary information of all data files in the database.

[0079] In the above implementation, the blockchain system can add marks (which can be called logical deletion marks) to the data involved within the rollback operation range in the metadata file. In this way, it can be ensured that during the execution of the rollback operation, in case of unexpected downtime or failure recovery, the data to be rolled back will not be wrongly restored into the memory (the blockchain system can identify such data based on the logical deletion marks), further enhancing the accuracy of state data management and ensuring the idempotency of the rollback operation of the blockchain system state data.

[0080] The above is a detailed elaboration of a method for rolling back state data in the blockchain system provided by the embodiments of this specification. It should be noted that although the above embodiments mainly take state data as an example to elaborate on the method flow. However, the technical concept embodied therein can also be applied to the rollback process of other data with equivalent data structures in the blockchain system.

[0081] According to an embodiment of another aspect, this specification also provides a computing device, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the steps of the foregoing method in combination with Figure 5 the method.

[0082] In this specification, the "first" in terms such as the first logical page and the first incremental page, and the corresponding "second", "third" (if any) in the text are only for the convenience of distinction and description, and do not have any restrictive meaning.

[0083] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. 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 the user programming the device. Designers can program themselves to "integrate" a digital system onto a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL), and there is not just one type of HDL, but many types, 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. Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing a little logical programming on the method flow using the above-mentioned several hardware description languages and programming it into an integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0084] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller 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 also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

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

[0086] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, 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 among the execution orders of numerous steps and does not represent the only execution order. When the actual device or terminal product is executed, it may be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, product or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device including the said elements. For example, if terms such as first and second are used to denote names, they do not denote any specific order.

[0087] For convenience of description, when describing the above device, it is described by various modules according to their functions. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, 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 displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in electrical, mechanical or other forms.

[0088] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (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, and the combination of processes and / or blocks in the flowchart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0089] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 in one block or multiple blocks.

[0090] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation 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 process Figure 1 one process or multiple processes and / or blocks Figure 1 in one block or multiple blocks.

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

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

[0093] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can implement information storage by any method or technology. The 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 technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, 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 computer-readable media, such as modulated data signals and carrier waves.

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

[0095] One or more embodiments of this specification can 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, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0096] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for the relevant content. In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0097] The above description is only for the embodiments of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims.

Claims

1. A method for rolling back state data in a blockchain system, wherein the blockchain system uses multiple logical pages to save a state Merkle tree, wherein the logical page includes a current memory page for representing the current version content of all tree nodes, a base page for representing several historical version contents of all tree nodes, and an incremental page for representing changes in the content of each historical version between adjacent base pages; the method includes: Read the first base page of each logical page corresponding to the rollback target version; A first rollback is performed for any first logical page, the first rollback comprising: restoring a first memory page corresponding to the target version based on the first base page, updating the current memory page to the first memory page, and deleting base pages and incremental pages after the first base page.

2. The method according to claim 1, wherein: The method further comprises: Clean up historical memory pages corresponding to the first logical page and having a version greater than that of the first memory page.

3. The method according to claim 1, wherein: The method further comprises: During the execution of the first rollback, the foreground IO of the blockchain system is blocked.

4. The method according to claim 1, wherein: The step of reading the first base page of each logical page corresponding to the rollback target version includes: Reading a first base page and a first incremental page corresponding to the rollback target version of each logical page, wherein the first incremental page includes content changes of the target version, and the first base page is a base page before the first incremental page; The restoring the first memory page corresponding to the target version based on the first base page includes: Based on the first base page and the first incremental page, recovering a first memory page corresponding to the target version; The deleting the base page and the incremental page after the first base page includes: Delete the base page and delta pages after the first delta page.

5. The method according to claim 4, wherein: The step of restoring a first memory page corresponding to the target version based on the first base page and the first incremental page includes: If the maximum version of the first incremental page is greater than the target version, the first incremental page is pruned to obtain a first pruned incremental page including the target version and previous versions, and a second pruned incremental page including a version after the target version; based on the first base page and the first pruned incremental page, a first memory page corresponding to the target version is restored; And, deleting the base page and the incremental page after the first incremental page includes: The second cropped delta page, as well as the base page and delta pages following the first delta page, are deleted.

6. The method according to claim 1, wherein: The blockchain system stores the location information of the state data in multiple data files through index files; The first rollback further includes: Determine the corresponding deletion index information in the index file according to the deleted basic page and incremental page; Deleting the status data corresponding to the deletion index information in the plurality of data files; Regenerate and persist index files based on multiple data files after deleting state data.

7. The method according to claim 1, wherein: The method further comprises: In the metadata file of the blockchain system, metadata information corresponding to the rollback data involved in the first rollback is marked so that when a fault recovery occurs, the rollback data will not be restored to a memory page.

8. The method according to claim 1, wherein: The first rollback further includes: A second incremental page is generated, where the second incremental page is used to record data changes of versions after the target version.

9. The method according to claim 1, wherein: The first rollback further includes: A first cache of the first logical page is cleared, wherein the first cache contains content changes that have not been written to a base page or a delta page.

10. A computing device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method according to any one of claims 1 to 9 is implemented.

Images