Routing Attacks in Ethereum PoS:
A Systematic Exploration

Practicality: BGP hijacking remains a practical threat; despite the growing adoption of RPKI [1], thousands of hijacks [2, 3, 4, 5] are observed each month that even affect IP prefixes protected by RPKI [6]. Critically, as we discuss in this paper, 40.85% of Ethereum nodes are not (properly) protected by RPKI. Beyond the lack of a comprehensive prevention mechanism, two factors make BGP hijacks a particularly practical attack. First, resolving hijacks after they have been detected is a slow manual process, taking at least 2-3 hours even for expert teams [6, 7]. Second, legal repercussions are rare for the attacker, as hijacks are indistinguishable from misconfigurations, which are common [8, 7]. Recent incidents targeting the Celer Bridge [9] and MyEtherWallet [10] further underscore the practicality of BGP hijacking in general and against blockchains. These attacks lasted hours, resulted in multi-million dollar gains despite RPKI, and incurred no consequences for the attackers.

Attacking Ethereum PoS with BGP hijacks: We introduce two representative attacks against Ethereum’s Proof-of-Stake (PoS) protocol: StakeBleed and KnockBlock. In both cases, the attacker controls a BGP-speaking router on the Internet—either through a malicious Internet Service Provider (ISP) or by compromising the infrastructure of a legitimate one (as in  [11, 12]) or by setting up their own Autonomous System (AS) [13]. The two attacks differ in their target selection, level of stealth, and potential impact.

Novelty: While prior work has leveraged network-layer vulnerabilities—particularly BGP hijacks [14, 15, 16, 17]—their impact has largely been confined to PoW-based systems. To our knowledge, this is the first work to exploit Ethereum’s PoS-specific characteristics, enabling both direct financial gain and inflicting financial damage —whereas prior PoW attacks focused primarily on reputational harm [18, 19, 17]. By contrast, recent attacks on PoS Ethereum [20, 21, 22, 23, 24] do not exploit Internet routing vulnerabilities.

Inferring network-level topology of validators: We design a multi-stage algorithm to infer the network-layer locations of Ethereum validators, enabling a realistic assessment of Ethereum’s susceptibility to network-layer attacks and helping operators understand what behaviors may inadvertently reveal their validators. Our algorithm combines a scalable collector (SuperNode) with a multi-stage inference pipeline: (i) SuperNode passively accepts inbound connections, maintaining them just long enough to determine whether the peer hosts a validator. It selectively logs the timing of various types of attestations —along with auxiliary signals such as eagerly pushed or unsolicited messages—to reliably infer validator identities while minimizing resource overhead. (ii) High-confidence mappings are bootstrapped from validators that are activated on the blockchain in sequence and co-located, reflecting a common deployment pattern by a single operator. (iii) These mappings seed a machine learning model that generalizes timing patterns to the broader validator set, allowing us to map it in its entirety. This is possible because, while sequential activation and co-location of validators is not a uniform pattern (e.g., not all validators are activated at the same time, and even those that are might be distributed across locations), the propagation pattern of these nodes is representative of that of any validator node as it reflects protocol-level behavior rather than operator-specific idiosyncrasies. We validate our methodology by verifying that co-located validators are not common in non-consecutive validator IDs, and by observing that validators belonging to distinct Lido operators are often co-hosted with their operators’ websites.

Novelty: Similar analyses exist for PoW-based Ethereum and Bitcoin, but their methodologies do not carry over to PoS. Prior research identified miners—similarly influential nodes—either through the websites of their public Stratum servers [19] or by analyzing block propagation delays using simple heuristics [18], neither of which translates to our setting. The difficulty of constructing a comprehensive validator-to-node mapping in PoS Ethereum is further underscored by recent work, which was only able to infer $\approx 15\%$ of validators [25]. This work is the first to provide a full mapping.

Countermeasures: While securing the entire Internet is the ideal solution to such attacks, it is not within the capabilities of the Ethereum and broader blockchain ecosystem. Hence, we propose countermeasures at the deployment, consensus, and peer-to-peer layers, enabling validator operators, protocol designers, and P2P developers to respond within their respective domains.

Ethics: No real Ethereum clients or IP prefixes were targeted in this study. We have disclosed our findings to the Ethereum Foundation. For details, refer to Appendix F.

Ethereum’s Proof-of-Stake (PoS) system requires validators to deposit 32 ETH and maintain high availability to perform time-sensitive duties that secure the network. In exchange, validators earn rewards proportional to their stake. Validators operate through a set of interconnected clients: the execution client handles transactions and smart contracts, the consensus client manages the PoS logic, and the validator client submits attestations and proposes blocks. Each node in the network is identified via an Ethereum Node Record (ENR), and node participation in the network is dynamic, with frequent churn—the process of nodes entering and exiting the network. At the protocol level, validators contribute to network security and liveness by issuing attestations (votes on block validity and network state) and occasionally proposing blocks that extend the blockchain. Validators are also assigned to committees, which determine which parts of the network they interact with and which messages they are expected to sign.

libp2p is a modular P2P networking stack used by Ethereum. It includes a pubsub system that allows nodes to subscribe to and publish messages in specific topics. Validators subscribe to topics based on their committee assignments, ensuring efficient and relevant message dissemination. Ethereum primarily uses Gossipsub [26], a gossip-based pubsub protocol that maintains a mesh of connections per topic. Gossipsub distinguishes between long-lived (mesh) and short-lived (fanout) peers, and uses heartbeats to maintain mesh health. It relies on several control messages: GRAFT and PRUNE adjust peer connections, while IHAVE and IWANT help peers exchange metadata about unseen messages, ensuring reliable propagation without overwhelming the network.

The Border Gateway Protocol (BGP) [27] is the Internet’s de facto interdomain routing protocol, governing how IP packets are forwarded across Autonomous Systems. ASes exchange routes for IP prefixes, each of which is originated by a single AS and propagated through the network. Routers independently select next hops based on routes advertised by their neighbors. BGP does not verify route authenticity by default, allowing any AS to advertise false routing information. Such false advertisements, known as BGP hijacks, can misdirect traffic to unintended destinations and are a powerful mechanism for traffic interception attacks.

Methodology: Using our validator-to-IP mappings, we resolve routable prefixes, ASNs, ROA coverage, and countries. We obtain routable prefixes and ASNs by querying the RouteViews RIB via the pyASN library [39, 40]. Finally, we map countries using IPInfo Lite [41], and check ROA coverage with Routinator [42].

Validator Centralization High validator concentration increases an attacker’s efficiency in targeting large portions of the network. Ethereum validators are highly centralized at the prefix level: 60% reside under just 100 prefixes, with individual prefixes hosting up to 37,000 validators (Figure 4a). The full set ($N=1,063,660$) spans only 4,600 prefixes, and over a third of it is under just 29 prefixes, meaning a StakeBleed attacker could drive the network into the leak state by hijacking just these prefixes. As a robustness check on our centralization estimates, we repeated the analysis using an alternative mapping methodology (see §D), which reveals even greater centralization.

Validator rewards are multiples of the base reward rate $b$ which scales with the inverse of the square root of the total active stake. Considering Ethereum’s current validator set size of $N=1,063,660$, we derive $b=346$. Rewards and penalties are applied to the validator’s balance, which is used to update its effective balance of 1 ETH increments every epoch. The latter is used in determining the rewards, penalties, and the probability of performing duties other than attesting. In this section we consider all validators to have their initial 32 ETH of actual balance.

Non-hijacked validator rewards: if a StakeBleed attacker hijacks a $p$ fraction of validators, non-hijacked validators lose on average $13148\cdot p-2422\cdot p^{2}$ Gwei per epoch in rewards, which increases to $1384\cdot p+9342$ Gwei if the attacker induces a leak. In the absence of a leak, the losses occur because of three things: (i) attestation rewards as a whole are directly reduced by the fraction of the hijacked stake, (ii) validators voting in a slot of a hijacked proposer are unable to cast a timely head vote, forfeiting that reward, (iii) non-hijacked block proposers are unable to collect attestations and sync contributions from the $p$ fraction of hijacked validators. Putting these together, a validator’s expected per-epoch reward becomes $E[R_{V}]=(1-p)\left[(1-p)R_{h}+R_{s}+R_{t}+\frac{32\cdot R_{P}}{N}\right]+\frac{32\cdot 512\cdot R_{Y}}{N}$. If the attacker forces the chain to enter the leak state, $R_{h},R_{s},R_{t}$ are set to zero, effectively removing attestation rewards. Figure 5a depicts the fraction of the their full expected rewards that validators receive as a function of the hijacked stake. Taken in aggregate, an attacker can cause losses of over 125 ETH per epoch to non-hijacked validators with a partition size of $p>0.33$, as shown in Figure 5c. Note that all rewards $R_{x}$ are multiples of the base reward rate $b$. A reduction in total active stake would increase $b$ and consequently all $R_{x}$ which means that our estimates serve as a lower bound for validator losses.

Hijacked validator rewards: regardless of the leak, hijacked validators miss all rewards since, when they rejoin the network, they adopt the majority view of the chain that non-hijacked validators have as canonical. Instead, hijacked validators incur an attestation penalty that scales as $0.625\cdot n\cdot b$, with $n$ being the validator’s effective balance increments of 1 ETH. For our given $b$, and 32 effective balance increments, this amounts to 6,920 Gwei per epoch. If the attacker triggers a leak, hijacked validators also pay a $\frac{s_{i}\cdot B_{i}}{4\cdot 1677216}$ Gwei penalty on every epoch, where $s_{i}$ is the validator’s inactivity score at epoch $i$ (increases by 4 per epoch hijacked during the leak), and $B_{i}$ is the validator’s effective balance at epoch $i$ (initially $32\cdot 10^{9}$ Gwei). These penalties are depicted in Figure 5b as a function of the hijack length. Depending on the duration of the hijack, the inactivity penalty can continue to apply even after the network exits the leak state. Validators that have their effective stake balance reduced to the 16 ETH threshold are ejected from the active validator set - this takes $\sim$ 3 weeks with a leak for a validator that has a 32 ETH initial balance.

Ethereum’s blockchain throughput in Transactions Per Second (TPS) decreases proportionately when an attacker hijacks a fraction $f$ of validators. This is because block proposers are selected pseudorandomly in proportion to their effective balance. Thus, hijacking fraction $f$ of validators prevents the same fraction of block proposals.

StakeBleed’s costs in practice: We estimate the aggregate losses that a realistic adversary can inflict on validators through penalties and missed rewards. Network operators surveyed on BGP hijacks reported the majority of hijacks lasted over an hour, and their effects spanned for hours or more [43]. We thus consider an adversary with a hijacking time budget of a handful of hours during which she prioritizes hijacking prefixes with the most hosted validators to maximize her impact. As shown in Figure  6a, the attacker significantly improves her ability to inflict losses by crossing the threshold of 29 prefixes required to trigger a leak (see §4), causing nearly 300 ETH in damages with just a 2-hour hijack. Our findings also show that even if the attacker does not trigger a leak, prolonging the attack is an effective way to increase her impact, with a 3-hour hijack causing an aggregate of 379 ETH in losses.

Experimental validation: We experimentally validate StakeBleed in a simulated Ethereum network. Our simulations take as input the validators distribution, and the changes to the network connectivity graph when the attacker performs a hijack. Our results confirm StakeBleed’s effectiveness, as described in §6 (see §E for details).

Maximizing attack success: To maximize success the attacker targets proposers for which she has high mapping confidence (e.g., those seeded via consecutive validator IDs) and prefixes that are easy to hijack (e.g., prefixes < /24 without an ROA). She may also hijack additional candidate prefixes for the same validator to hedge mapping or filtering failures. If the immediate preceding proposer cannot be suppressed, the attacker can instead target proposers/attesters in the few preceding slots; because blocks include a bounded number of prior-slot attestations, this means the attacker still has a high probability of including attestations intended for previous slots in her block.

Proposer predictability: KnockBlock requires accurately predicting the proposer schedule with enough lead time for a BGP announcement to take effect. Effective validator balances change only rarely (only 0.0033% of blocks include a slashing [44]), and the RANDAO-based schedule is available two epochs in advance, giving an attacker a practical prediction window of $\approx$12.8 minutes. BGP announcements can take effect in less than 90 seconds [18], so the attacker can reliably prepare short, targeted hijacks.

Impact analysis: Successful KnockBlock attacks lead to a measurable increase of up to 453.6% in the attacker’s revenue in the form of block proposal rewards because of the inclusion of additional attestations and sync committee contributions. Using the protocol specification the expected block proposal reward is $E[R_{P}]=\frac{1}{7}\cdot\left[\frac{N}{32}\cdot R_{A}+512\cdot R_{Y}\right]$. In the event that there exist valid attestations issued in the preceding 32 slots that have not been included in another block, the block proposer can include these for an additional reward. In particular, new attestations receive the full reward of $\frac{54\cdot n\cdot b}{64}$ Gwei. Attestations delayed up to 5 slots lose the head portion of their reward, meaning that they receive $\frac{40\cdot n\cdot b}{64}$ Gwei. Attestations delayed 6 to 32 slots also lose the source portion of the reward and only receive the target portion: $\frac{26\cdot n\cdot b}{64}$ Gwei. A proposer can include up to 8 slots worth of attestations [45] in their block, increasing their reward by up to 453.6%. A single block proposal is worth 46,003,328 Gwei, while a block proposed by a KnockBlock adversary is worth up to 254,674,423 Gwei. Using mevboost payment data [46], we observe that blocks following a missed slot yield, on average, 44.5% higher MEV (Fig. 6b). As a result, by forcing a proposer to miss its slot, a KnockBlock adversary also increases her expected MEV by 44.5%.

Attack costs: A KnockBlock adversary can use her profits from running the attack to amortize her costs in setting up her own AS (RIR fees [47], transport providers [13], hardware [29], etc.) if she does not run or has already compromised one. Given that a validator proposes on average $\sim 2.47$ times per year, and that KnockBlock attack results in an average increase of 0.05 ETH in MEV and 0.03 ETH in attestation rewards, the validator’s annual revenue increase because of the attack will be 0.19 ETH (848 USD at the time of writing). By estimating annual AS operating costs to be approximately $2,500, the attack is profitable if the adversary owns more than 3 validators. This is a very pessimistic estimate for the attacker, considering that she can increase her revenue at no additional cost by collaborating with other validator owners and targeting the most profitable MEV opportunities.

Comparative impact A focused KnockBlock campaign can cause aggregate network damage comparable to larger StakeBleed partitions while being substantially stealthier (Fig. 6c). For example, with a 24-hour active hijack budget, both attack types can impose >800 ETH in losses, but KnockBlock achieves similar damage via many brief, single-prefix hijacks rather than sustained multi-prefix hijacks.

Automate migration on local detection: A key challenge in mitigating BGP hijacking is that its impact cannot be addressed at the application layer, nor can it be resolved locally. Recovery requires intervention by the affected network provider, who must coordinate with upstream and peer providers to filter the bogus advertisement at their networks—a process that often takes several hours [7, 6]. This makes it essential for validator operators to implement migration strategies, meaning automated processes that relocate validator operations to alternative (cloud) locations, under different providers and separate jurisdictions to minimize shared dependencies. This can be triggered by observable signals, such as changes in peer connectivity, unexpected reward loss, or increased message delays, which might indicate malicious reroutes [48].

Reducing predictability: StakeBleed is feasible because the attacker can monitor validator activity and adapt the partition accordingly. Knowing when each validator is expected to attest, she can verify whether she has successfully isolated them. KnockBlock relies on the adversary’s knowledge the block proposer schedule in advance, reducing the BGP hijacking set to even a single prefix. Removing the predictability in both cases would significantly strengthen the protocol against such attacks. For hiding the proposer schedule, one can use one of the several efficient SSLE constructions [49, 50]. In fact, integrating SSLE into Ethereum is actively being discussed [51].

Obfuscating validator locations: Our attacks depend on accurately mapping validators to IP addresses using P2P timing signals. We found that naive countermeasures are ineffective; adding exponentially distributed latency ($1/\lambda=[50,500]$ms), for instance, barely reduces our mapping model’s accuracy (1-3%) and risks harming liveness. This finding is consistent with prior work in Bitcoin [52]. A more effective approach is to disrupt the identifying signals at the source. Disabling "eager push" and OOS attestations is highly effective, slashing our inference model’s accuracy from 93% to 38%. Alternatively, validators could use temporary proxy nodes to broadcast attestations, effectively serving as decoys to obscure their true location.

Network attacks and defenses on PoW Routing attacks on cryptocurrencies have previously been discussed in the context of partitioning the Bitcoin network [18, 53]. Tran et al. demonstrated that it is possible to attack PoW mining pools by tampering with Stratum connections intercepted via BGP hijacks [19]. Researchers have also attempted to partition multiple cryptocurrencies at once by inferring Bitcoin’s and Ethereum’s network topologies through Ripple’s [28]. Neither of these works leverages a PoS-specific mechanism, nor do they infer the Ethereum PoS topology. Eclipsing attacks on blockchain peer-to-peer networks [14, 15, 16, 17], are not routing attacks per se as they do not perform a BGP hijack and can be resolved with a single whitelisted connection. Defenses against routing attacks include SABRE [54], which, however, contributes to the network’s consolidation and offers little incentive for newcomers.

Attacks on Ethereum PoS consensus Recent research in Ethereum PoS has focused on manipulating its fork choice rule and finality gadget to degrade the blockchain’s performance, yet without exploiting network routing. These methods allow an attacker to perform reorgs [20, 22], and split validators across different chains [21]. In response, Ethereum introduced countermeasures and patches, such as proposer boost, but these have been shown to still be vulnerable [23, 24]. Finally, prior work has investigated ways to further exploit Ethereum’s inactivity leak [55] after it has been triggered if the attacker holds stake. Such attacks can be used atop StakeBleed to increase its impact.