# On the relevance of Blockchains for DDoS Mitigation: a Methodological Assessment and Performance Evaluation of Hyperledger Fabric

Constant Rohmer, Pierre Alain, Mohamed-Aymen Chalouf, Guillaume Doyen

<figure><img src="image_1.png" /></figure>

## To cite this version:

Constant Rohmer, Pierre Alain, Mohamed-Aymen Chalouf, Guillaume Doyen. On the relevance of Blockchains for DDoS Mitigation: a Methodological Assessment and Performance Evaluation of Hyperledger Fabric. 2025 34th International Conference on Computer Communications and Networks (ICCCN), Aug 2025, Tokyo, France. pp.1-9, 10.1109/ICCCN65249.2025.11133718. hal-05317890

HAL Id: hal-05317890

https://hal.science/hal-05317890v1

Submitted on 16 Oct 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# On the relevance of Blockchains for DDoS Mitigation: a Methodological Assessment and Performance Evaluation of Hyperledger Fabric

Constant Rohmer*, Pierre Alain*, Mohamed-Aymen Chalouf*, Guillaume Doyen†

*SOTERN - IRISA (UMR CNRS 6074), Rennes University,

†SOTERN - IRISA (UMR CNRS 6074), IMT Atlantique,

*†{constant.rohmer, pierre.alain, mohamed-aymen.chalouf, guillaume.doyen}@irisa.fr

***Abstract***—The expanding attack surface and increasing complexity of information systems render human responses insufficient against modern threats. The introduction of concepts such as self-protection and collaborative cybersecurity opens up possibilities for new defence systems tailored to today's requirements. Distributed Denial-of-Service (DDoS) attacks, in particular, demand automated and wide-reaching responses due to their disruptive nature and broad impact across networks. Recent research is exploring blockchain-based solutions to address the fundamental challenge of trust among collaborators, as blockchain provides a secure and transparent framework for sharing threat intelligence and enforcing consensus. However, the literature did not establish the relevance of blockchain technology for collaborative DDoS mitigation before its application. The contribution of this paper is twofold. First, we methodologically analyse the relevance of blockchain technology for our use-case and determine that Hyperledger Fabric (HLF) is a promising solution. Second, we evaluate the performance impacts of HLF combined with the SmartBFT consensus algorithm for collaborative DDoS attack mitigation. Our performance analysis measured system durations ranging from 200 to 1500 ms under various network configurations, influenced by topological size (number of nodes) and geographical size (communication delays). The modeling of our results showed quadratic scaling with the number of HLF orderers and stronger, linear scaling with communication delays. These findings provide actionable insights to optimise collaborative blockchain-based DDoS mitigation solutions.

***Index Terms***—Collaborative Cybersecurity, Blockchain, Hyperledger Fabric, Performance

## I. INTRODUCTION

The diversification and multiplication of Internet applications, services and users has led to a significant increase in the global attack surface. Consequently, information systems are faced with a growing number of threats that require rapid reactions to limit their impact. However, current defence systems often still rely on human intervention, a process that has become too slow given the speed of modern attacks and the complexity of the systems to be protected [1]. This situation necessitates a re-evaluation of modern defence strategies, with an emphasis on approaches capable of ensuring an automatic and coordinated response to threats. The concept of self-protection [2] emerged in this context to enable systems to manage their security autonomously and react to attacks in real-time. Today, this automation is paving the way for larger-scale solutions, such as collaborative self-protection. This

approach leverages the sharing of information between independent systems, enabling more effective collective detection and response to attacks through the collaboration of multiple participants. One significant application area of collaborative cybersecurity is the mitigation of Distributed Denial-of-Service (DDoS) attacks. The increasing frequency and sophistication of these attacks necessitate the implementation of robust and wide-ranging mitigation strategies. Traditional approaches, which rely on individual Autonomous Systems (ASes) to address attacks independently, are often insufficient due to the distributed nature of these threats.

In this context, the use of blockchain technology has emerged as a promising solution to address the inherent issues of trust in collaborative efforts [3]. Collaborative DDoS mitigation, which employs blockchain technology, aims to enable the secure and efficient sharing of threat intelligence across multiple ASes. This approach provides a more comprehensive defence mechanism thanks to the decentralised and tamper-resistant nature of the blockchain. For such approach to succeed, it is fundamental to evaluate the technical choices that best meet the requirements of collaborative DDoS mitigation, and to assess whether the chosen solution can achieve acceptable performance in real-world scenarios. The development of different types of blockchains (i.e. permissionless and permissioned) expands the choices available for storage technology. However, despite its rapid development and increasing adoption in the research, blockchain technology is not necessarily suitable for all use-cases and should therefore not be used by default.

As a result, our research questions are: (1) How are the blockchain-based DDoS mitigation solutions implemented in the state-of-the-art, and are they methodologically relevant? (2) Can such solutions achieve acceptable performance for DDoS mitigation? This paper answers these questions by: (1) investigating and applying Wüst and Gervais' methodology [4] to determine the most appropriate type of blockchain for collaborative DDoS mitigation, and comparing the findings with the state-of-the-art. (2) Based on the gaps and strengths identified in the state-of-the-art, we evaluate to what extent a combined solution leveraging Hyperledger Fabric (HLF) and the SmartBFT consensus can satisfy the real-time performance requirements of collaborative DDoS mitigation.
The rest of this paper is organised as follows. Section II gives some useful background on blockchain technology and HLF, and presents relevant related works. Section III presents our methodological analysis of the problem requirements and confronts it to the state-of-the-art. In section IV, we describe the state-of-the-art inspired solution we implemented, before detailing the conducted performance evaluation and discussing our results. Section V finally concludes this paper and specifies the future works we identified.

## II. BACKGROUND AND RELATED WORKS

This section provides background information on general blockchain technology, with a specific focus on HLF as it is the blockchain we selected for our implementation and performance evaluation. We then present related works on the use of blockchain for collaborative DDoS mitigation.

### A. Background

1) *Blockchain Concepts*: A blockchain is a ledger where each block is linked to its predecessor using a cryptographic hash function, ensuring integrity and chronological order of transactions. Transactions, initiated and executed by peers, are stored in blocks. Initially used for financial transactions, as seen with Bitcoin, blockchain technology has since evolved to support a variety of applications including maintaining records of any kind, and executing arbitrary code through smart contracts.

Smart contracts are self-executing code stored in the blockchain that automatically enforce contract terms when predefined conditions are met. They eliminate intermediaries and increase transaction efficiency and transparency.

Blockchain's properties make it a robust architecture for collaborative applications among non-trusting entities. The integrity of data is ensured by the ledger's structure as a linked list of blocks, preventing tampering by unauthorised parties. Additionally, non-repudiation ensures that recorded transactions cannot be denied or reversed, fostering accountability and trust among participants.

Blockchain networks can be categorised using two parameters: access control and data validation policy. The access control defines who can read the blockchain data. Public vs. private blockchains refer to participation capabilities. Public blockchains allow anyone to participate, while private blockchains restrict participation with a central authority or consortium. The data validation policy determines who can write data and participate in the consensus process. Permissionless vs. permissioned blockchains relate to participant requirements. Permissioned blockchains enhance privacy and speed up transactions by limiting consensus to a few known participants. As for permissionless blockchains, they let any participant validate transactions and contribute to the consensus process without requiring permission from any authority.

Consensus mechanisms enable non-trusting blockchain peers to agree on transaction validity and maintain the blockchain's integrity. Notable mechanisms include proof-based consensus, such as Proof of Work for Bitcoin [5], where

<figure><img src="image_3.png" /><figcaption>Fig. 1: The three phases (*Execute*, *Order*, *Validate*) of a transaction processing in Hyperledger Fabric</figcaption></figure>

participants solve complex puzzles in a resource-intensive process called mining, providing high security, and Proof of Stake for Ethereum [6], which selects participants based on their token holdings, offering more energy efficiency. In contrast, committee-based consensus like Practical Byzantine Fault Tolerance (PBFT) [7] use a voting process to reach consensus, functioning efficiently even if up to one-third of nodes act maliciously.

2) *Hyperledger Fabric Concepts*: HLF is a private permissioned blockchain featuring a modular architecture adaptable to various use cases. It supports different consensus protocols and container technology for hosting smart contracts.

An HLF network connects multiple organisations that collaboratively maintain a private ledger. The ledger is composed of a world-state database to maintain its current state and a blockchain to store the immutable sequence of state transitions: the transactions inside the blocks. The transactions result from chaincode (i.e., smart contract) invocations. Furthermore, organisations can be enrolled in multiple private subnets or channels with their own ledger and chaincodes, which is crucial for privacy in competitive environments.

Each organisation maintains one or more peer nodes that host the ledger and the chaincodes of every channel the organisation is a member of. HLF follows the *Execute, Order, Validate* phases as shown in Figure 1.

1) *Execute*: Clients send transaction proposals to the peers, who are responsible for executing and endorsing them.

2) *Order*: The peers send the signed and verified transactions to the ordering service, shared by all the channels, which orders the transactions into blocks following the consensus protocol.

3) *Validate*: The new block, agreed upon by the orderers, is sent back to the peers that validate and commit the transactions sequentially.

In its latest version (v3.0.0), HLF supports two different committee-based consensus protocols. Raft [8] is a Crash-Fault Tolerant ordering service following the “leader and follower” model. An election designates one ordering node per channel as its leader, whose decisions will be replicated by the other
<figure><img src="image_4.png" /><figcaption>Fig. 2: Visualisation of the related works for blockchain-based DDoS mitigation</figcaption></figure>

orderers called the followers. SmartBFT [9] is a Byzantine Fault Tolerant consensus algorithm inspired by PBFT. A leader is elected among the orderers, and is continuously monitored by the followers. If the followers suspect the leader is faulty, it can be rotated out, allowing consensus to continue with a new leader.

## B. Related Works

Our research is based on a comprehensive survey by Miller and Pahl [3] that provides valuable insights into collaborative cybersecurity using blockchain. Similar to other domains, blockchain is used in many collaborative cybersecurity applications such as intrusion detection, DDoS defence, or secured data sharing.

We added other articles to the ones identified by Miller and Pahl to ensure the completeness of the work, using the same search methodology they used. An overview of this selection is presented in Figure 2. The use of blockchain enables non-trusting ASes to exchange information (e.g. malicious IP addresses) about ongoing attacks and mitigate the latter on a wider scale with an inter-AS network. When under attack, an AS can issue an alert on the blockchain network to notify other participating ASes. Ethereum and HLF are the two blockchain technology used, they represent respectively ten [10]–[19] and four [20]–[23] out of the fifteen papers studied, one of them [24] using both Ethereum and HLF for comparison. According to [3], Ethereum remains the most used technology for blockchain-based cybersecurity solutions. Its popularity stems from its smart contract capabilities, which are effective for DDoS mitigation, as shown in several studies. Its accessibility and established ecosystem of decentralised applications, built with the specialised programming language Solidity, further enhance its appeal. However, the same survey indicates a shift away from Ethereum as organisations increasingly adopt technologies such as the open-source private permissioned blockchain HLF. Despite the relative scarcity of studies using

HLF for DDoS attacks mitigation, its growing popularity can be attributed to its advanced privacy features and modular architecture.

Multiple papers implemented inter-AS collaboration to share blacklisted IP addresses [18]–[20]. Others also incorporated the sharing of whitelists [10], [11]. Various papers have addressed different limitations of the base scenario. For instance, [14], [15] minimised on-chain data storage by leveraging distributed storage solutions like InterPlanetary File System (IPFS) [25] or Swarm<fnref n="1" />. Papers such as [13], [17] implemented incentives and reputation mechanisms to enhance cooperation and prevent free-riding behaviours (consuming without contributing) within collaborative networks. Additionally, [21] developed a recursive algorithm to enable a precise reaction with intra-AS mitigation to trace the source of attacks within the network. Two papers focused on multiple features: [16] explored off-chain storage and reputation mechanisms, while [12] implemented reputation mechanisms and precise reaction with intra-AS mitigation. Finally, some papers focused on earlier stages of the mitigation, such as [22] for the detection of attacks and [23] for botnet prevention.

Despite the proposal of numerous solutions for collaborative DDoS mitigation, the performance evaluation of the proposed solutions is lacking in nearly half of the studied papers. In fact, only nine out of the fifteen papers show performance evaluations [15]–[22], [24] but only two of them conducted a thorough evaluation: [20] evaluated duration and throughput of an HLF-based solution and [15] evaluated the performances of their solution in a Wide-Area Network (WAN). Our work aims to evaluate the relevance of blockchain technology and address the identified lack of evaluation by presenting a precise reproducible performance evaluation in real-world conditions.

## III. ASSESSING BLOCKCHAIN RELEVANCE IN THE STATE-OF-THE-ART

In this section, we will ensure the usefulness of using blockchain technology, compared to more conventional solutions such as centralised databases, for collaborative DDoS mitigation.

### A. Blockchain Needs and Fit

We apply the structured approach from Wüst and Gervais [4] to answer our first research question: whether the blockchain-based DDoS mitigation solutions implemented in the state-of-the-art are methodologically relevant? The process is also depicted in Figure 3. To identify the most appropriate blockchain type and decide between Permissionless, Public Permissioned, Private Permissioned, and not using blockchain, six questions, (1) to (6), need to be answered. Our answers to these questions are highlighted in Figure 3 and we detail them below.

The first objective of a collaborative DDoS mitigation solution is to let a given AS store (1) the malicious IP addresses for them to be retrieved by other participants. There

<footnote n="1">¹https://www.ethswarm.org/swarm-whitepaper.pdf</footnote>
<figure><img src="image_5.png" /><figcaption>Fig. 3: Application of a decision flow chart [4] to determine whether a blockchain is the appropriate technical solution for collaborative DDoS mitigation</figcaption></figure>

will be multiple writers (2), as any participating AS should be able to broadcast IP addresses. The system can not rely on an always online Trusted Third-Party (TTP) (3) as it would introduce a new SPoF that would make it vulnerable to DDoS attacks itself. To prevent malicious individuals from posing as ASes, only known and authorised ASes should be able to participate in the network (4). In such a network, ASes (i.e. the writers) should not be trusted (5), as errors, conflicts of interest, or collusion could lead to biased or inaccurate data, compromising network integrity. Finally, the public verifiability is not required (6) as ASes' security policies are strictly confidential and should therefore not be available publicly. Based on these criteria, the most appropriate technical solution for a blockchain-based DDoS mitigation solution is a private permissioned blockchain.

## B. State-of-the-art Analysis

As mentioned in Section II-B, Ethereum and HLF are the two blockchain technologies used by state-of-the-art works. HLF is a private permissioned blockchain and is therefore fully suited for this use. On the other hand, Ethereum is widely used thanks to its smart contracts and decentralised applications but is a public permissionless blockchain, which we deduced from Figure 3 to be inappropriate for our use. Although the solutions presented in the papers using Ethereum are based on a public permissionless blockchain, it can be argued that they are working as a private permissioned blockchain. Solidity,

the language used to code smart contracts, can be used to restrict the smart-contracts' access to a limited set of Ethereum wallet addresses in a similar way as in private permissioned blockchains. Contrarily to platforms explicitly designed for privacy in a controlled environment like private permissioned blockchain, Ethereum was not designed for this purpose and is therefore not adapted. Even if Ethereum's design makes it sufficiently adaptable to this use, it is the smart contracts developers' responsibility to embed the needed features into the code which makes these implementations less reliable and robust than purposefully private permissioned blockchain platforms. As such, we believe that Ethereum should not be used for this use-case any longer, as more robust and mature platforms exist for this specific use.

Moreover, switching from Ethereum to private permissioned blockchains should also be motivated by their respective performance. As shown by [4], permissioned blockchains generally exhibit higher throughputs and lower latencies than permissionless blockchains, which is a key point for DDoS mitigation as the mitigation time should be as short as possible to limit the disruptions. These performance differences are mainly due to the fact that the consensus can be quicker among fewer and known participants, which is only possible in a permissioned environment. The management of permissioned blockchains can be ensured by a not-always online TTP that could be responsible for the generation of certificates thereby avoiding a SPoF once the network is up and running [4].
<figure><img src="image_6.png" /><figcaption>Fig. 4: Our network topology and mitigation algorithm</figcaption></figure>

Consequently, as HLF is a private permissioned blockchain gaining importance in blockchain-based collaborative cyber-security [3], we believe that it should be further studied in order to benefit from its latest version. In fact, the five studies using HLF [20]–[24] were conducted with older versions of HLF, which included weaker consensus algorithms that were not resistant to Byzantine behaviours.

Combined with the lack of performance evaluations identified in section II-B, the results of this methodological analysis motivated the work presented in the remaining sections of this paper: the performance evaluation of a baseline solution implemented with HLF.

## IV. PERFORMANCE TESTS AND RESULTS

In this section, we detail the state-of-the-art inspired solution we implemented, followed by the results of its performance evaluation.

### A. Evaluation scenario

The main objective of state-of-the-art collaborative DDoS mitigation solutions is to enhance the scope of mitigation by sharing malicious IP addresses through an inter-AS blockchain network. Our goal is to use a network consistent with the state-of-the-art [18]–[20] and deploy it using HLF. We therefore opt for the network shown in Figure 4 which involves one HLF organisation for each of the four ASes (AS1 to AS4) participating to the network. Moreover, we consider this a reasonable number of ASes to illustrate meaningful collaboration while remaining manageable for deployment and analysis.

With the introduction of SmartBFT [9] in HLF v3.0.0, a new security mechanism is now available for blockchains built with HLF. To the best of our knowledge, HLF v3.0.0 and SmartBFT have not yet been used or evaluated for DDoS mitigation. Given that SmartBFT generally exhibits lower performance than its predecessor Raft [8], we aim to evaluate the performance of this new algorithm in our context. This evaluation will help determine if SmartBFT can provide an important security layer without significantly compromising the efficiency and response duration crucial for effective DDoS mitigation strategies.

The use of HLF lets us benefit from its capability to support multiple isolated channels within the same network, each with its own access control policy to restrict access to a subset of participants. The implemented solution therefore adopts a two-layer approach. The first layer is an inter-AS channel used to securely share malicious IP addresses between participants which is a very common approach in the state-of-the-art as mentioned in section II-B. The second layer consists of an intra-AS channel for each AS to manage its internal configurations, and specifically blacklist the malicious IP addresses advertised on the inter-AS channel. As such, each AS is enrolled in both the inter-AS channel and its dedicated intra-AS channel without having access to the intra-AS channels of the other ASes. It is worth noting that the intra-AS channels we implemented do not handle the generation of the configuration to specific devices (e.g. firewalls or routers) or the generation of filter rules from the list of malicious IP addresses. The goal of this study is to ensure that the list of malicious IP addresses can be disseminated quickly and efficiently to every member of the collaborative network.

Figure 4 outlines the implemented steps. We assume that the AS hosting the victim of the attack begins mitigation immediately after detecting the attack. This process starts either before or concurrently with the advertising of the malicious IP addresses to the inter-AS channel (0). Upon detecting a DDoS attack, the affected AS publishes a list of malicious IP addresses on the inter-AS channel (1), making it accessible to network members. Each partner AS is then alerted and retrieves this list (2). Subsequently, each AS disseminates the list to mitigating devices (e.g., firewalls and routers) via their independent intra-AS channels (3). The implementation concentrates on the sharing and dissemination of this list. For a fully operational solution, the next step would involve configuring these devices to apply targeted mitigation based on the AS's internal security policies. Consequently, the implemented collaborative solution ends when every AS has successfully written the malicious IP addresses into their intra-AS ledger. This ensures that the malicious traffic will be blocked in every participating AS and let us evaluate the exact total time needed for sharing malicious IP addresses.

Although the use of blockchain is justified for the inter-AS channel according to the decision tree presented in Figure 3, it may not seem necessary for the intra-AS channels as each AS independently decides whether to adopt one. However, we argue that it is beneficial for ASes to continue using a blockchain for their intra-AS channels. Doing so eliminates the SPoF of a centralised system and increases the robustness of their intra-AS configuration management.

For illustrative purposes, we place the attackers within AS3's and AS4's networks (Figure 4). However, attackers do not need to be within a participant AS's network for such a solution to be effective, as malicious traffic will be blocked throughout the entire collaborative network, with greater benefits as more ASes join.
<figure><img src="image_7.png" /><figcaption>Fig. 5: Average duration (ms) depending on the number of peers/AS (*p*), the number of orderers (*o*) and the inter-AS delay (*d* in ms). To ensure the readability of the figures, we set the parameters to *p* = 2, *o* = 8, and *d* = 20ms when necessary, and represented the data for *o* = 4, 8 and 14 only on Figure 5a.</figcaption></figure>

## B. Implementation

Our tests were performed on a single Ubuntu 24.04 machine equipped with a 4-core Intel Xeon W-2223@3.6GHz, 32GB of RAM and a 512GB NVMe. In order to guarantee the automation and reproducibility of our tests, we developed a configurable platform handling the HLF's deployment on Docker containers. We use the latest available HLF release at the time of writing and the consensus SmartBFT. Our platform also deploys a Prometheus server for monitoring purposes and gathers the relevant metrics at run-time.

Our initial experiments evaluate the impact of network topology size, specifically the number of peers and orderers (see Section II-A2), on system performance. It is important to note that since the network was emulated on a single machine, inter-node communication was instantaneous, resulting in an unrealistic scenario where communication delays were negligible compared to those observed on the Internet. However, this setup allows us to analyse the algorithmic and system-level performance without the influence of delays. Given that the system is intended for deployment across potentially vast geographical areas, it is important to assess its performance in a realistic context. To emulate real-world conditions, we introduced communication delays using the command-line tool *tc netem add delay*. Following Zhang and He's work [26], which demonstrated that the Pareto distribution can effectively model end-to-end delays on the Internet, we adopted this distribution for our simulations. We introduced a 2ms delay for intra-AS communications, assuming minimal latency within an AS. For inter-AS communications, we applied one-way delays of 0ms, 20ms, 40ms and 80ms to account for variability due to factors such as geographical distance, routing, and network disruptions. The range of one-way delays 0-80ms, i.e. 0-160ms for Round-Trip Time (RTT) delays, was chosen based on Martinez et al.'s study [27] on RTT delays across the Internet, as it covers the average measured RTT in 2022 for every continent.

We measured the performances of our solution for 1 to 4 peers per AS (peers/AS), 4 to 14 orderers and 0-80ms inter-AS communication delays. Our tests consisted of 100 executions

of the scenario presented in Section IV-A for each combination of (peers/AS, orderers, delay) resulting in 17600 executions in approximately 40 hours of run-time. Our methodology involved deploying the network once for each combination of (peers/AS, orderers, delay), followed by executing the 100 runs sequentially. This approach minimises the overhead associated with redeploying the network for each run and allows us to smooth out the effects of the execution server's processor or disk load, resulting in near-zero confidence intervals that are not shown in the figures.

## C. Results

Our testbed is described by 3 parameters: *p* the number of peers per AS, *o* the number of orderers for the consensus, and *d* the inter-AS communication delay in ms. To effectively present the results, we vary two parameters while keeping the third fixed. The selected fixed values are *p* = 2 peers/AS, *o* = 8 orderers, and a *d* = 20ms inter-AS communication delay when required. These values represent a minimal redundancy scenario for peers and orderers, while the 20ms one-way inter-AS delay aligns with the average measured RTT for Europe and North America in 2022, which is approximately 40ms [27]. The observed trends remain consistent across various combinations of peers/AS, orderers, and inter-AS communication delays.

1) *HLF performance analysis:* Figure 5 depicts the average duration in milliseconds (ms) of our tests depending on *p*, *o* and *d*. This duration corresponds directly to the time measured from the detection of an attack to the effective sharing of its information to the entire network of ASes. The obtained results show that duration ranges from 200ms for the minimal network on a local machine (i.e. *p* = 2, *o* = 4 and *d* = 0ms) to 1500ms for the largest network size and the maximum inter-AS delay (i.e. *p* = 4 and *d* = 80ms), regardless of the number of orderers. Duration increases with the three parameters: *p*, *o* and *d*, though not at the same rate. Figure 5a shows a linear evolution along *p*. This can be explained by the fact that messages returned to ASes must be sent to all peers. Figure 5b shows a different behaviour, with duration
<figure><img src="image_8.png" /><figcaption>Fig. 6: Detailed Transaction Lifecycle average duration (ms) depending on the number of peers/AS (p), the number of orderers (o) and the inter-AS delay (d in ms).</figcaption></figure>

evolving quadratically along o. This quadratic increase with the number of orderers can be attributed to the intrinsic nature of the consensus algorithm. Specifically, SmartBFT scales with $\Theta(o^2)$ due to the n-to-n communication round between orderers during its Prepare phase [9]. However, while this quadratic increase is evident for small values of d (0ms and 20ms), it appears to stabilise for d = 80ms. Figure 5c shows a linear evolution of the duration with the inter-ASes delay.

The relationship between the total duration and the three parameters is captured by the regression model defined as follows:

$$ \mathcal{D}(p, o, d) = 237.7 - 16.1p - 22.6o + 14.2d + 6.8po + 0.2od + 2.0o^2 - 0.02o^2d \quad (1) $$

where D is the average duration in ms. This equation accurately models our measures with a correlation coefficient of $r^2 = 0.995$. The regression is also represented on Figure 5. The regression equation corroborates that while duration increases linearly with p and d, it exhibits a quadratic increase with o. The duration stabilisation from a quadratic form to an almost linear form observed on Figure 5b can be explained by the $o^2d$ negative term in Equation (1). The quadratic increase due to $o^2$ is offset by the increase in d. This term can be interpreted as a parallelisation factor, where a sufficient delay allows the orderers to complete the necessary computations while awaiting further messages. Despite the quadratic scaling along o, it is the inter-AS delay that has the most significant impact on the total duration of the tests, as shown in Figures 5b and 5c.

The different metrics directly provided by HLF to Prometheus offer a detailed overview of the transaction lifecycle. We grouped these different metrics in the three phases of the lifecycle: Execute, Order and Validate (Figure 1). The respective average durations of each of these phases are presented in Figure 6 depending on p (Figure 6a), o (Figure 6b) and d (Figure 6c). The results align with our previous analysis: the test duration is significantly impacted by the Order phase, which involves the consensus algorithm, while the Execute and Validate phases remain negligible. Furthermore, the Order

phase is exclusively affected by increasing d, remaining stable with changes in p and o. Additionally, the durations of the Execute and Validate phases slightly increase with the network's topological size (increasing p and o), but remain relatively constant with increasing geographical size (d).

2) Comparison to the state-of-the-art: Our testbed exhibits a total duration between 200 and 1500ms depending on network size and inter-AS delays. Table I summarises the main characteristics of three state-of-the-art solutions [10], [12], [20] and compares them to our implementation. Among the reviewed studies, two use Ethereum as their blockchain technology, while the third one employs HLF. All the solutions focus on reaction and inter-AS collaboration, with [12] also incorporating detection capabilities and supporting both intra- and inter-AS scenarios for a more targeted approach. Regarding the network environment, [12], [20] were conducted in a local setting and [10] over a WAN. We used an emulated WAN for our assessment as it allows for more controlled testing conditions while still approximating real-world network complexities. Performance evaluations were thorough in two of the studies, while one was limited. There is a notable duration discrepancy between Ethereum and HLF, as HLF does not have a fixed delay between the emission of two blocks, whereas Ethereum can emit a block every 15 seconds. This explains the higher observed durations in studies such as [10], [12] and further disqualifies Ethereum-based solution for performance-sensitive applications such as collaborative DDoS mitigation. Comparing our results to those of [20] is challenging due to several differences in the corresponding implementations. We use different versions of HLF with varying consensus algorithms: they employed the Solo consensus, which is suitable for proof of concept but not recommended for production due to its lack of fault tolerance [20]. Actually, the Solo consensus uses a single orderer to create blocks, whereas SmartBFT requires at least four orderers. SmartBFT is more security-oriented as it necessitates a two-third majority among the orderers and three communication rounds [9]. This is obviously more than for Solo where no communication round is required for the consensus, and even more than the Raft consensus mentioned earlier in Section II-A2 which requires
<table><caption>TABLE I: State-of-the-art solutions comparison</caption><thead><tr><th>Paper</th><th>BC Tech</th><th>Use-case</th><th>Scope</th><th>Network</th><th>Performance Evaluation</th><th>Measured Duration</th></tr></thead><tbody><tr><td>Rodrigues et al. [10]</td><td>Ethereum</td><td>Reaction</td><td>Inter-AS</td><td>WAN</td><td>Thorough</td><td>15 to 35s</td></tr><tr><td>Pavlidis et al. [12]</td><td>Ethereum</td><td>Detection &amp; Reaction</td><td>Intra-/Inter-AS</td><td>Local</td><td>Limited</td><td>30s</td></tr><tr><td>Hajizadeh et al. [20]</td><td>HLF v1.1</td><td>Reaction</td><td>Inter-AS</td><td>Local</td><td>Thorough</td><td>5s @ 100TPS</td></tr><tr><td><strong>Our assessment</strong></td><td>HLF v3.0.0</td><td>Reaction</td><td>Intra-/Inter-AS</td><td>Emulated WAN</td><td>Thorough</td><td>200ms to 1.5s</td></tr></tbody></table>

2 communication rounds between orderers [9]. This increased security affects consensus performance, with an even greater impact in a WAN as shown by [9]. Our experiments emulate a WAN with inter-AS communication delays, and we maintain a single transaction per run, unlike varied transaction throughputs in [20] (Transactions Per Second, TPS). Considering these differences and assuming all other factors (e.g., transaction throughput) are equal, we expect the solution presented in [20] to demonstrate better performance than our implementation, despite our use of a newer and more robust version of HLF.

## D. Discussion

Our results highlight the impact of the number of peers/AS, the number of orderers and the inter-AS delay on the performance of an HLF network. This brings new insights on the use of HLF and SmartBFT for a blockchain-based collaborative DDoS mitigation network. However, our emulation operates under controlled conditions with no concurrent alerts which renders throughput evaluation not possible. Although these conditions could be more realistic, they were essential for identifying bottlenecks that are likely to be amplified in a more realistic environment. Therefore, studying these parameters separately is crucial to precisely evaluate their impact on overall performance.

1) Architecture recommendations: Based on our findings, we can provide detailed insights into the optimal provisioning of nodes for a blockchain-based collaborative DDoS mitigation solution. Deploying a single peer/AS is insufficient due to redundancy concerns, as it would introduce a SPoF. Implementing at least two peers/AS enhances fault tolerance and operational continuity, allowing for horizontal scaling by dynamically increasing the number of peers. In contrast, the number of orderers must be more carefully determined due to the observed quadratic scaling. This necessitates a delicate balance between performance and resource allocation. While the compensation identified through the $o^2d$ term in Equation 1 can mitigate the impact of the quadratic scaling, it is crucial to note that shorter inter-AS communication delays will amplify the effect of the number of orderers on the duration. However, even with this amplification, improving network performance will remain beneficial, as it results in faster overall performance compared to using fewer orderers with longer delays. We propose distributing two orderers/AS. This maintains a low total number of orderers while enabling each AS to participate in the consensus process. It also avoids introducing a new SPoF that would occur if all orderers were hosted in the same location. Given the security requirements of the SmartBFT consensus, an attacker would need to compromise one third of the orderers to affect the network. In our tests, this translates

to compromising two out of the four ASes, thereby achieving a high-level of security. For greater number of participating ASes, we recommend reducing to one orderer/AS as this will limit the total number of orderers while still allowing every AS to participate in the consensus process. Finally, as our results indicate that the inter-AS communication delay is the most critical parameter affecting the total duration, the most impacting choice to improve its performance will be to collaborate with ASes that are geographically close, in order to maintain a low inter-AS communication delay.

2) Real-world implications: In a real environment, the independence of ASes raises a question about the choice of location for the orderer nodes. Considering the role of the orderers in an HLF network, this implies that every block, from either inter-AS or intra-AS channels, must be agreed upon by the orderers hosted by every AS. This is the goal of the implemented solution for the inter-AS, but it is debatable for the intra-AS. A failure of the collaborative network would hinder the AS in their internal management, contradicting their independence. These reflections do not question our assessment, as everything was hosted on the same machine; however, they pose a problem for a real environment. We therefore suggest that if an AS chooses to handle its internal configuration management with HLF, it should be done in a separate, and local HLF deployment. This ensures that the orderers responsible for the consensus will be hosted internally and that no internal data will be processed outside of the AS.

For further context, existing commercial solutions like CloudFlare's Magic Transit<fnref n="2" /> can detect and mitigate DDoS attacks typically within three seconds. Although this solution does not use collaborative blockchain technology, this comparison highlights that an HLF-based solution is competitive in terms of mitigation speed while bringing added security guarantees with a Byzantine-tolerant consensus and the absence of a SPoF. This demonstrates that blockchain-based solutions can be compared to operational solutions that rely on distributed server farms with centralised communication and synchronisation. Moreover, it underscores that state-of-the-art solutions based on Ethereum, which are not inherently designed for such performance, fall short, potentially leading to the misconception that blockchain cannot be a viable alternative to current client/server architectures like CloudFlare's.

## V. CONCLUSION AND FUTURE WORKS

In this paper, we first conducted a methodological analysis of the problem requirements and the state-of-the-art in the context of blockchain-based collaborative DDoS mitigation.

<footnote n="2">²https://www.cloudflare.com/network-services/products/magic-transit/</footnote>
Secondly, we performed a thorough performance evaluation of a baseline solution leveraging HLF and the SmartBFT consensus algorithm. Our findings indicate that while HLF provides a robust framework for such applications, performance is significantly influenced by the number of peers and orderers in the network, as well as the inter-AS communication delay. By integrating communication delays into the model, we enabled more precise comparisons with existing solutions and gained a deeper understanding of the network's behaviour under real-world conditions. Based on our methodological and performance analysis, we demonstrated the relevance of HLF and SmartBFT, as well as provided precise architectural recommendations to enhance the effectiveness and efficiency of blockchain-based collaborative DDoS mitigation approaches.

Future works should include scenarios with multiple concurrent alerts to assess HLF's duration under worst-case conditions, providing valuable insights into the system's throughput under heavy load. Another area for improvement is the generalisation of such solution to different types of attacks as sharing attack information can be beneficial for mitigating various attack types. Lastly, it is worth noting that recent research has explored the detection of attacks using blockchain technology. Combining detection and mitigation solutions could significantly enhance our overall capability to handle cybersecurity threats.

## ACKNOWLEDGEMENTS

This study is partially supported by the ANR within the framework of the PIA EUR CyberSchool project (ANR-18-EURE-0004) and the CMA Cyberskills4all project (ANR-23-CMAS-0026)

## REFERENCES

[1] N. Zuk, "Welcome to the Era of Autonomous Security," Feb. 2022. [Online]. Available: https://www.paloaltonetworks.com/blog/2022/02/extended-security-intelligence-and-automation-management/

[2] J. Kephart and D. Chess, "The vision of autonomic computing," Computer, vol. 36, no. 1, pp. 41-50, Jan. 2003, conference Name: Computer. [Online]. Available: https://ieeexplore.ieee.org/document/1160055/?arnumber=1160055

[3] L. Miller and M.-O. Pahl, "Collaborative Cybersecurity Using Blockchain: A Survey," Mar. 2024, arXiv:2403.04410 [cs].

[4] K. Wust and A. Gervais, "Do you Need a Blockchain?" in 2018 Crypto Valley Conference on Blockchain Technology (CVCBT). Zug: IEEE, Jun. 2018, pp. 45-54.

[5] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008.

[6] V. Buterin, "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform." 2014.

[7] M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," USENIX Association, vol. 3rd Symposium on Operating Systems Design and Implementation (OSDI 99), 1999.

[8] D. Ongaro and J. Ousterhout, "In Search of an Understandable Consensus Algorithm."

[9] A. Barger, Y. Manevich, H. Meir, and Y. Tock, "A Byzantine Fault-Tolerant Consensus Library for Hyperledger Fabric," Jul. 2021, arXiv:2107.06922 [cs].

[10] B. Rodrigues, T. Bocek, A. Lareida, D. Hausheer, S. Rafati, and B. Stiller, "A Blockchain-Based Architecture for Collaborative DDoS Mitigation with Smart Contracts," in Security of Networks and Services in an All-Connected World, D. Tuncer, R. Koch, R. Badonnel, and B. Stiller, Eds. Cham: Springer International Publishing, 2017, vol. 10356, pp. 16-29, series Title: Lecture Notes in Computer Science.

[11] M. Essaid, D. Kim, S. H. Maeng, S. Park, and H. T. Ju, "A Collaborative DDoS Mitigation Solution Based on Ethereum Smart Contract and RNN-LSTM," in 2019 20th Asia-Pacific Network Operations and Management Symposium (APNOMS). Matsue, Japan: IEEE, Sep. 2019, pp. 1-6.

[12] A. Pavlidis, M. Dimolianis, K. Giotis, L. Anagnostou, N. Kostopoulos, T. Tsigkritis, I. Kotinas, D. Kalogeras, and V. Maglaris, "Orchestrating DDoS mitigation via blockchain-based network provider collaborations," The Knowledge Engineering Review, vol. 35, p. e16, 2020.

[13] B. Rodrigues and B. Stiller, "Cooperative Signaling of DDoS Attacks in a Blockchain-based Network," in Proceedings of the ACM SIGCOMM 2019 Conference Posters and Demos. Beijing China: ACM, Aug. 2019, pp. 39-41.

[14] L.-Y. Yeh, J.-L. Huang, T.-Y. Yen, and J.-W. Hu, "A Collaborative DDoS Defense Platform Based on Blockchain Technology," in 2019 Twelfth International Conference on Ubi-Media Computing (Ubi-Media). Bali, Indonesia: IEEE, Aug. 2019, pp. 1-6.

[15] B. Rodrigues, L. Eisenring, E. Scheid, T. Bocek, and B. Stiller, "Evaluating a Blockchain-based Cooperative Defense," 2019.

[16] L.-Y. Yeh, P. J. Lu, S.-H. Huang, and J.-L. Huang, "SOChain: A Privacy-Preserving DDoS Data Exchange Service Over SOC Consortium Blockchain," IEEE Transactions on Engineering Management, vol. 67, no. 4, pp. 1487-1500, Nov. 2020.

[17] B. Rodrigues, S. Trendafilov, E. Scheid, and B. Stiller, "SC-FLARE: Cooperative DDoS Signaling based on Smart Contracts," in 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). Toronto, ON, Canada: IEEE, May 2020, pp. 1-3.

[18] Z. El Houda, A. S. Hafid, and L. Khoukhi, "Cochain-SC: An Intra- and Inter-Domain Ddos Mitigation Scheme Based on Blockchain Using SDN and Smart Contract," IEEE Access, vol. 7, pp. 98 893-98 907, 2019.

[19] S. Alharbi, D. Alghazzawi, A. Hakeem, L. Mohaisen, L. Cheng, and A. Attiah, "A Blockchain-Based Collaborative Intrusion Detection Systems Framework," IEEE Internet of Things Journal, pp. 1-1, 2023.

[20] M. Hajizadeh, N. Afraz, M. Ruffini, and T. Bauschert, "Collaborative Cyber Attack Defense in SDN Networks using Blockchain Technology," in 2020 6th IEEE Conference on Network Softwarization (NetSoft). Ghent, Belgium: IEEE, Jun. 2020, pp. 487-492.

[21] W. Guo, J. Xu, Y. Pei, L. Yin, and C. Jiang, "LDBT: A Lightweight DDoS Attack Tracing Scheme Based on Blockchain," in 2021 IEEE International Conference on Communications Workshops (ICC Workshops). Montreal, QC, Canada: IEEE, Jun. 2021, pp. 1-6.

[22] W. Guo, J. Xu, Y. Pei, L. Yin, C. Jiang, and N. Ge, "A Distributed Collaborative Entrance Defense Framework Against DDoS Attacks on Satellite Internet," IEEE Internet of Things Journal, vol. 9, no. 17, pp. 15 497-15 510, Sep. 2022.

[23] Q. Shafi and A. Basit, "DDoS Botnet Prevention using Blockchain in Software Defined Internet of Things," in 2019 16th International Bhurban Conference on Applied Sciences and Technology (IBCAST). Islamabad, Pakistan: IEEE, Jan. 2019, pp. 624-628.

[24] S. M. Sajjad, M. R. Mufti, M. Yousaf, W. Aslam, R. Alshahrani, N. Nemri, H. Afzal, M. A. Khan, and C.-M. Chen, "Detection and Blockchain-Based Collaborative Mitigation of Internet of Things Bots," Wireless Communications and Mobile Computing, vol. 2022, pp. 1-26, Apr. 2022.

[25] J. Benet, "IPFS - Content Addressed, Versioned, P2P File System," Jul. 2014, arXiv:1407.3561 [cs].

[26] W. Zhang and J. He, "Modeling End-to-End Delay Using Pareto Distribution," in Second International Conference on Internet Monitoring and Protection (ICIMP 2007), Jul. 2007, pp. 21-21. [Online]. Available: https://ieeexplore.ieee.org/document/4271767/?arnumber=4271767

[27] G. Martínez, J. A. Hernández, P. Reviriego, and P. Reinheimer, "Round Trip Time (RTT) Delay in the Internet: Analysis and Trends," IEEE Network, vol. 38, no. 2, pp. 280-285, Mar. 2024, conference Name: IEEE Network. [Online]. Available: https://ieeexplore.ieee.org/document/10155553