Denial-of-Service Attacks on Permissioned Blockchains: A Practical Study

Abstract

Hyperledger Fabric (HLF) is a leading permissioned blockchain platform designed for enterprise applications. However, it faces significant security risks from Denial-of-Service (DoS) attacks targeting its core components. This study systematically investigated network-level DoS attack vectors against HLF, with a focus on threats to its ordering service, Membership Service Provider (MSP), peer nodes, consensus protocols, and architectural dependencies. In this research, we performed experiments on an HLF test bed to demonstrate how compromised components can be exploited to launch DoS attacks and degrade the performance and availability of the blockchain network. Key attack scenarios included manipulating block sizes to induce latency, discarding blocks to disrupt consensus, issuing malicious certificates via MSP, colluding peers to sabotage validation, flooding external clients to overwhelm resources, misconfiguring Raft consensus parameters, and disabling CouchDB to cripple data access. The experimental results reveal severe impacts on the availability, including increased latency, decreased throughput, and inaccessibility of the ledger. Our findings emphasize the need for proactive monitoring and robust defense mechanisms to detect and mitigate DoS threats. Finally, we discuss some future research directions, including lightweight machine learning tailored to HLF, enhanced monitoring by aggregating logs from multiple sources, and collaboration with industry stakeholders to deploy pilot studies of security-enhanced HLF in operational environments.

1. Introduction

Blockchain technology represents a paradigm shift in how digital trust is established across various industries. Initially developed to support cryptocurrencies, blockchain has evolved into a foundational technology for decentralized applications (dApps), smart contracts, and enterprise systems [1]. At its core, a blockchain operates as a distributed, immutable ledger maintained through consensus between a network of nodes. This decentralized structure ensures tamper resistance, transparency, and fault tolerance, making it vital for applications requiring integrity and trust.

Blockchain networks are broadly categorized into public (permissionless) and permissioned types. Public blockchains, such as Bitcoin and Ethereum, use open participation and consensus mechanisms like Proof of Work (PoW) [2] and Proof of Stake (PoS) [3]. However, they suffer from privacy limitations, as transaction data is visible to all participants [4]. Permissioned blockchains address this issue by restricting access to authorized users, thereby offering confidentiality and regulatory compliance. Furthermore, permissioned systems can employ more efficient consensus mechanisms, achieving higher throughput and lower latency compared with their public counterparts [5]. They may be further categorized into private and consortium blockchains, depending on the governance model [6]. These features have made permissioned blockchains particularly attractive for enterprise applications in finance, supply chains, and healthcare [7].

Despite these advantages, permissioned blockchain systems remain vulnerable to cyber threats. Denial-of-Service (DoS) attacks, in particular, pose a serious risk to network availability. Public blockchains derive resilience from their decentralization and scale, while permissioned networks, with their relatively smaller and more centralized infrastructure, may become single points of failure under attack [8]. DoS attacks may be executed through communication flooding, invalid transactions, or resource exhaustion, thereby degrading the performance or availability of the network [9].

Although DoS attacks have been widely studied in the context of public blockchains, the literature on permissioned platforms is sparse and fragmented. Most prior studies focus on public-blockchain-specific attack vectors, such as incentive manipulation in PoW systems [10], speculative execution in smart contracts [11], or selfish mining coupled with Sybil identities [12]. These rely on assumptions that are not applicable to permissioned systems, such as anonymous validators, open participation, and financial incentives, which limits their relevance. A key research gap, therefore, lies in systematically analyzing DoS threats in permissioned environments, where system architecture, access control, and consensus models differ fundamentally from public networks.

To address this gap, we focused on Hyperledger Fabric (HLF), a widely adopted, modular permissioned blockchain framework. Used in projects such as IBM Food Trust [13], Walmart’s supply chain traceability [14], and healthcare data sharing with HealthVerity [15], HLF is a highly relevant case study for assessing the real-world impact of DoS threats in enterprise settings. While some prior work has explored performance bottlenecks and consensus behavior in HLF [16], few studies have designed and executed controlled experiments to demonstrate specific DoS vulnerabilities in different HLF components. Moreover, existing literature lacks insight into how configurations (e.g., Raft consensus tuning, MSP settings) may be exploited to launch targeted attacks, leaving a blind spot for both researchers and practitioners.

The contribution of this paper is thus twofold: (1) we experimentally demonstrated a series of DoS attack vectors that targeted HLF’s orderers, peers, consensus mechanism, and CouchDB state database, and (2) we analyzed the impacts of these attacks on key performance metrics.

The primary objectives of this work were as follows:

• To experimentally analyze DoS attack scenarios targeting critical components in HLF networks.
• To evaluate the impact of these attacks on performance metrics such as transaction latency, throughput, and node-level resource usage.
• To propose practical countermeasures that improve the resilience of permissioned blockchains to such attacks.

These objectives directly address the identified research gap by grounding the experiments in HLF’s architecture and known configuration behaviors. We have selected the specific attack scenarios in our experiments based on their practical relevance to real-world HLF deployments, their exploitability via configurable components, and the relative lack of empirical analysis in prior work. Previous studies extensively explored DoS attacks in permissionless blockchains, such as mempool flooding and selfish mining in PoW systems [10,11,17], but comparatively few have examined attack surfaces in permissioned platforms like HLF. Among those that do, Thakkar et al. [16] highlighted performance bottlenecks in HLF under a transaction load, while Bano et al. [18] and Xu et al. [5] discussed theoretical vulnerabilities in consensus mechanisms and peer-to-peer communication layers. Inspired by these studies, we focused on practical scenarios targeting components central to HLF’s modular design: the ordering service (including Raft consensus), peer endorsement, MSP misconfiguration, and CouchDB as the state database. These components have either been identified as critical performance bottlenecks or as areas prone to misconfiguration in enterprise deployments [19,20]. In contrast, we excluded attacks specific to anonymous or incentivized environments, such as Sybil-based or incentive manipulation attacks, because they exploit features not present in HLF’s permissioned trust model.

Our selection of attack scenarios reflects both a synthesis of identified vulnerabilities in the literature and a practical assessment of what can be realistically executed and measured in a controlled HLF environment. By aligning attack designs with system-specific configurations and literature findings, this study bridged the divide between descriptive security analysis and actionable resilience strategies.

The remainder of this paper is structured as follows: Section 2 provides background on permissioned blockchains and the architecture of Hyperledger Fabric (HLF). Section 3 reviews related work on known attacks targeting HLF. Section 4 outlines the study’s methodology, including the threat model. Section 5 presents the experimental setup and results. Section 6 discusses the findings in detail, analyzes the root causes of DoS vulnerabilities, and offers mitigation recommendations. Finally, Section 7 concludes the paper by summarizing key insights, acknowledging limitations, and outlining directions for future research.

2. Background

To better understand DoS attacks on permissioned blockchains, it is essential to first grasp the fundamental concepts of blockchain and the architecture of permissioned blockchains.

2.1. Permissioned Blockchains

While public blockchains are open to anyone, permissioned blockchains operate under a different paradigm. They are permissioned networks where only authorized participants can access, interact, and contribute to the blockchain. This characteristic makes permissioned blockchains particularly appealing for enterprises and organizations that require data privacy, controlled access, and efficient transaction processing. Unlike public blockchains, which rely on open consensus mechanisms, permissioned blockchains typically use various consensus protocols [21,22] to validate transactions between a predefined group of trusted nodes, improving the efficiency and transaction throughput. These blockchains are widely used in enterprise applications, with platforms such as HLF [23], R3 Corda [24], and Quorum [25] facilitating secure transactions in industries like finance, healthcare, and supply chain management [26]. Permissioned blockchains offer advantages such as faster transaction processing, greater scalability, and enhanced data privacy. However, their reliance on centralized governance reduces decentralization and transparency, making them more susceptible to collusion, censorship, or single points of failure [27]. While these trade-offs make permissioned blockchains more efficient for specific use cases, they limit the openness and trustless nature that define public blockchains.

2.2. HLF Architecture

HLF is a widely used permissioned blockchain platform designed for enterprise applications. It employs a modular architecture, allowing enterprises to configure their blockchain networks based on specific requirements. Its flexibility makes it suitable for various industries [28]. The following are some key architectural components.

2.2.1. Ledgers

The ledger in a permissioned blockchain consists of the following:

World state: A database that maintains the current state of the blockchain.

Blockchain ledger: An append-only log of all transactions grouped into blocks.

2.2.2. Peers

Peers are the core nodes in a HLF network. They maintain the ledger and execute smart contracts, known as chaincode. Peers play two main roles. Endorsing peers execute transaction proposals and generate endorsements. Committing peers validate and apply transactions to the ledger after receiving ordered blocks. A single peer can take on both roles depending on the network configuration.

2.2.3. Certificate Authority (CA)

The Certificate Authority is responsible for issuing digital certificates to participants in the network. These certificates authenticate users and nodes, ensuring secure communication and identity verification [29].

2.2.4. Ordering Service

The ordering service is responsible for determining the sequence of transactions and creating blocks. It ensures all peers receive transactions in the same order, maintaining consistency across the network. Unlike public blockchains that use Proof of Work (PoW) or Proof of Stake (PoS), Fabric uses consensus mechanisms like Raft and Kafka [23], which prioritize efficiency and low latency. The ordering service does not validate transactions but simply orders them, separating consensus from execution.

2.2.5. Membership Service Provider (MSP)

HLF operates in a permissioned environment, requiring identity verification for all participants. The MSP handles authentication and access control using digital certificates issued by a CA. It ensures that only authorized entities can endorse, order, or commit transactions. This identity management system enhances security and accountability by preventing anonymous or malicious actors from manipulating the network.

2.2.6. Consensus Protocols

Consensus protocols ensure that all nodes agree on the order and validity of transactions. Examples of consensus protocols in permissioned blockchains include Practical Byzantine Fault Tolerance (PBFT) [30], RAFT [31], and Kafka [32].

2.2.7. Chaincode

Chaincode is HLF’s equivalent of smart contracts and defines the business logic of transactions. It runs in a secure execution environment, typically inside Docker containers. Unlike Ethereum’s smart contracts, which are limited to Solidity, HLF allows chaincode to be written in Go, Java, and JavaScript [33], making it accessible to a broader range of developers. Chaincode execution follows an endorsement policy, specifying which peers must approve a transaction before it is committed to the ledger.

2.2.8. Channels

HLF follows an execute–order–validate model [23], which differs from the traditional order execute model used in many other blockchains. By executing transactions before ordering and validation, HLF reduces the computational overhead and ensures only valid transactions proceed. This approach improves efficiency, particularly in permissioned environments where endorsement policies determine transaction validity before ordering. The transaction process involves six key stages [34].

2.2.9. State Database

In HLF, CouchDB is used as the default state database that stores the current state of the ledger [35]. It is a NoSQL database that provides an efficient and flexible way to store and query the state data associated with blockchain transactions.

3. Related Work

DoS attacks pose a critical threat to the security and functionality of HLF. Prior research has extensively investigated vulnerabilities across various elements of HLF, including ordering services, consensus mechanisms, endorsement processes, and application-level components. While these studies offer valuable insights, they vary significantly in scope, methodology, and targeted subsystems. To highlight both the breadth and fragmentation of existing DoS-related research on HLF,

Table 1. Summary of related studies.

Study	Methodology	Main Findings
Ordering Service Vulnerabilities
Dabholkar et al. (2019) [36]	Systematic modeling of attack scenarios.	Identified vulnerabilities due to block withholding and batch size manipulation in the ordering service.
Carlos and Urmila (2021) [37]	Architectural analysis of Raft-based ordering.	Highlighted DoS risks via Raft leader election manipulation through timeout abuse.
Jayadev et al. (2024) [38]	Simulated transaction flooding on Ethereum and Fabric.	Demonstrated that transaction flooding degrades performance.
Consensus Protocol Vulnerabilities
Giuliari et al. (2024) [39]	Simulated low-bandwidth DoS attacks on HotStuff.	Showed that attacks as low as 30 Mbps can halt HotStuff.
Rasolroveicy et al. (2022) [40]	Benchmarked PBFT, Raft, and PoET under DDoS in Sawtooth.	Found Raft suffered the most degradation (latency, packet loss); proposed adaptive switching strategy.
Battisti et al. (2023) [41]	Flood-based attack simulations on Raft in HLF and Ethereum.	Confirmed Raft’s vulnerability; HLF showed CPU overload, latency rise, and packet loss.
Chen et al. (2022) [42]	Evaluated SGX-based EGES protocol on Ethereum.	EGES showed DoS resilience and scalability on Ethereum.
Endorsement Layer Vulnerabilities
Andola et al. (2019) [43]	Simulated targeted DoS attacks by sending a high rate of transactions to selected endorsers.	Found that attacking 2 endorsers caused a 20% throughput drop and a 75% latency increase; proposed VRF-based randomized endorsement.
Nie et al. (2021) [44]	Simulated SHA-256-based dynamic endorser selection.	Mitigated risk from static endorser configurations and reduced attack success rate by nearly 50%.
Zheng et al. (2021) [45]	Conceptual modeling of Denial-of-Endorsement (DoE) attack.	Showed that colluding peers can selectively refuse endorsements; proposed diversified policies without empirical testing.
La Salle et al. (2023) [46]	Petri Net-based simulation of Sybil and endorsement attack.	Sybil nodes increased endorsement delays and MVCC conflicts and disrupted the transaction flow.
Application Layer Vulnerabilities
Zhang et al. (2024) [47]	Controlled simulations of MTC attack.	Showed that persistent logical conflicts prevent transaction validation; proposed redefining conflict rules for mitigation.
Detection and Defense Mechanisms
Dai et al. (2022) [48]	Proposed CNN-based detection (CMCNN).	CMCNN outperformed traditional models for network-layer DoS detection in blockchain systems.
Li et al. (2024) [49]	Applied GRU-based sequential model.	GRU achieved high accuracy and robustness in detecting DDoS within Fabric.
Chen et al. (2025) [50]	Static analysis using SSA form for chaincode.	Detected DoS-prone Read/Write logic flaws in Go chaincode pre-deployment.
Chiras et al. (2024) [51]	AMRA: SDN-based monitoring framework.	Proposed AMRA framework was effective in identifying anomalous traffic patterns including DoS behavior.
Putz and Pernul (2020) [52]	Log aggregation with rule-based threat detection.	Introduced indicators for security threats; developed a threat-monitoring framework aggregating logs from blockchain components.

organizes prior studies by subsystem and method. While these studies offer valuable insights, their findings often lack integration, and few directly inform real-world attack design. By critically synthesizing their methodologies, we identify the gaps that shaped our experimental setup.

3.1. Ordering Service Vulnerabilities

Dabholkar et al. [36] found that block withholding and batch size manipulation could disrupt ordering services in HLF. Similarly, the Cloud Security Alliance [37] examined vulnerabilities in the leader election process. The study showed that attackers could manipulate randomness intervals to affect the availability of ordering services. However, both studies were largely theoretical and lacked empirical validation. A more applied approach by Zhang et al. [38] simulated DDoS attacks in three different scenarios and validated their impact on the blockchain’s performance. The experimental results confirmed that excessive transaction flooding significantly increases the latency and reduces the throughput. Since this study primarily focused on comparing Ethereum and HLF under DDoS conditions, its attack scenarios were generic and not specifically designed to exploit HLF’s unique security vulnerabilities. These studies highlighted vulnerabilities in ordering services but failed to explore effective mitigation strategies.

3.2. Consensus Protocol Vulnerabilities

Several studies have explored the DoS resilience of consensus protocols. Giuliari et al. [39] simulated static-leader attack and leader-tracking attack and examined leader-based consensus resilience. Their study demonstrated that low-bandwidth attacks, as small as tens of Mbps, can halt the HotStuff consensus due to its reliance on a single leader. However, the experiment was based on standalone implementations rather than an actual blockchain platform, so the impact on HLF’s performance requires further investigation. A comparative study [40] benchmarked PBFT, Raft, and PoET under DDoS conditions in Hyperledger Sawtooth, and found that Raft was the most vulnerable consensus among them, as it exhibited the highest CPU utilization, response time degradation, and packet loss in the attack. However, since this study focused exclusively on Sawtooth and IoT applications, the impact on HLF remains unverified. Battisti et al. [41] analyzed Raft’s performance on both HLF and Ethereum in flood DoS scenarios, demonstrating that Raft is susceptible to Byzantine faults. To mitigate DoS vulnerabilities associated with static and explicit consensus committees, Chen et al. [42] proposed a consensus protocol named EGES. It leverages Intel SGX to implement a stealth committee mechanism and obfuscate validator identities to enhance security. Their experiment compared EGES to nine other baseline protocols and showed that EGES provides robustness, scalability, and resistance to DoS attacks. While EGES demonstrated promising results in Ethereum, its applicability and performance in the HLF context needs to be explored.

These findings collectively underscore the susceptibility of consensus protocols to DoS attacks, yet there is a lack of focused empirical evaluation within real HLF deployments, a gap we directly address. Our choice of Raft protocols was motivated by its prominence as HLF’s default consensus and its demonstrated weaknesses under adversarial conditions.

3.3. Endorsement Vulnerabilities

Andola et al. [43] identified that endorsers’ identities are publicly visible within a channel, making them vulnerable to targeted DoS attacks. Their experimental results show that attacking two endorsers led to a 20% reduction in the throughput and a 75% increase in the latency. To mitigate the risk, they proposed randomized endorser selection using Verifiable Random Functions (VRFs) and pseudonymous endorsements. However, the proposed strategy sacrificed network efficiency for security, leaving room for further improvement. Building on this concern, Nie et al. [44] identified that statically configured, publicly known endorsers are easy targets. It creates a vulnerability where attackers can target a small subset of these nodes to disrupt transaction processing. To mitigate this, they proposed a dynamic and randomized selection mechanism for endorsing peers using the SHA-256 hashing of public keys combined with time-based randomness. Their simulation results demonstrated a nearly 50% reduction in the success rate of such attacks. Zheng et al. [45] investigated Denial-of-Endorsement (DoE) attacks in HLF, where malicious nodes conspire to selectively refuse transaction endorsements. While mitigation strategies such as custom endorsement policies and increased trusted peer nodes have been proposed, there is no detailed design or empirical validation to test their effectiveness. La Salle et al. [46] developed a Petri Net-based modeling framework to simulate Sybil attacks on HLF’s transaction flow. By forging multiple Sybil clients and malicious endorsers, these attacks significantly disrupt the transaction flow, increase the endorsement latency, and impact the multiversion concurrency control (MVCC) and ordering services. However, since their study focused specifically on Sybil attacks, it does not necessarily constitute a DoS attack in all cases.

While several solutions like VRF-based selection and dynamic endorsement policies have been proposed, none have been validated collectively with other layers under a coordinated attack. This informed our attack scenario design targeting endorsement peers in combination with ordering services to explore cascading effects.

3.4. Application Layer Vulnerabilities

Zhang et al. [47] introduced the Manipulated Transaction Collision (MTC) attack. In such attacks, adversaries control one or more DApp accounts and intentionally induce persistent transaction conflicts to prevent a targeted user’s transactions from being validated. Unlike traditional network-based DoS attacks, MTC attacks are more stealthy, as they rely on syntactically valid transactions that are difficult to distinguish from legitimate user activity. The authors proposed a mitigation strategy by redefining conflicts based on transaction conditions rather than state versions, reducing both attack feasibility and natural conflicts. However, this approach introduces additional computational overhead and may still be vulnerable in DApps with highly sensitive execution logic. The MTC attack illustrates how adversaries can exploit business logic without triggering conventional network-layer detection.

Despite the growing sophistication of application-level architectures in HLF, few studies systematically investigated their potential as DoS vectors. This underscores the need for future research to explore architectural threats beyond consensus or networking layers, broadening our understanding of systemic weaknesses in permissioned blockchains.

3.5. Detection and Defense Mechanisms

Various mitigation strategies have been explored to detect and prevent DoS attacks in HLF, ranging from machine learning-based traffic analysis to system-level monitoring. Dai et al. [48] proposed a Cross-Multilayer Convolutional Neural Network (CMCNN)-based detection method, enhancing traffic classification in HLF and Ethereum environments. Their model showed better generalizability and higher accuracy rates compared with traditional detection methods. Similarly, a two-layer GRU deep learning model [49] demonstrated high accuracy in detecting DoS attacks within the HLF environment, significantly outperforming conventional machine learning techniques. While these data-driven approaches focus on runtime detection, other studies target the development phase. To mitigate Chaincode-related DoS attacks, a static analysis technique based on the Static Single Assignment (SSA) form of Go’s intermediate representation has been developed to detect vulnerabilities before deployment [50]. However, this method is limited to pre-deployment detection and lacks runtime mitigation strategies. In terms of system-level monitoring, Putz and Pernul [52] developed a set of threat indicators and introduced a threat-monitoring framework. The framework aggregates log data from HLF components and external sources to detect security anomalies. However, their framework was not specifically designed for DoS attack detection and lacks empirical validation within HLF deployments. Building on the need for more targeted and dynamic defenses, Chiras et al. [51] explored the use of Software-Defined Networking (SDN) to enhance the security of containerized blockchain environments, specifically testing on HLF. Their study introduced the Advanced Monitoring and Response Application (AMRA) framework. Experimental results demonstrated that the proposed method effectively detects potential threats and provides visualization for security engineers. These studies illustrate that current solutions are often fragmented and narrowly focused, lacking comprehensive integration across system layers. This underscores the need for holistic, adaptive defense frameworks that align with the modular and layered architecture of HLF.

3.6. Gaps in Literature

The literature provides a fragmented but rich foundation for understanding DoS threats in HLF. However, existing studies primarily focus on theoretical analyses and isolated attack scenarios. Most studies lack empirical validation through controlled experimental simulations within realistic HLF deployments. This indicates a gap in comprehensive, data-driven assessments of DoS vulnerabilities across multiple HLF components. In addition, most experimental studies only simulate a single DoS attack technique, such as SYN flooding. This narrow focus fails to explore a diverse range of attack vectors targeting different components and limits the understanding of the interplay between these components under adversarial conditions. Furthermore, existing mitigation strategies have not been systematically evaluated for their effectiveness in mitigating different types of DoS threats in HLF. They are also limited to detection-based mechanisms, rather than proactive or adaptive defense mechanisms that can make real-time responses. Our work addresses these gaps by systematically investigating the feasibility of network-level DoS attacks using multiple attack vectors. Through a comprehensive evaluation, we demonstrated how both external attackers and malicious insiders can exploit HLF’s modular architecture, consensus protocol, and identity management mechanisms to compromise the system performance and availability.

Previous research exposed security weaknesses in HLF, but there is still a critical gap: the real-world testing of DoS attacks in permissioned blockchains. While many studies focus on theory or individual attack methods without practical validation, our work tackles this problem. We systematically tested how realistic network-level DoS attacks impacted HLF. We showed how both outside attackers and malicious insiders could exploit HLF’s design, including its modular structure, consensus rules, and identity management, to disrupt the network. By measuring the real performance impact of these attacks, our study provides concrete, practical insights to help businesses build stronger, more resilient blockchain systems.

4. Methodology

HLF consists of various core components, including the ordering service, MSP, validating nodes, and client applications. These are integral to the secure and efficient operation of the blockchain network. If compromised, attackers can exploit them to conduct various malicious activities, including DoS attacks [53], which degrade the system performance and availability.

Our attack vector assumed that attackers can compromise internal components in the permissioned blockchain with public information and various hacking techniques. The attackers could be outsiders or insiders. The motive of the attackers behind the DoS attacks was to affect the availability of the blockchain so that it is unable to provide normal services, resulting in financial benefits against competing organizations. The attackers could make an attack strategy by collecting the victim’s information. They concentrated on attacking those components with a higher benefit, e.g., the consensus mechanism, ordering service, membership service, or peer nodes. Multiple attack strategies are usually available to attackers to target different components. We formulated threats that targeted different parts of a permissioned blockchain.

4.1. Threat Model for HLF

Our threat model considered two primary attacker profiles: (1) outsider attackers, who did not have legitimate access to the blockchain network but could reach exposed interfaces (e.g., client APIs or misconfigured services) to overwhelm components like the ordering service, and (2) insider attackers, who possessed authorized access to specific HLF components (e.g., as peer operators, DevOps personnel, or compromised administrators) and could exploit their limited privileges to issue malicious requests or manipulate configurations. Our models reflected realistic enterprise scenarios, such as third-party consortium members, compromised cloud-hosted nodes, or accidental misconfigurations within an organization. Our attacks were tailored to these profiles, focused on scenarios that were both technically feasible and historically observed in enterprise blockchain deployments.

4.1.1. Threats to Ordering Service

The ordering service is a crucial component that is responsible for managing the sequencing of transactions and creating blocks for validation by peers. If this component is compromised, the entire network’s transaction flow can be disrupted. The ordering service in HLF groups a certain number of transactions into a block before it is sent for validation. An attacker may manipulate the block size configuration by increasing it to an abnormally large value, delaying the block formation [54]. Alternatively, setting a very small block size forces the orderer to create and distribute blocks frequently, consuming network and computational resources unnecessarily. As a result, the transaction throughput decreases significantly as large blocks introduce latency, and smaller blocks create processing overhead for validating nodes. Similarly, an attacker with privileged access can programmatically discard blocks before distribution. This attack causes transaction inconsistencies, delays in consensus, and incomplete ledger states [55]. Block discarding can be selective or global. In the former case, only specific clients or transactions are targeted, affecting their processing. In the latter case, all transactions face block loss, creating major disruptions.

4.1.2. Threats to MSP

The MSP plays a fundamental role in managing identities and access control within the network in HLF. It is responsible for issuing and managing digital identities using X.509 certificates [56]. These certificates uniquely identify all entities in the network, including peers, ordering nodes, clients, and administrators. It verifies the authenticity of certificates using cryptographic signature validation to ensure that only legitimate entities can participate in the network. If the MSP is compromised, an attacker can issue fake certificates that allow unauthorized identities to enter the network.

An attacker with access to the MSP can issue a certificate with partial permissions, effectively allowing a client to connect to the network but preventing it from performing critical functions. As a result, clients experience communication failures and service disruptions, impacting system usability.

4.1.3. Peer Nodes Threats

Peer nodes are in charge of carrying out transactions, confirming that they adhere to the relevant chaincode regulations, and keeping a copy of the ledger. From proposal to endorsement to commitment, these are the essential elements of the transaction lifecycle. HLF’s performance and scalability are improved by this division of labor: ordering by orderers and execution and validation by peers. Peer and orderer networks’ distributed architectures support resilience and fault tolerance. In a collusion attack, a group of peer nodes, typically managed by different administrators, collude to disrupt the consensus process by refusing to validate transactions or altering transaction outcomes [57]. Colluding nodes may isolate honest peers by dropping or delaying communication, effectively splitting the network and reducing its availability. The attack can render the network unable to process valid transactions, effectively causing a DoS scenario.

4.1.4. External Threats

Rogue external clients can repeatedly submit invalid or excessive transaction requests, overwhelming the orderer and causing bottlenecks [58]. This results in performance degradation, delayed transaction processing, and potential network failures. In addition, external attackers can also flood other central components with high volumes of malicious requests.

4.1.5. Threats to Consensus Protocols

The Raft consensus protocol is a widely used algorithm for achieving agreement on shared states in distributed systems. Raft simplifies distributed agreement using a leader–follower model [31]: a single leader node proposes transaction ordering, while followers replicate and acknowledge entries. Once a quorum approves, transactions are committed network-wide. This approach simplifies the consensus process and ensures consistency across the network. Raft’s leader election mechanism ensures continued operation even if the leader fails. Followers periodically send heartbeats to the leader. If a heartbeat is missed, an election is triggered. Randomized time-outs and a term-based system prevent simultaneous elections and ensure a single leader is chosen. The leader manages transaction orders and communicates with followers. While Raft tolerates node failures (e.g., crashes), it remains vulnerable to Byzantine faults (e.g., malicious leaders or colluding followers), misconfiguration, and network partitioning [59]. For instance, if an attacker manipulates Raft’s heartbeat intervals, they can artificially slow the consensus or force repeated leader elections, degrading the throughput. Misconfigurations, such as incorrect time-outs, can destabilize the consensus process, leading to delays in block finalization, failed consensus, and potential network partitioning. Properly configuring Raft is crucial for the stability and performance of the HLF network.

4.1.6. Architectural Threats

Attackers can exploit the weaknesses in the design, configuration, and deployment of the system components of HLF to disrupt the functioning of the blockchain or manipulate its behavior to serve malicious interests [60]. CouchDB is the default world state database that stores the current state of the blockchain ledger. It is a NoSQL database that provides an efficient and flexible way to store and query the state data associated with blockchain transactions. An attacker may exploit vulnerabilities in CouchDB (e.g., insecure APIs or weak authentication) to overload the database, degrading the query performance and causing potential ledger inconsistencies [61,62,63].

4.2. Attack Scenarios

Considering the above-mentioned threat model, we selected a set of attack scenarios for our experiments in this study. The selection of attack scenarios was informed by both theoretical vulnerabilities and practical concerns observed in enterprise deployments of HLF identified in prior studies [64,65]. Unlike public blockchains, HLF’s permissioned nature reduces the node diversity and increases the reliance on specific architectural roles (e.g., orderers, endorsers, peers), which introduces unique threat vectors. We focused on seven distinct types of DoS attacks, each representing a plausible and high-impact method of degrading the performance or reliability of HLF. These attacks include a batch size attack, block-discarding attack, boycott attack, collusion attack, malicious client attack, consensus protocol attack (on Raft protocol), and architectural attack (on CouchDB).

Each attack scenario selected aligns with practical enterprise deployments of HLF, where access control boundaries are enforced through the MSP, but insider roles (e.g., node operators) may still have limited configuration or API-level access. These attacks are feasible and practical as they are based on documented vulnerabilities and security advisories, such as the 2022 Fabric Gateway DoS advisory [66], as well as misconfiguration risks in hybrid-cloud deployments [67,68] and real-world CouchDB vulnerabilities [69].

Table 2. Summary of attacker types and capabilities in HLF.

Attacker Type	Access Level	Capabilities	Realistic Scenario
Outsider	No credentials, external network access	Flood-exposed endpoints, send malformed or excessive requests	Misconfigured REST API or service exposed to the internet
Insider–Client	Valid user identity with limited permissions	Abuse APIs, send frequent or malformed transaction proposals	Rogue client or compromised user in a partner organization
Insider–Admin	Access to peer or orderer configurations	Alter block sizes, discard blocks, manipulate Raft parameters	Malicious or compromised DevOps/admin with access to node-level configs
Colluding Peers	Legitimate peer operators across consortium orgs	Boycott endorsements, drop/delay messages, disrupt consensus	Sybil-style or misbehaving peers in multi-organization setup

provides details about the attacker types, their capabilities, access level, and real-world scenarios.

4.3. Ethical Considerations

All experiments conducted in this study were performed in an in-house controlled and isolated environment using an HLF testbed deployed solely for research purposes. The simulated attacks were not conducted on any live or production systems. No real-world user data or third-party infrastructure was involved, thus eliminating the risk of harm to external systems or stakeholders. The primary intent of simulating these attacks was to evaluate vulnerabilities in a safe environment and propose practical mitigations. As permissioned blockchains like HLF are increasingly deployed in critical industries, proactive threat modeling and impact assessment are vital for ensuring trustworthy system design. This research adhered to ethical guidelines [70] for cybersecurity experimentation and aimed to enhance the resilience and security posture of enterprise permissioned blockchain systems through the responsible disclosure of findings.

5. Experiments and Results

This research focused on DoS attacks against blockchain systems at the network level. We assumed the attackers had enough knowledge about the network architecture and protocols and had access to the internal components, which allowed them to manipulate the configuration files and run instructions to impair the functioning or the performance of the blockchain system. We examined the viability of network-level DoS attacks through the use of different attack vectors.

5.1. Test Bed

The test bed for this research was implemented on a system running Ubuntu 24.0.7 on a 2.3 GHz Intel Core i5 processor with 4 GB DDR3 RAM. The software stack included Docker version 24.0.7, Docker Compose 1.29.2, Java 11.0.4 (utilized for application and code chain), HLF version 2.5.9, and Fabric CA version 1.5.12. The default HLF architecture consisted of a consortium network with two organizations, each containing a single peer node and a single orderer shared by both organizations. Additional orderers or peers were introduced only in scenarios where the attack logic or mitigation strategies required a larger fault domain.

The selected test bed configuration was designed to balance the experimental control with realism in enterprise deployments of permissioned blockchains. The choice of a two-organization consortium with one peer and a shared orderer is a common minimal configuration used in HLF deployments, e.g., in finance, where limited consortia are standard. This setup also made it easier to observe the effects of various attacks on specific nodes and the network without excessive network complexity. Furthermore, the selected versions of software components represented stable and widely used releases at the time of the study, which ensured the relevance and reproducibility of the results.

5.2. Attack Simulation

We simulated various DoS attack scenarios and provide a detailed analysis of them. We implemented at least one representative scenario from each threat category within the HLF environment to evaluate the blockchain network’s response. We analyzed their impacts on the blockchain performance using a range of metrics, including throughput, latency, and accessibility of critical HLF components. We performed a regression analysis to model the relationship between attack parameters and system performance metrics.

The network topology used in this study is illustrated in Figure 1. The default HLF configuration was augmented with three peer nodes (two in Organization 1 and one in Organization 2), three Certificate Authority (CA) nodes (one per organization and one shared), and five nodes dedicated to the Raft consensus mechanism. This modified structure was designed to represent a realistic deployment based on the standard HLF network model. However, each attack might only affect a specific part of this architecture, such as a peer, orderer, or user within an organization. In our experiments, the transactions followed a structured workflow:

• Chaincode execution: An application triggered a chaincode function installed on peer nodes, which performed credential verification and permission checks before returning a response.
• Transaction submission: Once validated, the application submitted the transaction to the ordering service.
• Consensus and block creation: The ordering service coordinated a consensus between its nodes. Successful consensus results in the transaction were added to a block, which was then propagated to peers for storage on the distributed ledger.

For clarity, our attack diagrams focus on the transaction submission and ordering phases, omitting initial validation steps. The message flows illustrate interactions between the application, ordering service, and peers across two organizations, with a channel configuration defining the component relationships. Further details about the simulations and test bed configurations are provided in Appendix A.

5.2.1. Batch Time-Out Attack

A batch time-out attack exploits the HLF ordering service’s mechanism for grouping transactions into blocks. By manipulating the rate or batch of submitted transactions, an attacker can overwhelm the ordering service (potentially comprised of multiple orderers depending on the consensus protocol), leading to a denial of service and impacting the network availability. After gaining initial access, the attacker initiates the attack by altering the ordering service’s configuration through changes to the batch time-out settings. This is illustrated in Figure 2. Specifically, the attacker exploits the batch time-out parameter. An optimal value for this parameter was selected based on network conditions, system hardware, and the use case [71]. However, an attacker can set the batch time-out to an extremely large number to launch a DoS attack on the blockchain. This causes the ordering service to accumulate a large number of transactions before creating a block. This increases latency for transaction confirmation as users wait for larger blocks to be filled. It can also cause potential memory exhaustion on ordering nodes as they struggle to hold a massive backlog of pending transactions. Similar to a batch time-out attack, there exists a related threat called a batch size attack in HLF. In this type of attack, the focus is on manipulating the size of the transaction batches rather than the time they take to form. An attacker can flood the ordering service with numerous transactions to force the creation of blocks that quickly reach their maximum capacity, potentially hindering the inclusion of legitimate transactions and straining the network resources [72].

Figure 3a illustrates the impact of increasing the batch time-out on the transaction delay, which refers to the time taken for a transaction to be fully processed, validated, and committed to the ledger. The x-axis of the figure represents the batch time-out in seconds, which ranged from 0.2 to 30. The y-axis represents the per-transaction delay in seconds. The figure shows that the delay increased with the increase in the batch time-out. A small batch time-out requires fewer transactions to fill, which reduces the waiting time for block formation. At the batch time-out = 0.2, the transaction delay was 1.38 s. The delay increased by 81% to 2.5 s at batch time-out = 1, and by 327% to 5.9 s at time-out = 5. Going from batch time-out = 5 to 15, the delay increased by 1291% to 19.2 s. Finally, at batch time-out = 30, we saw a total increase of 3052%, where it reached 43.5 s. The trend continued with larger batch time-outs. The reason for this increase in latency was that there was a significant waiting time to accumulate the transactions to fill the block. The end users and validators experienced higher delays in processing due to the large number of transactions. Sending very large blocks caused network congestion, which added communication delays.

Figure 3b shows the impact of increasing batch time-out on the throughput, as measured in the number of transactions per minute (TMP). At a batch time-out of 0.2, the system achieved a throughput of around 43 TPM. However, as the batch time-out increased to 5, the throughput decreased to 10 TPM, and finally reached a very low value of 1 TMP at a batch time-out of 30.

This level of degradation would be unacceptable in most enterprise blockchain deployments. The actual throughput requirement of enterprise networks varies from industry to industry. As such, setting the batch timeout beyond 5 s not only increased the latency but also risked falling below performance thresholds that could breach Service Level Agreements (SLAs) or cause network unavailability for applications such as supply chain tracking or financial settlement.

5.2.2. Block-Discarding Attack

Another critical threat to HLF is the block-discarding attack, where a compromised ordering service intentionally drops blocks before they reach peers. For this attack to succeed, an adversary must control at least one malicious orderer node within an organization or channel. The attack scenario for the block-discarding attack is depicted in Figure 4. In our simulated attack scenario, the malicious orderer (associated with Organization 1) selectively discarded transactions from that organization’s users. The discard rate followed a probabilistic function—for example, a probability of 0.2 meant the orderer dropped roughly 16–24% of transactions. The results were averaged over three test runs per probability setting.

Figure 5a presents the throughput achieved under different probabilities of block discarding. The x-axis shows the probability for block discarding ranging from 5% to 80%, while the y-axis indicates the resulting throughput in transactions per minute (TPM). The results show that a modest discard rate of 5% resulted in a throughput of approximately 23 TPM. As the probability of discarding blocks increased, the throughput declined rapidly, which dropped to around 13 TPM at a 40% probability and further down to 3 TPM at an 80% probability. The reduction in throughput highlighted the cascading effect of missing blocks on the normal transaction flow. When blocks were discarded, the network had to wait for new blocks to be proposed, batched, and validated, which led to fewer successfully processed transactions per unit time.

Figure 5b illustrates the impact of a block-discarding attack on transaction success. The x-axis denotes the probability function for block discarding, and the y-axis represents the number of successfully recorded transactions out of 100 attempted transactions. As seen in the graph, a small probability of discarding (e.g., 5%) had a relatively low effect, with 96 transactions successfully recorded. However, as the discard probability increased, the number of confirmed transactions declined rapidly, which dropped to only 14 recorded transactions at a discard probability of 80%. This downtrend demonstrated a direct correlation between the attacker’s ability to discard blocks and the resulting decrease in the system’s reliability.

In business-critical networks, such as those used in banking or healthcare, even a 20–30% drop in transaction success rates can disrupt daily operations. A decline observed in our experiments would represent near-total denial of service. Such a performance would fail to meet operational benchmarks for even the most tolerant batch-processing systems, let alone those requiring near-real-time confirmation. The results confirm that block discarding is a potent vector for DoS attack [55]. While minor levels of discarding had a moderate effect, higher discard probabilities quickly undermined the network’s ability to process transactions.

5.2.3. Boycott Attack

In a boycott attack, the attacker exploits compromised membership services to grant partial network access: the victim can initially connect to the blockchain but is later blocked from completing critical operations due to revoked permissions. The malicious MSP configures permissions to allow the client application to submit transactions but denies access to query or read data. To demonstrate this attack in HLF, we simulated a malicious certificate revocation to disrupt user authentication. The attack involved the following steps. We added the target user’s certificate serial number to the MSP’s Certificate Revocation List (CRL) by editing the local MSP configuration files. Next, a channel configuration update transaction was generated, embedding the modified CRL, and submitted to the ordering service. This propagated the revocation to the channel’s configuration block. Using the revoked user’s credentials, we attempted to submit transactions. As expected, peers rejected these requests during certificate validation by cross-referencing the updated CRL.

Figure 6 illustrates a boycott attack targeting the client application. However, attackers could similarly sabotage peer nodes or the peering system. Removing peers weakened the network distribution, which lowered the barrier for a 51% attack. Networks with a high fault tolerance may remain operational despite peer removals, but the reduced node count makes consensus manipulation easier. Our results confirmed that peers consistently blocked the revoked user, which proved the attack’s efficacy in disrupting the network access. This attack highlights how compromised MSP configurations can bypass legitimate identity management protocols.

5.2.4. Collusion Attack

In this collusion attack, three out of five orderer nodes in an HLF channel were compromised. These malicious orderers sabotaged the consensus protocol to prevent new nodes from joining the network by disrupting the consensus process required for enrollment. They also interfered with the block finalization based on a probabilistic decision function. The malicious nodes employed a probability function tied to a block receipt counter. When the function output 1, the nodes colluded to invalidate the consensus for the current block (e.g., withholding approvals). A 0 output allowed normal validation. To evade detection, attackers could limit how frequently the function output 1 (e.g., triggering disruption in 30% of blocks within a window). The collusion attack scenario is shown in Figure 7. To demonstrate this attack, we modified the orderer.yaml files of the three orderers and configured them to drop transactions that exceeded a certain buffer size. Next, we developed a custom client (using HLF SDK) to generate transaction proposals with payloads that deliberately exceeded the buffer size. Standard-sized transactions were created to mimic legitimate traffic, while large payloads were generated with a predefined probability. Malicious orderers rejected oversized transactions during consensus. The attack prevented the required quorum (≥3 confirmations) for block validation. This resulted in stalled block finalization, reduced throughput, and ultimately crashing the ordering service.

Figure 8a,b demonstrate the attack’s effects. We saw a 43% decline in the transaction throughput, down from 22 TPM to 12 TPM, and a 42% reduction in successfully recorded transactions, down from 93 to 54 successfully recorded transactions at a 60% probability of disruption. At 80% probability, the throughput was reduced by roughly 90%.

A low throughput over extended periods is likely to breach the performance expectations defined in SLAs or user contracts, resulting in cascading delays across integrated systems. The attack highlights how malicious coordination among orderers can not only slow the network but also render it unreliable from a service delivery perspective. It also underscores the risks of insider collusion in permissioned blockchains, where compromised orderers can cripple both the availability and trust.

5.2.5. Malicious Client Attack

In this attack, a malicious client targets the blockchain network by flooding the ordering service with a high volume of unconfirmed transactions [73]. This overwhelms the network’s processing capacity, delaying consensus formation as nodes prioritize handling the spam requests over legitimate transactions. This attack scenario is shown in Figure 9. To demonstrate this attack, we deployed three rogue client applications using the HLF SDK for Java, two clients authenticated with peers from Organization 1 and one client authenticated with a peer from Organization 2. Each client was assigned a unique Fabric user certificate for secure channel interaction. We created a function to generate high-volume transaction proposals that were sent concurrently to ensure a sustained pressure on network resources, which mimicked a DoS scenario. Transactions were generated at a rate that exceeded the network’s default throughput limits, which saturated the communication channels. Next, we observed the impact of this attack on a normal node. Figure 10a shows a 183% increase in the delay for transaction logging and retrieval on a legitimate node during the attack (going up from 2.5 s to 7.2 s). As shown in Figure 10b, the transaction throughput was decreased by 65% as the ordering service struggled to manage the malicious load (it went down from 24 TPM to 7.1 TPM). The attack forced the nodes to allocate resources to redundant request handling, which stalled the block finalization and propagating delays across the network.

5.2.6. Consensus Protocol Attack

In HLF, various consensus protocols can be configured for the network’s ordering service. Raft is one of the most widely used consensus protocols in HLF. However, its openness to configuration also makes it vulnerable to attacks by malicious ordering nodes. We demonstrated how improper configuration of Raft’s timing parameters could enable DoS attacks. Moreover, a malicious channel manager could alter these settings and send them to other nodes for updates, which exposed the network to further risks. Raft’s performance and fault tolerance depend on three timing settings: the tick interval, action tick, and heartbeat tick. These settings play a vital role in determining the frequency of requests, actions, and heartbeat checks, which ultimately impact the network’s overall performance and resilience [74]. The tick interval, for instance, controls the frequency of heartbeat messages sent by the leader to the followers. A shorter tick interval results in more frequent heartbeat messages, enabling the network to detect node failures more quickly. In contrast, a longer tick interval increases the time between heartbeat messages, which can lead to the delayed detection of node failures. The action tick, on the other hand, determines the frequency of actions, such as log replication, that are performed by the nodes. Finally, the heartbeat tick influences the frequency of leader election time-outs. Understanding the interplay between these tick settings is essential for striking a balance between the network performance, fault tolerance, and security.

To demonstrate this attack, we assumed an attacker had compromised a channel manager or ordering node with configuration update privileges. We increased the tick interval value in the Raft ordering service, which slowed the execution of the Tick() function. This function initiates a number of events, including making block proposals, heartbeating, and election time-outs. The default value of the tick interval in HLF’s Raft consensus was 500 ms. Increasing the tick interval prolonged the time between requests, leader selection, and consensus. The attack scenario, including maliciously configured orderers, is illustrated in Figure 11. The effects of the attack are visualized in Figure 12a,b. These figures illustrate the attack’s consequences: increased latency and reduced throughput. The transaction confirmation delays increased by 417%, where they went up from 2.5 s to 13 s due to sluggish block proposals. The throughput was reduced by 81%, where it went down from 23.5 TPM to 4.5 TPM as the nodes struggled with infrequent Tick() cycles.

5.2.7. Architectural Attack

In HLF, each peer node can be configured to use CouchDB as its state database, enabling powerful querying on the current world state. While this enhances the data access flexibility, it introduces architectural dependencies that may be exploited by adversaries. Specifically, each peer’s CouchDB instance runs independently, often as a Docker container. This means that the availability of the peer is directly tied to the availability of its CouchDB instance.

In this experiment, we evaluated the impact of an architectural attack targeting the CouchDB container. By forcibly stopping the CouchDB Docker container on a peer, we observed that the affected peer could no longer process transactions or serve read requests. In scenarios where CouchDB is shared between multiple peers, the consequences become more severe, i.e., a single point of failure can cascade across the network, potentially disrupting multiple components.

Figure 13 illustrates such an attack scenario where a user was denied access to the ledger due to CouchDB unavailability. Our test confirmed that once the CouchDB service was disabled, the client application was unable to read from or write to the blockchain, which effectively resulted in a DoS condition.

This experiment highlighted a critical architectural vulnerability in HLF deployments that rely on CouchDB. The extent of disruption depends on the redundancy and fault-tolerance mechanisms in place, but the reliance on external state database services such as CouchDB represents a significant attack surface. If not properly mitigated, such a dependency can be exploited to compromise the availability of the network.

5.3. Statistical Analysis of System Performance Under Attacks

To evaluate the fundamental relationships between the attack intensity and system performance, we employed the Spearman rank-order correlation ($\rho$), which detects monotonic trends (consistent directional relationships where variables increase or decrease together without assuming linearity). This non-parametric method is ideal for our attack scenarios. We computed the $\rho$ between each attack parameter (batch timeout, probability, malicious clients, tick interval) and performance metric (delay, throughput, successful transactions) to test the hypothesis that a higher attack intensity monotonically degrades system behavior. The Spearman rank correlations revealed perfect monotonic relationships across all the attack scenarios. All correlations exhibited either perfect ($\pm 1.00$) or near-perfect coefficients with extremely low p-values (typically <$0.0$ or <${10}^{-24}$). These values indicate highly statistically significant relationships. This analysis revealed that increases in the attack parameters clearly increased the delay and reduced the throughput and successful transactions. It confirmed that the attack intensity always degraded the performance within the tested ranges, with no exceptions or optimal operating points. Our analysis revealed clear degradation patterns across all attacks. This is shown in

Table 3. Spearman correlation coefficients for system performance metrics under various attack types.

Attack Type	Variable Pair	Metric	Spearman $\mathit{\rho }$	p-Value Interpretation
Batch Timeout	Batch Timeout (s) vs. Throughput (t/s)	Throughput	−1.00	Very strong negative correlation
	Batch Timeout (s) vs. Delay (s)	Delay	1.00	Very strong positive correlation
Block Discard	Probability vs. Throughput (t/s)	Throughput	−1.00	Perfect negative correlation
	Probability vs. Recorded TXs	Recorded TXs	−1.00	Perfect negative correlation
Collusion	Probability vs. Throughput (t/s)	Throughput	−1.00	Perfect negative correlation
	Probability vs. Recorded TXs	Recorded TXs	−1.00	Perfect negative correlation
Malicious Client	Malicious Clients vs. Throughput (t/s)	Throughput	−1.00	Perfect negative correlation
	Malicious Clients vs. Delay (s)	Delay	1.00	Perfect positive correlation
Consensus Protocol	Tick Interval (ms) vs. Throughput (t/s)	Throughput	−1.00	Very strong negative correlation
	Tick Interval (ms) vs. Delay (s)	Delay	1.00	Very strong positive correlation

.

Next, we employed regression analysis to quantify the precise functional relationships between the attack parameters and the system performance. We evaluated multiple regression forms: linear, quadratic, exponential, and power law, where we selected optimal fits through adjusted $R^2$ maximization and residual analysis. The resulting models revealed attack-specific scaling behaviors and quantified degradation patterns with a high explanatory power($R^2\ge 0.985$), which enabled insights for security optimization.

The batch timeout attacks exhibited a quadratic increase in the transaction delay, where the delay grew with the square of timeout duration. The throughput decayed exponentially, where it halved every 6.36 s. This confirmed that the timeout values beyond 5 s triggered disproportionate latency penalties.

The block discard and collusion attacks followed power-law dynamics. The throughput scaled inversely with the discard probability, where a 10% probability increase caused a 7.14% throughput loss. The collusion attacks demonstrated a 50% faster exponential decay than the block discards, indicating a more severe degradation per unit probability increase. The recorded transactions decreased linearly in both attacks, where the block discards caused 11% greater transaction losses per probability unit.

The malicious client attacks showed a quadratic increase in delay, where the delays compounded rapidly beyond five clients. The throughput decayed exponentially, where each additional client reduced the throughput by 16.7%. This highlighted the non-linear risk of coordinated adversaries.

The consensus protocol attacks showed near-perfect inverse relationships. The delay increased linearly with tick intervals, where 2.64 s was added per 500 ms interval. The throughput followed a reciprocal pattern, which confirmed that halving the tick interval doubled the throughput.

5.4. Testbed Limitations

The relative performance changes in the latency, throughput, and successful transactions observed in our experiments were obtained on modest hardware and reflected the impact of parameter variation under constrained conditions. While we expect the general trends to hold, performance characteristics may differ on enterprise-grade infrastructure due to differences in resource availability and system bottlenecks. It is also important to note that performance improvements or degradations do not always scale linearly with system resources. For example, the effect of increasing the block size on the latency might be amplified or reduced due to better parallelism or caching on a high-end server.

We acknowledge that this simplified network and hardware configuration did not capture the full complexity and scalability challenges of real-world, large-scale HLF deployments. In particular, the absence of complex topologies and peer/orderer hierarchies limits the generalizability of quantitative performance findings. Our goal in adopting a constrained testbed was to isolate and clearly observe system behaviors under attack conditions rather than to simulate enterprise-scale operational loads. Previous studies have shown that the CPU core count and memory can significantly alter the latency/throughput trends in HLF, and the performance can change by changing the number of clients, endorsers, orderers, etc., even with controlled test scenarios [75].

6. Discussion

This section consolidates our experimental findings, root cause analysis, and broader discussion of the vulnerabilities in HLF exposed by the DoS attack simulations. The focus was on understanding how misconfigurations or adversarial actions could disrupt the network availability, degrade performance, and compromise trust in a permissioned blockchain system. A comparison of different attack scenarios of this study is presented in

Table 4. Comparison of HLF attacks.

Attack	Goal	Method	Target	Attacker Abilities	Key Impact	Severity
Batch Time-out Attack	Disrupt availability of ordering service	Manipulating BatchTimeout in configuration	Ordering service	Ability to alter ordering service configuration	Increased latency, decreased throughput	Medium
Block Discarding Attack	Prevent block propagation, causing DoS	Malicious orderer discarding blocks	Ordering service	Control over at least one orderer node	Reduced throughput, lower successful transaction rate	High
Boycott Attack	Prevent specific user from critical operations	Revoking user certificate via compromised MSP	MSP, specific user/node	Ability to alter MSP configuration	Targeted user cannot submit transactions or query data	Low to Medium
Collusion Attack	Prevent new nodes from joining, disrupt block finalization	Compromised orderers sabotage consensus	Ordering service (consensus mechanism)	Compromise of the majority of orderer nodes	Reduced throughput, reduced successful transactions, stalled block finalization	High
Malicious Client Attack	Overwhelm ordering service and delay consensus	Flooding ordering service with high transaction volume	Ordering service	Ability to deploy malicious client applications	Increased delay and decreased throughput for legitimate users	Medium to High
Consensus Protocol Attack	Degrade performance by manipulating Raft timing parameters	Changing the Raft tick interval (or other parameters)	Ordering service (Raft consensus)	Compromised channel manager or ordering node with update privileges	Increased latency, decreased throughput	Medium to High
Architectural Attack (CouchDB)	Render the network unusable (read and write)	Disabling the CouchDB instance	Peer nodes (CouchDB)	Ability to disable CouchDB instance or exploit vulnerabilities	Network becomes unusable, data retrieval fails	High

. The table provides an overview of the goal, method, target, attacker ability, impact, and severity of each attack.

6.1. Key Findings from Experimental Attacks

Our experiments revealed that several components in HLF can become single points of failure under stress, despite its modular and decentralized architecture:

• Ordering service vulnerabilities: The ordering service was highly sensitive to parameter manipulation. Attacks such as batch time-out misconfiguration and block discarding caused severe performance degradation. For example, setting large batch time-outs increased the latency several fold, while dropping just a small percentage of blocks led to a huge drop in the throughput, which revealed HLF’s dependency on honest orderers, a weakness also noted in prior work [55].
• Consensus manipulation: Altering Raft’s tick interval delayed leader elections and destabilized the consensus, which increased both the latency and the chance of partitioning. These attacks were feasible through unauthorized access to the system channel, which controlled the Raft parameters.
• Architectural weakness in CouchDB dependency: Disabling the CouchDB containers rendered the peers incapable of responding to world state queries. This effectively halted the application functionality, as HLF applications often rely on real-time data access from the state database. The lack of redundancy or failover in CouchDB presents a significant architectural fragility.
• Malicious client flooding: High volumes of invalid or excessive transaction requests from external clients overloaded the ordering service and peer components, which reduced the throughput and increased the latency. The absence of rate-limiting or client validation mechanisms contributed to this vulnerability.
• Selective disruption via boycott and collusion: Attacks such as the certificate revocation by compromised MSPs or colluding orderers refusing to commit transactions allowed for a selective DoS. These attacks evaded detection while severely impacting specific users or disrupting the network-wide throughput. They highlight the need for better monitoring, accountability, and proactive certificate lifecycle management.

6.2. Root Causes of DoS Vulnerabilities

Across all attack vectors, several core root causes emerged:

• Insecure configuration access: Many attacks were made possible through access to the configuration channels or admin privileges (e.g., Raft settings, batch timeouts). Default settings often lack constraints against extreme or malicious values.
• Over-reliance on trusted components: The network assumes correct behavior from orderers, peers, and MSPs. When compromised, these components can cause cascading failures due to the absence of effective fault tolerance mechanisms.
• Architectural dependencies: CouchDB, an external component not governed by consensus, represents a critical weak point. Its failure affects not just data access but also overall peer functionality.
• Lack of resilience mechanisms: There is minimal redundancy, anomaly detection, or automatic recovery built into the current default deployment of HLF, making it vulnerable to performance exhaustion and DoS propagation.

6.3. Prioritization and Recommendations

To enhance resilience, DoS mitigation strategies should be prioritized based on the potential for widespread impact. Attacks that can make the network completely or largely unusable, e.g., CouchDB disabling, block discarding, and Raft misconfiguration, must be addressed first. Mitigations include state database replication, stricter channel configuration controls, and consensus hardening. Attacks that significantly degrade performance, such as client flooding and batch timeout manipulation, should be tackled with improved rate limiting, input validation, and dynamic batching logic. Attacks with localized or targeted effects (e.g., boycott, endorsement denial by colluding peers) warrant the deployment of monitoring and accountability tools, including peer behavior analytics and misbehavior penalties. Threats such as MSP compromise, though harder to execute, have high-impact consequences. Emphasis should be placed on securing credential issuance, enforcing revocation policies, and deploying certificate anomaly detection systems.

7. Conclusions

The flexibility and modularity of HLF, while beneficial for custom deployments, introduce attack surfaces when the configuration access is not tightly controlled. This study systematically evaluated DoS attack vectors in HLF, demonstrating that both external adversaries and malicious insiders can exploit its modular architecture, configurable consensus, and identity management model to degrade performance and availability.

While the results of this study are based on the HLF ecosystem, similar vulnerabilities likely exist in other enterprise blockchain platforms that rely on modular architectures and complex configuration layers (e.g., Corda, Quorum, or Besu). This calls for a shift from performance-centric tuning to the threat-aware engineering of blockchain deployments. The bottom line is that even in permissioned blockchain systems that assume trust among participants, security-through-configuration alone is insufficient.

7.1. Limitations

The experimental setup was based on a testbed with constrained hardware and a minimal network configuration. While this allowed for controlled simulations, real-world deployments may exhibit different behaviors under scale, heterogeneous network conditions, or mixed workloads. Additionally, while multiple scenarios of DoS attacks were tested, the scope did not include advanced persistent threats (APTs) or coordinated multi-vector attacks. These limitations should be considered when generalizing the findings.

7.2. Future Work

To strengthen the resilience of HLF against emerging threats, future research should be guided by a prioritized roadmap.

7.2.1. Immediate Security Enhancements

To address the current vulnerabilities in HLF, future work should focus on developing targeted mitigation techniques tailored to its unique architecture. These include tuning dynamic batch sizes or timeouts to prevent orderer overloads; enhancing CouchDB redundancy and implementing robust failover strategies to improve ledger availability; and introducing consistency checks for Raft consensus, such as heartbeat validation mechanisms. Additionally, policy-driven security extensions should be developed, including tamper-resistant monitors to track and alert on unauthorized configuration changes. Finally, it is important to strengthen defenses against malicious MSPs by introducing middleware or plug-in modules capable of detecting and isolating suspicious MSP behavior, such as unauthorized certificate revocations or selective block propagation.

7.2.2. Detection and Response Mechanisms

Another important research direction is to prioritize the development of robust detection and response mechanisms to enhance HLF’s operational security. This includes applying lightweight machine learning models to detect anomalies in real time, including unexpected block drops or certificate manipulation. Additionally, integrating HLF with Security Information and Event Management (SIEM) systems will enable centralized log aggregation, rule-based correlation, and automated incident response workflows, facilitating rapid threat detection and containment.

7.2.3. Validation and Scalability

Finally, and most importantly for practical impact, it is necessary to do collaborative pilot studies with the industry in real-world settings to rigorously test threat models in real-world settings, assess the effectiveness of mitigation strategies, evaluate system performance under adversarial conditions, and focus on large-scale validation and scalability.