Routing Attacks in Ethereum PoS: A Systematic Exploration

TL;DR

This paper investigates routing-layer threats to Ethereum's PoS through BGP hijacks. It proposes StakeBleed and KnockBlock as practical, PoS-specific attacks and introduces SuperNode to infer validator Internet-topology without disrupting live traffic. The empirical analysis shows StakeBleed can cost almost $300$ ETH in two hours by hijacking as few as $30$ prefixes, while KnockBlock yields about $44.5\%$ higher MEV and up to $71.4\%$ higher block rewards with brief hijacks. The work highlights urgency for stronger Internet routing defenses and for the Ethereum P2P protocol to conceal validator locations to preserve liveness, safety, and economic incentives.

Abstract

With the promise of greater decentralization and sustainability, Ethereum transitioned from a Proof-of-Work (PoW) to a Proof-of-Stake (PoS) consensus mechanism. The new consensus protocol introduces novel vulnerabilities that warrant further investigation. The goal of this paper is to investigate the security of Ethereum's PoS system from an Internet routing perspective. To this end, this paper makes two contributions: First, we devise a novel framework for inferring the distribution of validators on the Internet without disturbing the real network. Second, we introduce a class of network-level attacks on Ethereum's PoS system that jointly exploit Internet routing vulnerabilities with the protocol's reward and penalty mechanisms. We describe two representative attacks: StakeBleed, where the attacker triggers an inactivity leak, halting block finality and causing financial losses for all validators; and KnockBlock, where the attacker increases her expected MEV gains by preventing targeted blocks from being included in the chain. We find that both attacks are practical and effective. An attacker executing StakeBleed can inflict losses of almost 300 ETH in just 2 hours by hijacking as few as 30 IP prefixes. An attacker implementing KnockBlock could increase their MEV expected gains by 44.5% while hijacking a single prefix for less than 2 minutes. Our paper serves as a call to action for validators to reinforce their Internet routing infrastructure and for the Ethereum P2P protocol to implement stronger mechanisms to conceal validator locations.

Figures (12)

• Figure 1: Network view (left): A StakeBleed adversary controlling a router in AS 8 isolates nodes in $P$, from the rest of the Ethereum network by diverting their traffic using a BGP hijack and dropping their connections to nodes outside $P$. Blockchain view (right): Nodes in $P$ have a minority chain view of the blockchain and nodes outside $P$ have the eventually canonical chain view. Before the inactivity leak is triggered, validators in $P$ lose their proposer rewards and incur penalties because they do not produce attestations in the canonical chain, while validators outside $P$ also lose some of their rewards from proposing and attesting. After four epochs of $P$ being isolated, an inactivity leak is triggered, causing validators in $P$ to incur severe inactivity penalties, while validators outside $P$ to stop receiving attestation rewards.
• Figure 2: Illustration of a KnockBlock adversary that controls the validator node E that is set to propose in Slot 3. The attacker calculates the proposer schedule and finds that validator D is scheduled to propose before her in Slot 2. She prevents node D from proposing by performing a BGP hijack, and preferentially includes some transactions and attestations that were intended for Slot 2 in her own block, while denying node D its proposer rewards.
• Figure 3: Cumulative distribution of the time needed to finalize a node by our SuperNode. 60% of nodes finalizations happened in just over 41 hours.
• Figure 4: For more than half of the validators there is one unique IP prefix whose nodes demostrate exceptionally low latency in delivering attestation of consecutive validator IDs.
• Figure 5: Cumulative distribution of the number of attempts required to successfully initiate a connection on demand. Out of 500 randomly selected ENRs, our node only eventually succeeds in connecting to $\approx 1/3$ of the corresponding nodes. The vast majority of successful connections required just a handful of attempts. This illustrates the difficulty of connecting to any given Ethereum node on demand.