Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Storage and data efficiency
| Parameter | Result |
|---|---|
| Off-chain data size | ~200 MB (stored in IPFS) |
| Blockchain size after 1000 txns | ~8.4 MB |
| Hashing time per record (SHA-256) | 8.2 ms |
Performance matrices and their description
| Metric | Result | Description |
|---|---|---|
| Transaction Latency | 315 ms (avg) | Time from IIoT sensor event to blockchain confirmation. |
| Throughput | 75 TPS | Number of transactions handled by the network under load. |
| Block Creation Time | ~2 sec | Average block interval in RAFT consensus. |
| Edge CPU Usage | 42% avg | Lightweight agents kept device CPU below critical thresholds. |
Comparative Analysis of block chain and traditional system
| Feature | Traditional Security | Proposed Blockchain Framework |
|---|---|---|
| Central Point of Failure | Yes | No (decentralized) |
| Tamper Resistance | Low; unauthorized changes detected in >500 ms | High; unauthorized changes detected in <50 ms |
| Auditability | Manual logs; verification takes several minutes | Automated, real-time; verification <100 ms per transaction |
| Device Authentication | PKI / Static keys; higher impersonation risk | Certificates + Blockchain; stronger authentication |
| Integration Complexity | Medium | High (initial setup) |
Comparison of RAFT, PBFT, and Other Consensus Mechanisms
| Consensus Mechanism | Fault Tolerance | Communication Overhead | Scalability | Latency | Suitability for IIoT/Industry 4.0 |
|---|---|---|---|---|---|
| RAFT (Crash Fault Tolerant) | Tolerates crash faults (non-Byzantine) | Low (leader-based log replication) | High (scales well with nodes) | Low latency | Highly suitable: lightweight, efficient, good for trusted/permissioned environments |
| PBFT (Byzantine Fault Tolerant) | Tolerates Byzantine and crash faults | High (quadratic communication with node count) | Moderate (limited by overhead at scale) | Moderate to high latency | Suitable when adversarial behavior is expected, but less efficient for large IIoT systems |
| PoW (Proof of Work) | Byzantine fault tolerant | Very high (energy- and compute intensive) | Low (resource expensive, slow) | Very high latency (seconds–minutes) | Unsuitable: resource-heavy and impractical for real-time operations |
| PoS (Proof of Stake) | Byzantine fault tolerant | Moderate (depends on stake distribution) | Moderate to high | Higher latency than RAFT, lower than PoW | Less suitable: requires stake economics, not aligned with industrial trust model |
Statistical validation: ANOVA
| Latency under Network Load | |
|---|---|
| F-statistic | p-value |
| 6.16 | 0.0111 (< 0.05) |
| Memory Usage over Time | |
| F-statistic | p-value |
| 0.085 | 0.918 (> 0.05) |
| Security Incident Response Time | |
| F-statistic | p-value |
| 26.44 | 0.00017 (< 0.001) |
Hardware and Software Environment
| Category | Specification |
|---|---|
| Blockchain/Server Nodes | Intel Xeon Silver 4210 (10 cores, 2.2 GHz, 32 GB RAM, 1 TB NVMe SSD), Ubuntu 22.04 LTS, 1 Gbps Ethernet |
| Edge/IIoT Devices | Raspberry Pi 4 Model B (Quad-core Cortex-A72 @ 1.5 GHz, 4 GB RAM, 64 GB microSD), Raspberry Pi OS |
| Blockchain Platform | Hyperledger Fabric v2.4, Docker v20.x, Docker Compose v2.x, CouchDB v3.x (world state DB) |
| Messaging Protocols | MQTT (Mosquitto v2.0), CoAP (Eclipse Californium) for device communication |
| ML/Analytics Server | Intel Core i7-11700K (8 cores, 3.6 GHz, 16 GB RAM), NVIDIA GTX 1660 Ti (6 GB VRAM), Ubuntu 22.04 LTS |
| ML Frameworks | Python 3.10, TensorFlow 2.12, PyTorch 2.0, Scikit-learn 1.2, Optuna 3.0 (for hyperparameter tuning) |
| Monitoring Tools | Prometheus, Grafana, Node Exporter, Docker Stats |
| Random Seed Control | Seeds: 42, 123, 2025, 7, 99 across all experiments (NumPy, TensorFlow, PyTorch, Fabric configs) |
Statistical validation: t-tests
| Latency under Network Load | |
|---|---|
| t-statistic | p-value |
| -5.04 | 0.0039 (< 0.01) |
| Memory Usage over Time | |
| t-statistic | p-value |
| 0.29 | 0.7795 (>0.05) |
| Security Incident Response Time | |
| t-statistic | p-value |
| -13.86 | 0.0008 (< 0.001) |
System Model Description
| Module | Description |
|---|---|
| Identity & Access Control | Each device and user gets a digital certificate from the CA. Smart contracts verify roles before granting data access. |
| Smart Contracts | Three chaincodes developed: (1) Predictive Maintenance, (2) Supply Chain Logger, and (3) Access Auditing. |
| Security Agents | Python scripts deployed on edge gateways that intercept data, compute hashes, and push to blockchain. |
| Monitoring Dashboard | Visual interface for network health, transaction logs, and device status. |
Statistical Validation of Experimental Results
| Metric | Test Type | Comparison | Test Statistic | p-value | Significance | Interpretation |
|---|---|---|---|---|---|---|
| Latency (ms) | Paired t - test | Blockchain vs Traditional | t = -5.04 | 0.0039 | Yes (p < 0.01) | Blockchain significantly lowers latency. |
| ANOVA (F-test) | All methods | F = 6.16 | 0.0111 | Yes (p < 0.05) | Significant overall difference across methods. | |
| Blockchain vs Traditional | – | 0.0157 | Yes | Blockchain significantly better than Traditional. | ||
| Memory Usage (MB) | Paired t-test | Blockchain vs Traditional | t = 0.29 | 0.7795 | No | No significant difference. |
| ANOVA (F-test) | All methods | F = 0.085 | 0.9184 | No | No significant difference across methods. | |
| Response Time (s) | Paired t-test | Blockchain vs Traditional | t = -13.86 | 0.0008 | Yes (p < 0.001) | Blockchain significantly faster response. |
| ANOVA (F-test) | All methods | F = 26.44 | 0.00017 | Yes (p < 0.001) | Strong significant difference across methods. | |
| ANOVA (F-test) | All methods | F = 26.44 | 0.00017 | Yes (p < 0.001) | Strong significant difference across methods. |
Security Threats, Countermeasures, and Results
| Threat (STRIDE / MITRE ATT\&CK) | Countermeasure | Result |
|---|---|---|
| Spoofing (Identity Theft / T1078 – Valid Accounts) | PKI-based digital identities, digital signatures | Ensures strong authentication and prevents unauthorized device/user impersonation |
| Replay Attacks (T1001 – Data Obfuscation / T1071 – Application Layer Protocol) | Nonce values, timestamp validation in transactions | Prevents reuse of captured messages, ensuring data freshness and integrity |
| Tampering (Data Manipulation / T1565 – Data Manipulation) | Transaction verification, hash integrity checks in blockchain | Detects and prevents alteration of IIoT or blockchain data |
| Repudiation (T1070 – Indicator Removal on Host) | Immutable blockchain audit logs | Provides non-repudiation and forensic evidence for compliance and recovery |
| Information Disclosure (T1040 – Network Sniffing) | End-to-end encryption (TLS/DTLS) | Protects sensitive industrial data during transmission |
| Denial of Service (T1499 – Endpoint DoS) | Rate limiting, edge filtering, consensus mechanism resilience | Maintains service availability under attempted overload conditions |
| Elevation of Privilege (T1548 – Abuse Elevation Control) | Role-Based Access Control (RBAC) enforced via smart contracts | Restricts unauthorized privilege escalation, ensuring secure access control |
Security Evaluation matrices
| Threat Scenario | Outcome | Defences |
|---|---|---|
| Data Tampering | Detected | Hash mismatch alerted via smart contract |
| Replay Attack | Prevented | Nonce and timestamp verification |
| Unauthorized Access | Blocked | Role-based access enforced on-chain |
| Node Failure | Recovered | Peer node failure tolerated by RAFT consensus |