Fuzzychain-edge: Adaptive Blockchain Access

• Fuzzychain-edge is a fuzzy logic-based adaptive access control model that integrates zero-knowledge proofs and smart contracts to secure blockchain-enabled edge computing for IoT.
• The model uses a layered architecture combining IoT devices, edge nodes, permissioned blockchains, and cloud services to ensure privacy, traceability, and dynamic access decisions in sensitive domains like healthcare.
• It employs a detailed fuzzy inference system with triangular/trapezoidal membership functions and zk-SNARK integration to achieve low latency and high throughput, as verified by comparative performance metrics.

Fuzzychain-edge is a Fuzzy logic-based adaptive access control model designed for blockchain-based edge computing environments, emphasizing the integration of Zero-Knowledge Proofs (ZKPs), context-aware fuzzy inference, and smart contracts within permissioned distributed ledgers. The framework targets security and privacy challenges in Internet of Things (IoT) domains—especially healthcare—by enabling privacy-preserving, adaptive, and traceable access decisions for sensitive data and services (Farooq et al., 15 Jan 2026).

1. System Architecture

Fuzzychain-edge adopts a four-tier architecture comprising:

• IoT Devices: Sensors and wearables responsible for generating subject attributes (SA), object attributes (OA), trust levels (TL), data sensitivity (DS), and transmitting credentials ($CU$).
• Edge Nodes: Host the Fuzzy Logic Access Control Module (FLACM) and a local blockchain node, serving as intermediaries for cryptographic operations and initial processing.
• Permissioned Blockchain Network: Implements distributed, immutable storage with consensus and hosts smart contracts enforcing the access policy (example platforms: Hyperledger Fabric).
• Cloud/Data Center Providers: Deliver the backend computation or store records (e.g., electronic health-record servers).

Data flow occurs through seven steps:

1. IoT device submits attributes and credentials.
2. Edge node generates zk-SNARK proof $P_U = f(CU, kp)$; verification performed on both user and service provider sides.
3. Privacy-preserved hashes ($H_{\text{Blockchain}_U}$, $H_{\text{Blockchain}_S}$) are appended onto blockchain $B$.
4. FLACM fuzzifies parameters to produce a capability token $C(\tau_i, \nu_j)$.
5. Rule-based fuzzy inference derives Degree-of-Access ($DoA$).
6. Smart contracts grant or deny access, with all decisions logged immutably.
7. Edge node returns result or denial reason to requesting device.

This layered approach separates data capture, policy evaluation, cryptographic proof, blockchain-based enforcement, and service provisioning.

2. Fuzzy Logic Access Control Model

Access control is achieved through a fuzzy inference system evaluating multi-dimensional, contextual variables:

• Input Variables: Five normalized parameters ($x_i \in [0,1]$):
  • Data Sensitivity ($x_1$)
  • Trust Level ($x_2$)
  • User Activity ($x_3$)
  • Compliance History ($x_4$)
  • Patient Condition ($x_5$)

Membership Functions: Triangular and trapezoidal, e.g.:

$$\mu_{\text{tri}}(x;a,b,c) = \begin{cases} 0, & x \leq a, \ \dfrac{x-a}{b-a}, & a < x \leq b, \ \dfrac{c-x}{c-b}, & b < x < c, \ 0, & x \geq c. \end{cases}$$

Rule Base (sample rules):

Rule	Condition	Decision
R1	IF $DS$ is High AND $TL$ is Low AND PatientCondition is Critical	Deny
R2	IF $DS$ is Medium AND $TL$ is Medium AND PatientCondition is Moderate	Read–Write
R3	IF $DS$ is Low AND $TL$ is High AND PatientCondition is Stable	Full
R4	IF UserActivity is Frequent AND ComplianceHistory is Excellent	Full
R5	IF UserActivity is Occasional AND ComplianceHistory is Poor	Read-Only

Fuzzification and Inference:

• Each input is mapped to fuzzy sets.
• Mamdani inference applies: for each rule $j$,

$$\alpha_j = \min_k\,\mu_{A_{j,k}}(x_{i_k}) \text{ (antecedent strength)}$$

• Resulting MFs are aggregated:

$$\mu_{\text{agg}}(y) = \max_j(\alpha_j \wedge \mu_{B_j}(y))$$

Defuzzification:

• Centroid method to obtain crisp decision:

$$y^* = \frac{\int y\,\mu_{\text{agg}}(y)\,dy}{\int \mu_{\text{agg}}(y)\,dy}$$

This adaptive evaluation resists role-based injection attacks and supports fine-grained, context-aware enforcement.

3. Zero-Knowledge Proof Integration

ZKPs are deployed to verify credentials and sensitive attributes without revealing underlying information.

• zk-SNARK Protocol:
  • Prover constructs proof $\pi = \mathsf{Prove}(x,w;kp)$, where $x$ is a public statement (attributes), $w$ a witness, with $kp$ the private key.
  • Verifier checks: $$\mathsf{Verify}(\pi, x; vk) \in \{\mathrm{True}, \mathrm{False}\}$$.
• NP-Relation Definition:

$$R = \{ (x,w) \mid w \text{ certifies } x \text{ satisfies policy} \}$$

• Security Properties:
  • Completeness: Valid $(x,w)$ always accepted.
  • Soundness: Invalid instances are accepted only with negligible probability.
  • Zero-Knowledge: Existence of a simulator $\mathcal{S}$ ensuring indistinguishability between simulated and real proofs.

Hashes of ZKP-derived proofs, salted for privacy, are stored on the blockchain, preventing replay and correlational attacks.

4. Smart Contract Protocols and Implementation

The access logic is enforced on-chain using smart contracts:

• Contract State: Code is specified in Solidity-style pseudocode.
  • Enum Decision encodes {Deny, ReadOnly, ReadWrite, Full}
  • struct Policy links subject, object, and decision.
  • Mappings maintain policies and store ZKP proofs.
  • Events signal grant or denial.

Pseudocode highlights:

function requestAccess( bytes32 requestId, bytes calldata proof, bytes32 subjHash, bytes32 objHash ) external { require(verifyZKP(proof, subjHash), "ZKP failure"); Decision doA = evaluateFuzzy(subjHash, objHash); if (doA != Decision.Deny) { policies[requestId] = Policy(subjHash, objHash, doA); emit AccessGranted(requestId, subjHash); } else { emit AccessDenied(requestId, subjHash); } }

• Performance: Verification for zk-SNARKs costs ~200,000 gas, fuzzy inference ~30,000 gas, and hash/storage operations ~8,000 gas.

On-chain access decisions are logged for traceability and non-repudiation.

5. Security and Performance Evaluation

Threat Model and Mitigations:

• Defends against unauthorized access, proof replay, and collusion.
• zk-SNARKs provide credential privacy and replay resistance.
• Fuzzy logic enables dynamic, context-driven adaptation to thwart rule injection.
• Blockchain enforces auditability and immutable policy enforcement.

Evaluation Metrics:

• Latency ($\varphi$), throughput (TPS), access decision accuracy, and privacy coverage.
• Selected performance results:

Send Rate (tps)	Paper 1 Lat (ms)	Paper 2 Lat (ms)	Fuzzychain Lat (ms)	Paper 1 TPS	Paper 2 TPS	Fuzzychain TPS
25	320	315	312	22	22	24
100	400	390	386	100	100	105
200	2285	1785	1765	150	160	165

Fuzzychain-edge achieves lowest observed latency and highest throughput across all tested loads compared to alternative schemes. This suggests improvements in efficiency and scalability within permissioned IoT environments.

6. Limitations and Prospective Enhancements

Identified Limitations:

• zk-SNARK proof generation remains a computational bottleneck for resource-constrained edge nodes.
• Consensus overhead in permissioned blockchains introduces additional delay under elevated transaction rates.

Future Directions:

• Explore zk-STARKs or Bulletproofs to reduce proof size and verification time.
• Offload cryptographic operations to hardware accelerators at the edge.
• Combine reinforcement learning with fuzzy rule-base for dynamic adaptation.
• Extend applicability to other high-value IoT domains (e.g., smart grids, industrial IoT).
• Investigate hybrid on-chain/off-chain storage for performance and cost optimization (Farooq et al., 15 Jan 2026).

Fuzzychain-edge defines a direction for integrating privacy-preserving, adaptive access control in decentralized edge computing, supporting verifiable, context-sensitive, and efficient policies across sensitive domains.