Data-Availability-Aware Hybrid Storage Optimization in Permissioned Blockchains: A Multi-Objective Metaheuristic Approach

Abstract

Modern permissioned blockchain systems increasingly adopt hybrid data architectures in which critical metadata are anchored on-chain, while large or sensitive payloads are stored off-chain using infrastructures such as IPFS and cloud services. Although this paradigm improves scalability and cost efficiency, it introduces a coupled design challenge where latency, operational cost, and security must be balanced simultaneously. Existing Layer-2 and data-availability approaches primarily focus on throughput and verification, leaving data placement decisions in enterprise permissioned environments insufficiently explored. This paper formulates hybrid on-chain, IPFS, and cloud data placement as a multi-objective optimization problem that jointly encodes storage location, transaction execution mode, and key blockchain parameters, aiming to minimize latency and cost while maximizing integrity and resilience. To explore this high-dimensional design space without costly physical deployment, a digital-twin-based evaluation framework is proposed to approximate the performance, cost, and security behavior of a Fabric-class permissioned blockchain integrated with IPFS and cloud storage. The optimization problem is solved using NSGA-II, yielding a Pareto front that reveals fundamental trade-offs among hybrid configurations. The results demonstrate that hash-anchored off-chain storage consistently outperforms purely on-chain and purely off-chain strategies by reducing latency and cost while preserving strong integrity and replication guarantees. The proposed framework provides practical decision support for data-availability-aware permissioned blockchains in domains such as supply chains, healthcare, and disaster response.

1. Introduction

1.1. Motivation

Blockchain-based data infrastructures have become fundamental components of modern digital ecosystems. In supply chain management, blockchain adoption has been widely studied to strengthen traceability and integrity [1,2]. Similar requirements arise in blockchain-enabled healthcare data sharing and privacy-preserving record management [3,4]. In disaster-response and humanitarian logistics, tamper resistance, auditability, and accountability have likewise been emphasized under adverse conditions [5,6]. Blockchain–cloud-integrated platforms have also been reported in regulated energy-market settings, where cloud services complement blockchain-based coordination and auditability requirements [7]. In enterprise and governmental environments, permissioned blockchains are commonly adopted because they provide identity-based access control, governance, and regulatory compliance that are not available in permissionless networks [8,9]. These properties make permissioned ledgers especially suitable for sensitive institutional data sharing and inter-organizational collaboration [10,11]. However, as data volumes and transaction complexity increase, purely on-chain storage becomes increasingly impractical due to high latency, limited throughput, and significant operational cost [12,13]. These limitations severely restrict the scalability of permissioned blockchains, particularly for data-intensive applications and long-term data retention. To overcome these challenges, hybrid blockchain architectures have been widely proposed, in which only cryptographic commitments are stored on-chain, while large data objects are placed in external storage systems such as IPFS or cloud platforms [14,15]. Such designs significantly reduce storage overhead and transaction latency while preserving verifiability and tamper evidence [16,17]. As a result, IPFS-based and cloud-assisted storage backends have become common components of modern enterprise and consortium blockchain deployments [18,19]. These hybrid approaches allow blockchain networks to scale beyond the limitations of native ledger storage while maintaining cryptographic linkage between on-chain and off-chain data [20,21]. However, the adoption of hybrid storage introduces a new and largely underexplored challenge in determining how much data should be placed on-chain, which data should be anchored off-chain, and how these choices interact with transaction execution and blockchain configuration parameters. In practice, storage placement decisions directly affect latency, operational cost, and security guarantees, and their impact is strongly coupled with block size, block interval, and replication strategy. Despite this coupling, current permissioned blockchain deployments often rely on static design choices or domain-specific heuristics, rather than systematic exploration of architectural trade-offs. In parallel, Layer-2 and data-availability mechanisms have been introduced in public blockchains to decouple data storage from transaction execution and improve throughput [22,23]. However, these solutions are primarily designed for permissionless ecosystems and do not directly address the hybrid storage governance, compliance, and configuration decision requirements of enterprise-grade permissioned blockchains [24]. Consequently, there is a clear need for a principled, optimization-driven approach that can systematically explore hybrid storage and execution configurations and reveal Pareto-optimal trade-offs between efficiency, cost, and security in permissioned blockchain systems.

1.2. Problem Statement

Despite the widespread adoption of hybrid blockchain storage architectures, the problem of deciding where data should be stored and how blockchain parameters should be configured remains largely unresolved in permissioned environments. Existing studies typically focus on individual aspects such as off-chain storage integration, access control, or performance analysis, without providing a unified framework that jointly optimizes data placement, execution mode, and network configuration [14,15]. In practical deployments, permissioned blockchains must simultaneously satisfy multiple and often conflicting requirements. Storing data on-chain improves integrity and auditability but leads to higher latency and cost, whereas off-chain storage using IPFS or cloud services improves scalability at the expense of increased dependence on external availability and replication mechanisms [16,18]. These trade-offs become even more pronounced in enterprise settings where regulatory compliance, service-level agreements, and budget constraints must all be considered [8,19]. Recent works have explored hybrid on-chain and off-chain storage models for specific application domains such as healthcare, industrial IoT, and smart cities, demonstrating that no single storage strategy is optimal across all operational scenarios [25,26]. However, most of these approaches rely on fixed architectural assumptions or predefined heuristics, limiting their adaptability to heterogeneous workloads and evolving system requirements [27,28]. In parallel, several optimization-based approaches have been proposed to improve blockchain performance by tuning parameters such as block size, block interval, or replication factor [13,29]. While these studies highlight the benefits of multi-objective optimization, they typically treat storage decisions, execution modes, and network parameters as independent design dimensions, rather than as tightly coupled variables within a single decision space [30,31]. As a result, there is currently no systematic method that enables designers of permissioned blockchains to explore the combined impact of hybrid data placement, transaction execution choices, and network configuration parameters on latency, cost, and security in an integrated manner. This gap motivates the formulation of hybrid blockchain data storage and execution as a unified multi-objective optimization problem, in which architectural trade-offs can be explicitly analyzed and Pareto-optimal configurations can be identified.

1.3. Related Works

On-Chain and Off-Chain Storage in Permissioned Blockchains: Early studies on blockchain storage primarily relied on fully on-chain data persistence to ensure integrity and immutability, but this approach quickly revealed severe scalability and cost limitations in permissioned networks [12,32]. As data volumes grow, ledger expansion and consensus overhead significantly degrade transaction throughput and latency, making pure on-chain storage unsuitable for enterprise-scale applications [9,13]. To address these limitations, off-chain storage mechanisms have been introduced, allowing large payloads to be stored externally while maintaining cryptographic linkage to the blockchain [16,33]. In permissioned settings, such approaches typically combine on-chain hashes with external storage backends to preserve tamper evidence and auditability without incurring excessive on-chain overhead [14,15].

IPFS and Cloud-Assisted Hybrid Storage Architectures: IPFS has emerged as a popular decentralized storage layer for blockchain-integrated systems due to its content-addressable structure and replication support [17,33]. Several studies demonstrate that IPFS-based hybrid storage significantly reduces on-chain storage cost while maintaining data integrity through hash anchoring mechanisms [34,35]. In parallel, cloud-assisted blockchain architectures have been proposed to leverage elastic storage, high availability, and managed services offered by commercial cloud providers [18,19]. Blockchain–cloud integration has been explored in smart-contract-based energy market cloud service platforms, highlighting the role of cloud backends in data-intensive enterprise workflows [7]. In such hybrid deployments, access control remains a core requirement, and systematic reviews have summarized design patterns and open challenges for blockchain-based access control in cloud environments [36]. These blockchain–cloud integration models are particularly attractive for permissioned deployments in healthcare, smart cities, and industrial platforms, where reliability and regulatory compliance are critical [11,27]. However, hybrid IPFS–cloud designs introduce additional trade-offs related to replication, availability zones, and data placement policies, which directly impact latency, operational cost, and resilience [20,21]. Most existing studies evaluate these architectures under fixed configurations, limiting their applicability to dynamic and heterogeneous workloads [28].

Layer-2 and Data Availability Approaches: Layer-2 (L2) and data-availability solutions have been extensively studied in the context of permissionless blockchains to improve throughput and scalability by decoupling data storage from transaction execution [22,23]. Techniques such as rollups and off-chain verification significantly reduce on-chain load while preserving cryptographic verifiability [24]. Despite their effectiveness in public blockchain ecosystems, L2 and data-availability layers are primarily designed for open, adversarial environments and do not directly address governance, access control, or compliance requirements in permissioned blockchains [15,23]. Moreover, these approaches focus on transaction batching and verification rather than fine-grained data placement decisions across heterogeneous storage backends [21].

Optimization-Based Blockchain Configuration and Storage Strategies: Several studies have applied multi-objective optimization techniques to improve blockchain performance by tuning network parameters such as block size, block interval, and replication factor [29,30]. Metaheuristic approaches including genetic algorithms and particle swarm optimization have been shown to effectively balance latency, throughput, and energy-related objectives in blockchain systems [31,37]. Time-variant multi-objective particle swarm optimization has also been explored for peer-device storage optimization in blockchain–IoT settings, highlighting the role of adaptive search strategies under dynamic constraints [38]. More recent works have investigated hybrid optimization strategies that jointly consider storage, execution, and networking aspects in IoT and fog–cloud–blockchain environments [39,40]. However, these studies typically optimize individual subsystems or assume fixed storage architectures, rather than jointly optimizing data placement, execution mode, and network parameters within a unified decision space [28].

Smart-contract design patterns have also been proposed to improve maintainability and reusability when a contract must process multiple, logically consistent transaction types. In particular, AdapT provides a reusable pattern/package for implementing smart contracts that handle any number of congruous transaction types while reducing redundant verification logic [41]. This line of work is complementary to our approach: while AdapT focuses on structuring and reusing on-chain verification and processing logic, the proposed optimization framework decides when transaction families should be executed on-chain versus off-chain anchoring, and how these choices should be co-designed with hybrid storage placement and blockchain parameters.

Research Gap and Positioning of This Study: Although substantial progress has been made in hybrid blockchain storage, cloud integration, and performance optimization, existing studies lack a unified framework that explicitly models the coupled trade-offs between data placement, execution mode, and network configuration in permissioned blockchains. In particular, there is limited work on systematically exploring Pareto-optimal hybrid configurations that balance latency, cost, and security under enterprise governance constraints. This study addresses this gap by formulating hybrid on-chain, IPFS, and cloud data placement as a multi-objective optimization problem and solving it using a Pareto-based evolutionary algorithm. Unlike Layer-2–centric approaches, the proposed framework focuses on data-availability-aware architectural decision support for permissioned blockchains, enabling flexible and context-dependent configuration selection.

1.4. Proposed Approach

This study models hybrid blockchain data storage as a joint optimization problem over three key performance dimensions: latency, cost, and security. Each data class may be stored fully on-chain, off-chain using IPFS or cloud storage with cryptographic anchoring, or in a hybrid configuration. Transaction execution may also occur on-chain or off-chain, with integrity guaranteed by hash commitments. These placement and execution decisions are optimized in conjunction with blockchain configuration parameters such as block size, block interval, and replication factor. To capture these trade-offs, each candidate system configuration is represented as a unified decision vector Θ that jointly encodes three categories of design variables: (i) data placement decisions for each data class, (ii) transaction execution locations, and (iii) blockchain network parameters. This unified representation allows all variables to be optimized simultaneously rather than sequentially, enabling the discovery of Pareto-optimal configurations across multiple objectives. Formally, the decision vector is defined as Θ = [X | Y | Z], where X represents the storage location of each data class, Y represents the execution location of each transaction type, and Z represents the blockchain network parameters. For each data class $D_i$, a 2-bit encoding $x_i$ = {00, 01, 10, 11} is used, where 00 denotes off-chain cloud storage, 01 denotes IPFS storage with off-chain data and on-chain pointer storage, 10 denotes IPFS storage with on-chain cryptographic hash anchoring, and 11 denotes fully on-chain storage, which is typically reserved for small and highly critical data. The complete data placement vector is represented as X = [$x_1$, $x_2$, …, $x_N$]. For each transaction type $P_j$, a 1-bit encoding $y_i$ = {0, 1} is used to determine the execution location, where 0 denotes off-chain execution with result anchoring on-chain, and 1 denotes on-chain execution as a smart contract. The transaction execution vector is represented as Y = [$y_1$, $y_2$, …, $y_M$]. Three key blockchain network parameters are also encoded in the decision vector: block size (B), block interval (T), and replication factor (R). These parameters are selected from predefined discrete sets and represented as Z = [B, T, R]. Together, the data placement, execution, and network parameters form a single chromosome that fully characterizes a hybrid blockchain configuration. Rather than evaluating candidate configurations on a costly physical testbed, a digital-twin-based synthetic evaluation framework is employed to approximate the behavior of a permissioned blockchain integrated with IPFS and cloud storage. For each candidate Θ, this framework estimates latency, cost, and security metrics based on the selected data placement, execution, and network parameters. The resulting multi-objective optimization problem is solved using the Non-dominated Sorting Genetic Algorithm II (NSGA-II), which evolves a population of candidate decision vectors toward a Pareto front of optimal trade-offs between efficiency and integrity. This allows system designers to explore and select hybrid storage and execution configurations that best match their operational priorities.

1.5. Rationale for Selecting NSGA-II

The hybrid data storage optimization problem addressed in this study is inherently multi-objective, involving mutually conflicting criteria of latency, cost, and security. Since no single configuration can simultaneously optimize all objectives, the aim is to identify a diverse set of Pareto-optimal solutions that support informed architectural decision-making rather than a single global optimum. The decision space is discrete and heterogeneous, encompassing categorical data placement choices (on-chain, IPFS, cloud), binary transaction execution modes, and discrete blockchain configuration parameters such as block size, block interval, and replication factor. This structure gives rise to a non-convex, non-differentiable optimization landscape, rendering classical gradient-based methods and scalarized single-objective formulations unsuitable. NSGA-II (Non-dominated Sorting Genetic Algorithm II) is therefore selected as the core optimization method due to its proven effectiveness in solving discrete multi-objective problems without requiring predefined objective weights. By employing Pareto dominance-based ranking and elitist selection, NSGA-II preserves high-quality non-dominated solutions across generations, while its crowding-distance mechanism maintains diversity along the Pareto front. This property is particularly important for systematically exploring a wide spectrum of latency–cost–security trade-offs and enabling context-dependent configuration selection. Moreover, NSGA-II has been extensively adopted in blockchain performance optimization, IoT-enabled systems, and distributed architectures, which enhances both the interpretability and comparability of the obtained results. These characteristics make NSGA-II a robust and well-established choice for addressing the proposed hybrid blockchain data storage optimization problem.

1.6. Contributions

This study contributes a unified architectural decision model for permissioned hybrid storage, where data placement, transaction execution mode, and key blockchain parameters are co-encoded as a single discrete multi-objective decision vector. Unlike works that optimize these dimensions in isolation or under fixed hybrid assumptions, the proposed formulation enables Pareto-based exploration of coupled latency–cost–security trade-offs and supports interpretable regime extraction for deployment-oriented decision making. The main contributions of this paper are summarized as follows:

• Data-availability-aware hybrid storage optimization: Hybrid on-chain, IPFS, and cloud data placement in permissioned blockchains is formulated as a unified multi-objective optimization problem that jointly considers data storage location, transaction execution mode, and blockchain network configuration parameters. Unlike existing approaches that address these design dimensions independently, the proposed formulation explicitly captures their coupled impact on latency, cost, and security. This addresses a modeling gap observed in prior literature, where hybrid storage is often evaluated under fixed or manually selected placement/execution assumptions rather than treated as an architecture-level decision variable within a single optimization model.
• Pareto-based decision support: A Pareto-based architectural decision-support mechanism is introduced to expose the fundamental trade-offs between latency, cost, and security in hybrid permissioned blockchains. By identifying diverse non-dominated configurations, the approach enables the selection of practically relevant operating regimes that align with application-specific performance and compliance requirements. In contrast to studies that report isolated best-case settings, the proposed decision-support view provides a regime-oriented interpretation of the Pareto region, enabling architects to select configurations based on explicit trade-offs and operational priorities rather than a single scalarized optimum.
• Digital-twin-based evaluation framework: A digital-twin-based evaluation framework is developed to approximate the performance, cost, and security behavior of a Fabric-class permissioned blockchain integrated with IPFS and cloud storage. This synthetic yet realistic environment enables controlled and reproducible optimization without requiring full-scale physical blockchain deployments. Unlike conventional one-off simulations, the digital twin is embedded as a structured evaluator that deterministically maps each candidate decision vector to objective estimates, thereby enabling repeatable Pareto-front generation and sensitivity analysis under consistent architectural assumptions.
• Architectural Sensitivity and Design-Space Interpretability: Beyond performance optimization, an architectural sensitivity analysis is provided to clarify how data placement decisions, execution modes, and fundamental blockchain configuration parameters jointly shape distinct operational regimes. By explicitly translating Pareto-optimal regions into a set of named architectural design patterns, the framework enhances the interpretability of multi-objective trade-offs and supports informed deployment decisions in permissioned blockchain systems.

1.7. Paper Organization

The remainder of this paper is organized as follows. Section 2 introduces the system model and the unified decision vector used to encode hybrid data placement, transaction execution modes, and blockchain network parameters. Section 3 presents the NSGA-II-based multi-objective optimization methodology and the chromosome structure. Section 4 describes the digital-twin-based evaluation framework and experimental setup used to approximate performance, cost, and security behavior. Section 5 reports the optimization results, Pareto-front analyses, and representative hybrid configurations. Section 6 discusses the practical implications, architectural insights, and limitations of the proposed framework. Finally, Section 7 concludes the paper and outlines directions for future research.

2. System Model and Security-Aware Hybrid Architecture

2.1. System Scope and Architectural Assumptions

The proposed model targets permissioned blockchain environments, where participants are known, authenticated, and governed by organizational policies [9,11]. Unlike public blockchains, permissioned systems operate under identity-based access control, contractual trust relationships, and enforceable storage and computation policies. This enables reliable enforcement of hybrid storage strategies, predictable performance, and systematic optimization of data placement and execution. Although Hyperledger Fabric is used as a reference implementation for defining execution semantics, consensus behavior, and transaction commit processes, the proposed optimization framework is not restricted to Fabric-specific primitives [9,13]. The model captures a Fabric-class permissioned blockchain, meaning that it assumes (i) deterministic smart-contract execution, (ii) membership service providers, and (iii) configurable block and replication parameters, which are shared by most enterprise-grade permissioned ledgers.

The system integrates three heterogeneous storage layers:

• On-chain ledger storage, which provides immutability and consensus-backed integrity.
• Off-chain decentralized storage (IPFS), which provides content-addressed, distributed data availability.
• Off-chain cloud storage, which provides low-latency, low-cost, and elastic storage capacity.

Hybrid configurations combine these layers by anchoring cryptographic commitments of off-chain objects on the blockchain, enabling verifiable integrity without incurring the cost of full on-chain storage.

2.2. Security and Privacy Model

In hybrid blockchain architectures, security must be distinguished into integrity, availability, and confidentiality, each governed by different mechanisms. Confidentiality is treated as an external enforcement layer rather than an optimization objective, because encryption and key management policies are typically fixed by organizational and regulatory requirements and do not exhibit continuous trade-offs comparable to latency, cost, and integrity. The proposed framework focuses on optimizing integrity and resilience through cryptographic anchoring and replication, while confidentiality is ensured through a complementary encryption and key management layer [8,16,36]. The overall architecture of the proposed permissioned hybrid blockchain system, including encryption, key management, on-chain anchoring, and off-chain IPFS and cloud storage, is illustrated in Figure 1.

2.2.1. Integrity and Availability

For each off-chain object, a cryptographic hash of the payload is stored on-chain [20,21,25]. This ensures that any modification of IPFS or cloud-stored data can be detected by recomputing and comparing hashes. Replication across IPFS peers or cloud availability zones increases resilience against data loss and unavailability. These properties are explicitly captured in the security score optimized by the algorithm.

2.2.2. Confidentiality and Access Control

All off-chain data objects are assumed to be encrypted at the client side before being uploaded to IPFS or cloud storage. The encryption keys are owned by the data-owning organization and are not stored in plaintext on any external storage system. Key management follows a permissioned trust model:

• Data encryption keys are stored and managed in an organizational Key Management Service (KMS) or Hardware Security Module (HSM).
• Only key identifiers and access policies are recorded on-chain.
• Authorized participants obtain decryption keys through organizational policy enforcement, not through the storage layer.

This design ensures that IPFS nodes or cloud providers may store and serve encrypted data, but cannot read its contents.

2.2.3. Key Recovery and Loss Prevention

To prevent catastrophic data loss caused by key deletion or compromise, the model assumes that encryption keys are protected through policy-based escrow and redundancy mechanisms. These include multi-organization threshold key storage, KMS-backed key backup and rotation procedures, and audit-logged key recovery workflows. Together, these mechanisms ensure that encrypted off-chain data remains recoverable while preserving strict access control and accountability.

2.3. Decision Vector Representation

Each candidate system configuration is represented as a unified decision vector Θ = [X | Y | Z], where X encodes the storage location of each data class, Y specifies the execution location of each transaction type, and Z represents the blockchain network parameters.

Data Placement Encoding: For each data class $D_i$, its storage location is represented using a 2-bit encoding $x_i$ = {00, 01, 10, 11}, where 00 denotes off-chain cloud (e.g., AWS S3, Azure Blob), 01 denotes off-chain IPFS with the content identifier stored on-chain, 10 denotes on-chain hash combined with off-chain IPFS storage, and 11 denotes fully on-chain storage (typically used only for small and highly critical data). The set of data placement decisions is represented as X = [$x_1$, $x_2$,...,$x_N$], where N denotes the total number of data classes. The data placement segment of the chromosome has a total length of 2N-bits.

Transaction Execution Encoding: For each transaction type $P_j$, a 1-bit encoding $y_j$ ∊ {0,1} is used to determine the execution location, where 0 indicates off-chain computation with the result hash committed on-chain, and 1 indicates on-chain execution as a chaincode in Hyperledger Fabric. The set of transaction execution decisions is represented as Y = [$y_1$, $y_2$, …, $y_M$], where M is the total number of transaction types. This segment contributes M-bits to the chromosome.

In practical hybrid blockchain deployments, different transaction types may encapsulate data with heterogeneous characteristics, including size, confidentiality level, regulatory sensitivity, and access frequency. In the proposed model, storage-layer selection is not performed at random but is explicitly controlled through the transaction-type encoding component of the decision vector Θ. For each transaction type $t_j$, a dedicated execution-storage mapping rule is defined as part of the chromosome. This mapping determines whether the payload is:

  (i)

fully committed on-chain,

 (ii)

cryptographically anchored on-chain with off-chain bulk storage in IPFS, or

(iii)

stored in cloud infrastructure with on-chain hash verification.

This encoding enables transaction-type-aware storage control, ensuring that heterogeneous transaction categories are deterministically routed to the storage layer consistent with their policy requirements. At runtime, this control logic is enforced through smart contract-level conditional routing rules derived from the optimized configuration. Unlike structural smart-contract design patterns such as AdapT [41], which organize transactions of congruous types within reusable contract templates, the present study operates at the architectural optimization layer. The proposed approach determines the optimal mapping between transaction types and storage regimes prior to deployment, while remaining compatible with contract-level structuring mechanisms.

Network Parameter Encoding: In addition to data placement and execution decisions, three key blockchain network parameters are encoded within the chromosome using discrete bit representations. These parameters include the block size B, encoded with 2-bits and taking values from {0.5 MB, 1 MB, 2 MB, 4 MB}; the block time T, also encoded with 2-bits and selected from {0.5 s, 1 s, 2 s}; and the replication factor R, encoded with 2-bits and ranging over {1, 2, 3}. Together, these parameters form the vector Z = [B, T, R], contributing a total of 6 bits to the overall chromosome length.

2.4. Objective Functions

In the proposed optimization model, each candidate solution Θ is evaluated based on three performance objectives: latency, cost, and security score. These objectives form the fitness vector for the multi-objective optimization process. The goal is to minimize latency and cost while maximizing the security score.

• Latency (L(Θ)): Latency is defined as the time between transaction submission and commit confirmation in the blockchain network. To capture performance under varying conditions, latency is measured at the 95th percentile (p95) across different operational scenarios s ∈ Σ. Each scenario is weighted by its relative importance ${\mathsf{\pi }}_s$, as formulated in Equation (1).

  $$L\left(\Theta \right)={\displaystyle \sum }_{s\in \mathsf{\Sigma }}{\mathsf{\pi }}_s.L_{p95}\left(\Theta ,s\right)$$

  (1)
  Here, Σ is the set of scenarios (e.g., normal load, peak hours, network congestion), ${\mathsf{\pi }}_s$ is the weight of scenario s, and $L_{p95}\left(\Theta ,s\right)$ is the p95 latency observed for Θ in scenario s. The objective is to minimize $L\left(\Theta \right)$.
• Cost (C(Θ)): The total cost combines the on-chain execution cost, off-chain IPFS cost, and off-chain cloud storage cost. Each component is calculated based on storage volume, bandwidth usage, and replication requirements, as formulated in Equation (2).

  $$C\left(\Theta \right)=C_{chain}\left(\Theta \right)+C_{ipfs}\left(\Theta \right)+C_{cloud}\left(\Theta \right)$$

  (2)
  Here, $C_{chain}\left(\Theta \right)$ includes peer/orderer compute time, ledger storage size, and I/O usage, $C_{ipfs}\left(\Theta \right)$ includes pin storage (gigabyte month) and bandwidth usage, and $C_{cloud}\left(\Theta \right)$ includes storage (GB·month), egress charges, and multi-availability-zone costs. The objective is to minimize C(Θ).
• Security Score (S(Θ)): The security score is a composite metric that evaluates the level of on-chain data integrity, replication robustness, and compliance with critical data storage policies. It is defined in Equation (3).

  $$S\left(\Theta \right)=w_1{H}_{cov}\left(\Theta \right)+w_2{R}_{norm}\left(\Theta \right)+w_3{T}_{crit}\left(\Theta \right)-w_4{P}_{loss}\left(\Theta \right)$$

  (3)
  Here, $H_{cov}\left(\Theta \right)$ denotes the ratio of data classes anchored by on-chain hashes, $R_{norm}\left(\Theta \right)$ represents the normalized replication factor (mapped from 1→0 to 3→1), $T_{crit}\left(\Theta \right)$ corresponds to the fraction of small and high-critical data stored fully on-chain, and $P_{loss}\left(\Theta \right)$ captures the estimated probability of data loss. The weighting coefficients w₁, w₂, w₃, and w₄ are policy-defined parameters reflecting organizational priorities and regulatory constraints rather than empirically optimized values, enabling the framework to adapt to diverse deployment contexts. This choice avoids overfitting the optimization process to a specific deployment scenario. The $P_{loss}$ term implicitly accounts for both storage-layer failures and catastrophic key loss scenarios, assuming that key escrow and recovery mechanisms reduce but do not eliminate such risks. The objective is to maximize S(Θ). The security objective is defined as a weighted combination of integrity, replication, and critical-data protection factors. The meaning of each term and its role in the composite score are summarized in

  Table 1. Interpretation of the security-score components used in Equation (3).

  Term	Meaning	Interpretation
  $H_{cov}$	Hash coverage	Fraction of data objects protected by on-chain cryptographic hashes
  $R_{norm}$	Replication level	Normalized replication factor across IPFS and blockchain nodes
  $T_{crit}$	Critical data protection	Fraction of critical data stored on-chain or hash-anchored
  $P_{loss}$	Data loss probability	Estimated probability of off-chain data becoming unavailable or corrupted

  .

Each term captures a distinct aspect of hybrid-storage security, namely integrity anchoring ($H_{cov}$), replication-driven availability ($R_{norm}$), critical-data compliance ($T_{crit}$), and residual unavailability risk ($P_{loss}$).

3. Multi-Objective Optimization Methodology

3.1. Rationale for Pareto-Based Optimization

Hybrid blockchain storage design inherently involves conflicting objectives [15,29]. Configurations that maximize security through full on-chain storage and high replication inevitably increase latency and operational cost, whereas configurations that minimize cost and latency by relying on off-chain cloud storage significantly weaken data integrity and resilience. Consequently, the problem does not admit a single globally optimal solution but instead yields a set of Pareto-optimal trade-offs, each representing a different balance among performance, cost, and security. Pareto-based optimization is therefore a natural choice for this problem, as it preserves diversity among competing solutions and allows system designers to select configurations that best match their operational priorities. Rather than collapsing all objectives into a single weighted score, the proposed framework explicitly models latency, cost, and security as independent dimensions, enabling transparent trade-off analysis. The overall optimization workflow, including decision encoding, digital-twin-based evaluation, and NSGA-II-driven Pareto search, is illustrated in Figure 2.

3.2. Selection of NSGA-II

Based on the problem characteristics outlined in Section 1.5, NSGA-II is employed as the core multi-objective optimization algorithm in this study. Its Pareto dominance-based selection and crowding-distance mechanisms enable an effective exploration of the latency–cost–security trade-off space while preserving solution diversity. Given the discrete and heterogeneous nature of the decision variables, NSGA-II provides a computationally efficient and well-established baseline for generating representative Pareto-optimal configurations within the proposed framework [29,30,40].

3.3. Chromosome Structure and Initialization

Each candidate solution Θ is represented as a chromosome that concatenates data placement decisions, execution modes, and network parameters, defined as Θ = [$x_1$,$x_2$, …, $x_N$ | $y_1$,$y_2$, …, $y_M$ | B | T | R], where the total chromosome length is 2N+M+6 bits. The initial population is generated randomly under feasibility constraints. In particular, critical data classes are required to satisfy integrity policies, such that they must be assigned to on-chain or hash-anchored storage options. This constrained initialization ensures that the search starts from a feasible and security-compliant region of the design space, preventing the optimizer from wasting computational effort on invalid configurations.

3.4. Genetic Operators

Uniform crossover is applied at the segment level to preserve the semantic integrity of the encoded variables. For categorical two-bit data placement fields, swapping is performed in two-bit blocks, whereas binary execution flags and network parameter bits are exchanged independently. Mutation is implemented through a hybrid strategy in which binary fields undergo bit-flip operations, categorical fields are reassigned to alternative valid storage codes, and network parameters are mutated by selecting different permissible discrete values. This approach maintains population diversity while ensuring compliance with domain-specific constraints.

3.5. Constraint Handling and Repair

After crossover and mutation, offspring chromosomes are checked against security and policy constraints. If a violation is detected, a minimal repair operator is applied to restore feasibility, for example by converting a cloud-only placement of critical data into a hash-anchored IPFS or on-chain configuration. This ensures that all evaluated solutions comply with the system’s trust and integrity requirements. To make the complete NSGA-II-based search process explicit, Algorithm 1 summarizes how the decision vectors Θ = [X | Y | Z] are evolved, evaluated by the digital twin, and filtered into a feasible Pareto-optimal set.

Algorithm 1. NSGA-II-Based Optimization of Hybrid Blockchain Storage and Execution

Input: Population size P, generations Gmax, Npop—population size, Gmax—maximum number of generations, DT(Θ)—digital-twin evaluator returning (L(Θ), C(Θ), S(Θ)), Feasible(Θ)—constraint and repair function Output: Pareto-optimal set of configurations Θ* 1    Initialize population P0 with Npop feasible chromosomes Θ = [X | Y | Z] 2    Evaluate each Θ ∈ P0 using DT(Θ) → (L, C, S) 3    Perform non-dominated sorting and crowding-distance assignment 4    t ← 0 5    while t < Gmax do 6      Select parent population Pt from Pt using NSGA-II tournament selection 7      Apply crossover and mutation on Pt to generate offspring Qt 8      Apply Feasible(Θ) to repair invalid offspring 9      Evaluate each Θ ∈ Qt using DT(Θ) 10    Rt ← Pt ∪ Qt 11    Perform non-dominated sorting on Rt 12    Select the best Npop individuals based on Pareto rank and crowding distance 13    Set Pt+1 ← selected population 14    t ← t + 1 15  endwhile 16  return the final non-dominated Pareto front Θ*

Algorithm 1 shows how NSGA-II iteratively explores the hybrid storage design space by evolving the decision vector Θ under digital-twin-based evaluation and feasibility constraints. The procedure ensures that only valid, security-compliant configurations are retained while progressively refining the Pareto-optimal trade-off surface.

3.6. Convergence and Pareto Front Formation

The algorithm terminates after a predefined number of generations or when improvements in the Pareto front become negligible. Although some experimental tables exhibit a stable Pareto set size across generations, can be attributed to the discrete nature of the decision space and the strong constraint structure, which limit the number of fundamentally distinct optimal trade-offs. As convergence progresses, NSGA-II refines the quality and distribution of these Pareto-optimal solutions rather than increasing their cardinality.

4. Digital-Twin-Based Experimental Setup

4.1. Digital Twin and Synthetic Evaluation Framework

Deploying and benchmarking a full-scale permissioned blockchain integrated with IPFS and cloud storage for each candidate configuration would be prohibitively expensive. It would also be operationally infeasible. Each configuration would require re-deployment of blockchain parameters, replication factors, storage backends, and execution modes, leading to significant overhead and limited experimental coverage. To overcome this limitation, the proposed framework employs a digital-twin-based synthetic evaluator that approximates the behavior of a Fabric-class permissioned blockchain integrated with IPFS and cloud storage. The digital twin models the dominant performance and cost drivers observed in real systems by capturing on-chain execution overhead and block commit delay, off-chain storage and retrieval latency, replication-induced network and storage overhead, as well as the costs associated with cryptographic anchoring and integrity verification. Rather than simulating packet-level network behavior, the evaluator operates at the architectural level by mapping the decision vector Θ into latency, cost, and security outcomes through explicitly stated parametric relationships and a quantified noise model [28,39]. Such an abstraction enables efficient exploration of thousands of candidate configurations while preserving the fundamental trade-off structure of real deployments. The objective of this study is architectural decision support rather than implementation benchmarking; therefore, no production-grade prototype or public code repository is provided at this stage.

Scalability and generality of N and M: In the illustrative experimental configuration, the number of data classes and transaction types are set to N = 6 and M = 4 to maintain clarity of presentation. However, the decision vector formulation is defined for arbitrary values of N and M. The placement segment scales linearly with 2N-bits (two bits per data class), and the execution segment scales linearly with M-bits. Consequently, the total chromosome length grows as O(N + M), and the NSGA-II optimization complexity increases linearly with the number of modeled entities.

The proposed formulation does not assume homogeneous data characteristics. Each data class is treated as an independent decision unit and may represent heterogeneous sizes, access frequencies, or criticality levels. Such heterogeneity is implicitly captured through the architectural ratios used in the evaluator and can be further weighted if required in large-scale enterprise scenarios. Therefore, the encoding scheme and objective formulation remain valid for dozens or hundreds of data classes without structural modification.

4.2. Mapping from Decision Vector to Performance Metrics

For each candidate configuration Θ, the evaluator decodes the corresponding data placement, transaction execution, and network parameters to estimate the objective values. Latency is modeled to increase with higher proportions of on-chain execution and storage, while shorter block intervals and increased replication further contribute to commit delays. Cost is driven by on-chain computation overhead, ledger growth, IPFS pinning requirements, cloud storage volume, and cross-zone data transfers. Security improves with greater on-chain hash coverage, higher replication levels, and a larger fraction of critical data stored on-chain, but decreases when off-chain storage relies on single-location deployments. To reflect stochastic variability present in real distributed systems, Gaussian noise is injected into each metric, emulating workload fluctuations, network jitter, and transient performance effects. The proposed digital-twin approach does not aim to reproduce absolute real-world numbers, but it accurately preserves relative trade-offs, which is the key requirement for Pareto-based optimization and architectural decision support.

Evaluator transparency and parametric instantiation: To ensure full transparency of the synthetic evaluation process, the mapping from a decoded chromosome Θ = [X | Y | Z] to the objective triplet (L(Θ), C(Θ), S(Θ)) is formally defined. Let N denote the total number of data classes and M the total number of transaction types. After decoding the placement and execution segments X and Y, the numbers of data classes assigned to on-chain, hash-anchored, IPFS, and cloud storage are denoted by $n_{on}, n_{hash}, n_{ipfs}, n_{cloud}$ respectively, and the number of transaction types executed on-chain is denoted by $m_{on}$. The control parameters are decoded as Z = [B, T, R], representing block size, block interval, and replication factor, consistent with Table 2. From these decoded quantities, architectural-level latency is computed through a monotonic parametric core that captures ordering pressure, execution overhead, replication amplification, and off-chain retrieval effects. The deterministic latency component is given by

$$L_{det}\left(\Theta \right)=L_0+{\alpha }_1\left({\displaystyle \frac{m_{on}}{M}}\right)+{\alpha }_2\left({\displaystyle \frac{n_{on}}{N}}\right)+{\alpha }_3\left({\displaystyle \frac{1}{T}}\right)+{\alpha }_4\left({\displaystyle \frac{1}{B}}\right)+{\alpha }_5\left(R-1\right)+{\alpha }_6\left({\displaystyle \frac{n_{ipfs}}{N}}\right)+{\alpha }_7\left({\displaystyle \frac{n_{cloud}}{N}}\right)$$

(4)

As expressed in Equation (4), higher fractions of on-chain execution or storage increase latency due to validation and ordering overhead, shorter block intervals increase consensus pressure, and higher replication factors amplify synchronization cost. Conversely, larger block sizes reduce ordering frequency, thereby lowering the latency score. In a similar manner, the cost objective is formulated at the architectural level by aggregating execution overhead, ledger growth, off-chain storage volume, and replication-induced infrastructure burden. The deterministic cost component is defined as

$$C_{det}\left(\Theta \right)=C_0+{\beta }_1\left({\displaystyle \frac{m_{on}}{M}}\right)+{\beta }_2\left({\displaystyle \frac{n_{on}}{N}}\right)+{\beta }_3\left({\displaystyle \frac{n_{ipfs}}{N}}\right)+{\beta }_4\left({\displaystyle \frac{n_{cloud}}{N}}\right)+{\beta }_5\left(R-1\right)$$

(5)

Equation (5) preserves architectural monotonicity: increasing on-chain execution or storage raises computational and ledger-maintenance cost, while off-chain and cloud allocations reflect storage and pinning expenses. Replication linearly increases infrastructure demand. The security objective S(Θ) is computed according to Equation (3), instantiated using the decoded placement ratios and replication factor. Higher on-chain or hash-anchored coverage and increased replication monotonically improve integrity and availability, while reliance on single off-chain locations reduces resilience. To emulate bounded environmental variability while preserving qualitative Pareto structure, zero-mean Gaussian perturbations are introduced. The final objective values are computed as

$$L\left(\Theta \right)=L_{det}\left(\Theta \right)+{\mathcal{E}}_L, C\left(\Theta \right)=C_{det}\left(\Theta \right)+{\mathcal{E}}_C$$

(6)

$$S\left(\Theta \right)=\min \left\{1,\max \left\{0, S_{det}\left(\Theta \right)+{\mathcal{E}}_S\right\}\right\}$$

(7)

The perturbation terms follow Gaussian distributions

$${\mathcal{E}}_L~\mathbf{𝒩}(0,{\left(K_L{L}_{det}\right)}^2), {\mathcal{E}}_C~\mathbf{𝒩}(0,{\left(K_C{C}_{det}\right)}^2), {\mathcal{E}}_S~\mathbf{𝒩}(0,{K_S}^2)$$

(8)

where $K_L$ = 0.03, $K_C$ = 0.02, and $K_S$ = 0.01. These coefficients ensure limited stochastic dispersion without distorting the underlying trade-off geometry. The proportional scaling of variance ensures that stochastic dispersion grows consistently with architectural magnitude, while remaining sufficiently small to preserve Pareto dominance relations. The specific coefficient values used to instantiate Equations (4)–(8) in the experimental evaluation are summarized in Table 2. These values define the relative architectural sensitivities of latency and cost to placement, execution, and replication decisions.

Table 2. Default digital-twin coefficients used in Equations (4)–(8).

Group	Parameter	Value
Latency	$L_0$	40
Latency	${\alpha }_1,{\alpha }_2,{\alpha }_3,{\alpha }_4,{\alpha }_5,{\alpha }_6,{\alpha }_7$	35, 45, 12, 8, 10, 6, 3
Cost	$C_0$	0.30
Cost	${\beta }_1,{\beta }_2,{\beta }_3,{\beta }_4,{\beta }_5,{\beta }_6,{\beta }_7$	0.45, 0.55, 0.35, 0.25, 0.25

Table 2. Default digital-twin coefficients used in Equations (4)–(8).

Group	Parameter	Value
Latency	$L_0$	40
Latency	${\alpha }_1,{\alpha }_2,{\alpha }_3,{\alpha }_4,{\alpha }_5,{\alpha }_6,{\alpha }_7$	35, 45, 12, 8, 10, 6, 3
Cost	$C_0$	0.30
Cost	${\beta }_1,{\beta }_2,{\beta }_3,{\beta }_4,{\beta }_5,{\beta }_6,{\beta }_7$	0.45, 0.55, 0.35, 0.25, 0.25

The coefficients are selected to preserve architectural monotonicity and scale consistency with the reported synthetic results, without claiming deployment-specific calibration. To further eliminate any ambiguity regarding the internal mechanics of the digital-twin evaluator, the chromosome-to-objective mapping procedure is explicitly summarized in Algorithm 2. The algorithm details how placement, execution, and control decisions are decoded and transformed into deterministic latency, cost, and security components, followed by controlled stochastic perturbation. This representation complements the analytical formulation in Section 4.2 and makes the evaluation pipeline fully transparent.

Algorithm 2. Digital-Twin Evaluation of Blockchain Configurations

Input: Chromosome Θ = [X | Y | Z], X: data placement (N items), Y: execution mode (M items),          Z: control parameters [B, T, R] Output: Objective vector (L(Θ), C(Θ), S(Θ)) 1    Initialize counters: $n_{on}$←0, $n_{ipfs}$←0, $n_{cloud}$←0, $m_{on}$←0, $n_{hash}$←0 2    for i = 1 to N do 3    if $X_i$ = ON_CHAIN then $n_{on}$←$n_{on}$+1 4    else if $X_i$ = HASH_ANCHOR then $n_{hash}$←$n_{hash}$+1 5    else if $X_i$ = IPFS then $n_{ipfs}$←$n_{ipfs}$+1 6    else if $X_i$ = CLOUD then $n_{cloud}$←$n_{cloud}$+1 7    endfor 8    for j = 1 to M do 9    if $Y_j$ = 1 then $m_{on}$←$m_{on}$+1 10  endfor 11  Calculate ratios: $r_{exec}$←($m_{on}$)/M, $r_{on}$←($n_{on}$)/N, $r_{ipfs}$←($n_{ipfs}$)/N, $r_{cloud}$←$(n_{cloud}$)/N, $r_{hash}$←$(n_{hash})$/N 12  Decode control parameters (B, T, R) from Z 13  Compute deterministic latency, cost, and security: 14  $L_{det}$(Θ)←$L_0$+${\alpha }_1{r}_{exec}+{\alpha }_2{r}_{on}+{\alpha }_3\left(1/T\right)+{\alpha }_4\left(1/B\right)+{\alpha }_5\left(R-1\right)+{\alpha }_6{r}_{ipfs}+{\alpha }_7{r}_{cloud}$ 15  $C_{det}\left(\Theta \right)\leftarrow C_0+{\beta }_1{r}_{exec}+{\beta }_2{r}_{on}+{\beta }_3{r}_{ipfs}+{\beta }_4{r}_{cloud}+{\beta }_5\left(R-1\right)$ 16  $S_{det}$(Θ)←SecurityScore($r_{on}$, $r_{hash}$, R) 17  Inject stochastic noise using Digital-Twin uncertainty:${\mathcal{E}}_L~$N$(0,{\left(K_L{L}_{det}\right)}^2$),${\mathcal{E}}_C~$N$(0,{\left(K_C{C}_{det}\right)}^2$), ${\mathcal{E}}_S~$N$(0,{K_S}^2$) 18  Finalize objectives:$L$(Θ)←$L_{det}\left(\Theta \right)$+${\mathcal{E}}_L$, $C\left(\Theta \right)\leftarrow C_{det}\left(\Theta \right)+{\mathcal{E}}_C$, $S\left(\Theta \right)\leftarrow \min \{1,\max \left\{0,S_{det}\left(\Theta \right)+{\mathcal{E}}_S\}\right\}$ 19  return L(Θ), C(Θ), S(Θ)

Algorithm 2 clarifies that the evaluator operates purely at the architectural abstraction level. All objective values are derived deterministically from decoded ratios and control parameters before bounded stochastic variability is introduced. The perturbation terms remain sufficiently small to preserve Pareto dominance ordering while preventing artificial degeneracy in the population. As a result, the Pareto front reflects structured trade-offs induced by placement, execution, and replication decisions rather than artifacts of an opaque evaluation model.

The framework operates at the architectural abstraction level and is not intended to replicate packet-level network simulations, peer-to-peer message propagation, or bytecode-level smart contract execution traces. Instead, it captures the structural effects of placement, execution, and replication decisions through monotonic parametric relationships that preserve trade-off consistency. The objective of the evaluator is to generate structurally meaningful Pareto-optimal regimes for architectural comparison rather than deployment-specific performance benchmarks. As such, the framework emphasizes transparency, reproducibility, and controlled parametric sensitivity over low-level system emulation.

4.3. Baseline Configurations

To assess the benefit of hybrid optimization, three baseline strategies are compared:

• IPFS-only: All data classes are stored in IPFS with on-chain hash anchoring, while blockchain parameters are optimized.
• Cloud-only: All data is stored in cloud storage without decentralized replication, with only minimal on-chain anchoring.
• Hybrid (Proposed): Data placement, execution modes, and blockchain parameters are jointly optimized across on-chain, IPFS, and cloud layers.

These baselines allow direct evaluation of whether hybrid, data-availability-aware configurations can achieve superior latency–cost–security trade-offs compared to single-technology deployments. To ensure that the optimization explores a realistic and sufficiently rich design space, the digital twin is parameterized over a discrete set of storage, execution, and blockchain configuration options, as summarized in

Table 3. System parameter space used in the digital twin.

Parameter	Description	Discrete Values
Data storage type	Storage location for each data class	On-chain, IPFS (hash-anchored), Cloud
Transaction execution	Execution mode for each transaction type	On-chain, Off-chain
Block size (B)	Maximum block payload	0.5 MB, 1 MB, 2 MB, 4 MB
Block interval (T)	Block generation time	0.5 s, 1 s, 2 s
Replication factor (R)	Number of ledger replicas	1, 2, 3

.

To make the operation of the digital twin more transparent, it is important to illustrate how a concrete chromosome Θ = [X | Y | Z] is decoded into a hybrid storage configuration and subsequently mapped into quantitative performance metrics. Each chromosome specifies the storage location of each data class, the execution mode of each transaction type, and the blockchain network parameters. The digital twin then applies the latency, cost, and security models described above to compute the corresponding objective values L(Θ), C(Θ), and S(Θ). Representative examples of this decoding and evaluation process are reported in

Table 4. Example of digital-twin evaluation for representative hybrid chromosomes.

Chromosome (Bitstring)	Data Placement (X)	Proc. Exec. (Y)	Block Size	Block Time	Replication	L(Θ)	C(Θ)	S(Θ)
10 11 00 01 01 10	[Hash + IPFS, Full On-chain, Cloud, IPFS, IPFS, Hash + IPFS]	[1, 0, 0, 1]	4.0 MB	0.5 s	2	128.53	1.245	0.872
00 00 01 01 00 00	[Cloud, Cloud, IPFS, IPFS, Cloud, Cloud]	[0, 0, 0, 0]	1.0 MB	2.0 s	1	89.21	0.945	0.412

.

Policy Weight Instantiation and Regime Sensitivity: In the aggregated objective formulation given in Equation (3), the weights $w_1,w_2,w_3$ and $w_4$ represent policy-level priorities assigned to latency, cost, security, and reliability, respectively. These weights are defined within a normalized policy vector satisfying the constraint given in Equation (9).

$$w_i\in \left[0,1\right], {{\displaystyle \sum }}_{i=1}^4{w}_i=1$$

(9)

In the baseline experimental configuration, a neutral policy profile is adopted with $w_1=w_2=w_3=w_4=0.25$. This ensures that the regime structures identified in Section 5.2 emerge from the intrinsic architectural trade-offs rather than from an imposed dominance of any single objective. Alternative priority profiles can also be defined within the same formulation. For example, a latency-sensitive configuration can be expressed as $w_1$ = 0.40, $w_2$ = 0.20, $w_3$ = 0.20, $w_4$ = 0.20, while a security-priority configuration may be expressed as $w_1$ = 0.20, $w_2$ = 0.20, $w_3$ = 0.40, $w_4$ = 0.20. Adjusting these weights does not modify the optimization model or the Pareto set itself; rather, it changes the preference projection over the same feasible design space. Consequently, regime boundaries are policy-sensitive yet remain structurally grounded in the objective landscape defined by Equation (3).

4.4. Experimental Protocol

NSGA-II is executed with a population size of 60 over 80 generations. Each generation evaluates all individuals according to the three objectives [L(Θ), C(Θ), −S(Θ)]. Experiments are repeated using multiple random seeds to assess stability, and results are reported as mean and standard deviation where applicable. The final outcome of each run is a Pareto-optimal set of configurations representing the best achievable trade-offs under the given architectural assumptions.

5. Results and Pareto-Based Performance Analysis

5.1. Optimization Behavior and Convergence

The convergence behavior of the NSGA-II optimizer across generations is shown in Figure 3, illustrating how latency, cost, and security objectives evolve during the search process.

The evolution of the objective values over generations demonstrates a rapid improvement during the early stages of the optimization process, followed by gradual refinement as the Pareto front stabilizes. Latency and cost decrease sharply within the first 10–20 generations, indicating that NSGA-II quickly identifies promising regions of the design space. Security scores increase early and remain consistently high, reflecting the algorithm’s ability to preserve integrity and resilience while exploring cost-efficient configurations. The convergence behavior confirms that the optimizer does not collapse toward a single extreme solution but instead maintains a stable set of trade-off configurations that reflect fundamentally different architectural strategies. It is also worth noting that the size of the non-dominated Pareto set remains stable across later generations, which is consistent with the discrete and constrained nature of the design space, as discussed in Section 3.6.

5.2. Pareto Front Structure

The global trade-off structure uncovered by NSGA-II is visualized through the final Pareto front shown in Figure 4, which illustrates how latency, cost, and security interact across optimized hybrid storage configurations.

Figure 4 reveals that hybrid storage configurations form a dominant Pareto region that consistently outperforms purely on-chain and purely off-chain designs across the latency–cost–security trade-off space. In particular, solutions combining on-chain hash anchoring with IPFS or cloud storage achieve comparable security levels with substantially lower latency and cost. The dispersion of Pareto-optimal points further indicates the presence of distinct operating regions rather than a single optimal configuration. These observations motivate the architectural regime-based interpretation presented in the Discussion section. To illustrate how individual Pareto-optimal points translate into concrete system designs, several representative hybrid configurations are reported in

Table 5. Representative Pareto-optimal hybrid storage configurations.

Solution	Latency	Cost	Security	Block Size (MB)	Block Interval (s)	Replication	Storage Strategy
P1 (Low-Cost)	Low	Very Low	Medium	4	2.0	1	Cloud + IPFS (hash-anchored)
P2 (Balanced)	Medium	Medium	High	2	1.0	2	IPFS + On-chain hashes
P3 (High-Security)	High	High	Very High	1	0.5	3	Critical data on-chain, others IPFS
P4 (Low-Latency)	Very Low	Medium	Medium	4	0.5	2	Cloud + On-chain hashes
P5 (Resilient)	Medium	High	Very High	2	1.0	3	IPFS replicated + On-chain anchoring

.

The final Pareto front in the latency–cost plane reveals three dominant architectural regimes:

• Low-latency, low-cost region: These solutions primarily rely on cloud and IPFS storage with minimal on-chain execution. They achieve excellent performance and cost efficiency but exhibit reduced security due to limited cryptographic anchoring and replication.
• High-security region: These solutions store a large fraction of data fully on-chain or use hash-anchored IPFS with high replication. While they provide strong integrity and resilience, they incur higher latency and operational cost.
• Balanced hybrid region: The most practically relevant configurations lie between these extremes. They combine on-chain hash anchoring for critical data with IPFS or cloud storage for large payloads, together with moderate replication and optimized block parameters. These solutions achieve substantial reductions in latency and cost compared to fully on-chain designs while preserving strong security guarantees.

The smooth gradient of security values across the Pareto front confirms that the digital twin correctly captures the fundamental trade-offs of hybrid blockchain architectures.

5.3. Representative Pareto-Optimal Configurations

While Pareto fronts and convergence curves provide a global view of the optimization landscape, practical deployment decisions require concrete and interpretable system configurations. Accordingly, a subset of representative non-dominated solutions is summarized in

Table 6. Representative Pareto-optimal hybrid blockchain configurations.

ID	L(Θ)	C(Θ)	S(Θ)	Block Size (MB)	Block Time (s)	Replication	On-Chain Data (%)	IPFS Data (%)	Cloud Data (%)	On-Chain Exec (%)
1	130.89	2.01	1.03	4.0	0.5	3	70	25	5	75
2	112.92	0.92	0.41	4.0	2.0	1	10	20	70	10
3	110.71	0.93	0.37	4.0	2.0	1	15	15	70	10
4	205.84	1.60	0.97	4.0	2.0	2	60	30	10	60
5	62.88	1.02	0.38	4.0	0.5	1	20	30	50	20

to illustrate how different on-chain, IPFS, and cloud placement strategies, together with blockchain parameter settings, translate into latency, cost, and security outcomes.

These configurations correspond to different regions of the Pareto front and provide interpretable deployment options for diverse operational priorities.

5.4. Comparison with Baseline Strategies

Pure IPFS-only and cloud-only baselines occupy limited regions of the Pareto space. IPFS-only configurations improve over full on-chain storage but still incur noticeable latency and replication overhead. Cloud-only configurations achieve low cost and latency but consistently score poorly in terms of security. In contrast, the proposed hybrid optimization framework produces a much broader and more favorable Pareto front, offering configurations that dominate the baselines in at least one objective without excessively sacrificing the others. This demonstrates that data-availability-aware hybrid placement is essential for achieving scalable yet trustworthy permissioned blockchain systems.

5.5. Baseline Comparison with Alternative Multi-Objective Optimizers

To assess whether NSGA-II provides competitive Pareto-set quality for the proposed discrete hybrid storage optimization problem, we performed a comparative evaluation against three widely used multi-objective baselines, SPEA2, MOPSO, and MOEA/D. All algorithms were executed under the same evaluation budget, using a population (or swarm) size of 60 and 80 generations/iterations, repeated over 30 independent runs with randomized seeds. Since security is naturally a maximization objective, it was transformed to a minimization form as S’(Θ) = 1 − S(Θ) for a consistent three-objective minimization setting. Pareto-set quality was quantified using hypervolume (HV, higher is better), inverted generational distance (IGD, lower is better), and the size of the obtained non-dominated set (|P|). HV was computed with respect to a common reference point derived from the worst objective values observed across all runs, while IGD was computed using the combined non-dominated solutions from all algorithms as an empirical reference front. The comparative results are summarized in

Table 7. Comparison of multi-objective optimizers (30 runs, mean ± std). Arrows indicate whether higher (↑) or lower (↓) values correspond to better performance.

Algorithm	HV ↑ (Mean ± Std)	IGD ↓ (Mean ± Std)	|P| ↑ (Mean ± Std)	Best L ↓ (Mean ± Std)	Best C ↓ (Mean ± Std)	Best S ↑ (Mean ± Std)
NSGA-II	229.979 ± 2.566	1.073 ± 0.120	60.00 ± 0.00	45.071 ± 0.427	0.719 ± 0.032	0.924 ± 0.008
SPEA2	227.253 ± 3.193	1.337 ± 0.599	60.00 ± 0.00	46.281 ± 1.553	0.860 ± 0.047	0.910 ± 0.013
MOPSO	212.699 ± 3.526	1.851 ± 0.688	60.00 ± 0.00	47.227 ± 1.839	0.752 ± 0.022	0.908 ± 0.012
MOEA/D	119.872 ± 18.676	33.582 ± 5.142	53.47 ± 4.67	44.125 ± 0.315	1.016 ± 0.080	0.506 ± 0.048

and visualized in Figure 5. Overall, NSGA-II achieves strong and stable Pareto-set quality, indicating that it is a suitable optimizer for discrete hybrid on-chain/off-chain storage configuration problems under the proposed digital-twin evaluation setting.

To further examine the run-to-run stability of the optimizers beyond the mean ± std summary in Table 7, Figure 5 visualizes the distribution of hypervolume (HV) values across 30 independent runs.

As shown in Figure 5, NSGA-II achieves the highest HV with a narrow interquartile range, indicating both strong Pareto-set quality and consistent performance across runs. SPEA2 remains competitive but yields slightly lower HV values. MOPSO produces noticeably lower HV, suggesting reduced coverage of the dominated objective space. In contrast, MOEA/D exhibits substantially lower HV and large variability, implying instability and difficulty in maintaining a high-quality Pareto set under the discrete decision encoding and noisy digital-twin evaluation. While HV captures convergence and diversity jointly, Figure 6 reports the inverted generational distance (IGD) distributions to explicitly quantify how closely the obtained Pareto sets approach the empirical reference front.

Figure 6 further confirms this trend. NSGA-II attains the lowest IGD values with limited dispersion, demonstrating reliable convergence toward the empirical reference front. SPEA2 shows higher IGD and increased variability, whereas MOPSO yields consistently larger IGD values. MOEA/D performs significantly worse, with IGD values orders of magnitude higher than the other optimizers, indicating that its solutions remain far from the reference front in this problem setting. The weaker behavior of MOEA/D can be attributed to the combination of (i) discrete/binary decision encoding, (ii) strong objective coupling between storage placement and network parameters, and (iii) stochastic noise injected by the synthetic evaluator. Under these conditions, decomposition-based search with fixed weight vectors may have difficulty preserving stable subproblem optimization progress and generating well-distributed non-dominated solutions, whereas Pareto-ranking-based methods such as NSGA-II and SPEA2 remain more robust.

6. Discussion

6.1. Architectural Interpretation of the Pareto Front

The obtained Pareto front demonstrates that hybrid data placement is not a secondary implementation detail but a primary architectural control mechanism in permissioned blockchains [14,15]. The optimization results show that latency, cost, and security cannot be independently tuned, but instead emerge from tightly coupled interactions between storage location, execution mode, and blockchain network parameters [29]. Three dominant architectural regimes can be observed across the Pareto surface. The first regime is characterized by low cost and low latency, achieved primarily through extensive use of cloud storage and off-chain execution, combined with large block sizes and longer block intervals. These solutions minimize consensus overhead and on-chain data footprint but provide only moderate cryptographic protection. The second regime corresponds to high-security configurations, where a large fraction of data and transactions are anchored or executed on-chain, and replication is maximized. These designs exhibit significantly higher latency and operational cost, reflecting the inherent overhead of consensus-backed storage and execution. Between these extremes lies a balanced hybrid regime, which combines on-chain hash anchoring for critical data with IPFS or cloud storage for large payloads, together with moderate replication and optimized block parameters [14,20]. These solutions achieve a near-optimal compromise between efficiency and integrity and represent the most practically relevant design space for real deployments [42]. This structure confirms that the hybrid storage problem is fundamentally multi-modal: different application domains require different points along the Pareto front rather than a single universal configuration [15,29]. These dominant architectural regimes and their corresponding design characteristics are summarized in

Table 8. Architectural design regimes extracted from the Pareto-optimal hybrid storage solutions.

Regime	Data Placement Pattern	Blockchain Parameters	Latency–Cost Profile	Security Level	Typical Application Domains
Low-Cost Regime	Predominantly cloud storage with minimal on-chain hash anchoring	Large block size, long block interval, low replication (R = 1)	Very low latency, very low cost	Low to medium	IoT telemetry, archival systems, low-regulation environments
Balanced Hybrid Regime	IPFS and cloud storage with on-chain hash anchoring for critical data	Medium block size, moderate block interval, moderate replication (R = 2)	Moderate latency, moderate cost	High	Supply chains, logistics, industrial platforms
High-Security Regime	Critical data on-chain, remaining data on IPFS with hash anchoring	Small block size, short block interval, high replication (R = 3)	High latency, high cost	Very high	Healthcare, disaster response, legal and regulatory systems

.

Table 8 translates the abstract Pareto-optimal solutions into concrete architectural design regimes that are directly interpretable by system architects. Rather than listing individual chromosomes or numerical trade-offs, the table groups Pareto-optimal configurations into three dominant patterns that correspond to real-world deployment strategies. The low-cost regime is dominated by cloud-centric designs that prioritize throughput and minimal operational expenditure but offer limited cryptographic guarantees. The high-security regime, in contrast, is driven by consensus-backed storage and aggressive replication, which ensures maximum integrity and availability at the expense of performance. The balanced hybrid regime represents the most practically valuable region of the Pareto front, where cryptographic anchoring and moderate replication provide strong data integrity while IPFS and cloud storage absorb the bulk data volume. This regime aligns closely with the requirements of most enterprise and governmental blockchain deployments.

From a software-architecture perspective, these three dominant regimes can be treated as reusable hybrid-storage design patterns, each capturing a recurring structural solution under different latency–cost–security priorities: (i) the Cloud-Centric Off-Chain Pattern, which routes bulk payloads to cloud storage and favors off-chain execution while keeping only lightweight integrity anchors on-chain; (ii) the Hash-Anchored Hybrid Pattern, which stores large payloads in IPFS and/or cloud while enforcing integrity for critical classes through systematic on-chain hash anchoring and mixed execution; and (iii) the On-Chain Critical Pattern, which maximizes integrity and availability by keeping the most critical data and/or transactions on-chain with stronger replication at the expense of latency and operational cost. This interpretation formalizes the link between Pareto-optimal regions and concrete architectural templates, thereby establishing a systematic mapping between Pareto-dominant regions and concrete architectural templates.

The relationship between the Pareto-optimal solution space and the resulting architectural design regimes is visually summarized in Figure 7.

The Pareto front is interpreted as three dominant hybrid blockchain design regimes: a low-cost cloud-dominant region, a balanced hybrid region based on IPFS with on-chain hash anchoring, and a high-security region characterized by on-chain storage and higher replication. The figure provides a conceptual mapping from optimization results to system-level architectural strategies. Unlike the Pareto scatter plots reported in the Results section, Figure 7 does not display individual solutions but illustrates qualitative architectural operating regions across the cost–latency–security trade-off space.

6.2. Comparison with IPFS-Only and Cloud-Only Architectures

The comparison with IPFS-only and cloud-only baselines highlights why hybrid optimization is essential. Cloud-only configurations consistently achieve low cost and low latency, but their security scores remain low because they rely on a single administrative domain and lack decentralized replication and cryptographic anchoring [18,19]. IPFS-only configurations improve resilience and integrity but incur higher latency and storage overhead due to replication and content-addressed retrieval [16,17,33]. The Pareto-optimal solutions generated by the proposed framework dominate these baselines by selectively combining their strengths. Instead of committing to a single storage technology, the optimizer allocates critical data to on-chain or hash-anchored IPFS storage while routing large, less sensitive payloads to cloud infrastructure [14,20,21,43]. This selective anchoring mechanism allows hybrid solutions to achieve security levels comparable to IPFS-based systems while retaining the performance and cost advantages of cloud storage. The resulting trade-off curve is therefore substantially broader and more favorable than that of any single-technology architecture.

6.3. Data Availability, Integrity, and Replication Trade-Off

A key insight revealed by the Pareto front is that data availability and integrity scale differently across storage layers. On-chain storage provides the strongest integrity guarantees but is expensive and slow. IPFS provides decentralized availability and tamper detection but incurs replication and retrieval overhead. Cloud storage provides low-latency and elastic capacity but depends on trust in the provider. The optimized solutions show that cryptographic anchoring is more important than physical data location for preserving integrity [14,20]. This observation is consistent with recent adaptive on-chain/off-chain architectures, where integrity and regulatory compliance are enforced through cryptographic binding rather than strict data locality [44]. By storing hashes on-chain, off-chain data can be verified with the same cryptographic strength as native blockchain records. Replication, represented by the replication factor, plays a complementary role by protecting against data loss and unavailability [11,28]. The security objective therefore increases not because data is fully on-chain, but because hash coverage and replication jointly ensure that off-chain data remains verifiable and recoverable. This explains why many Pareto-optimal configurations allocate only a small fraction of total data volume to on-chain storage while still achieving high security scores.

6.4. Implications for Permissioned Blockchain Design

For enterprise and governmental permissioned blockchains, the results imply that hybrid architectures should be treated as tunable systems rather than fixed design choices. Application designers should not decide storage placement in isolation, but must co-design it with transaction execution strategies and blockchain parameters such as block size, block interval, and replication factor [9,13]. For example, healthcare and disaster-response systems, which prioritize integrity and availability, should operate in the high-security or balanced regions of the Pareto front, where critical records are hash-anchored or stored on-chain and replication is high [3,4,5,6]. This observation is consistent with recent blockchain-based disaster-relief architectures, where hybrid on-chain anchoring combined with off-chain storage has been shown to improve transparency, auditability, and operational scalability under real-world emergency constraints [45]. In contrast, large-scale IoT or supply-chain platforms that process massive volumes of telemetry data can operate closer to the low-cost regime while still maintaining integrity through on-chain hash commitments. The proposed framework provides a systematic tool for identifying these operating points rather than relying on ad hoc architectural decisions. This perspective implies that hybrid blockchain platforms should expose storage placement, execution mode, and replication level as configurable policy parameters rather than hard-coded architectural decisions. By aligning system configuration with application-specific regulatory, performance, and cost constraints, the Pareto front becomes a practical design map rather than a purely analytical artifact.

Table 9. Practical deployment guideline derived from the Pareto-optimal design regimes.

Constraint/Priority	Recommended Regime	Storage Policy	Replication (R)	Block İnterval (T)	Notes
Strict compliance, auditability	High-security	Critical on-chain+hash-anchored IPFS	High (3)	Short (0.5–1 s)	Prefer on-chain exec for critical tx
Balanced ops cost+integrity	Balanced hybrid	Hash anchoring + IPFS/cloud split	Medium (2)	Medium (1 s)	Default enterprise setting
Minimum cost, archival/telemetry	Low-cost	Cloud-dominant + minimal anchoring	Low (1)	Longer (2 s)	Use anchoring for spot checks
Low latency interactive workloads	Balanced/Low-cost	Cloud for bulk + on-chain hashes	1–2	Short (0.5–1 s)	Tune block size upward
High availability under disruptions	High-security/Balanced	IPFS replicated + anchoring	2–3	Medium	Prioritize resilience over cost

summarizes a practical selection checklist that maps common enterprise constraints to the most suitable Pareto regime and recommended configuration directions.

Table 9 operationalizes the Pareto insights into a practitioner-facing decision guide. Rather than prescribing a single ‘best’ design, it provides configuration directions aligned with compliance, cost, and latency constraints. This mapping is consistent with the architectural regime interpretation presented in Table 8 and Figure 7, while emphasizing actionable deployment choices.

The architectural regimes summarized in Table 8, together with the practical deployment guidelines provided in Table 9, yield direct implications for the engineering design of blockchain-based systems. Beyond descriptive classification, these regimes inform how storage configuration, execution placement, replication intensity, and anchoring strategies should be selected in alignment with application requirements. Specifically, the low-cost regime is most appropriate for large-scale, data-intensive applications where throughput and storage efficiency dominate strict integrity guarantees, such as IoT logging infrastructures, archival platforms, or analytics-oriented systems. In these contexts, prioritizing off-chain storage with lightweight on-chain anchoring enables economic scalability. The high-security regime is suited for compliance-driven and mission-critical systems, including governmental registries, financial auditing infrastructures, and healthcare data platforms. Here, stronger on-chain execution and consensus-backed replication mechanisms enhance tamper resistance and integrity assurance, albeit at higher latency and operational cost. The balanced hybrid regime provides a pragmatic architectural alternative for enterprise deployments where cost, performance, and regulatory compliance must be co-optimized. By combining selective on-chain commitment with IPFS or cloud-based bulk storage, this regime supports robust yet scalable system configurations. Accordingly, the proposed framework does not prescribe a single architectural template; rather, it enables context-aware regime selection grounded in application priorities and policy-defined objective weighting.

6.5. Limitations and Practical Implications

The digital-twin-based evaluation framework abstracts away hardware-specific effects, network congestion, and low-level protocol details [12]. As a result, the absolute values of latency and cost should not be interpreted as deployment-ready benchmarks. However, the framework is designed to preserve relative trade-offs between architectural choices, which is the key requirement for Pareto-based design exploration. Although NSGA-II is adopted here due to its robustness, low implementation overhead, and strong baseline performance for three-objective problems, alternative Pareto-based and indicator-driven evolutionary optimization strategies can be explored as future work to further assess the generality of the observed trade-offs [29,30]. A systematic benchmark over such alternatives on a physical Fabric–IPFS–cloud testbed will further validate the consistency of the obtained design insights. Accordingly, the security dimension in this study captures integrity, tamper-evidence, and resilience rather than end-to-end data confidentiality, which is assumed to be enforced by external access control and encryption mechanisms in permissioned deployments [8,36]. Future work will explicitly integrate key management, encryption, and recovery strategies, such as KMS-backed escrow or threshold key sharing, to analyze their impact on availability and compliance. From a practical perspective, the Pareto-optimal configurations identified by the optimizer can serve as candidate architectures for real deployments [46,47]. System designers may select configurations aligned with their regulatory, performance, and budget constraints and subsequently refine them through empirical benchmarking on physical testbeds. In this sense, the proposed framework functions as a decision-support layer that significantly reduces the design space prior to costly deployment experiments.

7. Conclusions

This study presented a data-availability-aware hybrid storage optimization framework for permissioned blockchain systems. The proposed approach jointly optimizes data placement, transaction execution strategies, and blockchain network parameters under conflicting objectives of latency, cost, and security. By encoding these design decisions within a unified decision vector and evaluating them through a digital-twin-based performance model, the framework enables a systematic and reproducible exploration of the hybrid blockchain design space. The NSGA-II-based multi-objective optimization results reveal that neither fully on-chain nor purely off-chain storage architectures are optimal across all operational scenarios. Instead, the Pareto analysis demonstrates that hybrid configurations, particularly those combining on-chain hash anchoring for critical data with IPFS or cloud storage for bulk payloads, consistently provide superior trade-offs. These configurations achieve strong integrity and resilience while significantly reducing latency and operational cost. The findings further indicate that cryptographic anchoring and replication strategies are more influential for secure data availability than raw on-chain storage volume, highlighting the architectural importance of selective anchoring rather than exhaustive on-chain persistence. From a practical standpoint, the proposed framework serves as an architectural decision-support tool for enterprise and governmental permissioned blockchain deployments. Rather than prescribing a single optimal configuration, the Pareto front exposes a spectrum of viable operating regimes that allow system designers to align blockchain configurations with application-specific priorities, such as regulatory compliance, data sensitivity, performance constraints, and budget limitations. In this sense, the framework helps bridge the gap between abstract optimization results and actionable system-level design decisions. Future work will extend this study in several directions. First, the proposed digital-twin-based evaluation will be complemented with physical blockchain testbeds to validate the observed trade-offs under real network and hardware conditions. Second, additional optimization dimensions, including energy consumption, dynamic workload patterns, and adaptive reconfiguration policies, will be incorporated to further enrich the design space. Third, alternative Pareto-based and indicator-driven multi-objective optimization techniques will be explored to assess their effectiveness in capturing more complex trade-off surfaces. Finally, tighter integration of key management, encryption, and recovery mechanisms into the optimization framework will enable a more comprehensive analysis of confidentiality, availability, and compliance in real-world permissioned blockchain deployments. Beyond the specific scenarios evaluated, the proposed framework provides a transferable decision-support methodology for a broad class of data-intensive permissioned blockchain systems.