Solo staking in the dark forest: a survival guide by Qianchen "Q" Yu | Devcon SEA

[Music] hello hello yeah I guess it's my turn um yeah surprise title actually I'm going to talk about solo staking the Dark Forest um yeah so today I'm going to demo you 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 um and we're going to find out a validator or a solo Staker that um actually runs uh uses M boost and um which is next to their consensus client um in order to find them uh we actually yeah 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 Randal 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 buil privacy preserving infrastructure so we'll actually use a Sandbox environment for Demo's purpose but there's nothing actually preventing this attack happening in real life right now um our sandbox actually has three three consensus client with a total of 192 validators in a cortosis network um with also one MV relay and one block Builders um for now those validators are just you know a list of anonymous public keys but not for long so while this test has been running um Let Me Explain how we actually conduct conduct this attack so first we actually need to deize validators um to identify our Target so to validators actually they need to attest block Productions and those attestations are propagated into the pure to network in Gossip up uh we can actually just silently observe those attestations to create a probalistic uh collect like correlation between the validators public key to the IP address of the consensus layer client and we actually have this oh the test is 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 needed a little bit help from The Trusted MAV relay um maybe we're just observing the math or we are just uh you know colluding with the MAV relay or we just the relay ourselves right um map boost users actually need to trust the relay to deliver uh 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 uh data table that we created which is called metadata here we collect all the metadata of each htpp request that uh from connected validators and block Builders so it actually gives us a strong link between the validator public key to the MF boost IP address which sits right next to the consensus layer client and this is just because validators are uh they have to they must uh register with every relay that's connected to okay here now we have the exercise going on um 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 built between the public key of the public uh of the uh Pi IDs and then we know the uh the IP address from the P ID pretty easily and then plug the information of the MAV boost id M boost IP address on top of that um and next question is who to attack so here we actually just pick uh slot 246 and 247 but we actually have a wider choice because uh validators they are like the proposers are announced two Epoch ahead of time right um to launch this attack we use traditional uh Doos technique uh introducing the IC flood and S flood but just to make our attch a bit more clear um we actually use a um math we use a memory stress test just directly on this uh instance to obtain the same result and here we can see that block 2 for6 and 2 for 7 they are skipped and now it's time to check the rent out value of the slot 246 and 247 they're actually the same so congratulations fellow attackers we managed to uh stop the block production and also control the vend rendal value um yep so if I can skip to the last slide um yeah so here we just demo the attack as an attacker gim um I welcome everybody uh who are interested in this topic to further discussion discuss the implication and improvements on how to avoid this attack uh we're going to have a report releas soon on The Ether Church Forum as well as a discussion that's going to be held at 1:30 later at the blue discussion Corner um to close my talk I would like to give a heart thank you to eum Foundation um that gave us a grant to conduct This research thank you very much okay thank you very much q and sorry for missing your name now are there any questions come on the so just to clarify so we were able to skip the solo scker slot here is that the attack or was it just the Rand down manipulation so we actually managed to make the solo Staker not being able to propose at the slot that they were given yes so by doing by doing so we interactive actually manipulate the Randal yeah yeah and like is there any what do you think are the financial implications of this should should a big staking pools be doing this to maximize their rewards actually good question because uh there was one of the further discussion that we had around this experiment is that uh we believe that the current uh definition of me which is the single we always look at just one Whatever transaction that's been included into one block um this narrow definition which is also the definition written on the E theorem like the page of etherum foundation um is a bit too narrow so by kicking out the production of one block we can effectively have this skip slot me uh just an example like some uh some people who want like to have this multiblock me right this is one of the attack of having that uh to achieve this um multiblock um meth and um also it just basically um it also creates a threat on the uh resilience of the network right if you can easily identify a block proposer and then just kick them out at the place where supposed to produce a block then doesn't mean that um especially for solo stakers who have very poor let's say who doesn't really have a access to Strong Network protection doesn't mean that uh those percentage of solo stakers of ethereum network they are at risk yeah last question please um how difficult is it to obtain the IP address of a certain valid data and what is the role of MEF boost in in this kind of process yeah thanks um 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 them uh attestations by just put dumping them into a database very simple data analytic analytics and then you can have this correlation so the longer you run that the stronger link that you have it uh even though there's some technical details about how we actually going to tackle the aggregated attestations but yeah you know you got to figure it out and we also know the pattern um of Gossip up so combining these two the uh analytics is actually pretty accurate um and uh the role of the MAV relay is that because solo stakers um let's say they already invest into Hardware right to and also put into some Stak 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 help them to build the most profitable block and here right now we have thanks to your research Tony is that we know that there's more than 90% of the validators they are using a MAV relay um or like M boost architecture and relay which is an obvious very obvious single point of failure no let's say a single entity like a central