Fine-grained encryption metadata protection method, device and equipment for persistent memory

Abstract

The application relates to a fine-grained encryption metadata protection method, device and equipment for persistent memory, and relates to the technical field of computer storage. In the process of fine-grained encryption of plaintext data in the persistent memory, in response to receiving a write request of metadata corresponding to the plaintext data, a versioned write-ahead log entry corresponding to the metadata is generated; the versioned write-ahead log entry is merged with a minimum consistency unit as a merging granularity to obtain a log micro-batch, and the minimum consistency unit comprises a child leaf node corresponding to a same cache line in the persistent memory and an associated parent leaf node; in response to successful execution of an atomic commit operation corresponding to the log micro-batch, a committed micro-transaction corresponding to the metadata is generated, and a stability voucher corresponding to the committed micro-transaction is generated; after system crash, recovery judgment and data repair processes are performed according to a daemon predicate in the versioned write-ahead log entry and the stability voucher to generate persistent metadata.

Description

Technical Field

[0001] This application relates to the field of computer storage technology, specifically to a method, apparatus, and device for fine-grained encrypted metadata protection for persistent memory. Background Technology

[0002] Persistent memory (PMem) combines DRAM-level access latency with non-volatile storage characteristics. High-frequency, fine-grained encryption operations on data in persistent memory generate massive amounts of complex metadata. The integrity, consistency, and recoverability of this metadata directly determine the reliability and security of the system.

[0003] In related technologies, changes are typically recorded in advance and then replayed after a system crash to restore the state; database systems generally use write-ahead log protocols to ensure that the corresponding redo and undo logs are persisted before data pages are modified.

[0004] However, when this protection framework is directly used in scenarios involving fine-grained encrypted metadata protection for persistent memory, it is prone to causing metadata parent-child tearing due to write granularity mismatch, resulting in structural atomicity loss. Summary of the Invention

[0005] In view of this, this application provides a fine-grained encrypted metadata protection method, apparatus and device for persistent memory, the main purpose of which is to solve the technical problem that related technologies are prone to metadata parent-child tearing and structural atomicity loss.

[0006] According to a first aspect of this application, a fine-grained cryptographic metadata protection method for persistent memory is provided, the method comprising:

[0007] During the fine-grained encryption of plaintext data in persistent memory, in response to the received write request for the metadata corresponding to the plaintext data, a versioned pre-write log entry corresponding to the metadata is generated.

[0008] The versioned pre-write log entries are merged using the smallest consistency unit as the granularity to obtain log micro-batches. The smallest consistency unit includes the leaf nodes corresponding to the same cache line in persistent memory and their associated parent leaf nodes.

[0009] In response to the successful execution of the atomic commit operation corresponding to the log micro-batch, a committed micro-transaction corresponding to the metadata is generated, and a stability certificate corresponding to the committed micro-transaction is generated.

[0010] After a system crash, based on the guardian predicates and stability credentials in the versioned pre-write log entries, a recovery determination and data repair process is executed to generate persistent metadata.

[0011] According to a second aspect of this application, a fine-grained cryptographic metadata protection device for persistent memory is provided, the device comprising:

[0012] The receiving module is used to generate versioned pre-write log entries corresponding to the received metadata in response to a write request for the received metadata during the fine-grained encryption of plaintext data in persistent memory.

[0013] The merging module is used to merge versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain log micro-batches. The smallest consistency unit includes the leaf nodes corresponding to the same cache line in persistent memory and their associated parent leaf nodes.

[0014] The generation module is used to generate the committed microtransaction corresponding to the metadata and the stability certificate corresponding to the committed microtransaction in response to the successful execution of the atomic commit operation corresponding to the log micro-batch.

[0015] The recovery module is used to perform recovery determination and data repair processes based on the guardian predicates and stability credentials in the versioned pre-write log entries after a system crash, and to generate persistent metadata.

[0016] According to a third aspect of this application, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of the first aspect described above.

[0017] According to a fourth aspect of this application, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method of the first aspect described above.

[0018] The fine-grained encrypted metadata protection method, apparatus, and device for persistent memory provided in this application, compared with related technologies, in the process of fine-grained encryption of plaintext data in persistent memory, in response to receiving a write request for the metadata corresponding to the plaintext data, generates a versioned pre-write log entry corresponding to the metadata; merges the versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain log micro-batches, the smallest consistency unit including the leaf nodes corresponding to the same cache line in persistent memory and their associated parent leaf nodes; in response to the successful execution of the atomic commit operation corresponding to the log micro-batches, generates the committed micro-transaction corresponding to the metadata, and generates the stability certificate corresponding to the committed micro-transaction; after the system crashes, according to the guardian predicate and stability certificate in the versioned pre-write log entries, performs a recovery determination and data repair process, and generates persistent metadata. In this way, before executing the write operation corresponding to the write request, this application can create a versioned pre-write log entry for the metadata corresponding to the write request, and integrate the versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain a log micro-batch. Logically, the leaf nodes and their parent leaf nodes in the same cache line are bound into an indivisible atomic operation unit. After the atomic commit operation corresponding to the log micro-batch is successfully executed, a committed micro-transaction and its stability certificate are generated. In the event of a system crash, the guardian predicate in the versioned pre-write log entry is used to perform metadata consistency verification, which solves the parent-child tearing problem in the metadata update process and ensures the consistency of persistent metadata after the repair is completed. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a fine-grained encrypted metadata protection method for persistent memory provided in an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of a fine-grained encrypted metadata protection device for persistent memory, provided in an embodiment of this application. Detailed Implementation

[0023] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0024] Specifically, the basic unit of writing to persistent memory is the cache line, while encrypted metadata often involves cascading update dependencies between leaf nodes and parent leaf nodes. A small encryption operation may require updating the leaf counter and parent checksum located in different cache lines. If the system crashes between two persistence operations, it can easily result in a dangling state where the parent leaf node has been updated, but the data of the leaf nodes it verifies is still the old value. This inconsistent data will pollute upwards along the tree structure, leading to widespread data unavailability. Currently, write-ahead logs mainly record the physical mirror of the data, such as a value changing from A to B, which is mechanically replayed during recovery. However, in fine-grained encryption scenarios, consistency is more of a logical contract, such as the key version must advance unidirectionally and the counter must increment continuously. Existing logs cannot effectively encapsulate and verify such logical predicates, leaving hidden dangers for security vulnerabilities such as version rollback attacks, and during recovery, it is impossible to confirm whether the transaction has achieved the expected logical state, reducing the robustness of the system.

[0025] It is understood that the fine-grained cryptographic metadata protection method for persistent memory can be implemented by a computing device, which includes at least a processor and memory. The memory stores a computer program, and the processor is configured to execute the computer program to implement the fine-grained cryptographic metadata protection method for persistent memory. The memory includes at least persistent memory. This application addresses the protection of metadata consistency when performing fine-grained encryption operations on persistent memory.

[0026] The following description, with reference to the accompanying drawings, describes a method, apparatus, and device for fine-grained encrypted metadata protection for persistent memory according to embodiments of this application.

[0027] This application provides a fine-grained encrypted metadata protection method, apparatus, and device for persistent memory, with the main purpose of solving the technical problem that related technologies are prone to metadata parent-child tearing and structural atomicity loss.

[0028] like Figure 1 As shown, embodiments of this application provide a fine-grained encrypted metadata protection method for persistent memory, including:

[0029] Step 101: During the fine-grained encryption of plaintext data in persistent memory, in response to the received write request for the metadata corresponding to the plaintext data, a versioned pre-write log entry corresponding to the metadata is generated.

[0030] The versioned pre-write log entries (WAL, wal_record) can describe the local consistency conditions of metadata based on guardian predicates. The guardian predicates can be predicate logic that verifies the consistency of metadata before and after the write operation, and can include pre-guard guardian predicates, post-guard guardian predicates, etc. Correspondingly, consistency can be the metadata consistency judged from logical, physical, version, data relationship, security and other levels.

[0031] In some embodiments, the system can create a versioned pre-write log entry for the metadata corresponding to a write request before executing the write operation. This versioned pre-write log entry is a versioned log entry associated with the system's version domain. It is generated before the write operation corresponding to the write request and embeds a guard predicate to formally describe the consistency state that the metadata must satisfy before and after the write operation. It can be bound to attributes such as metadata version number, transaction version identifier, and version domain ownership information. By generating versioned pre-write log entries before the write operation, the system does not immediately execute the write operation to write the metadata to the target location in persistent memory when it receives a write request. Furthermore, by recording the guard predicate instead of just the data itself, it provides a higher-dimensional verification basis for subsequent data recovery, ensuring the atomicity and recoverability of the write operation.

[0032] Step 102: Merge the pre-versioned log entries using the smallest consistency unit as the merging granularity to obtain log micro-batches.

[0033] In some embodiments, versioned pre-write log entries of the same minimum consistency unit can be aggregated into a log micro-batch (such as rank2_batch) to facilitate the execution of an atomic commit operation on the entire log micro-batch, ensuring the consistency of the execution results of multiple write operations within the batch, without the need to commit each write operation separately, thereby improving system storage efficiency.

[0034] The minimum consistency unit is the leaf node corresponding to the same cache line in persistent memory and its associated parent leaf node. The minimum consistency unit can be a second-level consistency (rank-2) unit or a third-level consistency (rank-3) unit. By defining the minimum consistency unit, the leaf node (corresponding to leaf metadata) and its parent leaf node (corresponding to parent leaf metadata) are logically bound into an indivisible atomic operation unit. Any modification to this unit either succeeds completely or does not occur at all, thus directly preventing the most fatal parent-child tearing problem in metadata updates. To physically guarantee this atomicity, a strict child-first, parent-later persistence write order is enforced, that is, the ciphertext data and counter line of the leaf node are persisted first, and the parent leaf node is persisted last. This ensures that in the event of a crash, the system will never enter an inconsistent state where the parent has been updated but the child has not, making the system state always recoverable.

[0035] Specifically, a seemingly simple encrypted data write operation often triggers a series of chained metadata updates. For example, updating a version counter will cause the integrity check value of its parent leaf node to be updated accordingly. In persistent memory with cache lines as the basic write granularity, if these scattered metadata updates cannot be executed atomically, an unexpected system crash may leave it stuck in an inconsistent state where the child leaf node has been updated but the parent leaf node has not. To solve this problem, this embodiment proposes the logical concept of the minimum consistency unit, which is not a physically contiguous memory region, but a logically indivisible update atom.

[0036] For example, a rank-2 unit can consist of two hierarchical elements:

[0037] (1) Rank-1 (leaf layer): A whole cache line in persistent memory. This cache line can contain at least one leaf node corresponding to encrypted data, as well as leaf metadata closely associated with the leaf node, such as counter lines;

[0038] (2) Rank-2 (parent leaf): In the data integrity tree structure, the parent leaf node that uniquely covers all child leaf nodes in Rank-1.

[0039] Specifically, when multiple versioned pre-write log entries are awaiting commit, the system parses the target address of each entry and identifies its rank-2 unit. All versioned pre-write log entries belonging to the same rank-2 unit are automatically aggregated into a rank2_batch, providing a logically clear and well-defined processing object for the disjunctive normal form (DNF) compression and atomic predicate fence (APF, apf_record) commit operations described later.

[0040] Correspondingly, in a tree structure with a deeper hierarchy, a rank-3 unit can be defined, which is the leaf node of the same cache line, its parent leaf node, and its grandparent node, to deal with more complex cascading update scenarios.

[0041] In this way, a predetermined number of versioned pre-write log entries for the same minimum consistency unit are aggregated into log micro-batches for subsequent atomic commit operations, efficiently grouping write operations.

[0042] Step 103: In response to the successful execution of the atomic commit operation corresponding to the log micro-batch, generate the committed micro-transaction corresponding to the metadata and generate the stability certificate corresponding to the committed micro-transaction.

[0043] Among them, the stability proof (stable_proof_entry) can be used to recover and verify metadata. As a compact and efficiently verifiable proof of the stability of committed transactions, it can prove that at a certain point in time, a certain batch of data has been safely and consistently written to disk.

[0044] Specifically, after a log micro-batch is successfully committed, the write operations associated with that log micro-batch can form a logically indivisible committed micro-transaction, and the system will generate a corresponding stability certificate for it. The stability certificate may include key summary information of the committed micro-transaction, such as the leaf node summary within the batch, the local commitment of the parent-child relationship, etc.

[0045] Step 104: After the system crashes, based on the guardian predicates and stability credentials in the versioned pre-write log entries, execute the recovery determination and data repair process to generate persistent metadata.

[0046] Specifically, when the system crashes unexpectedly, such as due to a power outage, a recovery determination and data repair process can be initiated based on versioned pre-write log entries and stability credentials. For example, the stability credentials can be checked through the recovery manager. If the stability credentials corresponding to a committed microtransaction are complete and valid, the committed microtransaction can be directly determined to be stable without replaying all its corresponding log entries. If the stability credentials corresponding to a committed microtransaction are missing or incomplete, the versioned pre-write log entries corresponding to the committed microtransaction can be consulted through the recovery manager, and the recorded guardian predicates can be used to determine if it is a recovery operation for that transaction, such as redo or undo. By using versioned pre-write log entries and stability credentials in combination, the recovery process is accelerated, and after repair, all persistent metadata can be kept in a completely consistent state, effectively preventing metadata write tearing, enhancing the logical safety of transactions, and achieving near-instantaneous crash recovery.

[0047] Compared with related technologies, this embodiment can create versioned pre-write log entries for the metadata corresponding to the write request before executing the write operation corresponding to the write request, and integrate the versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain log micro-batches. Logically, the leaf nodes and their parent leaf nodes in the same cache line are bound into an indivisible atomic operation unit. After the atomic commit operation corresponding to the log micro-batch is successfully executed, the committed micro-transaction and its stability certificate are generated. In the event of a system crash, the guardian predicate in the versioned pre-write log entries is used to perform metadata consistency verification, which solves the parent-child tearing problem in the metadata update process and ensures the consistency of persistent metadata after the repair is completed.

[0048] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the implementation of this embodiment, optionally, to ensure the persistence and orderliness of data writing, a preferred persistence primitive sequence, such as an atomic operation sequence, can be preset and followed by each related step. Specifically, for any target object that needs to be persisted, such as wal_record, encrypted data, etc., the atomic operation sequence can be followed: append → clwb → sfence. Here, append refers to writing the data of the target object to the target address of persistent memory; clwb (Cache Line Write Back) is a processor instruction used to write the cache line data containing the target object back to the persistent memory controller, but not immediately evict the cache line from the cache; sfence (Store Fence) is a memory fence instruction used to ensure that all write operations before this instruction must be globally visible before any storage operation after the execution of this instruction, thereby ensuring the orderliness of write operations. By strictly executing the atomic operation sequence, the consistent write order between target objects can be guaranteed to be reproducible, providing a deterministic basis for crash recovery.

[0049] Optionally, the method in this embodiment may further include: when the system starts up, obtaining the consistent state signature corresponding to the metadata saved at the last shutdown in persistent memory, and recalculating the real-time state signature according to the current system parameters; and determining the initial state of the system based on the comparison result between the consistent state signature and the real-time state signature.

[0050] Specifically, to ensure the system is in a known and consistent state at startup, a consistency check is performed before executing any specific process described in this application. For example, the processor reads the consistent state signature saved at the time of the last normal shutdown from the persistent metadata page. This consistent state signature can be calculated based on key state metadata such as the stable epoch ID, root integrity version, and key version at the time of the last shutdown. The processor recalculates the real-time state signature using the same parameters and signature algorithm and compares it with the stored consistent state signature. Only when two signatures are completely identical is the comparison result of the two signatures determined to be a successful verification, and the initial state of the system can be confirmed to be valid, and the version context in memory can be constructed based on this. If the comparison result of the two signatures is a verification failure, or if boundary conditions are encountered during processing, such as the dataset to be processed being an empty set, or a version number being out of bounds, the system can adopt a preset rollback strategy. For example, the system can roll back to the most recently confirmed stable version number and use the default mapping seed version (seed_version) to initialize the relevant data structures, thereby reducing the divergence that abnormal paths may cause and enhancing the robustness of the system.

[0051] Optionally, security constraints can be preset during read path processing. These constraints can be immutable and enforceable, such as requiring at least one integrity verification for any read path. During data reading, such as reading stable versions of data or retrieving the latest version of data that has already been posted (billed) from the pre-write log, integrity verification can be performed using methods like MAC verification and CRC verification. This ensures that any data returned to the upper-layer application is complete and untampered, preventing data corruption due to hardware errors or malicious attacks.

[0052] Optionally, versioned pre-write log entries corresponding to the metadata are generated, which may include: obtaining a version snapshot of the counter row and the parent leaf node at the target address of the plaintext data in persistent memory; constructing a pre-guard predicate corresponding to the metadata based on the version snapshot of the counter row and the parent leaf node, the pre-guard predicate including a local consistency assertion corresponding to the current state of the metadata, used to determine the consistency of the metadata before the write operation is executed; and generating versioned pre-write log entries based on the pre-guard predicate and pre-stored version advancement evidence, the version advancement evidence being used to force unidirectional version advancement.

[0053] The write request can carry the plaintext data to be written and the target address corresponding to the plaintext data; the counter line can refer to the metadata associated with at least one encrypted data cache line, which can include version number, update count, etc., to prevent replay attacks; the parent leaf node can be the node above the counter line in a tree structure (such as a Merkle tree) that maintains data integrity, and the parent leaf node version snapshot can be specifically represented as the message authentication code MAC value or hash value.

[0054] For example, when the system receives a write request, it performs a pre-state sampling operation, forming a pre-guard predicate. The sampling operation can be as follows: the processor precisely reads the current counter version snapshot (snapshot_cv) corresponding to a specific target address, and the parent version snapshot (snapshot_pv) corresponding to the parent leaf node to which the counter row belongs, as the expected version snapshot corresponding to the metadata. This sampling method freezes the instantaneous state before the write operation, providing a factual basis for subsequently building consistency conditions. The pre-guard predicate can be a Boolean expression used to assert the preconditions that must be met to perform the write operation.

[0055] For example, the preguard predicate (pre_guard) can be a logical AND expression, which can be represented as:

[0056] pre_guard = (current_cv == snapshot_cv) AND (current_pv == snapshot_pv);

[0057] In the formula, `current_cv` is the snapshot of the counter row version actually read at a future time (such as during commit or recovery), and `current_pv` is the snapshot of the parent leaf node version actually read at that time. The meaning of this predicate is: only when the current state of the target metadata is completely consistent with that at the time of sampling is the subsequent write operation safe and effective. This transforms the pre-predicate into a data structure that encapsulates the expected version snapshot, making the versioned pre-write log entry record logical contract, which can be understood as a precondition. During the system recovery process, logical consistency can be verified, rather than simply blindly rolling back physical data, thus enhancing the robustness of system recovery.

[0058] Optionally, the composition of the preceding guardian predicate can also be adjusted according to security requirements. For example, if performance overhead is the primary consideration, the preceding guardian predicate can only include the counter row version snapshot, omitting the parent leaf node version snapshot, thereby reducing one persistent memory read, but slightly reducing the strength of the consistency guarantee; in scenarios requiring the highest security, the preceding guardian predicate can also include the grandparent leaf node version snapshot, forming a stronger constraint.

[0059] Optionally, after constructing the pre-guard predicate, version advancement evidence can be generated. Version advancement evidence ensures that the encryption key version and related seed version in the system can only evolve in one direction and cannot be maliciously rolled back.

[0060] Furthermore, generating evidence for version advancement may specifically include the following steps:

[0061] (1) A one-way forward security chain is established based on the key version; the system can maintain the key version. When it is necessary to rotate the key, the new key version (key_versionn+1) can be generated by applying a fixed, collision-resistant one-way hash function H to the current key version (key_versionn), such as key_versionn+1 = H(key_versionn). Due to the one-way nature of the hash function, key_versionn cannot be deduced in reverse from key_versionn+1, so the chain of hash values ​​can be used as the forward security chain. When generating version advancement evidence, the system can use the currently valid key_versionn as part of the evidence, which can be called the forward security anchor point;

[0062] The implementation of the forward security chain can vary. For example, a one-time signature scheme based on digital signatures can be used, where each version is signed with the private key of the previous version, forming a verifiable and irreversible chain.

[0063] (2) Set seed drift limits for the seed version to constrain its range of variation and time window; the system can also maintain the seed version for other cryptography-related purposes, such as the generation of initialization vectors. In order to prevent the seed version from being tampered with without restriction, a seed drift limit can be preset to quantify the constraints on the changes of the seed version. For example, the seed drift limit can be specified as follows: within the current working version cycle, the total value change of the seed version does not exceed the preset maximum increment, and the time interval between two changes is not less than the minimum time window;

[0064] (3) Integrate the forward security chain and seed drift restriction to generate version progress evidence; the version progress evidence can be constructed into a data structure containing forward security anchors and currently effective seed drift restriction rules. In subsequent atomic commits and crash recovery processes, the system can enforce the verification of version progress evidence, so that operations that attempt to write to old versions or violate seed drift restrictions are rejected, effectively blocking the window for version rollback attacks.

[0065] Optionally, versioned pre-write log entries may include at least one of the following: an address range derived from the write request, a tree hint, and a counter increment hint. The address range explicitly records the persistent memory address range affected by the write operation. The tree hint can be a pointer or index directly pointing to the parent leaf node, used to accelerate the location of relevant metadata during recovery, avoiding traversal lookups. The counter increment hint can be used to indicate the expected change in the counter line version number, such as +1. This simplifies the calculation process of the post-guard predicate.

[0066] By using the above methods, the requirement for metadata consistency is elevated from physical data to a logical contract, and an unforgeable proof is provided for version timing security.

[0067] Optionally, the method also includes: constructing a post-guard predicate corresponding to the metadata, wherein the post-guard predicate includes a local consistency assertion corresponding to the target state of the metadata, which is used to determine the consistency of the metadata after the write operation is executed.

[0068] Specifically, for each versioned pre-write log entry, the system derives a corresponding post-write guardian predicate based on its pre-write guardian predicate and the write operation content (such as counter increment). The post-write guardian predicate is structurally similar to the pre-write guardian predicate and is used to assert the target state that must be achieved after the write operation is completed. For example, `pre_guard` can be used to assert that before executing this write operation, the counter version associated with the target address must be V. Correspondingly, the post-write guardian predicate (`post_guard`) can be used to assert that after completing this write operation, the counter version must be V+1, and the checksum of the parent leaf node of the metadata corresponding to the write operation should be a preset value, such as H'.

[0069] Optionally, before step 103, the method of this embodiment may further include: integrating the post-guard predicates in the versioned pre-write log entries belonging to the same parent leaf node based on the disjunction normal form, obtaining the final guardian digest corresponding to the metadata, the final guardian digest being used to verify the overall consistency of the metadata corresponding to the log micro-batch when performing the atomic commit operation corresponding to the log micro-batch; constructing an atomic predicate fence, the atomic predicate fence being used to encapsulate the final guardian digest and version progress evidence, serving as a dual verification point for metadata consistency and version security when recovering data after a system crash; and persisting the atomic predicate fence to persistent memory before marking the committed micro-transaction according to the set commit bit.

[0070] In some embodiments, post-guard predicates describing the post-write consistency state contained in a predetermined number of versioned pre-write log entries belonging to the same parent leaf node can be aggregated. For example, if a pre-guard predicate of a versioned pre-write log entry requires that the counter version counter_version == V, and the write operation increments the counter by 1, then its corresponding pre-guard predicate is the logical assertion that the counter version counter_version == V+1.

[0071] Correspondingly, the atomic commit operation is not performed on a single versioned pre-write log entry, but rather on a group of versioned pre-write log entries within a log micro-batch. Before executing the atomic commit operation, the system iterates through all versioned pre-write log entries within the log micro-batch and aggregates their respective post-guard predicates, forming a set of post-guard predicates (Set_PG). Then, the disjunctive normal form is applied to condense a predetermined number of post-guard predicates into a single final guard digest for use by the atomic commit operation. This addresses the problem that Set_PG may contain a large amount of redundant information, leading to high persistence overhead and complex recovery verification.

[0072] Optionally, based on the disjunction paradigm, the post-guard predicates in the versioned pre-write log entries belonging to the same parent leaf node are integrated to obtain the final guardian summary corresponding to the metadata. Specifically, this may include: classifying the post-guard predicates into security predicates corresponding to system verifiability indicators and performance predicates corresponding to system performance indicators according to the semantic rules and application requirements corresponding to the disjunction paradigm; aggregating the security predicates and performance predicates respectively based on different processing strategies, and generating the final guardian summary based on the final aggregation state obtained by aggregation.

[0073] Among them, the disjunctive paradigm can be a predicate folding algorithm that preserves all security constraints while maximizing the compression ratio.

[0074] For example, the post-guard predicates in Set_PG can be color-coded to distinguish between security predicates and performance predicates. Security predicates are typically directly related to data integrity, consistency, or decryptability, affecting system verifiability. If their asserted state is not met, it means the data is corrupted or in an inconsistent state. System verifiability metrics may include counter line version numbers, parent leaf node message authentication code (MAC) values, and CRC checksums of encrypted data. Performance predicates are only related to system performance monitoring, cache management, or statistical metrics, affecting only system performance. Deviations in their state do not affect the correctness of core data. System performance metrics may include access frequency counts for a data block and cache hit rate statistics.

[0075] Optionally, the classification rules for post-guard predicates can be dynamically configured according to application requirements. For example, in scenarios with extremely high performance requirements, some metadata that is usually regarded as security predicates (such as integrity checks on non-critical paths) can be downgraded to performance predicates in exchange for faster commit speeds.

[0076] Optionally, the system employs different strategies to handle different types of post-guard predicates. For security predicates, since the accuracy of their state is crucial, algebraic elimination is usually not performed. Instead, the expected values ​​of all security predicates within the log micro-batch (such as all updated counter versions and parent leaf node MAC values) can be deterministically serialized, and the cryptographic hash value of the serialized byte string, such as SHA-256, can be calculated.

[0077] Correspondingly, since performance predicates are typically additive or merging, algebraic elimination can be performed only on the performance predicates to minimize the complexity of the final guardian digest while preserving all security constraints. For example, if a log micro-batch contains two write operations, generating two performance predicates: perfp1 = (access_freq == F+1) and perfp2 = (access_freq == F+2), then these two can be algebraically merged into a single predicate about the increment: perf_p_delta = (access_freq_delta == +2), thereby reducing the amount of information that needs to be recorded, where access_freq is the access frequency, access_freq_delta is the access frequency increment, and F is the baseline value of the current access frequency.

[0078] Specifically, when performing algebraic elimination on performance predicates, the system first identifies the semantic type of the performance predicate and associates it with a corresponding opcode. For example, OpCode=OP_INC indicates an incremental update, and OpCode=OP_SET indicates setting a new value. During integration, the system traverses all performance predicates within the log micro-batch that belong to the same parent leaf node and target the same performance metadata (such as access frequency counters at the same address). During the traversal, a temporary aggregation state is maintained. When a performance predicate of type OP_INC is encountered, its incremental value is added to the incremental accumulator of the temporary aggregation state; when a performance predicate of type OP_SET is encountered, its new value overwrites the temporary aggregation state, and the incremental accumulator is cleared. After the traversal is completed, the final aggregation state (such as the final value or total increment) is obtained, which is used to generate the final guardian digest. This allows multiple discrete performance metadata update operations to be losslessly merged into an equivalent, single update operation, achieving efficient algebraic elimination.

[0079] Optionally, the algorithm for generating the final guardian digest can differ. For example, a small Merkle tree can be constructed, where the leaf nodes are hashes of the individual security predicates, and the final guardian digest is the root hash of that tree, providing a more fine-grained proof of partial correctness during system recovery.

[0080] Through the elimination and hash folding processes described above, the complex Set_PG can be condensed into a final guardian digest of fixed size and extremely high information entropy. This digest is logically equivalent to the logical AND set of all predicates in the batch in a compact form.

[0081] In some embodiments, the system may construct a dedicated log record as an atomic predicate fence, which may be in the form of a structure. Its core fields may include: the final guardian summary corresponding to the log micro-batch and the version progress evidence, which become a dual verification point after the atomic predicate fence is persisted, describing the precise protocol for performing atomic commit operations using the final guardian summary.

[0082] During system crash recovery, the recovery manager can be used to read atomic predicate fences and perform two orthogonal verifications simultaneously:

[0083] (1) Data consistency verification: Calculate the real-time summary of the relevant metadata in the current persistent region and compare it with the final guardian summary in the atomic predicate fence to determine whether the target state of all data in the batch is correct;

[0084] (2) Version security verification: By checking the version progress evidence in the atomic predicate fence, it is determined whether the atomic commit operation complies with the system version evolution rules to prevent version rollback attacks.

[0085] For example, to ensure the atomicity of atomic commit operations, the persistence process can follow a strict sequence: write the incremental normalization block containing the final guardian summary and the atomic predicate fence to the log area of ​​persistent memory; execute a persistence primitive sequence (such as clwb + sfence) to ensure the atomic predicate fence is completely written to disk; only after this, set a flag bit, such as the commit bit, at a certain location in the persistence area to mark the committed microtransaction; execute the persistence primitive sequence again to ensure that the change of the commit bit is also completely written to disk. This ensures that the system state is clear at any time in the event of a crash. For example, if the commit bit is not set, even if the atomic predicate fence exists, the microtransaction is considered incomplete and can be safely rolled back; if the commit bit is set, the transaction is considered complete and requires roll-forward or verification.

[0086] This method enables the construction and submission of atomic predicate fences. By using atomic predicate fences, the final guardian summary used to verify data consistency and the version progress evidence used to verify version security are jointly encapsulated, providing dual verification points of data and logic during crash recovery, thereby achieving fine-grained and provable protection of transaction logic consistency.

[0087] Optionally, after obtaining the log micro-batch, the process may further include: generating a parent-before-image commitment corresponding to the parent leaf node based on the real-time status of the parent leaf node associated with the log micro-batch and the leaf update summary of the child leaf node in the log micro-batch. The parent-before-image commitment is used to verify the integrity of the parent-child data relationship within the log micro-batch during system crash recovery; and recording anti-tear margin in the parent leaf node associated with the log micro-batch. The anti-tear margin is used to characterize the number of child leaf nodes within the log micro-batch that have not yet been persisted, so as to provide a rollback boundary for incompletely written log micro-batches during system crash recovery.

[0088] In some embodiments, parent preimage commitment allows the system to make verifiable assertions about the future state of parent leaf nodes in advance without actually performing expensive recalculation of parent leaf nodes. The generation process is as follows: The system obtains the MAC value (MAC_parent_current) of the parent leaf node associated with the rank2_batch before the update, and generates a child update summary (summary_child_updates) for all child leaf nodes to be updated in the batch. This summary is such as a serialized concatenation / encrypted hash of the MAC values ​​or version numbers of all updated child leaves in the batch, to improve efficiency. For example, parent preimage commitment (parent_preimage_commit) can be calculated using the following formula:

[0089] parent_preimage_commit= H(MAC_parent_current || summary_child_updates);

[0090] In the formula, H is a cryptographic hash function, and || represents byte string concatenation.

[0091] This approach uses the parent-previous-image commitment to bind the parent leaf node's previous image (i.e., the state before the update) to the child leaf node's increment (i.e., the update content within the batch). During crash recovery, the recovery manager only needs to read MAC_parent_current from persistent memory and summary_child_updates from WAL to recalculate the parent-previous-image commitment without accessing any child leaf data and compare it with the value recorded in the log. This achieves efficient verification of the integrity of the parent-child data relationship and is an important foundation for subsequent implementation of constant-time (O(1)) recovery.

[0092] For parent-image commitments, to enhance security, a keyed hash message authentication code can be used instead of a regular hash function H to prevent forgery attacks targeting the commitment itself.

[0093] Specifically, the tear prevention margin can be an integer field written to the metadata area corresponding to the parent leaf node. When a rank2_batch containing N leaf updates begins to be persisted, the tear prevention margin can be N; each time an update of a leaf (including its data and counter rows) is successfully persisted to PMem, the tear prevention margin can be atomically decremented by 1; when all updates in the entire rank2_batch are completed, the tear prevention margin is 0. During system recovery, if the tear prevention margin of a parent leaf node is found to be greater than 0, such as K, it indicates that the batch write was interrupted. The recovery manager can confirm that K leaf updates were incomplete, and the NK completed leaf updates need to be rolled back, thus providing a precise rollback boundary for incomplete writes.

[0094] Optionally, bitmaps can be used to calculate anti-tear margins. For example, if a cache line contains 64 leaves, a 64-bit integer can be used as a bitmap. Each time a leaf is persisted, its corresponding bit in the bitmap is set to 1 to indicate that a leaf has been completed, thus providing more granular recovery information.

[0095] By introducing parent-previous image commitments and anti-tear margins, the verifiability and recovery accuracy of log micro-batches during crash recovery are enhanced.

[0096] Furthermore, to physically guarantee the atomicity of the rank-2 unit, all write operations must follow a child-to-parent persistence write order. For example, when updating the encrypted data constituting the rank2_batch and its metadata in persistent memory, the following dependency order must be followed:

[0097] (1) Persist the ciphertext data associated with any leaf node (ciphertext_line);

[0098] (2) Update the counter line corresponding to the persistent leaf node;

[0099] (3) The persistent leaf node and the parent leaf node to which the counter row belong are updated if and only if all related leaf node updates are completed.

[0100] This child-first-then-parent persistent write order ensures that the system state is either not yet started (the parent leaf node still points to the old, consistent child leaf node) or the update is complete. At any time of crash, it can avoid the inconsistent state where the parent leaf node has been updated but its child leaf data or counter is not ready. This ensures atomicity at the physical level and eliminates the generation of inconsistent states.

[0101] Optionally, generating stability credentials corresponding to committed microtransactions may include: generating credential fragments corresponding to committed microtransactions, whereby the credential fragments are used to encapsulate the batch self-verification information of committed microtransactions and to independently verify committed microtransactions; assembling the credential fragments corresponding to committed microtransactions into a constant-time complexity credential header; generating stability credentials based on the constant-time complexity credential header; and using the constant-time complexity credential header to determine the stability of constant-time complexity during system crash recovery.

[0102] In some embodiments, the system generates a corresponding stable shard for each successfully committed rank2_batch, i.e., a committed micro-transaction, to achieve modularity and self-containment of the shard. The internal consistency of the corresponding rank2_batch can be verified based on the shard and its corresponding small amount of log information, without having to trace the historical state of the entire system. This enables the shard to independently verify the committed micro-transaction.

[0103] For example, the self-verifying information within a batch may include, but is not limited to: micro-batch identifier (batch_id), parent previous image commitment, final guardian digest, leaf node digest within the batch, and stitching boundary information (stitching_boundary_info); among which, the leaf node digest within the batch is the digest value calculated from the new state of all modified leaf nodes within the batch, such as the hash of all new MAC values; stitching_boundary_info is the key to realizing the stitchable feature. This field records the logical position of the batch in the relevant data stream, such as: WAL sequence number range, the highest consecutive sequence number of the monotonic ticket ledger snapshot (mtl_snapshot) covered in the device write-through scenario.

[0104] In a device-to-device write scenario, the device generates a co-signed working ticket (wct) based on the write request. The host receives the co-signed working ticket and performs echo reconciliation. The device can be a SmartNIC, a storage controller supporting RDMA, an FPGA accelerator card, etc. When the device needs to write data directly to the host's persistent memory, it generates a co-signed working ticket (wct). Co-generational consistency is the foundation for ensuring cross-source consistency, requiring the device's write operation to be aligned with the host's logical version. Co-signing represents the responsibility and credentials of both parties. Specifically, before initiating a write operation, the device obtains the currently used working version number (working_epoch_id) from the host. For example, wct may include:

[0105] Version number (epoch): The working version number obtained from the host;

[0106] Serial number (seq): A serial number maintained by the device itself and guaranteed to increase monotonically;

[0107] Message Authentication Code (mac_wct): A MAC value calculated using a symmetric key shared only by the host and device within the current version number, based on ticket content such as the version number and serial number.

[0108] After completing its data write operation, the device atomically appends the co-signed ticket to the dedicated log area wct_log in the host's persistent memory. The device then sends a compact digest of the co-signed ticket, such as the seq number and mac_wct, to the host CPU via the control link as a notification that the write operation is complete.

[0109] Optionally, after receiving the compact digest sent by the device, the host CPU can execute the Host Echo Reconciliation (HER) protocol; based on the result of the echo reconciliation, update the monotonic bill ledger snapshot and establish a verifiable cross-source contemporary evidence chain.

[0110] Specifically, the host records a compact summary in its proprietary log, indicating that the host is aware of the operation on the device side. Reconciliation is a periodic or event-triggered checking process. The host-side software scans the proprietary log area written by the device and its own proprietary log. By comparing serial numbers, the host can establish a correspondence between co-signed tickets and compact summaries, and check for serial number jumps or missing information, thereby detecting anomalies such as the device having written the information but the host not receiving notification (lost message) or the host receiving duplicate notifications.

[0111] Accordingly, after successful reconciliation, to avoid having to repeat the reconciliation process during future recovery, the system condenses the reconciliation results into an extremely compact monotonic invoice ledger snapshot. For example, the monotonic invoice ledger snapshot can be a very small data structure that records: the highest consecutive sequence number, the highest consecutive, uninterrupted, co-signed invoice sequence number confirmed through reconciliation; and the highest invoice authentication code, the message authentication code value of the invoice corresponding to the highest consecutive sequence number. The monotonic invoice ledger snapshot is atomically updated and persisted, providing the system with a checkpoint on the progress of the device write-through path that can be verified in O(1) complexity.

[0112] Optionally, the generation of co-signed tickets can include richer contextual information, such as a summary of the written data range, to provide stronger binding. Reconciliation protocols can also be more complex, for example, by introducing retransmission requests and timeout mechanisms to address unreliable control links. Furthermore, in scenarios with multiple write-through devices, vector clocks can be used instead of monotonic sequence numbers to correctly handle the partial order relationships of events from different devices.

[0113] Furthermore, while individual credential fragments can be verified independently, checking thousands of fragments one by one during recovery is still inefficient (time complexity O(n), where n is the number of credential fragments). Therefore, an O(1) proof header is introduced, which assembles a predetermined number of credential fragments into a constant-time proof header to generate a stable credential. The O(1) proof header can be a very small and fixed-size data structure that can be periodically and atomically written to a predetermined anchor location in persistent memory. It can include a root hash value (such as Merkle_root) and other digest information; the other digest information can be the version number or timestamp of the last credential fragment covered by the O(1) proof header.

[0114] Preferably, the document fragment assembly process can be implemented by constructing a Merkle tree. This involves obtaining a set of document fragments generated within a recent period (e.g., 10 milliseconds), performing a hash calculation on each fragment, and using it as a leaf node of the Merkle tree. These leaf nodes are then paired and hashed to generate the parent leaf node of the next level. This process is repeated until a single merkle_root is finally calculated. Optionally, before assembly, the boundary information of adjacent document fragments can be checked to ensure that the logical sequence numbers of adjacent document fragments are continuous and uninterrupted. Only continuous sets of fragments will be assembled, thus ensuring that the O(1) document header represents a continuous and complete operation history.

[0115] Optionally, the assembly structure of the O(1) credential header can be a hash chain, such as `proof_headn = H(proof_headn-1|| H(stable_shardn))`, where `stable_shardn` is the nth credential fragment, and `proof_headn-1` and `proof_headn` are the (n-1)th and nth O(1) credential headers, respectively. This method is simpler to calculate, but in case of inconsistency, it needs to be verified one by one from back to front. In addition, the persistence strategy of the O(1) credential header can also be configurable. In scenarios where extreme performance is emphasized, an asynchronous background thread can be used to assemble and persist the O(1) credential header; while in scenarios where the highest data reliability is emphasized, it can be configured to synchronously persist the O(1) credential header once every N successfully committed micro-transactions to minimize the scope of checks required after a crash.

[0116] Furthermore, to achieve final coupling with the host path, based on stitching boundary information including monotonic ticket ledger snapshots, the O(1) credential header not only covers all micro-transactions on the host CPU path but also indirectly covers the consistency state of the device write path. During crash recovery, the collaborative consistency of the two heterogeneous write paths is verified simultaneously through a single comparison of the O(1) credential header, thereby reducing the complexity of cross-source consistency verification from O(n) (scanning the proprietary log area) to O(1).

[0117] Optionally, the recovery determination and data repair process may include: performing a single comparison operation on the O(1) voucher header to directly determine the stability of any committed microtransaction; performing differential replay only on committed microtransactions that are determined to be unstable, so as to reduce the time complexity of the recovery determination to the constant level.

[0118] Specifically, after the system restarts from a crash, the recovery determination and data repair process can be simplified as follows: the recovery manager reads the last successfully persisted O(1) credential header from the anchor point; based on the real-time state of the current persisted metadata (i.e., re-traversing the relevant parent leaf nodes and child leaf nodes), the real-time O(1) credential header (proof_head_current) is recalculated; and repair is performed based on the comparison result between proof_head_current and proof_head.

[0119] For example, if the two are completely consistent, it means that all committed microtransactions have been completely and correctly persisted since the last anchor point, that is, the system state is completely consistent, and the recovery determination process is declared complete at this moment, with a time complexity of O(1), which is independent of the number of transactions that occurred during the period.

[0120] Correspondingly, if the two are inconsistent, it indicates that the system state is inconsistent. The recovery manager can efficiently locate the rank2_batch corresponding to the first inconsistent credential fragment with O(log n) complexity by comparing the paths of the Merkle tree reconstructed based on the O(1) credential header with the real-time Merkle tree. For the unstable committed micro-transaction, the manager can perform differential replay or rollback for the rank2_batch. Specifically, it is determined whether it is the part that was not completed before the rollback or the part that has been completed, based on its actual state (such as anti-tear margin). In this way, the scope of recovery is precisely limited to the smallest fault unit, and the recovery time changes from being proportional to the log length to an almost constant and extremely short time.

[0121] Furthermore, when quickly locating inconsistent document fragments based on the Merkle tree, a recursive, top-down difference localization algorithm can be initiated. The algorithm takes two Merkle root nodes as input: the historical Merkle root (merkle_root_old) corresponding to the last successfully persisted O(1) document header, and the real-time Merkle root (merkle_root_new) corresponding to the real-time O(1) document header. If the two Merkle root nodes are inconsistent, the algorithm recursively calls its own data, comparing the corresponding left and right child node pairs, and proceeds downwards along the branch path where the values ​​are inconsistent until a level is reached. If the parent leaf node is inconsistent, but one of its child leaf node pairs is consistent, the inconsistent child leaf node is the first node to introduce the difference. Since the Merkle tree is a balanced binary tree with a height of log n, where n is the number of leaf nodes, the time complexity of this localization algorithm is O(log n), achieving rapid localization of inconsistent document fragments.

[0122] Optionally, the recovery determination and data repair process may also include: identifying the replay set and rollback set to be processed based on versioned pre-write log entries.

[0123] In some embodiments, after the system restarts and data repair is confirmed to be necessary, the recovery manager can scan versioned pre-write log entries. Based on the evidence left by each microtransaction at the moment of the crash, it definitively categorizes them according to a predefined, unambiguous recovery truth table, which specifies the corresponding actions for different combinations of metadata states.

[0124] If the versioned pre-write log entry corresponding to the micro-transaction is found to be complete, has an atomic predicate fence, and its commit bit has been successfully set, but the transaction has not yet been included in the previous stable O(1) credential header, then it is identified as a transaction that has been logically committed but may not be fully physically persisted, and all relevant log entries of such transactions are added to the replay set as candidate transactions that need to be redone.

[0125] If a microtransaction's versioned pre-write log entry is detected to be incomplete, and / or missing atomic predicate fences, and / or its commit bit is not set, then it is identified as an incomplete or invalid transaction, and all related log entries for this type of transaction are added to the rollback set as candidate transactions to be rolled back. In this way, the recovery manager can initially organize the chaotic log state into replay and rollback sets.

[0126] Further, optionally, address deduplication is performed on the replay set and the rollback set, and topological sorting is performed following the child-to-parent dependency relationship to generate an idempotent recovery sorting view.

[0127] In some embodiments, operating directly on the aforementioned set in log order may lead to errors or more severe data corruption if the system crashes again during recovery. Therefore, an idempotent recovery sorting view can be generated through address deduplication and topological sorting to ensure the idempotency of subsequent data repair operations. Idempotency means that performing a recovery operation once or multiple times results in the same system state, and even if the recovery process is interrupted, it will not cause secondary data corruption.

[0128] For example, address deduplication of the replay and rollback sets may specifically include: using a recovery manager to traverse all log entries in both sets and constructing an address mapping table oriented towards the final state. For any persistent memory address that has been updated multiple times, this mapping table will only retain its final, correct state. For instance, if multiple log entries in the replay set update the same counter, the deduplication operation will calculate the correct final version number of that counter and generate only a single operation to set that counter to the final version number, thus replacing multiple incremental, non-idempotent operations.

[0129] For example, topological sorting following a child-to-parent dependency relationship can specifically include: using the recovery manager to construct a directed acyclic graph (DAG) based on the child-to-parent physical dependencies. Nodes in the DAG represent deduplicated recovery operations, and edges represent execution dependencies between operations. For instance, for operations in the replay set, there must be an edge pointing from a persistent leaf node to a persistent parent leaf node. The system performs topological sorting on this graph, generating a linear, conflict-free sequence of operations. For operations in the rollback set, the sorting follows the reverse parent-to-child dependency relationship. The final generated recovery sorting view is a carefully orchestrated linear list of atomic write operations, rather than the original set of log entries.

[0130] Accordingly, after acquiring the recovery sorting view, the recovery manager begins to sequentially execute its corresponding atomic write operations for physical data repair. This execution is interpolated; when performing operations in the replay set, the system utilizes information such as parent previous image commitments and anti-tear margins to accurately calculate the minimum data range requiring repair. The recovery manager treats the interrupted rank2_batch as a whole, determines the breakpoint by checking its anti-tear margin, and only performs interpolated replays on those incomplete or uncertain sub-leaves, rather than blindly rewriting the entire batch, thus minimizing recovery I / O overhead. After all physical write operations are completed and persisted, the recovery process enters the final logical convergence phase. The system selects a fully self-consistent version generation (i.e., key_version, seed_version, and root_version are all consistent) from multiple available version bindings and establishes it as the new stable version. The system atomically updates the stable version number in the persistent metadata page and generates a signature for this new, consistent system state. At this point, the entire crash recovery process is complete, and the system can safely resume normal service.

[0131] Optionally, the generation of the recovery sorting view can be parallelized. For large dependency graphs containing multiple disjoint subgraphs, the system can perform topology sorting and data repair on these independent subgraphs in parallel on multi-core processors, thereby shortening the recovery time for large systems or complex crash scenarios. Furthermore, for extremely rare severe corruption cases that cannot be handled by the recovery truth table, such as circular dependencies caused by hardware failures, the system can be designed with a safety mode as a backup. In this mode, the system will abandon automatic repair, mark the damaged data area as read-only isolated, and issue an alert to the system administrator for manual intervention, thus avoiding secondary damage that may be caused by erroneous automatic repair strategies.

[0132] Optionally, after locating the unstable rank2_batch that requires interpolation replay, the specific interpolation calculation and execution steps are as follows: The recovery manager reads the last recorded anti-tear margin from the parent leaf node associated with this batch. Simultaneously, it reads the shadow bitmap from the batch descriptor (rank2_batch_descriptor) in the WAL, which marks all child leaf positions planned for update in this batch. The system can further combine the shadow bitmap and actual verification of the child leaf region (e.g., checking if its version number has progressed) to accurately identify the number of child leaf nodes in incomplete and completed states, thereby generating a minimal set of repair operations.

[0133] Further optionally, redo operations are generated for incomplete leaf nodes, i.e., the data and metadata are rewritten according to the records in the WAL; undo operations are generated for completed leaf nodes, i.e., their state is rolled back to the state before the start of this micro-batch (this state can be obtained from the preceding guardian predicate or an earlier log). The recovery manager executes the above interpolation operation plan strictly according to the order of the idempotent recovery view, thereby restoring the data area affected by the interrupted micro-batch to a deterministic and consistent state with minimal I / O cost.

[0134] Optionally, the hash function used in the calculation of the different digests mentioned in this application (such as the final guardian digest, the leaf update digest, etc.) may be SHA-256.

[0135] For example, in the initial state, at time T0, the system has a parent leaf node `parent_leaf_P`, located at persistent memory address 0x1000, whose current integrity check value is MAC_P0 = 0xABCD... The system has two child leaf nodes, `leaf_A` and `leaf_B`, sharing the same cache line located at address 0x2000, and therefore both belong to the rank-2 unit managed by `parent_leaf_P`. The initial state of `leaf_A` is version counter `counter_vA0` = 5, and the initial state of `leaf_B` is version counter `counter_vB0` = 8. The current system working version number is `working_epoch_id` = 10;

[0136] At time T1, the system receives two write requests: Request 1 and Request 2. Request 1 aims to update the data in leaf_A, advancing its version counter to counter_vA1 = 6. Request 2 aims to update the data in leaf_B, advancing its version counter to counter_vB1 = 9. The system generates corresponding versioned pre-write log entries for these two requests: wal_record_A and wal_record_B. The pre-guard predicate of wal_record_A requires counter_vA to be 5; the pre-guard predicate of wal_record_B requires counter_vB to be 8. Since the target addresses of both write requests are located at cache line 0x2000, wal_record_A and wal_record_B can be aggregated into the same rank2_batch, with batch identifier batch_id = 101;

[0137] At time T2, the system generates intra-batch commitments for this micro-batch. To compute the parent preceding image commitment, summary_child_updates is constructed as a serialized concatenation of the new states of the two leaves. Assuming the updated MAC of leaf_A is MAC_A1=0x33.. and the updated MAC of leaf_B is MAC_B1=0x44.., then summary_child_updates=serialize(MAC_A1 || MAC_B1), where serialize is the serialization operation;

[0138] The formula for calculating the commitment made in front of the father is:

[0139] parent_preimage_commit=H(MAC_P0 || summary_child_updates);

[0140] That is, SHA-256(0xABCD.. || serialize(0x33.. || 0x44..)), assuming the calculation result is 0xC0DE... Meanwhile, since this micro-batch contains two leaf updates, the anti-tear margin is atomically set to 2 in the metadata area of ​​the parent leaf node parent_leaf_P;

[0141] At time T3, the system performs DNF compression and atomic commit. To condense the final guard digest `final_guard_digest`, two security predicates can be asserted in the `Set_PG` of this batch: `counter_vA == 6` and `counter_vB == 9`. The system serializes these two expected values ​​and performs hash calculation: `final_guard_digest = H(serialize(6 ||9))`, assuming the calculation result is 0xD1AB.... The system constructs an atomic predicate fence, which contains `final_guard_digest = 0xD1AB...` and version progress evidence of the current version, and follows a strict persistence order: persisting the atomic predicate fence first, and then setting the commit bit.

[0142] At time T4, after the microtransaction is successfully committed, the system generates a stability credential for it. A credential fragment with ID 101 can be created, which may contain batch_id: 101, parent_preimage_commit: 0xC0DE..., final_guard_digest: 0xD1AB.... Assuming this is the only microtransaction recently, the system hashes the credential fragment and uses its hash value as the root of the Merkle tree to generate an O(1) credential header. proof_head = H(serialize(stable_shard_101)), assuming the calculation result is 0xFACE.... The system atomically writes this O(1) credential header to the predetermined anchor location in persistent memory. At time T5, crash recovery and O(1) determination are performed. Assuming that after T4, all data has been correctly persisted, and then the system crashes unexpectedly. After the system restarts, the recovery manager reads the last persisted O(1) credential header from the anchor location, whose value is 0xFACE.... To verify, the recovery manager recalculates the O(1) credential header based on the actual data state in the current persistent memory. It finds the committed transaction batch_id=101, reads the previous image MAC_P0 of parent_leaf_P, reads the leaf update information recorded in WAL, recalculates parent_preimage_commit; reads the updated counter, recalculates final_guard_digest; and constructs a temporary credential fragment stable_shard_current based on these recalculated values, finally calculating proof_head_current = H(serialize(stable_shard_current)). The recovery manager performs the core comparison operation: compare(proof_head_current, 0xFACE...). Since all data was correctly persisted before the crash, the result of proof_head_current must also be equal to 0xFACE.... Since they match, the determination is successful. The recovery manager can immediately confirm that the system state is consistent without performing any data repair operations. The entire determination process involves only one anchor point reading and one recalculation and comparison based on the latest state, which is independent of the number of historical transactions, and therefore has a time complexity of O(1).

[0143] In some embodiments, to achieve optimal performance and memory alignment under a typical 64-bit computing architecture, the field sizes of several key data structures in this application are preferably designed as follows: For the rank2_batch_descriptor, its batch identifier batch_id is preferably a 64-bit unsigned integer to facilitate atomic increment operations; its shadow_bitmap is preferably a 64-bit unsigned integer, where each bit can be used to mark the update status of a unit when a cache line can hold a maximum of 64 minimum cryptographic units; and its parent_leaf_ptr is preferably a 64-bit address pointer. For the atomic predicate fence record, its final guard digest final_guard_digest is preferably 256 bits to be compatible with the output length of standard secure hash algorithms such as SHA-256, providing approximately 128 bits of security strength. For the stable credential fragment stable_shard, its parent previous image commitment and batch inner leaf node digest are also preferably 256 bits.

[0144] Furthermore, to adapt this application to different application workloads, such as from low-latency online transaction processing (OLTP) to high-throughput batch analytics, the following core parameters are designed to be tuned during system deployment or runtime. The commit strategy for `rank2_batch` can be controlled by two parameters. The first is the batch commit count threshold `batch_commit_threshold_count`, which defines the maximum number of versioned pre-write log entries that must be aggregated in a microbatch before a commit is triggered. Its typical value is 8, and a recommended range is 1 to 64. Lower values ​​make each write approach a synchronous commit, resulting in the lowest latency but also the lowest throughput. Higher values ​​can improve throughput but increase the average latency per write. The second is the batch commit timeout threshold `batch_commit_threshold_time_us`, in microseconds, which defines the maximum time a microbatch waits for aggregation from its creation. Its typical value is 100 microseconds, and a recommended range is 10 to 1000 microseconds.

[0145] In low-load scenarios, this parameter ensures that writes will not be indefinitely delayed even if the number of writes does not reach the threshold. The quota of the Bounded Authentication Queue (BAQ) is controlled by the `baq_quota_per_second` parameter, which limits the maximum number of failed sketch proofs that the BAQ can authenticate per second. Its typical value is 10,000, and a recommended range is 100 to 1,000,000. This parameter is crucial for the system's defense against read path denial-of-service attacks; its value should be set based on the expected maximum version rotation frequency and read failure rate under normal business conditions, with a certain margin. The half-decay window for negative proofs is controlled by the `decay_window_ms` parameter, in milliseconds, and is the default lifetime of the routing preference record. Its typical value is 50 milliseconds, and a recommended range is 10 to 500 milliseconds. This window duration should be slightly longer than the average time it takes for a versioned pre-write log entry to be written and then merged into the stable region in the background, such as the P99 latency. This ensures that, in most cases, the routing preference can cover the entire unstable period, while also becoming invalid as soon as the data stabilizes, avoiding the use of outdated routing strategies. By reasonably setting the above data structure size and flexibly tuning runtime parameters, it is possible to accurately match the different performance, latency, and security requirements of specific business scenarios.

[0146] Optionally, obtaining version progress evidence may also include: reading persistent metadata pages and startup parameter sets; verifying the consistency of the stable version number, root integrity version, and key version; comparing the consistent state signature from the last shutdown to obtain the initial value of the memory-state version context and the root state image; reading the version context and root state image; and filling in default fields and boundary conditions, such as using the default mapping seed version for the empty set seed and reverting out-of-bounds version numbers to the most recent stable version number, to obtain a standardized version context suitable for concurrent scenarios and reduce abnormal path divergences; and reading the standardized version context and constructing a visibility view containing read-only snapshots and write-end announcement bits to obtain readable path lookups. The query and write path reference version domain snapshot provides a baseline for allocating working versions and routing decisions; read the standardized version context, generate a forward security chain by advancing the key version unidirectional hash chain and solidify its anchor point to obtain a verifiable forward security anchor point to prevent version rollback during rotation; read the mapping seed version and forward security anchor point, form a seed drift limit by calculating the seed drift upper limit and time window and bind it to the working version number to obtain version advancement constraints that are available for atomic commit and recovery verification; read the version advancement constraints and version domain snapshot, write them to the version binding table and synchronize them to the visibility view to obtain version advancement evidence that can be directly referenced by the atomic predicate fence and O(1) credential header.

[0147] Optionally, the process of building the versioned pre-write log entry index may include:

[0148] Read the plaintext data to be written and the version progress evidence, construct the pre-predicate and organize the fields, such as address range, tree hint, counter increment hint, etc. by sampling the version snapshot of the counter row of the target address and the version snapshot of the parent leaf node, to obtain the versioned pre-write log entries containing version and guardian information;

[0149] Read the pre-write log entries and sequentially execute append, cache line refresh, and barrier (append wal→clwb→sfence) to obtain the written records that can be traced during the disk write operation;

[0150] Read the recorded data and plaintext data to be written, encrypt it at the cache line granularity through the Advanced Encryption Standard instruction set extended pipeline, and update the corresponding counter line to obtain ciphertext data and a new counter image consistent with the predicate, and prepare input for the parent leaf calculation;

[0151] Read the tree hints and counter image, locate the parent leaf node and write in parent-child dependency order (ciphertext first → counter / parent leaf last → clwb+sfence at each step) to obtain the encrypted metadata update and persistent data group containing the parent leaf increment;

[0152] Read the data group, map the leaf positions involved in the same cache line to a bitmap, obtain the shadow bitmap, and together with the parent leaf number, form the boundary information described by rank2_batch, which is convenient for intra-batch proof;

[0153] Read the rank2_batch description, allocate a unique batch number from the current parent leaf namespace and resolve conflicts (atomic ordering, timestamp shuffling) to obtain a batch number with global uniqueness, ensuring that subsequent vouchers can be located in a single instance;

[0154] Read the counter new image and the current MAC input of the parent leaf, calculate the previous image commitment of the parent leaf according to the local summary method and attach it to the rank2_batch description to obtain the parent leaf submission entries that can verify the batch integrity without recalculating the entire parent leaf;

[0155] Read the parent leaf submission entries and shadow bitmap, record the tear prevention margin of the current batch in the parent leaf and update the count of fallen child leaves in real time to obtain the rank-2 completeness trajectory that can be used for delimitation and rollback during the recovery period;

[0156] Read the rank-2 completeness trajectory, encapsulate the final state and verify the signature to obtain the rank-2 final state proof and write it back to the rank2_batch description, thus obtaining the rank-2 final state proof that can be directly used in credential generation and recovery determination;

[0157] Read multiple versioned pre-write log entries from the same parent leaf, color-code the post-guard predicates according to security / performance categories, and perform algebraic elimination on the performance items to obtain a simplified guard set that retains only the security-necessary items, laying the foundation for reducing duplicate writes; read the simplified guard set and the earliest pre-guard predicate, generate the final guard summary by folding multiple post-guard predicates, and organize it into an incremental paradigm block to obtain an incremental paradigm block that can cover multiple locally consistent entries in a single commit;

[0158] Read the incremental paradigm block and version progress evidence, write the atomic predicate fence and then set the commit bit to obtain the committed microtransaction with guardian commitment + version forward evidence and the queryable WAL index.

[0159] Furthermore, the working version number and address range are read. A co-signed ticket containing the version number, serial number, and MAC epoch identifier is generated at the target end and appended to the device ticket area to obtain the ticket digest for the returning host, supporting cross-source credentials. The device ticket area and ticket digest are read, and by verifying the monotonicity of the serial number and the validity of the MAC and marking gaps, a continuous view of device tickets that can provide a basis for reconciliation and snapshots is obtained. The ticket digest is read, and by registering echo entries on the host and constructing echo mappings, an echo entry consistency view that can be used for monotonic ledger snapshot comparisons is obtained. The echo mappings and the continuous view of device tickets are read, and by retransmitting and resolving missing or duplicate data, such as echo queries and deduplication marking, a cross-source consistency mapping is obtained. The encrypted data and encrypted metadata updates are read, and by registering batch information to the background merge queue and attaching searchable entries to the visibility view, write path completion markers and batch candidate sets that can be directly routed and retrieved are obtained.

[0160] Optionally, performance parameter hooks can be constructed. Specifically, various target objects can be read, such as encrypted data, counter lines, parent leaf nodes, and pre-write log commit bits. By defining an object-level sequence template of append → clwb → sfence, a persistent primitive sequence can be obtained, making the consistent write order of different objects reproducible. The status bit combination of each key write point can be read. By exhaustively listing the crash location and listing the rollback / replay actions, an anomaly rollback matrix and recovery truth table can be obtained, ensuring that the boundary path is sufficiently exposed. The routing decision and verification results can be read. By solidifying the immutable rule that any path must complete an integrity verification once, a security constraint summary table can be obtained to avoid implementation deviations. All structure definitions can be read. By listing field names and sizes, such as batch number 64, shadow bitmap 64, leaf set hint 128, final guardian digest 256, a data structure table that can be compared can be obtained to support cross-implementation consistency. Runtime monitoring metrics can be read. By providing the default values ​​and tuning ranges of rank-2 batch size, bounded authentication queue quota, and half-life window upper and lower limits, a deployment-controllable performance parameter hook can be obtained, which is convenient for engineering implementation.

[0161] Optionally, in response to a failure to verify a read request for a stable version, the failure trajectory is encoded as a verifiable failure sketch.

[0162] Specifically, in a typical read operation, the system will first attempt to read data from the stable version's data area. However, during the brief window of version rotation, data at a certain address may have been encrypted with the key of the new version (working version) and written to the WAL, but has not yet been merged back into the stable area. At this time, using the stable version's key to decrypt or verify will result in failure. When such verification failure occurs, the system does not simply discard the event, but encodes it into a compact, probabilistic data structure—the Verifiable Failure Sketch (vfs). A preferred encoding method is to use 2-choice hashing: maintain a bitmap in memory, such as vfs_sketch; combine key information of the failure event, such as the target read address (read_addr) and the stable version number of the failure, into an input string; use two independent hash functions H1 and H2 to calculate the positions in the two bitmaps: pos1 = H1(Input string) and pos2 = H2(Input string); set the pos1 and pos2 bits in vfs_sketch to 1; at the same time, generate a failure sketch proof (vfs_proof), which contains a digest of the input string and the position information of pos1 and pos2.

[0163] Optionally, verifiable failure sketches can be authenticated by comparing them with versioned pre-write log entries using a bounded authentication queue.

[0164] In some embodiments, simply changing the routing policy based on `vfs_sketch` is dangerous because attackers can fill `vfs_sketch` with a large number of read requests to invalid addresses, causing routing decision pollution and resulting in a denial-of-service attack. To address this, a bounded authentication queue is introduced as a security gateway. For example, the bounded nature of the queue is reflected in its fixed processing rate quota; for instance, a maximum of 1000 failed events can be authenticated per second, with any excess being discarded, effectively suppressing traffic-based attacks. When a `vfs_proof` enters the bounded authentication queue, the authentication logic is triggered. This logic queries the WAL index: whether there exists a committed versioned pre-write log entry that overwrites the target read address, and whether this entry was generated after the stable version number and from the current working version number. If it exists, it provides evidence of a stable version read failure—because a newer version does exist in the log—and the `vfs_proof` is considered authenticated. If it does not exist, the failure is considered an unfounded and suspicious event, and the `vfs_proof` is discarded. This ensures that only expected read failures caused by genuine write operations can proceed to the next step.

[0165] Optionally, a routing preference record can be established based on the authenticated failure sketches to suppress invalid read attempts to the same destination address within a preset half-life window.

[0166] In some embodiments, for each failed event that passes the bounded authentication queue (BALQ) authentication, the system creates a temporary routing preference record, also known as a negative proof cache entry. For example, the core content of this record is: for the target read address, for a period of time, the default route for read requests will be temporarily changed from stable version priority to working version priority. The lifespan of this record is controlled by a preset half-life window, for example, 50 milliseconds. That is, within the next 50 milliseconds, any read request to `read_addr` will be directly routed to the WAL, thus avoiding doomed stable version read attempts and reducing the average latency of read operations. When the preset half-life window expires, the routing preference record automatically becomes invalid. In a preferred implementation, a stabilization closed-loop mechanism exists: when the background merging process officially merges the data corresponding to `read_addr` from the WAL into the stable version area, it will actively issue a stabilization trigger flag. This flag will immediately force the clearing of the corresponding routing preference record, even if its half-life window has not yet expired. This ensures that the routing strategy always returns to the optimal stable state in a timely and accurate manner.

[0167] Optionally, verifiable failure sketches can use other probabilistic data structures, such as Bloom filters or count Bloom filters, the latter of which also allows logging the number of failures. The authentication logic of the bounded authentication queue can be configured with different trust levels; for example, failures with only versioned pre-write log entries but not yet committed can be weakly authenticated, while failures with committed microtransaction flags are strongly authenticated and given a longer half-life window.

[0168] Optionally, the specific implementation of querying the WAL index in the authentication logic can be further defined as follows: To achieve efficient querying of the WAL index, the index is preferably implemented as an in-memory hash table or a radix tree adapted to the address space. Here, the key is the normalized value of the persistent memory's `read_addr` (e.g., aligned to cache line size), while the value is a pointer or reference pointing to the metadata of the cached versioned pre-write log entry `wal_record` associated with that address. This metadata includes at least its working version number and commit status. When the authentication logic needs to query, it uses the `read_addr` from the read failure event as the key and directly performs a search of varying complexity within this hash table or radix tree. If an entry is found, its version number and commit status are further checked to ensure they meet the authentication conditions, thus completing an efficient authentication query.

[0169] Compared to related technologies, this embodiment addresses the system crash problem of persistent memory by providing comprehensive and robust protection measures for metadata in fine-grained encryption operations. Specifically, at the structural and physical levels, it provides structured atomicity protection and physical write order protection. Specifically, by defining a minimum consistency unit, a child leaf metadata and its parent leaf metadata are logically bound into an indivisible atomic operation unit, directly preventing the most fatal parent-child tearing problem during metadata updates. To physically guarantee this atomicity, a strict persistent write order of child before parent is enforced, ensuring that in any crash, the system will never enter an inconsistent state where the parent has been updated but the child has not, making the system state always recoverable. At the logical transaction level, it provides logical transaction consistency protection. Based on versioned pre-write logs and an atomic predicate barrier mechanism, transaction commit operations are atomically persisted as barrier records containing a final guardian digest and version progress evidence. The final guardian digest serves as a data consistency commitment, and the version progress evidence serves as a version sequence safety commitment, elevating metadata consistency verification from physical state matching to logical contract verification. During recovery, only the atomic predicate fence record needs to be checked to simultaneously determine the validity of data and version, enhancing the robustness of the system. At the time-series security level, time-series security and rollback protection are provided. By establishing a forward security chain based on an irreversible hash chain for key versions, any malicious or erroneous operation attempting to revert to older version metadata will be rejected because it cannot provide correct version progression evidence. This effectively protects metadata from version rollback attacks, ensuring system security and linear evolution of state. At the system availability level, efficient and verifiable recovery protection is provided. By generating independently verifiable and interlocked stability credentials, and assembling them into an O(1) credential header that can be verified in constant time, when the system recovers from a crash, instead of time-consuming scanning of all log metadata, a single comparison with this credential header can almost instantly determine the stability of most metadata. This improves the availability of metadata and minimizes system downtime.

[0170] Based on the above Figure 1 The specific implementation of the method shown in this embodiment provides a fine-grained encrypted metadata protection device for persistent memory, such as... Figure 2 As shown, the device includes: a receiving module 31, a merging module 32, a generating module 33, and a recovery module 34;

[0171] The receiving module 31 is used to generate a versioned pre-write log entry corresponding to the metadata in response to a write request for the received metadata during the fine-grained encryption of plaintext data in persistent memory.

[0172] The merging module 32 is used to merge versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain log micro-batches. The smallest consistency unit includes the leaf nodes corresponding to the same cache line in persistent memory and their associated parent leaf nodes.

[0173] The generation module 33 is used to generate the committed microtransaction corresponding to the metadata and generate the stability certificate corresponding to the committed microtransaction in response to the successful execution of the atomic commit operation corresponding to the log micro-batch.

[0174] Recovery module 34 is used to perform recovery determination and data repair process based on the guardian predicate and stability credentials in the versioned pre-write log entries after the system crashes, and generate persistent metadata.

[0175] The generation module 33 is specifically configured to: obtain a version snapshot of the counter row and the parent leaf node of the plaintext data at the target address in persistent memory; construct a pre-guard predicate corresponding to the metadata based on the counter row version snapshot and the parent leaf node version snapshot, the pre-guard predicate includes a local consistency assertion corresponding to the current state of the metadata, used to determine the consistency of the metadata before the write operation is executed; generate versioned pre-write log entries based on the pre-guard predicate and pre-stored version advancement evidence, the version advancement evidence is used to force unidirectional version advancement; the method also includes: constructing a post-guard predicate corresponding to the metadata, the post-guard predicate includes a local consistency assertion corresponding to the target state of the metadata, used to determine the consistency of the metadata after the write operation is executed.

[0176] The generation module 33 is specifically configured to integrate the post-guard predicates in versioned pre-write log entries belonging to the same parent leaf node based on disjunction normalization, obtain the final guardian summary corresponding to the metadata, and use the final guardian summary to verify the overall consistency of the metadata corresponding to the log micro-batch when performing the atomic commit operation corresponding to the log micro-batch; construct atomic predicate fences, which are used to encapsulate the final guardian summary and version progress evidence; and persist the atomic predicate fences to persistent memory before performing the set commit bit operation to form a committed micro-transaction, serving as a dual verification point for metadata consistency and version security when recovering data after a system crash.

[0177] The generation module 33 is specifically configured to, based on the semantic rules corresponding to the disjunction paradigm and the application requirements, distinguish the post-guard predicates into security predicates corresponding to the system verifiability indicators and performance predicates corresponding to the system performance indicators; aggregate the security predicates and performance predicates respectively based on different processing strategies, and generate the final guard summary based on the final aggregation state obtained by aggregation.

[0178] The generation module 33 is further configured to generate a parent-previous image commitment corresponding to the parent leaf node based on the real-time status of the parent leaf node associated with the log micro-batch and the leaf update summary of the child leaf node in the log micro-batch. The parent-previous image commitment is used to verify the integrity of the parent-child data relationship within the log micro-batch during system crash recovery. It also records a tear prevention margin in the parent leaf node associated with the log micro-batch. The tear prevention margin is used to characterize the number of child leaf nodes within the log micro-batch that have not yet been persisted, so as to provide a rollback boundary for incompletely written log micro-batches during system crash recovery.

[0179] The generation module 33 is specifically configured to generate voucher fragments corresponding to committed microtransactions. The voucher fragments are used to encapsulate the batch self-verification information of the committed microtransactions and to independently verify the committed microtransactions. The voucher fragments corresponding to the committed microtransactions are assembled into a constant-time complexity voucher header. A stability voucher is generated based on the constant-time complexity voucher header. The constant-time complexity voucher header is used to determine the stability of constant-time complexity during system crash recovery.

[0180] The recovery module 34 is specifically configured to, when the system starts, obtain the consistent state signature corresponding to the metadata saved at the last shutdown in persistent memory, and recalculate the real-time state signature according to the current system parameters; and determine the initial state of the system based on the comparison result between the consistent state signature and the real-time state signature.

[0181] Based on the above, Figure 1 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 The method shown.

[0182] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0183] Based on the above, Figure 1 The method shown, and Figure 2 To achieve the above objectives, the present application also provides an electronic device, comprising a storage medium and a processor; the storage medium for storing a computer program; and the processor for executing the computer program to implement the above-described virtual device embodiments. Figure 1 The method shown.

[0184] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0185] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0186] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0187] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware. This application, based on versioned pre-write logs and atomic predicate fence mechanisms, atomically persists transaction commit operations as fence records containing a final guardian summary and version progress evidence, elevating metadata consistency verification from physical state matching to logical contract verification. During recovery, only the atomic predicate fence record needs to be checked to simultaneously determine the validity of data and version, enhancing system robustness.

[0188] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0189] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A fine-grained encrypted metadata protection method for persistent memory, characterized in that, include: During the fine-grained encryption of plaintext data in persistent memory, in response to receiving a write request for the metadata corresponding to the plaintext data, a versioned pre-write log entry corresponding to the metadata is generated. The versioned pre-write log entry is a versioned log entry associated with the system version domain. It is generated before the write operation corresponding to the write request is executed and contains a guardian predicate, which is used to formally describe the consistency state that the metadata must satisfy before and after the write operation. The guardian predicate is the predicate logic for verifying the consistency of the metadata before and after the write operation. The guardian predicate includes a pre-guard guardian predicate and a post-guard guardian predicate. The versioned pre-write log entries are merged using the smallest consistency unit as the merging granularity to obtain log micro-batches. The smallest consistency unit includes the leaf nodes corresponding to the same cache line in the persistent memory and their associated parent leaf nodes. In response to the successful execution of the atomic commit operation corresponding to the log micro-batch, a committed micro-transaction corresponding to the metadata is generated, and a stability credential corresponding to the committed micro-transaction is generated. After a system crash, based on the guardian predicate in the versioned pre-write log entry and the stability credential, a recovery determination and data repair process is executed to generate persistent metadata. The generation of the versioned pre-write log entries corresponding to the metadata includes: Obtain the counter row version snapshot and the parent leaf node version snapshot of the plaintext data at the target address in the persistent memory; Based on the counter row version snapshot and the parent leaf node version snapshot, a pre-guard predicate corresponding to the metadata is constructed. The pre-guard predicate includes a local consistency assertion corresponding to the current state of the metadata, which is used to determine the consistency of the metadata before the write operation is executed. Based on the aforementioned pre-guard predicate and the pre-stored version advancement evidence, the versioned pre-write log entry is generated, and the version advancement evidence is used to force unidirectional version advancement; The method further includes: Construct a post-guard predicate corresponding to the metadata. The post-guard predicate includes a local consistency assertion corresponding to the target state of the metadata, which is used to determine the consistency of the metadata after the write operation is executed.

2. The method according to claim 1, characterized in that, Before the atomic commit operation corresponding to the log micro-batch is successfully executed, the committed micro-transaction corresponding to the metadata is generated, and the stability credential corresponding to the committed micro-transaction is generated, the method further includes: Based on the disjunction paradigm, the post-guard predicates in the versioned pre-write log entries belonging to the same parent leaf node are integrated to obtain the final guardian digest corresponding to the metadata. The final guardian digest is used to verify the overall consistency of the metadata corresponding to the log micro-batch when the atomic commit operation corresponding to the log micro-batch is executed. Construct an atomic predicate fence, which is used to encapsulate the final guardian summary and the version advancement evidence, serving as a dual verification point for metadata consistency and version security when recovering data after a system crash; The atomic predicate fence is persisted to the persistent memory before the microtransaction is committed according to the set commit bit flag.

3. The method according to claim 2, characterized in that, The method, based on the disjunction paradigm, integrates the post-guard predicates in versioned pre-write log entries belonging to the same parent leaf node to obtain the final guardian digest corresponding to the metadata, including: Based on the semantic rules and application requirements corresponding to the disjunction paradigm, the post-guard predicates are divided into security predicates corresponding to system verifiability indicators and performance predicates corresponding to system performance indicators. The security predicate and the performance predicate are aggregated based on different processing strategies, and a final guardian summary is generated based on the final aggregated state.

4. The method according to claim 2, characterized in that, After obtaining the log micro-batch, the method further includes: Based on the real-time status of the parent leaf node associated with the log micro-batch and the child leaf update summary of the child leaf node in the log micro-batch, a parent before image commitment corresponding to the parent leaf node is generated. The parent before image commitment is used to verify the integrity of the parent-child data relationship within the log micro-batch during system crash recovery. A tear prevention margin is recorded in the parent leaf node associated with the log micro-batch. The tear prevention margin is used to characterize the number of leaf nodes in the log micro-batch that have not yet been persisted, so as to provide a rollback boundary for log micro-batches that are not fully written during system crash recovery.

5. The method according to claim 4, characterized in that, The generation of the stability certificate corresponding to the committed microtransaction includes: Generate a credential fragment corresponding to the committed microtransaction. The credential fragment is used to encapsulate the batch self-verification information of the committed microtransaction and to independently verify the committed microtransaction. The credential fragments corresponding to the submitted microtransactions are assembled into a constant-time complexity credential header, and the stability credential is generated based on the constant-time complexity credential header. The constant-time complexity credential header is used to determine the stability of the system in constant time complexity during system crash recovery.

6. The method according to claim 1, characterized in that, The method further includes: When the system starts up, it obtains the consistent state signature corresponding to the metadata saved at the last shutdown in the persistent memory, and recalculates the real-time state signature based on the current system parameters. The initial state of the system is determined based on the comparison between the consistent state signature and the real-time state signature.

7. A fine-grained encrypted metadata protection device for persistent memory, characterized in that, include: The receiving module is used to, during the fine-grained encryption of plaintext data in persistent memory, respond to a write request for the metadata corresponding to the received plaintext data, and generate a versioned pre-write log entry for the metadata. The versioned pre-write log entry is a versioned log entry associated with the system version domain, generated before the write operation corresponding to the write request is executed, and embeds a guardian predicate to formally describe the consistency state that the metadata must satisfy before and after the write operation. The guardian predicate is the predicate logic for verifying the consistency of the metadata before and after the write operation, and the guardian predicate includes a pre-guard guardian predicate and a post-guard guardian predicate. The step of generating versioned pre-write log entries corresponding to the metadata includes: obtaining a counter row version snapshot and a parent leaf node version snapshot of the plaintext data at the target address in persistent memory; constructing a pre-guard predicate corresponding to the metadata based on the counter row version snapshot and the parent leaf node version snapshot, wherein the pre-guard predicate includes a local consistency assertion corresponding to the current state of the metadata, used to determine the consistency of the metadata before the write operation is executed; generating versioned pre-write log entries based on the pre-guard predicate and pre-stored version advancement evidence, wherein the version advancement evidence is used to force unidirectional version advancement; the device further includes: constructing a post-guard predicate corresponding to the metadata, wherein the post-guard predicate includes a local consistency assertion corresponding to the target state of the metadata, used to determine the consistency of the metadata after the write operation is executed; The merging module is used to merge the versioned pre-write log entries with the smallest consistency unit as the merging granularity to obtain log micro-batches. The smallest consistency unit includes the leaf nodes corresponding to the same cache line in the persistent memory and their associated parent leaf nodes. The generation module is used to generate the committed microtransaction corresponding to the metadata and generate the stability certificate corresponding to the committed microtransaction in response to the successful execution of the atomic commit operation corresponding to the log micro-batch. The recovery module is used to perform recovery determination and data repair processes and generate persistent metadata after a system crash, based on the guardian predicate in the versioned pre-write log entry and the stability credential.

8. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

Images