By Kaya Alpturer, Constantine Doumanidis, and Aviv Zohar
TLDR. Ethereum’s consensus layer makes identities expensive, but its peer-discovery layer still treats network identities as cheap. That gap leaves nodes exposed to eclipse and Sybil attacks before consensus even begins. AetherWeave is a peer-discovery protocol that ties network participation to deposited stake, making those attacks expensive while keeping a node’s network identity unlinkable from its on-chain deposit. Each node proves that it has valid stake without revealing which deposit it owns; request volume is limited in proportion to stake, and excessive request-spamming can be punished via slashing. The gossip structure also limits an attacker to suppressing records rather than inflating their representation, and makes successful suppression or eclipsing detectable. Per-node communication is O(s\sqrt{n}) per round, and on-chain interaction is limited to deposit, unstake, and slash. We built a research prototype on a fork of Prysm. Full paper here.
Motivation
When a new Ethereum node comes online, it needs to find peers. It contacts a bootstrap node, asks for a list of IP addresses of other peers, and starts connecting. This raises the question: how does the new node know the bootstrap node is not malicious and providing it only attacker-controlled IPs?
Nodes currently cannot be certain of this, and are at risk of becoming eclipsed where their view of the network is controlled by the attacker who can hide blocks, deliver stale data, or launch more sophisticated attacks that partition the network.
Eclipse attacks against Bitcoin and Ethereum have been demonstrated in real systems. The reason these attacks work is that creating new network identities is essentially free. An attacker who controls a few thousand IP addresses can flood the discovery process with bogus entries and crowd out the real ones. Defenses today (IP subnet bans, rate-limiting, reputation tracking) partially mitigate the issue, but cannot deter well-provisioned attackers.
Interestingly, Ethereum has already solved the “free identity” problem in the consensus layer. Proof-of-stake ensures that representation in consensus through validators is tied to stake, meaning that consensus is Sybil-resistant by design. But the network layer right underneath consensus lacks such mechanisms and remains free.
So the natural question is whether we can utilize staked identities in the network layer.
Stake-backed peer discovery
The basic idea is: every node in the discovery network has to back its participation with a stake deposit. If a node misbehaves — for example, by sending more requests than the protocol allows — anyone in the network can produce a proof of misbehavior and use it to slash the node’s deposit. That puts a real cost on Sybil identities: an attacker who wants 10,000 fake nodes has to lock the stake for 10,000 of them.
This isn’t a new idea by itself. Coretti et al. previously showed that a stake-weighted random graph can sustain Byzantine-resilient gossip. But their analysis assumed that everyone already knows which network address corresponds to which deposit.
This is a strong assumption as figuring out who is who is most of the peer-discovery problem in practice.
So the things we wanted to add on top were:
- An actual discovery protocol that defines how nodes find each other, how new nodes bootstrap, how the system handles peers leaving and rejoining with new addresses.
- A way for a node to prove stake ownership without revealing which deposit it owns. While showing stake ownership is straightforward through zero-knowledge proofs of set-membership, the hard part is making this coexist with slashing. Slashing requires that when a node misbehaves, anyone in the network must be able to point at the offender’s deposit and burn it. That looks like a direct contradiction of unlinkability as you need to know who they are to slash them. Most of the work in this part of the design is reconciling the two: honest nodes stay fully unlinkable, but the moment a node breaks the protocol’s rules, the misbehavior itself leaks just enough information to identify exactly which deposit to slash.
- A way to detect when an attacker is trying to partition the honest network, so that even if the attack succeeds the victims don’t silently keep operating in a compromised network state.
The protocol sketch
A node in AetherWeave keeps two peer tables, each of size s\sqrt{n}, where n is the number of staked nodes and s is a small constant (we use s=4 in experiments). One table is used for gossip — exchanging peer records with others. The other is used to draw the node’s actual overlay connections from. The two tables are populated using independent private seeds, so what a peer learns by gossiping with you tells them nothing about your overlay neighbors.
Each round, every node does roughly the same thing:
- It picks a fresh pseudorandom slice of the staked network.
- It asks each peer in its gossip table for any records matching that slice.
- Each responder filters its own table by the requester’s slice and returns the matching records (only s^2 records in expectation, to minimize bandwidth use).
- Each record contains the responder’s network public key, a recent zero-knowledge proof that the key is backed by a real stake deposit, and a signed network address.
A useful way to think about why this works: the slice is chosen by the requester, not the responder. So a malicious responder can’t pad their answer with extra adversarial records as those records wouldn’t match the slice and would be rejected. The only thing a malicious responder can do is suppress honest records that should have matched. And suppression has a fingerprint: if a node receives many fewer records than expected, that’s a statistical signal that something is wrong.
That signal is what we use in the eclipse-detection mechanism. If a node’s table comes out too sparse compared to what the protocol predicts, the node raises a local flag. In a deployment this could trigger switching bootstrap peers, alerting an operator, or pausing RPC related operations until the table looks healthy.
Guarantees
The cleanest result in the paper is a guarantee about partitioning the honest network. Informally:
Suppose an adversary controls some fraction \alpha of the stake, knows every honest node’s private seeds, and can drop arbitrary messages between honest nodes. Suppose each node’s expected overlay degree grows like \Omega(\log n). Then with overwhelming probability, for every way the adversary tries to split the honest nodes into two groups, either some node on one side has an overlay connection to the other (so the partition fails), or a large fraction of the smaller side raises the eclipse-detection alarm.
In other words: against the strongest adversary we could write down, a successful partition is highly visible.
We also have a mean-field analysis that gives a closed-form picture of when the gossip layer converges. The condition is
which says, roughly, that the rate at which honest records spread has to beat the rate at which silent or adversarial nodes drop them. With s = 4 this tolerates \alpha < 15/16 adversarial stake before the gossip layer breaks.
Privacy
Naively, tying network participation to stake creates a privacy regression: every node’s IP becomes linkable to a specific validator deposit. This is undesirable, and avoided in our design.
A node’s network public key is derived deterministically from the same secret that controls its stake deposit, but you can’t go from the network key back to the deposit without breaking the underlying zero-knowledge proof system. When a node serves peer records, it includes a fresh zk-proof saying “this network key is backed by some deposit in the staking contract”, without saying which one. This means that a peer table looks like a list of pseudonyms with fresh stake proofs, rather than a list of validators with their IPs.
However, unlinkability holds only as long as a node behaves honestly. The slashing mechanism works by requiring each request to carry a cryptographic share of a slashing secret tied to a bounded commitment to the requester’s full set of intended recipients that round. If a node ever issues two batches with different commitments in the same round (which is what request spam requires), anyone who sees both shares can reconstruct the slashing secret, identify the offending deposit, and burn it.
A detail relevant to our protocol’s privacy is that the slice seed has to stay private from individual responders. Otherwise, an adversarial responder can learn what the requester is looking for, and learn information about their table. One way to achieve this is by having responders evaluate the slice predicate inside a TEE, so the responder’s host never sees the requester’s seed. This is what lets each response stay small (s^2 records in expectation), because the responder filters down to just the matching records before replying.
A trust-free alternative is private information retrieval, which removes the hardware assumption but may cost us in bandwidth: sending responses that are roughly the size of the responder’s table rather than s^2 can avoid the TEE assumption. So the O(s\sqrt{n}) communication cost and the TEE assumption are coupled.
The prototype
We forked Prysm and replaced its discovery layer with AetherWeave. The new components are:
- A staking smart contract written in Solidity, using a sparse Merkle tree over deposit commitments and Poseidon hashes.
- The stake proofs and slashing-share proofs are written in Circom and use Groth16 with Baby Jubjub keys and Poseidon hashes. Proof generation and verification happen off-chain.
- Per-node bandwidth scales as O(s\sqrt{n}) per round.
We ran simulated deployments up to 625 full nodes on a single AMD EPYC 9354P server with 2-minute rounds. Extrapolating from the per-operation profile, even at one million nodes the protocol would need only a handful of CPU cores per node — i.e., it doesn’t crowd out the CPU budget of a consensus client that’s also doing attestations and block validation.
We also built a separate Python event-driven simulator to test things at larger scales and confirmed churn-resistance, robust slashing, and healthy peer propagation.
What this could look like in Ethereum
We are not yet proposing an EIP but we believe that our design can be practically deployed:
- AetherWeave can run alongside discv5, rather than replacing it. Stake-bearing validators opt in and form a hardened core; non-stakers continue to participate via existing discovery on a best-effort basis.
- The stake itself can either reuse the existing validator deposits, or live in a smaller separate staking contract if reusing validator stake is too entangled with the consensus layer.
- All zk-proof verification happens off-chain by the participating nodes. The on-chain footprint is just deposit, unstake, and slash.
The questions we’d most like to hear thoughts on:
- Does it make more sense to reuse validator stake, or to have a separate (smaller) discovery-layer stake?
- What slashing economics make sense for discovery-layer misbehavior, where each individual offense is small but the cumulative damage from repeated offenses can be serious?
- Is the TEE assumption for slice-seed privacy something the community is willing to accept, or should we push directly to a PIR-based variant?
- Are there discv5 deployment lessons we should be drawing on more explicitly?
Limitations
- We don’t model NAT and firewall traversal. A real deployment needs hole-punching or relay mechanisms.
- There’s no reward for honest participation. A rational responder could free-ride by declining to serve responses.
- The slice-privacy guarantee depends on TEE integrity, and the protocol’s small per-round communication (O(s\sqrt{n})) depends on slice privacy holding so that responders can filter before replying. Side-channel attacks on TEEs weaken this in practice. A compromised TEE only degrades slice privacy and doesn’t break correctness, slashing, or eclipse detection. The bandwidth cost of moving to a PIR-based variant could be high, and we’d prefer a hardware-free option long-term.
- Higher-layer protocols running on top of the overlay can leak topology in ways that undermine table privacy. We only focus on discovery-layer guarantees.
Links
- Paper PDF: https://arxiv.org/abs/2603.23793
- Prototype, including the Prysm fork and staking contract: https://github.com/CedArctic/aetherweave-artifact
- Simulator: https://github.com/CedArctic/aetherweave_simulator
We’d love to hear constructive feedback.