Data hierarchical dynamic storage method and system based on block chain

Abstract

The invention discloses a block chain-based data hierarchical dynamic storage method and system, and the method comprises the steps: obtaining to-be-stored data, segmenting the to-be-stored data into a plurality of to-be-stored file blocks, generating a hash value for each to-be-stored file block, and taking the hash value as a unique identifier of the data block; comparing the hash value of the to-be-stored file block with a hash value existing in a database to identify whether the hash value of the to-be-stored file block is consistent with the hash value existing in the database, and if so, updating the data of the to-be-stored file block to a storage position corresponding to the existing hash value; and if not, storing the data of the to-be-stored file to the block chain.

Description

Technical Field

[0001] The present invention relates to the field of blockchain storage technology, and in particular to a blockchain-based data hierarchical dynamic storage method and system. Background Art

[0002] Blockchain technology has been widely used in many fields such as the Internet of Things, digital finance, smart manufacturing, supply chain, healthcare, digital transactions, etc. Although blockchain has the characteristics of decentralization, immutability and security, these characteristics are also the main reasons for the growing storage demand of blockchain. In the existing alliance chain, each node must save the complete data of the entire blockchain. As the running time of the blockchain increases, the number of blocks that the node needs to store increases linearly. Taking Bitcoin and Ethereum as examples, the storage overhead of these two platforms currently exceeds 400GB and 1TB respectively. Nodes need more storage space to cope with the growing storage demand. Since the growth rate of node storage load in the blockchain exceeds the current hardware development speed, this has greatly restricted the development of blockchain technology.

[0003] The nodes in the blockchain store data in the form of copies. As time goes by, the number of blocks in the blockchain continues to increase, causing the storage pressure on the nodes to increase accordingly, which puts a lot of pressure on the storage of large amounts of data. Summary of the invention

[0004] In order to solve the deficiencies of the prior art, the present invention provides a data hierarchical dynamic storage method and system based on blockchain;

[0005] On the one hand, a data hierarchical dynamic storage method based on blockchain is provided, including:

[0006] Acquire the data to be stored, divide the data to be stored into a plurality of file blocks to be stored, and generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block;

[0007] The hash value of the file block to be stored is compared with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database. If they are consistent, the data of the file block to be stored is updated to the storage location corresponding to the existing hash value; if they are inconsistent, the data of the file to be stored is stored on the blockchain.

[0008] On the other hand, a data hierarchical dynamic storage system based on blockchain is provided, including:

[0009] An acquisition module is configured to: acquire data to be stored, divide the data to be stored into a plurality of file blocks to be stored, and generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block;

[0010] The comparison module is configured to: compare the hash value of the file block to be stored with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database; if they are consistent, update the data of the file block to be stored to the storage location corresponding to the existing hash value; if they are inconsistent, store the data of the file to be stored on the blockchain.

[0011] The above technical solution has the following advantages or beneficial effects:

[0012] The present invention proposes an efficient storage method, which uses logical block address LBA (Logical Block Address) to avoid storing duplicate file blocks. According to the access frequency of block data, the hotness and coldness of the block are quickly identified, and then the number of shared copies between nodes is determined according to the threshold time and heat, so as to significantly reduce the total storage cost.

[0013] This paper proposes a reliable storage method for multimodal data by uploading files of different modalities, including text, pictures, videos, and audios; then, the model is compared with traditional storage methods. The experimental results clearly show that compared with traditional methods, the model of this paper has significant advantages in storage optimization and scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0015] Figure 1 This is a flowchart of hierarchical dynamic collaborative storage according to Embodiment 1;

[0016] Figure 2 This is a hierarchical dynamic collaborative storage model diagram of the first embodiment;

[0017] Figure 3 This is an object management flow chart of embodiment 1. DETAILED DESCRIPTION

[0018] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0019] Terminology explanation:

[0020] Blockchain: A decentralized technology that ensures secure and transparent management of data through continuous blocks and cryptographic links.

[0021] Blockchain node: A device or computer in the network that participates in maintaining and verifying blockchain data.

[0022] Block: The basic unit for storing transaction data in the blockchain.

[0023] Embodiment 1

[0024] This embodiment provides a data hierarchical dynamic storage method based on blockchain;

[0025] The data hierarchical dynamic storage method based on blockchain includes:

[0026] S101: Acquire data to be stored, divide the data to be stored into a plurality of file blocks to be stored, generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block;

[0027] S102: Compare the hash value of the file block to be stored with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database. If they are consistent, update the data of the file block to be stored to the storage location corresponding to the existing hash value; if they are inconsistent, store the data of the file to be stored on the blockchain.

[0028] Furthermore, the data to be stored is multimodal data; the multimodal data includes: text data, audio data and video data.

[0029] Furthermore, the data to be stored is divided into a plurality of file blocks to be stored, which is to divide the data to be stored into a plurality of file blocks of set capacity by using a logical block address (LBA).

[0030] It should be understood that the data to be stored is divided into a number of file blocks to be stored in order to ensure data management efficiency and processing speed.

[0031] It should be understood that the logical block address LBA is a method used on computer storage devices (such as hard disk drives) to address and access data blocks in storage space. It allows operating systems and applications to use logical block numbers to access specific data blocks on storage devices without having to worry about the details of physical storage locations. The logical block address LBA is a common storage access method that simplifies data access operations and improves the efficiency of storage devices.

[0032] Furthermore, the method of dividing the data to be stored into a plurality of file blocks of set capacity by using a logical block address LBA method specifically includes:

[0033] Set the capacity of each file block;

[0034] The data to be stored is divided according to the set file block capacity; if the capacity of the data to be stored is not an integer multiple of the file block size, the last file block is smaller than the set file block capacity;

[0035] A unique logical block address (LBA) is generated for each file block. The logical block address is a continuous sequence of numbers used to uniquely identify the location of each file block on the storage device.

[0036] Furthermore, a hash value is generated for each file block to be stored, and the file block to be stored is input into the MD5 algorithm to obtain the hash value.

[0037] It should be understood that the MD5 algorithm is a hash function used to convert a message (or data) of any length into a 128-bit (16-byte) hash value of a set length.

[0038] It should be understood that in order to ensure the integrity and uniqueness of each block, this embodiment generates an MD5 hash value for each such file block. MD5 hash provides a 128-bit digital fingerprint of the data block, which can be used as a unique identifier of the data block. By applying the MD5 algorithm encoding to the input data, the generated hash value ensures that the same input will produce the same hash result.

[0039] It should be understood that the hash value of the file block to be stored is compared with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database. If they are consistent, the data of the file block to be stored is updated to the storage location corresponding to the existing hash value; if they are inconsistent, the data of the file to be stored is stored in the blockchain, including:

[0040] Compare the hash value to the hash values ​​already in the database to identify a unique block of data:

[0041] If a data block is verified to be unique, the data block will be encrypted and stored on the corresponding blockchain node to ensure the immutability and security of the data.

[0042] If a data block is verified to be non-unique, the information of the data block is updated to the existing data block record in the database without duplicate storage.

[0043] Furthermore, the method further comprises:

[0044] S103: Classify the blockchain nodes into four levels of shards: first-level shards, second-level shards, third-level shards, and fourth-level shards, each level of shards includes a number of blockchain nodes; wherein, from the first-level shards to the fourth-level shards, the access heat of the blocks stored in the nodes decreases in sequence;

[0045] S104: At time t0, data object a is stored in the blockchain node of the first-level shard, and the initial block access heat value BH is configured for data object a; at time t0, data object a is also backed up and stored in the blockchain nodes of the second, third and fourth-level shards, and the initial block access heat value BH is configured for data object a;

[0046] S105: At time t1, t1>t0, the blockchain node of the first-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH0 of the first-level shard within the set threshold time range; if it reaches it, no processing is performed; if it does not reach it, the data object a is deleted from the blockchain node of the first-level shard;

[0047] S106: At time t2, t2>t1, the blockchain node of the second-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH1 of the second-level shard within the set threshold time range; if it reaches, no processing is performed; if it does not reach, the data object a is deleted from the blockchain node of the second-level shard;

[0048] S107: At time t3, t3>t2, the blockchain node of the third-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH2 of the third-level shard within the set threshold time range; if it reaches it, no processing is performed; if it does not reach it, the data object a is deleted from the blockchain node of the third-level shard;

[0049] S108: At time t4, t4>t3, the blockchain node of the fourth-level shard does not delete the data stored in the current blockchain node.

[0050] It should be understood that the benefit of the operation of S103 to S108 is that by storing data objects on shard nodes of different levels according to their access popularity, storage resources can be used more efficiently. Data objects with high access frequency are stored in the first-level shards with faster access speeds, while data objects with low access frequency are stored in shards of subsequent levels, thereby reducing the overall storage cost. Data objects with high access popularity are usually accessed more frequently. Storing them on nodes with faster access speeds can improve the efficiency and response speed of data access and enhance the user experience. By setting the access heat thresholds of shards of different levels, the system can dynamically adjust the storage location of the data according to the actual usage of the data.

[0051] Furthermore, the calculation process of the threshold time range set in S105 to S107 includes:

[0052] Assume that the threshold time range is set to be 0 to t, where the unit of t is hours; the left endpoint value of the threshold time range is set to be 0; the right endpoint value of the threshold time range is set to be t; and t is an unknown quantity;

[0053] Set the probability D(t,α) of at least one access to the first-level shard to 50%, the probability D(t,α) of at least one access to the second-level shard to 74.95%, the probability D(t,α) of at least one access to the third-level shard to 93.75%, and the probability D(t,α) of at least one access to the fourth-level shard to 100%;

[0054] The exponential distribution cumulative distribution function (CDF) is used to estimate the probability D(t,α) that the current level shard will be accessed at least once in a given time period:

[0055] D(t,α)=1-e -αt ;

[0056] Among them, α is the rate parameter, α represents the average frequency of events occurring per unit time; α = 0.2;

[0057] Using expression 1-e -αt To predict the probability of at least one event occurring within a specified time of 0 to t hours, to predict the probability of at least one visit within a given time of 0 to t hours.

[0058]

[0059] Among them, α i is the rate parameter of the i-th time period, w iis the weight of the i-th time period, n is the total number of time periods, and for the access data of different time periods, the value of α is determined by weighted average, which more accurately reflects the access frequency of different time periods, making the prediction results more in line with the actual situation.

[0060] Based on the data access frequency D(t,α), calculate the corresponding threshold time:

[0061] Fix α to 0.2 and calculate the threshold time t of each shard SL, where D(t,0.2) represents the cumulative probability of accessing the object with α=0.2 within time t.

[0062] For example, setting the time unit (T) to one hour, the time window corresponding to the access frequency of 50% is the past 3.47 hours, and the access frequency of 93.75% corresponds to the past 13.86 hours. Therefore, the nodes in shard SL0 will store data accessed in the past 3.47 hours, while the nodes in SL2 will store objects accessed in the past 13.86 hours.

[0063] Furthermore, the block access heat value, the specific calculation process includes:

[0064] Block access heat value HD i , obtained by calculating the number of accesses to the block in each time period;

[0065]

[0066] The block access heat value HD is calculated by multiplying the number of visits in each cycle by the corresponding access frequency weight and adding it to the current cycle cur. i ;f ij represents the number of times block i is accessed in the jth cycle, while cur-j represents the time interval from the current cycle to the previous cycle, and cur represents the current time cycle;

[0067] As j approaches cur, i.e., the event is newer, the value of cur-j decreases, so e -α(cur-j) The increase in the value of means that the impact of early visits on the current popularity gradually decreases. is the decay rate, a positive number that determines the rate of decay, The larger the value, the faster the decay weight of the old data decreases. In order to normalize the heat value to the range of 0 to 1, normalization is used:

[0068] HD max =max(HD i ), HD min =min(HD i )

[0069]

[0070] Among them, HD max Indicates the current maximum heat, HD i Indicates current popularity, HD min Indicates the current minimum heat, HD i,norm Indicates the heat threshold that should be set.

[0071] It should be understood that as time goes by, the number of visits to online content shows an exponentially decreasing trend. Using the exponentially decaying access model, the decay coefficient e is set for each past cycle before the current cycle according to Newton's cooling law. -α(cur-j) The closer the cycle is to the current cycle, the higher the access frequency weight is, and the farther the cycle is from the current cycle, the lower the access frequency weight is.

[0072] Furthermore, the set block access heat threshold of the first-level shard is 0.75-1.

[0073] The threshold time range set for the first level sharding is 0-3.47 hours.

[0074] Furthermore, the set block access heat threshold of the second level shard is 0.5-1.

[0075] The threshold time range set for the second level sharding is 0-6.93 hours.

[0076] Furthermore, the set block access heat threshold of the third level shard is 0.25-1.

[0077] The threshold time range set for the third level sharding is 0-13.86 hours.

[0078] Furthermore, the set block access heat threshold of the fourth level shard is 0-1.

[0079] The threshold time range set for the fourth level sharding is all time.

[0080] Exemplarily, based on the number of shards, the present invention divides the activity of the block into four levels. Nodes in SL0 store data with a heat value of 0.75 and accessed within the past 3.47 hours; while nodes in SL2 store data with a heat value of 0.25 and accessed within the past 13.86 hours. Such a setting helps balance storage requirements and node performance, ensuring the efficiency and data availability of shards at all levels. SL3, as the highest level of sharding, maintains a complete copy of the blockchain content to ensure data availability in the network.

[0081] Furthermore, the method further comprises:

[0082] S109: The blockchain node i of the first-level shard obtains a query request;

[0083] Determine whether the object to be queried exists in the blockchain node i of the first-level shard. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node j of the first-level shard; where blockchain node j is the node closest to blockchain node i;

[0084] Determine whether the object to be queried exists in the blockchain node j of the first-level shard. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node k of the second-level shard; where blockchain node k is the node closest to blockchain node i;

[0085] S110: Determine whether the object to be queried exists in the blockchain node k of the second-level sharding. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node l of the third-level sharding; wherein the blockchain node l is the node closest to the blockchain node i;

[0086] S111: Determine whether the object to be queried exists in the blockchain node l of the third-level sharding. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node of the fourth-level sharding, and the blockchain node of the fourth-level sharding returns the query result and query cost.

[0087] It should be understood that the benefits of the operation of S109 to S111 are: searching for the object to be queried in the blockchain nodes of the first-level shards, and directly returning the result if found, avoiding the time delay of passing the query request to other shard nodes, thereby speeding up the query response speed. By processing the query request in the nearest blockchain node, the number of data transmissions and the transmission distance on the network can be reduced, thereby saving network bandwidth and communication costs. Distributed query optimization can evenly distribute the query load on different levels of shard nodes for processing, avoiding excessive load on a single node, and improving the stability and throughput of the overall system.

[0088] According to the availability of nodes, they are classified into different levels of shards SL. In the simplified model, it is assumed that the present invention can know the availability of nodes in advance. Different shard SL levels set different thresholds, including threshold time and heat;

[0089] like Figure 1 As shown in the figure, in the file storage part, the multimodal file is subdivided into fixed-size file blocks through LBA, and an MD5 hash value is generated, which is stored in the node and the block is chained. Figure 2 As shown in the sharding part, different shards are divided according to different threshold times and threshold temperatures. SL represents different shards, N represents nodes, and K represents the cost caused by the query.

[0090] Lower-level shard SLs typically include a large number of nodes with low availability, such as personal computers or desktops, which have relatively short threshold times. In contrast, higher-level shard SLs contain fewer but highly available nodes, such as dedicated servers, which have longer threshold times and can therefore store more objects. In the highest-level shard SLs, nodes do not delete any objects based on thresholds to ensure maximum data availability. In addition, because the block heat (BH) value of an object is updated regularly, frequently accessed objects will continue to remain in local storage. This not only helps reduce storage requirements, but also effectively reduces query costs. In each shard SL, nodes decide whether to delete objects based on the access situation of objects in local storage and the threshold time; if the access frequency of an object does not reach the threshold heat or exceeds the threshold time, it will be deleted. This mechanism optimizes data management while maintaining efficient operation of the system.

[0091] When a node cannot query the required object in the current SL, it can query other nodes in a specific shard SL for the object through the content addressing method. The content addressing method generates a unique hash value for each object and node, and uses the XOR distance of these hash values ​​to determine the distance between nodes, thereby achieving efficient data storage and retrieval. When a node needs to query an object, it will gradually query nodes that are closer to the target hash value until the target object is found. This method effectively optimizes the data management and access efficiency in distributed systems. Each object and node is identified by a unique hash value, and the XOR operation of these hash values ​​is used to calculate the distance between nodes. Therefore, nodes can retrieve objects by the hash value of the object.

[0092] The formula for calculating the distance between nodes is based on the exclusive OR (XOR) operation of the hash value. The hash values ​​of two nodes are XORed. The closer the hash values ​​of the nodes are, the smaller their XOR results are, which means the distance is closer; conversely, the larger the XOR result is, the farther the distance is.

[0093] like Figure 1 As shown, when a node queries an object that is not stored locally, each node can only initiate a remote query to nodes in the same SL or a SL at a higher level.

[0094] Node N0 first searches for the nearest node in the same SL to query the object, assuming it is node N1.

[0095] If node N1 owns the object, a query is performed in the current node and the query cost is recorded as Cost0.

[0096] If node N1 does not have the object, N0 goes to the next layer SL k+1 The query is initiated by the nearest node N2. If node N0 successfully retrieves the object through node N2, the query cost is increased to Cost1.

[0097] In extreme cases, if the object needs to be obtained from node N4 at a farther distance SLk+3, the query cost will increase further.

[0098] This query mechanism ensures that the node closest to the object hash value is more likely to store the object. In the content addressing method, objects and nodes are identified by hash values. Since the object hash value and the node hash value are calculated by the same hash function, and consistent hashing or similar algorithms are usually used to assign objects to nodes. Therefore, the closer the hash value of an object is to the hash value of a node, the more likely it is to be stored on that node. This design effectively prevents the formation of query hotspots and improves the efficiency and performance of the hierarchical dynamic collaborative storage system. Through this hierarchical and purposeful query strategy, the system can ensure data accessibility and responsiveness while maintaining efficiency.

[0099] Manage stored objects: All nodes manage objects in their local storage according to the threshold of their respective shard SLs, so that inactive objects can be deleted in a timely manner. Newly received objects are stored in local storage and their heat is updated.

[0100] like Figure 3 As shown, at time t0, a new object (ID 1001) is stored in each node and assigned an initial BH value.

[0101] At time t1, the node located at SL0 deletes object 1001 from storage because it fails to reach the required heat BH0 within the set threshold time.

[0102] In SL1 and SL2, this object failed to reach the heat BH1 and BH2 at time t2 and time t3 respectively and was deleted.

[0103] The nodes in the shard search for the location of the relevant ledger file in the local device based on the deletion information obtained previously and perform physical deletion.

[0104] Nodes in the highest level shard SL (Storage Levels) will not delete any objects to ensure data availability.

[0105] When an object needs to be read, its BH (Block Heat) will be updated to the latest state. For example, if a node in SL0 requests an object with ID 1010 and the node in SL1 does not store this object, the request will be passed to the node of the next level SL. Finally, the object is found by the node in SL3 and returned to the requester. During this process, all nodes involved will increase the number of visits to the object by 1 and update its heat value accordingly. If the heat of the object reaches the threshold of the corresponding shard SL, the blockchain node continues to save the object in local storage. Similarly, if the requester's node meets the conditions, it will also store the object in its local storage.

[0106] The simulation experiment was conducted with the help of a simulated blockchain platform. The experiment was based on a multi-node deployment simulation test of a Docker container, and each network node ran in a Docker container. This experiment was conducted using the Ubuntu 20.04 64-bit operating system. The smart contract was written in Go language, and different hard disk space and CPU cores were set for each node. It was mainly based on the Hyperledger Fabric open source framework simulation and construction. The experimental data set was part of the block data of the Ethereum blockchain. At the same time, Hyperledger Caliper was used for performance testing. The configuration information of the simulation test environment of the experiment is as follows:

[0107] Table 1 Configuration information of the simulation test environment of the experiment

[0108]

[0109] The proposed method is compared with Multi-layer Practical Byzantine Fault Tolerance (MPBFT), RapidChain and BFT-Store. For better comparison, the present invention sets the uniformity to four different shards, and the number of nodes in each shard is set to 1, 2, 4, and 8 respectively. MPBFT is a traditional storage model. RapidChain and BFT-Store are the two most advanced methods applied to consortium chain storage.

[0110] The simulation of the present invention generates 1000, 1500, 2000, 2500, and 3000 blocks respectively. The number of blocks is intercepted from Ethereum, and based on the parameter optimization in the previous part, the number of nodes is fixed to 15 and the number of groups is fixed to 4. The storage overhead is calculated respectively, and the group storage method of the present invention is compared with the traditional storage method. The storage overhead of the proposed method is 86%, 46%, and 43% lower than that of MPBFT, BFT-Store, and RapidChain, respectively. Therefore, the proposed method achieves lower storage overhead than similar methods.

[0111] The present invention discloses a hierarchical dynamic collaborative storage model based on blockchain; as the blockchain runs, the problem of node storage limitation in the blockchain is solved. The present invention proposes a hierarchical dynamic collaborative storage model, which is an innovative two-stage storage optimization framework. The files to be stored are split into file blocks of fixed size and MD5 hash values ​​are generated to avoid repeated storage of file blocks. At the same time, the sharding adopts a multi-level hierarchical storage model, and different threshold times and heats are set for each layer to delete infrequently accessed objects from the local storage. Efficient storage of block data is achieved while ensuring high data availability. The method can achieve lower storage overhead while ensuring high reliability. It highlights its potential for solving blockchain-based storage optimization problems.

[0112] Embodiment 2

[0113] This embodiment provides a data hierarchical dynamic storage system based on blockchain, including:

[0114] An acquisition module is configured to: acquire data to be stored, divide the data to be stored into a plurality of file blocks to be stored, and generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block;

[0115] The comparison module is configured to: compare the hash value of the file block to be stored with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database; if they are consistent, update the data of the file block to be stored to the storage location corresponding to the existing hash value; if they are inconsistent, store the data of the file to be stored on the blockchain.

[0116] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A data hierarchical dynamic storage method based on blockchain, characterized in that: include: Acquire the data to be stored, divide the data to be stored into a plurality of file blocks to be stored, and generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block; Compare the hash value of the file block to be stored with the hash value already in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already in the database. If they are consistent, update the data of the file block to be stored to the storage location corresponding to the existing hash value; If there is inconsistency, the data of the file to be stored is stored on the blockchain.

2. The data hierarchical dynamic storage method based on blockchain as claimed in claim 1 is characterized in that: The dividing the data to be stored into a plurality of file blocks to be stored is to divide the data to be stored into a plurality of file blocks of set capacity by using a logical block address.

3. The data hierarchical dynamic storage method based on blockchain as claimed in claim 2 is characterized in that: The data to be stored is divided into several file blocks of set capacity by using a logical block address, specifically including: setting the capacity of each file block; dividing the data to be stored according to the set file block capacity; if the capacity of the data to be stored is not an integer multiple of the file block size, the last file block is smaller than the set file block capacity; and generating a unique logical block address for each file block, wherein the logical block address is a continuous digital sequence used to uniquely identify the position of each file block on the storage device.

4. The data hierarchical dynamic storage method based on blockchain as claimed in claim 1 is characterized in that: The method further comprises: The blockchain nodes are classified into four levels of shards: first-level shards, second-level shards, third-level shards, and fourth-level shards. Each level of shards includes several blockchain nodes. From the first-level shards to the fourth-level shards, the access popularity of the blocks stored in the nodes decreases in sequence. At time t0, data object a is stored in the blockchain node of the first-level shard, and the initial block access heat value BH is configured for data object a; at time t0, data object a is also backed up and stored in the blockchain nodes of the second, third and fourth-level shards, and the initial block access heat value BH is configured for data object a; At time t1, t1>t0, the blockchain node of the first-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH0 of the first-level shard within the set threshold time range; if it reaches it, no processing is performed; if it does not reach it, the data object a is deleted from the blockchain node of the first-level shard; At time t2, t2>t1, the blockchain node of the second-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH1 of the second-level shard within the set threshold time range; if it reaches it, no processing is performed; if it does not reach it, the data object a is deleted from the blockchain node of the second-level shard; At time t3, t3>t2, the blockchain node of the third-level shard determines whether the real-time block access heat value of the data object a stored in itself reaches the set block access heat threshold BH2 of the third-level shard within the set threshold time range; if it reaches it, no processing is performed; if it does not reach it, the data object a is deleted from the blockchain node of the third-level shard; At time t4, t4>t3, the blockchain node of the fourth-level shard does not delete the data stored in the current blockchain node.

5. The data hierarchical dynamic storage method based on blockchain as claimed in claim 4 is characterized in that: The calculation process of the set threshold time range includes: Assume that the threshold time range is set to be 0 to t, where the unit of t is hours; the left endpoint value of the threshold time range is set to be 0; the right endpoint value of the threshold time range is set to be t; and t is an unknown quantity; Set the probability D(t,α) of at least one access to the first-level shard to 50%, the probability D(t,α) of at least one access to the second-level shard to 74.95%, the probability D(t,α) of at least one access to the third-level shard to 93.75%, and the probability D(t,α) of at least one access to the fourth-level shard to 100%; Estimate the probability D(t,α) that the current level shard is accessed at least once in a given time period: D(t,α)=1-e -αt ; Among them, α is the rate parameter, which represents the average frequency of events occurring per unit time.

6. The data hierarchical dynamic storage method based on blockchain as claimed in claim 5 is characterized in that: Using expression 1-e -αt To predict the probability of at least one event occurring within a specified time of 0 to t hours, to predict the probability of at least one visit within a given time of 0 to t hours; Among them, α i is the rate parameter of the i-th time period, w i is the weight of the i-th time period, n is the total number of time periods, and for access data in different time periods, the value of α is determined by weighted average.

7. The data hierarchical dynamic storage method based on blockchain as claimed in claim 4 is characterized in that: The block access heat value, the specific calculation process includes: Block access heat value HD i , obtained by calculating the number of accesses to the block in each time period; The block access heat value HD is calculated by multiplying the number of visits in each cycle by the corresponding access frequency weight and adding it to the current cycle cur. i ;f ij It represents the number of times block i is accessed in the jth cycle, while cur-j represents the time interval from the current cycle to the previous cycle, and cur represents the current time cycle.

8. The data hierarchical dynamic storage method based on blockchain as claimed in claim 7 is characterized in that: To normalize the heat value to the range of 0 to 1, normalization is used: HD max =max((HD i ),HD min =min(HD i ) Among them, HD max Indicates the current maximum heat, HD i Indicates current popularity, HD min Indicates the current minimum heat, HD i,norm Indicates the heat threshold that should be set.

9. The data hierarchical dynamic storage method based on blockchain as claimed in claim 1 is characterized in that: The method further includes: a blockchain node i of the first level shard obtains a query request; Determine whether the object to be queried exists in the blockchain node i of the first-level shard. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node j of the first-level shard; where blockchain node j is the node closest to blockchain node i; Determine whether the object to be queried exists in the blockchain node j of the first-level shard. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node k of the second-level shard; where blockchain node k is the node closest to blockchain node i; Determine whether the object to be queried exists in the blockchain node k of the second-level sharding. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node l of the third-level sharding; where blockchain node l is the node closest to blockchain node i; Determine whether the object to be queried exists in the blockchain node l of the third-level sharding. If so, directly return the query result and query cost; if not, pass the query request to the blockchain node of the fourth-level sharding, and the blockchain node of the fourth-level sharding returns the query result and query cost.

10. A data hierarchical dynamic storage system based on blockchain, characterized by: include: An acquisition module is configured to: acquire data to be stored, divide the data to be stored into a plurality of file blocks to be stored, and generate a hash value for each file block to be stored, and use the hash value as a unique identifier of the data block; a comparison module, which is configured to: compare the hash value of the file block to be stored with the hash value already existing in the database to identify whether the hash value of the file block to be stored is consistent with the hash value already existing in the database; if they are consistent, update the data of the file block to be stored to the storage location corresponding to the existing hash value; If there is inconsistency, the data of the file to be stored is stored on the blockchain.

Images