# Denial-of-Service Attacks on Permissioned Blockchains: A Practical Study
## 5 Experiments and Results
### Attack Simulation
#### 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 1: The network topology of the test bed, which represented a realistic deployment based on the standard HLF network model. Figure 2(a) 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 2(b) 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,  
Figure 3: Comparison of transaction delay and throughput in batch time-out attack. Figure 2: Batch time-out attack scenario where the attacker increases the batch time-out parameter in the ordering service configuration. 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.