Blockchain-Enabled Decentralized End Hopping for Proactive Network Defense

Abstract

As network attack methods continue to evolve, flooding attacks remain a major threat that causes network paralysis and service disruption. Statically configured systems are particularly vulnerable, as attackers can exploit reconnaissance information to launch large-scale attacks, while conventional defense mechanisms often fail under high-intensity traffic. To address this problem, this paper introduces Moving Target Defense (MTD) within a decentralized framework and proposes a blockchain-based decentralized End Hopping system. The system employs the Practical Byzantine Fault Tolerance (PBFT) consensus protocol for dynamic controller election and incorporates a disaster recovery mechanism, which eliminates single points of failure while ensuring reliable controller transitions and rapid service restoration. Experimental results demonstrate that the proposed system achieves satisfactory performance in terms of availability, effectiveness, and security, providing a practical approach to constructing robust proactive defense networks.

1. Introduction

In recent years, the proliferation of network services has been accompanied by a persistent threat from flooding attacks, which remain the leading cause of network and service outages. Driven by the static configuration of cyber systems, flooding attacks have become increasingly accessible through Distributed Denial-of-Service (DDoS)-as-a-Service platforms and botnet rental services [1,2]. Static system or network configurations enable attackers to perform reconnaissance on target systems, identify potential vulnerabilities, and subsequently select optimal attack vectors to launch devastating, large-scale cyber-attacks. Traditional mitigation solutions (e.g., firewalls and intrusion prevention systems) are also often unable to handle the massive volume of traffic directed at the target system. In addition, cloud-based or content delivery-based mitigation solutions typically incur prohibitive economic costs [3].

Moving Target Defense (MTD) has been developed to achieve dynamic and proactive network defense by altering attack surfaces to invalidate the intelligence that attackers collect during reconnaissance [4,5]. To increase the uncertainty of network or system configurations, various MTD techniques have been proposed in recent years, which can be grouped into three main categories: network-level MTD, host-level MTD, and application-level MTD [6]. Network-level MTD modifies network configuration parameters and topologies (e.g., IP mutation and network topology shuffling). Host-level MTD focuses on switching hosts and operating systems. Techniques that alter application types or randomize memory layouts are classified as application-level MTD.

In recent years, several network-level MTD techniques have been proposed to counter flooding attacks, including End Hopping [7,8], MT6D (Moving Target IPv6 Defense) [9], and software-defined networking (SDN)-based MTD [10]. However, these techniques rely on a static, centralized controller, which introduces a critical vulnerability: a single-node failure caused by system crashes or targeted attacks can disable the entire defense mechanism. This centralization risk remains a fundamental obstacle to the broader adoption of network-level MTD.

An alternative approach to countering flooding attacks is cooperative mitigation, in which multiple systems share defense resources and capabilities [11]. When an attack is highly sophisticated and no local countermeasure is available, a targeted domain can request assistance from any member of the alliance. However, the strategic intelligence exchanged among participants may be compromised by malicious members. Furthermore, establishing consensus (i.e., an incentive mechanism that fosters cooperative behavior) is essential for the reliable operation of such systems. Achieving this consensus, therefore, requires a trusted and dependable environment.

In this paper, we adopt End Hopping as a representative network-level MTD technique. Inspired by frequency hopping in military communications, End Hopping mitigates threats such as Denial-of-Service (DoS) attacks and eavesdropping by pseudo-randomly mutating the communication endpoints during transmission, including ports, IP addresses, time slots, cryptographic algorithms, and protocols [7].

Exploiting the decentralization, trustlessness, and traceability of blockchain technology, we propose a private blockchain network composed of multiple End Hopping servers that enables dynamic controller switching while supporting cooperative mitigation. However, merely distributing the controller across multiple nodes is insufficient for security-critical environments. Traditional distributed systems (e.g., cloud clusters) operate under the assumption that nodes fail only by halting (crash faults). In adversarial settings, it must be assumed that the controller itself may be subverted (Byzantine faults) and issue malicious hopping patterns that expose the network.

Therefore, a private blockchain is necessary over standard distributed databases for two reasons. First, it provides Byzantine Fault Tolerance: through PBFT consensus, the network can reject malicious hopping strategies issued by a compromised controller, which preserves the integrity of the defense mechanism. Second, it provides immutable synchronization: a tamper-proof ledger of hopping schedules ensures that all legitimate nodes synchronize to identical moving-target parameters ($F_{hop}$) without relying on a blind trust model. In addition, all hopping strategies and user data are recorded on the blockchain, ensuring the trustworthiness of inter-node communication.

The main contributions of this paper are summarized as follows:

(1)

A blockchain-based decentralized network-level MTD system model is presented in detail, comprising a dynamic controller and normal servers. The Practical Byzantine Fault Tolerance (PBFT) algorithm is employed to elect the dynamic controller.

(2)

The security challenges facing the proposed system are analyzed, and corresponding countermeasures are provided.

(3)

Targeted experiments are conducted to evaluate the availability, effectiveness, and security of the proposed decentralized network-level MTD system.

The remainder of this paper is organized as follows. Section 2 reviews network-level MTD and private blockchain technologies, focusing on the limitations of static controllers that motivate the proposed decentralized approach. Section 3 describes the architecture of the proposed blockchain-based End Hopping system. Section 4 provides a security analysis against various threat models. Section 5 presents the implementation details and experimental results. Finally, Section 6 concludes the paper and outlines directions for future work.

2. Related Work

This section reviews the literature in two areas: network-level Moving Target Defense (MTD) and private blockchain technology. We examine existing MTD strategies with a focus on the security risks arising from their reliance on centralized controllers and justify the adoption of a private blockchain as a solution.

2.1. Moving Target Defense

Moving Target Defense (MTD) counters the asymmetric advantage of attackers by dynamically altering system configurations, which invalidates intelligence gathered during reconnaissance [12]. MTD techniques can be categorized into three layers according to the defense surface. Host-level MTD focuses on rotating the execution environment; techniques such as virtual machine live migration and platform diversity shuffling disrupt co-residency attacks and persistent footholds by reconfiguring the underlying infrastructure, as exemplified by the Adaptive Defense Agent (ADA) [13], which employs container orchestration for infrastructure-level rotation. Application-level MTD introduces diversity into application code and memory layout through techniques such as Address Space Layout Randomization (ASLR) and Instruction Set Randomization (ISR), which prevent memory corruption exploits by randomizing entry points and execution paths [14]. Network-level MTD, the primary focus of this work, obfuscates communication paths and network topologies to counter reconnaissance and flooding attacks. As a representative network-level MTD technique, End Hopping(also known as IP/Port Hopping) pseudo-randomly rotates communication parameters (IP addresses, ports, and protocols) to filter malicious traffic [7]. Other network-level approaches include MT6D (Moving Target IPv6 Defense) [9], which exploits the large IPv6 address space for address mutation, and SDN-based MTD [15], which employs software-defined controllers to dynamically remap virtual IPs. However, these architectures share a common limitation: the Static Controller Paradox. Most network-level MTD systems depend on a static, centralized controller (e.g., an SDN controller or a synchronization server) to manage hopping patterns. Such a controller constitutes a single point of failure (SPoF) and a high-value target for DoS attacks [16]. Once the controller is compromised, the entire defense mechanism is neutralized.

2.2. Private Blockchain for Decentralized Control

Since the introduction of cryptocurrencies such as Bitcoin [17], blockchain technology has received considerable attention and has been applied to finance, public services, the Internet of Things (IoT), and reputation systems [18,19,20]. To justify the design of the proposed decentralized framework, it is necessary to distinguish among blockchain architectures and explain why a private blockchain is selected for MTD.

2.2.1. Public vs. Private Blockchain Architectures

Blockchain networks are broadly classified into public and private types, each involving different trade-offs in performance, security, and privacy [21,22]. In public networks (e.g., Bitcoin, Ripple), any participant can join and query the ledger without prior identification. However, these networks rely on Proof of Work (PoW) or Proof of Stake (PoS) consensus mechanisms, which consume substantial energy, time, and computational resources [21]. Moreover, the transparency of public ledgers is detrimental to MTD, as it may expose defense strategies to adversarial analysis [23]. In contrast, private blockchains are governed by authenticated internal nodes, and ledger data remains confidential from external entities. Because participant nodes are restricted and pre-authorized, private blockchains offer higher transaction throughput, lower costs, stronger privacy guarantees, and greater resistance to malicious attacks [24].

2.2.2. Applications in Trusted Environments

Private blockchains are favored by organizations that require high security, well-defined trust boundaries, and explicit role management [25]. Prior studies have demonstrated the effectiveness of private blockchains in eliminating single points of failure (SPoF) and resolving multi-party trust issues in security-critical environments.

For instance, Li et al. proposed a private blockchain-based distributed Public Key Infrastructure (PKI) to mitigate the vulnerabilities of centralized Certificate Authorities (CA) [26]. Miao et al. designed a natural gas IoT architecture using a side-chain/backbone model to address the deficiencies of centralized energy supply architectures [27]. Shahid et al. used the immutability and traceability of blockchain to construct a supply chain management solution [28]. Collectively, these studies demonstrate that private blockchains can reduce centralization risks while maintaining a trusted environment.

2.2.3. Justification for Private Blockchain in MTD

Based on the properties discussed above, a private blockchain is essential for the proposed decentralized End Hopping system for three reasons. First, regarding performance and latency, MTD requires rapid synchronization of hopping parameters to maintain service continuity. Public blockchains exhibit high latency (on the order of seconds to minutes per block), whereas private blockchains achieve substantially lower latency (e.g., sub-second finality for simple transactions) [29], which is critical for sustaining the hopping rhythm ($F_{hop}$). Second, regarding confidentiality, transaction data in public blockchains is visible to all participants. A private blockchain ensures that hopping parameters remain encrypted and accessible only to authorized defense nodes, thereby preventing adversaries from analyzing the ledger to predict future hopping patterns [30]. Third, regarding Byzantine fault tolerance, controller nodes may be compromised in adversarial environments. By employing deterministic consensus algorithms such as PBFT, the network can tolerate the compromise of up to one-third of its nodes. If a compromised controller issues a malicious hopping strategy, it is rejected by the consensus of honest nodes, a level of resilience that centralized architectures cannot provide [26].

Overall, the proposed system employs a private blockchain to establish a trusted, high-speed, and fault-tolerant environment for generating and synchronizing hopping strategies, which addresses the centralization bottleneck of traditional MTD architectures.

2.3. Comparative Analysis with State-of-the-Art Solutions

To contextualize the proposed system, this section compares it with two representative categories of existing MTD solutions: IPv6-based MTD (e.g., MT6D [9]) and SDN-based MTD (e.g., RHM [31] and FRVM [15]).

2.3.1. Comparison with IPv6-Based MTD

MT6D exploits the large address space of IPv6 to rotate interface identifiers and conceal communication endpoints [9]. However, MT6D typically depends on pre-shared keys or a centralized synchronization gateway to maintain the hopping rhythm between communicating parties. If the synchronization server is compromised or subjected to DoS attacks, the defense mechanism may fail. In contrast, the proposed system employs a decentralized blockchain ledger for synchronization. Even if some nodes fail, the PBFT consensus ensures the consistency and availability of synchronization parameters ($F_{hop}$), thereby eliminating the single point of failure inherent in centralized synchronization schemes.

2.3.2. Comparison with SDN-Based MTD

SDN-based solutions, such as Random Host Mutation (RHM) [31] and Flexible Random Virtual IP Multiplexing (FRVM) [15], use the programmability of SDN controllers to dynamically map virtual IPs to real IPs. Although these methods effectively protect the Data Plane, they suffer from the “Static Controller Paradox”: the controller orchestrating the defense is itself static and centralized. Adversaries can bypass the moving targets by directly attacking the controller [3]. Moreover, traditional SDN controllers lack built-in mechanisms to verify the intent of flow rules, which leaves them vulnerable to malicious commands if hijacked. The proposed system implements “Dual Hopping,” rotating both the Data Plane (End Hopping) and the Control Plane (Dynamic Controller Election). By integrating PBFT consensus, the proposed system can identify and reject malicious strategies issued by compromised nodes, providing a level of Byzantine fault tolerance that standard SDN-MTD architectures lack.

2.3.3. Forensics and Traceability

A common limitation of traditional End Hopping and SDN-MTD is the volatility of network configurations. Once a hop occurs, the previous state is lost, making post-attack forensics and attribution extremely difficult. The proposed solution uses the immutability of the private blockchain to record every hopping strategy and user state transition as a transaction. This creates a tamper-proof historical ledger that enables administrators to replay the network topology at any past moment for forensic analysis.

The qualitative comparison is summarized in

Table 1. Comparison of the proposed system with state-of-the-art MTD solutions.

Feature	MT6D [9]	SDN-MTD [15]	Proposed System
Defense Scope	Data Plane (IPv6)	Data Plane (Virtual IP)	Data & Control Plane
Controller Architecture	Static/Gateway	Static/Clustered	Dynamic (Elected)
Single Point of Failure	High (Sync Server)	High (Controller)	Eliminated (Disaster Recovery)
Byzantine Fault Tolerance	No	No	Yes (PBFT)
Forensics Capability	Ephemeral (Low)	Log-based (Mutable)	Blockchain (Immutable)
Trust Model	Trusted Endpoints	Centralized Trust	Zero-Trust/Consensus

.

3. Model Sketch

As introduced in Section 1, End Hopping achieves proactive network defense by pseudo-randomly mutating the communication endpoints of participating nodes. The End Hopping model is illustrated in Figure 1, which comprises a controller and several End Hopping servers. The controller is responsible for early-warning analysis, cooperative control, and endpoint information management. Each End Hopping server executes proactive defense operations according to the controller’s instructions and provides services to End Hopping clients.

In this paper, we adopt End Hopping as a representative network-level MTD technique and construct a blockchain-based decentralized End Hopping system, as illustrated in Figure 2. Each blockchain node can assume one of two roles: dynamic controller or normal server.

3.1. Dynamic Controller Node

To address the centralization problem caused by the static controller in existing End Hopping systems, we randomly elect a participating node to serve as the dynamic controller, thereby achieving controller decentralization. The election is performed through the PBFT consensus mechanism in the private blockchain. The responsibilities of the dynamic controller are described below.

3.1.1. Synchronization

The synchronization mechanism ensures that End Hopping services remain accessible to authorized clients. In the decentralized End Hopping system, the dynamic controller serves as a communication relay that stores the operational information of each End Hopping server, including the hopping pattern and the hopping rate. The synchronization procedure is as follows:

Step 1:

After the dynamic controller $Nod{e}_{ctl}$ is elected, each authorized End Hopping client receives a notification packet containing the public key of $Nod{e}_{ctl}$.

Step 2:

Each End Hopping server $Nod{e}_{srv}$ uploads its real-time hopping strategy and user data.

Step 3:

The authorized End Hopping client requests access to the End Hopping service by broadcasting a request packet encrypted with the public key of $Nod{e}_{ctl}$, which includes the client’s own public key.

Step 4:

$Nod{e}_{ctl}$ verifies the identity of the client and then randomly selects an End Hopping server $Nod{e}_{srv}^{\prime }$ as the response server. After encrypting the hopping strategy of $Nod{e}_{srv}^{\prime }$ with the public key of the client, $Nod{e}_{ctl}$ replies with the encrypted strategy.

Step 5:

Based on the hopping strategy received from $Nod{e}_{ctl}$, the client connects to $Nod{e}_{srv}^{\prime }$.

Step 6:

After a new controller election round, the synchronization procedure is re-established following the steps described above.

3.1.2. Adaptive Control

The hopping strategy (i.e., the hopping pattern and hopping rate) is critical to the proactive defense capability of the End Hopping system. A higher hopping rate and a more complex hopping pattern increase the attack difficulty and cost, which strengthens the proactive defense capability. However, such aggressive strategies also degrade system performance and the quality of End Hopping services.

To balance system performance and proactive defense capability, the dynamic controller performs adaptive control, as illustrated in Figure 3. By monitoring and analyzing real-time network traffic, the dynamic controller identifies the presence of attack traffic and automatically adjusts the hopping strategy. The dynamic controller issues the updated hopping strategy by initiating transactions to the End Hopping servers, ensuring that the strategy is recorded on the blockchain.

Owing to the immutability of the blockchain, each End Hopping server follows the existing hopping strategy recorded on the blockchain until it receives new adjustment commands from the next dynamic controller, which ensures that the MTD configuration remains consistent after a controller switch. Meanwhile, the immutable hopping strategy can serve as forensic evidence, providing a verifiable record when a malicious controller issues incorrect or inappropriate hopping strategies.

3.1.3. Disaster Recovery Mechanism

The capacity of a single End Hopping server to handle high-volume, high-concurrency traffic is inherently limited, and the server will inevitably become unavailable under powerful flooding attacks. To address this extreme scenario, the dynamic controller migrates user data from the disabled server to other operational servers, thereby restoring the network service rapidly; this process is referred to as disaster tolerance recovery, as illustrated in Figure 4. Because each End Hopping server regularly uploads its user data and real-time hopping strategy to the blockchain, the dynamic controller can recover the service with minimal disruption by exploiting the traceability property of the blockchain.

3.2. Normal Server Node

Each participating node operates as an End Hopping server for the majority of the time. Two key mechanisms deployed on the normal server are introduced in this section.

End Hopping: The End Hopping server achieves proactive network defense by continuously mutating the communication endpoints (e.g., IP address, port, and protocol) in a pseudo-random manner. Taking IP address and port as examples, End Hopping can be expressed as $EndHopping$: $(I{P}_{pool};Por{t}_{pool};F_{hop})$, where $I{P}_{pool}=\{I{P}_1;I{P}_2;\cdots ;I{P}_m\}$ and $Por{t}_{pool}=\{Por{t}_1;Por{t}_2;\cdots ;Por{t}_n\}$.

Let $\delta$ denote the switching process of $(IP;port)$ from time t to time $t+1$,

$$\begin{array}{c}\hfill \delta :H\left(t\right)\stackrel{F_{hop}}{⟶}H(t+1)\end{array}$$

(1)

where $F_{hop}$ denotes the hopping strategy, $H\left(t\right)$ represents the combination of IP and port at time t, denoted by ${(IP;port)}_t$, and $\delta$ is the switching process of $(IP;port)$ from time t to time $t+1$.

Server message uploading: After a new controller is elected, each End Hopping server uploads its real-time hopping strategy and user data (e.g., the client list and user status) by initiating transactions to the controller, enabling the new controller to take over the system promptly. In addition, the hopping strategy and user data are uploaded periodically during normal operation, facilitating rapid disaster tolerance recovery with minimal service disruption by exploiting the traceability of the blockchain.

3.3. Justification for Blockchain Integration

The integration of a private blockchain is motivated by specific security requirements of End Hopping that neither centralized nor conventional distributed controllers can satisfy. MTD aims to conceal the location of servers; however, if the controller managing these hops is static, it becomes the primary attack target (the “Static Controller Paradox”). The proposed blockchain approach employs random controller elections to apply MTD principles to the control plane itself, making the management layer as elusive as the data layer. In cooperative mitigation scenarios, participating nodes may belong to different security domains. A private blockchain ensures that a malicious hopping strategy issued by a compromised node is rejected by the consensus mechanism before it propagates, a capability that standard master-slave architectures cannot provide.

4. Security Analysis

In this section, we analyze the security of the decentralized End Hopping system.

4.1. Security Challenge and Solution

4.1.1. End Hopping Server Security

In the decentralized End Hopping system, the participating nodes serve as $Server$ for the majority of the time. Therefore, we first analyze the security of $Server$.

Case 1: The unauthorized client attempts to access the End Hopping service directly.

In the access event, the $Client$ must be authorized by $Controller$, which effectively preserves data privacy. To prevent $Server$ from being directly accessed by an unauthorized $Client$, a real-time certificate with an expiration date is used to indicate that the $Client$ has been authorized by $Controller$. First, $Controller$ verifies the identity of $Client$ against the client whitelist. Then, $Controller$ issues a real-time certificate signed with its private key to $Client$. Finally, $Server$ verifies the certificate to confirm whether the $Client$ has been authorized. If verification fails, $Server$ denies the access request.

Case 2: The hopping strategy is eavesdropped by the malicious End Hopping server.

The $CurHopStra$ is crucial to the security of the entire system. If it is leaked to external attackers, they can launch precise attacks, and the proactive defense capability of the system is severely compromised. Moreover, because blockchain data are accessible to every node, the plaintext of $CurHopStra$ must not be transmitted directly, thereby preventing a malicious $Server$ from obtaining its content. To achieve this, $Server$ computes the hash digest of $CurHopStra$ and transmits it to $Controller$ by initiating a transaction. Meanwhile, the plaintext of $CurHopStra$ is encrypted with the public key of $Controller$ and sent via normal network packets. Consequently, $Controller$ can both verify the integrity of $CurHopStra$ and prevent it from being eavesdropped on by a malicious $Server$.

Case 3: The malicious End Hopping server refuses to upload the server message.

To ensure reliable system operation, each $Server$ must upload its server message within a specified time window. The penalty mechanism is implemented as a smart contract on the private blockchain. The contract maintains a state mapping table on the ledger that tracks the block height of the latest heartbeat message ($H_{last}$) for each registered server. A system-wide threshold parameter, ${\Delta }_{max}$, defines the maximum allowable silent period, measured in blocks.

The detection logic is triggered either periodically or on demand. If the difference between the current block height $H_{cur}$ and the last update height satisfies $H_{cur}-H_{last}>{\Delta }_{max}$, the smart contract executes the penalty logic, which includes freezing the assets of the node and revoking its authorized identity. The logical flow is presented in Algorithm 1.

Algorithm 1 Penalty mechanism for non-compliant servers.

Require: $ServerID$, $CurrentBlockHeight\left(H_{cur}\right)$; Ensure: $CandidateWhitelist$, $AccountStatus$; 1:   $H_{last}\leftarrow$ GetLastUpdateBlock($ServerID$); 2:   if  $H_{cur}-H_{last}\le {\Delta }_{max}$  then 3:      return Normal; Server is compliant 4:   else 5:      {Timeout detected, trigger penalty} 6:      LockAssets($ServerID$); 7:      RemoveFromWhitelist($ServerID$); 8:      $AccountStatus\leftarrow$ Banned; 9:   end if 10: return $AccountStatus$;

As shown in Algorithm 1, the mechanism operates in three phases. In the state monitoring phase, when a server uploads a hopping strategy or user data, the smart contract updates the corresponding $H_{last}$ to the current block height. In the timeout detection phase, any node (typically the Controller) can invoke the check function, which compares the current block height against the recorded $H_{last}$ to determine whether the silent period exceeds ${\Delta }_{max}$. Upon confirming a violation, the contract atomically executes the penalty: (1) the staked deposit of the offending server is frozen; (2) the address of the server is removed from the active_node_list, thereby preventing it from participating in future consensus rounds or service allocation. This on-chain automated execution eliminates the need for manual intervention and ensures tamper-proof enforcement of the penalty.

Case 4: The historical hopping strategy requires immutable verification for post-attack forensics and non-repudiation.

A key advantage of the blockchain-based architecture is the ability to audit the “Moving Target.” In traditional MTD, ephemeral configurations are lost after each hop, which makes post-attack forensics infeasible. In the proposed system, every hopping strategy ($F_{hop}$) is recorded as a transaction on the immutable ledger. If a legitimate client is denied service or a server is breached, administrators can replay the exact network configuration at the time of the incident, providing evidence that distinguishes between system malfunction and malicious activity.

4.1.2. Discussion: Privacy and Access Control Challenges

The decentralized blockchain architecture also introduces challenges regarding data transparency and access authority. Unlike centralized databases, the blockchain ledger is replicated across all participating nodes. Although the private blockchain restricts external access, internal nodes (which may be compromised or “honest-but-curious”) possess a full copy of the ledger. This raises privacy concerns regarding sensitive user data (e.g., real IP addresses of clients) and defense parameters (e.g., the seed of the hopping algorithm). The key risks are identified below, along with preliminary mitigation strategies.

To mitigate internal privacy leakage risks, one potential approach is to apply granular encryption to on-chain data. Sensitive payloads recorded in transactions, such as the User Status List and the Hopping Strategy ($F_{hop}$), would be encrypted with the public key of the target entity (the current Dynamic Controller or the specific End Hopping Server) before being broadcast. The transaction metadata (timestamp, sender, and receiver) would remain visible on the ledger for auditability, whereas the semantic content would be opaque to unauthorized nodes. Consequently, even if a participant node is subverted, it would not be able to decrypt the defense strategies of other honest nodes, which preserves the confidentiality of the MTD configuration.

The rotation of the Dynamic Controller also introduces the risk of authority confusion, where a retired malicious controller might attempt to issue unauthorized certificates to illegitimate clients. A possible countermeasure is a smart contract-enforced role-based access control (RBAC) system linked to the PBFT consensus epochs. The smart contract would maintain a dynamic mapping of the current controller authority. Upon completion of a controller election (Section 3.1), it would automatically revoke the write-permission of the previous controller and register the public key of the newly elected node. End Hopping Servers would then query the smart contract to verify client certificates; a certificate would be considered valid only if it was signed by the key of the controller active at the time of issuance. Such a mechanism could prevent “Zombie Authority” attacks and ensure synchronized access control across the decentralized network. The detailed implementation and formal verification of these strategies are left for future work.

4.1.3. Flooding Attack

Network flooding attacks have long been a standard technique in an attacker’s arsenal for denying service. The attacker sends a massive volume of traffic to a target server with the aim of exhausting all its resources so that it cannot process legitimate service requests. Servers with static network configurations are particularly vulnerable to flooding attacks. By contrast, a server employing End Hopping can effectively filter bogus traffic and extend its service lifetime by continuously mutating the communication endpoints. Let the IP pool be $\{I{P}_1;I{P}_2;\cdots ;I{P}_m\}$ and the port pool be $\{Por{t}_1;Por{t}_2;\cdots$; $Por{t}_n\}$. The number of $(IP,port)$ combinations is $mn$, and the service lifetime of the End Hopping server is:

$$\begin{array}{c}\hfill T_a=T_0\left(1+\sum _{i=1}^{m-1}i{\displaystyle \frac{C_{mn-1}^1}{C_{mn}^i{C}_{mn-1}^1}}\right)\end{array}$$

(2)

where $T_0$ denotes the service lifetime of a traditional server without End Hopping under the same conditions. It is evident that the service lifetime $T_a$ is positively correlated with the number of $(IP,port)$ combinations. Let the flooding attack intensity be $S_{atk}$ and the hopping rate be v; the average attack intensity per $(IP,port)$ combination is:

$$\begin{array}{c}\hfill aveAtt={\displaystyle \frac{S_{atk}}{mnv}}\end{array}$$

(3)

In Equation (3), the average attack intensity is inversely proportional to the hopping rate for a fixed number of $(IP,port)$ combinations. A server with a low hopping rate remains vulnerable to targeted attacks, as the long hopping interval provides a skilled attacker sufficient time to reconnoiter the system and launch a precise flooding attack. Conversely, a $Server$ with a high hopping rate can substantially disrupt attackers and effectively reduce the attack intensity. Therefore, the hopping rate should be increased as much as possible. However, as the hopping rate increases, the performance overhead on the server becomes non-negligible. It is evident that the capability of a single server to withstand flooding attacks is limited, and the decentralized End Hopping system offers a more promising defense against powerful flooding attacks.

4.2. Robustness

In the decentralized End Hopping system, both the $Controller$ and the End Hopping $Server$ exhibit strong robustness. To address controller centralization, a participating node is randomly elected via the blockchain to serve as the dynamic $Controller$, thereby achieving controller decentralization. The election is performed through the PBFT consensus mechanism, which is a replication algorithm capable of tolerating Byzantine faults.

In addition, all legitimate nodes are eligible to be promoted from $Server$ to the next $Controller$, which effectively eliminates the single point of failure of $Controller$. However, a single End Hopping server can hardly withstand a powerful flooding attack. Therefore, the disaster tolerance recovery mechanism ensures rapid service restoration by migrating user data from the disabled $Server$ to other operational servers, which further demonstrates the robustness of the decentralized End Hopping system.

5. Experimental Analysis

A prototype of the decentralized End Hopping system has been implemented in Python 3.8 and Java 8. The system is deployed on seven Linux PCs, of which five constitute the core network, the sixth operates as the End Hopping client, and the seventh acts as the external attacker. The PC configuration is listed in

Table 2. Linux PCs configuration.

Item	Configuration
CPU	Intel(R) Core(TM) i7-7700
Operation system	Ubuntu 16.04
Memory	8G
Hard disk	1T

. Among the five core network nodes, four are assumed to be benign and one is malicious, satisfying the fault tolerance requirement of Byzantine fault-tolerant protocols. To evaluate the availability, effectiveness, and security of the decentralized End Hopping system, we conduct targeted tests on both the dynamic controller and the normal server.

5.1. Dynamic Controller

To address the centralization caused by the static controller in existing End Hopping systems, a participating node is randomly elected to serve as the dynamic controller, thereby achieving controller decentralization.

5.1.1. Decentralization Test

To address the centralization caused by the static controller in existing End Hopping systems, a participating node is randomly elected to serve as the dynamic controller in each round. In this test, we record the frequency with which each node serves as the dynamic controller. After 500 rounds, the frequency distribution is shown in Figure 5.

As shown in the figure, the election frequencies of the five nodes are 100, 93, 102, 98, and 107, respectively, with all values exceeding 90. The results indicate that each node has an approximately equal probability of being elected as the dynamic controller, confirming that the End Hopping system has eliminated the static controller mode and achieved controller decentralization.

5.1.2. Robustness Test

In the decentralized End Hopping system, the election of the temporary controller is performed through the PBFT consensus mechanism, which is a replication algorithm capable of tolerating Byzantine faults. Since all legitimate nodes are eligible to be promoted from End Hopping server to the next dynamic controller, single-node failure is effectively eliminated, and the dynamic controller maintains strong robustness.

To compare the robustness of the dynamic controller and the static controller, we launch a flooding attack using Hping3 v3.0.0 against both modes and record their response times to client requests. The switching period of the dynamic controller is set to 1 min, the flooding attack rate is 100 Mbps, and the attack begins at the 2nd minute. The results are shown in Figure 6.

Initially, the response times of both modes are comparable. However, the flooding attack initiated at the 2nd minute causes a significant increase in response time, so that both controllers are unable to respond to requests by the 3rd minute. In subsequent measurements, the static controller remains permanently disabled by the flooding attack. In contrast, the negative impact on the dynamic controller is short-lived. After the 3rd minute, a newly elected dynamic controller takes over the decentralized End Hopping system, and the response time returns to normal, demonstrating the strong robustness of the dynamic controller against powerful flooding attacks.

5.2. Normal Server

5.2.1. Hopping Rate Test

As analyzed previously, the hopping rate is critical to the proactive defense capability of the End Hopping system. In this test, Apache serves as the End Hopping server to provide web services, and the web page loading time is recorded as the response time using JMeter v4.0. Flooding attacks are launched against four servers with different hopping rates using Hping3 v3.0.0, and the results are shown in Figure 7.

The results indicate that the response time of all servers increases gradually at the beginning. As the attack intensity increases, the response time of servers with low hopping rates (e.g., 1 hop/s or 10 hops/s) rises sharply once the attack intensity exceeds 45 Mbps. By contrast, the server operating at 100 hops/s exhibits a smaller increase in response time, demonstrating that End Hopping can effectively protect web services from flooding attacks and that a higher hopping rate provides stronger proactive defense capability.

However, increasing the hopping rate incurs a non-trivial cost, as higher End Hopping rates lead to non-negligible server performance degradation.

To quantify this trade-off, we analyze the latency overhead observed in the experiments. As shown in Figure 7, under non-attack conditions, the baseline response time for low-frequency hopping (e.g., 1 hop/s) remains minimal, whereas for the 100 hops/s configuration, the response time increases to 1200 μs. We define the performance cost ratio ($R_{cost}$) as:

$$R_{cost}={\displaystyle \frac{T_{high\_rate}}{T_{baseline}}}$$

(4)

Comparing the 100 hops/s mode (1200 μs) against the low-rate modes (approximately 300 μs in the initial phase), the latency increases by a factor of 4 ($R_{cost}\approx 4.0$). This increase is attributed to the frequent re-establishment of connections and the synchronization overhead incurred at high frequencies. The quantitative comparison is summarized in

Table 3. Quantitative analysis of latency trade-offs (non-attack scenario).

Hopping Rate	Response Time (μs)	Relative Overhead
Low (1 hop/s)	≈300 (Baseline)	1.0× (Ref)
Medium (10 hops/s)	≈450	≈1.5×
High (100 hops/s)	1200	≈4.0×

.

This 4× latency penalty justifies the Adaptive Control mechanism (Section 3.1.2), which activates the high-cost, high-security mode (100 hops/s) only upon threat detection and defaults to a low-rate mode to preserve performance during normal operation.

5.2.2. Disaster Tolerance Recovery

End Hopping can effectively protect system services from flooding attacks. However, the defense capability of a single server is limited. By comparison, the decentralized End Hopping system exhibits strong robustness against powerful flooding attacks, maintaining normal service operation through the disaster tolerance recovery mechanism. To verify this, we launch high-intensity flooding attacks against both Apache and Vsftpd servers using Hping3 and record the web page loading time as the response time of the web service and the text file download time as the response time of the FTP service. With the hopping rate set to 10 hops/s, the following results are obtained.

As shown in Figure 8, both modes exhibit the same growth trend in response time when the attack rate is in the range of 0–40 Mbps, indicating that the servers can still withstand flooding attacks at this intensity. As the attack intensity increases, neither the static nor the dynamic mode can operate normally when the attack rate reaches approximately 60 Mbps. However, the web service in dynamic mode recovers immediately even as the attack intensity continues to increase. This is because the dynamic controller migrates user data from the disabled server to other operational servers, which makes continued attacks against the disabled server ineffective.

The response time of the FTP service under the disaster tolerance recovery test is shown in Figure 9. For the FTP service, both modes exhibit the same growth trend in response time when the attack rate is in the range of 0–30 Mbps, but neither can operate normally when the attack rate reaches 40 Mbps. Owing to the disaster tolerance recovery mechanism, the FTP service also recovers rapidly even as the attack intensity continues to increase. These results confirm that the disaster tolerance recovery mechanism ensures strong robustness of the End Hopping service against powerful flooding attacks.

5.3. Network Performance

To evaluate the network performance of the two controller modes, we use Hping3 v3.0.0 to launch TCP-SYN flooding attacks with a packet size of 65,495 bytes. The bandwidth is recorded using Iperf v3.1.3, and the results are shown in Figure 10. Both modes initially achieve a maximum bandwidth of approximately 92 Mbps. However, the bandwidth of the static mode drops sharply to 17.70 Mbps when the attack rate reaches 500 packets/s and falls to its minimum value at 1000 packets/s. In contrast, the dynamic mode maintains substantially higher performance, reaching its minimum bandwidth of 2.25 Mbps only at an attack rate of 3000 packets/s. These results demonstrate that the decentralized End Hopping system achieves superior network performance compared with the static centralized system.

5.4. Scalability Analysis and Discussion

The proposed system exhibits robustness and low latency in small-scale networks; however, scalability remains a concern as the network grows. The system employs the PBFT consensus algorithm for Byzantine fault tolerance, which has $O\left(N^2\right)$ message complexity, where N denotes the number of participating nodes.

As N increases, the number of messages exchanged during the three-phase consensus process (pre-prepare, prepare, and commit) grows quadratically. Existing studies on PBFT performance indicate that the system maintains high throughput with low latency when $N\le 20$. Beyond 50–100 nodes, consensus latency increases significantly, potentially affecting the frequency of dynamic controller elections.

In the context of End Hopping for proactive defense, participant nodes are trusted entities within a security alliance (e.g., core servers or gateways of an organization). The network size is naturally bounded and unlikely to reach public blockchain scale. For the target deployment scenario (4 to 16 core nodes in a consortium), the current architecture strikes a satisfactory balance between security and performance, prioritizing strict consistency and security over massive scalability.

For larger-scale deployments, optimized consensus mechanisms such as sharding or hierarchical PBFT (e.g., partitioning nodes into consensus groups) could reduce the message complexity from $O\left(N^2\right)$ to $O\left(N\right)$ or $O\left(\log N\right)$.

6. Conclusions and Future Work

This paper applies network-level Moving Target Defense (MTD) to address security vulnerabilities in network infrastructure. A decentralized End Hopping system built on a private blockchain is proposed to overcome the limitations of existing network-level MTD techniques. Compared with other mainstream network-level MTD approaches, the proposed system demonstrates strong resistance to flooding attacks. The system achieves controller decentralization through the PBFT consensus mechanism, whose fault tolerance and disaster recovery capabilities render it robust against both Byzantine faults and high-intensity flooding attacks.

In future work, this blockchain framework will be extended beyond network-level defense. The decentralized consensus mechanism can be adapted to host-level and application-level MTD scenarios. For instance, the immutable ledger and PBFT consensus can be employed to synchronize the rotation schedules of virtual platforms (host-level) or to distribute randomization seeds for software diversity (application-level) across distributed clusters, thereby eliminating single-point failures in these domains.

Although this paper presents the implementation logic of the smart contract-based penalty mechanism, the study focuses primarily on architectural feasibility. Stress testing of the smart contract logic, including gas cost analysis and response latency under extreme congestion, will be conducted in subsequent work to validate the efficiency of the mechanism. Finally, although this paper identifies the privacy and access control challenges introduced by controller decentralization and outlines preliminary mitigation strategies (Section 4.1.2), the detailed implementation, formal security proofs, and experimental validation of these mechanisms remain important directions for future investigation.