Extensible decentralized oblivious data storage method

Abstract

The invention particularly relates to an extensible decentralized casual data storage method, which comprises the following steps of: based on a casual random access memory, storing a global data tree in different storage nodes, and centrally maintaining metadata and metadata logs on a semi-trusted control node. Moreover, the server side extracts the incremental log and the cache fragment from the control node according to the access address and the timestamp, reads the target data bucket from the corresponding storage node and returns the target data bucket to the client side; and the client rewrites the target access path and the data bucket after locally replaying the log synchronization metadata, and feeds back to the control node and the storage node. And furthermore, in combination with a data expelling operation triggered according to access times and a refreshing operation triggered when the virtual blocks are used up, the distribution randomness of the data blocks on the tree and the sufficiency of virtual block resources are maintained. According to the method, on the premise of a hidden access mode, separated storage of data and metadata, increment synchronization of the metadata as required and asynchronous parallel access of the control node and the storage node are realized.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and more specifically to a scalable, decentralized, unintentional data storage method. Background Technology

[0002] Decentralized storage, a new storage paradigm that has emerged in recent years, is gradually becoming an important infrastructure for various decentralized applications. These systems integrate a large amount of idle storage resources across the network, providing large-scale outsourced storage capabilities at a lower cost. For example, some content distribution platforms use decentralized storage to cache static resources, encrypted databases store user data on decentralized storage, and social networks can store user-generated content on third-party nodes.

[0003] Existing decentralized storage products already provide basic data privacy protection mechanisms, such as end-to-end encryption to protect data at rest or encryption during transmission to prevent storage nodes from directly reading plaintext content. However, these solutions still expose the user's data access process and related metadata, such as access frequency, access order, and operation type; this information is collectively referred to as access patterns. Existing research shows that even if the data content itself is always encrypted, analyzing access patterns alone can infer user behavior characteristics and data relationships, thereby leaking a large amount of sensitive information—up to 80% of the data can be leaked.

[0004] Oblivious Random Access Memory (ORAM) is a storage paradigm that hides access patterns. It generates completely random access patterns independent of input data, preventing servers from extracting any useful information from exposed access patterns. The goal of ORAM is to provide a traditional random access memory (RAM) interface on the client side while generating near-random access sequences on the server side, independent of input data, making it impossible for passive observers to obtain useful information from exposed access patterns. In industry, some encrypted communication systems and encrypted file systems have already used ORAM to protect address book lookups or file access patterns. For example, the encrypted communication software Signal uses ORAM to protect users' address books, and the encrypted file system UtahFS uses ORAM to protect users' file access patterns.

[0005] Although existing decentralized storage systems have protected data security to some extent through encryption, and existing ORAM technology provides theoretically complete privacy protection in terms of hiding access modes, existing ORAM solutions cannot meet the core requirements of decentralized scenarios such as resisting global attackers, removing trusted proxy dependencies, having good horizontal scalability, and supporting asynchronous access.

[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0007] This invention provides a scalable, decentralized, unintentional data storage method, a computer-readable storage medium, and a computer program product, which can effectively overcome the defects existing in the prior art.

[0008] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0009] According to a first aspect of the present invention, a scalable, decentralized, unintentional data storage method is provided, the method comprising: Based on the secure and lightweight partitioning strategy, storage nodes and control nodes are initialized separately. Storage nodes are used to store data subtrees, and control nodes are used to store the metadata corresponding to the data subtrees and metadata logs. Tree nodes are data buckets used to store real data blocks and virtual blocks, and metadata logs are used to record metadata update information. The metadata and metadata logs in the control node are sent to the client via the communication connection; In response to an access request sent by a client, based on the last access timestamp and access address in the access request, the corresponding incremental log and cache fragment extracted from the control node, as well as the corresponding target data bucket extracted from the storage node, are sent to the client; where the cache fragment is the metadata in the control node corresponding to the access address; The updated metadata and metadata logs sent by the client are used to update the metadata and metadata logs in the control node, respectively. The updated metadata and metadata logs are generated by the client rewriting the access path corresponding to the access address based on the incremental log and cache fragments, and the corresponding log records. Simultaneously, the updated data bucket sent by the client is used to update the data subtree in the storage node; the updated data bucket is the data bucket obtained by the client after rewriting the actual data blocks in the target data bucket.

[0010] In some exemplary embodiments, initializing the storage node and control node according to the secure lightweight partitioning strategy includes: The data tree is divided into multiple data subtrees at a preset partitioning layer, and these subtrees are assigned to corresponding storage nodes; the data tree is constructed based on the tree bucket structure of the random access memory. Read the branch path between the global root node of the data tree and the root node of the subtree of the data tree, and store the branch path to the corresponding storage node; The mapping relationship between data subtrees and corresponding storage nodes, as well as the index information of the trunk bucket, are stored as metadata in the control node; where the index information of the trunk bucket is the identifier of the storage node corresponding to the trunk bucket, and the trunk bucket is the data bucket on the branch path. Initialize the metadata log corresponding to the metadata in the control node.

[0011] In some exemplary embodiments, the step of responding to an access request sent by a client, based on the last access timestamp and access address in the access request, sending the corresponding incremental log and cache fragment extracted from the control node, and the corresponding target data bucket extracted from the storage node to the client, includes: Based on the timestamp of the log record in the metadata log, locate the first log record with a timestamp greater than the last access timestamp, and determine the log entry from the first log record to the current log record as the incremental log; Based on the access address in the access request and the metadata currently stored in the control node, determine the access path corresponding to the access address and the target storage node corresponding to the access path; Extract the cache fragment corresponding to the access path from the control node, and read the target data bucket corresponding to the access path from the target storage node; The incremental logs, cached fragments, and target data buckets are combined to form a response message, which is then sent to the client.

[0012] In some exemplary embodiments, the method further includes: The lower limit of the metadata log capacity in the control node is determined based on the number of clients and preset security parameters.

[0013] In some exemplary embodiments, the method further includes: When the number of accesses reaches a preset threshold, the system receives eviction control information sent by the client and determines the eviction path based on the eviction control information. Determine the metadata corresponding to the path to be evicted from the control node; Based on the path to be evicted, the corresponding data bucket is read from the storage node according to the data bucket's eviction height; and the data bucket is sent to the client; where the data bucket's eviction height represents the distance of the data bucket relative to the global root node; The client receives the evicted data blocks generated after rearranging the data blocks in the bucket; Write the evicted data block to the data bucket on the write-only path in the corresponding storage node; where the write-only path is a dedicated access path pre-specified on the storage node that is only used to receive the write of the evicted data block.

[0014] In some exemplary embodiments, the method further includes: After each access request ends, refresh control information is received from the client; the refresh control information includes: the identification information of the access path to be refreshed, and the virtual data block exhaustion flag of the data bucket on the access path to be refreshed; Based on the current metadata in the control node, determine the data subtree corresponding to the identification information of the access path to be refreshed; and, based on the data subtree and the virtual data block exhaustion flag of the data bucket, determine the data bucket to be refreshed; and send the data bucket to be refreshed to the client. The system receives the refreshed data bucket sent by the client and replaces the corresponding data bucket on the storage node with the refreshed data bucket. The refreshed data bucket is obtained by adding virtual data blocks to the data bucket to be refreshed by the client and rearranging the added virtual data blocks and real data blocks.

[0015] According to a second aspect of the present invention, a scalable, decentralized, unintentional data storage method is provided, the method comprising: Establish communication connections with the control node and storage node, obtain metadata and metadata logs generated by the control node based on the security lightweight partitioning strategy through the communication connections, and cache the obtained metadata and metadata logs locally; The access address is determined based on metadata and metadata logs. An access request is constructed by combining the operation type and the last access timestamp recorded locally, and the access request is sent to the server. The system receives incremental logs and cache fragments extracted from the control node and the target data bucket extracted from the storage node, returned by the server based on the access request; it then synchronizes the locally cached metadata based on the incremental logs and cache fragments; and finally uses the synchronized metadata to determine the access path corresponding to the access address. The access path is rewritten, and the rewritten access path is updated to the synchronized metadata; the local cached metadata log is appended and updated based on the mapping change of the access path; the updated metadata and metadata log are sent to the control node to update the metadata and metadata log in the control node. When the operation type is a write operation, the actual data block in the target data bucket is rewritten with the data to be written in the access request to generate an updated data bucket; the updated data bucket is sent to the corresponding storage node to update the data subtree in the storage node.

[0016] According to a third aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the storage medium is located to execute the above-described scalable decentralized inadvertent data storage method.

[0017] According to a fourth aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the above-described scalable decentralized inadvertent data storage method.

[0018] According to a fifth aspect of the present invention, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to implement the aforementioned scalable decentralized inadvertent data storage method by executing the executable instructions.

[0019] The embodiments of this invention provide a scalable, decentralized, unintentional data storage method, comprising: storing a global data tree across different storage nodes based on unintentional random access memory, and centrally maintaining metadata and metadata logs on a semi-trusted control node. Furthermore, the server extracts incremental logs and cached fragments from the control node based on the access address and timestamp, and reads the target data bucket from the corresponding storage node and returns it to the client; after the client replays the logs locally to synchronize metadata, it rewrites the target access path and data bucket, and feeds back to the control node and storage node. Further, by combining data eviction operations triggered by the number of accesses and refresh operations triggered when virtual blocks are exhausted, the randomness of the data block distribution on the tree and the sufficiency of virtual block resources are maintained. This invention, while hiding the access mode, achieves separate storage of data and metadata, incremental synchronization of metadata on demand, and asynchronous parallel access between the control node and storage node, which can resist global passive attackers and has good horizontal scalability and multi-client concurrent access performance.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1 The diagram illustrates a server-side flowchart of an exemplary embodiment of the present invention for a scalable decentralized inadvertent data storage method. Figure 2The illustration shows a secure and lightweight partitioning strategy for a scalable, decentralized, unobtrusive data storage method according to an exemplary embodiment of the present invention. Figure 3 This illustration schematically depicts a client-side diagram of a scalable, decentralized, unintentional data storage method according to an exemplary embodiment of the present invention. Figure 4 This schematic diagram illustrates a comparison between an exemplary embodiment of the present invention—a scalable decentralized inadvertent data storage method—and a synchronization protocol. Figure 5 The diagram illustrates the composition of an electronic device according to an exemplary embodiment of the present invention. Detailed Implementation

[0023] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0024] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0025] Existing ORAM solutions cannot simultaneously meet the core requirements of decentralized scenarios, specifically in the following aspects: (1) Insufficient resistance to global attackers: In open decentralized networks, network traffic and request routing are more transparent, and attackers have a greater ability to monitor a large number of requests from multiple clients at the same time, even approaching the ability of a "global passive observer".

[0026] (2) Limitations of relying on trusted proxies: To reduce client overhead or simplify protocol implementation, some ORAM variants introduce trusted proxies or trusted execution environments (TEEs) to replace the client in executing some sensitive logic. However, in decentralized scenarios, reliable deployment of trusted hardware is not always feasible, and trusted execution environments themselves are also subject to side-channel attack risks. At the same time, introducing any centralized "trusted party" conflicts with the design philosophy of decentralized systems to eliminate central control. Therefore, the applicability of solutions relying on trusted proxies is limited in such scenarios.

[0027] (3) Insufficient horizontal scalability: Traditional ORAM implementations often deploy the complete ORAM structure on a small number of servers. Even if a multi-server or sharding mechanism is adopted in form, the management of data and metadata is still easily concentrated on a few nodes, causing these nodes to become performance bottlenecks. For decentralized storage systems with ever-increasing node and data scale, if the load cannot be evenly distributed to a large number of storage nodes and the system throughput can be linearly increased with the number of nodes, it will be difficult to meet the actual large-scale deployment needs.

[0028] (4) Lack of adaptation to asynchronous access environments: In traditional centralized cloud environments, there is usually a unified request scheduling and load balancing mechanism, and the client-server interaction of the ORAM protocol can assume strong consistency and synchronization. However, in decentralized storage, node online / offline is highly dynamic, and access requests from different clients often arrive asynchronously, lacking a global scheduling center. If the synchronous interaction mode is simply adopted, individual node blocking can easily lead to increased overall access latency, and even affect the correctness and availability of data access in some abnormal situations. Existing solutions still lack a sound mechanism for supporting asynchronous concurrent access by multiple clients while maintaining ORAM security.

[0029] To address the shortcomings and deficiencies of existing technologies, this example implementation provides a scalable, decentralized, unintentional data storage method. (Reference) Figure 1 As shown, the execution entity of this method is the server, and it can specifically include: Step S10: According to the security and lightweight partitioning strategy, initialize the storage nodes and control nodes respectively; wherein, the storage nodes are used to store the data subtrees, and the control nodes are used to store the metadata corresponding to the data subtrees and the metadata logs; wherein, the tree nodes are data buckets used to store real data blocks and virtual blocks, and the metadata logs are used to record the update information of the metadata; Step S12: Send the metadata and metadata logs in the control node to the client via the communication connection; Step S14: In response to the access request sent by the client, based on the last access timestamp and access address in the access request, the corresponding incremental log and cache fragment extracted from the control node, and the corresponding target data bucket extracted from the storage node are sent to the client; wherein, the cache fragment is the metadata in the control node corresponding to the access address. Step S16: Using the updated metadata and metadata log sent by the client, update the metadata and metadata log in the control node respectively; wherein, the updated metadata and metadata log are the metadata update results and corresponding log records generated by the client rewriting the access path corresponding to the access address based on incremental logs and cache fragments. Step S18: Simultaneously, the updated data bucket sent by the client is used to update the data subtree in the storage node; wherein, the updated data bucket is the data bucket obtained by the client after rewriting the data of the real data blocks in the target data bucket.

[0030] Based on steps S10 to S18 above, using unintentional random access memory, the global data tree is stored across different storage nodes, and metadata and metadata logs are centrally maintained on a semi-trusted control node. Furthermore, the server extracts incremental logs and cached fragments from the control node based on the access address and timestamp, and reads the target data bucket from the corresponding storage node and returns it to the client. After the client replays the logs locally to synchronize metadata, it rewrites the target access path and data bucket and feeds it back to the control node and storage node. Further, by combining data eviction operations triggered by the number of accesses and refresh operations triggered when virtual blocks are exhausted, the randomness of the data block distribution on the tree and the sufficiency of virtual block resources are maintained. Under the premise of hidden access mode, separate storage of data and metadata, incremental synchronization of metadata on demand, and asynchronous parallel access between the control node and storage node are achieved. This can resist global passive attackers and has good horizontal scalability and multi-client concurrent access performance.

[0031] The following will describe in more detail the steps of a scalable decentralized inadvertent data storage method in this exemplary embodiment, with reference to the accompanying drawings and embodiments.

[0032] For example, in step S10, initializing the storage node and control node according to the secure lightweight partitioning strategy includes: Step S101: Divide the data tree into multiple data subtrees at a preset partitioning layer, and assign the multiple data subtrees to the corresponding storage nodes; wherein, the data tree is constructed based on the tree bucket structure of the random access memory; Step S102: Read the branch path between the global root node of the data tree and the root node of the subtree of the data tree, and store the branch path to the corresponding storage node. Step S103: The mapping relationship between the data subtree and the corresponding storage node, as well as the index information of the trunk bucket, are stored as metadata in the control node; wherein, the index information of the trunk bucket is the storage node identifier corresponding to the trunk bucket, and the trunk bucket is the data bucket on the branch path. In step S103, the aforementioned trunk bucket refers to the data bucket located on the branch path between the global root node and the root nodes of each data subtree after the Ring ORAM data tree is divided into multiple data subtrees according to a preset partitioning layer.

[0033] Step S104: Initialize the metadata log corresponding to the metadata in the control node.

[0034] Specifically, this approach addresses the shortcomings of existing solutions in data distribution across nodes and parallelization capabilities through a secure and lightweight partitioning strategy. Based on Ring ORAM, this strategy cleverly distributes the tree structure of ORAM across multiple storage nodes, achieving secure data isolation and efficient parallel access.

[0035] Specifically, the implementation process of this secure lightweight partitioning strategy is as follows: Step 1 (Data Tree Splitting): Split a complete Ring ORAM tree into... The layers are split to generate Each is an independent subtree. This represents the number of storage nodes. Each storage node is assigned a data subtree and is responsible for storing all the data buckets within that subtree.

[0036] For details, please refer to Figure 2 As shown. Figure 2 This diagram illustrates the data tree partitioning from a centralized to a decentralized scenario in this invention. The left side represents the centralized scenario (single server): a complete ORAM-based data tree is stored on the same server. The upper part of the tree is labeled "m-branch," indicating several branch nodes above the preset partitioning level; the circled portion represents a "subtree," and the area below the dashed line represents the "trunk," i.e., the path from the global root node to the root nodes of each subtree. Example parameters are given in the diagram. , indicating that the whole tree contains Each node can be divided into Individual trees.

[0037] The right side depicts a decentralized scenario (m storage nodes): the original data tree, centralized on a single server, is divided into multiple subtrees by partitioning, with each subtree mapped to a different storage node via arrows. The diagram labels prid:0, prid:1, prid:2, and prid:3, indicating that different subtrees are assigned to storage nodes numbered 0 through 3, thus distributing the data tree across m storage nodes in a decentralized environment.

[0038] Step 2 (Storing Ancestor Paths): In addition to storing the data subtree, each storage node also needs to synchronize its ancestor path, i.e., the path from the top of the subtree to the root node, also known as the trunk path. This ensures that the security guarantees of ORAM are fully preserved during data access. Furthermore, the synchronization cost of this secure and lightweight partitioning strategy is only [amount missing]. .

[0039] Step 3 (Cross-Node Synchronization): A lazy synchronization strategy is adopted, meaning that the latest copy of a data block is only synchronized across nodes when other storage nodes actually need it. To support this strategy, a public mapping table is maintained on a semi-trusted control node to record the storage node identifiers of the backbone bucket containing the latest data block. Through this public mapping table, any client or storage node that needs to obtain the latest version of a logical data block can first query this mapping table to determine the storage node currently holding the latest copy, and then synchronize the corresponding data block between nodes as needed. This mapping table only contains... The client can directly download the mapping table or its incremental updates from the control node and maintain it locally, thereby significantly reducing the communication overhead of cross-node synchronization while ensuring correctness.

[0040] Furthermore, a metadata log corresponding to the metadata is initialized in the control node to record incremental updates of metadata generated by subsequent access, eviction, and refresh operations. Storage space is allocated for the metadata log on the control node, the log recording format and log sequence number or timestamp fields are set, and the log content is initialized to empty or initial version records. This allows each metadata change to be incrementally appended in subsequent operations, enabling clients to replay the metadata log on demand based on timestamps and achieve synchronous updates of local metadata.

[0041] For example, in step S14, in response to an access request sent by the client, based on the last access timestamp and access address in the access request, the corresponding incremental log and cache fragment extracted from the control node, and the corresponding target data bucket extracted from the storage node, are sent to the client, including: Step S141: Based on the timestamp of the log record in the metadata log, locate the first log record that is greater than the last access timestamp, and determine the log entry that is the first log record to the current log record as the incremental log; Step S142: Based on the access address in the access request and the metadata currently stored in the control node, determine the access path corresponding to the access address and the target storage node corresponding to the access path. Step S143: Extract the cache fragment corresponding to the access path from the control node, and read the target data bucket corresponding to the access path from the target storage node; Step S144: Combine the incremental log, cache fragment, and target data bucket to form a response message; and send the response message to the client.

[0042] Specifically, this invention addresses the inefficiency of globally synchronizing metadata in a multi-client environment by using a bounded incremental metadata mechanism. Unlike existing work that relies on global consistency of metadata, this invention focuses on ensuring that clients always have the latest metadata view before accessing data.

[0043] Specifically, the implementation process of the bounded incremental metadata mechanism is as follows: Step 1 (Log Maintenance): Maintain the PosLog, also known as the metadata log, on the control node. This metadata log records all metadata updates. Each update includes a timestamp. User-operated data address The path number where the data block is located and its position on the data tree. To further reduce the access overhead of stash, the control node also manages a smaller one. The cache uses ORAM to protect stash access, ensuring the security of stash access.

[0044] Step 2 (On-demand synchronization): Upon receiving an access request from a client, obtain the timestamp of the current operation. The client retrieves the data first during access. All previous logs. Therefore, only the necessary logs need to be retrieved from the controller node. The content, namely incremental logs and cached fragments, allows the client's local metadata to be restored to the latest metadata state. This on-demand synchronization strategy avoids expensive global synchronization operations and reduces the synchronization overhead of metadata. Next, the control node finds the data subtree access path corresponding to the access address in the current metadata based on the access address; then, based on the mapping relationship between the data subtree and storage nodes, it determines which storage node (or multiple storage nodes) is responsible for storing the data buckets on this access path, thus obtaining the target storage node corresponding to the access path.

[0045] Step 3 (Parameter Selection): Determine a suitable log size This invention ensures that the probability of failure is relative to a safety parameter. It can be ignored, that is This mechanism ensures data integrity while incurring only storage overhead that is linearly related to the number of clients, and constant communication overhead. It also mitigates the risk of clients being unable to access data correctly due to expired metadata.

[0046] For example, when a data block with logical address addr=5 is rearranged into a data bucket bid'=8 on path pid'=3 after a single access, the control node appends a record (τ, 5, 3, 8) to the PosLog. Other clients, upon subsequent accesses, can then use their locally stored last synchronization timestamp. Press from PosLog Incremental logs are extracted on demand based on the conditions, and these records are replayed locally to update the local metadata to the latest state. To further reduce the access overhead of stash and hide the access pattern of stash, the control node also maintains a smaller StORAM cache, which stores stash-related indexes or state information to provide secure access to stash in the form of ORAM.

[0047] For example, the method further includes: Step S201: Determine the lower limit of the capacity of the metadata log in the control node based on the number of clients and preset security parameters.

[0048] Specifically, for a security parameter Let the number of clients be k. If the clients send requests uniformly and randomly, then when the metadata log size P satisfies expression (1), the probability of failure (expiration) for any client is... .

[0049] (1) in, This is a security parameter; the larger the value, the higher the security. k represents the number of clients, i.e., there are k clients sending requests in the system. The size of the metadata log is the length of time the metadata log is retained. The control node only retains the most recent P metadata update log records. For about Negligible functions, such as .

[0050] Furthermore, in a model with k clients, from which one client is randomly selected uniformly for each request, as long as the length P of the metadata log maintained by the control node is selected to be... This level of precision ensures that the probability of any client failing to synchronize metadata due to "missing too many logs because of prolonged inactivity" does not exceed [a certain threshold]. In other words, the log size grows linearly to... This is enough to make metadata expiration events virtually impossible in a cryptographic sense.

[0051] For example, the method further includes: Step S301: When the number of accesses reaches a preset threshold, receive the eviction control information sent by the client, and determine the eviction path based on the eviction control information; Specifically, the system maintains an "access counter," incrementing the counter by 1 after each access is processed. When the counter reaches a certain threshold (e.g., access count mod A = 0), an eviction is triggered. At this point, the client generates an eviction control message based on its own eviction policy. This message includes the path to be evictioned (corresponding to a path number pid_evct) and necessary parameters (such as subtree information). The server (control node) receives this eviction control message, extracts the identifier of the "path to be eviction," and determines the path to be evicted.

[0052] Furthermore, after retrieving the metadata, the client can directly perform data eviction operations without obtaining the actual data content. This is because subsequent read / write operations are independent of the metadata, allowing the system to separate metadata operations from data operations. That is, the client only needs to ensure the sequential execution of stash and eviction operations. Data read operations can be executed in parallel because they do not modify any data on the storage nodes.

[0053] Step S302: Determine the metadata corresponding to the path to be evicted from the control node; Specifically, because the control node previously stored the mapping relationships between paths and subtrees, subtrees and storage nodes, and information such as the trunk buckets / subtree roots on the path, once it knows the "path to be evicted pid_evct", the control node can find in its own metadata: which buckets (logical structure) are on this path; which data subtree each bucket belongs to; and which storage nodes these subtrees are distributed on.

[0054] Step S303: Read the corresponding data bucket from the storage node according to the eviction height of the data bucket based on the path to be eviction; and send the data bucket to the client; wherein, the eviction height of the data bucket is used to represent the distance of the data bucket relative to the global root node; Specifically, during data eviction, if a block ( ) compared to another block ( If it is closer to the root node, then The expulsion altitude is less than By prioritizing the processing of blocks with lower eviction heights, locks can be released more quickly, allowing other nodes to continue read and write operations, thereby improving parallelization.

[0055] Furthermore, this invention observes that the order in which blocks are read affects eviction performance. Therefore, a finer-grained mutex is employed at the bucket level, prioritizing the reading of blocks with lower eviction heights.

[0056] Furthermore, a Data Recording Log (DRL) is set up and stored on the control node. The DRL contains the results of the most recent user requests, along with updated metadata. This allows clients to continue their asynchronous queries even when data is temporarily unreadable due to eviction updates. The size of the DRL is a predetermined, constant value.

[0057] Step S304: Receive the evicted data block generated by the client after rearranging the data blocks in the bucket; Specifically, after the client obtains the buckets on the path, it performs several tasks locally: It considers the buckets on this path and the blocks in the stash suitable for being put back onto this path; it rearranges real and virtual data blocks according to ORAM rules, deciding which blocks to put back into the tree and where; and it generates the rearranged bucket contents, which are called evicted data blocks, or evicted buckets. Then, the client sends these evicted data blocks back to the server. The server receives the evicted and rearranged bucket contents returned by the client.

[0058] Step S305: Write the evicted data block to the data bucket on the write-only path in the corresponding storage node; wherein, the write-only path is a dedicated access path pre-specified on the storage node that is only used to receive the write of the evicted data block.

[0059] Specifically, to address the idle waiting issue caused by downloading the entire path in the data eviction path, a priority read strategy was introduced. Specifically, each storage node is assigned a write-only path, allowing clients to directly write evicted blocks to this path after retrieving the cache.

[0060] Furthermore, based on the identifier attached to the evicted data block, the server knows which storage node each block should be written back to; it then sends these evicted data blocks to the corresponding storage node; the storage node writes them to a data bucket on its pre-defined write-only path. After this process is completed, some blocks in the stash are evicted onto the data tree, but are only temporarily stored on the write-only path of each storage node. They can be further integrated into the normal path later through other reordering mechanisms, but the goal of moving them from the cache to the tree has been achieved, while avoiding lock contention.

[0061] Furthermore, because data and metadata are stored on different peer nodes, the system can parallelize their operations. During data eviction, once the previous request has written the stash back, the client can simultaneously download from the control node. (The cached ORAM structure) and reading data from the storage node. After the read operation is complete, the client processes the data locally and then writes it back to both the storage node and the control node.

[0062] For example, the method further includes: Step S401: After each access request ends, receive refresh control information from the client; wherein, the refresh control information includes: the identification information of the access path to be refreshed, and the virtual data block exhaustion flag of the data bucket on the access path to be refreshed; Step S402: Based on the current metadata in the control node, determine the data subtree corresponding to the identification information of the access path to be refreshed; and, based on the data subtree and the virtual data block exhaustion flag of the data bucket, determine the data bucket to be refreshed; and send the data bucket to be refreshed to the client. Step S403: Receive the refreshed data bucket sent by the client, and replace the corresponding data bucket on the storage node with the refreshed data bucket; wherein, the refreshed data bucket is obtained by adding virtual data blocks to the data bucket to be refreshed by the client and rearranging the added virtual data blocks and real data blocks.

[0063] Specifically, after completing an Access operation (and potentially an Eviction), the client checks the status information returned by each data bucket along the access path to determine if any data buckets on that path have zero virtual blocks or are below a threshold. If one or more data buckets are found to be virtual block exhausted, the client determines that a refresh operation, EarlyReshuffle(pid), needs to be performed on that path. The client sends a refresh request to the server. The refresh request carries refresh control information, which includes at least: the access path identifier (pid) to be refreshed; the identifier of the data bucket to be refreshed (e.g., its hierarchical position and bucket index on the path); and a bucket status summary (e.g., a virtual block exhaustion flag). The client then sends this refresh control information to the control node.

[0064] On the server side: The control node parses the refresh control information. After receiving the refresh control information from the client, the control node, based on the currently maintained metadata (including the mapping relationship from path to storage node, trunk bucket index, etc.), determines the data subtree corresponding to the access path PID, and identifies one or more storage nodes that store each target data bucket on that path. The control node issues read commands to the corresponding storage nodes, requesting: locking (or temporarily marking) the target data buckets to be refreshed; and reading the current encrypted content of these data buckets from the local data subtree. Each storage node, according to the control node's commands, reads the target data buckets on the path to be refreshed from its local storage and sends these data buckets to the client through a secure channel. At this point, the client obtains the complete encrypted content of the buckets that need to be refreshed.

[0065] Client-side local refresh: Based on the current real data block identifiers and virtual block markers within the bucket, restore the real data blocks in the bucket; regenerate a sufficient number of virtual blocks for the bucket (or each bucket along the path); and rearrange the real data blocks and newly generated virtual blocks according to a random permutation rule. After processing, the client receives the refreshed data bucket and the corresponding metadata update information. For example, the virtual block count is restored; the block positions and flags within the bucket change. The client then packages the refreshed data buckets according to their respective storage nodes and sends the metadata update information back to the server: refreshed data bucket → corresponding storage node; metadata update information → control node.

[0066] After receiving the refreshed data bucket from the client, each storage node: replaces the content of the corresponding old bucket in its local data subtree with the refreshed data bucket; unlocks the bucket, restoring normal service to other access requests. The control node updates the metadata and metadata log, applying the update to the currently maintained global metadata (such as virtual block status, bucket layout markers, etc.); and appends the metadata changes generated by this refresh operation to the metadata update log (PosLog) so that other clients can synchronize to the latest refreshed state when replaying the log on demand.

[0067] This example implementation provides a scalable, decentralized, unobtrusive data storage method. (See reference...) Figure 3 As shown, the execution subject of this method is the client, and it can specifically include: Step S50: Establish communication connections with the control node and storage node, obtain metadata and metadata logs generated by the control node based on the security lightweight partitioning strategy through the communication connections, and cache the obtained metadata and metadata logs locally; Step S52: Determine the access address based on metadata and metadata logs, construct an access request by combining the operation type and the last access timestamp recorded locally, and send the access request to the server. Step S54: Receive the incremental logs and cache fragments extracted from the control node and the target data bucket extracted from the storage node, returned by the server based on the access request; synchronize the local cached metadata based on the incremental logs and cache fragments; determine the access path corresponding to the access address using the synchronized metadata. Specifically, this step occurs on the client side. First, it receives the incremental log returned from the control node by the server. This log is stored in the control node's PosLog, and the timestamp is greater than the client's last access time. The metadata update record; the cache fragment (cache metadata fragment) from the control node: a small piece of metadata related to a path, subtree mapping, etc., associated with the current access address; the target data bucket from the storage node: this is the data bucket on the path that this access is actually going to read / write, containing the target data block and some virtual blocks.

[0068] Then, the client uses incremental logs and cached fragments to catch up with the latest local metadata. The client maintains a cached metadata (PosMap / path mapping, etc.) locally; after obtaining the incremental logs from the control node, it replays these logs locally in chronological order; and then, combined with the current path / subtree mapping provided in the cached fragments, it synchronizes its local metadata to the latest state consistent with the control node.

[0069] Finally, the latest metadata is used to calculate which path to take this time: with the synchronized metadata, the client can find out which ORAM path (which leaf) the current address is mapped to based on the access address addr; thus determining the access path corresponding to the access address, that is, the path from the root to the leaf.

[0070] Step S56: Rewrite the access path, update the synchronized metadata with the rewritten access path; append and update the locally cached metadata log based on the mapping change of the access path; send the updated metadata and metadata log to the control node to update the metadata and metadata log in the control node. Specifically, the access path is rewritten. According to the ORAM protocol, after each access to the logical address addr, a new path must be randomly selected for it. Originally: addr → pid; Rewritten: addr→pid′.

[0071] This way, even if an attacker sees multiple accesses to the same address, the path seen in the tree keeps changing, making it difficult to correlate. The client, in its locally synchronized metadata, changes the path of address to the new pid'; this change is recorded as a metadata log entry. For example, (timestamp τ, address, pid', bid'...).

[0072] The client appends this log entry to its local metadata log cache. It then sends the latest metadata and the newly written log entry back to the control node. The control node uses these two parts to update its global metadata (synchronizing the new path mapping of addr); it appends this change to the control node's PosLog (metadata update log) for other clients to replay as needed.

[0073] Step S58: When the operation type is a write operation, the actual data block in the target data bucket is rewritten with the data to be written in the access request to generate an updated data bucket; the updated data bucket is sent to the corresponding storage node to update the data subtree in the storage node.

[0074] Specifically, when the operation type is write, the client has already obtained the target data bucket, which contains real data blocks and virtual blocks. Now, the client examines the 'data' in the access request, finds the real data block corresponding to 'addr' in the bucket, changes its plaintext content to the data to be written, re-encrypts it according to the protocol, and puts it back into the bucket, resulting in an updated data bucket (the content has been modified, but the form is still a mixture of "real blocks + virtual blocks"). The updated bucket is sent back to the corresponding storage node for writing. The storage node uses this bucket to overwrite the original bucket, thus completing the action of updating the data in the server's ORAM tree.

[0075] The method provided in the embodiments of the present invention is referred to Figure 4 As shown. Figure 4 The left side shows the timeline under the synchronous access protocol, and the right side shows the timeline under the asynchronous access protocol. Specifically, Synchronous access protocol: Under this protocol, user requests cannot be executed in parallel and must wait for the previous request to finish (complete all data reading or updating) before they can be executed. Figure 4 It contains an access request and an eviction request.

[0076] Access requests require first reading metadata from the controller node (Read Meta), then reading data from the storage node (Read Data), and finally updating the metadata (Write Meta). Note that RingORAM access requests do not update data; only the metadata is updated.

[0077] The eviction request also first reads the metadata, then determines the data to be read and written (this is equivalent to generating a read and write plan in advance, but without actually completing the request, which is a feature of RingORAM), then reads the data and writes it back to the storage node (Write Data), and finally updates the metadata.

[0078] Asynchronous access protocol: Figure 4 The right side of the middle section illustrates four ways in which the asynchronous protocol in this invention overcomes the idle waiting time present in synchronous protocols: (1) Between multiple access requests, the synchronization protocol must wait for the previous request to finish. However, since the update of metadata does not depend on the data content, the client can directly access and update the metadata at the beginning. And since subsequent data reading does not modify the data content, the data reading part of the user's access request can be parallelized. After the data reading is completed, the client can update the StORAM in the order of the requests.

[0079] (2) Between access requests and EarlyReshuffle requests, the synchronous protocol requires the client to wait for the client to download the Stash from the control node and then update the data. Under the asynchronous protocol, the user can download data from both the storage node and the control node simultaneously (Read Data & Read Stash), then update the data locally (this process is very fast) and then write the updated data back to the StORAM (Write Data & Write Stash).

[0080] (3) Since Eviction needs to download data blocks along an entire path, the amount of data downloaded to the storage node is usually greater than the amount of data downloaded from the control node. Therefore, the degree of parallelization can be further improved, and after retrieving all the data from the Stash, the data can be written back to the storage node immediately.

[0081] (4) After the Stash write-back is completed, the client can continue to make access requests as long as the data to be read is different from the data being written back. In addition, the order in which data blocks are read during the reading process also affects the degree of parallelization. Therefore, this invention subsequently determined a priority reading strategy, which can prioritize reading data close to the root, thereby freeing up more access requests from subsequent users.

[0082] Specifically, the method provided in this embodiment of the invention has the following specific process: (1) The client initializes the storage node and the control node; (2) The client performs data access, which logically includes two operations: reading and writing. These two operations are converted into access operations, eviction operations and early reshuffle operations.

[0083] Specifically, the client initiates an access operation. .in, For logical operation types, The address to be accessed. This is the data that needs to be written (for read operations, a random number is sent to maintain consistency). It is the timestamp of the client's last access to the data: Metadata is locked using Meta.lock.

[0084] The client is based on Read the logs and download the metadata (StPosMap, StStash) of StORAM, including the current timestamp. And the Data Record Log (DRL).

[0085] Restore the local PosMap to the latest state based on the logs.

[0086] Reassign a random path pid' to addr, and denote the previous path as pid.

[0087] The update log specifies that if the current operation is an access operation, a single log entry is written; if the current operation is an eviction operation, multiple log entries are written to ensure security (for eviction...). For EarlyReshuffle, indivual.

[0088] Metadata unlocks Meta.unlock.

[0089] Data (data) is read based on the PID and Addr. If it's a read operation, data is returned to the client; if it's a write operation, then... .

[0090] Lock StORAM, update StORAM, unlock StORAM.

[0091] if If the virtual blocks are exhausted, Eviction is executed; if the virtual blocks are exhausted, EarlyReshuffle is executed.

[0092] Eviction operation: The client, based on... Determine the path that needs to be evicted, read all data blocks on that path to the local machine, read the Stash data from the control node, and write the data back after updating.

[0093] The plan for subsequent read and write operations is determined based on the metadata obtained from the control node.

[0094] StORAM locks, and buckets on the path are locked.

[0095] Read StORAM and the evicted path in parallel; if StORAM is finished reading, wait for the read data bucket of the i-th level in the evicted path (from the root to the leaf node, so as to free up more subsequent access operations), write the current bucket to the corresponding bucket in the write-only path wo_path and unlock the bucket.

[0096] Write back the updated StRAOM and metadata.

[0097] Unlock StORAM and synchronize wo_path.

[0098] The EarlyReshuffle(pid) operation checks if any buckets on the accessed path have run out of virtual blocks after a single access operation. If such buckets exist, they are flushed.

[0099] The beneficial effects of this invention are as follows: (1) Enhance the ability to protect against global passive attackers. This invention treats the control node and multiple storage nodes as a single ORAM server. On the client side, it rewrites the access path for each access and combines this with periodic data eviction and on-demand refresh mechanisms to maintain the continuous randomization of the logical address-to-data-tree path and the randomness of the data block distribution within the tree. Even if an attacker can simultaneously monitor the access trajectories of the control node and all storage nodes, the observed access patterns remain statistically indistinguishable from access sequences to random addresses. This overcomes the shortcomings of existing ORAM schemes in resisting global passive attackers in decentralized scenarios.

[0100] (2) No trusted proxy required, enhancing the applicability of decentralized deployment. This invention does not rely on a Trusted Execution Environment (TEE) or other centralized trusted proxies. Instead, it achieves metadata management and hides data access patterns through protocol interactions between the client, a semi-trusted control node, and multiple storage nodes. Metadata consistency is guaranteed through "incremental metadata logs + local replay," while access path randomization and virtual data block recovery are performed locally on the client. This avoids dependence on trusted hardware and is more suitable for deployment in open, decentralized network environments.

[0101] (3) Possesses good horizontal scalability and load balancing capabilities. This invention achieves a natural splitting of data and computational load across multiple nodes by dividing the global ORAM data tree into multiple data subtrees at a preset partitioning layer and allocating each data subtree to different storage nodes. The control node only maintains the "subtree". Lightweight metadata such as "storage nodes" and "trunk bucket indexes" are used, with each storage node responsible only for reading and writing data buckets within its local subtree. As the number of storage nodes increases, horizontal scaling can be achieved by increasing the number of data subtrees, preventing a few nodes from becoming performance bottlenecks and improving the overall system throughput.

[0102] (4) Metadata is synchronized incrementally on demand, reducing communication and storage overhead. This invention maintains a bounded metadata update log, PosLog, at the control node. Each update record contains only concise information such as timestamp, access address, path number, and bucket position. Before accessing a client, it only needs to obtain the incremental log since the last timestamp and necessary cached fragments, and replay them locally to synchronize the metadata state, avoiding frequent full metadata synchronization. By reasonably selecting the log length P, the probability of any client failing to access due to expired metadata is negligible. At the same time, the metadata storage and synchronization overhead is linearly related to the number of clients, meeting the performance requirements of large-scale multi-client scenarios.

[0103] (5) Data and metadata are stored separately to enable parallel and asynchronous access across nodes. This invention stores the data subtree to which the data block belongs across multiple storage nodes, while centrally storing metadata such as location mapping, trunk bucket index, and update logs on the control node. By separating data operations from metadata operations, this invention supports parallel processing between control nodes and storage nodes, as well as asynchronous interaction between clients and servers, effectively reducing tail latency for single accesses and improving the performance of concurrent access from multiple clients.

[0104] (6) Efficient data eviction and refresh mechanism to control cache size and maintain ORAM masking capability. This invention triggers a data eviction operation when the number of accesses reaches a preset threshold. Based on eviction control information and metadata, it determines the path to be eviction and reads the data bucket from the storage node according to the eviction height. The client then rearranges the data blocks in the stash locally, generating a write-only path for writing the evictioned data block to the storage node. This achieves a gradual "replacement" from the cache to the data tree, effectively controlling the scale of the stash. For data buckets where virtual data blocks are exhausted, this invention triggers a refresh process through refresh control information. The data bucket to be refreshed is sent to the client to replenish virtual blocks, reshuffled, and then written back. This maintains the mixed distribution of real / virtual blocks within the bucket and the masking capability of ORAM, ensuring security and stability during long-term operation.

[0105] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0106] It should be noted that although several modules or units of the device for performing actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0107] Figure 5 A schematic diagram of an electronic device suitable for implementing embodiments of the present invention is shown.

[0108] It should be noted that, Figure 5 The electronic device 1000 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0109] like Figure 5As shown, the electronic device 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage section 1008 into Random Access Memory (RAM) 1003. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004. Furthermore, the electronic device 1000 also includes an FPGA device and a System-on-a-Chip (SoC) device.

[0110] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.

[0111] In particular, according to embodiments of the present invention, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs various functions defined in the system of this application.

[0112] Specifically, the aforementioned electronic devices can be airborne intelligent electronic devices.

[0113] It should be noted that the storage medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein computer-readable program code is carried. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0116] It should be noted that, as another aspect, this application also provides a storage medium, which may be included in an electronic device or may exist independently without being assembled into the electronic device. The aforementioned storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the methods described in the following embodiments. For example, the electronic device may perform... Figure 1 The steps of the method shown.

[0117] In one embodiment, this application provides a computer program product including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0118] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0119] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0120] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A scalable, decentralized, unintentional data storage method, characterized in that, The method includes: Based on the secure and lightweight partitioning strategy, storage nodes and control nodes are initialized separately. Storage nodes are used to store data subtrees, and control nodes are used to store the metadata corresponding to the data subtrees and metadata logs. Tree nodes are data buckets used to store real data blocks and virtual blocks, and metadata logs are used to record metadata update information. The metadata and metadata logs in the control node are sent to the client via the communication connection; In response to an access request sent by a client, based on the last access timestamp and access address in the access request, the corresponding incremental log and cache fragment extracted from the control node, as well as the corresponding target data bucket extracted from the storage node, are sent to the client; where the cache fragment is the metadata in the control node corresponding to the access address; The updated metadata and metadata logs sent by the client are used to update the metadata and metadata logs in the control node, respectively. The updated metadata and metadata logs are generated by the client rewriting the access path corresponding to the access address based on the incremental log and cache fragments, and the corresponding log records. Simultaneously, the updated data bucket sent by the client is used to update the data subtree in the storage node; the updated data bucket is the data bucket obtained by the client after rewriting the actual data blocks in the target data bucket.

2. The method according to claim 1, characterized in that, The initialization of storage nodes and control nodes according to the secure lightweight partitioning strategy includes: The data tree is divided into multiple data subtrees at a preset partitioning layer, and these subtrees are assigned to corresponding storage nodes; the data tree is constructed based on the tree bucket structure of the random access memory. Read the branch path between the global root node of the data tree and the root node of the subtree of the data tree, and store the branch path to the corresponding storage node; The mapping relationship between data subtrees and corresponding storage nodes, as well as the index information of the trunk bucket, are stored as metadata in the control node; where the index information of the trunk bucket is the storage node identifier corresponding to the trunk bucket, and the trunk bucket is the data bucket on the branch path. Initialize the metadata log corresponding to the metadata in the control node.

3. The method according to claim 1, characterized in that, In response to an access request sent by the client, based on the last access timestamp and access address in the access request, the corresponding incremental logs and cache fragments extracted from the control node, and the corresponding target data bucket extracted from the storage node, are sent to the client, including: Based on the timestamp of the log record in the metadata log, locate the first log record with a timestamp greater than the last access timestamp, and determine the log entry from the first log record to the current log record as the incremental log; Based on the access address in the access request and the metadata currently stored in the control node, determine the access path corresponding to the access address and the target storage node corresponding to the access path; Extract the cache fragment corresponding to the access path from the control node, and read the target data bucket corresponding to the access path from the target storage node; The incremental logs, cached fragments, and target data buckets are combined to form a response message, which is then sent to the client.

4. The method according to claim 1, characterized in that, The method further includes: The lower limit of the metadata log capacity in the control node is determined based on the number of clients and preset security parameters.

5. The method according to claim 1, characterized in that, The method further includes: When the number of accesses reaches a preset threshold, the system receives eviction control information sent by the client and determines the eviction path based on the eviction control information. Determine the metadata corresponding to the path to be evicted from the control node; Based on the path to be evicted, the corresponding data bucket is read from the storage node according to the data bucket eviction height; and the data bucket is sent to the client; where the data bucket eviction height is used to represent the distance of the data bucket relative to the global root node; The client receives the evicted data blocks generated after rearranging the data blocks in the bucket; Write the evicted data block to the data bucket on the write-only path in the corresponding storage node; where the write-only path is a dedicated access path pre-specified on the storage node that is only used to receive the write of the evicted data block.

6. The method according to claim 1, characterized in that, The method further includes: After each access request ends, refresh control information is received from the client; the refresh control information includes: the identification information of the access path to be refreshed, and the virtual data block exhaustion flag of the data bucket on the access path to be refreshed; Based on the current metadata in the control node, determine the data subtree corresponding to the identification information of the access path to be refreshed; and, based on the data subtree and the virtual data block exhaustion flag of the data bucket, determine the data bucket to be refreshed; and send the data bucket to be refreshed to the client. The system receives the refreshed data bucket sent by the client and replaces the corresponding data bucket on the storage node with the refreshed data bucket. The refreshed data bucket is obtained by adding virtual data blocks to the data bucket to be refreshed by the client and rearranging the added virtual data blocks and real data blocks.

7. A scalable, decentralized, unintentional data storage method, characterized in that, The method includes: Establish communication connections with the control node and storage node, obtain metadata and metadata logs generated by the control node based on the security lightweight partitioning strategy through the communication connections, and cache the obtained metadata and metadata logs locally; The access address is determined based on metadata and metadata logs. An access request is constructed by combining the operation type and the last access timestamp recorded locally, and the access request is sent to the server. The system receives incremental logs and cache fragments extracted from the control node and the target data bucket extracted from the storage node, returned by the server based on the access request; it then synchronizes the locally cached metadata based on the incremental logs and cache fragments; and finally uses the synchronized metadata to determine the access path corresponding to the access address. The access path is rewritten, and the rewritten access path is updated to the synchronized metadata; the local cached metadata log is appended and updated based on the mapping change of the access path; the updated metadata and metadata log are sent to the control node to update the metadata and metadata log in the control node. When the operation type is a write operation, the actual data block in the target data bucket is rewritten with the data to be written in the access request to generate an updated data bucket; the updated data bucket is sent to the corresponding storage node to update the data subtree in the storage node.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 7.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images