A persistent storage method for consensus data, blockchain node

Abstract

A persistent storage method for consensus data is applied to any consensus node participating in consensus in a blockchain system. The process address space of the consensus process running on the consensus node includes a reserved mapping region. A one-to-one mapping relationship is established between the virtual memory address in the mapping region and the physical storage address in the non-volatile physical storage space on the consensus node used for persistent storage of consensus data. The method includes: acquiring consensus data generated by the consensus process during the execution of the consensus protocol; persistently storing the consensus data in the mapping region; and, in response to the consensus data being successfully written to the mapping region, determining the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping region, and further writing the consensus data back to the physical storage space based on the physical storage address.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a persistent storage method for consensus data and a blockchain node. Background Technology

[0002] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. The decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to address the issue of ensuring the consistency and correctness of the distributed ledger maintained locally by each decentralized (or multi-centralized) node.

[0003] In practical applications, nodes in a distributed blockchain network can run consensus protocols to ensure the consistency and correctness of the distributed ledger maintained locally by each node.

[0004] Current mainstream consensus protocols include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, and so on. Summary of the Invention

[0005] This specification proposes a persistent storage method for consensus data, which is applied to any consensus node participating in consensus in a blockchain system. The process address space of the consensus process running on the consensus node includes a reserved mapping area. The virtual memory address in the mapping area establishes a one-to-one mapping relationship with the physical storage address in the non-volatile physical storage space of the consensus node used for persistent storage of consensus data.

[0006] The method includes:

[0007] Obtain the consensus data generated by the consensus process during the execution of the consensus protocol;

[0008] The consensus data is written to the mapping area for persistent storage;

[0009] In response to the consensus data being successfully written to the mapping area, a physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area is determined, and based on the physical storage address, the consensus data is further written back to the physical storage space.

[0010] Optionally, the physical storage space is the disk storage space corresponding to the disk mounted on the node device.

[0011] Optionally, the consensus data is persistently stored in the form of files; the mapping area is a file mapping area reserved in the process address space.

[0012] Optionally, the mapping region is a region reserved in the shared area of ​​the process address space.

[0013] Optionally, the consensus data includes consensus-related metadata; and consensus message data for consensus interaction with other consensus nodes; correspondingly, the mapping area includes a first mapping area for storing the metadata and a second mapping area for storing the consensus message data.

[0014] Optionally, the consensus data is stored in the mapping area in the form of key-value pairs; wherein, the key in the key-value pair corresponding to the metadata is a fixed value; at least the key in the key-value pair corresponding to the metadata is pre-stored in the first mapping area.

[0015] Writing the consensus data into the mapping area for persistent storage includes:

[0016] If the consensus data contains key-value pairs corresponding to the metadata, starting from the starting address of the first mapping region, traverse the first mapping region and query the key in the key-value pairs corresponding to the metadata that are pre-stored in the first mapping region; if a key in a key-value pair corresponding to the metadata is found in the first mapping region, based on the value in the key-value pair corresponding to the metadata, further modify the value corresponding to the found key, so as to write the key-value pair corresponding to the metadata into the first mapping region for persistent storage;

[0017] If the consensus data contains key-value pairs corresponding to the consensus message data, starting from the starting address of the second mapping area, traverse the second mapping area to determine the tail address of the data already stored in the second mapping area, and use the storage location indicated by the tail address as the writing start position to write the key-value pairs corresponding to the consensus message data into the second mapping area for persistent storage.

[0018] Optionally, the method further includes:

[0019] In response to a read instruction for target consensus data, the data type of the target consensus data is determined;

[0020] If the target consensus data is the metadata, read the target consensus data from the first mapping area;

[0021] If the target consensus data is the consensus message data, read the target consensus data from the second mapping area.

[0022] Optionally, the read instruction includes the key of the target consensus data;

[0023] Determining the data type of the target consensus data includes:

[0024] Determine whether the key of the target consensus data is a fixed value;

[0025] If the key of the target consensus data is a fixed value, then the target consensus data is determined to be the metadata;

[0026] If the key of the target consensus data is not a fixed value, then the target consensus data is determined to be the consensus message data.

[0027] Optionally, the read instruction includes the virtual memory address of the target consensus data in the mapping region;

[0028] Determining the data type of the target consensus data includes:

[0029] The virtual memory address is matched with the first virtual memory address range corresponding to the first mapping region and the second virtual memory address range corresponding to the second mapping region, respectively;

[0030] If the virtual memory address matches the first virtual memory address range, then the target consensus data is determined to be the metadata;

[0031] If the virtual memory address matches the second virtual memory address range, then the target consensus data is determined to be the consensus message data.

[0032] Optionally, reading the target consensus data from the first mapping region or the second mapping region includes: searching for the target consensus data in the first mapping region or the second mapping region based on the key of the target consensus data.

[0033] Optionally, the method further includes:

[0034] In response to a garbage collection instruction for the consensus message data, the second mapping region is traversed to determine the target consensus message data that needs to be garbage collected stored in the second mapping region.

[0035] In response to the identification of target consensus message data that needs to be garbage collected, the virtual memory space occupied by the target consensus message data in the second mapping region is released.

[0036] Optionally, the garbage collection instruction includes a specified range of values ​​corresponding to the key of the target consensus message data that needs to be garbage collected;

[0037] Traversing the second mapping region to determine the target consensus message data that needs to be garbage collected stored in the second mapping region includes: traversing the second mapping region, searching for consensus message data whose key values ​​are within the range of the values ​​stored in the second mapping region, and determining the found consensus message data as the target consensus message data that needs to be garbage collected.

[0038] Optionally, the method further includes:

[0039] In response to the identification of target consensus message data that needs to be garbage collected, it is further determined whether the target consensus message data has been written back to the physical storage space; if so, the target consensus message data stored in the physical storage space is deleted synchronously.

[0040] Optionally, the method further includes:

[0041] In response to an instruction to restore the state of the consensus protocol running for the consensus process, the consensus data persistently stored in the mapping area is read, and the consensus protocol is restored based on the read consensus data.

[0042] This specification also proposes a persistent storage device for consensus data, applied to any consensus node participating in consensus in a blockchain system. The process address space of the consensus process running on the consensus node includes a reserved mapping region; the virtual memory address in the mapping region establishes a one-to-one mapping relationship with the physical storage address in the non-volatile physical storage space on the consensus node used for persistent storage of consensus data; the device includes:

[0043] The acquisition module acquires the consensus data generated by the consensus process during the execution of the consensus protocol.

[0044] The storage module writes the consensus data into the mapping area for persistent storage;

[0045] The write-back module, in response to the successful writing of the consensus data to the mapping area, determines the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area, and further writes the consensus data back to the physical storage space based on the physical storage address.

[0046] In the above embodiments, by employing memory mapping, a one-to-one mapping relationship is established between the virtual memory address in the reserved mapping area in the process address space of the consensus process and the physical storage address in the non-volatile physical storage space used for persistent storage of consensus data. This allows the consensus data generated by the consensus process during the execution of the consensus protocol to be stored in the memory space allocated to the consensus process. When the consensus process needs to access the persistently stored consensus data, it can directly read the consensus data from the memory space of the consensus process, without needing to access the physical storage space through system I / O. This reduces the frequency of I / O access to the physical storage space by the consensus process, improves the efficiency of reading and writing consensus data, and helps to improve the execution efficiency of the consensus process when executing the consensus protocol. Attached Figure Description

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

[0048] Figure 1 This is a schematic diagram illustrating an embodiment of this specification of persistently storing consensus data using a conventional database;

[0049] Figure 2 This is a flowchart illustrating a persistent storage method for consensus data in one embodiment of this specification;

[0050] Figure 3 This is a schematic diagram illustrating a reserved mapping region in the process address space in one embodiment of this specification;

[0051] Figure 4 This is a schematic diagram illustrating the division of a reserved mapping region in the process address space according to one embodiment of this specification;

[0052] Figure 5 This is a schematic structural diagram of an electronic device shown in one embodiment of this specification;

[0053] Figure 6 This is a block diagram of a persistent storage device for consensus data shown in one embodiment of this specification. Detailed Implementation

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

[0055] In related technologies, to ensure the consensus protocol running in a blockchain system has a certain degree of resilience, it is typically necessary to persistently store the consensus data generated by the consensus nodes participating in the consensus process. Subsequently, when state restoration of the consensus protocol is required, the entire persistently stored consensus data can be read, and the protocol state can be restored based on this data. Furthermore, to prevent the data volume from growing indefinitely, the persistently stored consensus data also needs to be periodically garbage collected, deleting older, more recently stored data.

[0056] Currently, the common approach for persistently storing consensus data is to utilize physical storage space such as disks to implement a centralized database (e.g., a key-value database) and use this database to persistently store the consensus data.

[0057] Please see Figure 1 , Figure 1 This specification illustrates a schematic diagram of using a traditional database to persistently store consensus data.

[0058] like Figure 1As shown, when using a traditional database to persistently store consensus data, the consensus module on the consensus node and the database typically interact in the following four ways:

[0059] 1: Write data

[0060] When a consensus node needs to write the consensus data generated by running the consensus protocol into a database, it can usually interact with the disk based on system I / O write commands to write the consensus data into a database created on the disk.

[0061] 2: Reading data

[0062] When a consensus node needs to read consensus data that is persistently stored in the database, it can also interact with the disk based on the system I / O read command to read the consensus data that has been written to the database created on the disk.

[0063] 3: Waste recycling

[0064] When garbage collection is needed on the consensus data persistently stored in the database, it is also possible to interact with the disk to modify the consensus data stored in the database and delete the consensus data stored earlier.

[0065] 4: Status Recovery

[0066] When a consensus node needs to restore the state of the running consensus protocol, it can interact with the disk based on the system I / O read command to read the full consensus data, and then restore the state of the consensus protocol based on the read full consensus data.

[0067] As can be seen, in any of the four scenarios shown above, traditional database-based persistent storage of consensus data requires interaction with the disk. When the amount of data to be accessed is large, this inevitably leads to numerous disk interactions, resulting in significant time overhead for accessing the consensus data.

[0068] For example, especially the garbage collection and state recovery mentioned above, garbage collection may require deleting a large amount of early consensus data stored in the database, while state recovery often requires reading the full amount of consensus data. Therefore, both garbage collection and state recovery usually require accessing a large amount of persistent consensus data in the database, which will result in a large number of frequent interactions with the disk.

[0069] Based on this, this specification proposes a technical solution that uses memory mapping to persistently store consensus data.

[0070] Please see Figure 2 , Figure 2This document presents a flowchart of a persistent storage method for consensus data, which can be applied to any consensus node participating in consensus within a blockchain system. The process address space of the consensus process running on the consensus node includes a reserved mapping region. A one-to-one mapping relationship is established between the virtual memory addresses in the mapping region and the physical storage addresses in the physical storage space on the consensus node used for persistent storage of consensus data. The method includes the following execution process:

[0071] Step 202: Obtain the consensus data generated by the consensus process during the execution of the consensus protocol;

[0072] In this specification, a consensus process can be run on the consensus nodes that participate in the consensus process. This consensus process can be used to run the consensus protocol adopted by the blockchain system.

[0073] It should be noted that the consensus process can be a system process corresponding to the blockchain system program running on the consensus node, or it can be a process corresponding to an independent consensus module in the blockchain system. No special limitation is made in this specification.

[0074] The operating system of a consensus node can allocate an independent process address space for that consensus process. This process address space specifically describes the memory space occupied by the process within the operating system. It typically contains a set of virtual memory addresses used by the process during runtime. In practical applications, after allocating an independent process address space for the consensus process, the operating system can also establish a mapping between the virtual memory addresses contained in the process address space and the actual physical memory addresses through a page table. This allows the consensus process to access the actual physical memory space based on virtual memory addresses.

[0075] Consensus nodes participating in the consensus process can also be equipped with physical storage space for persistently storing consensus data. Specifically, this physical storage space can be non-volatile, meaning that the data persistently stored in it will not be lost even if the device experiences a power outage. For example, in one scenario, this physical storage space could be the disk storage space corresponding to the disk mounted on the consensus node. Of course, this physical storage space can obviously also be other forms of non-volatile physical storage media besides disks.

[0076] It should be noted that the physical storage space carried by the consensus node can be the physical storage space carried locally by the consensus node, or it can be an external physical storage space carried by the consensus node.

[0077] For example, taking the physical storage space as the disk storage space corresponding to the disk mounted on the consensus node, the physical storage space can be the physical storage space corresponding to a local disk of the consensus node, or it can be the physical storage space corresponding to a disk peripheral connected to the consensus node (such as the disk on an external server connected to the consensus node).

[0078] In this specification, a mapping area for persistently storing consensus data can be reserved within the process address space allocated to the consensus process. For example, in one instance, the consensus data can be persistently stored as a file, and the aforementioned mapping area can be a file mapping area reserved in the process address space. Of course, in practical applications, consensus data can also be stored in other forms besides files, and this specification does not impose any specific limitations on this.

[0079] It should be noted that the specific location of the reserved mapping area in the process address space is not specifically defined in the specification.

[0080] For example, see Figure 3 In one embodiment shown, a shared region typically exists within the structure of the process address space. This shared region usually refers to a memory area that can be shared between processes. The aforementioned reserved mapping region can specifically be a reserved area within the shared region of the process address space structure. Of course, in practical applications, besides reserving the mapping region within the shared region, unused areas in other regions of the process address space structure can also be used to reserve the mapping region.

[0081] In order to utilize the reserved mapping area in the process address space of the consensus process to persistently store consensus data, the virtual memory address in this mapping area can also establish a one-to-one mapping relationship with the physical storage address in the physical storage space carried by the consensus node.

[0082] In this way, the consensus data stored in the physical storage space can be mapped to the reserved mapping area in the process address space of the consensus process. This allows the consensus process to access the persistent consensus data in the physical storage space using memory read / write instructions, just like accessing data stored in memory, without having to perform I / O interaction with the physical storage space.

[0083] In this specification, during the process of running the consensus protocol, the consensus process on the consensus node usually generates some consensus data. The consensus node can obtain this consensus data and then persist it, so that the consensus node can subsequently restore the state of the consensus protocol based on the full amount of persistently stored consensus data.

[0084] Among them, the consensus data generated during the consensus process of running the consensus protocol usually includes all the data generated during the running of the consensus protocol.

[0085] In one embodiment shown, the consensus data typically includes consensus-related metadata and consensus message data for consensus interaction with other consensus nodes.

[0086] Metadata related to consensus typically refers to data that describes the consensus protocol used by the blockchain system, as well as data that describes the consensus process initiated based on that protocol.

[0087] For example, in practical applications, consensus-related metadata may include the algorithm type of the consensus protocol used by the blockchain system, the block height that the consensus protocol is currently reaching, and the timestamp of the block that the consensus protocol is currently reaching.

[0088] Consensus message data used for consensus interaction with other consensus nodes typically refers to the consensus messages supported by the consensus protocol adopted by the blockchain system for interaction between consensus nodes. When a blockchain system runs different types of consensus protocols, the types of consensus messages sent by consensus nodes during consensus interaction will usually differ.

[0089] For example, taking the PBFT consensus algorithm as an example, the consensus messages that the PBFT consensus algorithm supports for interaction between consensus nodes typically include PRE-PREPARE, PREPARE, COMMIT, VIEW-CHANGE, and NEW-VIEW, etc.

[0090] Correspondingly, the mapping area reserved in the process address space of the consensus process may specifically include a first mapping area for storing the aforementioned metadata and a second mapping area for storing the aforementioned consensus message data.

[0091] For example, see Figure 4 The reserved mapping area in the process address space can be divided into a metadata area (i.e., the first mapping area mentioned above) and a message data area (i.e., the second mapping area mentioned above). For example... Figure 4 As shown, Figure 4The metadata pointer shown refers to the start pointer of the metadata area, the message pointer refers to the start pointer of the message data area, the data head refers to the head pointer of the consensus message data stored in the message data area, and the data tail refers to the tail pointer of the consensus message data stored in the message data area.

[0092] It should be noted that in practical applications, regardless of the consensus protocol adopted by the blockchain system, the types and quantities of metadata related to consensus usually do not change. Based on this data characteristic, a fixed-size area can be allocated in the mapping area as the aforementioned metadata area.

[0093] For example, the types and quantities of consensus-related metadata do not change, which means that even with different consensus protocols, the size of consensus-related metadata is usually relatively constant. Therefore, in practical applications, the size of the memory space corresponding to the metadata area can be planned based on the actual size of the metadata to be stored in the consensus protocol.

[0094] Unlike the metadata mentioned above, different consensus protocols typically support significant differences in the types and quantities of consensus messages that can be exchanged between consensus nodes. Based on this data characteristic, a region larger than the metadata region and of variable size can be allocated in the mapping area as the message data region.

[0095] For example, in practical applications, for consensus protocols that support a large variety and number of consensus messages interacting between consensus nodes, a larger memory space can be allocated in the mapping area as the aforementioned message data area. Conversely, for consensus protocols that support a smaller variety and number of consensus messages interacting between consensus nodes, a smaller memory space can be allocated in the mapping area as the aforementioned message data area.

[0096] In this way, not only can the memory space of the mapping area be fully utilized, but the mapping area can also be flexibly adapted to different consensus protocols and store consensus message data supported by different consensus protocols.

[0097] It should be noted that in practical applications, consensus-related metadata can usually be included in the consensus message data generated by the consensus process during the execution of the consensus protocol in the form of fields.

[0098] For example, consider the following consensus message data structure:

[0099] Algorithm_type|seq|view|msg_type|senderID

[0100] The consensus message includes fields such as Algorithm_type, seq, view, msg_type, and senderID. Algorithm_type indicates the type of consensus algorithm corresponding to the message; seq represents the sequence number of the message; view represents the view of the consensus algorithm (a unique concept in consensus algorithms, representing a stage or round in a consensus process); msg_type indicates the message type; and senderID represents the sender ID. Among these fields, the value of the Algorithm_type field indicates the type of consensus algorithm used by the blockchain system, and this value can be used as metadata related to consensus.

[0101] Step 204: Write the consensus data into the mapping area for persistent storage;

[0102] In this specification, after obtaining the consensus data generated by the consensus process during the execution of the consensus protocol, the consensus node can attempt to use memory write instructions to write this consensus data to the reserved mapping area in the process address space of the consensus process for persistent storage, instead of directly interacting with the physical storage space for I / O to write this consensus data to the physical storage space for persistent storage.

[0103] Specifically, when writing consensus data to the aforementioned mapping area for persistent storage, the consensus node can start from the start pointer in the mapping area, traverse the mapping area, and find the tail pointer of the consensus data already stored in the mapping area. Then, the storage location indicated by the tail address can be used as the write start position, and the consensus message data to be written can be sequentially overwritten downwards to write the consensus message data into the mapping area. Of course, if it is the first time writing data to the mapping area, the storage location indicated by the start pointer of the mapping area can be used as the write start position, and the consensus message data to be written can be sequentially overwritten downwards to write the consensus message data into the mapping area.

[0104] For example, please continue to see Figure 4 Taking the consensus data mentioned above as including consensus-related metadata and consensus message data for consensus interaction with other consensus nodes as an example, in this case, the above mapping area may include a metadata area and a message data area.

[0105] When a consensus node writes consensus data to the aforementioned mapping area for persistent storage, if the consensus data contains the aforementioned metadata, then it can... Figure 4The starting pointer `meta_data` of the metadata area shown in the diagram serves as the starting position for writing. The metadata to be written is then written sequentially downwards, overwriting existing metadata in the metadata area. If the consensus data contains the aforementioned consensus message data, then... Figure 4 The message data area's starting pointer, message_data, is shown as the starting position for writing. The consensus message data to be written is then written downwards in sequence to overwrite the previous consensus message data into the message data area.

[0106] In one embodiment shown, to facilitate the retrieval of consensus data written into the aforementioned mapping area, the consensus data can be stored in the mapping area in the form of key-value pairs.

[0107] Since the types and quantities of consensus-related metadata usually do not change regardless of the consensus protocol used by the blockchain system, the key in the key-value pair corresponding to the above metadata is usually a fixed value. In this case, the key-value pair corresponding to the above metadata, or only the key in the key-value pair, can be pre-stored in the metadata area of ​​the above mapping area.

[0108] Furthermore, when a consensus node writes consensus data to the mapping area, on the one hand, if the consensus data contains key-value pairs corresponding to the aforementioned metadata, it can start from the starting address of the metadata area of ​​the mapping area (i.e., the aforementioned starting pointer meta_data), traverse the metadata area, and query the key in the key-value pairs corresponding to the metadata that are pre-stored in the metadata area; if the key in the key-value pairs corresponding to the metadata is found in the metadata area, the value corresponding to the found key can be further modified based on the value in the key-value pairs corresponding to the metadata, so as to write the key-value pairs corresponding to the metadata to the metadata area for persistent storage.

[0109] On the other hand, if the consensus data contains key-value pairs corresponding to the consensus message data, then starting from the beginning address of the message data area in the mapping region (i.e., the beginning pointer message_data), the message data area can be traversed to determine the end address of the data already stored in the message data area, and the storage location indicated by the end address can be used as the writing start position to write the key-value pairs corresponding to the consensus message data into the message data area for persistent storage.

[0110] It should be noted that when a consensus node attempts to use a memory write command to write consensus data to a reserved mapping area in the process address space of the consensus process for persistent storage, the write command usually carries a virtual memory address as the starting position of the write. When the consensus node's operating system receives the write command, it can automatically map the virtual memory address used as the starting position of the write to a real physical memory address through the mapping relationship between the virtual memory address and the real physical memory address contained in the process address space established in the page table. Then, based on the physical memory address, the consensus data to be written is written into the physical memory.

[0111] Step 206: In response to the consensus data being successfully written to the mapping area, determine the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area, and based on the physical storage address, further write the consensus data back to the physical storage space.

[0112] In this specification, after a consensus node successfully writes consensus data into the aforementioned mapping area, the operating system of the consensus node can automatically write back the consensus data persistently stored in memory to the aforementioned physical storage space in the background. Specifically, after a consensus node successfully writes consensus data into the aforementioned mapping area, the operating system of the consensus node can respond to the event that the consensus data has been successfully written to the mapping area. Based on the established mapping relationship between the virtual memory address in the mapping area and the physical storage address in the non-volatile physical storage space used by the consensus node for persistent storage of consensus data, it can determine the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area. Then, based on the physical storage address, it can further write back the consensus data to the physical storage space.

[0113] It should be noted that, in practical applications, the specific timing of the consensus node's operating system writing back the consensus data persistently stored in memory to the aforementioned physical storage space in the background can be flexibly determined based on actual needs.

[0114] For example, in one approach, the consensus node's operating system can write back the consensus data to the aforementioned physical storage space in real time when it detects that consensus data has been successfully written to the mapping area; in another approach, the consensus node's operating system can also periodically write back the consensus data persistently stored in memory to the aforementioned physical storage space; in a third approach, the consensus node's operating system can also trigger the writing back of the consensus data persistently stored in memory to the aforementioned physical storage space when the storage pressure in memory is high, such as insufficient remaining memory storage space, or when the used memory storage space reaches a threshold.

[0115] Once the consensus node's operating system writes the consensus data persistently stored in memory back to the aforementioned physical storage space in the background, the consensus data persistently stored in the aforementioned physical storage space will be directly mapped to the process address space allocated to the consensus process. Subsequently, the consensus process can access the consensus data persistently stored in the physical storage space based on memory read / write instructions just like accessing data stored in memory, without needing to perform I / O interaction with the physical storage space.

[0116] In one embodiment, when the consensus process needs to read target consensus data that has been persistently stored, it can generate a memory read instruction for the target consensus data and send the memory read instruction to the operating system of the consensus node. Upon receiving the memory read instruction, the operating system can respond to it and determine the data type of the target consensus data to be read. If the target consensus data is metadata, it can be read from the metadata area in the mapping area; if the target consensus data is consensus message data, it can be read from the message data area in the mapping area.

[0117] It should be noted that when determining the data type of the target consensus data to be read, the operating system can do so based on the key of the target consensus data or based on the virtual memory address of the target consensus data in the mapping area.

[0118] For example, in one embodiment shown, the memory read instruction may specifically include a key for the target consensus data; when determining the data type of the target consensus data, the operating system may determine whether the key of the target consensus data is a fixed value; if the key of the target consensus data is a fixed value, the target consensus data may be determined to be the aforementioned metadata; if the key of the target consensus data is not a fixed value, the target consensus data may be determined to be the aforementioned consensus message data.

[0119] In another embodiment shown, the memory read instruction may also include the virtual memory address of the target consensus data in the mapping area. When determining the data type of the target consensus data, the operating system may match the virtual memory address included in the memory read instruction with the first virtual memory address range corresponding to the metadata area and the second virtual memory address range corresponding to the message data area. If the virtual memory address included in the memory read instruction matches the first virtual memory address range corresponding to the metadata area, the target consensus data can be determined to be the metadata; if the virtual memory address matches the second virtual memory address range corresponding to the message data area, the target consensus data can be determined to be the consensus message data.

[0120] In one embodiment shown, since consensus data can be stored in the mapping area in the form of key-value pairs, when reading the target consensus data from the metadata area or the message data area, the target consensus data can be searched in the metadata area or the message data area based on the key of the target consensus data.

[0121] In this specification, in order to prevent the amount of consensus data stored in memory from growing indefinitely, garbage collection can also be performed on the consensus data that has been persistently stored to delete the consensus data stored earlier.

[0122] It should be noted that since the types and quantity of consensus-related metadata do not change and do not cause data accumulation in the mapping area as the block height increases, the aforementioned metadata does not need to participate in garbage collection. Conversely, since the aforementioned consensus message data usually causes data accumulation in the mapping area as the block height increases, when performing garbage collection on the already persistently stored consensus data, garbage collection can specifically target only the aforementioned consensus message data.

[0123] For example, in one embodiment shown, a garbage collection process can also run on the consensus node to perform garbage collection on the persistently stored consensus message data. This garbage collection process can periodically scan the consensus message data stored in the mapping area to determine whether the consensus message data stored in the mapping area meets the garbage collection conditions.

[0124] When it is determined that the consensus message data stored in the mapping area meets the garbage collection conditions, the garbage collection process can generate a garbage collection instruction for the consensus message data and send the garbage collection instruction to the operating system of the consensus node.

[0125] It should be noted that, in practical applications, the above garbage collection conditions can be flexibly set based on specific needs, and are not specifically limited in this specification; for example, in one example, the above garbage collection conditions may specifically be whether the capacity of consensus message data stored in the message data area of ​​the above-mentioned mapping area has reached a threshold, or whether the remaining capacity of the above-mentioned message data area has reached a threshold.

[0126] Upon receiving the garbage collection instruction, the operating system of the consensus node can respond to the instruction, traverse the message data area in the aforementioned mapping region, and determine the target consensus message data that needs to be garbage collected from the consensus message data stored in the message data area.

[0127] The specific method for identifying the target consensus message data that needs to be garbage collected from the message data area usually depends on the specific garbage collection strategy and is not specifically limited in this specification.

[0128] In one embodiment, a strategy for garbage collection of consensus message data based on the key of the consensus message data can be adopted. In this case, the garbage collection instruction can include a specified range of values ​​corresponding to the key of the target consensus message data that needs to be garbage collected. When determining the target consensus message data to be garbage collected from the message data area, the message data area can be traversed to find consensus message data whose key values ​​are within the specified range. The found consensus message data is then identified as the target consensus message data to be garbage collected. For example, in one example, a key value can be specified as a garbage collection threshold, and consensus message data with key values ​​greater than or less than the threshold can be designated as the target consensus data to be garbage collected.

[0129] Once the target consensus message data that needs to be garbage collected is identified, the virtual memory space occupied by the target consensus message data in the message data area can be directly released in response to the identified target consensus message data, so as to achieve the purpose of clearing the target consensus message data.

[0130] For example, please continue to see Figure 4 In practical applications, Figure 4 The blank area between the start pointer message_data of the message data area and the head pointer data_head of the consensus message data stored in the message data area is the blank area left after the virtual memory space occupied by the consensus message data that needs to be garbage collected in the message data area is released.

[0131] In this way, the target consensus message data that needs to be reclaimed can be quickly cleared in memory through memory release, which can significantly improve the efficiency of garbage collection of consensus message data.

[0132] For example, if a traditional database in non-volatile physical storage is used to store consensus message data, garbage collection of a large amount of early-stored consensus data would require accessing the database one by one to delete the consensus data that needs garbage collection, inevitably generating a large amount of I / O interactions. However, garbage collection of consensus message data can be completed directly through memory release, obviously eliminating the need for direct I / O interactions with the database, thus significantly improving the efficiency of garbage collection of consensus message data.

[0133] In one embodiment shown, after the target consensus message data that needs to be garbage collected is determined, it can be further determined whether the target consensus message data has been written back to the physical storage space in response to the determined target consensus message data. If the target consensus message data has been written back to the physical storage space, then in the garbage collection phase, in addition to releasing the virtual memory space occupied by the target consensus message data in the message data area, the target consensus message data stored in the physical storage space can also be deleted synchronously.

[0134] In one embodiment, when the consensus process needs to restore the state of the running consensus protocol, it can generate a state restoration instruction for that consensus protocol and send the instruction to the operating system of the consensus node. Upon receiving the state restoration instruction, the operating system of the consensus node can respond by directly reading the full amount of persistently stored consensus data from the aforementioned mapping area, and then performing state restoration processing on the consensus protocol based on the read consensus data.

[0135] It should be noted that, in practical applications, state restoration of consensus protocols typically includes the following specific scenarios:

[0136] In one scenario, state restoration of a consensus protocol can occur after the consensus process running the protocol restarts or the entire blockchain system restarts. In this scenario, when the consensus process running the protocol restarts or the entire blockchain system restarts, the full amount of persistently stored consensus data can be read from the aforementioned mapping area to perform state restoration on the consensus protocol.

[0137] In another scenario, state restoration of the consensus protocol can also occur when a consensus protocol encounters an anomaly and requires a state rollback. For example, if a blockchain system forks at a certain block, the system needs to roll back the consensus protocol running on the consensus nodes to the state of the block preceding that block. In this scenario, when a consensus protocol encounters an anomaly and requires a state rollback, the full amount of consensus data that has been persistently stored can be read from the aforementioned mapping area, and state restoration processing can be performed on the consensus protocol to restore its state to the state before the anomaly occurred.

[0138] In another scenario, state restoration of the consensus protocol can also occur after a device restart (e.g., a power outage followed by a restart) due to a malfunction in the node device corresponding to the consensus node. In this scenario, since the data stored in memory is lost after a device restart, it is necessary to re-establish the one-to-one mapping relationship between the virtual memory addresses in the aforementioned mapping region and the physical storage addresses in the aforementioned non-volatile physical storage space after the node device completes the restart. Then, all the consensus data stored in the aforementioned physical storage space is synchronized to the aforementioned mapping region for storage. Finally, all the consensus data is read from the aforementioned mapping region to perform state restoration processing on the consensus protocol.

[0139] In the above technical solution, by using memory mapping, a one-to-one mapping relationship is established between the virtual memory address in the reserved mapping area in the process address space of the consensus process and the physical storage address in the non-volatile physical storage space used for persistent storage of consensus data. This allows the consensus data generated by the consensus process during the execution of the consensus protocol to be stored in the memory space allocated to the consensus process. When the consensus process needs to access the persistent consensus data, it can directly read the consensus data from the memory space of the consensus process, without having to access the physical storage space through system I / O. This reduces the frequency of I / O access to the physical storage space by the consensus process, improves the efficiency of reading and writing consensus data, and helps to improve the execution efficiency of the consensus process when executing the consensus protocol.

[0140] For example, regarding the garbage collection and state recovery mentioned above, garbage collection may require deleting a large amount of early-stored consensus data, while state recovery often requires reading the full consensus data. Therefore, both garbage collection and state recovery typically require accessing a large amount of persistently stored consensus data. In this case, directly reading data from the database on disk would result in numerous and frequent interactions with the disk. Conversely, if the memory-mapped persistent storage scheme proposed in this specification is adopted, this consensus data can be accessed directly and quickly from memory, thereby significantly improving the read and write efficiency of consensus data.

[0141] In addition, the consensus process may also need to access persistently stored consensus data during the execution of the consensus protocol. For example, when the consensus protocol malfunctions, the consensus process needs to access all the consensus data in memory to restore the state of the consensus protocol. In this scenario, if the consensus process can quickly obtain the persistently stored consensus data by accessing memory, then the consensus process can obviously quickly restore the state of the consensus protocol after the malfunction occurs and continue to run the restored consensus protocol to complete the subsequent consensus processing flow, thereby significantly improving the execution efficiency when executing the consensus protocol.

[0142] Corresponding to the embodiments of the foregoing methods, this specification also provides embodiments of apparatus, electronic devices, and storage media.

[0143] Figure 5 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 5 At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, memory 508, and non-volatile memory 510, and may also include other necessary hardware. One or more embodiments of this specification can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into memory 508 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0144] like Figure 6 As shown, Figure 6 This is a block diagram illustrating a persistent storage device for consensus data according to an exemplary embodiment, which can be applied to, for example... Figure 5The illustrated electronic device is used to implement the technical solution of this specification. The device can be applied to any consensus node participating in consensus in a blockchain system. The process address space of the consensus process running on the consensus node includes a reserved mapping region. The virtual memory addresses in the mapping region establish a one-to-one mapping relationship with the physical storage addresses in the non-volatile physical storage space on the consensus node used for persistent storage of consensus data. The device 600 includes:

[0145] The acquisition module 601 acquires the consensus data generated by the consensus process during the execution of the consensus protocol.

[0146] Storage module 602 writes the consensus data into the mapping area for persistent storage;

[0147] The write-back module 603, in response to the consensus data being successfully written to the mapping area, determines the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area, and further writes the consensus data back to the physical storage space based on the physical storage address.

[0148] Accordingly, this specification also provides an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement all the steps in the previously described method flow.

[0149] Accordingly, this specification also provides a computer-readable storage medium having stored thereon executable computer program instructions; wherein, when executed by a processor, the instructions implement all the steps in the previously described method flow.

[0150] Accordingly, this specification also provides a computer program product having executable computer program instructions stored thereon; wherein, when the computer program instructions are executed by a processor, they implement all the steps in the previously described method flow.

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

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

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

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

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

[0156] 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

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

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

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

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

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

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

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

Claims

1. A method for persistent storage of consensus data, applied to any consensus node participating in consensus in a blockchain system, wherein, The process address space of the consensus process running on the consensus node includes a reserved mapping area; the virtual memory address in the mapping area establishes a one-to-one mapping relationship with the physical storage address in the non-volatile physical storage space of the consensus node used for persistent storage of consensus data. The method includes: Obtain the consensus data generated by the consensus process during the execution of the consensus protocol; The consensus data is written to the mapping area for persistent storage; In response to the consensus data being successfully written to the mapping area, a physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area is determined, and based on the physical storage address, the consensus data is further written back to the physical storage space.

2. The method as described in claim 1, wherein the physical storage space is the disk storage space corresponding to the disk mounted on the consensus node.

3. The method as described in claim 1, wherein the consensus data is persistently stored in the form of a file; and the mapping region is a file mapping region reserved in the process address space.

4. The method as described in claim 1, wherein the mapping region is a region reserved in the shared area of ​​the process address space.

5. The method of claim 1, wherein the consensus data includes consensus-related metadata; and consensus message data for consensus interaction with other consensus nodes; accordingly, the mapping area includes a first mapping area for storing the metadata and a second mapping area for storing the consensus message data.

6. The method of claim 5, wherein the consensus data is stored in the mapping area in the form of key-value pairs; wherein, The key in the key-value pair corresponding to the metadata is a fixed value; The first mapping region pre-stores at least the key in the key-value pair corresponding to the metadata; Writing the consensus data into the mapping area for persistent storage includes: If the consensus data contains key-value pairs corresponding to the metadata, starting from the starting address of the first mapping region, traverse the first mapping region and query the key in the key-value pairs corresponding to the metadata that are pre-stored in the first mapping region; If a key corresponding to the metadata is found in the first mapping area, the value corresponding to the found key is further modified based on the value in the key-value pair corresponding to the metadata, so that the key-value pair corresponding to the metadata is written to the first mapping area for persistent storage. If the consensus data contains key-value pairs corresponding to the consensus message data, starting from the starting address of the second mapping area, traverse the second mapping area to determine the tail address of the data already stored in the second mapping area, and use the storage location indicated by the tail address as the writing start position to write the key-value pairs corresponding to the consensus message data into the second mapping area for persistent storage.

7. The method of claim 6, further comprising: In response to a read instruction for target consensus data, the data type of the target consensus data is determined; If the target consensus data is the metadata, read the target consensus data from the first mapping area; If the target consensus data is the consensus message data, read the target consensus data from the second mapping area.

8. The method of claim 7, wherein the read instruction includes the key of the target consensus data; Determining the data type of the target consensus data includes: Determine whether the key of the target consensus data is a fixed value; If the key of the target consensus data is a fixed value, then the target consensus data is determined to be the metadata; If the key of the target consensus data is not a fixed value, then the target consensus data is determined to be the consensus message data.

9. The method of claim 8, wherein the read instruction includes the virtual memory address of the target consensus data in the mapping region; Determining the data type of the target consensus data includes: The virtual memory address is matched with the first virtual memory address range corresponding to the first mapping region and the second virtual memory address range corresponding to the second mapping region, respectively; If the virtual memory address matches the first virtual memory address range, then the target consensus data is determined to be the metadata; If the virtual memory address matches the second virtual memory address range, then the target consensus data is determined to be the consensus message data.

10. The method of claim 8, wherein reading the target consensus data from the first mapping region or the second mapping region comprises: The target consensus data is searched in the first mapping region or the second mapping region based on the key of the target consensus data.

11. The method of claim 5, further comprising: In response to a garbage collection instruction for the consensus message data, the second mapping region is traversed to determine the target consensus message data that needs to be garbage collected stored in the second mapping region. In response to the identification of target consensus message data that needs to be garbage collected, the virtual memory space occupied by the target consensus message data in the second mapping region is released.

12. The method of claim 11, wherein the garbage collection instruction includes a specified range of values ​​corresponding to the key of the target consensus message data that needs to be garbage collected; Traverse the second mapping region to determine the target consensus message data that needs to be garbage collected, including: Traverse the second mapping region, find consensus message data whose key values ​​stored in the second mapping region are within the range of the specified values, and determine the found consensus message data as the target consensus message data that needs to be garbage collected.

13. The method of claim 11, further comprising: In response to the identification of target consensus message data that needs to be garbage collected, it is further determined whether the target consensus message data has been written back to the physical storage space; If so, the target consensus message data stored in the physical storage space is deleted synchronously.

14. The method of claim 1, further comprising: In response to an instruction to restore the state of the consensus protocol running for the consensus process, the consensus data persistently stored in the mapping area is read, and the consensus protocol is restored based on the read consensus data.

15. A persistent storage device for consensus data, applied to any consensus node participating in consensus in a blockchain system, wherein, The process address space of the consensus process running on the consensus node includes a reserved mapping region; the virtual memory addresses in the mapping region establish a one-to-one mapping relationship with the physical storage addresses in the non-volatile physical storage space on the consensus node used for persistent storage of consensus data; the device includes: The acquisition module acquires the consensus data generated by the consensus process during the execution of the consensus protocol. The storage module writes the consensus data into the mapping area for persistent storage; The write-back module, in response to the successful writing of the consensus data to the mapping area, determines the physical storage address that has established a mapping relationship with the virtual memory address of the consensus data in the mapping area, and further writes the consensus data back to the physical storage space based on the physical storage address.

16. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 14.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of claims 1 to 14.

18. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method of any one of claims 1 to 14.

Images