# Denial-of-Service Attacks on Permissioned Blockchains: A Practical Study
## 6 Discussion
### 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. \begin{table}
\begin{tabular}{p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline \hline
**Attack** & **Goal** & **Method** & **Target** & **Attacker Abilities** & **Key Impact** & **Severity** \\ \hline 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 \\ \hline Block Discarding Attack & Prevent block propagation, causing DoS Attack & Malicious orderer discarding blocks & Ordering service & Control over at least one order order node & Reduced throughput, lower successful transaction rate & High \\ \hline Boycott Attack & Prevent specific user from critical operations & Revoking user certificate via compromised MSP & MSP, specific user/node & MSP, specific & Ability to alter MSP configuration & Targeted user cannot submit transactions or query data & Low to Medium \\ \hline Collusion Attack & Prevent new nodes from joining, disrupt block finalization & Compromised orders’ sabotage consensus & Ordering service (consensus mechanism) & Compromise of the majority of ordered nodes & Reduced throughput, reduced successful transactions, stalled block finalization & High \\ \hline Malicious Client Attack & Overwhelm ordering service and day consensus & Flooding ordering service with high transaction volume & Ordering service with high transaction volume & Ability to deploy malicious client applications & Increased delay and decreased throughput for legitimate users & Medium to High \\ \hline Consensus Protocol Attack & Degree performance by manipulating Raft timing parameters & Changing the Raft tick interval (or other parameters) & Ordering service (Raft commers) & Compromised channel manager or ordering nodes with update & Increased latency, decreased throughput & Medium to High \\ \hline Architect 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 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Comparison of HLF attacks. * 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.