# Comprehensive Review of Storage Optimization Techniques in Blockchain Systems
## 4 Methods
### Ipfs
[71] advanced a blockchain storage optimization approach by integrating Distributed Hash Table (DHT) technology, thereby significantly improving storage efficiency in blockchain architectures. The authors employed DHT--a foundational component of IPFS--within the blockchain framework to facilitate decentralized storage. In this model, DHT partitions data into discrete chunks, each assigned a unique cryptographic hash; it distributes these chunks across multiple nodes, effectively eliminating redundant data storage. Upon data upload, the system checks the hash value to verify if it already exists within the network; if present, the data are referenced directly, bypassing the need for duplicate storage. DHT's distributed architecture enhances data localization and retrieval efficiency, as each node maintains only a subset of the data chunks, thereby minimizing inter-node redundancy, distributing storage loads, and achieving high data deduplication and resource optimization in decentralized storage environments. [PERSON] et al. [72] proposed the BC-Store framework, designed to address the issues of limited scalability and low data storage efficiency in blockchain systems. The BC-Store framework deploys a data access model within an IPFS cluster system to classify blockchain data into hot and cold data. As illustrated in Figure 7, hot data are stored in a local database to ensure rapid access, while cold data are stored in IPFS. Despite introducing some network latency, access delays remain within acceptable limits under reasonable network conditions. The primary advantage of this approach is its reduction of the storage burden on the blockchain. Through the design of BC-Store, the blockchain storage system becomes more efficient and flexible, allowing it to better accommodate large-scale data storage demands. [PERSON] et al. [73] proposed a dual-blockchain method to address the issue of blockchain storage. The dual-blockchain system consists of a Main Blockchain and a Secondary Blockchain, each handling distinct data storage and distribution tasks, significantly reducing storage redundancy in the blockchain system. The Main Blockchain only stores validated \"Hash Block,\" each containing a Content Identifier (CID). The CID has a fixed size, meaning that regardless of the actual transaction data size, the storage requirements of the Main Blockchain do not increase significantly with the number of transactions. The primary role of the Main Blockchain is to function as an index, using CIDs to point to the storage locations of original data. The Secondary Blockchain, in turn, stores the detailed transaction data as \"Raw Block\" via IPFS, which serves as the storage system for the Secondary Blockchain. IPFS segments each raw transaction block into multiple fragments and distributes these fragments across different nodes, forming a chain structure linked by CIDs. Through this dual-blockchain design, the actual transaction data are distributed across IPFS, while the Main Blockchain only stores references to these data via CIDs. As illustrated in Figure 8, compared to traditional Bitcoin core systems, where each mining node stores approximately 300 GB of complete block data, the dual-blockchain mechanism requires miners to store less than 0.2 GB of CIDs and metadata, achieving around 1685 times storage optimization. The integration of IPFS technology with blockchain to reduce storage redundancy in blockchain systems has seen practical applications. [PERSON] et al. [74] applied this approach in a decentralized evidence storage system to minimize storage redundancy and enhance storage efficiency. Table 2 illustrates the effectiveness of using IPFS to reduce storage redundancy in blockchain systems. It analyzes the implementation strategies for minimizing storage redundancy, provides a rough estimation of storage efficiency, and presents relevant usage scenarios. Figure 8: The dual-blockchain architecture. Figure 7: Hot and cold data storage model.