Analysis of a Modified Hyperledger Fabric Blockchain Architecture for GDPR-Compliant Identity and Access Management

Abstract

Background: Conventional blockchain ledgers are immutable by design, which conflicts with the right to erasure mandated by the European Union General Data Protection Regulation (GDPR, Article 17), particularly for identity and access management (IAM) workloads that store personal data on-chain. Methods: We integrated the National Institute of Standards and Technology (NIST) data block matrix (DBM) into Hyperledger Fabric, developed an IAM chaincode with erasure-aware role-based and attribute-based access control, formally modeled the deletion protocol in TLA+ at a bounded scope (up to 4 organizations, 3 assets, quorum $=3$), and evaluated the design on a local 3-VM testbed and a 20-organization cross-region Google Kubernetes Engine (GKE) deployment. Results: Hash-operation counts from ${10}^2$ to ${10}^6$ blocks track the theoretical $O\left(\sqrt{N}\right)$ bound; chaincode-level throughput reaches 78–102 TPS for individual operations and 1967–2465 TPS for batch writes, with a 305 TPS sustained measurement across 20 organizations over an 80–100 ms cross-region link. Conclusions: The design supports technical alignment with GDPR Article 17 for on-chain data, but a deterministic timing oracle on the deletion reject path and a rate-limiter gap on the request path remain open; these are disclosed as scope limitations and prioritized for structural mitigation in future work.

1. Introduction

The evolution of blockchain technology has transformed distributed computing by establishing decentralized, trustless environments for data storage and transaction processing [1]. Blockchain systems, distinguished by their immutable ledger architecture, have been adopted across diverse domains, spanning cryptocurrency and supply chain management to identity verification and access-control systems [2,3]. The core design principle of blockchain, that is, maintaining data integrity through cryptographic hashing and consensus mechanisms, produces an immutable record that remains unalterable once committed to the ledger. This immutability represents both blockchain’s primary strength and, increasingly, its most substantial limitation [4,5,6,7].

The European Union (EU) General Data Protection Regulation (GDPR), enacted in 2018, represents a landmark shift in data privacy legislation, establishing comprehensive frameworks for data protection and privacy across the EU and the European Economic Area [8]. Central to GDPR is the principle of data subjects’ rights, particularly the “right to be forgotten” or “right to erasure” (Article 17), which empowers individuals to request deletion of their personal data under specific circumstances [8,9]. This regulatory framework has created a fundamental tension with blockchain technology’s core design principle: the immutable nature of blockchain directly conflicts with GDPR’s requirement for data deletion capabilities [10].

This conflict becomes particularly pronounced in Identity and Access Management (IAM) systems, where personal data processing is integral to system functionality. Traditional IAM systems rely on centralized architectures that, while capable of data modification and deletion, suffer from single points of failure, limited transparency, and challenges in establishing cross-organizational trust [11,12]. The distributed trust properties of blockchain technology offer compelling advantages for IAM applications, including enhanced security through cryptographic verification, improved auditability through immutable transaction logs, and elimination of centralized trust dependencies. However, implementing blockchain-based IAM systems faces significant challenges when personal data must be stored, processed, and potentially deleted in compliance with privacy regulations [13,14].

Hyperledger Fabric, one of the most widely adopted permissioned blockchain frameworks [15], exemplifies these challenges. Comprehensive performance characterizations of Fabric, spanning the original execute–order–validate architecture [15], the bottleneck-targeted optimizations identified by Thakkar et al. [16], and recent stochastic workload models by Melo et al. [17,18], establish the performance envelope against which any privacy extension such as the present work must be measured. While Fabric provides sophisticated privacy features through private data collections and channel-based segregation, its fundamental architecture remains constrained by blockchain’s immutability requirements [19,20]. The National Institute of Standards and Technology (NIST) Data Block Matrix (DBM) architecture, originally proposed by Kuhn [21] and implemented as a proof of concept by Roberts et al. [22], offers a promising approach to reconciling blockchain immutability with data deletion requirements. However, comprehensive performance characterization and IAM-specific application of this architecture remain underexplored.

This work extends prior research presented at the International Symposium on Electronics and Telecommunications 2024 [4] and delivers an end-to-end IAM architecture on a DBM-enabled Hyperledger Fabric whose contributions span chaincode design, Fabric-core patches, an empirical security framework, and a formal verification of the deletion-protocol invariants. The DBM primitive itself originates from Kuhn [21] and a proof-of-concept Fabric integration was demonstrated by Roberts et al. [22]; neither prior work couples the primitive to a production-grade IAM policy engine, characterizes the bugs and bottlenecks that surface in Fabric under sustained multi-organization load with DBM active, or applies a quantitative or formal security framework to the deletion protocol. The present work makes the following specific contributions:

1.

IAM-specific chaincode integration with erasure-aware Role-Based Access Control (RBAC)/Attribute-Based Access Control (ABAC). Role layering distinguishes manager-level logical deletion (preserves audit evidence) from Data Protection Officer (DPO)-level cryptographic erasure (triggers matrix rehashing). The ABAC layer performs single-pass RBAC + ABAC evaluation over the caller’s bindings with a deny-overrides conflict resolver and a formally defined five-factor risk score (Section 3). The chaincode and the audit namespace are linked so that audit records are non-deletable by two independent code paths, specifically the chaincode-level protectAuditNamespace guard and the block-storage-level isNonErasable predicate; this provides defense-in-depth against the compromise of a single layer.

2.

Fabric-core patches required for DBM-compatible operation under sustained load. Eight targeted patches across common/ledger/blkstorage, common/ledger/kvledger, internal/pkg/gateway/commit, discovery/endorsement, common/channelconfig, and core/peer (Section 3.5) resolve three concurrency bugs that surface only under multi-organization load (iterator send-on-closed-channel, commit-notifier race, and status-listener notify-before-remove) and add four performance optimizations (endorsement-plan LRU cache, MSP identity cache, validator-pool size, and gateway concurrency limit) that are necessary for the DBM backend to deliver the workloads reported in Section 4.

3.

Formal verification of the deletion-protocol safety invariants. A TLA+ specification of the two-phase deletion state machine (Appendix B) is exhaustively model-checked at 4-organization/3-asset/quorum = 3 scope, searching 274,625 distinct states with zero counterexamples to three safety invariants: quorum enforcement, erase-implies-audit, and audit monotonicity.

4.

Empirical security framework. Seven attack vectors (selective history rewriting, mass-deletion Denial of Service (DoS) dose–response, collusion with a quorum matrix, role escalation, compromised-DPO under varying endorsement policies, rogue-Certificate Authority (CA)-minted identity and a latency side-channel probe) were executed as reproducible experiments against a three-organization testbed and are summarized in Section 3.3. Auxiliary sweeps (fuzz testing over 330 malformed-JSON variants and 200-variant probing of the audit namespace) characterize the robustness of the input-validation and namespace-isolation surfaces. Outcomes include a deterministic binary oracle for the timing side channel (rank-biserial $r_{rb}=-1.0000$, $n=400$) and a quorum-matrix outcome that matches the theoretical Byzantine bound (Section 3.3).

5.

Primitive-level and in-Fabric performance characterization. A benchmark of the DBM matrix primitive across $N={10}^2$–${10}^6$ cells yields $R^2=0.9998$–$0.99999$ for the $O\left(\sqrt{N}\right)$ insert, delete and proof operations, and $R^2=0.999998$ for the $O\left(N\right)$ full verification; these results are consistent with the theoretical complexity claim at the resolution of the measurement and are reported separately from the transaction-level 78–102 Transactions Per Second (TPS) characterization inside Fabric. A microbenchmark comparison against a chameleon-hash construction [23] indicates that the DBM primitive is faster at the operation level; the comparison is reported as context rather than as a precise performance ratio.

6.

Realistic IAM workflow evaluation and concurrency break-point analysis. Transaction-level benchmarks for identity registration, policy update, audit query, deletion request, and risk scoring workflows are reported in Section 4.3.4, along with a concurrency break-point sweep (Section 4.3.5) showing sustained TPS and $p_{99}$ latency up to the pipeline saturation point. Network-scale validation was performed against a 20-organization cross-region Hyperledger Fabric deployment (Section 4.3.6).

Research Questions

The evaluation is organized around four research questions:

• RQ1. Can a SHA-256 DBM be coupled with a multi-organization Hyperledger Fabric to support GDPR Article 17 erasure on the on-chain layer without consensus modification? (Section 3 and Section 4.3.6).
• RQ2. How closely does the DBM rehash overhead track the theoretical $O\left(\sqrt{N}\right)$ bound on commodity hardware? (Section 4.3.8 and Section 4.4.1).
• RQ3. Under realistic IAM workflows, what is the throughput and tail-latency cost of the DBM backend, and how does the deployment behave at the concurrency break-point? (Section 4.3.4 and Section 4.3.5).
• RQ4. Within a documented threat model, which adversary classes does the design defeat, which does it admit, and at what residual cost? (Section 3.3.3, Section 5.1 and Section 5.5).

The remainder of this paper presents the background and related work in Section 2, the proposed integration architecture in Section 3, experimental evaluation in Section 4, discussion in Section 5, and conclusions in Section 6.

2. Background and Related Work

This section presents the foundational concepts and existing approaches relevant to privacy-compliant blockchain systems. The analysis covers current compliance approaches, the NIST DBM architecture that forms the basis of the proposed solution, and related work in blockchain-based privacy preservation.

2.1. GDPR Compliance Challenges in Blockchain Systems

The fundamental conflict between blockchain immutability and GDPR requirements has been extensively documented in the literature [24,25]. Traditional approaches to addressing this challenge have relied on off-chain storage solutions or hybrid architectures that compromise either the integrity guarantees of blockchain or the comprehensiveness of privacy protection. These solutions often introduce additional complexity, potential points of failure, and may not fully satisfy regulatory requirements in complex cross-organizational scenarios requiring frequent data modifications.

2.2. European Blockchain Services Infrastructure

The European Blockchain Services Infrastructure (EBSI) represents the EU’s initiative to deploy blockchain technology across public services while maintaining GDPR compliance [26]. EBSI operates as a permissioned network spanning 27 EU Member States plus Norway and Liechtenstein, with approximately 40 nodes distributed across Europe. The infrastructure utilizes Hyperledger Besu with Quorum Byzantine Fault Tolerance (QBFT) consensus mechanism and Proof of Authority (PoA), achieving energy efficiency with an average consumption of 100 Wh per node [27]. The architecture of Hyperledger Besu is presented in Figure 1.

QBFT is a consensus protocol designed to ensure reliability and consistency in permissioned blockchain systems, even in the presence of malicious or faulty nodes [28]. Built on the foundational principles of Byzantine Fault Tolerance, QBFT enables distributed networks to reach agreement on the state of a blockchain by requiring a minimum of $3f+1$ validators to tolerate up to f Byzantine faults. The protocol follows a structured round-based approach consisting of three phases, namely, propose, prepare and commit, during which a designated proposer suggests a block that must be validated by a quorum of at least $2f+1$ nodes. If consensus is not achieved, typically due to a faulty or unresponsive proposer, the system automatically initiates a view change, selecting a new proposer to maintain liveness and ensure eventual agreement [28].

EBSI’s technical architecture employs an 8 s block time and 20 M gas limit per block to accommodate the pan-European network’s synchronization requirements. The system implements specialized smart contracts, including the DID Registry for Decentralized Identifiers (DIDs), the Trusted Issuers Registry for issuer verification and the Trusted Schemas Registry for schema validation, all designed to enforce GDPR compliance through automated verification processes [29].

The critical innovation lies in EBSI’s hybrid approach to data privacy: personal data is stored off-chain in secure databases while only cryptographic hashes and encrypted references are maintained on-chain. This architecture enables GDPR-compliant data deletion while preserving blockchain integrity through hash associations. Smart contracts encode GDPR rules directly into the system, maintaining immutable audit trails while ensuring user consent remains explicit, traceable, and revocable [27,29]. Despite these advances, EBSI’s reliance on off-chain storage introduces potential points of failure and complicates verification processes, while the hybrid architecture may not fully address all GDPR requirements in complex cross-organizational scenarios requiring frequent data modifications.

Table 1. Comparison of DBM and EBSI approaches.

Characteristic	DBM Approach	EBSI Approach
Data Location	On-chain (matrix)	Off-chain + hashes
True Deletion	Yes	Partial (off-chain only)
Verification	Single system	Multiple systems
Complexity	$O\left(\sqrt{N}\right)$	$O\left(1\right)$ lookup, $O\left(N\right)$ audit
Write TPS	80.5–101.6 (1 M)	∼125 (estimated)
GDPR Compliance	Architectural (on-chain deletion)	Architectural (off-chain)

compares the proposed DBM approach with EBSI’s hybrid architecture across key dimensions. The DBM approach offers stronger GDPR compliance guarantees through true on-chain deletion, while EBSI’s hybrid approach provides higher write throughput at the cost of architectural complexity and partial compliance.

2.3. NIST Data Block Matrix Architecture

The NIST developed the DBM as outlined in their Cybersecurity White Paper (CSWP) 25 [21]. This approach addresses the fundamental conflict between blockchain’s immutability and privacy regulations by introducing a two-dimensional matrix structure that maintains hash-based integrity protection while enabling controlled data deletion. Roberts et al. [22] subsequently implemented the DBM as a configurable option for Hyperledger Fabric, demonstrating proof-of-concept applications in healthcare data sharing and pharmaceutical supply chain scenarios. However, comprehensive performance characterization across varying scales and IAM-specific implementation details were not addressed in the prior work, motivating the present study.

The DBM replaces the traditional linear blockchain architecture with a matrix-based approach where data blocks are organized in a two-dimensional grid [21]. Each block in the matrix is protected by dual hash chains, one for its row and one for its column, creating redundant integrity-verification paths [21]. This dual-hash mechanism ensures that when a specific block is deleted, the integrity of all other blocks in the matrix remains verifiable through alternative hash chains. A visual representation of the DBM deletion mechanism is shown in Figure 2.

2.3.1. Mathematical Foundation

The DBM structure maintains several mathematically proven properties that ensure effectiveness for privacy-compliant applications. The balance property ensures that cells are filled in a balanced manner, with the upper half (above diagonal) containing at most one additional cell more than the lower half. The hash chain length property guarantees that the number of blocks in a row or column hash chain is proportional to $\sqrt{N}$ for a matrix with N blocks, providing efficient verification performance [21].

The block dispersal property ensures that no consecutive blocks appear in the same row or column, distributing data across the matrix to minimize the impact of any single deletion operation. This distribution pattern, combined with the dual-hash protection mechanism, constitutes a robust system where individual block deletion does not compromise the integrity verification of remaining data [21].

The DBM follows a specific construction algorithm that maintains the following loop invariant:

$$(i<j\wedge \mathrm{odd}\left(B_{i,j}\right))\vee (i>j\wedge \mathrm{even}\left(B_{i,j}\right))$$

(1)

where i and j are row and column indices, and $B_{i,j}$ represents the block number at position $(i,j)$ [21].

For efficient block retrieval, the DBM employs mathematical formulas to locate blocks within the matrix structure. For even-numbered blocks (lower half),

$$i=\lfloor \sqrt{B}\rfloor +[B>\lfloor \sqrt{B}\rfloor (\lfloor \sqrt{B}\rfloor +1)]$$

(2)

$$j={\displaystyle \frac{B-(i^2-i+2)}{2}}$$

(3)

For odd-numbered blocks (upper half),

$$j=\lfloor \sqrt{B+1}\rfloor +[B\ge \lfloor \sqrt{B+1}\rfloor (\lfloor \sqrt{B+1}\rfloor +1)]$$

(4)

$$i={\displaystyle \frac{B-(j^2-j+1)}{2}}$$

(5)

where $\left[\epsilon \right]$ is the Iverson bracket: $\left[\epsilon \right]=1$ if expression $\epsilon$ evaluates to true, and 0 otherwise [21].

The total number of data blocks in an $N\times N$ matrix is

$$\mathrm{Total}\mathrm{Blocks}=N\times (N-1)$$

(6)

This accounts for the null diagonal elements that are essential for the DBM’s integrity preservation properties [21].

2.3.2. Hash Computation

For row i, the hash is computed as

$$H_{i,-}=\mathcal{H}(\mathcal{H}\left(B_{i,0}\right)\parallel \mathcal{H}\left(B_{i,1}\right)\parallel \dots \parallel \mathcal{H}\left(B_{i,N-1}\right))$$

(7)

For column j, the hash is computed as

$$H_{-,j}=\mathcal{H}(\mathcal{H}\left(B_{0,j}\right)\parallel \mathcal{H}\left(B_{1,j}\right)\parallel \dots \parallel \mathcal{H}\left(B_{N-1,j}\right))$$

(8)

where $\mathcal{H}$ represents the hash function and ‖ denotes concatenation [21]. Note that diagonal elements (where $i=j$) are null and excluded from hash computations to preserve integrity after deletion operations.

2.4. Related Work in Blockchain Privacy

2.4.1. GDPR Compliance Approaches

Several research efforts have addressed the fundamental tension between blockchain immutability and privacy compliance requirements. Kuperberg [30] proposed a tree-based ledger architecture using context chains with simultaneous validity, enabling consensus-steered deletion of entire contexts while maintaining decentralization and cryptographic integrity. Godyn et al. [31] conducted a comprehensive analysis of GDPR compliance solutions for permissioned blockchains, implementing and evaluating the Reference-based Tree Structure (RBTS) approach that enables data deletion requiring only data owner consent.

Gonçalves et al. [32] developed Olympus, a GDPR-compliant blockchain system combining Hyperledger Fabric with IPFS for off-chain storage. Their hybrid approach stores personal data off-chain while maintaining cryptographic references on-chain, enabling Right to be Forgotten compliance through data deletion in the distributed file system. While effective, this approach introduces additional infrastructure complexity and potential points of failure compared to on-chain solutions.

2.4.2. Redactable Blockchain Mechanisms

A comprehensive survey by Abd Ali et al. [33] categorizes redactable blockchain approaches into chameleon hash-based and non-chameleon hash-based methods. Chameleon hash functions, originally introduced by Krawczyk and Rabin [23], enable collision computation with trapdoor keys, allowing block modification without disrupting the hash chain. Zhang et al. [34] proposed a Dynamic Attribute-Based Chameleon Hash (DACH) scheme enabling decentralized, dynamically redactable blockchains where network participants can securely join and leave without creating single points of failure.

However, chameleon hash approaches require specialized hash functions and complex key management outside conventional blockchain operations [33]. In contrast, the DBM architecture enables data deletion using standard SHA-256 hash functions, providing a more practical integration path with existing enterprise blockchain deployments without requiring fundamental cryptographic modifications.

2.4.3. Blockchain-Based Access Control

Blockchain technology has been extensively explored for access control systems. Cruz et al. [35] presented RBAC-SC, a foundational framework implementing Role-Based Access Control using Ethereum smart contracts, enabling trans-organizational role verification without centralized certificate authorities. NIST published comprehensive guidance on blockchain access control systems [12], examining how blockchain properties such as decentralization, tamper-resistance, and auditability can address traditional access control challenges.

Recent research on Self-Sovereign Identity (SSI) demonstrates growing interest in blockchain-based identity management [36]. Pava-Díaz et al. analyzed nine prominent SSI frameworks, including Sovrin, uPort, and KILT, evaluating their compliance with digital identity principles. Privacy-preserving audit logs represent another critical research area; Thazhath et al. [37] proposed Harpocrates, combining blockchain with zero-knowledge proofs to enable immutable audit logging without leaking sensitive information, tested on Hyperledger Fabric.

In parallel application domains, Hong et al. [38] developed OCHJRNChain, a blockchain-based privacy-preserving data sharing framework for transportation systems using hash XOR trees for selective disclosure. Their work on attribute-based encryption for secure access control was extended to healthcare in [39], combining blockchain with chameleon hash functions to enable patient-controlled EHR access while supporting regulatory compliance. These approaches demonstrate the breadth of blockchain privacy solutions across application domains.

These works collectively highlight the broader trend toward developing blockchain solutions that balance transparency with privacy requirements. However, most existing approaches modify the fundamental blockchain structure, require complex consensus modifications, or introduce off-chain storage dependencies. The DBM architecture uniquely provides true on-chain data deletion while maintaining integrity through its dual-hash matrix design, offering a more practical integration path with existing enterprise blockchain frameworks such as Hyperledger Fabric [22].

In summary, existing GDPR-compliant blockchain approaches fall into three categories: (1) off-chain storage with on-chain hashes (EBSI and Olympus), which introduces architectural complexity and additional failure points; (2) chameleon hash-based redactable blockchains, which require specialized cryptographic primitives and complex key management; and (3) structural modifications to the ledger (tree-based [30] and RBTS-based [31]), which require significant consensus changes. The DBM approach occupies a distinct position by enabling on-chain deletion using standard SHA-256 hashing without consensus modifications. The present work extends the proof of concept by Roberts et al. [22] with empirical performance validation at enterprise scale and IAM-specific chaincode, including security analysis of the deletion mechanism and direct microbenchmark comparison against a chameleon hash implementation (Section 6).

3. Proposed DBM-Hyperledger Fabric Integration

This section presents the proposed integration architecture, focusing on the modifications required to enable DBM functionality within Hyperledger Fabric and the custom chaincode implementation for IAM systems.

3.1. Integration Architecture

The integration of the DBM with Hyperledger Fabric is a practical step towards privacy-preserving Distributed Ledger Technology (DLT). Hyperledger Fabric was selected as a suitable platform for DBM integration because of its permissioned network architecture and enterprise-grade features. The integration required additive modifications to the Hyperledger Fabric codebase, focused on the block-storage module to preserve drop-in compatibility.

The DBM implementation maintains the existing Hyperledger Fabric Application Programming Interface (API) structure, allowing current applications to function without modification while extending functionality to support privacy-compliant operations. The system is configurable at the channel level, enabling organizations to choose between conventional blockchain or block matrix storage on a per-channel basis. This flexibility allows mixed deployments where some channels utilize traditional blockchain immutability while others employ the DBM for privacy-sensitive applications. An architectural overview of this integration is illustrated in Figure 3, highlighting the compatibility.

The DBM implementation within Hyperledger Fabric utilizes the existing block structure while modifying the storage organization to follow the matrix pattern. Each Hyperledger Fabric block contains a header and data section, with the data section containing transactions represented as read–write sets operating on key–value pairs. The DBM modification reorganizes these blocks according to the matrix algorithm while maintaining compatibility with existing Hyperledger Fabric consensus mechanisms.

The implementation supports dynamic matrix expansion, automatically increasing capacity as new blocks are added to the system. This feature ensures that the DBM can accommodate growing datasets without requiring system reconfiguration. The block location algorithms enable retrieval of specific blocks within the matrix structure, maintaining performance characteristics comparable to traditional blockchain implementations.

3.2. Custom Chaincode Implementation for IAM Systems

For IAM systems, a custom chaincode implementation was developed that leverages the DBM’s erasure capabilities while providing comprehensive access control mechanisms. The implementation incorporates both RBAC and ABAC patterns, creating a flexible system that can adapt to various organizational requirements.

The custom chaincode architecture consists of three primary components: identity management functions, access control enforcement mechanisms, and audit trail management. The identity management functions handle user registration, authentication, and profile management while ensuring that personal data can be deleted upon request. The access control enforcement mechanisms implement both RBAC and ABAC policies, allowing organizations to define granular access controls based on user roles, attributes, and contextual factors.

The RBAC component establishes fundamental permissions through organizational roles, namely, managers, auditors and data privacy officers, each with distinct system capabilities. Asset lifecycle management follows a structured validation process: managers can create new assets and allocate block matrix space, while updates require ownership verification or managerial override. Auditors access assets within their departmental scope, maintaining organizational boundaries.

The RBAC/ABAC design combines established enterprise IAM patterns (attribute-based authorization, deny-overrides conflict resolution) with non-obvious properties that are specifically required for operation on an erasure-capable ledger, and that prior blockchain-RBAC proposals such as Cruz et al. [35] or the general-purpose enforcement engines referenced in Section 2 do not supply. Six design properties differentiate the layer from textbook enterprise IAM frameworks and constitute the principal methodological contributions of this work:

• (i) Erasure-aware role layering.

Managers may perform logical deletion (which preserves audit evidence on the ledger), whereas DPOs may invoke cryptographic erasure, which in turn triggers matrix rehashing at the block-storage layer. No previous RBAC encoding in a Fabric chaincode distinguishes these two semantically different delete operations.

The distinction is not merely a permission-level refinement. Traditional IAM treats deletion as credential revocation or logical record marking: the access right is withdrawn, but the personal datum and the binding trace remain in the underlying data store [13,14]. GDPR Article 17 requires removal of the personal datum itself, which Politou et al. identify as the fundamental tension with blockchain immutability [24]. The DBM primitive proposed by Kuhn [21] closes the gap at the data layer but only if the chaincode above it exposes a deletion path that invokes it. Our role layering distinguishes (a) suppression of the access right (manager role, leaves the datum in place, and preserves the access trail) from (b) cryptographic erasure of the datum from the matrix cell (DPO role, triggers rehashing, and leaves only the non-personal audit record). Without this separation an IAM system on a DBM-enabled Fabric would either over-delete on every manager-level revoke or under-delete and reduce the DBM to a more expensive append-only chain. The combination of the two roles is the system-level capability that conventional IAM stacks cannot provide because they lack a deletion primitive at the ledger layer.

• (ii) Two-layer non-deletable audit namespace.

Audit records are protected by two independent code paths, the chaincode-level protectAuditNamespace guard and the block-storage-level isNonErasable predicate so that compromise of one layer cannot silently remove the record that a deletion occurred. This is empirically validated against 200 adversarial key-variant probes (Section 3.3).

• (iii) Formally defined five-factor risk score.

The ABAC risk gate is computed from five normalized environmental factors via the closed-form expression given below, rather than delegated to an opaque external risk engine. Algorithm 3 exposes the formula as concrete pseudocode (procedure CalculateRiskScore), making the implementation reproducible.

• (iv) Deny-overrides conflict resolution with explicit priority.

Policies are stored as JSON documents with fields id, resource, action, effect $\in \{$ALLOW, DENY}, priority, and conditions[] (each condition an (attribute, operator, value) tuple). The conflict resolver evaluates policies in priority order, and at equal priority DENY dominates ALLOW. A minimal example policy is

{“id”:“pol-phi-eu-hr”,“resource”:“asset:phi”,“action”:“read”,

“effect”:“ALLOW”,“priority”:10,

“conditions”:[{“attribute”:“department”,“operator”:“eq”,“value”:“hr”},

“conditions”:[{“attribute”:“geo”,“operator”:“in”,“value”:“EU”}]}

• (v) Single-pass RBAC+ABAC evaluation.

The hot-path authorize() helper performs one range scan of the caller’s bindings and inline-evaluates both role permissions and attribute conditions, eliminating the dual-scan cost that dominated the per-invoke chaincode latency in an early prototype. This is a chaincode-level optimization unavailable to policies implemented outside the execution environment.

• (vi) Integrated rate-limited erasure.

The time-bucketed sliding-window rate limiter (checkRateLimit) is part of the RBAC enforcement layer, not a separate middleware component, so rate decisions are made within the same transaction that authorizes the erasure; the counter is per-identity, per-minute bucketed over a 5 min window and is empirically validated by the dose–response sweep in Section 3.3.

The deletion mechanism represents the most sophisticated RBAC feature, distinguishing between logical deletion (managers) and complete erasure (data privacy officers). Logical deletion preserves data for compliance purposes, while complete erasure leverages DBM’s unique capabilities to remove data while maintaining blockchain integrity through hash recalculation.

The ABAC framework provides granular policy evaluation by assessing user credentials, asset characteristics, environmental context, and operational parameters. Key features include approval limits that prevent unauthorized access, security clearance validation for classified assets, and geographic access controls for multi-jurisdictional compliance.

The smart contract implementation combines both RBAC and ABAC evaluations for comprehensive security assessment. The risk score referenced in Algorithm 3 is computed as

$$R=0.25·min\left({\displaystyle \frac{f}{5}},1\right)+0.20·u+0.15·\sigma \left(t\right)+0.25·g+0.15·min\left({\displaystyle \frac{s}{3}},1\right)$$

where f is the number of recent failed authentication attempts (normalized to $[0,1]$ with saturation at 5), $u\in \{0,1\}$ indicates an unusual access pattern, $\sigma \left(t\right)=1/(1+e^{-0.1(t-48)})$ is a sigmoid function of hours since last access (centered at 48 h), $g\in \{0,1\}$ indicates access from a new geographic location, and s is the number of concurrent sessions (normalized with saturation at 3). The maximum allowed risk threshold is configurable per operation type (default 0.7), with deletion operations requiring the lowest threshold. Policy conflicts are resolved using a deny-overrides strategy: policies are evaluated by priority ordering, and in case of equal priority, DENY takes precedence over ALLOW. As a worked example, consider a user with 2 failed attempts, no unusual pattern, and 12 h since last access, accessing from a known location, with 1 concurrent session: $R=0.25\times 0.4+0.20\times 0+0.15\times 0.027+0.25\times 0+0.15\times 0.333=0.154$, which falls well below the 0.7 threshold and permits access. The implementation maintains detailed audit trails that capture access decisions without retaining personal data subject to deletion requirements, enabling compliance demonstration even after privacy rights exercise.

Audit records are stored in a separate key namespace (prefix audit:) and protected from erasure by two independent layers; the design is intentionally defense-in-depth because each layer closes a distinct adversary class from Section 3.3.3.

Layer 1 (chaincode guard protectAuditNamespace) intercepts every DelState call whose key carries the audit: prefix and rejects it before commit. It blocks adversary classes A1 (external), A2 (authenticated non-admin) and A4 (compromised DPO) on the audit-removal path since all three reach the ledger through the chaincode API. Layer 1 cannot block A3 (compromised peer-admin with offline block-store access).

Layer 2 (block-storage predicate isNonErasable) is evaluated in the DBM rewrite path and skips any key resolving to the audit: prefix. It is the only enforcement point that survives a chaincode-runtime compromise and so is the one that blocks A3 (and any future class with direct block-store write access). Layer 2 cannot block A1/A2/A4 in isolation since by the time A3-style manipulation is in play the chaincode guard has been bypassed; the two layers are complementary, not redundant.

A single-layer design is therefore insufficient on either side: a chaincode-only guard leaves the offline-storage attack open (closed by Layer 2), and a block-storage-only check leaves the runtime bypass open (closed by Layer 1 before commit). Audit records are accordingly non-deletable across the full chaincode-to-storage stack; the cross-layer surface (A2 + A3 collusion) requires simultaneously compromising both layers. Validation: (i) the rogue-CA adversary (A5), discussed in Section 3.3.3, was rejected by Layer 1 because the CA-signed admin identity lacked the required state-DB binding, and (ii) a 200-variant audit-namespace sweep found no externally reachable chaincode function able to write to the audit: namespace. Each audit entry captures operation type, actor, target, timestamp, decision (ALLOW/DENY) and a SHA-256 hash of the pre-deletion data; it does not retain the personal data itself, consistent with European Data Protection Board (EDPB) guidance on accountability records [9].

The detailed algorithmic implementations of these mechanisms are presented in Appendix A, including Algorithm A1 for RBAC authorization, Algorithm A2 for ABAC policy evaluation, and Algorithm A4 for the integrated IAM smart contract. These algorithms represent conceptual implementations; production deployments would require additional integration with Hyperledger Fabric’s Membership Service Provider infrastructure and organization-specific policy configurations.

Risk-Score Parameter Sensitivity and Cross-Industry Validation

The five-factor risk score is probed along three axes ($N=$ 10,000 Monte-Carlo actor draws, no chaincode invocations needed): coefficient sensitivity (

Table 2. Coefficient sensitivity of the five-factor risk score. Each coefficient is perturbed by the stated percentage while the other four are held at their defaults; the entry is the fraction of $N=$ 10,000 Monte-Carlo actor draws (uniform mixed-actor population) whose ALLOW/DENY decision at the default threshold $R_0=0.50$ flips relative to the unperturbed score. Smaller is more robust.

Coefficient (Default)	$-25\%$	$-10\%$	$+10\%$	$+25\%$
a (failed auth, 0.25)	8.43%	2.88%	2.50%	5.61%
b (unusual access, 0.20)	3.84%	1.52%	1.50%	3.29%
c (recency sigmoid, 0.15)	3.99%	1.50%	1.51%	3.68%
d (geo, 0.25)	1.80%	0.52%	0.34%	0.77%
e (sessions, 0.15)	5.09%	2.00%	1.92%	4.39%

), threshold robustness (

Table 3. Threshold robustness of the five-factor risk score. ALLOW and DENY rates and false-allow/false-deny rates are reported for four candidate thresholds against a synthetic ground truth that classifies the top 30% of the population by true score as “should deny”. The default operating point $R_0=0.50$ corresponds to a near-balanced false-positive/false-negative trade-off.

Threshold	ALLOW Rate	DENY Rate	False-Allow	False-Deny
$R_0=0.35$	4.8%	95.2%	0.00%	65.21%
$R_0=0.50$	21.1%	78.9%	0.00%	48.93%
$R_0=0.65$	50.6%	49.4%	0.00%	19.36%
$R_0=0.80$	77.7%	22.3%	7.69%	0.00%

) and cross-industry distributions (

Table 4. Cross-industry validation of the risk score. Each row instantiates the same closed-form expression with an industry-appropriate factor distribution; the score quartiles (Q1, median, and Q3) and the resulting DENY rate at the default threshold $R_0=0.50$ illustrate that the formula generalizes across operating regimes without parameter redefinition. The DENY rate is lowest in the healthcare population (mostly trusted clinicians) and highest in the financial population (high baseline anomaly rate).

Industry Preset	Q1 Score	Median	Q3 Score	DENY at ${\mathit{R}}_0=0.50$
Healthcare (ALLOW-by-default)	0.105	0.145	0.197	0.4%
Financial (DENY-by-default)	0.405	0.494	0.606	48.4%
Government (tiered)	0.121	0.396	0.653	43.9%

). Median decision-flip rate at $\pm 10\%$ coefficient perturbation stays below 2% across all five coefficients (geographic factor is most robust, failed-authentication most sensitive), which supports field re-tuning by small amounts without destabilizing the decision boundary. The default operating point $R_0=0.50$ is conservative by design (zero false-allow, 48.9% false-deny against a synthetic “top-30% should deny” ground truth). The same closed-form expression yields industry-appropriate medians (healthcare∼0.27, financial∼0.43, government near $R_0$), confirming that the operating point rather than the coefficients is the per-deployment tuning knob.

3.3. Security Analysis

The integration of data deletion capabilities into a blockchain system introduces potential security considerations that must be carefully addressed [9]. This subsection analyzes the security implications and countermeasures implemented in the proposed architecture, drawing on established frameworks for privacy-preserving audit systems [37,40].

3.3.1. Deletion Authorization Security

The DBM architecture implements strict authorization controls for deletion operations. Only designated Data Privacy Officers with appropriate credentials can execute complete erasure operations. This role separation ensures that:

• Regular users cannot delete data to hide malicious activities.
• Managers can only perform logical deletions that preserve audit metadata.
• Complete erasure requires documented justification and request tickets.
• All deletion attempts are logged in tamper-evident audit trails.

3.3.2. Audit Integrity Preservation

A critical concern is whether malicious actors could exploit erasure capabilities to compromise audit integrity [37]. The DBM implementation addresses this through mechanisms similar to privacy-preserving audit log systems [40]:

• Separation of audit and data layers: Audit metadata (timestamps, actor identities, operation types) is stored separately from personal data and is not subject to deletion, following the pattern established by Harpocrates for sensitive data operations [37].
• Hash chain continuity: Even after block deletion, the row and column hash chains maintain cryptographic proof of the deletion event.
• Multi-party verification: Deletion operations require endorsement from multiple peers before execution, consistent with EDPB guidance on blockchain processing [9].

3.3.3. Threat Model and Attack Vector Analysis

The introduction of erasure capabilities into the blockchain architecture expands the attack surface compared to traditional immutable ledgers.

Table 5. Formal threat model for DBM erasure capabilities. Compact form; detailed validation methodology is given in the paragraph following the table and in the cited benchmark artifacts.

Attack	Preconditions	Cost	Countermeasure (Summary)	Validation Outcome
Selective history rewriting	Compromised DPO credentials	High	Non-deletable audit namespace; GDPR ticket validation; multi-peer endorsement	Audit persistence + hash-chain integrity verified
Mass deletion DoS	Authenticated user with delete permission	Low	RBAC DPO-only erasure; 10/5 min sliding-window rate limiter on execute path; endorsement policy. Gap: counter is incremented inexecuteDeletiononly, not inRequestDeletion; with default DeletionQuorum $\ge 2$ and high-concurrency MVCC contention, short bursts may transiently bypass the limit until the first counter-bearing transaction commits (see Section 5.2).	Dose–response sweep: 5 accepted at B = 5; 5 accepted + 10 blocked at B = 15; 0 accepted at B ≥ 50 (on the execute path)
Collusion attack	Multiple compromised orgs	Very high	Cross-org endorsement policy; TLS mutual auth	Quorum matrix: $f=1$ → ENDORSEMENT_POLICY_FAILURE; $f\ge 2$ → commit
Role escalation	Lower-privilege valid credentials	Low	Attribute-based identity via Fabric MSP; role in X.509 cert	All non-DPO erasure attempts rejected by chaincode RBAC
Compromised DPO (A4)	Stolen DPO signing key (1 org)	Medium	Multi-org endorsement policy required	Under OR(...): commits. Under OutOf(2,...): rejected
Rogue CA (A5)	CA root compromise (1 org)	Very high	Chaincode RBAC binding in state DB required beyond MSP acceptance	Rogue cert: MSP-accepted, RBAC-rejected (“lacks asset:write”)
Timing side channel	Unauthorized invoke + latency observation	Low	Chaincode-level constant-time padding applied; structurally insufficient	Pre-/post-patch: $r_{rb}=-1.0000$, $p<{10}^{-60}$; deterministic binary oracle

formalizes the threat model, defining attack vectors, preconditions, estimated costs, implemented countermeasures, and validation approach for each threat. Figure 4 visualizes the mass-deletion DoS dose–response sweep, Figure 5 renders the quorum-matrix outcome across all $(f,\mathrm{signers})$ combinations, and Figure 6 shows the deterministic-oracle separation between the existing- and non-existent-asset invoke latencies.

The security-validation harness implements each attack scenario programmatically. (1) The mass-deletion DoS sweep was run as a dose–response experiment rather than a single point: bursts of $\{5,15,50,100,250\}$ deletion requests were issued after a rate-limit state reset, and the acceptance ratio was recorded per burst. Below the limit (burst $=5$) all requests succeeded; at and above the limit (burst $\ge 50$), all were blocked by the time-bucketed rate limiter. Figure 4 summarizes the complete curve.

(2) The quorum-matrix sweep, executed against a 3-organization local testbed with a committed OutOf(2, Org1MSP.member, Org2MSP.member, Org3MSP.member) signature policy, enumerated all $(f,\mathrm{signers})\in \{1,2,3\}$ combinations and recorded that the committed outcome was exactly VALID when $f\ge 2$ and ENDORSEMENT_POLICY_FAILURE when $f<2$, matching the theoretical Byzantine-quorum bound. (3) A 330-variant fuzz sweep of malformed JSON against AssignRole, CreatePolicy and DeleteAssetErasure returned zero RBAC/ABAC bypasses; 23 variants were accepted, but all landed in namespaces reachable only via existing admin authority and did not corrupt or impersonate audit records. (4) A 200-variant audit-namespace sweep confirmed that no externally reachable chaincode function writes to the audit: namespace; all variants either landed in the asset: prefix (namespace isolation) or were rejected. (5) The A4 compromised-DPO experiment shows a policy-dependent defense: single-org endorsement permits the attack, while 2-of-3 endorsement rejects it. (6) The A5 rogue-CA experiment shows that CA root compromise alone does not suffice to impersonate an admin because the chaincode RBAC layer requires a state-DB binding that only an existing admin can authorize. (7) A deliberate timing side-channel probe of the DeleteAssetErasure reject path revealed a statistically significant 103 ms latency gap between existing and non-existent target identifiers (Mann–Whitney U test, $p<{10}^{-60}$); this identifies a future-work item for constant-time padding.

The safety of the two-phase deletion protocol was additionally verified formally. A TLA+ specification models the ACTIVE →REQUESTED→APPROVED→ ERASED state machine with actions RequestDeletion, ApproveDeletion and ExecuteErasure. TLA+ Model Checker (TLC) model-checked three safety invariants, namely, quorum enforcement (no ERASED asset has fewer than Quorum distinct approvers), erase-implies-audit (every ERASED asset has a matching audit record) and audit monotonicity (the audit set never shrinks), exhaustively over bounded scopes. At the 3-organization, 2-asset, Quorum = 2 configuration (matching the empirical testbed), TLC searched 484 distinct states with zero counterexamples; at 4-organization, 3-asset, Quorum = 3, TLC searched 274,625 distinct states, again with zero counterexamples.

Collectively, these countermeasures, together with the combined empirical and formal validation, indicate that the introduction of erasure capabilities does not create exploitable pathways for malicious actors to compromise the integrity of audit records at the structural level.

3.4. Performance Optimization Strategies

The DBM implementation maintains performance characteristics comparable to traditional Hyperledger Fabric deployments while providing additional privacy capabilities. The dual-hash verification mechanism does introduce computational overhead, but this impact is offset by the elimination of complex off-chain storage architectures typically required for privacy-compliant blockchain systems.

Performance optimization strategies include parallel hash computation for row and column verification, efficient block location algorithms, and optimized data structures for matrix operations. These optimizations ensure that the DBM can support high-throughput applications while maintaining the integrity guarantees essential for enterprise IAM systems.

3.5. Fabric Core Patches for DBM Compatibility

The prior DBM proof of concept by Roberts et al. [22] introduced the matrix-backed block store but did not address the downstream Fabric subsystems that become critical under sustained multi-organization load: concurrent commit notification, endorsement-plan discovery, identity deserialization, and validator-pool sizing. An integration that runs only under single-organization single-peer conditions is unsuitable as a baseline for the performance and concurrency claims made in Section 4. The present work therefore includes a set of minimal, additive patches to Fabric’s core packages that are necessary for the DBM backend to run correctly and efficiently under concurrent workloads. Each patch is independent, preserves the upstream Fabric API, and was validated against the 3-organization and 20-organization testbeds described in Section 4.1.1. The patches are summarized in

Table 6. Fabric core patches developed for DBM-compatible deployment under concurrent workloads. Path prefix fabric/ omitted; slashes in file paths are marked as break-points to fit the column.

File (Package)	Change and Rationale
common/ledger/blkstorage/blockmatrix_mgr.go	DBM block manager implementing matrix-indexed block storage with row/column hash maintenance. Extends the upstream block manager interface rather than replacing it, so non-DBM channels on the same peer remain unaffected.
common/ledger/blkstorage/blockmatrix_itr.go	DBM-aware block iterator. Under concurrent reader/writer load the original implementation could send on a closed channel during shutdown; the fix loops on retrieveBlockByNumber with a micro-sleep so the iterator yields cleanly when the underlying store is transitioning.
common/ledger/kvledger/kv_ledger.go	Commit-notification subsystem: data channel buffer raised to 1024, and sendCommitNotification releases its lock before the select and installs a defer recover() to survive the send-on-closed-channel race that occurs when a channel is closed concurrently with a commit.
internal/pkg/gateway/commit/statusnotifier.go	Commit-status listener ordering fix: pending listeners now receive their event before they are removed from the map (the removal closes their channel), eliminating the race where a notify on a just-removed listener panicked.
discovery/endorsement/endorsement_cache.go	New LRU cache keyed on (channelID, chaincode-interest hash, membership fingerprint) with a 2 s TTL and 256 entries. Accelerates endorsement-plan lookup for repeated discovery requests from a bursting client, which is characteristic of IAM workloads. Cache is invalidated automatically by a change in the membership fingerprint. Aligned with the aggressive-caching strategy recommended by Thakkar et al. [16].
common/channelconfig/msp_identity_cache.go	New channel-level LRU for deserialized MSP identities. CreateMSPManager now wraps the base MSPManager with a caching manager so repeated submissions from the same identity avoid re-parsing the X.509 material.
core/peer/config.go	Default ValidatorPoolSize raised to runtime.NumCPU() × 4, removing the single-threaded validation bottleneck observed on modern multi-core peers during Phase 2 benchmarks.
sampleconfig/core.yaml	Gateway-service concurrency limit raised to 5000 (peer.limits.concurrency.gatewayService), matching the pipeline concurrency the Phase 2 driver actually drives. The prior default (500) saturated before the commit pipeline and was the first limit encountered under any realistic burst workload.

.

Three of these patches (commit-notification, status-listener, and iterator race) fix concurrency bugs that only surface under sustained multi-organization load; these bugs exist in the upstream Fabric codebase when the DBM backend introduces additional state-transition paths but are not easily surfaced under the single-peer single-channel workloads used by the proof of concept. The remaining four patches (endorsement-plan cache, MSP identity cache, validator-pool size, and gateway concurrency limit) are performance optimizations whose effect is empirically characterized in Section 4. The cumulative result is that the DBM-enabled Fabric peer sustains the IAM workloads reported in Section 4.3.4 and Section 4.3.5 without reaching a correctness or concurrency regression relative to stock Fabric on equivalent non-DBM channels.

4. Experimental Evaluation

4.1. Experimental Setup and Methodology

To evaluate the performance of the DBM-integrated Hyperledger Fabric implementation, benchmarking tests were conducted using Hyperledger Caliper, a widely adopted open-source blockchain performance evaluation framework [41,42]. The analysis encompassed both the core Hyperledger Fabric platform and the integrated DBM layer, enabling a comprehensive view of the system’s behavior. Performance metrics follow the standardized definitions established by the Hyperledger Performance and Scale Working Group [43].

4.1.1. Hardware and Software Configuration

The experimental evaluation was conducted in two phases. Phase 1 utilized a local testbed for data volume scalability validation (100–1,000,000 blocks), while Phase 2 deployed a production-grade multi-organization network for network-level performance characterization.

Phase 1, local scalability testbed. The Phase 1 testbed characterizes DBM primitive and chaincode-level performance using controlled hardware and served as the substrate for the attack-simulation, timing side-channel and concurrency break-point experiments discussed in Section 4 and Section 3.3. Network-scale realism, including cross-region consensus over an 80–100 ms Round-Trip Time (RTT) transatlantic link, was evaluated separately by the Phase 2 20-organization deployment described immediately below (Figure 7, Figure 8, Figure 9 and Figure 10, Section 4.3.6); the reader is referred there for the deployment scope that extends beyond the Phase 1 hardware envelope.

• Compute nodes: 3 virtual machines, each with 4 vCPUs (Intel Xeon at 2.4 GHz) and 16 GB of RAM.
• Storage: SSD-backed storage with a guaranteed 500 IOPS.
• Network: 1 Gbps internal network connectivity.
• Hyperledger Fabric version: 2.4.0 with DBM modifications; Phase 2 (Section 4.3.6) used 2.5.9 peer and orderer images with the equivalent DBM patches applied and deployed through the Hyperledger Bevel operator for Fabric.
• Consensus: Raft ordering service with 3 orderer nodes.
• Peer deployment: 4 peer processes distributed across the 3 virtual machines, with two peers co-located on a single virtual machine to match the endorsement redundancy of a small consortium channel while remaining within the Phase 1 hardware envelope.
• Channel configurations used on the same hardware: (i) A single-organization channel used for the core read/write/delete benchmark, the IAM workflow benchmark (Section 4.3.4), the concurrency break-point sweep (Section 4.3.5) and the data-volume scalability sweep; and (ii) a 3-organization channel carrying an OutOf(2, Org1MSP.member, Org2MSP.member, Org3MSP.member) endorsement policy, used for the attack-simulation sweeps discussed in Section 3.3. The two channels share peers and orderers; they differ only in MSP membership and endorsement policy.

Phase 2—Multi-Organization Cross-Region Deployment: Figure 7, Figure 8, Figure 9 and Figure 10 illustrate the production-grade cross-region topology that backs the network-scale measurements reported in this section. This deployment directly addresses the scalability concern that a single-machine testbed cannot represent enterprise deployments: the network comprises 20 independent peer organizations distributed across two geographic regions, nine Raft orderers (three per orderer organization) across three orderer organizations, and an Istio service-mesh fabric that exercises real cross-region consensus latencies (80–100 ms RTT) rather than loopback-network idealizations.

For legibility the topology is presented across four panels (Figure 7, Figure 8, Figure 9 and Figure 10); each panel is generated declaratively from a separate D2 source [44] rendered with the ELK layout engine and uses the official Kubernetes resource icons [45]. Edge colors are consistent across panels: solid green denotes application-layer traffic (peer joins, chaincode invocation), solid red denotes ordering-service traffic (broadcast/deliver and Raft replication), dashed red is reserved for cross-region links, dashed orange denotes Fabric CA enrolment, dashed purple denotes control-plane reconciliation by the operator, solid blue denotes intra-cluster Istio Server Name Indication (SNI) routing, and dashed teal denotes Persistent Volume Claim (PVC) binding.

Figure 7. Phase 2 topology, panel a: fabric-eu1 application plane (europe-north1). Purple: Bevel operator [46] and Istio ingress-gateway pair. Green: 14 peer StatefulSets (Org1MSP–Org14MSP). Orange: 14 per-org Fabric CA Deployments, paired with the corresponding peer via a dashed enrolment edge. Dashed-red boxes mark cross-figure references to panels b–d. Arrow conventions (colour and dash style) are summarised in the paragraph immediately preceding the four panels and are consistent across panels a–d; the in-figure “Panel a/b/c/d” boxes denote cross-references to the sibling panels in this work.

Figure 7. Phase 2 topology, panel a: fabric-eu1 application plane (europe-north1). Purple: Bevel operator [46] and Istio ingress-gateway pair. Green: 14 peer StatefulSets (Org1MSP–Org14MSP). Orange: 14 per-org Fabric CA Deployments, paired with the corresponding peer via a dashed enrolment edge. Dashed-red boxes mark cross-figure references to panels b–d. Arrow conventions (colour and dash style) are summarised in the paragraph immediately preceding the four panels and are consistent across panels a–d; the in-figure “Panel a/b/c/d” boxes denote cross-references to the sibling panels in this work.

Figure 8. Phase 2 topology, panel b: fabric-eu1 ordering plane. Red: orderer organizations OrdererOrg1 and OrdererOrg3, three Raft replicas each on the dedicated fabric_orderers node pool (n2-standard-8 with 375 GB NVMe local SSD, role=orderer, dedicated=orderer). Teal: per-orderer pd-balanced PVCs for Write-Ahead Log (WAL) and snapshot. Cross-figure boxes refer to panels a (broadcast in), c (cross-region Raft, 80–100 ms RTT) and d (deliver/broadcast on shared CRDs). Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

Figure 8. Phase 2 topology, panel b: fabric-eu1 ordering plane. Red: orderer organizations OrdererOrg1 and OrdererOrg3, three Raft replicas each on the dedicated fabric_orderers node pool (n2-standard-8 with 375 GB NVMe local SSD, role=orderer, dedicated=orderer). Teal: per-orderer pd-balanced PVCs for Write-Ahead Log (WAL) and snapshot. Cross-figure boxes refer to panels a (broadcast in), c (cross-region Raft, 80–100 ms RTT) and d (deliver/broadcast on shared CRDs). Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

Figure 9. Phase 2 topology, panel c: fabric-us1 namespace (us-east1). Same structure as panel a at smaller scale: Bevel operator, Istio ingress, 6 peer StatefulSets (Org15MSP–Org20MSP, green), 6 per-org Fabric CA Deployments (orange), and one Raft-replicated orderer organization OrdererOrg2 (red, 3 replicas) on the orderer node pool. Cross-figure boxes refer to panels a (cross-region SNI), b (Raft replication) and d (channel joins). Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

Figure 9. Phase 2 topology, panel c: fabric-us1 namespace (us-east1). Same structure as panel a at smaller scale: Bevel operator, Istio ingress, 6 peer StatefulSets (Org15MSP–Org20MSP, green), 6 per-org Fabric CA Deployments (orange), and one Raft-replicated orderer organization OrdererOrg2 (red, 3 replicas) on the orderer node pool. Cross-figure boxes refer to panels a (cross-region SNI), b (Raft replication) and d (channel joins). Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

Figure 10. Phase 2 topology, panel d: cluster-scoped channel and persistence layer. Orange: four FabricMainChannel Custom Resource Definitions (CRDs) (iam-global: 20 orgs/9 orderers; iam-eu: 14 EU/6; iam-us: 6 US/3; iam-single: 1/3). Center: IAM chaincode (CCAAS) and configtx ConfigMap. Teal: 20 per-peer pd-balanced PVCs (DBM blockmatrix). Dashed-red boxes on the right collapse inbound traffic from panels a–c. Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

Figure 10. Phase 2 topology, panel d: cluster-scoped channel and persistence layer. Orange: four FabricMainChannel Custom Resource Definitions (CRDs) (iam-global: 20 orgs/9 orderers; iam-eu: 14 EU/6; iam-us: 6 US/3; iam-single: 1/3). Center: IAM chaincode (CCAAS) and configtx ConfigMap. Teal: 20 per-peer pd-balanced PVCs (DBM blockmatrix). Dashed-red boxes on the right collapse inbound traffic from panels a–c. Arrow colour/dash conventions are as defined in the paragraph immediately preceding the four panels.

• Infrastructure: 2 regional Google Kubernetes Engine (GKE) clusters provisioned via Terraform [47]: fabric-eu1 in europe-north1 (Hamina, Finland) and fabric-us1 in us-east1 (Moncks Corner, SC, USA).
• Cluster sizing: Per-cluster regional control plane (GKE-managed, 3 zonal replicas); 5 n2-standard-8 agent nodes per cluster (8 vCPU, 32 GiB RAM, 100 GB pd-balanced boot disk); a dedicated fabric_orderers node pool (2 n2-standard-8 with 375 GB NVMe local SSD, role=orderer label, dedicated=orderer taint) per cluster for orderer low-latency write isolation.
• Fabric network: 20 peer organizations (Org1MSP–Org20MSP) distributed across the two clusters (14 in fabric-eu1, 6 in fabric-us1), 3 orderer organizations with 9 Raft orderer nodes (distributed across both clusters), 20 Certificate Authorities issued from per-org Fabric CAs.
• Network topology: GKE native VPC-scoped pod networking (Google Cloud CNI) within clusters; Istio service mesh for inter-cluster communication via SNI gateway routing between GKE clusters over Google’s private backbone.
• Cross-region latency: europe-north1 (Hamina)–us-east1 (Moncks Corner) measured ∼80–100 ms RTT.
• Channels: iam-global (all 20 orgs, all 9 orderers), iam-eu (14 EU orgs, 6 orderers), iam-us (6 US orgs, 3 orderers), iam-single (1 org, 3 colocated orderers).
• Orderer tuning: maxMessageCount=200, preferredMaxBytes=2 MB, batchTimeout=500 ms.
• State DB: LevelDB (chosen over CouchDB for write throughput).
• Chaincode deployment: External chaincode as a service (ccaas), deployed via an internally modified fork of the Hyperledger Bevel operator for Fabric [46]; modifications include (i) extending the FabricMainChannel Custom Resource Definition (CRD) to map anchor-peer declarations into the configtx.Organization specification (controllers/mainchannel/mainchannel_controller.go), (ii) relaxing FabricIdentity minLength validation on affiliation and enrollment fields, and (iii) copying four missing chaincode-lifecycle CRD manifests into the Helm chart to fix an operator crash loop observed at deployment time.
• Fabric operator: Hyperledger Bevel Operator for Fabric v1.14.0 (forked and modified, see above) [46].

The experimental design included controlled tests aimed at measuring key performance indicators such as transaction throughput, latency, and overall system efficiency across a range of load conditions. The configuration parameters used during the performance benchmarking are summarized in

Table 7. Experimental configuration parameters for performance benchmarking.

Parameter	Range	Description
Transaction Load	2–200 TPS	Transactions per second accepted
Assets	100–1,000,000	Number of data blocks
Workers	2–8	Concurrent worker threads
Test Duration	30–300 s	Duration of each run

.

4.1.2. Performance Metrics

The following metrics were used to evaluate system performance:

TPS, effective throughput:

$$TPS={\displaystyle \frac{T{x}_{succ}}{T_{last\_commit}-T_{first\_commit}}}$$

(9)

where $T{x}_{succ}$ is the number of successful transactions, $T_{last\_commit}$ is the timestamp of the last committed transaction, and $T_{first\_commit}$ is the timestamp of the first committed transaction.

Transaction Send Rate (SR):

$$SR={\displaystyle \frac{T{x}_{succ}+T{x}_{fail}}{T_{last\_accept}-T_{first\_submit}}}$$

(10)

where $T{x}_{fail}$ is the number of failed transactions.

Average Latency:

$$L_{avg}={\displaystyle \frac{{\sum }_{i=1}^n(T_{commi{t}_i}-T_{accep{t}_i})}{n}}$$

(11)

Maximum and Minimum Latency:

$$L_{max}=\underset{i\in [1,n]}{max}(T_{commi{t}_i}-T_{accep{t}_i})$$

(12)

$$L_{min}=\underset{i\in [1,n]}{min}(T_{commi{t}_i}-T_{accep{t}_i})$$

(13)

4.2. Performance Benchmark Results

The performance analysis indicates that the DBM implementation operates within a comparable performance envelope to standard Hyperledger Fabric while additionally supporting on-chain erasure. The measurements are consistent across operation types and load conditions, obtained via systematic benchmarking using Hyperledger Caliper [42]. Detailed performance metrics for the DBM channel are reported in

Table 8. Performance benchmark results for DBM-enabled Hyperledger Fabric at 1,000,000 assets.

Operation	App.-Layer		Chaincode-Layer
	TPS	Lat.	TPS	Lat.
GetAsset (Read)	77.9	0.25 s	91.9	0.21 s
PutAsset (Write)	80.5	0.24 s	101.6	0.19 s
DeleteAsset (DBM)	88.9	0.21 s	101.6	0.19 s
BatchWrite (100/bat.)	1967	0.05 s	2465	0.04 s

App.-layer: end-to-end client invocation; Chaincode-layer: internal processing.

.

4.3. Performance Analysis

The performance analysis highlights the trade-offs between privacy capabilities and system performance:

4.3.1. Read Operations

GetAsset transactions show consistent performance in the DBM implementation. At the application layer, the DBM reached 77.9 TPS with 0.25 s latency; at the chaincode layer, this improved to 91.9 TPS with 0.21 s latency at ${10}^6$ assets. Standard Hyperledger Fabric 2.x reports higher aggregate throughput (up to roughly 2250 TPS after the bottleneck-targeted optimizations described by Thakkar et al. [16] and further characterized by the stochastic performance model of Melo et al. [17,18]). For IAM workloads, where read patterns are typically user authentication and permission lookups rather than bulk data retrieval, the throughput reached by the DBM remains suitable. The $O\left(\sqrt{N}\right)$ matrix-based block-location algorithm offers efficient lookup complexity, confirmed by flat read latency (approximately 17 ms at the chaincode layer and 44 ms at the application layer) from ${10}^3$ to ${10}^6$ assets.

4.3.2. Write Operations

PutAsset operations show the expected trade-off for privacy capabilities. The DBM reached 80.5–101.6 TPS (application layer to chaincode layer) with 0.19–0.24 s latency for individual writes at ${10}^6$ assets, while batch operations reached 1967–2465 TPS, indicating reasonable bulk-processing efficiency. The throughput reduction compared with optimized Hyperledger Fabric baselines (roughly 2250 TPS after endorsement-policy and state-validation optimizations [16], with throughput further sensitive to block size and arrival rate as modeled by Melo et al. [18]) is attributed to

• Dual hash computation: Each write operation requires updating both row and column hash chains, effectively doubling the cryptographic computation.
• Matrix positioning: The block location algorithm adds computational overhead for determining optimal matrix placement.
• Integrity verification: Additional verification steps ensure matrix consistency after each write.

The dual-hash computation overhead grows from roughly 0.004 ms per operation at ${10}^2$ blocks to roughly 0.4 ms at ${10}^6$ blocks, which corresponds to well under 0.01% of total transaction latency at moderate scales and approximately 4% at ${10}^6$ assets. The batch-write capability (1967–2465 TPS) indicates that the DBM remains suitable for bulk-processing scenarios such as periodic audit-log commits or bulk user provisioning.

4.3.3. Delete Operations

The DBM’s GDPR-oriented deletion capability operated at 88.9–101.6 TPS with 0.19–0.21 s latency at ${10}^6$ assets, comparable to read and write operations. Unlike standard Hyperledger Fabric, where “deletion” merely marks records as deleted while preserving the underlying data, the DBM deletion corresponds to an actual erasure of the on-chain value with hash-chain recalculation; standard implementations do not offer an equivalent erasure guarantee regardless of their throughput. It should be noted that full GDPR compliance involves organizational, procedural and technical dimensions beyond on-chain deletion, including key-lifecycle management, log-replica handling across distributed nodes and designation of data-controller responsibilities, which lie outside the scope of the present architectural evaluation.

All three core operations (read, write and delete) reach a consistent performance envelope in the 78–102 TPS range, with sub-second latencies (0.19–0.25 s) at ${10}^6$ assets; this is a balanced system behavior that is suitable for typical IAM workloads. The chaincode-layer measurements are 14–26% above the application-layer measurements, which is consistent with client-side instrumentation accounting for the difference rather than the blockchain fabric itself.

4.3.4. IAM Workflow-Level Performance

Beyond the core read/write/delete primitives, enterprise IAM workloads comprise distinct transactional workflows whose performance characteristics depend on the interplay between chaincode logic and the Fabric Multi-Version Concurrency Control (MVCC) validation.

Table 9. Transaction-level performance for representative IAM workflows. k denotes pipeline endorsement/commit pool size; w denotes sync-mode workers.

Workflow	Concur.	TPS	p99 (ms)	Note
Identity registration (CreateRole)	k = 128	698.1	450	unique IDs per call, scales
Identity registration (AssignRole)	w = 4	10.7	191	bounded by RBAC range-query read-set
Policy creation (CreatePolicy)	k = 128	862.9	398	unique policy IDs
Policy update (UpdatePolicy, 1 admin)	w = 1	8.3	138	hot-key on single policy state entry
Risk scoring (ComputeRiskScore)	k = 128	661.6	652	unique userID per call
Audit query (QueryAuditByAsset)	w = 16	73.9	300	range scan over audit: namespace
Deletion request (reject path)	k = 128	0 (by design)	1655	DoS-defense latency for invalid erasure

summarizes transaction-level measurements for six representative workflows executed against the Phase 1 local testbed (four-peer, single-organization, DBM enabled); Figure 11 renders the same data graphically. For each workflow, the benchmark reports the sustained throughput and the 99th-percentile latency at the concurrency level at which the workflow saturates.

Two properties of these numbers merit emphasis. First, workflows that write unique state keys per invocation (CreateRole, CreatePolicy, and ComputeRiskScore) reach the 600–900 TPS range, well above the baseline point-operation TPS; this is consistent with the DBM rehash not being the dominant cost on the hot path. Second, workflows whose chaincode handlers read a range or touch a shared state key, namely, AssignRole (whose permission check scans the administrator’s binding range) and UpdatePolicy (which writes a single policy key), are bounded by Fabric’s MVCC validation rather than by the DBM overhead. This property is inherited from standard Hyperledger Fabric and applies identically in a non-DBM deployment; we report the numbers transparently so that the reader can separate the DBM-intrinsic cost from the Fabric-intrinsic cost. The single-admin policy-update throughput (8.3 TPS with a $p_{99}$ of 138 ms) is consistent with typical enterprise administrative workload patterns documented in NIST SP 800-63B [12].

The deletion-request reject path (where the request targets a non-existent or unauthorized asset) has a $p_{99}$ of 1655 ms at pipeline concurrency $k=128$, reflecting queueing under full-pipeline load on the 4-peer testbed. This latency characterizes the cost that a mass-deletion DoS attacker incurs per rejected request and complements the rate-limiter validation discussed in Section 3.3.

4.3.5. Concurrency Break-Point Analysis

To characterize the practical concurrency ceiling of a modest DBM-Fabric deployment, we swept the pipeline endorsement/commit pool size k for the PutAsset workflow until the sustained $p_{99}$ exceeded 5000 ms or the per-run error rate exceeded 5%.

Table 10. Concurrency break-point sweep for PutAsset on the 4-peer DBM-Fabric local testbed. Break criterion: sustained $p_{99}>5000$ ms.

k	TPS	p50 (ms)	p95 (ms)	p99 (ms)
8	82.2	139	266	337
16	101.1	210	344	439
32	100.9	374	582	665
48	29.6	561	9106	10,542
64	33.7	732	8869	9167

shows the resulting degradation curve, measured on the Phase 1 testbed after a substantial accumulated ledger state (over 20,000 preceding assets and audit records). Up to $k=32$ the system sustains approximately 100 TPS with $p_{99}<665$ ms. At $k=48$ the commit queue saturates abruptly: throughput drops to 29.6 TPS, and $p_{99}$ climbs past 10 s. The transition is cliff-like rather than gradual, which is the classical signature of a blocked commit pipeline.

Figure 12 visualizes this transition, with TPS (blue, left axis) and $p_{99}$ latency (red, right axis) against pipeline concurrency on a log-2 k-axis; the 5 s $p_{99}$ threshold (dashed gray) is crossed at exactly $k=48$ where the commit-queue saturates.

This concurrency break-point is a property of the ordering service and commit pipeline, not of the DBM rehash, and is consistent with published Fabric scaling behavior [16,18,19,20]. Practical deployments avoid the cliff by either (a) provisioning the commit pipeline for expected peak concurrency, (b) batching writes through higher-level clients, or (c) horizontally scaling to multiple channels.

4.3.6. Multi-Organization Cross-Region Throughput

The Phase 2 20-organization cross-region deployment described in Section 4.1.1 was benchmarked for sustained throughput with realistic geographic distribution. A pipeline-mode workload against 20 peers spread across the two Google Kubernetes Engine (GKE) clusters (europe-north1 and us-east1) sustained 305 TPS over 30,000 transactions with no transaction failures and a $p_{99}$ of 1.82 s end-to-end. This result isolates the cross-region consensus cost (Raft orderer quorum over the ∼80–100 ms RTT transatlantic link) from the DBM rehash cost, which accounts for roughly 4% of transaction time at ${10}^6$ assets. The 305 TPS figure is the aggregate network throughput when all 20 organizations drive the system concurrently; per-organization throughput is correspondingly bounded and is within the range required by typical enterprise authentication workloads (Section 5).

4.3.7. Production Deployment Cost Envelope

To situate the Phase 2 throughput in its infrastructure economics,

Table 11. Estimated monthly cost of the Phase 2 20-organization GKE deployment, derived from Google Cloud list prices [48,49]. Values are rounded to the nearest US dollar; taxes and support tiers excluded.

Component	Quantity	On-Demand (USD)	1-Year CUD (USD)	3-Year CUD (USD)
GKE Standard cluster-management fee	2 regional control planes	146	146	146
n2-standard-8 compute, EU cluster	7 nodes × 730 h	2410	1518	1085
n2-standard-8 compute, US cluster	7 nodes × 730 h	1985	1251	894
Local SSD, orderer node pools	4 nodes × 375 GB × $0.080/GB-mo	120	76	54
pd-balanced peer/orderer PVCs	∼200 GiB across clusters	24	24	24
Cross-region egress (EU↔US)	∼8 GiB/mo at $0.08/GiB	1	1	1
Monthly total		∼4686	∼3016	∼2204
Annual total		∼56,232	∼36,192	∼26,448

reports the monthly cost of the GKE deployment at list-price on-demand, 1-year committed-use discount, and 3-year committed-use discount, computed from Google Cloud published pricing [48,49]. The cost model is transparent and reproducible: 2 regional control planes at the GKE Standard SLA management fee of $0.10/h each; $2\times (5+2)=14$n2-standard-8 agent and orderer nodes across the two clusters (regional list prices $0.4716/h in europe-north1 and $0.3885/h in us-east1 per compute-engine all-pricing [49]); $2\times 2\times 375$ GB of local NVMe SSD attached to the orderer-dedicated node pools; per-cluster persistent-disk volumes for peer ledgers (5 GiB pd-standard per peer × 20 peers, plus 5 GiB per orderer × 9); and cross-region egress on Google’s private backbone for the sustained 305 TPS workload (estimated at ∼3–8 GiB/month based on the observed block-commit traffic).

Two observations follow. First, a production-grade 20-organization cross-region Hyperledger Fabric deployment with DBM privacy extensions runs at roughly $2200–$4700 per month depending on commitment posture; this bracket is an order of magnitude below the cost of a bespoke off-chain IPFS-plus-indexing architecture of comparable availability such as Olympus [32] and is comparable to a small managed Postgres-plus-app deployment serving a single IAM tenant. The DBM privacy layer does not impose a cost penalty at the infrastructure level. Second, the cost curve is dominated (94%) by compute rather than by storage or egress, which means that the correct optimization lever for operators is right-sizing the node pools against measured throughput (Section 4.3.5), not reducing the DBM overhead.

4.3.8. DBM Primitive Cost Decomposition

The end-to-end throughput numbers reported in the preceding subsections measure the DBM primitive as observed through the full Hyperledger Fabric stack (endorsement, ordering, validation, commit, gateway, gRPC). To separate the DBM rehash contribution from Fabric’s accumulated infrastructure cost, we additionally isolated the four core DBM primitives, namely, cell insertion, cell deletion with row/column/matrix rehash, full $O\left(N\right)$ audit and $O\left(\sqrt{N}\right)$ proof-path audit, and measured their cost on the Phase 1 testbed across matrix sizes from $N=100$ to $N=$ 1,000,000 cells arranged as $\sqrt{N}\times \sqrt{N}$. The results are summarized in

Table 12. DBM primitive cost in nanoseconds per operation, measured on the Phase 1 testbed hardware described in Section 4.1.1.

N	Insert	Delete + Rehash	Verify (Full, $\mathit{O}\left(\mathit{N}\right)$)	Verify (Proof, $\mathit{O}\left(\sqrt{\mathit{N}}\right)$)
100	491	530	3577	328
1000	1369	1380	28,100	892
10,000	3781	4018	249,114	2525
100,000	11,396	11,510	2,477,812	7663
1,000,000	37,464	36,075	25,152,931	24,069

.

Least-squares fits of $f\left(N\right)=a\sqrt{N}+b$ over the measured curves give coefficients of determination $R^2=0.9998$ (insert), $0.9999$ (delete+rehash) and $0.99999$ (verify-proof), which are consistent with the theoretical $O\left(\sqrt{N}\right)$ complexity at the resolution of the measurement. The verify-full operation, which by construction touches every cell, fits a linear model with $R^2=0.999998$ and is reported as the worst-case audit baseline. At $N=$ 1,000,000 the delete-and-rehash primitive costs on the order of 36 $\mathsf{\mu }$, whereas the end-to-end invoke latency observed through the Fabric stack is on the order of 10 ms; this suggests that Fabric endorsement, ordering and commit account for the bulk of the per-transaction cost and that the DBM primitive is unlikely to be the practical bottleneck in this regime. Figure 13 plots the four primitive operations on a log–log scale alongside their fitted models.

For context, a chameleon-hash redaction primitive (P-256 with the Krawczyk–Rabin construction [23]) measured on the same testbed costs on the order of $7\times {10}^4$ ns per redaction at a 10-cell row, compared with roughly $2\times {10}^2$ ns per operation for the corresponding DBM deletion. The relative cost is reported here as a rough indication rather than a precise ratio since the two primitives implement different threat models (unconditional erasure for the DBM versus trapdoor-based redaction with additional key-management assumptions for chameleon hashes); the comparison should be read alongside the qualitative trade-offs discussed in Section 2.

4.4. Scalability Analysis

The scalability analysis validates the DBM’s theoretical $O\left(\sqrt{N}\right)$ complexity through empirical measurement.

Table 13. Scalability analysis across different asset counts.

Assets	Application Layer		Chaincode Layer
	TPS	Lat. (ms)	TPS	Lat. (ms)
1000	21.1	47.3	54.7	18.3
10,000	23.1	43.4	54.0	18.5
50,000	22.7	44.1	58.6	17.1
100,000	22.6	44.2	58.6	17.1
250,000	22.8	43.8	58.2	17.2
500,000	22.9	43.6	58.2	17.2
1,000,000	22.8	43.9	57.5	17.4

presents results across multiple asset scales, while extended benchmarks up to 1,000,000 blocks were conducted to validate the hash complexity claims.

Table 13 reports a single-client, sequential measurement; it is the appropriate view for verifying that per-operation latency is independent of dataset size. With this measurement, both layers exhibit flat latency across ${10}^3$ to ${10}^6$ assets, which is consistent with the DBM’s $O\left(\sqrt{N}\right)$ complexity. The application-layer latency remains at approximately 44 ms, while the chaincode-layer latency is approximately 17 ms; the 2.5× difference is attributable to client instrumentation. Table 8 earlier reported a different measurement regime, namely, 20 concurrent workers driving the network in parallel, which produces higher aggregate TPS (77.9–91.9 for reads, 80.5–101.6 for writes and 88.9–101.6 for deletes) at the cost of per-request queueing latency on the order of 0.19–0.25 s. The two views are complementary and, by Little’s law, self-consistent (at 20 in-flight requests the expected per-request time is approximately 250 ms when the system delivers 80 TPS).

4.4.1. Hash Operation Complexity

The theoretical basis of the DBM’s efficiency lies in its $O\left(\sqrt{N}\right)$ hash-operation count. Figure 14 illustrates the difference between the linear $O\left(N\right)$ cost of a traditional chain and the $O\left(\sqrt{N}\right)$ cost of the DBM. At ${10}^6$ blocks, the DBM performs on the order of $2\times {10}^3$ hash operations per update, compared with ${10}^6$ for a naive linear-chain implementation; this reflects the asymptotic $O\left(\sqrt{N}\right)$ versus $O\left(N\right)$ relationship rather than an engineering optimization.

4.4.2. Verification Time Scaling

Figure 15 presents the measured hash-verification time as a function of dataset size. The measurements are consistent with an $O\left(\sqrt{N}\right)$ scaling. Panel (a) shows the linear-scale view, where the data points closely follow the theoretical $O\left(\sqrt{N}\right)$ curve, with verification time growing from roughly 0.004 ms at ${10}^2$ blocks to roughly 0.4 ms at ${10}^6$ blocks. Panel (b) shows the log–log view, where the measured slope of approximately $0.5$ is consistent with $O\left(\sqrt{N}\right)$ complexity. The $O\left(N\right)$ reference curve is included for comparison; the gap between the two curves at ${10}^6$ reflects the asymptotic $\sqrt{N}$-versus-N difference rather than an engineering improvement specific to this implementation.

4.4.3. Comprehensive Scalability Analysis

Figure 16 shows a three-panel view of the DBM’s scalability: (a) hash-recalculation time tracking the theoretical $O\left(\sqrt{N}\right)$ curve, (b) the ratio between linear and square-root counts growing from roughly $5\times$ at ${10}^2$ blocks to roughly $500\times$ at ${10}^6$ blocks (which reflects the asymptotic $\sqrt{N}$-versus-N relationship rather than an engineering improvement), and (c) normalized relative timing comparing the measured DBM cost with theoretical $O\left(\sqrt{N}\right)$ and $O\left(N\right)$ models. The measurements are consistent with $O\left(\sqrt{N}\right)$ scaling.

4.4.4. Practical Throughput Performance

While the $O\left(\sqrt{N}\right)$ complexity applies specifically to hash chain recalculation, practical throughput is influenced by additional factors, including network latency, consensus overhead, state database operations, and client instrumentation. Figure 17 presents the measured TPS at both measurement layers alongside the hash computation overhead analysis. At the application layer, parallel operations achieved 77.9–88.9 TPS; at the chaincode layer, this improved to 91.9–101.6 TPS. The hash computation overhead remains negligible at moderate scales and reaches approximately 4% of total transaction latency at 1,000,000 blocks, confirming that the $O\left(\sqrt{N}\right)$ hash complexity does not constitute a practical bottleneck.

4.5. Summary of Benchmark Results

Table 14. Complete benchmark summary across the dataset-size sweep. Matrix side is $\lceil \sqrt{N}\rceil$; hash operations per update is the DBM theoretical count $2\sqrt{N}$; update wall-clock is the measured DBM single-update latency (including row and column rehash); the theoretical $O\left(N\right)$ reference is the naive linear-chain hash count.

N (Blocks)	Matrix Side	DBM Hash Ops	DBM Update ($\mathsf{\mu }\mathrm{s}$)	Linear-Chain Hash Ops	Ratio (Linear / DBM)
100	11	20	10.59	100	≈5
1000	33	64	15.88	1000	≈16
10,000	101	200	23.28	10,000	≈50
100,000	317	632	37.73	100,000	≈158
1,000,000	1001	2000	123.17	1,000,000	≈500

presents a comprehensive summary of all benchmark measurements across the full range of dataset sizes from 100 to 1,000,000 blocks. The data validates both the theoretical $O\left(\sqrt{N}\right)$ complexity claims and demonstrates practical performance characteristics suitable for enterprise IAM deployments.

5. Discussion

The integration of the NIST DBM with Hyperledger Fabric addresses the core technical challenge of on-chain data erasure, a necessary but not sufficient condition for GDPR compliance. The results indicate that the technical capability for selective deletion can be achieved without compromising the distributed trust and security properties essential for enterprise applications. However, full GDPR compliance additionally requires: (1) coordinated deletion across all off-chain log replicas (e.g., monitoring systems, backup tapes) through organizational policy enforcement; (2) cryptographic key-lifecycle management ensuring that expired signing keys do not impede future deletion operations; and (3) clearly defined data-controller responsibilities per Article 26 of the GDPR, including designation of Data Protection Officers with the technical authority to execute erasure requests across all participating organizations. Compared with alternative approaches such as Olympus [32], which relies on off-chain InterPlanetary File System (IPFS) storage for GDPR compliance, the DBM approach keeps all data on-chain while enabling erasure, which can simplify system architecture and reduce potential points of failure.

Performance measurements indicate that the DBM’s dual-hash verification mechanism introduces a computational overhead, which is the expected cost of supporting on-chain erasure. State-of-the-art Fabric architectures such as Fabric-X [50] have reported throughputs of the order of ${10}^5$ TPS through microservices decomposition and sharded ordering; these optimizations target raw throughput rather than privacy compliance and are, in principle, orthogonal to the DBM extension. The ability to perform on-chain deletion while preserving ledger integrity addresses a limitation of current blockchain technology that has restricted its adoption in regulated environments [24].

Scalability must be evaluated along three independent dimensions. Data-volume scalability was validated empirically from ${10}^2$ to ${10}^6$ blocks, and the measurements are consistent with the theoretical $O\left(\sqrt{N}\right)$ complexity: at ${10}^6$ blocks the DBM performs on the order of $2\times {10}^3$ hash operations per update (around 123 $\mathsf{\mu }\mathrm{s}$ of wall time), compared with ${10}^6$ for a linear-chain implementation, in line with the $O\left(\sqrt{N}\right)$ versus $O\left(N\right)$ asymptotic ratio. Network scalability was evaluated through a multi-organization Fabric deployment across geographically distributed Kubernetes clusters, measuring cross-region consensus overhead. Production-scale scalability, combining large datasets with large networks under sustained load, remains future work and will require dedicated performance engineering.

The write-performance reduction compared with standard Hyperledger Fabric is the expected cost of supporting on-chain erasure. Dual-layer benchmarking (application layer versus chaincode layer) indicates that 14–26% of the measured latency is attributable to client instrumentation rather than to the DBM itself. This should be read in the context of typical IAM workload patterns, as follows:

• User registration and credential updates occur infrequently compared to authentication queries. Large-scale enterprise IAM providers report workload asymmetries that reflect this pattern: Okta’s 2024 Businesses at Work survey of over 18,800 customer organizations [51] documents an average of 93 applications integrated per organization with authentication traffic concentrated in a narrow daily peak, and Microsoft’s Digital Defense Report 2024 [52] reports that Microsoft Entra ID processes billions of authentications and blocks approximately 600 million identity attacks per day across its tenant base. In both cases, the read path (authentication, session validation, policy evaluation) dominates by several orders of magnitude over the write path (user provisioning, credential rotation, role assignment).
• Access control policy modifications are administrative operations with lower frequency requirements, typically under 10 updates per second even in large organizations; NIST SP 800-63B authentication assurance guidelines [12] assume peak concurrent sessions in the range of ${10}^2$–${10}^3$ per enterprise deployment, and stochastic performance models of Hyperledger Fabric under varying transaction workloads [17,18] characterize block-size and arrival-rate sensitivities that directly bound the sustainable write TPS for IAM-style workload mixes.
• Audit logging can be batched to amortize write overhead (batch writes achieved 1967–2465 TPS).
• The measured throughput of 78–102 TPS at ${10}^6$ assets provides meaningful headroom over peak demand; for a deployment managing ${10}^5$ users with an average of 10 authentication events per user per day, peak demand (assuming that 80% of activity occurs in an 8 h window) is on the order of 28 TPS, which is within the measured capacity.

The scalability analysis from ${10}^3$ to ${10}^6$ assets indicates that the single-client read latency remains essentially constant (approximately 17 ms at the chaincode layer and 44 ms at the application layer) independently of dataset size, which is consistent with the $O\left(\sqrt{N}\right)$ complexity model. The 2.5× latency difference between measurement layers indicates the importance of Software Development Kit (SDK)-based client integration in production deployments.

The implementation of RBAC and ABAC smart-contract mechanisms within the DBM framework illustrates the practical applicability of this approach to IAM scenarios. The ability to delete user data while preserving an audit trail of access decisions provides organizations with the flexibility required to align with privacy regulations while maintaining security and accountability.

The security analysis indicates that the DBM architecture can be implemented without introducing new attack vectors at the protocol level. The separation of audit metadata from deletable personal data, combined with multi-party authorization requirements, limits the abuse of deletion capabilities. The combined empirical sweep (seven attack vectors, with quantitative dose–response and adversary-capability curves) and the formal verification (a TLC exhaustive model-check of the quorum and audit-persistence invariants over 274,625 reachable states at the 4-organization, 3-asset, quorum = 3 configuration) together support this at the level of the threat model considered.

Scope of the formal verification. The bounded configurations exhaustively checked here (484 states at 3-org/2-asset/Q = 2 and 274,625 states at 4-org/3-asset/Q = 3) are sanity-grade evidence, not enterprise-scale proofs. TLC is an explicit-state checker whose cost grows combinatorially with org count, asset count and quorum size, so it does not extend to the 20-organization deployment of Section 4.3.6. A scaling argument requires a symbolic method (for example Apalache, Satisfiability Modulo Theories (SMT)-based) or a hand-proof with an abstraction-refinement mapping, both listed as future work (Section 5.6). The result here is a local check that the deletion state-machine logic is internally consistent at small org counts, not a production-scope soundness certificate.

Two implementation-level concerns warrant explicit discussion in advance of future work.

5.1. Disclosed Limitation: Deterministic Existence Oracle on the Deletion Reject Path

The timing side-channel probe in Section 3.3 revealed a deterministic binary oracle rather than a merely statistically significant gap. The architecture in its current form does not provide information-theoretic indistinguishability against an existence-query adversary on the deletion reject path: an attacker issuing a single DeleteAssetErasure request per candidate identifier can decide existence with zero inference and probability 1.

Two independent sweeps ($n=200$ existing plus $n=200$ non-existent probes, interleaved by random permutation) both yielded a Mann–Whitney $U=40,000$ (theoretical maximum) and rank-biserial $r_{rb}=-1.0000$. The two latency distributions have zero overlap and sharply different variance ($\sigma \approx 5$–7 ms non-existent vs. $\sigma \approx 11$–26 ms existing), indicating two structurally distinct execution regimes rather than one pipeline with different durations.

A chaincode-level constant-time padding patch (equalizing hash computation and timestamp formatting on both paths, ∼5–10 $\mathsf{\mu }\mathrm{s}$ added to the reject path) left $r_{rb}=-1.0000$ unchanged: closing a millisecond-scale gap with microsecond-scale padding is a four-order-of-magnitude scale mismatch [53]. The separating mechanism therefore lies outside the chaincode layer. The most plausible origin is Fabric’s transaction-lifecycle asymmetry: the happy path waits for endorsement–ordering–commit; the reject path returns an error from the chaincode and the gateway client returns without waiting for a commit event. The ∼100 ms gap matches the typical single-client commit-cycle latency. This reject path is operationally distinct from the DoS-defense reject path of Table 9 (whose $p_{99}=1655$ ms is dominated by pipeline queueing, not the chaincode branch) and should not be conflated. A chaincode-only patch cannot close the channel; the structural mitigations (always-commit semantics or a challenge–response deletion protocol) are listed as the highest-priority future work in Section 5.6.

5.2. Disclosed Limitation: Rate-Limiter Gaps on the Deletion Request Path

The current chaincode increments the rate-limit counter only inside executeDeletion. Under the default DeletionQuorum $\ge 2$, RequestDeletion creates a pending-deletion record without calling executeDeletion, so the counter does not advance on the request path. Under concurrent write load the increment is also not atomic against MVCC read-set validation, so short bursts can transiently bypass the limit until the first counter-bearing transaction commits. The DoS protection is therefore effective in steady state and on the execute path but incomplete on the request path under the default configuration. A deployment can configure DeletionQuorum = 1 (which places the rate-limited path on RequestDeletion directly, as validated in our experiments) or move the counter increment into RequestDeletion; both are implementation characteristics rather than architectural limitations of the DBM-Fabric coupling, and are listed in Section 5.6.

5.3. Illustrative Deployment Scenario: Healthcare Identity Management

To illustrate the practical applicability of the DBM-integrated Hyperledger Fabric architecture, consider a multi-hospital healthcare consortium that requires a shared IAM system for patient consent records, practitioner credentials and cross-institutional access permissions. The system must satisfy GDPR Article 17 (right to erasure) while maintaining immutable audit trails of access decisions. A four-organization Hyperledger Fabric deployment with three channels meets these constraints: (1) a patient-identity channel (DBM enabled) holding consent records and demographic data subject to deletion; (2) a practitioner-credentialing channel (DBM enabled); and (3) a conventional immutable channel for audit logs. Upon a GDPR Article 17 request, the DPO initiates the ABAC deletion flow; the RBAC layer checks the DPO’s jurisdiction; and the DBM chaincode locates the affected blocks, requires at least two organizations to endorse, executes the matrix rewrite using the $O\left(\sqrt{N}\right)$ rehash, and writes an audit record (containing operation timestamp, authorized parties and data categories, but no personal data) to the immutable audit channel. Auditors can subsequently verify (a) that each deletion was authorized via the preserved audit trail, (b) that hash-chain integrity is preserved through the alternative paths, and (c) that no residual personal data remains, consistent with EDPB guidance on hybrid blockchain architectures [9]. At ${10}^6$ assets the deployment supports roughly 80–102 concurrent consent updates per second via parallel operations (or 1967–2465 TPS batched), with deletion operations completing in well under one second; a ${10}^7$-record consortium ($5\times {10}^5$ blocks at 20 records/block) requires approximately $1.4\times {10}^3$ hash operations per deletion, which is below 50 ms for hash computation alone.

5.4. GDPR Compliance Scope and Residual Obligations

The DBM architecture provides architectural support for GDPR Article 17 erasure, a necessary but not sufficient condition for regulatory compliance. This subsection explicitly scopes the compliance boundary.

What this architecture provides: (1) true on-chain deletion of personal data through hash chain recalculation, satisfying the technical erasure requirement; (2) non-erasable audit trails preserving proof of deletion authorization and execution without retaining personal data; (3) RBAC/ABAC enforcement ensuring that only authorized actors can execute erasure; and (4) quorum-based multi-party approval preventing unilateral data destruction.

Residual obligations beyond this architecture: (1) Log replica coordination: Hyperledger Fabric peers and orderers maintain local file-system copies of blocks; deletion from the DBM does not automatically propagate to peer log replicas, monitoring systems, or backup infrastructure. Organizations must implement coordinated deletion policies across all replica locations, consistent with EDPB guidance [9]. (2) Key lifecycle management: cryptographic signing keys used to authorize transactions have finite lifetimes; expired or rotated keys must not impede future deletion operations, requiring key escrow or delegation policies. (3) Organizational data controller responsibilities: per GDPR Article 26, each participating organization in a consortium blockchain must designate data controllers and processors, conduct Data Protection Impact Assessments (DPIAs) and maintain Records of Processing Activities (ROPAs); none of these are automatable through chaincode alone.

This architecture is therefore best characterized as enabling technical compliance with Article 17 erasure within the on-chain data layer, while organizational, procedural, and infrastructure-level compliance remains the responsibility of the deploying consortium.

5.5. Scope of the Performance Evaluation and Open Measurements

The evaluation in Section 4 characterizes the DBM-Fabric coupling at the operation level and at a 20-organization cross-region deployment but does not cover the full load envelope of a production IAM system. The open measurements are:

• Higher-load and longer-run stress. Per-worker load was capped at 200 TPS with 2–8 workers, and the longest cross-region run was 30,000 transactions at 305 TPS, $p_{99}=1.82$ s; clusters were not held under load beyond about two minutes per run. The constraint is cost (each regional GKE cluster runs at ∼$1.10/h at the sizing used); sustained one-hour and 24 h runs and Okta/Microsoft-style mixed read/write/delete workloads [51,52] are open.
• Long-run ledger growth and storage footprint. On-disk cost of the DBM backend versus the linear chain at ${10}^7$–${10}^8$ blocks was not measured. The $O\left(\sqrt{N}\right)$ result here is a compute-cost claim, not a storage-cost claim.
• Crash and consistency recovery. Failure-injection experiments (orderer/peer pod kill, mid-deletion crash, partial-quorum failure) and the time to recover a consistent DBM state were not measured; the formal verification covers the protocol at a bounded scope but not deployment recovery.

The existing measurements establish that the design point is feasible and that per-operation cost behaves as the theoretical complexity predicts but are not sufficient to certify enterprise Service-Level Agreements (SLAs) over 24 h or seven-day windows; the open measurements above are the highest-priority experimental extensions.

5.6. Practical Implications and Future Research Directions

The findings of this work translate into five concrete research and engineering directions, each tied to a specific result earlier in the paper:

• Structural mitigation of the existence oracle (Section 5.1). Two paths queued for future work: always-commit semantics for deletion requests (encoding the outcome in the return value or audit record rather than in an error; a breaking API change), or a challenge–response deletion protocol that decouples the existence check from the erasure request.
• Counter-bearing RequestDeletion or atomic rate-limit primitive (Section 5.2). Moving the counter increment into RequestDeletion or exposing an atomic counter primitive in the chaincode runtime so the increment is robust to MVCC read-set contention under burst conditions.
• DBM compaction and ledger garbage collection at ≥10⁶ blocks (Section 5.5). A compaction policy that reclaims storage from rows or columns whose cells have all been erased, combined with long-run ledger-growth measurement, would close the storage-cost question.
• ABAC policy Domain-Specific Language (DSL) with formal conflict-resolution semantics (Section 3.2). The broader ABAC layer still uses an imperative deny-overrides resolver; a declarative DSL (XACML-style or a custom calculus) would make the policy layer auditable and verifiable alongside the existing formal verification.
• Cross-region orderer pool sizing and Raft quorum placement (Section 4.3.6). The 305 TPS sustained result used an asymmetric placement (two EU and one US). A systematic study of pool sizing and quorum placement across two and three regions, with the resulting commit-latency/throughput trade-off, forms the operational guidance that a deploying consortium needs.

6. Conclusions

This study reports a performance characterization of the NIST DBM architecture integrated with Hyperledger Fabric and examines its practical viability as a building block for GDPR-oriented IAM systems. Building on the foundational work of Kuhn [21] and the proof-of-concept implementation by Roberts et al. [22], this work quantifies the performance trade-offs and measures the theoretical complexity claims through empirical evaluation. The DBM enables selective data deletion while preserving blockchain integrity, which is a useful step towards reconciling privacy regulation with the immutable nature of DLT. The architecture addresses the core technical challenge of on-chain erasure; full GDPR compliance in production deployments additionally requires key-lifecycle management, consistent deletion across all ledger replicas and organizational data-controller responsibilities, all of which extend beyond the scope of the present evaluation.

Performance evaluations at ${10}^6$ assets indicate that the DBM implementation keeps a consistent throughput (78–102 TPS for parallel operations across application- and chaincode-layer measurements) while providing on-chain erasure. The throughput gap relative to standard Hyperledger Fabric is acceptable for IAM workloads and is offset by avoiding the off-chain storage layer required by alternative approaches such as EBSI and Olympus [32]. Unlike chameleon-hash-based redactable blockchain approaches [33,34], the DBM uses standard SHA-256 hash functions and avoids trapdoor key management. For context, a microbenchmark comparing the DBM’s SHA-256 deletion (hash replacement plus row/column rehash) with an equivalent chameleon-hash construction (P-256, Krawczyk–Rabin [23]) indicates that the DBM deletion is faster at the primitive level (on the order of ${10}^2$ ns versus ${10}^4$ ns per operation) and has lower per-operation memory allocation; we do not emphasize a precise ratio because the two primitives implement different trust models and operate in different regimes. The chameleon hash additionally requires per-block trapdoor generation, key-storage infrastructure and key-lifecycle management, which the DBM does not require. Although chameleon-hash redaction is $O\left(1\right)$ per block compared with the $O\left(\sqrt{N}\right)$ rehash of the DBM, the absolute cost difference at ${10}^6$ blocks (roughly 0.2 ms of hashing versus a single elliptic-curve operation of comparable order of magnitude) is small enough that, in practice, the consensus layer, not hash computation, dominates end-to-end latency.

The DBM’s mathematical design supports scalability with $O\left(\sqrt{N}\right)$ verification complexity, validated through empirical testing at scales up to ${10}^6$ blocks. At this scale, the DBM performs on the order of $2\times {10}^3$ hash operations per update, compared with ${10}^6$ for a linear-chain implementation; this is the $O\left(\sqrt{N}\right)$ versus $O\left(N\right)$ asymptotic ratio rather than an engineering speed-up. The custom chaincode developed for this work illustrates how organizations can build IAM frameworks that align with both security best practices and privacy mandates.

The Phase 1 evaluation probes data-volume scalability up to ${10}^6$ blocks on a local testbed, while Phase 2 extends the evaluation to a 20-organization Fabric network deployed across two regional GKE clusters (europe-north1 and us-east1). The Phase 2 deployment enables measurement of cross-region consensus-latency impact on DBM operations, realistic IAM workflow performance (identity registration, policy update, audit query and end-to-end GDPR deletion request) and security validation through simulated attack scenarios (selective history rewriting, mass-deletion DoS and collusion attacks). Intra-region TPS with aggressive batching approaches standard Fabric baselines; cross-region TPS reflects the physical constraint of Raft consensus over the 80–100 ms transatlantic RTT.

Future research should focus on: (1) exploring multi-dimensional matrix structures for enhanced scalability; (2) developing standardized tools for automated compliance verification; (3) investigating integration with emerging privacy-enhancing technologies such as zero-knowledge proofs for selective disclosure scenarios; and (4) evaluating SmartBFT consensus (Fabric 3.0) as an alternative to Raft for cross-region deployments.

Data and Code Availability

The artifacts supporting this study are publicly available under a permissive open-source license at https://github.com/BulzN/dbm-arch-paper (accessed on 18 May 2026). The repository comprises four reproducibility components: first, the chaincode and protocol logic, including the IAM contract (RBAC, ABAC, deletion workflow, and risk scoring) and the upstream patches that extend Hyperledger Fabric and the Bevel operator with Data Block Matrix support; second, the deployment infrastructure, consisting of Terraform manifests for the 20-organization GKE testbed and Helm-based operator overlays; third, the measurement corpus, comprising raw throughput, latency, and resource-utilization traces together with the analysis scripts that regenerate every figure and table reported in this paper; and fourth, the formal-verification assets, namely, the TLA⁺ specification of the deletion-quorum protocol and the model-checker configuration used in Appendix B. Sensitive credentials, organizational identities, and bare-metal cluster bootstrap secrets have been excluded; the public artifacts are sufficient to reproduce all reported measurements on a comparable infrastructure.