Solo staking in the dark forest: a survival guide

Hello, hello. Yeah, I guess it's my turn. Yeah, surprise title. Actually, I'm going to talk about why Dark Forest is even more dangerous to solo stakers with an attack that strikes at the heart of the Ethereum validation. So together, actually, we're going to play as an attacker.

And we're going to find out a validator or a solo staker that actually uses MEV boost, which is next to their consensus client. In order to find them, we actually are going to do the exercise together. But once we find them, what we're going to do is we're going to disrupt the block production of the solo staker and stop their rewards and manipulate the Randall value which is responsible for assigning new block proposers. So my name is Q, I'm the decentralized technology architect at Hopper. At Hopper we build privacy preserving infrastructure.

So we'll actually use a sandbox environment for demo purpose, but there's nothing actually preventing this attack happening in real life right now. Our sandbox actually has three consensus clients with a total of 192 validators in a kurtosis network with also one MEV relay and one block builder. For now, those validators are just a list of anonymous public keys, but not for long. So while this test has been running, let me explain how we actually conduct this attack. So first, we actually need to de-anonymize validators to identify our target.

So validators actually need to attest block productions, and those attestations are propagated into the peer-to-peer network in GossipSub. We can actually just silently observe those attestations to create a probabilistic correlation between the validator's public key to the IP address of the consensus layer client. And we actually have this, oh, the test has actually been running. We just let it run for a little while. Block has been proposed.

Just leave it there. So now is the moment to actually explain the other information that we need to conduct this attack. We actually need a little bit of help from the trusted map relay. Maybe we're just observing the map, or we're just colluding with the map relay, or we're just the relay ourselves. MapBoost users actually need to trust the relay to deliver, well, basically trust them on delivering correct content of the block on time.

However, they need to trust more than that. So that's the moment we look into the database of the relay and look at one of the new data table that we created, which is called metadata. Here, we collect all the metadata of each HTTP request from connected validators and block builders. So it actually gives us a strong link between the validator public key to the MapBoost IP address, which sits right next to the consensus layer client. And this is just because validators, they have to, they must register with every relay that's connected to.

Okay, here, now we have the exercise going on. As an attacker, we just have a dashboard with all the information we need. Right here is the attestation that we have with the occurrence of the attestation that we accumulate with, like, the more attestation we have, the stronger link we actually build between the public key of the peer IDs. And then we know the IP address from the peer ID pretty easily, and then plug the information of the MapBoost ID, MapBoost IP address on top of that. And next question is who to attack.

So here we actually just pick slot 246 and 247, but we actually have a wider choice because validators, they are, like the proposers are announced two epochs ahead of time. Right? To launch this attack, we use traditional DDoS technique, introducing the ICAP flood and SYN flood. But just to make our attack a bit more clear, we actually use a memory stress test just directly on this instance to obtain the same result. And here we can see that block 246 and 247, they are skipped.

And now it's time to check the rundown value of the slot 246 and 247. They're actually the same. So congratulations, fellow attackers. We managed to stop the block production and also control the Randall value. Yep.

So if I can skip to the last slide. Yeah, so here we just demo the attack as an attacker gene. I welcome everybody who are interested in this topic to further discuss the implication and improvements on how to avoid this attack. We're going to have a report released soon on the Etherchurch forum, as well as a discussion that's going to be held at 1.30 later at the blue discussion corner.

To close my talk, I would like to give a heartfelt thank you to Ethereum Foundation that gave us a grant to conduct this research. Thank you very much. Thank you very much. Thank you very much, Q, and sorry for missing your name. Now, are there any questions?

Come on, don't be shy. So just to clarify, so we were able to skip the solo sticker slot here? Is that the attack, or was it just the random manipulation? So we actually managed to make the solo sticker not being able to propose at the slot that it was given. So by doing so, we indirectly actually manipulate the rendout.

And like, is there any, what do you think are the financial implications of this? Do the big staking pools be doing this to maximize their rewards? Actually, good question. Because there was one of the further discussion that we had around this experiment is that we believe that the current definition of MEV, which is a single, we always look at just one, whatever transaction that's been included into one block. This narrow definition, which is also the definition written on the Ethereum, like the page of Ethereum Foundation, is a bit too narrow.

So by kicking out the production of one block, we can effectively have this skip slot MEV. Just an example, like some people would like to have this multi-block MEV, right? This is one of the attack of having that to achieve this multi-block MEV. And also, it just basically, it also creates a threat on the resilience of the network, right? If you can easily identify a block proposer and then just kick them out at the place where it's supposed to produce a block, then does it mean that, especially for solo stakers who have very poor, let's say, who doesn't really have access to strong network protection, does it mean that those percentage of solo stakers of Ethereum network, they are at risk.

Last question, please. How difficult is it to obtain the IP address of a certain validator and what is the role of MevBoost in this kind of process? Yeah, thanks. It is very easy, actually. Right now, you can just modify a little bit of your, I don't know, Lighthouse client.

Then you can collect attestations by just dumping them into a database. Very simple data analytics, and then you can have this correlation. So the longer you run that, the stronger link that you have it. Even though there's some technical details about how we're actually going to tackle the aggregated attestations. But yeah, you know, you're going to figure it out.

And we also know the pattern of gossips up. So combining these two, the analytics is actually pretty accurate. And the role of the map relay is that because solo stakers, let's say they already invest into a hardware, right, to, and also put into some stake to run their own staking setup, their goal is, one of their main goal is to make sure that they have economic returns. And very likely they're going to introduce whatever that helps them to build the most profitable block. And here right now we have, thanks to your research, Tony, is that we know that there are more than 90% of the validators, they are using MapRelay or MapBoost architecture.

And Relay, which is an obvious, very obvious single point of failure, no, let's say a single entity, like a central entity