Research on an On-Chain and Off-Chain Collaborative Storage Method Based on Blockchain and IPFS

Abstract

Blockchain technology, with its characteristics of decentralization, immutability, auditability, and traceability, has gradually become a core infrastructure in the digital economy era, demonstrating great potential in fields such as finance, government services, and the Internet of Things (IoT). However, as the scale of blockchain networks expands and data volumes surge, issues such as full-node storage redundancy, limited transaction throughput, and inefficient synchronization of historical data have become increasingly prominent, severely restricting the large-scale application of blockchain systems. The storage scalability problem faced by blockchain is therefore becoming more critical. To address the challenge in which on-chain storage expansion still cannot meet the demand for large-scale data storage, a storage method combining the InterPlanetary File System (IPFS) with blockchain, referred to as IPFS-BC, is proposed. In IPFS-BC, large-scale raw data are stored in the decentralized and content-addressable IPFS network, while the blockchain only retains the unique content identifier (CID) hash and related metadata. Through smart contracts enabling dynamic permission management and fine-grained access control, efficient interaction and collaborative storage between on-chain and off-chain systems are achieved. In this work, file upload simulation experiments were conducted, and two evaluation indicators—storage space consumption and storage performance (file read/write time and speed)—were used to compare three storage approaches: Distributed Hash Table (DHT)-based off-chain storage, Financial Blockchain Shenzhen Open Source (FISCO BCOS) on-chain storage, and the IPFS-BC on-chain/off-chain collaborative storage model. Experimental results show that the IPFS-BC model reduces storage space consumption by approximately 75% compared with FISCO BCOS blockchain storage when storing file data, significantly decreasing data redundancy. Moreover, IPFS-BC ensures system security during the on-chain process, and through the automated management and auditing provided by smart contracts, it effectively enhances system security and realizes scalable on-chain/off-chain collaborative storage.

1. Introduction

With the advent of the digital economy era, the scale of global data production and circulation has experienced unprecedented exponential growth. As a new type of production factor, data has generated increasing demands for security, trustworthy storage, and efficient multi-party collaboration, becoming a core requirement for building next-generation information infrastructure. Against this backdrop, blockchain technology, with its advantages in distributed storage, immutability, full-process traceability, and independence from centralized trusted entities, has gradually evolved from a theoretical concept into practical applications. It has become one of the most prominent and promising enabling technologies in contemporary data governance and management systems.

Initially proposed by the researcher known under the pseudonym “Nakamoto” in 2008, blockchain integrates distributed ledgers, consensus algorithms, and modern cryptographic techniques, enabling reliable data storage and value transfer even in environments without trusted third-party intermediaries. This technology fundamentally addresses a series of inherent limitations in traditional centralized systems, such as vulnerability to single-point attacks, insufficient protection against data tampering, high audit and traceability costs, and the complexity of establishing trust [1].

Although many data storage and access control functions can be realized using centralized architectures, such solutions typically rely on a fully trusted third party and introduce inherent limitations in multi-party data-sharing scenarios. In cross-organizational environments involving multiple independent stakeholders, centralized governance may lead to trust disputes, single points of failure, limited transparency, and high auditing costs. In contrast, blockchain provides a decentralized governance mechanism with built-in immutability, verifiable operation records, and trust minimization, making it particularly suitable for coordinating data indexing, access control, and accountability across multiple parties without relying on a centralized authority. This motivates the adoption of blockchain as the coordination and trust layer in on-chain/off-chain collaborative storage architectures.

In recent years, with the continuous maturation of the technology and the ongoing expansion of application scenarios, blockchain has achieved remarkable progress in various domains, including financial transactions and settlement [2], IoT device management and data security [3], global supply chain traceability and transparency [4], medical record sharing and privacy protection [5], and governmental data openness and cross-departmental collaboration [6]. Its technological ecosystem has become increasingly sophisticated, and its industrial application value has been continuously released and strengthened worldwide.

However, despite providing high security and strong trust guarantees, blockchain also faces increasingly severe challenges in storage and scalability. Public statistics show that by the end of 2025, the overall size of the Bitcoin blockchain had exceeded 710 GB, while the Ethereum blockchain surpassed 1.4 TB [7]. In traditional blockchain architectures, all nodes are required to store a complete copy of the ledger, causing on-chain data volume to grow irreversibly in a linear or even super-linear manner over time [8]. Numerous studies indicate that as blockchain networks expand, transaction frequency increases, and smart contracts become widely adopted, the costs associated with ledger storage, synchronization, and verification rise sharply. These trends lead to performance degradation, excessive node load, and increased block propagation delays within the system [9].

From a technical perspective, the bottlenecks of blockchain storage scalability are mainly reflected in three aspects: storage expansion caused by full data redundancy due to complete replication [10]; data synchronization latency affecting system throughput [11]; and rising storage costs reducing the degree of decentralization [12]. To address these challenges, researchers have proposed multiple technical approaches, including optimization of blockchain data and transaction structures, on-chain state pruning and compression, lightweight client verification, sharding and partitioning of the network, Layer-2 scaling solutions such as state channels and rollup protocols, and emerging data-availability layers supporting modular scalability [13,14,15]. However, these approaches primarily focus on reducing on-chain computational load or optimizing state maintenance processes, rather than fundamentally alleviating the long-term storage expansion of blockchain systems. As long as large-scale data remain permanently stored on-chain, purely on-chain optimization techniques cannot structurally prevent the continuous growth of blockchain storage.

Therefore, the blockchain research community and industry have increasingly shifted their focus toward on-chain and off-chain collaborative storage. This approach follows the principle of “storing indexes on-chain and storing data off-chain,” whereby large-scale raw files, historical records, media content, and other data are migrated to off-chain storage systems, while only file hashes, access permissions, and verification information are kept on-chain. This design reduces the on-chain storage burden while ensuring data security, thereby enabling an efficient and scalable data management architecture [16].

In recent years, extensive research has been conducted worldwide on on-chain and off-chain collaborative storage. Hassanzadeh et al. [17] proposed LightChain, which integrates blockchain ledgers with distributed hash tables to achieve a DHT-based scalable data storage structure. Li et al. [18] introduced an architecture combining off-chain hash-table storage with on-chain identity verification in IoT scenarios, effectively reducing the storage burden on IoT devices. Yao et al. [19] proposed LayerChain, which stores blockchain transaction data hierarchically across cloud environments and on-chain systems, enabling more efficient cross-domain data propagation. Eom et al. [20] designed an IPFS-based electronic medical record access framework that stores file hashes on-chain and incorporates access control strategies to achieve secure sharing and privacy protection of medical data. Gao et al. [21] constructed a trustworthy off-chain storage traceability mechanism using hash chains and digital signatures, significantly saving on-chain space by recording only hash values.

In addition to storage-oriented research, recent hybrid blockchain architectures have advanced in complementary directions. For example, a quality-of-service (QoS)-adjustable intelligent blockchain framework was proposed to dynamically orchestrate on-chain and off-chain resources to support heterogeneous QoS requirements under varying workloads [22]. Collaborative off-chain federated learning (CoCFL) has been introduced to enable joint model training across heterogeneous blockchain networks while preserving data locality and trust [23]. Although these works represent important advances in intelligent and collaborative blockchain ecosystems, their primary design objectives—adaptive resource scheduling, QoS optimization, or collaborative learning—differ fundamentally from storage-centric solutions.

In contrast to hybrid blockchain frameworks that primarily focus on resource orchestration or collaborative intelligence, on-chain/off-chain collaborative storage architectures, especially those integrating blockchain and IPFS, aim to directly resolve the structural storage bottleneck by decoupling data storage from ledger maintenance. IPFS is a content-addressed distributed file system that leverages content addressing, Merkle-DAG structures, and DHT routing to provide efficient distributed storage and retrieval capabilities, making it highly suitable for large file storage and structured data that do not require real-time updates [24]. When blockchain is integrated with IPFS, the blockchain stores the file hash (CID) for integrity verification, while the large file content resides in the IPFS network, forming a storage architecture that offers both high trustworthiness and high scalability [25].

Table 1. Comparison of representative hybrid blockchain architectures involving on-chain and off-chain collaboration.

Technical Solution	Proposer	Main Content	Key Features
DHT + Blockchain (LightChain)	Hassanzadeh-Nazarabadi et al. [17]	Uses DHT to store blocks and transactions off-chain while recording hashes on-chain, reducing per-node ledger storage.	High scalability; node storage cost greatly lowered.
IoT Data Storage via Blockchain	Li et al. [18]	Stores IoT data across decentralized nodes with blockchain-based verification.	Secure, decentralized IoT data protection.
Cloud Storage + Blockchain (LayerChain)	Yao et al. [19]	Hierarchical storage of blockchain transaction data across cloud and chain.	Reduces on-chain load and improves propagation.
IPFS + Blockchain EMR System	Pan et al. [20]	Stores medical file contents in IPFS while on-chain stores hashes and access control.	Enhances privacy; lowers chain storage.
Off-chain Hash Chaining + Signatures	Gao et al. [21]	Keeps traceability data off-chain and writes only hash values on-chain.	Improves integrity; reduces on-chain footprint.
QoS-Adjustable Intelligent Blockchain	Xu et al. [22]	Dynamic orchestration of on-/off-chain resources for QoS adaptation.	QoS optimization.
CoCFL	Wang et al. [23]	Federated learning coordination over blockchain networks.	Collaborative learning scalability.

presents a comparative analysis of representative on-chain/off-chain collaborative storage solutions discussed above.

The above studies demonstrate the effectiveness of off-chain storage in enhancing blockchain scalability. However, existing solutions still face several common issues, including insufficient efficiency in on-chain/off-chain interactions, difficulty in achieving unified cross-system access control, unreliable availability of off-chain nodes, inadequate data privacy protection mechanisms, and high latency in data sharing and collaboration across heterogeneous blockchain systems. Therefore, developing an on-chain/off-chain collaborative storage architecture with high integrity verification, strong scalability, robust access control, and adaptability to diverse application scenarios (e.g., the IPFS-BC model) has become an important research direction in the blockchain field.

Based on this background, this study designs and implements an on-chain/off-chain collaborative storage system, referred to as IPFS-BC, which integrates blockchain and IPFS. The IPFS-BC system leverages the strengths of IPFS for efficient large-file storage and the security features of blockchain for data trustworthiness and access management. By managing file indexes, access permissions, and data verification logic on-chain, and delegating large-file distribution and storage to the off-chain IPFS network, the proposed model significantly reduces the on-chain storage burden and improves the scalability and overall performance of the blockchain system, while ensuring data security and immutability. The main contributions of this study are as follows:

(1)

We have developed an on-chain and off-chain collaborative storage model IPFS-BC, which effectively ensures data integrity and immutability. Through smart contract collaboration, users need to verify their identity and permission to upload data when accessing data. The system also implements efficient file retrieval, sharing, and access control functions through strict data management during query verification.

(2)

Storage expansion and reduction in blockchain storage pressure. Large scale data is stored off-chain, achieving good scalability. The pressure on nodes within the blockchain block is shared with the IPFS system, and only the hash value of the data needs to be stored through smart contracts, optimizing storage space usage.

(3)

Reduce storage costs. The cost of storing data in blockchain systems is high. Storing data off-chain and on-chain only requires storing small-scale data such as hashes, greatly saving storage costs.

The remainder of this paper is structured as follows: Section 2 reviews the related theories and enabling technologies, including DHT-based off-chain protocols, cloud storage, the IPFS, the FISCO BCOS consortium blockchain platform, and hybrid blockchain architectures. Section 3 presents the proposed IPFS-BC storage model, detailing its overall architecture, functional layers, and system design. Section 4 describes the experimental environment and provides a comprehensive evaluation of the proposed model in terms of storage space and resource consumption, storage performance, and security. Section 5 discusses the experimental results and system-level trade-offs, and Section 6 concludes the paper and outlines directions for future research.

2. Related Theories and Technologies

This chapter introduces several key supporting technologies involved in this study, including the DHT-based off-chain protocol, cloud storage, IPFS, and the FISCO BCOS consortium blockchain, which together provide the theoretical foundation for the design and implementation of the proposed on-chain/off-chain collaborative storage model.

2.1. DHT Off-Chain Protocol

The DHT is a typical decentralized distributed indexing mechanism that maps keys to network nodes efficiently through hash functions, enabling stable and rapid data location in large-scale networks [26]. The fundamental concept of DHT is to apply a consistent hashing algorithm to the logical key space, dividing the entire key domain into multiple continuous intervals, with each interval managed and stored by a different node. This mechanism avoids the indexing bottlenecks of traditional centralized directories, allowing the system to maintain low routing complexity and strong scalability even in dynamic environments where nodes frequently join or leave the network [27].

In off-chain expansion scenarios, DHT serves as a mature distributed indexing technology capable of automatically performing data partitioning based on key-space ranges and evenly mapping the partitions to different storage nodes, thereby achieving efficient load balancing and capacity scaling. As shown in Figure 1, DHT maps input data to a key through a hash function, and nodes store the corresponding key–value pairs according to their positions on the hash ring. When a user initiates a query, the network progressively routes the request toward the target node via multi-hop routing, completing data lookup with a complexity of $O\left(logN\right)$ [28].

Benefiting from this hash-based structured addressing mechanism, DHT networks can maintain low query latency even when the number of nodes increases dramatically, thereby improving overall data access efficiency. In off-chain data management, DHT not only distributes large-scale data across different nodes based on key partitioning but also leverages its structured indexing capability to effectively reduce the storage burden on blockchain nodes. The blockchain only needs to record the CID of a file, while the DHT network is responsible for locating and accessing the corresponding off-chain data, thus achieving a collaborative model in which “indexes are stored on-chain while data entities are stored off-chain” [29].

Moreover, since DHT nodes possess autonomy and self-organizing capabilities, only a small number of key–value pairs need to be reassigned when the network topology changes, enabling local updates to routing tables and ensuring high robustness and maintainability of the system [30]. In practical applications, DHT demonstrates significant advantages in avoiding bottlenecks caused by data centralization, improving query efficiency, and reducing storage pressure, thereby providing essential technical support for building an off-chain distributed indexing layer. By migrating large files from the blockchain to a DHT-based distributed storage system, the blockchain can significantly enhance its scalability while maintaining data verifiability and traceability, thus offering a reliable foundation for on-chain/off-chain collaborative storage models [31].

2.2. Cloud Storage

Cloud storage is a remote data management model built upon virtualization and distributed file systems, which provides users with elastically scalable storage services through resource pooling and unified abstraction [32]. In this model, users do not need to deploy underlying hardware on their own; instead, they access storage capabilities offered by the cloud through the network, thereby obtaining on-demand resources at a relatively low cost. Cloud storage typically adopts a multi-node collaborative architecture to provide a unified access interface, as illustrated in Figure 2.

In traditional Internet and enterprise-level data environments, cloud storage has been widely adopted due to its centralized management, automatic scalability, and cross-regional redundancy capabilities [33]. When business workloads fluctuate, the system can dynamically adjust storage and computing resources to ensure continuous service operation under high concurrency and heavy traffic conditions. In addition, cloud storage supports mechanisms such as snapshots, backups, and tiered storage, enabling it to manage data at different lifecycle stages and meet the security and stability requirements of large-scale data platforms [34].

However, under a multi-tenant shared architecture, virtualization isolation still presents potential security risks. Since multiple tenants may share the same physical hardware, side-channel attacks and data leakage risks cannot be completely eliminated, a concern that has been repeatedly validated in security research [35]. Therefore, cloud storage has certain limitations in data isolation when applied to sensitive data or regulated industries.

More importantly, cloud storage is built upon a centralized architecture in which data control is held by the cloud service provider. Users cannot independently verify whether storage, replication, or deletion operations are executed as claimed by the cloud, resulting in inherent deficiencies in trustworthiness, verifiability, and tamper resistance. In scenarios requiring strong trust guarantees, users often need to introduce additional encryption, remote auditing, or third-party verification mechanisms to compensate for the lack of inherent trust in cloud environments.

In blockchain-related applications, these limitations become even more pronounced. Blockchain emphasizes immutability, transparent record-keeping, and decentralized management, while the centralized nature of cloud storage inherently conflicts with these design principles. Therefore, cloud storage is more suitable as an auxiliary off-chain storage layer for large-scale, non-critical data, while the blockchain is responsible for indexing, verification, and access control. Through this collaborative model, it becomes possible to achieve greater storage scalability while preserving trustworthiness.

2.3. InterPlanetary File System (IPFS)

The IPFS is a distributed storage protocol that manages files through content addressing. Its core mechanism computes a hash of the file content to generate a unique CID, which serves as the basis for locating data, enabling efficient global retrieval and access [36]. Unlike traditional file systems that rely on path-based addressing, IPFS indexes data by its content, eliminating dependency on centralized servers or fixed paths, and thereby enhancing system verifiability, reconstructability, and decentralization.

IPFS organizes files and directories using a Merkle Directed Acyclic Graph (Merkle-DAG) structure, where large files are divided into multiple data blocks and arranged into a hash tree, allowing any content modification to be instantly detected through hash verification [37]. Since each node only needs to store the data blocks it requires, the system can maintain high storage efficiency and loose coupling in large-scale networks. Based on this structure, IPFS supports rapid data location, deduplicated storage, and cross-node synchronization, making it a foundational technology in distributed storage systems, as illustrated in Figure 3.

In practical operation, IPFS maintains the mapping between nodes and content through a DHT, enabling users to publish, retrieve, and transfer data without relying on a central server [38]. When a node requests the content corresponding to a CID, the IPFS network performs multi-hop routing based on the DHT to locate the node that stores the required data block, thereby completing distributed content discovery. This mechanism maintains high availability and routing efficiency even when nodes dynamically join or leave the system, making IPFS suitable for open and continuously expanding storage networks.

In on-chain/off-chain collaborative storage architectures, IPFS is commonly employed as a key component of the off-chain storage layer. The blockchain records the CID of a file as a trusted index, while the file content is stored within the IPFS network, significantly reducing the storage burden on blockchain nodes and improving data processing efficiency [39]. This structure not only enhances the performance of large-scale file storage but also ensures verifiable and auditable access to off-chain data, since any modification to a file results in a change in its CID. The immutability inherent in content addressing makes IPFS a widely adopted foundational distributed storage solution for blockchain systems.

Furthermore, IPFS is well suited for cross-regional transmission and distributed data sharing, and its decentralized architecture effectively eliminates the single point of failure associated with traditional centralized servers, thereby providing higher data availability in multi-node environments [40]. Cross-regional transmission refers to the fact that, within the IPFS network, data are no longer bound to fixed geographic locations or specific servers, but are instead located, retrieved, and transmitted among nodes distributed across different geographical regions worldwide through a content-addressing mechanism. This allows users in different regions to efficiently access target data from nearby or available nodes, thereby enabling globally distributed data transmission and sharing.

2.4. FISCO BCOS Consortium Blockchain

FISCO BCOS is an open-source consortium blockchain platform designed for multi-institution collaborative scenarios. It adopts a layered and modular architecture that divides the system into several functional components, including the network layer, consensus layer, execution and storage layer, and access interface layer, to meet the requirements of complex business environments for high performance and scalability [41]. At the consensus layer, the platform supports Practical Byzantine Fault Tolerance (PBFT), Raft, and a pluggable consensus framework, enabling developers to select different fault-tolerance levels and latency models based on the characteristics of specific applications. Its multi-layer architecture, as illustrated in Figure 4, consists of key functional modules such as the interface layer, management layer, core blockchain layer, and infrastructure layer, providing flexible technical support for upper-layer applications.

At the interface layer, FISCO BCOS provides interfaces based on Remote Procedure Call (RPC), WebSocket, JavaScript Object Notation–Remote Procedure Call (JSON-RPC), and multi-language Software Development Kits (SDKs), enabling developers to interact with on-chain services in a standardized manner, thereby improving development efficiency and system compatibility. At the management layer, the platform supports functionality such as permission management, parameter management, consensus management, and multi-ledger management, allowing secure and controllable operations in multi-institution environments [42]. In particular, its fine-grained permission system enables multidimensional access control over users, nodes, and smart contracts, meeting the stringent security requirements of domains such as finance and government affairs.

At the core blockchain layer, FISCO BCOS provides components including precompiled contracts, an Ethereum Virtual Machine (EVM) execution environment, block management, and transaction pool management to support high-throughput and high-concurrency on-chain operations [43]. The platform also supports the Advanced Multi-Dimensional Database (AMDB) distributed storage framework and multiple database drivers, including MySQL, LevelDB, and Oracle, to accommodate sustainable storage requirements across different business scenarios. In addition, the built-in network communication layer adopts a peer-to-peer (P2P) topology and implements mechanisms for block synchronization, node discovery, and transaction propagation, ensuring high reliability and low communication latency in cross-institution deployments.

At the infrastructure layer, FISCO BCOS integrates cryptographic modules, data acceleration modules, and database driver layers to support secure computation and efficient storage of on-chain data [44]. With the support of National Cryptographic algorithms, privacy-preserving algorithms, and various pluggable components, the platform provides verifiable and auditable data management capabilities while maintaining security, giving it natural advantages in regulatory technologies and trusted data services. Among them, the National Cryptography algorithm, also known as the commercial cryptographic algorithm system recognized and standardized by the China National Cryptography Administration. It does not refer to a single algorithm, but a complete series of cryptographic algorithm standards aimed at safeguarding China’s network and information security, and achieving independent and controllable cryptographic technology.

In practical applications, the smart contract mechanism of FISCO BCOS enables on-chain access control, audit logging, and cross-node collaboration, achieving automated execution and trusted verification of business logic. Its high throughput and millisecond-level confirmation latency make it an ideal platform for recording on-chain indexes and performing data verification. When combined with off-chain storage systems, FISCO BCOS can construct a flexible and efficient on-chain/off-chain collaborative data management structure, providing a solid foundation for multi-institution data sharing, trusted interconnection, and business cooperation [45].

2.5. Hybrid Blockchain Architecture

Hybrid blockchain architecture refers to a system design paradigm that integrates on-chain mechanisms with off-chain components to jointly support data storage, computation, and coordination tasks. In such architectures, the blockchain is typically used as a trusted execution and verification layer, while resource-intensive operations—such as large-scale data storage, complex computation, or cross-domain coordination—are offloaded to external systems. This separation-of-concerns design, which has been widely discussed in prior studies [46], significantly improves system scalability while preserving decentralization and trust guarantees.

The motivation for adopting hybrid blockchain architectures stems from the inherent mismatch between blockchain’s strong security and consistency guarantees and its limited capability for high-throughput data processing. Because on-chain operations require global consensus and full replication across nodes, directly handling large data volumes on-chain leads to substantial performance overhead. To address this limitation, hybrid architectures decouple ledger maintenance from auxiliary functions, allowing off-chain modules to operate independently while remaining verifiable through cryptographic commitments anchored on the blockchain, as demonstrated in representative hybrid designs.

Structurally, a typical hybrid blockchain system is composed of three core layers: an on-chain trust layer, an off-chain execution or storage layer, and a coordination interface that connects them. As illustrated in Figure 5, the on-chain layer maintains immutable records and verification metadata, whereas off-chain components are responsible for data storage, computation, or collaborative processing. The coordination interface ensures that off-chain results can be efficiently validated and audited on-chain through hashes, proofs, or state commitments, thereby forming a scalable yet trustworthy architecture [47].

In recent years, hybrid blockchain designs have evolved along multiple complementary directions beyond simple storage offloading. For example, QoS-adjustable intelligent blockchain frameworks dynamically orchestrate on-chain and off-chain resources to satisfy heterogeneous quality-of-service requirements under varying workloads [22]. In addition, CoCFL enables joint model training across heterogeneous blockchain networks while preserving data locality and trust relationships [23]. Although these approaches substantially enhance resource adaptivity and collaborative intelligence, their primary objectives—such as QoS optimization or distributed learning—differ fundamentally from storage-centric hybrid blockchain architectures.

Overall, by flexibly integrating blockchain networks with heterogeneous off-chain infrastructures, hybrid blockchain architectures provide a general and extensible foundation for addressing scalability challenges in data- and computation-intensive applications. As emphasized in recent studies [48], such architectures also serve as an important theoretical basis for the design of on-chain/off-chain collaborative storage systems.

3. Proposed IPFS-BC Storage Model

This section presents the proposed IPFS-BC storage model, which aims to address the inefficiency and scalability limitations of traditional on-chain data storage by enabling coordinated on-chain and off-chain data management. The core objective of this model is to leverage IPFS for efficient distributed storage while using blockchain as a trusted control and verification layer. In particular, the proposed approach introduces automated smart contract logic to bridge IPFS and the blockchain, enabling data upload, indexing, access control, and verification processes to be executed in a decentralized and programmable manner. Section 3.1 describes the overall architecture and key components of the IPFS-BC model, including the blockchain layer, IPFS layer, and smart contract layer. Section 3.2 then details the design of the data storage, query, and verification mechanisms, illustrating how on-chain and off-chain interactions are coordinated.

3.1. Model Description

To achieve efficient and stable data storage in blockchain networks and alleviate the growing storage burden, the IPFS-BC storage model proposed in this study introduces a smart contract mechanism to enable automatic and reliable execution of storage strategies. Specifically, during the data storage phase, the system uploads the core data that must be backed up by transaction participants, along with other relevant user data, to the IPFS distributed storage system. After receiving an upload request, IPFS responds according to its predefined system rules. It first verifies the integrity and validity of the data, and upon confirming compliance, splits the data into multiple independent blocks. Leveraging its distributed architecture, IPFS performs parallelized storage and processing, thereby significantly improving overall storage and retrieval efficiency. After storage is completed, IPFS generates a unique CID, i.e., the IPFS hash value, for each file. This identifier is globally unique and tamper-resistant, serving as a reliable addressing reference for locating files in the distributed network [49]. In this study, smart contracts are developed and deployed to ensure that operations such as file uploading, block partitioning, storage, and hash generation are automatically triggered and executed based on predefined logic, eliminating reliance on centralized servers and enabling decentralized and automated management of the storage workflow. The detailed implementation process is shown in Figure 6.

After a user submits an upload request, the system first performs identity authentication and access control based on the user address. Let the user address be denoted as $u$, the legality of the user identity be represented by $Auth\left(u\right)$, and the access permission verification be denoted as $Perm\left(u\right)$. When $Auth\left(u\right)=0$ or $Perm\left(u\right)=0$, the system immediately terminates the upload process and returns an error message, ensuring the security and integrity of stored data.

Once identity and permission verification are passed, the file content $F$ enters the segmentation module. According to the predefined block size $s$, the system divides the file into multiple fragments. If the file size is $S$, the number of fragments is calculated as $n=\lceil S/s\rceil$. The file segmentation mechanism enhances transmission and storage efficiency for large files in distributed systems. Upon completing segmentation, each fragment is sequentially submitted to IPFS nodes for storage, and the corresponding hash value $h_i$ is returned. The system then binds these fragment hashes to the on-chain index to achieve a one-to-one mapping between on-chain metadata and off-chain file content. The segmentation process can be expressed as shown in the next subsection.

The IPFS-BC storage model is composed of multiple functional layers, which are described in the next subsection.

3.1.1. Blockchain Layer

The IPFS-BC system continues to adopt the FISCO BCOS consortium blockchain as its underlying blockchain support platform. Multiple FISCO BCOS blockchain nodes interconnect to form a distributed network. The nodes run the PBFT consensus mechanism, ensuring state consistency across the system. This mechanism guarantees the immutability and operational reliability of the entire process of data indexing and verification in IPFS-BC [50].

The main responsibilities of the blockchain layer include ensuring the uniqueness of stored data, recording content hash values, and preventing large-scale historical data accumulation, thereby reducing on-chain storage pressure. Meanwhile, leveraging the inherent decentralization of the blockchain, IPFS-BC achieves a high degree of automation in storage scheduling and management, improving overall system robustness and trustworthiness.

3.1.2. IPFS Layer

The IPFS layer is composed of a distributed storage network formed by IPFS nodes, which collectively provide decentralized storage services based on content addressing. Each node can respond to storage and retrieval requests transmitted from the system, enabling efficient data processing. Under the IPFS-BC architecture, every stored file is assigned a globally unique cryptographic hash value as its content identifier. Users can retrieve required content by querying this identifier. If any modification occurs in the file content, its corresponding hash value changes accordingly, ensuring the integrity of stored data and preventing unauthorized data tampering or forgery, thereby establishing a trustworthy data storage environment.

3.1.3. Smart Contract Layer

Smart contracts serve as the core functional module of the IPFS-BC storage model, acting as the bridge between the blockchain and the IPFS storage system. Through custom-designed and deployed contract logic, the system performs permission management, data access control, and integrity verification, enabling automatic lifecycle management of stored data.

Smart contracts obtain the hash value of the target data returned by FISCO BCOS blockchain nodes and subsequently call the corresponding IPFS interface to retrieve or verify stored content. By utilizing the hash values recorded on the blockchain, users can verify whether the retrieved data is complete, authentic, and untampered, enabling verifiable and trustworthy data utilization. Moreover, smart contracts maintain operation logs for all user actions in the IPFS-BC system, ensuring traceability, auditability, and regulatory compliance in accordance with security standards.

3.2. Model Design

In the IPFS-BC data storage model, the integration of on-chain and off-chain storage leads to frequent interactions between the IPFS system and the FISCO BCOS blockchain. As illustrated in Figure 7, this process mainly consists of three stages: uploading data to the IPFS system, verifying the unique hash value generated through content addressing, and performing efficient data management and permission control.

3.2.1. Data Upload and Storage

In the IPFS-BC data storage model, smart contracts are employed to automatically execute storage strategies, thereby improving the efficiency and intelligence of storage operations. Specifically, the system first uploads backup data generated during transactions, various files submitted by users, and other related data content to the IPFS distributed storage network. After receiving the data, the IPFS system processes the upload request according to its built-in distributed protocol rules. Upon verifying data integrity and validity, IPFS divides the data into multiple independent blocks. These blocks are stored across different nodes in the network, enabling parallelized storage and processing, which significantly enhances overall storage efficiency and data-handling performance.

After the storage process is completed, IPFS generates a unique content-addressed hash value, known as the CID, which serves as the permanent identifier of the file within the distributed network. Furthermore, smart contract technology is utilized to automatically trigger and execute operations such as data uploading, storage, and verification based on predefined business logic and storage rules. The entire process operates without reliance on any centralized authority or manual intervention, thereby enhancing system decentralization and operational transparency. The complete workflow is illustrated in Figure 8.

After a user initiates an upload request, the system first performs identity authentication and access control based on the user address. Let the user address be denoted as $u$, the legality of the user identity be represented by $Auth\left(u\right)$, and the access permission verification be denoted as $Perm\left(u\right)$. When $Auth\left(u\right)=0$ or $Perm\left(u\right)=0$, the system immediately terminates the upload process and returns an error message, ensuring the security and integrity of stored data.

Once identity and permission verification are passed, the file content $F$ enters the segmentation module. According to the predefined block size $s$, the system divides the file into multiple fragments. If the file size is $S$, the number of fragments is given by $n=\lceil S/s\rceil$. The segmentation process can be expressed as:

$$F\to \{f_1,f_2,\dots ,f_n\}$$

(1)

The generated fragments are then organized into an upload queue to facilitate distributed uploading.

During the fragment upload phase, the system sends each fragment to the designated IPFS storage node. Due to the content-addressing mechanism of IPFS, each fragment is assigned a unique CID. For example, the CID of fragment $f_i$ is generated by: $CI{D}_i=IPFS\left(f_i\right)$. If a fragment fails to upload and results in $CI{D}_i=\Phi$, the system records that “the $i$-th fragment upload failed,” and re-uploads the entire file to ensure the integrity and availability of stored data.

When all fragments are successfully uploaded, the system constructs the file-level CID based on the fragment CIDs. The file-level CID is the combined hash of multiple fragment hashes:

$$CID=Hash\left(CI{D}_1,CI{D}_2,\dots ,CI{D}_n\right)$$

(2)

This file-level CID serves as the unique verification identifier of the file within the IPFS network and forms the core field to be recorded on the blockchain.

Subsequently, the system assembles the final CID, the user address $u$, the upload timestamp $t$, and the access control strategy $accessType$ into the metadata:

$$Meta=(CID,u,t,accessType)$$

(3)

The metadata is then written into the smart contract to achieve tamper-proof on-chain indexing of the file.

Once file metadata registration is completed, the system returns a “file uploaded successfully” message along with the final CID, marking the end of the entire storage process.

To support on-chain file hash verification, the IPFS-BC model further designs a smart contract dedicated to managing data uploads. Its parameter structure is shown in

Table 2. IPFS file uploaded to storage contract parameter structure.

Field	Field Type	Description
fileHashes	mapping	Stores the mapping between the user address and the file hash value (CID), where the key is the user address and the value is the file hash value.
FileUploaded	event	File upload event, recording the user address, the file hash value (CID), and the upload timestamp.
uploadFile	function	The user calls this function to upload the file hash value (CID) to the blockchain.
getFileHash	function	Queries the file hash value (CID) uploaded by a specific user.
Cid	String	File Hash Value

.

Because IPFS hashes are generated based on file content, even a minimal change in the data will result in a completely different IPFS hash value [51]. When a blockchain user needs to retrieve data stored off-chain, the corresponding data blocks can be quickly located and fetched from the IPFS network using the CID. Through its content-addressing mechanism, IPFS ensures precise data localization and correct extraction, thereby enabling efficient and reliable operation of the IPFS-BC storage model during the data uploading and storage phases.

3.2.2. Data Query and Verification

Based on this mechanism, the IPFS-BC storage model establishes a complete data query and verification framework to support file access, data sharing, and integrity validation. The overall architecture and execution workflow of the data query and verification procedure are illustrated in Figure 9, which integrates on-chain querying, off-chain data retrieval, and cross-system consistency verification.

When a user requests access to file data or initiates a verification operation, a query request containing the target file hash value is first submitted to the blockchain network. Upon receiving the request, the blockchain system automatically invokes the FISCO BCOS service and searches the distributed ledger for a storage record corresponding to the submitted hash value. If no matching on-chain record is found, the verification process is immediately terminated, indicating that the data have not been properly anchored or that the on-chain information is invalid.

If a corresponding on-chain record exists, the system uses the retrieved file hash to initiate a data retrieval request to the IPFS network, from which the original file content is obtained. The system then recomputes the hash value of the retrieved file and compares it with the hash value stored on the blockchain to determine whether the on-chain and off-chain data are consistent. Upon completion of the verification process, the system returns the verification result together with relevant operational logs, forming a complete data query and verification cycle.

From a logical perspective, the data query and verification workflow can be abstracted into three main stages. First, the user submits a query request to the blockchain network to retrieve the stored file hash record from the distributed ledger. Second, the corresponding file content is fetched from the IPFS system in the off-chain environment based on the file hash. Third, a consistency check is performed between the on-chain hash value and the off-chain file data, and the final verification result is generated to determine whether the data remain complete, untampered, and trustworthy.

By combining the immutability of blockchain technology with the security properties of cryptographic hash functions, this process provides a reliable mechanism for data verification in distributed storage environments. For clarity, the detailed implementation of each stage is described as follows.

(1) 

On-Chain Query of the File Hash Value

The user inputs the IPFS-side hash value $ipfsHash$ of the file to be queried, and the corresponding hash stored in the blockchain system is $\mathit{blockchainHash}$. The on-chain hash retrieval can be expressed as:

$$blockchainFileHash=GetHashFromBlockchain\left(blockchainHash\right)$$

(4)

If the returned result is empty, i.e., $\mathit{blockchainFileHash}=\Phi$, it indicates that the corresponding on-chain record does not exist and the verification cannot proceed.

(2) 

Retrieving the File Content from the IPFS System

If the on-chain data exists, the system reads the corresponding file content from the IPFS system based on the user-input IPFS hash:

$$ipfsFileData=GetFromIPFS\left(ipfsHash\right.)$$

(5)

If $ipfsFileData=“”$, it indicates that the file does not exist in IPFS or has changed, and the verification fails.

(3) 

On-Chain and Off-Chain Data Comparison and Verification

After both the on-chain and off-chain data are successfully retrieved, the system compares the two:

$$validationResult=\left\{\begin{array}{c}true, if blockchainFileData=ipfsFileData\hfill \\ false, otherwise\hfill \end{array}\right.$$

(6)

If the comparison result is true, the on-chain and off-chain data are considered consistent, indicating that the file content has not been tampered with. Otherwise, the inconsistency suggests potential data anomalies or security risks.

Furthermore, in the IPFS-BC model, the data query and verification process is also enforced on-chain through smart contract execution. The smart contract maintains the mapping between user addresses and file hash values (CIDs) and performs consistency verification on the hash values provided by users. The $\mathit{verifyFile} \left(\right)$ function receives the CID submitted by the user, reads the stored on-chain hash value, computes the Keccak-256 hash of both values, and determines whether they are consistent, as expressed by:

$$isValid=Keccak-256\left(\mathit{storedHash}\right)=Keccak-256\left(cid\right)$$

(7)

Upon completion of the verification process, the smart contract triggers the $\mathit{FileVerified} \left(\right)$ event, which records the verification result together with the user address, file hash value, and verification timestamp on the blockchain. This information supports subsequent auditing and forensic analysis. The core parameters and structures of the data query and verification smart contract are summarized in

Table 3. Data query and verification contract parameter structure.

Field	Field Type	Description
fileHashes	mapping	Stores the mapping between the user address and the file hash value (CID), where the key is the user address and the value is the file hash value.
FileVerified	event	File verification event, recording the user address, the file hash value (CID), the verification result, and the timestamp.
verifyFile	function	The user calls this function to verify whether the file hash value (CID) is consistent.
setFileHash	function	For testing purposes
timestamp	uint256	Timestamp, used to record
isValid	Bool	Boolean constant, indicating whether the verification is valid

.

By querying the data hash value and verifying whether the blockchain record matches the corresponding file content stored in IPFS, the system ensures consistency between on-chain and off-chain data. The verification results are recorded by the smart contract in the on-chain log, guaranteeing full traceability and auditability of the verification process, thereby completing the data query and validation phase of the IPFS-BC storage model.

3.2.3. Efficient Management and Access Control

The efficient interaction mechanism between the blockchain network and the IPFS constitutes a core component of the IPFS-BC architecture. In this framework, smart contracts serve as a crucial bridge connecting the blockchain network and the IPFS system, coordinating data transmission and state synchronization between the two. Designing and implementing a smart contract mechanism that not only supports stable interaction between the blockchain and IPFS, but also enables efficient management and control of user access to on-chain data, has become an important technical challenge.

In this study, smart contracts are employed to automatically enforce predefined access control rules, thereby achieving fine-grained control over user data access behavior. Based on the permission policies encoded in the contract, the mechanism can automatically perform operations such as authorization, revocation, and verification, eliminating the dependence on centralized access control authorities and enhancing the degree of decentralization as well as the security and reliability of the system. The detailed workflow of permission control and data interaction is illustrated in Figure 10.

In the research on off-chain storage expansion that integrates FISCO BCOS with IPFS, the IPFS-BC approach first relies on the user registration and identity management smart contracts designed within the FISCO BCOS platform to perform strict authentication of user private keys. This ensures that only legitimate users can obtain data access permissions, thereby safeguarding data security and privacy. Meanwhile, through the associated role management mechanism, the model assigns different roles—such as regular users and administrators—to each user via smart contracts, enabling fine-grained access control and permission configuration, and effectively preventing unauthorized operations. Users who possess upload and storage permissions can upload data to the IPFS distributed storage system. Based on the access frequency and actual storage requirements of the file, the system intelligently selects the optimal storage nodes to improve storage efficiency and response speed. In addition, the entire process is accompanied by an auditing contract that generates comprehensive and detailed audit logs, accurately recording every user action to support subsequent traceability and security analysis.

Within this framework, the user registration and identity management module, the upload and storage contract module, and the auditing contract module work collaboratively to form a complete framework for user permission control and efficient management. The access control mechanism not only restricts data access rights among different users, but also ensures that the identity of the uploading user is legitimate and trustworthy, that permission settings are transparent and dynamically adjustable, and that all user operations are fully traceable, thereby significantly enhancing the overall security and manageability of the system.

(1) 

File Storage and Access Control

In the actual execution process, the system represents a user address as $u$, and the user’s role recorded on the blockchain is defined as:

$$Role\left(u\right)\in \{NONE,USER,ADMIN\}$$

(8)

The access control list of a file is expressed as:

$$AccessList\left(CID\right)=\{u_1,u_2,\dots ,u_m\}$$

(9)

A user has access permission only when:

$$u\in AccessList\left(CID\right)$$

(10)

Before executing file upload and storage, the user must complete identity authentication, represented by the function $Auth\left(u\right)$, where $Auth\left(u\right)=1$ denotes a legitimate user, and $Auth\left(u\right)=0$ denotes authentication failure.

A user is allowed to perform file upload only when $Auth\left(u\right)=1$ and $Role\left(u\right)=USER$ or $ADMIN$.

After a file is successfully uploaded, the system checks whether the user has access permission based on the access control policy, determined by:

$$Access\left(u,CID\right)=\left\{\begin{array}{c}\begin{array}{cc}1,& u\in AccessList\left(CID\right.)\\ 0,& otherwise\end{array}\end{array}\right.$$

(11)

All access operations will be recorded in the audit log for subsequent traceability and management.

(2) 

File Storage and Access Control Management Algorithm

This study abstracts the overall workflow of the access control algorithm into three core operational steps: first, identity authentication is performed to verify the legitimacy of the requesting entity; second, access authorization is executed to allocate appropriate permissions based on policy rules; and finally, storage optimization is applied to improve system resource utilization and response performance.

1. 

Identity Authentication Phase

The system first performs identity authentication on the user address. If authentication fails, the file upload and access process is immediately terminated, and a “user authentication failed” message is returned. The authentication process can be expressed as:

$$Auth\left(u\right)=\left\{\begin{array}{c}true, User is valid\hfill \\ false, User is invalid\hfill \end{array}\right.$$

(12)

2. 

File Upload and Access Authorization Phase

If the authentication is passed, the system executes the file upload module. The file upload function can be abstracted as:

$$uploadSuccess=Upload(u,F,CID,accessType)$$

(13)

If the upload is successful, the system further checks whether the current user has access permission. The access authorization condition is $accessGranted=Access\left(u,CID\right)$, if the verification succeeds, “Access granted” is recorded; otherwise, “Access denied” is recorded.

The system then writes the operation into the log through the audit module:

$$auditLog=Log\left(u,CID,accessGranted,t\right)$$

(14)

3. 

File Storage Optimization Phase

After the upload and access control are completed, the system performs storage optimization strategies based on file fragmentation, node performance, and access frequency, which can be abstracted as:

$$storageSuccess=OptimizeStorage\left(CID,fileChunks,storageNodes\right)$$

(15)

The complete process returns four items: the upload success flag, the access permission judgment result, the audit log, and the storage optimization result, which together constitute the final management output.

4. 

Efficient Management and Audit Smart Contract Logic

The core code structure of the IPFS-BC permission management and auditing contract is detailed in

Table 4. Permission control and efficient management of contract parameter information.

Field	Field Type	Description
Role	enum	Defines user roles, including NONE (no permission), USER (regular user), and ADMIN (administrator).
userRoles	mapping	Stores the mapping between user addresses and roles, where the key is the user address and the value is the user role.
fileAccessList	mapping	Stores the mapping between the file hash value (CID) and the access permission list, where the key is the file hash value and the value is the list of user addresses.
RoleAssigned	event	Role assignment event, recording the user address, the assigned role, and the timestamp.
FileAccessUpdated	event	File access permission update event, recording the file hash value (CID), the user list, and the timestamp.
assignRole	function	The administrator calls this function to assign a role to a user.

, where a modular design approach is adopted to implement a clear and well-defined access control mechanism. The contract first defines an enumeration type, Role, which contains various role options used to distinguish different levels of user permissions. Through the $userRoles$ mapping structure, the system can accurately record and associate the role information corresponding to each user address, thereby providing essential data support for permission management.

File access permissions are maintained by the $fileAccessList$ data structure, which uses the file’s CID as a unique key, and the corresponding value is a dynamic list of user addresses representing all users authorized to access the file. Administrators can flexibly assign or modify user roles by invoking the $assignRole\left(\right)$ function, ensuring that permission configurations remain timely and accurate. In addition, the $updateFileAccess\left(\right)$ function allows administrators to update the access permission list for any file, and each modification triggers a $FileAccessUpdated$ event, which records detailed information about the permission update, enhancing transparency throughout the change process.

To verify user permissions, the contract provides the $hasAccess\left(\right)$ query interface, which efficiently determines whether a given user has the right to access the target file. Meanwhile, all access attempts are recorded by the $logAccessAttempt\left(\right)$ function, which generates log entries containing detailed information such as timestamp, user address, file CID, and the access result, enabling comprehensive tracking of access behaviors.

Through these mechanisms, the system achieves full-process on-chain automation for user role assignment, file permission control, and access record management. This not only significantly enhances the security and controllability of file access operations but also improves the transparency and traceability of permission-related actions through the immutability of blockchain technology, ultimately establishing an efficient and reliable distributed file permission management system.

In IPFS-BC, the data upload process can segment and reduce the scale of large-scale data files in parallel. Moreover, uploading files will generate a unique file hash, ensuring the uniqueness and immutability of the data. When the hash of a file stored in a blockchain system needs to be verified, users only need to manage the request through a smart contract to automatically verify the file information. The fine-grained user identity authentication function and permission operation restrictions in blockchain and smart contracts ensure information security during the interaction process of IPFS-BC, achieving user permission control and efficient management. Through this mechanism, the efficiency and security issues in traditional on-chain and off-chain interaction processes have been solved.

4. Experimental Results and Analysis

To verify the effectiveness and efficiency of the proposed IPFS-BC storage model, we built an underlying blockchain system based on FISCO-BCOS in an Ubuntu environment. On this platform, we compiled and deployed the smart contracts involved in IPFS-BC to support data uploading, storage, verification, querying, user access permission enforcement, and efficient system management. These smart contracts ensure that only authorized users are permitted to access or modify the stored data. Based on this implementation, a blockchain- and IPFS-combined on-chain and off-chain collaborative storage model was realized. Finally, experimental simulations and comparative evaluations were conducted to systematically assess the proposed storage model in terms of network storage resource utilization, storage performance, and security characteristics.

4.1. Experimental Environment

In this study, a blockchain and off-chain storage testing platform was constructed in a local environment to evaluate the storage efficiency and access performance of the IPFS-BC model. The hardware and software configurations of the experimental setup are shown in

Table 5. Experimental Environment Configuration.

Item	Detailed Configuration
CPU	AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx 2.10 GHz
Operating System	Ubuntu 20.04
Blockchain Platform	FISCO BCOS 2.9.0
Smart Contract Language	Solidity
IPFS Version	IPFS Desktop 0.23.0

. The blockchain component adopts FISCO BCOS 2.9.0, with Solidity used to deploy smart contracts for file indexing and access control. The off-chain component employs IPFS Desktop 0.23.0 to manage distributed storage and content addressing for large files. All modules operate within an Ubuntu 20.04 environment.

4.2. Storage Space and Resource Consumption Analysis

Assuming that the local storage capacity of the system is 100 GB and the size of each uploaded file does not exceed 500 MB, the numbers of files automatically uploaded via the IPFS file upload contract are set to 10, 20, 50, 100, and 200, respectively, to verify whether the IPFS-BC storage model can achieve the expected storage expansion effect. During the simulation experiments on storage space and resource consumption, the storage performance of the combined FISCO BCOS + IPFS model is compared with that of DHT-based off-chain storage and the native storage of the FISCO BCOS blockchain system. The results are shown in Figure 11.

Due to the distributed hash table used by DHT systems to store data across multiple nodes in the system, each DHT node only stores a portion of the data. Therefore, when the amount of system file data is small, the storage space occupancy of DHT system storage is also ideal. Moreover, with the increase in data volume, the time for querying and retrieving data within the system may increase storage overhead, resulting in a slow increase in storage space occupancy, but still in a stable state. The FISCO BCOS blockchain system itself is used to store file data. Due to the high redundancy storage mechanism adopted by the system, each node needs to store a complete copy of the blockchain. When storing large-scale data, it will show exponential growth, occupying a lot of system storage space and putting excessive storage pressure. When using the IPFS-BC model to store file data, due to the fact that the IPFS system is a content addressed distributed storage system, the data is dispersed across multiple nodes. The blockchain system only needs to store a small number of hash values, thus significantly reducing storage space usage. By comparing and testing the storage usage of the three models, it can be concluded that the IPFS-BC storage model reduces storage space usage by about 75% compared to FISCO BCOS blockchain storage when storing file data. It can be seen that the IPFS-BC model has significant advantages in terms of storage space occupation when storing large-scale data.

To further analyze system resource consumption, the CPU utilization of different storage schemes during transaction processing was evaluated, and the results are shown in Figure 12.

The light-colored plot represents the local storage space occupied when storing files solely on the FISCO BCOS consortium blockchain. The dark-colored plot illustrates the storage consumption of the new hybrid model that combines FISCO BCOS with the IPFS file system. The purple plot specifically depicts the data variation curve of the DHT-based off-chain storage mode.

Both the FISCO BCOS + IPFS architecture and the pure FISCO BCOS architecture exhibit a relatively stable trend in CPU utilization during the initial stage of transactions. This is mainly because, at the beginning of transaction processing, the data synchronization rate within the blockchain network remains low, and the speed of data retrieval and processing is comparatively slow. However, as on-chain transaction data continues to accumulate and blockchain application scenarios expand and deepen, the amount of data that must be stored on the chain grows significantly, and the forms of stored data become increasingly diverse. These factors collectively cause a rapid increase in the storage burden on each full node, substantially raising the cost of synchronizing the complete dataset.

Under such circumstances, relying solely on FISCO BCOS for data storage leads to a rapid rise in CPU utilization and markedly increased storage pressure. In contrast, although the data read/write speeds of the DHT-based off-chain storage scheme and the IPFS-BC model are relatively slower, their resource consumption remains more stable and manageable. This comparison clearly demonstrates that integrating the IPFS storage mechanism effectively distributes and reduces the storage burden on the blockchain main chain, significantly enhancing the overall scalability and stability of the system.

4.3. Storage Performance Analysis

A series of detailed experimental tests were conducted for three different storage models: DHT-based off-chain storage, FISCO BCOS consortium blockchain storage, and the hybrid FISCO BCOS + IPFS storage scheme. During the experiments, multiple files of varying sizes—specifically 10 MB, 100 MB, 500 MB, and 1 GB—were uploaded sequentially to comprehensively evaluate the performance of each storage approach under different data volumes.

In these experiments, the system response time is defined as the latency measured from the moment the system receives a user’s file storage request to the moment the system completes the response. This metric directly reflects the processing efficiency and real-time performance of the storage system.

Based on the system response time results and the trend illustrated in Figure 13, it can be observed that the storage model using FISCO BCOS for on-chain storage exhibits the longest response time. This is because storing data directly on FISCO BCOS requires multi-node transaction validation through a consensus mechanism, and all participating nodes must maintain a complete copy of the updated data, which introduces additional redundant computation and network overhead.

In contrast, both the DHT off-chain storage model and the IPFS-BC storage model achieve shorter system response times. This is primarily because these two approaches divide the uploaded file into multiple fragments and distribute them across different nodes, while the blockchain needs to store only the data index or hash value. Although the IPFS-BC model incurs extra time overhead for hash mapping and storage permission verification in IPFS, the incorporation of smart-contract-based access control ensures data integrity and secure access while keeping the response time relatively low. The DHT-based off-chain storage model, however, lacks such security guarantees.

Overall, the IPFS-BC storage model significantly improves storage performance in terms of system response time, demonstrating particularly strong advantages when processing large-scale data.

To further analyze the differences in file read and write performance among different storage schemes, a comparative analysis of file write time, system file read time, file write speed, and system file read speed was conducted for three storage models under identical file size conditions, and the results are shown in Figure 14.

Three storage models—DHT-based off-chain storage, FISCO BCOS consortium blockchain storage, and the hybrid FISCO BCOS + IPFS architecture—were evaluated using file upload experiments with different file sizes (10 MB, 100 MB, 500 MB, and 1 GB). For files of identical sizes, the performance of the three storage approaches was comparatively analyzed across four key dimensions: file write time, system file read time, file write speed, and system file read speed.

The test results indicate that although the combined FISCO BCOS + IPFS storage model incurs additional time overhead during file retrieval due to the introduction of off-chain storage, resulting in relatively slower read performance, this storage strategy essentially trades time cost for storage expansion and overall efficiency improvement.

Overall, the hybrid storage model demonstrates significantly better performance compared with pure on-chain storage on FISCO BCOS and DHT-based off-chain network storage. These findings clearly show that the IPFS file system can effectively assist blockchain systems in alleviating storage pressure associated with on-chain transactional data and large-scale data, substantially reducing system storage load and providing considerable practical application value.

4.4. Security Analysis

The traditional FISCO BCOS blockchain system demonstrates significant advantages in data storage security, primarily due to the public–private key cryptographic mechanism integrated within the blockchain and its inherent traceability and auditability features. These characteristics jointly ensure the confidentiality and reliability of data during the storage process. In contrast, when using a DHT for off-chain data storage, the frequent interactions between on-chain and off-chain components may expose data to potential leakage risks during transmission, and the integrity of the data cannot always be guaranteed, thereby introducing security vulnerabilities.

By combining FISCO BCOS with the IPFS, the hybrid storage model not only optimizes local storage resource usage but also improves the overall efficiency of the data storage workflow. During the process of storing data into the system, both FISCO BCOS and IPFS exhibit high system reliability, while the introduction of IPFS-BC further enhances the security of data throughout the on-chain anchoring process. In addition, because both IPFS and blockchain technologies share decentralized characteristics, data is distributed across multiple nodes, and any node can participate in data storage and access, thus improving system robustness and availability.

Whether through generating a unique and tamper-resistant hash value during file upload or performing exact hash matching during data verification, the system can effectively prevent data leakage or unauthorized modification. Furthermore, the automated management and auditing functions provided by smart contracts further strengthen the overall security of the system, ensuring transparency and trustworthiness in all data operations.

5. Discussion

Although the “on-chain index, off-chain storage” paradigm has been widely adopted to alleviate blockchain storage pressure, the core contribution of this work lies not in proposing a new conceptual model, but in the concrete engineering implementation and system-level integration of IPFS with a smart contract–driven control framework. The proposed IPFS-BC model demonstrates how decentralized storage, on-chain indexing, and automated access control can be tightly coupled into a coherent and verifiable storage system suitable for data-intensive blockchain applications.

Compared with purely on-chain storage mechanisms, the IPFS-BC model significantly reduces on-chain storage redundancy by offloading large-scale raw data to the IPFS network while retaining only essential metadata and content identifiers on the blockchain. More importantly, in contrast to direct DHT-based off-chain storage approaches, the proposed system leverages the intrinsic characteristics of IPFS, including content-based addressing, cryptographic integrity verification, and decentralized content retrieval. These properties allow stored data to be uniquely identified and validated through CIDs, which cannot be natively guaranteed by traditional key-based DHT storage without additional verification mechanisms. By anchoring these identifiers on-chain, IPFS-BC establishes a trustworthy binding between off-chain data and on-chain records.

The integration of smart contracts further differentiates the IPFS-BC model from conventional off-chain storage solutions. Rather than treating off-chain storage as an external and loosely coupled component, smart contracts in IPFS-BC enforce access control, automate storage workflows, and maintain auditable operation logs at the protocol level. This contract-driven coordination enables verifiable interaction between blockchain and IPFS, ensuring that data access, modification, and verification processes are transparent and traceable. Such functionality is difficult to achieve in direct DHT-based storage systems, where access control and auditing typically rely on off-chain logic or centralized coordination.

Nevertheless, the experimental analysis and system design reveal that this tightly integrated architecture inevitably introduces additional system complexity. Unlike single-layer storage architectures, IPFS-BC relies on coordinated interactions among blockchain nodes, IPFS nodes, and smart contracts. This multi-component dependency increases the complexity of system deployment, configuration, and monitoring, particularly in large-scale or heterogeneous network environments. Smart contracts, while enabling automation and trust minimization, also introduce challenges related to contract testing, debugging, and upgradeability after deployment.

From an operational perspective, the IPFS layer introduces practical considerations such as node availability, content persistence, and network stability. The accessibility of off-chain data depends on the reliability of IPFS nodes and the effectiveness of replication or pinning strategies. Although these factors do not compromise the correctness or security of the proposed model, they may influence system performance and maintenance costs in real-world deployments. However, these challenges are not unique to IPFS-BC; rather, they reflect common engineering issues encountered in decentralized storage systems and can be mitigated through appropriate system design and operational strategies.

Overall, the IPFS-BC model embodies a deliberate engineering trade-off between architectural simplicity and storage scalability. By choosing IPFS coupled with a smart contract–based coordination mechanism instead of a direct DHT-based storage approach, the system achieves stronger data integrity guarantees, finer-grained access control, and improved auditability at the cost of increased system complexity. With suitable engineering optimizations and modular system design, the proposed architecture provides a practical and extensible foundation for scalable on-chain/off-chain collaborative storage in blockchain-based systems.

6. Conclusions

This paper proposes an on-chain/off-chain collaborative storage method (IPFS-BC) based on blockchain and the IPFS. The method leverages the immutability and verifiability of blockchain technology to accurately record file metadata indexes and access control policies on-chain, while utilizing the content addressing and distributed storage architecture provided by IPFS to achieve efficient off-chain storage and trustworthy on-chain management of large-scale files. The experimental results show that this study effectively reduces the storage burden of blockchain nodes, significantly improves data upload and retrieval speed, and enhances the overall system scalability while ensuring data integrity and controllable access permissions. Future research will focus on designing privacy protection mechanisms for off-chain data, developing cross-chain collaborative storage architectures, and further optimizing system performance in large-scale distributed node environments to continuously improve the security and operational reliability of the IPFS-BC model in real-world applications.