PaB-PIF: A Hybrid Architecture to Evaluate Mutable and Immutable Blockchains in IoT–Fog Networks

Abstract

Blockchain provides secure and decentralized data storage. Normal blockchains permanently store data. Mutable blockchains allow users to change data, but this reduces tamper resistance. This paper tests both methods in PaB-PIF, a hybrid architecture for IoT-Fog networks. Our design uses an immutable mainchain in the cloud layer and mutable sidechains in the fog layer. We analyze throughput, latency, and tamper resistance using math models and simulations. Results show that blockchain greatly improves network security. Without blockchain, the network has zero tamper resistance. The mutable blockchain in the fog layer has a tamper resistance of 0.58. The immutable blockchain in the cloud layer reaches 0.99. However, this extra security increases latency and reduces throughput. The mutable blockchain has lower latency, so it is a good fit for the fog layer. The immutable blockchain provides maximum security, which is best for the cloud layer. This trade-off works well for IoT systems like the Internet of Vehicles, where data integrity and legal rules are essential. We also compare PaB-PIF with an IoT-Fog network that has no blockchain.

1. Introduction

Blockchain technology is a widely recognized approach for secure, transparent, and decentralized data management in various scenarios, such as the Internet of Things (IoT). It is a distributed ledger that keeps transactions in a chain of blocks, where each block is cryptographically linked to its predecessor to provide tamper resistance and data integrity. This technology removes the need for central middlemen, which increases trust and transparency among users. Blockchain can be different based on how they reach agreement (consensus), how they store data, and what they are used for. They are used in many real-life areas, like healthcare and supply chain management. By using cryptography and decentralized consensus, blockchain increases reliability and security. It protects data from unauthorized changes and reduces the risk of a single point of failure [1]. In a fog-enabled design, nearby fog devices process data close to where it is created. This can improve blockchain performance by lowering delay, saving bandwidth, and sharing the workload. It can improve scalability, lower energy consumption, and efficiently support mutable data management in IoT-Fog environments [2].

On the one hand, immutability is the main feature of a blockchain to avoid cheating and tampering, and it guarantees that data cannot be altered [3]. In the literature, the security-aware IoT architectures employ blockchain for immutability features to avoid malicious modifications by attackers. On the other hand, some applications need modification. Immutability keeps the data safe from changes, so blockchain is good for situations that need clear records and protection against tampering [4], but IoT and fog often need to change or delete data to work better, follow rules, or save storage space.

This need has created hybrid blockchain designs. They keep important records unchanged (immutable), but allow some records to be changed (mutable). We can use redaction methods to make controlled edits while still keeping trust and data integrity. Sidechains and redaction tools let us change some data without hurting the main blockchain [5]. Also, cryptographic methods like chameleon hashing and fog-layer sidechains help update data safely and efficiently without breaking the blockchain’s structure.

Fog plays a crucial role in IoT security defence mechanisms. Fog-localized data processing helps detect real-time threats, such as DDoS attacks and makes employing Intrusion Detection Systems (IDSs) easier. blockchain technology helps stop data tampering because it cannot be easily changed, but it does not protect against all cyber threats, like Distributed Denial-of-Service (DDoS) attacks. By combining fog computing with blockchain, we can improve the security of IoT networks. It works because blockchain is decentralized and tamper-proof. Still, blockchain has some problems, such as high cost, slow speed, and too much processing work. To fix these problems, we suggest a hybrid method. In this method, we use fog computing and add changeable (mutable) blockchains at the fog layer [6].

The tension between blockchain and privacy has been analyzed by many authors, and the reader may find a good introduction and analysis in [7]. An example of application in which privacy is crucial, data have to be collected at high rates and by means of a fog computing infrastructure and blockchain is chosen because of its non-repudiability and intrinsically shared nature is provided in [8]. Such a choice must be supported by means of a risk assessment aware decision framework since the earliest phases of the design cycle in order to comply to GDPR privacy-by-default and privacy-by-design principles, which impact on performances. This should be kept into account in a systematic way together with blockchain-related considerations when exploring blockchain use in complex architectures involving GDPR-related data. It gives more flexibility and follows rules like GDPR when dealing with non-sensitive user data [9]. We use an immutable blockchain in the cloud layer to keep crucial user information unaltered. The pros of this architecture are that it makes the IoT more secure in terms of tamper resistance.

In IoT-Fog networks, we should think about security, privacy, and resource efficiency at the same time: security stops attacks; privacy keeps user data safe; resource efficiency helps to use less energy and makes the responses faster. Blockchain can help with security and privacy because it saves data in a safe and locked way, but it can use a lot of energy if we do not manage it well. If we use blockchain together with fog computing, we can build frameworks that work near the devices, protect data, and use less energy. This is very useful for things like smart cities and healthcare, where speed and safety are very important [10].

Recently, a mutable blockchain has been proposed in academic areas for controlled modifications and maintaining security. In our previous work [11], we analysed the challenges of mutable blockchains in IoT-driven sustainable urban planning using analytical modelling. The need to modify data in daily life appliances is always a challenge when using blockchain. It motivated us to design an architecture that integrates mutable and immutable blockchains to consider flexibility and security. Using both types, we can compare their pros and cons with a fog-based IoT paradigm that does not use blockchain. To this end, we conducted simulations and analytical modelling to evaluate performance in key metrics such as latency, throughput, and tamper resistance. We aim to explain the good and bad points of employing mutable and immutable blockchains in IoT scenarios. Although traditional databases or off-chain storage provide data mutability with lower costs, they lack key blockchain benefits such as decentralization, resistance to manipulation, and cryptographic auditability. Mutable blockchain, on the other hand, provides security, decentralization and controlled modifications. They make changes verifiable and do not compromise the integrity of critical data.

Most current architectures use only one immutable blockchain, a single mutable chain, or a central off-chain database. What makes our system different is how we combine two types of blockchain in different layers. We place a mutable sidechain in the fog layer so users can update data quickly, and an immutable mainchain in the cloud layer to keep core records safe. This design allows fast local edits without losing the overall security of the IoT-Fog network.

Our contributions are as follows:

• We present a blockchain architecture for IoT that employs fog computing for mutable data in the fog layer and immutable ones in the cloud layer.
• We employ SHA-256 and chameleon methods as well-known approaches for immutable and mutable blockchains.
• We conduct analytical modelling and implementation to indicate the pros and cons of employing blockchain in the IoT architecture.
• We implement two state-of-the-art baselines, a single mutable chain and a hybrid off-chain design, and we compare them with PaB-PIF under the same simulation setup and the same parameters.

We organize the rest of the paper in five sections. Section 2 reviews related work in this field. Section 3 explains our system design and how data moves through it. In Section 4, we show our math models for latency, throughput, and tamper resistance. Section 5 describes our tests, setup, and results. Lastly, Section 6 sums up our findings and suggests ideas for future research.

2. Related Works

Many blockchain architectures manage data in IoT environments. We selected the following papers based on data mutability, security mechanisms, and integration with fog or cloud computing. To make their advantages and limits clear, we group these works into three main categories: mutable designs, immutable designs, and hybrid approaches.

Fully and Partially Mutable Blockchains. Tulkinbekov and Kim [12] proposed an edge computing framework that allows data deletion. However, allowing on-demand deletions increases the risk of tampering. Kottursamy et al. [13] introduced mutable blocks with immutable transactions. The transactions remain safe, but updating the block structure creates delays and introduces security risks, such as trapdoor key attacks.

Immutable Blockchains for IoT. Immutability is the most common way to secure data. Latif et al. [14] and Rahman et al. [15] combined immutable blockchains with Software-Defined Networking (SDN) to protect IoT communications. These designs are highly secure but have high latency and processing overhead. Gomez et al. [16] proposed S-HIDRA, which uses smart contracts to manage fog nodes safely. Hewa et al. [17] used blockchain and IPFS to manage device identities in 5G networks. These immutable solutions provide excellent security, but they cannot modify or delete data easily.

Hybrid and Off-Chain Architectures. Some designs use off-chain storage to balance flexibility and speed. Can et al. [18] proposed a consent management system. It stores Merkle roots on-chain but keeps the actual data in a central off-chain database. This improves processing speed, but the central database becomes a single point of failure.

Unlike these works, PaB-PIF introduces a decentralized hybrid system. It avoids single points of failure by using a mutable sidechain in the fog layer for rapid updates and an immutable mainchain in the cloud layer for critical data.

Table 1. Qualitative design comparison of related works with the proposed architecture.

Work	Mutability Support	Security	Scalability	Performance
Tulkinbekov & Kim [12]	Fully Mutable	Medium (On-demand deletions have risks)	Low (Risk of Sybil attacks)	Moderate (Deletion may impact efficiency)
Kottursamy et al. [13]	Partially Mutable (Mutable blocks, immutable transactions)	Medium (Vulnerable to trapdoor key attacks)	Moderate (Scalability affected by block structure updates)	Moderate (Block update process adds overhead)
Latif et al. [14]	Immutable	High (Secure authentication, blockchain integration)	High (SDN-based clustering enhances scalability)	Moderate (Energy consumption optimized, but PoW increases latency)
Gomez et al. [16]	Immutable	High (Smart contracts ensure secure orchestration)	High (Domain-based model enables distributed coordination)	Moderate (Network orchestration improves performance but adds complexity)
Can et al. [18]	Partially Mutable (Hybrid on-chain and off-chain)	Medium (Off-chain database creates a single point of failure)	High (Off-chain reduces blockchain overhead)	High (Efficient data processing via off-chain storage)
Hewa et al. [17]	Immutable	High (Zero-knowledge proofs for anonymity)	High (IPFS-based storage improves scalability)	Moderate (Extended storage system adds overhead)
Rahman et al. [15]	Immutable	High (Blockchain-secured flow-rule verification)	Moderate (Layered SDN design)	Moderate (Latency due to flow-rule validation)
PaB-PIF	Hybrid (Mutable Sidechain + Immutable Mainchain)	High (Tamper-proof storage with chameleon hashing)	High (Fog-Cloud layered approach)	High (Optimized for IoT-Fog networks, reduced overhead in Fog layer)

presents a qualitative comparison of these designs.

In Table 1, we use the labels “High,” “Moderate,” and “Low” to evaluate each architecture. For Mutability Support, “High” means full support, while “Moderate” means partial or off-chain support. For Security, “High” means strong protection against tampering, and “Medium” means there are risks like single points of failure. Scalability is “High” if the network can grow easily, and “Low” or “Moderate” if heavy consensus rules limit growth. Finally, Performance is “High” for fast systems and “Moderate” when processing delays slow down the network. For a measured and fair comparison, we evaluate the immutable and the mutable paradigms used by these works under one common simulator in Section 5.

3. Methodology

This section gives an account of the reference mutable and immutable blockchain architecture.

3.1. Problem Statement

Let B represent a blockchain architecture where each block $B_i$ is cryptographically linked. The hash function can be defined as

$$H\left(B_i\right)=H(D_i,H\left(B_{i-1}\right))$$

(1)

where $D_i$ represents data in the block, and $H\left(B_{i-1}\right)$ is the hash of the previous block.

Immutable blockchains have high resistance to tampering, as changing any block requires recomputing all subsequent hashes, making modification computationally infeasible. We can quantify it as

$$T{R}_{\mathrm{immutable}}\approx 1-{\displaystyle \frac{1}{2^{256}}}$$

(2)

The chance of changing a block successfully is very low because cryptographic hash functions protect the data strongly. However, IoT-Fog networks need to allow some controlled changes (mutability) to stay flexible during operation. Chameleon hashing makes it possible to change data in a controlled way using a secret key (called a trapdoor). It keeps the data safe and only lets approved users make changes. We can measure this with the following formula:

$$CH\left(B_i\right)=CH(D_i,CH\left(B_{i-1}\right))$$

(3)

In the equation, $CH$ denotes a chameleon hash function that efficiently updates when the correct trapdoor information is present. Accordingly, incorporating chameleon hashing reduces tamper resistance compared to immutable blockchains. The tamper resistance of mutable blockchains is defined as the following equation where the reduction in tamper resistance arises due to the controlled mutability feature of chameleon hashing:

$$T{R}_{\mathrm{mutable}}\approx 1-{\displaystyle \frac{1}{2^{128}}}$$

(4)

The values 256 and 128 in the tamper resistance equations correspond to the security levels of the cryptographic hash functions used in these approaches. The value $2^{256}$ represents the approximate number of possible outputs of a 256-bit cryptographic hash function, such as SHA-256. It has a high level of security, which makes tampering almost impossible. In contrast, $2^{128}$ corresponds to the security level of a chameleon hash function, which operates with a 128-bit collision resistance for its trapdoor mechanism.

Latency (L) and throughput (T) are critical performance metrics. Latency is the incremental delay by transaction validation, block creation, and consensus mechanisms, formulated as:

$$L=T_{\mathrm{validation}}+T_{\mathrm{block} \mathrm{creation}}+T_{\mathrm{consensus}}.$$

(5)

Throughput (T) is defined as the number of transactions successfully processed per unit of latency, given by:

$$T={\displaystyle \frac{N_{\mathrm{transactions}}}{L}}.$$

(6)

This equation indicates that increasing latency negatively impacts throughput, as longer transaction validation and consensus times reduce the number of processed transactions.

Objective: Evaluate the mutable and Immutable blockchain performance regarding latency, throughput, and tamper resistance and discuss the pros and cons.

3.2. Fog-Enabled Blockchain Architecture

The reference IoT-Fog-enabled blockchain architecture employs a cloud–fog–device structure consisting of three layers. The front-end layer (device layer) consists of user devices (such as smartphones, drones, vehicles, etc.). They run user applications and may send requests (Transactions) to the fog gateway. The IoT-Fog region has a fog gateway located at the edge of the access network inside the IoT-Fog region, which is responsible for receiving tasks and coordinating the IoT devices inside its own region. The fog gateway receives and processes users’ requests. All fog gateway nodes send tasks to a sidechain blockchain network with several miners. Finally, the cloud layer, which consists of a cloud gateway, provides virtually unlimited resources for data storage offloaded from the fog gateway. Each fog gateway creates and sends tasks to the cloud gateway and receives all tasks. Cloud gateway nodes send tasks to the mainchain blockchain network with several miners.

PaB-PIF uses a blockchain consisting of a mainchain and a sidechain. It stores a database copy in each fog gateway. Each fog gateway is a blockchain node (i.e., Each fog gateway is a mainchain node and sidechain node). In the sidechain, each IoT device sends transactions to its fog gateway, and the fog gateways sends all transactions in its region to the shared blockchain layer among all fog gateways. The fog gateway stores each transaction as a record inside the sidechain block. For each new transaction, the fog gateway adds it to a new block, computes the previous block’s hash, and links them accordingly. It will be published in all sidechain nodes. In the PaB-PIF architecture, the fog gateway has the most powerful computational capacity within the IoT Fog region. Each fog gateway has a certain number of miners.

Each cloud gateway has its fog gateways in its sub-cluster, and each fog gateway creates and sends transactions to its cloud gateways. For the mainchain, the Cloud gateways store each transaction as a record. For each new transaction, the Cloud gateway collects the data, aggregates it into a block, computes the previous block’s hash, and stores the new block with the transaction and the hash reference at the end of the chain. It saves the new record inside all the Fog gateways. In the mainchain, each fog gateway sends its transaction to the cloud gateway, which sends all transactions in its region to the shared blockchain layer among all cloud gateways.

We implement sidechain in the IoT-Fog gateways layers. It includes sidechain blocks and sidechain smart contracts. In our architecture, both sidechains and mainchains are secure, tamper-proof ledgers that store critical data. Only pre-authorized IoT devices have access to change data in sidechain. The data in the mainchain are immutable, whereas the data in the sidechain are mutable. A sidechain is a second blockchain that is linked to the mainchain; it can use a different consensus method and can process transactions faster or slower than the mainchain. In our design, the sidechain handles requests to delete or modify data. Smart contracts are self-executing programs that run on both the mainchain and the sidechain. They run automatically when the set conditions are met. The sidechain adds extra data to the mainchain but does not copy it. The mainchain keeps the important, immutable core data, such as user identities and other critical records. The sidechain stores the mutable user data that may need updates or deletions. Figure 1 depicts the PaB-PIF architecture.

To explain our architecture clearly, we adopt the 1 + 5 Architectural Views Model [19]. Figure 1 shows the Deployment View of our system, displaying the physical devices, fog gateways, cloud servers, and their network connections. This mapping connects the physical nodes in Figure 1 with their internal software functions. When we map this to the Logical View, each node runs specific software modules:

• Device Layer: IoT nodes run sensor data modules and lightweight authentication clients to sign requests.
• Fog Layer: Fog gateways act as sidechain nodes. They run API gateways, access control managers, chameleon hashing modules, and local smart contracts to process fast data edits and local consensus.
• Cloud Layer: Cloud gateways run cloud aggregators, SHA-256 hashing modules, and mainchain smart contracts to permanently store immutable records.

3.3. Data Flow in the PaB-PIF Architecture

The sensors generate the data (transactions) in the device layer and send it to the fog gateway inside the fog region. The fog gateways send data to the sidechain blockchain. The fog gateways generate the data (transactions) in the fog layer and send it to the cloud gateways inside the Cloud region. Finally, fog gateways send all data to the mainchain blockchain. The Cloud Gateway submits critical and immutable data to the mainchain blockchain on fog gateways. Smart contracts on the mainchain (cloud gateway) validate and store the data permanently. For modifying the data, the sidechain starts the responsibility for data control as follows: Fog gateways check user credentials to modify or delete transactions and requests to the sidechain smart contract. Sidechain smart contracts (in the fog gateways) handle the deletion or modification of data on the sidechain. mainchain smart contract check the authorization of users to change or delete transactions, keeping a record of the change. It marks the data point as deleted or modified entirely from the sidechain ledger. It creates a record of the deletion or modification event with relevant details and sends modified or deleted tasks in the sidechain to the mainchain as new tasks. Figure 2 indicates the sequence diagram.

4. Analytical Modeling

In this section, we analytically model the behavior of the blockchain to help other researchers understand the pros and cons of using blockchains in IoT scenarios.

4.1. Tamper Resistance

Tamper resistance ($TR$) quantifies blockchain resistance to unauthorized modifications. It depends on cryptographic hashing dependencies (H), consensus mechanisms (C), and the probability of a successful attack (P).

4.1.1. Immutable Blockchain (SHA-256)

Each block $B_i$ contains $H_i=H(D_i,H_{i-1})$ and each block depends on all previous blocks. Modifying a single block requires recomputing hashes for all subsequent blocks, making tampering infeasible. The probability of a successful attack is defined by the following Equation (7)

$$P_{\mathrm{immutable}}={\left({\displaystyle \frac{1}{2^{256}}}\right)}^n$$

(7)

where n is the number of blocks. Since $P_{\mathrm{immutable}}\approx {10}^{-77n}$, we define tamper resistance by Equation (8).

$$T{R}_{\mathrm{immutable}}=1-P_{\mathrm{immutable}}\approx 0.99$$

(8)

In Equation (8), we initially approximated $T{R}_{\mathrm{immutable}}$ as $0.99$. However, since $P_{\mathrm{immutable}}$ is extremely small (${10}^{-77n}$), the tamper resistance is much closer to $1.0$:

$$T{R}_{\mathrm{immutable}}=1.0-P_{\mathrm{immutable}}\approx 1.0$$

(9)

4.1.2. Mutable Blockchain (Chameleon Hash)

Each block links to the previous block using chameleon hashes $C{H}_i=CH(D_i,C{H}_{i-1})$. Tampering requires modifying only one adjacent block, leading to a higher probability of attack as in Equation (10)

$$P_{\mathrm{mutable}}={\displaystyle \frac{1}{2^{128}}}$$

(10)

As a result, the tamper resistance will be

$$T{R}_{\mathrm{mutable}}=1-P_{\mathrm{mutable}}\approx 0.58$$

(11)

4.1.3. Tamper Resistance Formula

Equation (12) shows how to calculate tamper resistance. In this equation, k is the cryptographic security level (256 for SHA-256, 128 for chameleon hashing), and d is the number of dependent blocks:

$$TR=1-{\displaystyle \frac{1}{2^{k·d}}}$$

(12)

This latter formula is derived from the probability of a successful tampering attempt. In a blockchain, altering a block requires modifying its cryptographic hash and, depending on the blockchain type, possibly modifying subsequent blocks. The probability of successfully tampering with a single block is approximately ${\displaystyle \frac{1}{2^k}}$, where k represents the hash security level. If d blocks must be modified for a successful attack, the total probability of success $P_{\mathrm{tamper}}$ will be

$$P_{\mathrm{tamper}}={\left({\displaystyle \frac{1}{2^k}}\right)}^d={\displaystyle \frac{1}{2^{k·d}}}$$

(13)

Since tamper resistance is the complement of this probability, we can obtain it by Equation (14).

$$TR=1-P_{\mathrm{tamper}}=1-{\displaystyle \frac{1}{2^{k·d}}}$$

(14)

For immutable blockchains, all previous blocks depend on a single change, making $d=n$, which results in an extremely low probability of successful tampering, yielding $TR\approx 0.99$. In contrast, for mutable blockchains, only one adjacent block is affected ($d=1$), leading to a higher probability of tampering success and a lower tamper resistance of approximately $TR\approx 0.58$.

4.2. Latency

Latency (L) is the time from when a transaction starts to when it is finalized. It depends on many steps: transaction checks, block creation, and the consensus process. Blocks group many transactions together instead of processing them one by one. Consensus also adds delay because nodes must agree before a block is considered valid. Different algorithms (e.g., PoW, PoS, BFT) take different times to reach agreement, so total latency changes. In a blockchain-enabled IoT–fog network, we model latency with three main parts.

• $T_{validation}$: Time required for verifying transaction authenticity.
• $T_{block}$: Time for transaction inclusion in a block.
• $T_{consensus}$: Time required for achieving consensus among nodes.

Accordingly, the total latency L can be expressed as follows:

$$L=T_{validation}+T_{block}+T_{consensus}$$

(15)

Blockchain latency depends on how mutable the design is. In an immutable blockchain, each transaction needs strong checks with cryptographic hashes (like SHA-256) and network-wide consensus, increasing latency. In mutable blockchain, that uses chameleon hashes, the hashing work and consensus steps can be lighter, reducing the overall latency.

For an immutable blockchain, the validation time depends on the hashing time ($t_{\mathrm{hash}}$) and the network verification delay across all nodes ($N_{\mathrm{nodes}}$):

$$T_{\mathrm{validation}}^{\mathrm{immutable}}=t_{\mathrm{hash}}+N_{\mathrm{nodes}}·t_{\mathrm{comm}}$$

(16)

where $t_{\mathrm{hash}}$ is the SHA-256 calculation time and $t_{\mathrm{comm}}$ is the network delay for each node.

For a mutable blockchain on the Fog sidechain, the validation time is defined as:

$$T_{\mathrm{validation}}^{\mathrm{mutable}}=t_{\mathrm{chameleon}}+T_{\mathrm{consensus}}\left(N_{\mathrm{sidechain}}\right)$$

(17)

where $t_{\mathrm{chameleon}}$ is the execution time of the chameleon hash, and $T_{\mathrm{consensus}}\left(N_{\mathrm{sidechain}}\right)$ is the consensus and network delay for $N_{\mathrm{sidechain}}$ Fog nodes.

Because the sidechain uses much fewer nodes than the mainchain ($N_{\mathrm{sidechain}}\ll N_{\mathrm{nodes}}$), the network delay is lower, which gives:

$$T_{\mathrm{validation}}^{\mathrm{mutable}}<T_{\mathrm{validation}}^{\mathrm{immutable}}$$

(18)

4.2.1. Block Creation Time

Block creation latency is influenced by transaction batching and block generation intervals. Given a block size of B transactions, the time taken to form a complete block depends on the transaction arrival rate. We can quantify it as the following equation in which $T_{\mathrm{transaction}}$ represents the average inter-arrival time between consecutive transactions:

$$T_{\mathrm{block}}=B·T_{\mathrm{transaction}}$$

(19)

4.2.2. Consensus Time

Consensus mechanisms have significant delays due to miner competition and block propagation. For a PoW-based blockchain, the time required to mine a new block depends on the mining difficulty D and the computational power of a miner $H_{\mathrm{miner}}$. The mining difficulty D represents the required mean number of hash attempts to successfully mine a block, while $H_{\mathrm{miner}}$ denotes the hash rate (i.e., the number of hash computations per second) of an individual miner. The expected time for a single miner to find a valid block can be estimated as:

$$T_{\mathrm{consensus}}^{\mathrm{PoW}}={\displaystyle \frac{D}{H_{\mathrm{miner}}}}$$

(20)

In a distributed network, the block discovery time is determined by the total network hash rate $H_{\mathrm{network}}$, which is indicated as the following equation:

$$T_{\mathrm{consensus}}^{\mathrm{PoW}}={\displaystyle \frac{D}{H_{\mathrm{network}}}}$$

(21)

where $H_{\mathrm{network}}$ is the combined hashing power of all participating miners.

For a mutable blockchain using chameleon hashing, consensus occurs locally within the sidechain, reducing delay:

$$T_{consensus}^{mutable}=O\left(N_{sidechain}\right)$$

(22)

Since $N_{sidechain}\ll N_{mainchain}$, we obtain:

$$T_{consensus}^{mutable}<T_{consensus}^{immutable}$$

(23)

4.2.3. Total Latency Comparison

By substituting the respective latency components into Equation (15), we compare the total latency for immutable and mutable blockchains.

For the immutable blockchain, the total latency ($L^{\mathrm{immutable}}$) is:

$$L^{\mathrm{immutable}}=t_{\mathrm{hash}}+T_{\mathrm{consensus}}\left(N_{\mathrm{nodes}}\right)+{\displaystyle \frac{B}{R_{\mathrm{bandwidth}}}}+{\displaystyle \frac{D}{H_{\mathrm{miner}}}}$$

(24)

For the mutable blockchain, the total latency ($L^{\mathrm{mutable}}$) is:

$$L^{\mathrm{mutable}}=t_{\mathrm{chameleon}}+T_{\mathrm{consensus}}\left(N_{\mathrm{sidechain}}\right)+{\displaystyle \frac{B}{R_{\mathrm{bandwidth}}}}$$

(25)

To compare the two architectures, we calculate the latency difference:

$$\begin{array}{cc}\hfill L^{\mathrm{mutable}}-L^{\mathrm{immutable}}& =(t_{\mathrm{chameleon}}-t_{\mathrm{hash}})\hfill \\ \hfill & +\left(T_{\mathrm{consensus}}\left(N_{\mathrm{sidechain}}\right)-T_{\mathrm{consensus}}\left(N_{\mathrm{nodes}}\right)\right)-{\displaystyle \frac{D}{H_{\mathrm{miner}}}}\hfill \end{array}$$

(26)

In these equations, $t_{\mathrm{hash}}$ is the computation time for a standard hash function, $t_{\mathrm{chameleon}}$ is the computation time for the chameleon hashing operation, $T_{\mathrm{consensus}}$ is the consensus delay as a function of participating nodes, B is the block size in bits, and $R_{\mathrm{bandwidth}}$ is the network transmission rate in bits per second. The term ${\displaystyle \frac{B}{R_{\mathrm{bandwidth}}}}$ represents the block transmission time, which is identical in both systems and cancels out.

Although $t_{\mathrm{chameleon}}$ is slightly larger than $t_{\mathrm{hash}}$, the overall latency of the mutable structure is significantly lower because the sidechain consensus delay is much smaller ($N_{\mathrm{sidechain}}\ll N_{\mathrm{nodes}}$).

The total processing delay for a block modification request, $T_{\mathrm{modify}}$, combines the local compute time and the consensus delay across sidechain nodes:

$$T_{\mathrm{modify}}=t_{\mathrm{proc}}+t_{\mathrm{net}}·N_{\mathrm{sidechain}}$$

(27)

where $t_{\mathrm{proc}}$ is the computation time for the chameleon hashing trapdoor operation, $t_{\mathrm{net}}$ is the average transmission delay between two adjacent fog nodes, and $N_{\mathrm{sidechain}}$ is the number of active nodes participating in the sidechain consensus.

Here, the term ${\displaystyle \frac{B}{T_{\mathrm{transaction}}}}$ (block handling time, where B is the block size and $T_{\mathrm{transaction}}$ is the transaction throughput) is equal in both systems and cancels out. Although $t_{\mathrm{chameleon}}$ is slightly higher than $t_{\mathrm{hash}}$, the overall latency of the mutable structure is significantly lower because the sidechain consensus delay is much smaller ($N_{\mathrm{sidechain}}\ll N_{\mathrm{nodes}}$).

It is worth mentioning that $O\left(N_{\mathrm{sidechain}}\right)$ is not a function in the traditional sense. Instead, it is Big-O notation that describes how the computational complexity grows as the number of sidechains increases.

Given that $O\left(H_{\mathrm{chameleon}}\right)<O\left(H\right),O\left(N_{\mathrm{sidechain}}\right)\ll O\left(N_{\mathrm{nodes}}\right),O\left(N_{\mathrm{sidechain}}\right)<{\displaystyle \frac{D}{H_{\mathrm{miner}}}}$, each term on the right-hand side is negative, implying:

$$L^{\mathrm{mutable}}-L^{\mathrm{immutable}}<0$$

(28)

that shows as mutable blockchains reduce latency compared to immutable ones because:

$$L^{\mathrm{mutable}}<L^{\mathrm{immutable}}.$$

(29)

4.2.4. Latency Scaling with Network Size

The impact of network size on latency can be analyzed by considering the number of participating nodes (N).

In an immutable blockchain, each node participates in transaction validation which can be denoted as

$$L^{\mathrm{immutable}}\propto O\left(N\right),$$

(30)

meaning that the load or computational cost of the immutable method grows proportionally with the number of nodes N.

In a mutable blockchain exploiting a sidechain, transaction validation is restricted to a subset of nodes within the sidechain rather than the entire network. If the number of nodes in the sidechain has a hierarchical or partitioned structure, the validation process can scale logarithmically with the total number of nodes:

$$N_{\mathrm{sidechain}}\approx O(logN),$$

(31)

meaning that the number of sidechains grows approximately logarithmically with the total number of nodes N. In other words, the growth is slow even as the network becomes very large. Accordingly, the validation process in a mutable blockchain can be indicated as

$$L^{\mathrm{mutable}}\propto O(logN),$$

(32)

thus the load of the mutable method grows proportionally to the logarithm of the number of nodes N, leading to a slow and efficient scaling as the network expands. This logarithmic scaling arises from the reduced number of nodes involved in validation which makes mutable blockchains more efficient in large-scale IoT networks.

All in all, our analytical model demonstrates that blockchain-based architectures have significant latency due to cryptographic validation, block creation, and consensus overhead. With localized validation, mutable blockchains (chameleon hashing) show lower latency than immutable ones. This reduction is crucial for latency-sensitive IoT-Fog applications requiring real-time processing.

4.3. Throughput

Throughput (T) is the number of transactions the architecture confirms in a given time. In blockchain-based IoT–fog systems, it depends on transaction validation, how fast blocks are created, and the consensus method. Higher throughput means the network is more efficient and can confirm more transactions per second (TPS).

The total throughput is defined as:

$$T={\displaystyle \frac{N_{transactions}}{L}}$$

(33)

where:

• $N_{transactions}$: Number of transactions processed.
• L: Latency required to process these transactions.

Since transactions are not necessarily independent, their total processing time is not simply the sum of individual latencies. Instead, the effective latency $L_{\mathrm{total}}$ considers factors such as batch processing, network congestion, and parallel execution. In immutable and mutable blockchains, throughput differs due to variations in block validation time and consensus overhead, which impact $L_{\mathrm{total}}$.

In immutable blockchain, transactions are in strict cryptographic validation (SHA-256) and require global consensus among all nodes, leading to lower throughput:

$$T^{immutable}={\displaystyle \frac{B}{T_{validation}^{immutable}+T_{block}+T_{consensus}^{PoW}}}$$

(34)

In mutable blockchain using chameleon hashing, transactions are processed with reduced validation complexity and localized consensus, leading to higher throughput:

$$T^{mutable}={\displaystyle \frac{B}{T_{validation}^{mutable}+T_{block}+T_{consensus}^{mutable}}}$$

(35)

Since $T_{validation}^{mutable}<T_{validation}^{immutable}$ and $T_{consensus}^{mutable}<T_{consensus}^{PoW}$, we have:

$$T^{mutable}>T^{immutable}$$

(36)

4.3.1. Transaction Validation Impact on Throughput

Throughput is influenced by transaction validation time, which depends on the cryptographic complexity of hashing:

$$T_{validation}^{immutable}=O\left(H\right)+O\left(N_{nodes}\right)$$

(37)

$$T_{validation}^{mutable}=O\left(H_{chameleon}\right)+O\left(N_{sidechain}\right)$$

(38)

Since chameleon hashing has lower computational complexity than SHA-256 we have:

$$O\left(H_{chameleon}\right)<O\left(H\right)$$

(39)

Moreover, mutable blockchains can validate transactions faster which causes higher throughput. We quantify it as:

$$T_{validation}^{mutable}<T_{validation}^{immutable}$$

(40)

4.3.2. Block Creation Rate and Throughput

The block creation rate also affects throughput. Given a block size of B transactions, the throughput can be formulated as (41), where $T_{block}$ is the time required to finalize a block

$$T={\displaystyle \frac{B}{T_{block}}}$$

(41)

Since the immutable blockchain requires full network validation for each block, the block creation time is:

$$T_{block}^{immutable}=O\left(N_{nodes}\right)$$

(42)

In a mutable blockchain instead, block finalization occurs locally in the sidechain:

$$T_{block}^{mutable}=O\left(N_{sidechain}\right)$$

(43)

Since $N_{sidechain}\ll N_{nodes}$, we have $T_{block}^{mutable}<T_{block}^{immutable}$ causes improved throughput in mutable blockchains.

4.3.3. Consensus Overhead and Its Impact on Throughput

The consensus mechanism has significant delays that affect throughput. In an immutable blockchain using Proof-of-Work (PoW), the consensus time is determined by mining difficulty (D) and miner computational power ($H_{miner}$):

$$T_{consensus}^{PoW}={\displaystyle \frac{D}{H_{miner}}}$$

(44)

In a mutable blockchain, as shown in Equation (22), consensus occurs at the sidechain level with reduced node participation ($T_{consensus}^{mutable}=O\left(N_{sidechain}\right)$).

Since $O\left(N_{sidechain}\right)\ll {\displaystyle \frac{D}{H_{miner}}}$, we conclude $T_{consensus}^{mutable}<T_{consensus}^{PoW}$ which causes higher throughput.

4.3.4. Total Throughput Comparison

By substituting latency components into Equations (34) and (35), we obtain the total throughput for immutable and mutable blockchains:

$$T^{immutable}={\displaystyle \frac{B}{O\left(H\right)+O\left(N_{nodes}\right)+O\left(N_{nodes}\right)+\frac{D}{H_{miner}}}}$$

(45)

$$T^{mutable}={\displaystyle \frac{B}{O\left(H_{chameleon}\right)+O\left(N_{sidechain}\right)+O\left(N_{sidechain}\right)+O\left(N_{sidechain}\right)}}$$

(46)

Since $O\left(H_{chameleon}\right)<O\left(H\right)$, $O\left(N_{sidechain}\right)\ll O\left(N_{nodes}\right)$, and $O\left(N_{sidechain}\right)<{\displaystyle \frac{D}{H_{miner}}}$, we have $T^{mutable}>T^{immutable}$. It shows that mutable blockchains achieve higher throughput compared to immutable ones.

4.3.5. Throughput Scaling with Network Size

Throughput is affected by the number of participating nodes (N). In an immutable blockchain, every node must participate in consensus, leading to:

$$T^{immutable}\propto O\left({\displaystyle \frac{1}{N}}\right).$$

(47)

In mutable blockchains, where consensus occurs at the sidechain level instead:

$$T^{mutable}\propto O\left({\displaystyle \frac{1}{logN}}\right)$$

(48)

As a result, in large-scale IoT networks, mutable blockchains scale better in terms of throughput than immutable blockchains.

All in all, analytical model above demonstrates that throughput in blockchain-enabled IoT-Fog architectures is constrained by validation complexity, block generation time, and consensus mechanisms. Immutable blockchains have lower throughput because of SHA-256 hashing and the extra work from PoW consensus. In contrast, mutable blockchains that use chameleon hashing and local (sidechain) validation can process more transactions. They reach higher throughput and are a better fit for IoT–fog networks with many transactions.

5. Implementation

To connect our theoretical model with the simulation setup, we link the performance metrics in the simulation and the analytical modeling presented before. In this section, we give an account of the evaluations we performed to evaluate the performance of the PaB-PIF architecture. We run the simulator on a laptop with an 11th Gen Intel(R) Core(TM) i7-1165g7 2.80 GHz processor and 16 gigabytes of RAM. We compared PaB-PIF against a traditional IoT-Fog-Cloud architecture that lacks blockchain infrastructure [20]. The standard model has three layers: cloud, fog, and device. User devices create transactions and send them to a fog gateway at the edge of the network. The fog gateway processes the requests, coordinates the IoT devices in its area, and forwards tasks to a cloud broker. We used Fobsim [21,22], a Python-based discrete-event simulator, to implement Fog-blockchain integration scenarios to evaluate our architecture. It models architecture behavior by processing events sequentially over time, handling transaction validation, block generation, and network communication with minimal computational overhead.

The reported latency values do not depend on the laptop hardware used for the simulation. Since a discrete event simulation has been performed, simulation results depend only on the simulator setup and not on the hardware it runs. Of course simulation time is affected by the computational power available to simulation. On the other hand, values obtained as simulation outcome depends on the type of machines assumed in the simulated system. In a real-world system or on dedicated servers, the latency values would be much lower when better processing power is assumed. However, the performance trends and the differences between the mutable and immutable blockchains would remain the same. These trends depend on the network size and the cryptography rules, not just the hardware.

5.1. Simulation Setup

The simulation parameters are defined in the Sim_parameters.json file, specifying various settings for fog, cloud, and blockchain configurations.

Table 2. Simulation parameters.

Parameter	Value
Number of Fog Nodes	20
Number of Cloud Nodes	4
Number of Users per Fog Node	3
Delay (End User-Fog Gateway)	5 s
Delay (Fog Gateway-Fog Blockchain)	15 s
Delay (Fog Gateway-Cloud Gateway)	10 s
Delay (Cloud Gateway-Cloud Blockchain)	50 s
Redaction Delay	10 s

lists the key simulation parameters we used.

5.2. The Metrics

For the performance evaluation, we use Throughput, Latency, and Attack Impact in terms of tamper resistance metrics and characterized them with Confidence Intervals (CIs).

5.2.1. Throughput

Throughput measures in Transactions Per Second (TPS) which is the number of transactions completed per unit time. It is evaluated using Equation (49). In this equation Total Transactions represents the total number of transactions processed by IoT devices, fog nodes, and cloud nodes. Moreover, total latency means the whole time it takes from starting a transaction until it is finished.

$$\mathrm{Throughput}={\displaystyle \frac{\mathrm{Total}\mathrm{Transactions}}{\mathrm{Total}\mathrm{Latency}}}$$

(49)

5.2.2. Latency

It represents the total time taken for a transaction to be processed from initiation to completion. Equation (50) indicates how to calculate it

$$\mathrm{Latency}=T_{\mathrm{finish}}-T_{\mathrm{start}}$$

(50)

In this equation start denotes the timestamp when the transaction processing begins, finish is the timestamp when the transaction is successfully completed. In the simulation, we measured it in seconds.

5.2.3. Tamper Resistance

Tamper resistance measures the resilience of the architecture against unauthorized modifications and attacks. It is calculated based on multiple security factors, including cryptographic security, consensus mechanisms, and access control, using the following Equation (51):

$$\mathrm{Tamper}\mathrm{Resistance}=1-{\displaystyle \frac{P_{\mathrm{Unauthorized}\mathrm{Change}}}{1+\mathrm{Security}\mathrm{Boost}}}.$$

(51)

In this equation, unauthorized change is the probability of unauthorized modifications occurring, influenced by attack rates and security vulnerabilities; Security Boost represents the additional security enhancements provided by the blockchain architecture (e.g., immutable vs. mutable blockchain). A higher tamper resistance value (closer to $1.0$) indicates a more secure system, while a lower value shows increased vulnerability to unauthorized changes.

5.2.4. Confidence Intervals

In this paper, we calculated the results with a $99\%$ CI with the usual approach of Equation (52):

$$CI=\eta \pm (2.576\times {\displaystyle \frac{\sigma }{\sqrt{n-1}}})$$

(52)

In Equation (52), $2.576$ corresponds to the $99\%$ percentile of the t-Student distribution. Moreover, n, $\sigma$, and $\eta$ represent the number of samples, standard deviation, and sample mean, respectively.

5.3. The Scenario

Comparing methods based on various attack rates. The number of IoT devices and fog devices in this scenario is 60 and 20, respectively. The percentage of attacks ranges from 0 to $40\%$. This percentage represents the proportion of malicious requests versus benign ones.

5.4. Implementation Results

In this section, we explain the implementation results for the PaB-PIF architecture and other architecture in the mentioned scenarios. First, we explain the evaluation of different attack rates.

As first step, we evaluated the PaB-PIF architecture fog layer latency, which uses the chameleon method with a Fog-enabled IoT architecture without any security mechanism. The IoT architecture without blockchain has significantly lower latency (5.04 s) compared to PaB-PIF (mutable blockchain with chameleon hashing redaction), because it does not require blockchain-related computations such as cryptographic hashing, consensus validation, and redaction processing. In contrast, PaB-PIF latency is much higher (ranging from 35 s to 55 s) due to transaction validation delays, miner competition, and consensus overhead, which have computational and communication bottlenecks. The confidence interval (CI) for PaB-PIF latency is significant because blockchain operations can be highly variable, depending on network congestion, block finalization times, and adversarial interference. Meanwhile, IoT latency has a very small CI across all attack rates since it follows a deterministic execution model without blockchain delays; it has consistent task completion times regardless of network conditions or attack levels.

Table 3. Fog layer latency.

Attack Rate	PaB-PIF Latency	PaB-PIF CI	IoT Latency	IoT CI
0%	48.39	(38.51, 58.27)	5.03	(5.03, 5.04)
10%	55.42	(17.81, 93.03)	5.04	(5.03, 5.06)
20%	38.35	(32.40, 44.31)	5.04	(5.03, 5.04)
30%	44.25	(34.11, 54.40)	5.04	(5.03, 5.05)
40%	35.21	(30.83, 39.57)	5.04	(5.03, 5.05)

shows the fog layer latency for a non-blockchain IoT architecture and the chameleon hashing redaction method.

We also evaluated the PaB-PIF architecture cloud layer latency, which uses the SHA-256 method with the IoT architecture. The IoT architecture without blockchain exhibits consistently lower latency (60 s) than PaB-PIF (immutable blockchain using SHA-256) because it processes tasks directly without blockchain-related overhead. PaB-PIF latency is significantly higher (ranging from 117 s to 152 s) due to computationally expensive cryptographic hashing (SHA-256), consensus mechanisms, and transaction verification, all of which have additional processing and communication delays. The confidence interval (CI) for PaB-PIF is significant, especially at $0\%$, $10\%$, and $30\%$ attack rates, because blockchain operations depend on variable factors such as miner availability, block validation times, and network conditions. As a result, it causes fluctuations in latency. In contrast, IoT latency has an extremely small CI, remaining nearly constant across all attack rates, as it follows a deterministic execution model without blockchain constraints; it has stable task execution and minimal processing variation.

Table 4. Cloud layer latency.

Attack Rate	PaB-PIF Latency	PaB-PIF CI	IoT Latency	IoT CI
0%	151.95	(96.92, 206.98)	60.011	(60.00, 60.01)
10%	133.47	(95.40, 171.53)	60.022	(60.00, 60.03)
20%	123.97	(119.39, 128.55)	60.01	(60.00, 60.01)
30%	146.39	(109.25, 183.52)	60.01	(60.00, 60.01)
40%	117.23	(107.25, 127.20)	60.012	(60.00, 60.01)

shows the cloud layer latency for a non blockchain IoT architecture and SHA-256 method for immutable blockchain.

Third experiment evaluated the PaB-PIF architecture Fog layer throughput, which uses the Chameleon reduction method with the IoT architecture. The IoT architecture without blockchain achieves significantly higher throughput (47.56–47.64 TPS) compared to PaB-PIF (mutable blockchain using chameleon hashing redaction, 5.16–6.89 TPS) because it processes transactions directly without the computational and communication overhead of blockchain. PaB-PIF throughput is lower due to the additional time required for block creation, consensus validation, cryptographic hashing, and redaction operations. The confidence interval (CI) for PaB-PIF is large because blockchain processing is highly variable, depending on factors such as miner workload, block finalization time, and attack disruptions. In contrast, IoT throughput has a very small CI, remaining stable across all attack rates since transactions are processed straightforwardly and deterministically without waiting for block confirmation or consensus. Accordingly, it leads to minimal variation in performance.

Table 5. Fog layer throughput.

Attack Rate	PaB-PIF Throughput	PaB-PIF CI	IoT Throughput	IoT CI
0%	5.16	(3.98, 6.33)	47.64	(47.60, 47.68)
10%	5.41	(3.39, 7.42)	47.579	(47.49, 47.66)
20%	6.38	(5.39, 7.37)	47.61	(47.55, 47.67)
30%	5.61	(4.52, 6.70)	47.56	(47.49, 47.62)
40%	6.89	(6.12, 7.67)	47.56	(47.50, 47.62)

indicates the Fog layer throughput for a non blockchain IoT architecture and chameleon method for mutable blockchain.

Our fourth experiment evaluated the PaB-PIF architecture cloud layer throughput, which uses the SHA-256 method with the IoT architecture. The IoT architecture without blockchain achieves consistently higher throughput (3.99 TPS) compared to PaB-PIF (immutable blockchain using SHA-256, 1.71–2.06 TPS) because it processes transactions directly without the computational overhead of blockchain. PaB-PIF throughput is significantly lower because of the time-consuming processes of SHA-256 hashing, consensus mechanisms, block validation, and transaction finalization, which have delays in confirming transactions. The confidence interval (CI) for PaB-PIF is significant, particularly at $0\%$, $10\%$, and $30\%$ attack rates, because blockchain transaction processing time varies due to miner competition, block propagation delays, and attack disruptions affecting consensus efficiency. In contrast, IoT throughput remains stable with an extremely small CI across all attack rates. Its transactions are processed deterministically without waiting for blockchain-related validation. As a result, it has consistent throughput across different scenarios.

Table 6. Cloud layer throughput.

Attack Rate	PaB-PIF Throughput	PaB-PIF CI	IoT Throughput	IoT CI
0%	1.75	(1.18, 2.31)	3.99	(3.99, 3.99)
10%	1.88	(1.53, 2.23)	3.99	(3.99, 4.00)
20%	1.93	(1.86, 2.01)	3.99	(3.99, 3.99)
30%	1.71	(1.36, 2.06)	3.99	(3.99, 3.99)
40%	2.06	(1.87, 2.25)	3.99	(3.99, 3.99)

indicates the cloud layer throughput for a non blockchain IoT architecture and SHA-256 for immutable blockchain.

We evaluated the PaB-PIF architecture fog layer tamper resistance, which uses the chameleon method with the IoT architecture, in the fifth simulated scenario. The PaB-PIF architecture (mutable blockchain with chameleon hashing redaction) demonstrates a consistent tamper resistance of $0.58$ across all attack rates, with a narrow confidence interval of 0.57, 0.59, showing that the blockchain mechanism provides a stable level of protection against unauthorized modifications. The immutability feature of chameleon hashing controlled redaction and prevented arbitrary tampering. In contrast, the IoT architecture without blockchain or security defence mechanisms has a tamper resistance of 0 across all attack rates, meaning it is fully vulnerable to attacks, as there are no cryptographic safeguards, consensus validation, or data integrity enforcement. The CI for IoT tamper resistance is also 0.

Table 7. Fog layer tamper resistance.

Attack Rate	Mutable Tamper Resistance	Mutable CI	IoT Tamper Resistance	IoT CI
0%	0.58	(0.57, 0.59)	0	(0, 0)
10%	0.58	(0.57, 0.59)	0	(0, 0)
20%	0.58	(0.57, 0.59)	0	(0, 0)
30%	0.58	(0.57, 0.59)	0	(0, 0)
40%	0.58	(0.57, 0.59)	0	(0, 0)

indicates the fog layer tamper resistance for a non blockchain iot architecture and chameleon method for mutable blockchain.

Finally, we evaluated the PaB-PIF architecture cloud layer tamper resistance, which uses the SHA-256 method with the IoT architecture. The PaB-PIF architecture (immutable blockchain using SHA-256) demonstrates an extremely high tamper resistance of $0.99$ across all attack rates, with a negligible confidence interval, indicating near-perfect protection against unauthorized modifications. This is due to the strong cryptographic integrity of SHA-256, coupled with the immutability of the blockchain, which prevents data from being altered once recorded. In contrast, the IoT architecture without blockchain has a tamper resistance of 0, meaning it is completely vulnerable to attacks, as there are no intrusion detection systems (IDSs) or security defense mechanisms.

Table 8. Cloud layer tamper resistance.

Attack Rate	Immutable Tamper Resistance	Immutable CI	IoT Tamper Resistance	IoT CI
0%	0.99	(0.99, 0.99)	0	(0, 0)
10%	0.99	(0.99, 0.99)	0	(0, 0)
20%	0.99	(0.99, 0.99)	0	(0, 0)
30%	0.99	(0.99, 0.99)	0	(0, 0)
40%	0.99	(0.99, 0.99)	0	(0, 0)

indicates the cloud layer tamper resistance for a non blockchain IoT architecture and SHA-256 method for immutable blockchain.

In Table 7 and Table 8, the tamper resistance stays at 0.58 for the fog layer and 0.99 for the cloud layer. These numbers do not change when the attack rate changes. This is because tamper resistance depends on the hash method, not on network traffic. In the fog layer, we use chameleon hashing to edit data. Here, changing one block only changes the next block ($d=1$), so the value stays at 0.58. In the cloud layer, SHA-256 connects each block to all older blocks ($d=n$), so the value stays high at 0.99. Changing the attack rate makes the network slower, but the hash security stays the same.

The difference in tamper resistance comes from how hashes connect blocks in each blockchain type. In the immutable blockchain (SHA-256), each block’s hash depends on all previous blocks. If someone changes one block, all following blocks become invalid, making tampering almost impossible. That is why its tamper resistance is $0.99$. In the mutable blockchain (chameleon hashing), only the previous block’s hash connects to the current block. It controls changes without breaking the whole chain but makes tampering easier. Because of this, its tamper resistance is $0.58$, which is lower than the immutable blockchain.

5.5. Quantitative Comparison with State-of-the-Art Designs

To provide a clear understanding of system performance, we first present a general comparison between our proposed architecture and existing models (Table 1). Following this comparison, we analyze how varying attack rates impact specific performance metrics, including latency and throughput.

The comparison in Table 1 is a qualitative one. It shows the design choices of the related works, but it does not give measured numbers. To add a measured comparison, we implemented two state-of-the-art baselines in the same simulation environment, with the same parameters of Table 2 and the same metric definitions of Section 5. In this way, the numbers can be compared in a fair way. We chose these two baselines because they cover the two main design ideas in the related works that are different from PaB-PIF.

The first baseline is a fully mutable single-chain design (Baseline A). It keeps all the data on one public chain and allows on-demand redaction and deletion, in the same spirit as Tulkinbekov and Kim [12] and Kottursamy et al. [13], and it uses chameleon-hash style redaction [23]. There is no fog offloading, so the consensus is global, but the cryptography is light. We implemented it with light hashing, global consensus, and an on-chain redaction step.

The second baseline is a hybrid on-chain and off-chain design (Baseline B), in the same spirit as Can et al. [18]. Most operations run on a fast central off-chain database, and only periodic Merkle-root anchors are written on-chain with SHA-256. We implemented it with a fast off-chain write and a small amortized anchoring cost.

For reference, we also report our own measured results for the immutable chain (the immutable design used by Latif et al. [14], Gomez et al. [16], Hewa et al. [17], and Rahman et al. [15]), the mutable sidechain of PaB-PIF, and the non-blockchain IoT base line [20]. We ran every configuration with the same number of nodes, the same delays, and the same attack rates from $0\%$ to $40\%$, and we report the average over all attack rates with a $99\%$ confidence interval.

Table 9. Measured comparison of state-of-the-art designs and PaB-PIF under the same simulation setup (average over attack rates 0–$40\%$).

Architecture/Design (Representative Works)	Mutability	Throughput (TPS)	Latency (s)	Tamper Resistance
No blockchain, fog [20]	None	47.59	5.04	0
No blockchain, cloud [20]	None	3.99	60.01	0
Baseline A: single mutable chain [12,13]	Mutable	3.74	65.57	0.55
Baseline B: hybrid off-chain [18]	Hybrid (off-chain)	24.69	9.89	0.30
Immutable chain [14,15,16,17]	Immutable	1.87	134.60	0.99
PaB-PIF mutable sidechain (fog)	Mutable	5.89	44.32	0.58
PaB-PIF(full, this work)	Hybrid (mutable fog/immutable cloud)	Layered	Layered	0.58 (fog)/0.99 (cloud)

shows the results.

The results show clear trade-offs. The non-blockchain baseline is the fastest and gives the highest throughput, but its tamper resistance is 0, so it has no protection at all. Baseline B (hybrid off-chain) is also fast, with about $24.69$ TPS and 9.89 s latency, because most work runs off-chain. But its tamper resistance is only about $0.30$, because the sensitive data sits in one central off-chain database. This database is a single point of failure, and the blockchain can only detect a change, not stop it. Baseline A (single mutable chain) gives a medium speed of about $3.74$ TPS and 65.57 s latency. Its tamper resistance is about $0.55$. It is a bit slower and a bit less safe than our mutable sidechain ($5.89$ TPS, 44.32 s, $0.58$), because it runs one global chain and allows on-demand deletion, which makes a larger attack surface. The immutable chain is the safest, with a tamper resistance of about $0.99$, but it is the slowest, with about $1.87$ TPS and 134.60 s latency, because of SHA-256 hashing and global consensus. So no single design is good in every metric at the same time.

PaB-PIF uses two engines in one architecture. It runs the mutable sidechain in the fog layer for speed and the immutable mainchain in the cloud layer for strong protection. So PaB-PIF is faster than the immutable chain in the fog layer, it is safer than the hybrid off-chain baseline, and it avoids the larger attack surface of the single mutable chain. In this way, PaB-PIF reaches a better balance than any single baseline. None of the related works in Table 1 does this, because each of them uses only one design.

We also note one limitation. We implemented the two main alternative designs, but we did not re-implement each of the seven systems exactly. Their source code is not public, and they were built for different domains and report different metrics. For example, Tulkinbekov and Kim [12] report delete latency and block height, not throughput in TPS, so their own numbers cannot be placed next to ours in a fair way. For this reason, we implemented the two design families that they share, under one common setup. A full per-system replication of all seven systems is a part of our future work.

5.6. Discussion and Limitations

Our results show a balance between speed and security. The fog layer uses a sidechain, which makes the system fast and lets us edit data. At the same time, the cloud layer saves main data permanently, which keeps important records safe.

However, our study has three main limitations:

• Simulator use: We tested our system using FoBSim, not real hardware. The simulator models delays well, but real IoT devices can have extra network problems and bad connections.
• Storage space: Fog nodes must store copies of the sidechain. This can fill up memory on small devices.
• Key safety: Our security values show theoretical math safety. In real life, if someone steals the secret keys for the chameleon hashing, system security will drop.

6. Conclusions

In this paper, we studied mutable and immutable blockchains in IoT-Fog networks. We tested our proposed architecture, PaB-PIF, using math models and simulations. Our system uses a mutable sidechain in the fog layer for fast response times and an immutable mainchain in the cloud layer for high security. Our results show that no single design is best for everything. The fog layer allows fast data edits with a tamper resistance of 0.58. The cloud layer gives strong data protection with a tamper resistance of 0.99, but it is slower. By using both layers together, PaB-PIF gets a better balance than using only one blockchain type. Our study has some limitations. We tested the architecture using a simulator instead of real hardware devices, and storing sidechain data uses memory on fog nodes. In future work, we plan to test PaB-PIF on real IoT devices, measure energy use, and try data compression methods to save storage space.