A method and system for asynchronous storage of state data

Abstract

The application belongs to the technical field of blockchains, and provides a state data asynchronous storage method and system, wherein after new block consensus is passed, block data is completed persistent storage, and state data is written into a cache first, and the state data in the cache is asynchronously persisted; in the above process, when a state data read-write request is received, a data copy is constructed based on the latest version of the state data in the cache and the persistent storage, and then read-write is performed. The application can avoid state data loss after node abnormal downtime caused by a state data cache mechanism, reduce new block processing blocking caused by state data persistent storage, improve blockchain transaction throughput, and avoid inconsistent or incorrect blockchain state execution results.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a method and system for asynchronous storage of state data. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Blockchain technology is a distributed ledger technology composed of various technologies such as peer-to-peer communication, cryptographic algorithms, smart contracts, and consensus mechanisms. It possesses characteristics such as transparency, immutability, non-repudiation, and traceability. Data on a blockchain typically includes block data and state data. Block data adopts a chain-like data structure, including a block header and a block body. The block header contains information such as the prehash value of the previous block, the hash value of the current block body, the state root of the current block, and a timestamp. The block body contains the transaction records of the current block, and the block height of each block increases sequentially based on time. As a new block is generated, the state data read and written by transactions within the block will change. The changed state data will be persistently stored on disk or storage media along with the new blockchain.

[0004] In blockchain, to ensure data consistency and correctness, blockchain nodes will only start the next round of consensus or block execution after the data of the blocks that have passed consensus and the state data have been persistently stored. Otherwise, conflicts between the read and write data of the previous and next blocks may cause the state data used when reading and writing the state data of the next block to be outdated, resulting in inconsistent or incorrect execution results.

[0005] During the process of uploading block data to the blockchain, the writing of state data requires a significant amount of IO resources and time, which limits the transaction throughput of the blockchain. Summary of the Invention

[0006] To address the aforementioned problems, this invention proposes a method and system for asynchronous storage of state data. This invention can avoid the loss of state data after a node crash due to abnormal state data caching mechanism, reduce the blocking of new block processing caused by persistent storage of state data, improve the throughput of blockchain transactions, and avoid inconsistent or incorrect blockchain state execution results.

[0007] According to some embodiments, the present invention adopts the following technical solution:

[0008] A method for asynchronously storing state data includes the following steps:

[0009] After the consensus of the new block is passed, the block data is persisted and the state data is first written to the cache, and the state data in the cache is persisted asynchronously.

[0010] In the above process, when a request to read or write state data is received, a data copy is constructed based on the latest version of the state data in the cache and persistent storage before reading or writing.

[0011] As an alternative implementation, before writing the state data to the cache, all write data involving changes, additions, or deletions of the state data are combined into a state data set. Based on the identifier of the state data, a Bloom filter is constructed, and the state data set is written to the state cache queue in batches with the block height n of the block as the version. The Bloom filter corresponding to the state data set of that version is written to the Bloom filter cache.

[0012] As an alternative implementation method, the process of persistently storing block data involves determining that the current block consensus has passed according to the consensus rules, and after reaching the persistent on-chain state, persistently storing the block data and the current block height.

[0013] As an optional implementation, the process of asynchronously persisting the state data in the cache includes: asynchronously persisting the state data sets of each version in the state cache queue in order of version number from low to high; after each version of the state data set is persisted, deleting the cached state data set of that version from the state cache queue, deleting the Bloom filter of that version from the Bloom filter cache, updating the block height of the currently persisted state data in the persistent storage, and starting the persistent storage of the next version of the state data set, until there is no data to be persisted in the state cache queue.

[0014] As an alternative implementation, the state data of the block data is written to the state cache queue, and the construction, consensus or block execution of the next block can be started without waiting for the data in the state cache queue to be persisted.

[0015] As an alternative implementation, if the construction, consensus or execution process of a new block requires reading and writing state data, the Bloom filter of each version of the cached state data set is searched sequentially from high version to low version until the highest version of the state data set where the required data may be located is located and the data is obtained from it.

[0016] If the required data is not found in any of the cached versions of the state data, then the latest version of the required data is in persistent storage, and the required data is retrieved from the persistent state data.

[0017] As an alternative implementation, during the reading and writing process after building a data copy, the identifiers of the write data that have been changed, added, or deleted are collected into the block's pending status data set, and a Bloom filter is built based on the identifiers of the write data that have been changed, added, or deleted.

[0018] A node downtime recovery method for asynchronous state data storage, based on the above asynchronous state data storage method, when a node restarts after downtime, recover cached state data that failed to be persistently stored when the node went down based on the block data persistently stored by the node, and complete persistent storage of the missing state data.

[0019] As an optional implementation, the process of recovering cached state data that failed to be persistently stored when the node went down based on the block data persistently stored by the node comprises: acquiring the current block height a of the local node and the block height b of the local node for which state data persistent storage has been completed from persistent storage; if b < a, it indicates that there is unfinished state data persistent storage when the local node went down;

[0020] the node acquires the next block for which state data persistent storage has been completed from the persistent storage, replaying and executing transactions in the next block, calculating a state root based on the state data obtained through execution, and comparing the state root with the state root recorded in the next block; if they are equal, it indicates that the state execution is correct, and the state data is stored in the persistent storage;

[0021] sequentially completing re-execution and persistent storage of state data of remaining blocks according to the above steps, so as to implement recovery of state data.

[0022] As an optional implementation, if the state root obtained through execution is inconsistent with the state root recorded in the block data during the state data recovery process, the block and subsequent blocks with higher block heights are discarded, a request is sent to synchronize missing block data from other nodes in the network, and re-verification and execution are performed until the block height is caught up.

[0023] A system for asynchronous state data storage, comprising at least one blockchain node, wherein the blockchain node comprises:

[0024] a block processing module configured to construct, execute and conduct consensus verification on blocks based on blockchain communication rules and consensus rules, and persistently store block data that has passed consensus;

[0025] a state data caching module configured to: after a new block passes consensus, write state data into a cache first, cache a to-be-persisted block state data set with block height as a version, and asynchronously perform persistent storage on cached state data of various versions; when receiving a state data read-write request, construct a data copy based on the latest version of state data in the cache and the persistent storage, and then perform read-write operations.

[0026] As an optional implementation, the blockchain node further comprises a state execution engine module, wherein the state execution engine module comprises:

[0027] The status data execution module is configured to form a status data set by all write data involving changes, additions or deletions of status data before writing status data to the cache.

[0028] A Bloom filter construction module is configured to construct a Bloom filter based on the identifier of the state data;

[0029] The state root calculation module is configured to calculate the state root of the block based on the write data collected by the state data execution module, and submit it to the block processing module for block verification.

[0030] As an alternative implementation, the state data caching module includes:

[0031] The state data cache queue is configured to use a queue structure for first-in-first-out cache state execution engine module to collect the state data of each block version to be persisted.

[0032] The asynchronous state data storage module is configured to sequentially retrieve a version of the state data set to be persisted from the state data cache queue and persist it. After each version of the state data set is persisted, the state data set is deleted from the state data cache queue, the Bloom filter of the data set is deleted from the latest version state data retrieval module, and the block height of the currently completed state data persistence storage is updated.

[0033] The latest version of the state data acquisition module is configured to retrieve the latest version of the state data required for block state execution based on the Bloom filter of each version of the state data to be persisted, and create a data copy based on the retrieved data.

[0034] A node failure recovery system with asynchronous storage of state data includes at least one blockchain node, the blockchain node comprising:

[0035] The state data recovery module is configured to recover cached state data that failed to be persisted when the node crashed, based on the block data of the node's persistent storage, and to persist the missing state data.

[0036] As an alternative implementation, the state data recovery module includes:

[0037] The missing data detection module is configured to check whether there is a version missing in the persistent state data of this node based on the current block height of the node and the block height of the currently completed state data persistence.

[0038] The replay execution module is configured to start from the block height of the smallest version of the missing state data, replay the block data, calculate the state root based on the executed state data, and check whether it is equal to the state root in the block data. If they are equal, the state data set is persisted until the current block height is caught up.

[0039] As an alternative implementation, a block synchronization module is also included, which is configured to synchronize missing blocks from other nodes in the blockchain, and perform execution, verification, and on-chain storage until the current block height in the blockchain system is caught up.

[0040] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0041] This invention maintains a cache of state data to be persisted using block height as the version. Writing state data to the cache can start the state processing of the next block. The state data in the cache is persisted asynchronously, thereby reducing the blocking of new block processing caused by persistent storage of state data and improving the transaction throughput of the blockchain.

[0042] This invention supports reading and writing state data during block processing by constructing a data copy based on the latest version of the state data in the cache and persistent storage before reading and writing. This avoids inconsistencies or errors in the new block results when there is a conflict between the read and write state data of the old and new blocks due to the failure of the cached data to be persistently stored in time. On the other hand, the method of constructing the data copy does not change the historical block state data in the cache and does not affect the correctness of the persistent storage of historical block state data.

[0043] When retrieving the latest version of state data based on the cache, this invention improves the data retrieval efficiency using a Bloom filter.

[0044] This invention stores the current block height and the block height of the blockchain node that has completed state data persistence in real time, and provides a state data recovery mechanism based on this. Even if the node crashes and causes the cached state data to be lost, the state data can be recovered based on the block data.

[0045] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0046] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0047] Figure 1 This is a flowchart illustrating a method for asynchronous storage of state data according to one embodiment.

[0048] Figure 2 This is a schematic diagram of a version update process according to one embodiment;

[0049] Figure 3 This is a schematic diagram illustrating the data flow of asynchronous storage of state data in one embodiment.

[0050] Figure 4 This is a schematic diagram of a node failure recovery method for asynchronous storage of state data, according to one embodiment.

[0051] Figure 5 This is a schematic diagram of a blockchain node that asynchronously stores state data in one embodiment. Detailed Implementation

[0052] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0053] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0054] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0055] Where there is no conflict, the embodiments and features described in this application may be combined with each other.

[0056] Example 1

[0057] A method for asynchronous storage of state data, such as Figure 1 As shown, it includes the following steps:

[0058] Step 101: New block construction, execution, and consensus state data aggregation; blockchain nodes create a new block of height n. n During the construction, execution, and consensus process, all write data involving changes, additions, or deletions of state data constitutes the state data set, state_set. n The above state data identifiers are used to construct a Bloom filter. n .

[0059] The process of building, executing, and reaching consensus on new blocks requires reading and writing state data. The latest version of the state data is obtained from the cached set of various versions of state data and persistent storage, and a data copy is built for reading and writing.

[0060] The Bloom filter mentioned above is a space-efficient and time-complex data structure used to determine whether an element belongs to a set, and can give the result that the element may or may not exist in the set.

[0061] The process is as follows: Figure 2 As shown, steps 1001-1009 are included:

[0062] Step 1001: Obtain the highest version number of the current cached state set as the initial version number for cache retrieval.

[0063] Step 1002: Retrieve the data identifier from the cache for this version of the Bloom filter.

[0064] Step 1003: Determine the return value of the Bloom filter. If it is true, it means that the data may exist in the cached state data set for this version. Proceed to step 1004. If it is false, it means that the data definitely does not exist in the cached state data set for this version. Proceed to step 1006.

[0065] Step 1004: Try to retrieve data from the state data set of this version in the cache.

[0066] Step 1005: Determine whether data was obtained in step 1004. If yes, proceed to step 1007; otherwise, proceed to step 1006.

[0067] Step 1006: Determine if the current version is the lowest version in the cache. If yes, proceed to step 1008; otherwise, proceed to step 1009.

[0068] Step 1007: Create a data copy based on the data obtained in step 1005 and perform read and write operations.

[0069] Step 1008: Retrieve data from persistent storage and perform data read and write operations.

[0070] Step 1009: Decrement the current version number by 1, and proceed to Step 1002 to continue the data retrieval process.

[0071] Step 102: New block data persistence. When blockchain nodes determine the block size according to the consensus rules... n After consensus is reached and the data is persisted on the blockchain, the block data will be stored in `block_data`. n The current block height currentBH=n is persistently stored.

[0072] Step 103: Write the state data set to the cache, and add the state data set to be committed (state_set). n Using the block height n of this block as the version, write the data in batches to the state cache queue, and then copy the state data set corresponding to this version to the `bloom_filter`. n Write to the Bloom filter cache.

[0073] Step 104: Asynchronously persist the state data set, storing the state data set (state_set) of each version in the state cache. n-m to state_set n Asynchronously, persistent storage is performed according to version number, from lowest to highest. A state data set `state_set` is created after each version is completed. k If the state is persistently stored, then the cached state data set for that version is removed from the state cache queue. k Remove this version of the Bloom filter from the Bloom filter cache. k Update the block height stateBH=k of the currently completed persistent state data storage in the persistent storage, and start the persistent storage of the next version of the state data set until there is no data to be persisted in the state cache queue.

[0074] Blockchain nodes will set state_set n After writing to the state cache queue, it is not necessary to wait for the data in the state cache queue to be persisted before starting the next block block. n+1 The construction, execution, and consensus of [the system].

[0075] If the next block bl ock n+1 The construction, execution, and consensus processes require reading and writing state data. x Then, it searches sequentially from the highest to the lowest version in the Bloom filter of the cached state data sets until it locates the highest version of the state data set cached as the required data. x and from state_set x If the required data is not found in any of the cached version status data, it means that the latest version of the required data is in persistent storage. The required data is then retrieved from the persistent status data.

[0076] Get the data state x Then, a data copy of the state is created based on this data. x’ Data read and write operations are performed, and write data identifiers involving changes, additions, or deletions are aggregated into blocks.n+1 The set of pending state data, state_set n+1 In the process, a Bloom filter is constructed based on the identifiers of the changed, added, or deleted write data. n+1 .

[0077] like Figure 3 As shown in this embodiment, data1-235 represents the 235 cached version of state data1, and data1-db represents the persistent storage version of data1.

[0078] The state cache queue contains versions 235, 236, and 237 awaiting writing to persistent storage. Version 235's state data set contains data1-235 and data2-235; version 236's state data set contains data3-236; and version 237's state data set contains data1-237 and data4-237. The persistent database contains persistent data including data1-db, data2-db, data3-db, data4-db, data5-db, and data6-db.

[0079] During the block processing (construction, execution, consensus) of new block 238, data1, data2, and data6 need to be read and written. The latest version of data1 is in the cached state data set of version 237, the latest version of data2 is in the cached state data set of version 235, and the latest version of data6 is in persistent storage. Based on the above data, data replicas data1-237', data2-235', and data6-db' are constructed for data reading and writing during the new block processing. Among them, data1-237' and data6-db' are written during data processing. Data1-237' and data6-db' are then aggregated into the write operation state data set of version 238 as data1-238 and data6-238, and this version state data set is written to the cache queue.

[0080] The state data cache queue stores the state data sets of each version in order of version size from low to high. This process does not affect the processing of new blocks, and the reading and writing of state data by new blocks does not affect the correctness of the persistent storage of state data.

[0081] This embodiment constructs a version-based state data caching and asynchronous persistent storage mechanism. After the consensus of a new block is passed, the block data is persistently stored and the state data is first written to the cache. This allows the consensus or execution of the next block to begin. The state data in the cache is asynchronously persistently stored. During this process, when state data needs to be read or written, a data copy is constructed based on the latest version of the state data in the cache and persistent storage before reading or writing. This reduces the blocking of new block processing caused by persistent state data storage, improves the blockchain transaction throughput, and avoids inconsistent or incorrect blockchain state execution results.

[0082] Example 2

[0083] A system for asynchronous storage of state data includes at least one blockchain node, the blockchain node comprising:

[0084] The block processing module is configured to construct, execute, and verify blocks based on blockchain communication rules and consensus rules, and to persistently store the data of blocks that have passed consensus.

[0085] The state data caching module is configured to first write state data into the cache after a new block consensus is passed, cache the set of block state data to be persisted with the block height as the version, and asynchronously persist the state data of each version in the cache; when a request to read or write state data is received, a data copy is built based on the latest version of the state data in the cache and persistent storage before reading or writing.

[0086] In some embodiments, the blockchain node further includes a state execution engine module, which includes:

[0087] The status data execution module is configured to form a status data set by all write data involving changes, additions or deletions of status data before writing the status data to the cache.

[0088] A Bloom filter construction module is configured to construct a Bloom filter based on the identifier of the state data;

[0089] The state root calculation module is configured to calculate the state root of the block based on the write data collected by the state data execution module, and submit it for block verification.

[0090] In some embodiments, the state data caching module includes:

[0091] The state data cache queue is configured to use a queue structure for first-in-first-out cache state execution engine module to collect the state data of each block version to be persisted.

[0092] The asynchronous state data storage module is configured to sequentially retrieve a version of the state data set to be persisted from the state data cache queue and persist it. After each version of the state data set is persisted, the state data set is deleted from the state data cache queue, the Bloom filter of the data set is deleted from the latest version state data retrieval module, and the block height of the currently completed state data persistence storage is updated.

[0093] The latest version of the state data acquisition module is configured to retrieve the latest version of the state data required for block state execution based on the Bloom filter of each version of the state data to be persisted, and create a data copy based on the retrieved data.

[0094] Of course, the subject of protection in Embodiment 2 can also be a blockchain node.

[0095] Example 3

[0096] A node failure recovery method with asynchronous storage of state data, such as Figure 4 As shown, based on the above embodiments, the following steps are included:

[0097] Step 201: Obtain the current block height currentBH and the block height stateBH of the current completed state data of this node from the persistent storage.

[0098] Step 202: Compare whether stateBH is less than currentBH. If yes, proceed to step 203; otherwise, it means that the cached state data has been fully persisted when the node crashed, and there is no need to recover the cached data that has not been persisted.

[0099] Step 203: Retrieve the block from persistent storage stateBH+1 Block data, for bl ock stateBH+1 The transaction replay execution is performed, and the state root is calculated based on the state data obtained from the execution.

[0100] Step 204: Compare the state root obtained in Step 3 with the block block. stateBH+1 Check if the records are the same. If they are, proceed to step 205; otherwise, proceed to step 206.

[0101] Step 205: Store the state data in persistent storage and update stateBH to stateBH+1. Repeat steps 202 to 206 until the block is reached. currentBH This enables the re-execution and persistent storage of state data, completes the recovery of state data, and allows the node to restart and continue participating in subsequent blockchain system operations.

[0102] Step 206: Discard the block and subsequent blocks of higher height, request synchronization of missing block data from other nodes in the network, re-verify and execute, until the block height is caught up.

[0103] This embodiment can prevent the loss of some data in the state cache queue due to failure to complete persistent storage after an unexpected blockchain node crash.

[0104] This embodiment uses real-time persistent storage of the state data blocks that the blockchain node has already completed persistent storage. This allows the cached state data that was not persisted when the node crashed to be recovered based on the persistent storage of the block data after the node crashes and restarts after an abnormal node crash. The missing state data is then persisted, thus avoiding the loss of state data after an abnormal node crash due to the state data caching mechanism.

[0105] Example 4

[0106] A blockchain node that asynchronously stores state data, such as Figure 5 As shown, it specifically includes a block processing module 301, a state execution engine 302, a state data cache module 303, a state data recovery module 304, and a block synchronization module 305.

[0107] In this embodiment, the block processing module 301 constructs, executes, and verifies blocks based on blockchain communication rules and consensus rules, and persistently stores the block data that has passed consensus.

[0108] In this embodiment, the state execution engine 302 provides reading and writing of block state data, collection of written data, construction of Bloom filters for written data, and calculation of the new block state root when executing a new block.

[0109] Specifically, it includes a state data execution module 3021, a Bloom filter construction module 3022, and a state root calculation module 3023.

[0110] The aforementioned status data execution module 3021 provides status execution when a new block is executed, and collects write operation data involving changes, additions, or deletions during status execution.

[0111] The Bloom filter construction module 3022 constructs a Bloom filter by identifying write operation data involving changes, additions, or deletions during state execution, and submits the state data Bloom filter of the block to the latest version state data acquisition module 3033 after the block reaches the on-chain state.

[0112] After the block and state execution is completed, the state root calculation module 3023 calculates the state root of the block based on the write data collected by the state data execution module, and submits it to the block processing module 301 for block verification.

[0113] In this embodiment, the state data caching module 303 caches the set of block state data to be persisted using the block height as the version, and retrieves the latest state data version from the cache and persistent storage when processing a new block and submits it to the state data execution module for state execution, and asynchronously persists the state data of each version in the cache.

[0114] Specifically, it includes a status data cache queue 3031, a status data asynchronous storage module 3032, and a latest version status data acquisition module 3033.

[0115] In some embodiments, the state data cache queue 3031 adopts a queue structure with a first-in-first-out cache state execution engine 302 to collect the state data set of each block version to be persisted.

[0116] The asynchronous state data storage module 3032 sequentially retrieves one version of the state data set to be persisted from the state data cache queue 3031 and persists it. After each version of the state data set is persisted, it is deleted from the state data cache queue 3031, the Bloom filter for that version of the data is removed from the latest version state data retrieval module 3033, and the block height of the currently persisted state data in the persistent storage is updated.

[0117] The latest version status data acquisition module 3033 retrieves the latest version of the status data required for block status execution based on the Bloom filter of each version of the status data to be persisted, and creates a data copy based on the retrieved data and submits it to the status data execution module 3021.

[0118] In this embodiment, the state data recovery module 304 checks whether there are missing versions of the persistent state data of the node when the node starts up, based on the current block height of the node in persistent storage and the block height of the currently persisted state data. If there are, it starts from the block height of the smallest version of the missing state data, replays the block data, calculates the state root based on the executed state data, and checks whether it is equal to the state root in the block data. If they are equal, it persists the state data set until it catches up with the current block height.

[0119] The status data recovery module 304 also includes:

[0120] The missing data detection module 3041 is configured to check whether there is a version missing in the persistent state data of this node based on the current block height of the node and the block height of the currently completed state data persistence.

[0121] The replay execution module 3042 is configured to replay the block data starting from the block height of the smallest version of the missing state data, calculate the state root based on the executed state data, and verify whether it is equal to the state root in the block data. If they are equal, the state data set is persisted until the current block height is caught up.

[0122] In this embodiment, if the state root obtained after the block data replay is not equal to that in the block data, the block and subsequent block data are discarded, and the block synchronization module synchronizes the missing block from other nodes in the blockchain.

[0123] The block synchronization module 305 synchronizes missing blocks from other nodes in the blockchain, and performs execution, verification, and on-chain storage until it catches up with the current block height in the blockchain system.

[0124] Example 5

[0125] A node failure recovery system for asynchronous storage of state data includes at least one blockchain node provided in Embodiment 2 or the blockchain node provided in Embodiment 4.

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

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

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

[0129] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made by those skilled in the art without creative effort within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for asynchronous storage of state data, characterized in that, comprising the following steps: after the consensus on a new block is reached, completing persistent storage of block data, writing state data into a cache first, and performing asynchronous persistent storage on the state data in the cache; in the above process, when a state data read-write request is received, reading and writing are performed after constructing a data copy based on the latest version of the state data in the cache and the persistent storage.

2. The method for asynchronous storage of state data as described in claim 1, characterized in that, before writing the state data into the cache first, all write data involving modification, addition or deletion of state data constitutes a state data set, a bloom filter is constructed based on the identifiers of the state data, the state data set is written into a state cache queue in batches with the block height n of the block as a version, and the bloom filter corresponding to the state data set of this version is written into a bloom filter cache.

3. The method for asynchronous storage of state data as described in claim 1, characterized in that, the process of completing persistent storage of block data is: determining that the consensus on the current block is reached according to a consensus rule, and after the block reaches a persistent on-chain state, performing persistent storage on the block data and the current block height.

4. The method for asynchronous storage of state data as described in claim 1, characterized in that, the process of performing asynchronous persistent storage on the state data in the cache comprises: performing asynchronous persistent storage on state data sets of various versions in the state cache queue sequentially from a low version to a high version according to the version number; after completing persistent storage of one version of the state data set, deleting the cached state data set of the version from the state cache queue, deleting the bloom filter of the version from the bloom filter cache, updating the block height for which persistent storage of state data has been currently completed in the persistent storage, and starting persistent storage of the next version of the state data set until there is no data to be persisted in the state cache queue.

5. A method for asynchronous storage of state data as described in any one of claims 1-4, characterized in that, writing the state data of the block data into the state cache queue, and starting construction, consensus or block execution of a next block without waiting for the data in the state cache queue to complete persistence; or further, if construction, consensus or execution of a new block requires reading and writing state data, retrieving sequentially from a high version to a low version from bloom filters of state data sets of various versions in the cache until locating the highest-version state data set cache where required data may exist, and acquiring data from the highest-version state data set cache; if the required data does not exist in state data of any version in the cache, indicating that the latest version of the required data is in the persistent storage, and the required data is acquired from the persistent state data.

6. A node failure recovery method for asynchronous storage of state data, based on the method for asynchronous storage of state data according to any one of claims 1-5, characterized in that, when a node is restarted after downtime, based on the block data persistently stored by the node, cached state data that failed to complete persistent storage when the node went down is recovered, and persistent storage of the missing state data is completed.

7. The node failure recovery method for asynchronous storage of state data as described in claim 6, characterized in that, the process of recovering cached state data that failed to complete persistent storage when the node went down based on the block data persistently stored by the node comprises: acquiring a current block height a of the node and a block height b for which the node has currently completed persistent storage of state data from the persistent storage, and if b < a, it indicates that there is state data for which persistence is not completed when the node went down; The node retrieves the next block from the persistent storage where the node has completed the persistent storage of its current state data, replays and executes the transactions in the next block, calculates the state root based on the state data obtained from the execution, compares it with the state root recorded in the next block, and if they are equal, it means that the state execution is correct and stores the state data in the persistent storage. By following the steps described above, the state data of the remaining blocks will be re-executed and persistently stored to restore the state data. Alternatively, if the state root obtained during the recovery of state data is inconsistent with the state root recorded in the block data, discard that block and subsequent blocks of higher height, request synchronization of the missing block data from other nodes in the network, re-verify and execute, until the block height is caught up.

8. A system for asynchronous storage of state data, characterized in that, Includes at least one blockchain node, said blockchain node comprising: The block processing module is configured to construct, execute, and verify blocks based on blockchain communication rules and consensus rules, and to persistently store the data of blocks that have passed consensus. The state data caching module is configured to first write state data into the cache after a new block consensus is passed, cache the set of block state data to be persisted with the block height as the version, and asynchronously persist the state data of each version in the cache; when a request to read or write state data is received, a data copy is built based on the latest version of the state data in the cache and persistent storage before reading or writing.

9. A system for asynchronous storage of state data as described in claim 8, characterized in that, The blockchain node also includes a state execution engine module, which comprises: The status data execution module is configured to form a status data set by all write data involving changes, additions or deletions of status data before writing the status data to the cache. A Bloom filter construction module is configured to construct a Bloom filter based on the identifier of the state data; The state root calculation module is configured to calculate the state root of the block based on the write data collected by the state data execution module, and submit it to the block processing module for block verification. Alternatively, the state data caching module includes: The state data cache queue is configured to use a queue structure for first-in-first-out cache state execution engine module to collect the state data of each block version to be persisted. The asynchronous state data storage module is configured to sequentially retrieve a version of the state data set to be persisted from the state data cache queue and persist it. After each version of the state data set is persisted, the state data set is deleted from the state data cache queue, the Bloom filter of the data set is deleted from the latest version state data retrieval module, and the block height of the currently completed state data persistence storage is updated. The latest version of the state data acquisition module is configured to retrieve the latest version of the state data required for block state execution based on the Bloom filter of each version of the state data to be persisted, and create a data copy based on the retrieved data.

10. A node failure recovery system with asynchronous storage of state data, based on the system of any one of claims 8 or 9, comprising at least one blockchain node, characterized in that, The blockchain nodes include: The state data recovery module is configured to recover the cached state data that failed to be persisted when the node crashed, based on the block data of the node's persistent storage, and to complete the persistent storage of the missing state data when the node restarts. include: The missing data detection module is configured to check whether there is a version missing in the persistent state data of this node based on the current block height of the node and the block height of the currently completed state data persistence. The replay execution module is configured to start from the block height of the smallest version of the missing state data, replay the block data, calculate the state root based on the executed state data, and check whether it is equal to the state root in the block data. If they are equal, the state data set is persisted until the current block height is caught up. Alternatively, the system may also include a block synchronization module, configured to synchronize missing blocks from other nodes in the blockchain, and perform execution, verification, and on-chain storage until the current block height in the blockchain system is caught up.

Images