Figure 1.
Architecture of the proposed framework
Table 1.
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 |
Table 2.
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 |
Table 3.
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. |
Table 4.
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) |
Table 5.
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. |
Table 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 |
Table 7.
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 |
Table 8.
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) |
Figure 2.
Comparison block chain framework verses traditional frame work
Figure 3.
Memory Usage Over Time in the Blockchain Framework vs Traditional Approach
Figure 4.
Latency versus Load (line chart)
Figure 5.
Security incident response time
Figure 6.
Key Performance Metrics
Table 9.
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) |
Table 10.
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) |
Table 11.
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. |