# Comprehensive Review of Storage Optimization Techniques in Blockchain Systems
## 4 Methods
### Data Sharding Storage  
In blockchain, data sharding is a technique that divides the data and processing tasks across the entire blockchain network into multiple independent partitions, known as shards. Each shard is responsible for handling its own subset of data and transactions, enabling parallel processing and reducing the storage and computational load on individual nodes. As shown in Figure 9, the diagram illustrates an overview of data sharding. Data sharding distributes on-chain data (including transaction data and state data) among different nodes, with each node maintaining only a portion of the data and processing transactions involving its local data. Nodes within each shard not only validate and execute only a fraction of transactions but also store only a subset of the data [75]. [PERSON] et al. [76] propose a Sharded Storage Model Based on Block Access Frequency and Size (BAPS), aimed at enhancing storage efficiency and system performance by optimizing blockchain storage strategies. The core concept of this model is to classify and manage blocks based on their access frequency and size, allowing for tailored storage schemes for different types of blocks, ultimately achieving optimal configuration and utilization of storage resources. The paper highlights two primary issues with traditional blockchain sharded storage: first, when the number of replicas is too low, system stability decreases, making data recovery challenging in the event of node failure or malicious nodes; second, \begin{table}
\begin{tabular}{c c c c} \hline \hline
**References** & **Implementation Strategies** & **Storage Efficiency** & **Usage Scenario** \\ \hline \multirow{3}{*}{[PERSON] [70]} & Blockchain stores hash values, smart contracts & \multirow{3}{*}{Midium} & Big file storage \\  & & manage permissions & \\ \multirow{3}{*}{[PERSON] [71]} & \multirow{3}{*}{Blockchain stores hashes, files are stored in IPFS,} & \multirow{3}{*}{Midium} & Big data storage \\  & & and DHT manages data & \\ \multirow{3}{*}{[PERSON] [72]} & \multirow{3}{*}{Hot data are stored locally, cold data are stored} & \multirow{3}{*}{High} & Hot and cold \\  & & in IPFS & \\ \multirow{3}{*}{[PERSON] [73]} & \multirow{3}{*}{Main blockchain stores CIDs, and secondary} & \multirow{3}{*}{High} & \multirow{3}{*}{Transaction data} \\  & & blockchain stores complete data in IPFS & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: IPFS for reducing storage redundancy. Figure 9: Data sharding architecture. -frequent block recovery operations can reduce system efficiency, especially for frequently accessed blocks, as sharded storage increases the overhead of data recovery. To address these issues, the authors propose a classification-based storage strategy according to access frequency and block size. Blocks are divided into four categories: small block + low access frequency, small block + high access frequency, large block + low access frequency, and large block + high access frequency, as illustrated in Figure 10. For blocks with low access frequency, the model applies sharded storage regardless of block size, enhancing storage efficiency and overall system performance. For high-frequency access, small blocks use complete block storage, reducing recovery overhead and improving access speed. High-frequency access blocks with large storage requirements use a combination of sharded storage and temporary storage mechanisms, ensuring improved storage efficiency while reducing recovery time and cost. The innovation of the BAFS model lies in its ability to dynamically adjust storage strategies to balance storage demands and access efficiency. By tracking the number of accesses each block receives over specific time periods along with its storage size, the system can flexibly choose the optimal storage approach. This access-feature-based sharded storage model not only improves blockchain storage performance but also alleviates node storage pressure, thus enhancing overall system operational efficiency. [PERSON] et al.