Ethereum's decentralisation; five years into proof of stake

Transcript

Sweet. Hello everybody. My name is Oisin. I apologize in advance that I'm already running out of voice and conference, but it's probably a good sign. And today I'm going to talk about Ethereum's decentralization and particularly we're going to look at proof of stake 5 years in. So, I'm assuming pretty much everyone here is going to be pretty familiar, but just God forbid. Um, Ethereum's proof of stake chain launched in December 2020. And there was 16,000 validators at launch. Then the next kind of big main event was the merge which happened in September 22.

At that point we'd gone up to about 13 million ETH staked. Today we're through seven hard forks, working on the next G star and H star ones, and about 30% of all ETH is staked to this point in time. Um, a lot of this talk is going to be focused on like risks and decentralization. And one of the key aspects of it is client diversity. For those people that don't know, if a client were to fail and to fork off into a different chain, if more than 66% of the network were to sign that incorrect chain, all of that ETH will be burned. This actually happened on Holesky earlier last year, and we ended up having to more or less retire the entire network.

So, one of the key risks is when we have too much of a single client throughout the network. You can see right now that Geth, Nethermind, and Lighthouse are you know, victims of their own success right now, and are some of the most adopted clients. So, an issue in any one of these could be extremely problematic for the network, bordering on catastrophic. Um, over the last few years, the makeup of the state of the validator set has changed. When we went to Genesis, um, there was about 5% of the stake were identified as solo stakers. And then over the years, unfortunately that number has declined. Um, I kind of particularly draw attention to the like era in 2024 where there's a lot of focus on issuance. I kind of thought that was past tense, but it sounds like it's kind

of back in the flavor of the month, and I'm going to be going and pestering people about it after this talk. But at this point in time, the solo stakers percentage is down to only 0.4%, which is not maybe where people want. And a lot of the growth is like marked as unidentified, but a lot of that unidentified stake actually consists of the staking ETFs and the digital asset treasuries. So, yeah, it's not necessarily in the best place right now, and maybe we can do something about it. Um put in a different way, at Devcon 2024, it was announced that issuance caps at rough consensus, and I think that was a a key point that I point to when it comes to like seeing when the behavior changed in the network

and how things started to change. Even from that point, we've gone down another 66% in identified solo stakers, um despite the best efforts of people in this room that are trying to do things and improve them. Um similarly, although the data isn't super public, the operator fees and the kind of delegation costs has gone particularly low from that point. One of the main reasons was if you assume you're going to have issuance caps, the only thing you can do is maybe make money from MEV in proposals, so you may as well try and kind of grow your TVL. So, nowadays the largest operators or the largest delegators in the world are paying more or less zero fees for delegating because the node operators are trying to grow their TVL.

So, it maybe goes without saying, but I thought I would spend a moment or two talking about like why we should decentralize Ethereum, like it, you know, what's it all for? Um one of the key reasons for decentralization is to ensure Ethereum never goes down. If we have too much of our stake running on one single setup or one single operator or single client team, it increases the likelihood that we will have a major outage on the chain. It also increases the likelihood that the network can be censored and can be co-opted. And all of these are kind of, you know, not what Ethereum wants, not what, you know, decentralized blockchains are all about.

On the plus side, decentralization is improved censorship resistance. It improves things like um uh I forgot the word for the AMMs. It makes them it more likely for people to get better fairer execution. And generally speaking, it'll hopefully make the net network more uh World War III proof. So, if that's the case, I do want to like spend a lot of this talk talking about what we're going to do about it as opposed to just saying uh, you know, things are going the wrong direction. So, I've broken this down into like three different sections depending on validators, core devs, and the ETH community.

And on the validator side, I want to talk a little bit about trying to give more language to people about how we talk about validator decentralization, how we try and make valid like client diversity more real, how we kind of can learn lessons about layer twos and how they have different stages of decentralization, and we want to do something similar. On the core dev side, I'm going to talk a little bit about some EIPs that can improve Ethereum's decentralization. And then for the community at large, we can talk about crops, the mandate, and some of the goals. So, for validator decentralization, um layer twos have these stages where if you're a stage zero layer two, you're not in good shape. If you get to stage one, you have reasonable security guarantees, and then the dream is like a

stage two layer two where no one person can corrupt it or take control over it or it's like running in a, you know, security guarantees in line with Ethereum. I am hoping to introduce something similar for validators focusing particularly on safety and on liveness. So, this idea of if a beacon node client forks off onto the wrong chain, if you're just running one beacon node and you sign it, that's a safety failure. That is the thing that could have you lose all of your money if 66% of the network does it at the same time. This is, you know, a stage zero validator, call it.

If instead you use some software like Obol Vouch any of these types of softwares, you can turn on settings where you say, "Hey, I noticed that of my beacon clients, some of them are on different forks. I'm going to stop and I'm not going to attest to either until I figure out what's going on." That means you are now safe, but you're not live. That brings it to like stage one decentralization. And then if you can afford it and you have a bigger setup, you can also run like four beacon nodes and you can do a majority rules type of setting. So even if only one of your nodes forks off, you can say, "Oh, I'm going to stick with the three out of four. Odds are this is like reasonably safe assumption." And that would be a safe and live validator and or like a stage two validator.

I will say that, you know, it's not a perfect guarantee that, you know, the majority could be right. In the whole ski situation, two clients, you know, could fail and go on the wrong fork, but it is um language that I think will help as we try and speak to people in the community and say, "Hey, you really should be adopting minority clients. You should be using, you know, multiple setups and you should try not to sign on the wrong chain lest you lose all of your money or your customers' money." On the EIP front, there is some like ready EIPs and some aspirational designs that I think core devs could consider to help mitigate the kind of centralization that we're struggling with and to try and improve the network um more broadly.

The first one that most people have probably heard of is fossil. This is um a feature where transactions in the mempool seen by other validators can get forced included into subsequent blocks. Um one of the disappointments is in the current design, it is possible to censor and refuse to put in a transaction that's in fossil so long as you build a full block, but you can't do that for very long. It gets extremely expensive. So this feature will try and increase the censorship resistance of the chain and give people better guarantees that things will be included.

The second EIP is 7716 and it is an EIP that hope I hope you guys will be down to support for inclusion in H star. This is the idea of penalizing validators extra if they go offline in a correlated fashion with everybody else. Right now, people might be aware that slashing scales with the more people that get slashed at the same time. This is meant to you know, encourage people not to run in the same setup and that they should favor like decentralization. A missed opportunity here is doing something similar for downtime.

We see correlated outages a lot more often than we see correlated slashing. There's never been a correlated slashing event on the chain in the last 5 years, but we regularly see situations where one data center goes down and we lose a chunk of the network or maybe one validator client has an issue and we lose a chunk of the network. This EIP will increase the penalties just for the brief moment when the step up and down time happens. It doesn't like stay elevated and the reason it's chosen that way is we don't want to penalize a small solo staker who's going to take longer to fix their node than an enterprise who has, you know, good SLAs and will be able to fix something in hours rather than days. But if we did this and you ran something in a bit of a centralized fashion and you you had an

outage and all of a sudden you lost a month, 2 months of reward, everyone go, "Ah, I'm going to not do that again." And this will help decentralize the network so that we don't end up in like a slashing situation where you know, it's a little too late at that point. Um and then last but not least is not an EIP formally yet, but is a maybe a pet project of mine, which is trying to allow for an alternative to the exit queue. The exit queue is often used as a point of concern when people are afraid to native stake or to stake in a more decentralized fashion. They don't like this idea of oh, it could be 100 days before I can get my money back. That's um pretty uncomfortable and that's very understandable.

But what we could do is have a second queue where you burn a certain amount of ETH to get your ETH out in a deterministic and ideally quick fashion. Um this doesn't risk the point of the exit queue, which is to prevent long-range attacks, because it would be on an exponential base fee. So, you could tune the parameters such that you can maybe take out 1% of the validator set per week. But if someone were to try and take out 10% of the validator set, the burn would go, you know, parabolic and you'd be like burning all of your ETH. So, it's a safe way to allow people to exit with better determinism. This would make it less uncomfortable for people to do native staking or to like adopt something more on the long tail.

And I think it'd be good for Ethereum's decentralization. Lastly, on the community side, trying to figure out how we encourage crops and generally to try and push for Ethereum to be more decentralized. One of the most important measures of decentralization is what's called a Nakamoto coefficient. This means how many companies or how many entities do you have to put together to get to 51% of stake or 51% of hash power? Right now in Ethereum, this is not a number that's kind of tracked super objectively, and I would love if people were to try and put more work into measuring this data and reporting it, because if we can see that number, we can see that it's not in great shape. My informed opinion is the number's in and

around five, which is not super high. Many corporate blockchains have a better Nakamoto coefficient than Ethereum. And I think we should be aiming to 10x that. I would love to at least see a double-digit number, better yet, you know, a triple-digit number someday. And the first step to that is, you know, increasing awareness of it, getting people reporting it, having dashboards about it, you know, advocating for it to improve. Previously, um there's a website called like nakaflow.ie. I can't remember the domain. But that reports on different chains Nakamoto coefficient and they actually ended up removing Ethereum because there was a lot of people upset about calling Lido one entity as opposed to 50 entities.

Um on the staking side, I would love the community really encourages solo staking, squad staking like running in small orgs. It is not super easy to get involved in stake staking if you don't have 32 ETH, but fortunately we have protocols like Lido and Rocket Pool who allow people to get involved from as low as about 2 and 1/2 ETH and better yet you can run with a group and then even like reduce that further. So if the community could kind of really make a push to try and get people to run their own nodes and to take part in the network themselves, that will I think marginally help as we, you know, push for Ethereum's decentralization.

And lastly, privacy is also something that is under invested in particularly on the staking side. There is, you know, the only people you who are staking privately are actually the daps and the ETFs and that's where they show up in the in the unidentified stake. Encouraging privacy would probably also help us in terms of decentralization and living the crops values. That's pretty much the entirety of my talk. Would love to help, you know, everyone get involved in staking in any way I can. Feel free to grab me and happy to take any questions about this topic. Thank you. I'll see you.

Thank you. Um anyone have a question? Yes. Thanks, really interesting talk. Um you kind of mentioned client diversity and validator diversity, but if you go to Etherscan and you look at who's building the blocks, it's mostly one Titan builder. Is that an issue for decentralization? Yes, I think it's definitely an issue. I think it is maybe a more solvable issue than validator centralization insofar as more people can build blocks and can get involved there. It's harder for the

validator set to maybe decentralize than it is for, you know, alternatives in the block building front. But certainly I do agree that the block building is particularly centralized. But people like flashbots and buildernet are a good kind of alternative in that front. But I I would agree with you that it is generally something to worry about for sure. Thanks. Yeah. Thank you. Another question? No? So thanks again for presentation. Thank you. Thank you.