Golden Raspberry Awards Of Ethereum Scaling 2025

Hi, I'm Sebastian Orbasti, as he just said, and I present today, although I'm just usually doing research at Alphabet, I can present to you the Golden Raspberry Award of Ethereum Scaling. I don't know if you know the Raspberry Awards, it's like an anti-Oscar ceremony, and I'm going to try to be very gentle, also because so much good things have happened in Ethereum Scaling, and I just want to follow the philosophy of who I work for, which is actually providing transparency, and I would probably need a clicker, right, I don't know, like, next slide. And so, I want to provide transparency, and one way of providing transparency is probably to criticize just a little bit. Okay, next slide. I mean, it wouldn't be a problem if I do it manually like this, I'll just say.

Yeah, perfect. So, you probably know Bartek, and maybe you've seen him at DEF CON, he ripped dramatically a sign apart, which is the sign of stage zero, we have three stages at Alphabet, three stages of decentralization. He ripped apart the zeroth stage, and we kind of told you at DEF CON that it's time to grow up, like we have this notion of training wheels, and you kind of need training wheels when you're in your childhood, or you're trying to learn a new thing, like scaling, but now we kind of are mature enough to grow up. Thanks. And so, time to grow up, and in a few days, it's not 16 days as shown there, this is our website, it's seven days, in seven days, there will be the big recategorization, which is not, like, super big, but it will, in the first week or so, be probably quite big, because as you can see here, we are going to introduce minimum requirements for decentralization, so minimum requirements to be considered scaling a theorem, right?

Those will be at least having a proof system which is sufficiently open, and having data availability that is sufficiently guaranteed by, for example, a data availability bridge, or a data availability committee of a certain size. You can see here, for example, Validiums and Optimiums are going to go to the others category, almost all of them, and they will be considered as not scaling a theorem at this moment, or at least as working on it. For Rolops, it looks better, I showed the worst case here, and yeah, you can see. So let's get to the awards. The first award is the Most Overloaded Security Council.

I also wanted to ask, I forgot, can you raise your hand if you know LCBs at all? That's epic. Very nice. Most Overloaded Security Council, if you know LCBs, you probably know what a security council is, Specialized Multisig. Overloaded, I will explain soon, but first I'll show you, it's StartNet, and I'm not trying to throw shade on StartNet, although it looks like it.

Maybe just a little bit of shade, but I don't want to show the worst case, the worst offenders, because they probably don't care about decentralization, and StartNet definitely does. So I want to motivate where the motivation actually means something, and for StartNet, it definitely does mean something, and you can see here, the Most Overloaded Security Council probably has something to do with the operator section. So the slice at the bottom, this pizza is about risk. You probably know it from our site, and the yellow parts are mostly operators. So sequencer, proposer, often very centralized.

Would be nice maybe to decentralize. It's not always necessary to decentralize, but you probably want to force transactions for example to have sufficient decentralization. So the problem with StartNet is they do have a security council, very robust, very new. It has nine out of 12 thresholds. It's just a multisig, but a special one because there's special signers, and StartNet now also uses this multisig for a different thing.

Usually it's used for upgrades, for emergency things, right? Things that happen when something breaks or when there's a big change in the protocol. They now also use it, you can see, this is our internal tool. I don't need to say internal because you can all use it. We also publish it on our website in a hosted version, but you can download it.

And you can see that there's a second copy of the same multisig with a lower threshold of three out of 12, which is the quorum-breaking minority of the nine out of 12, and those are an operator. So this multisig can finalize proven state. So if state is CK proven, they can finalize this state, and you can withdraw based on it. That's basic operator duty. Now, this is kind of a problem because here I show in a rough form what the stages are about.

If you don't know stages, this will be a nice abstraction. You can just say, at stage zero, the operator can review, right? Or you could also say you have to trust the operator. At stage one, it's only the security counsel, nobody else should be. Lots of implicit assumptions there.

But should only be the security counsel that can review. So for stage one, the security counsel is extremely important. Stage two, nobody can. It's a permissionless system, fully permissionless. Now, for StackNet, you always have implicit assumptions, but suddenly for StackNet, you have one more, the purple one down there or the pink one.

Suddenly, when your transaction gets censored in StackNet now, the operator is still centralized, but now you would have as a user to go to the security counsel and say, well, I want to withdraw from this rollup. My transaction got censored. First, how do you go to the security counsel? What is even that process? Do you call them?

Do you write them on the blockchain? I don't know. And there's no formal way to find yet. And for example, maybe we would have to do this. So the reason for these awards is also to – we talked to StackNet about this, but there should be more people talking about it, right?

You should maybe talk to us, and more people should discuss these special cases, right? Security counsel should not be an operator, I think. Okay, Kinto is an honorable mention. It's a bit smaller, but it's also stage one. It's also a rollup, and an AppChain rollup is different, but it's also a rollup.

And they are also severely overloading their security counsel. They have a full KYC chain, which kind of sounds weird, right? Decentralization, stage one, and also full KYC. But the way they do this is they still hold true to this main principle. Only security counsel can rug you at stage one by just making the security counsel do the KYC-ing.

Not specifically the KYC-ing, but at least the censoring part. So you get KYC-ed somewhere, whatever, then you can use the chain, then you're censored because you land on the OFAC list, I don't know, you use PshanatoCache or whatever, and then the security counsel has to approve your censorship. So, for example, your KYC revocation. If they wouldn't have to do this, it wouldn't be stage one. But this is stage one.

So you can see that's a different stage one than if there wasn't KYC, right? So maybe you should trust Vita Drake here and make security counsels as limited as possible, right? Because they're very powerful at stage one. I wouldn't trust them for sequencing or censorship resistance. They don't even have the tools.

We are on some security counsels, and we don't have the tools at L2B to run operator for all blockchains, right? Longest possible pause at stage one is a very simple word, and it's for the superchain in its entirety, especially for the superchain at stage one, the few rulers that are at stage one of the superchain. And this right now, longest possible pause, is even longer than that, so infinite, but in the future will probably be six months because we have been in discussions with them, and it came out that probably it will be six months. This should probably also be a bigger discussion because it's a huge thing. This pausing is not the security counsel, even at stage one, because it's not indefinite.

We wouldn't allow it indefinitely by a non-security counsel, but this can be by any team multisig, right? Three plus three because you can pause locally and you can pause the entire superchain by different actors, and you can stack it. So this problem should be discussed, in my opinion. Least available data, so that's about data availability, as you can imagine, and put Eigen-DA there just because no project uses their bridge, which is a problem, and I think it should also be Eigen-DA motivating projects to use the Eigen-DA bridge. And I would say this award goes to all data availability committees that are one.

The committee is literally one person. Already doesn't work with the work committee. And to the ones that have data availability somewhere else, not on Ethereum, but are not building a bridge. Why build a bridge? This is the beautiful, sunny case.

You just put your data on Ethereum. You can, for example, put your data on Ethereum here, the full transaction data. That means everyone can, just by looking at Ethereum, we already trust Ethereum, we already think it's very decentralized, so no new trust assumptions. You just look at Ethereum and you can take all transactions, execute them, and you get the state of the roll-up. That's pretty awesome.

But you can just do this if the full transaction data is on Ethereum. And you need it for the most important things, like, for example, with drawing. For your Merkle proof, you need the full state. And then you can withdraw. Or, for example, optimistic systems with fault proofs.

They need the full data, otherwise they can't even challenge. Like someone would propose a malicious state that rugs everyone, and no one could challenge because they can't reproduce the data. That's what we see here. That's what many do today. That's why the AltDA section is like two projects in one week.

They put data, I mean, it's like putting in their basement. They put it somewhere else, maybe on a great data availability layer. There is awesome solutions, right? There's Celestia, there's Abrail, and so on. But they put it there, and they don't build a bridge.

So, at that moment, if you're looking from Ethereum, and this is not a thought experiment, but having this perspective from Ethereum is super important. Everything else, if you're not starting somewhere with your trust assumptions, everything else will never scale. You cannot say, yeah, but maybe these other blockchains are also decentralized. You cannot do, like, if you're bridged to an L2, and suddenly, well, the data is on Celestia, and now I need to run a Celestia node for it to be trustless. I need to read about Celestia.

This never scales, right? And we want to scale Ethereum. All the awards are about scaling Ethereum, right? So, not building bridges will never scale. Maybe in the future, Celestia is a better decentralized platform, but then we will only look from the Celestia perspective and build bridges to there.

So, yeah, this is a problem. You can't withdraw, that's why it's red. You can't build the Merkle proof. You can't challenge. You'll get wrecked.

And this is a good thing that some projects do, and we have many commitments. Like, I'm not saying this will always be so empty, our scaling page, after the recriticalization. We have lots of commitments. Literally, projects are writing me today that they're switching to a data availability bridge. So, it looks pretty good.

And yeah, this is again, the viewpoint of Ethereum is super important. This huge abyss of non-scaling. If you take anything else and put it in the trust assumptions, it doesn't work. You can't just add trust assumptions. You have to convince Ethereum that your data was made available somewhere else.

And that's what the bridge does. Here are all the awards. If you're working for them or with them, you can come to me and we can discuss it, and maybe I even have an award for you. Is this with questions or without? Oh, nice, perfect.

Yeah, yeah, yeah, okay. Least Proven Proof System, I'll go through this quick, because it's not super known. Metis, I've looked so much at their code and I just need to get it out of my system a little bit. This is also personal and not about L2B at all. Metis also tries to get through these new requirements, the new recategorization, which needs data availability on Ethereum, and it's green.

So, yes, they're posting their full transaction data to Ethereum since two weeks ago or so. The other thing is, have a proof system, right? You need a proof system if you want to scale Ethereum. So, there it is. It's there.

You can, again, use our tools to look at it in depth. Well, the problem is, it's not connected to the rollup. So, it is like this, right? I don't know if you know this, but this is a typical OP stack proof system. They didn't connect it to the rollup.

And the only connection is here, the Metis multisig. This has, as a conclusion, like as a consequence, proof system works like this. If you see someone will rug you, right? You see malicious state being proposed, you will lose all of your money on L2. Then you go to the Metis multisig, like this kid does.

Because Metis multisig has this role, game creator. So, they can deploy a proof, like a bisection game, OP stack specific fault proofs. They deploy it. You win because your state is the correct state, right? That's how fault proofs work.

But again, no connection. So, nothing happens. You just win. You're happy. Like when you receive my award.

And then you go again to Metis multisig, here, and you say, can you please delete the state that I just proved is wrong? So, that's not how you do a proof system. And I'm sure they will change it. I'm just saying, probably projects will change it even faster, maybe, if I give them awards. Okay, so maybe you want to ask some questions.

That's why I summarized the points I wanted to make. So, about the POV, right? You should look from a theorem. Pauses should be explicitly limited. I think we shouldn't say, yeah, no indefinite pauses, because then the next project will do, like, five million years pause, and say, well, it's not indefinite.

The proof systems are currently, cannot be left alone. They cannot be, like, permissionless, as we would like them in stage two, right? They're good for stage one, but current proof systems are still hard to scale. Bisection games are pretty hard to scale. You often need huge bonds.

And ZK proof systems are also hard to scale. You cannot really make them permissionless at the moment, because completeness for ZK proofs in this, often you can find something that is somehow not provable, or will, like, kill the ZK proof. And job of the security counselor should be super clear. So, don't overload them with, like, random stuff. Security counselors should be extremely specialized and focused on upgrades, actually on emergency upgrades.

Ideal would be if a security counselor could always leave if there are no bugs. And, yeah, like, alignment to, like, the framework that we make, or that anyone creates, should probably always have very hard requirements, but also some, like, guiding principles, so that people can actually think, what was the thought behind this framework, and, like, follow it in a good-faith way, not only tick on a checklist these requirements. And that's it. And you can ask some questions, if you like. Thank you.

We already have some questions from our wonderful tool, so we select for answering, what are the Golden Raspberry Awards that you would give to L2Beat itself? I mean, I already showed them in the beginning, right? The vegan and stuff. But seriously, probably, like, the main thing we're trying at the moment is to make this transparency even more credibly neutral. So it might look, if you look at our page, it might look like our opinion and a thing that you cannot really verify, but we really want to make more of an effort to actually give you the tools and allow you to verify everything yourself.

So use these tools that I just showed, that shows contract, on-chain contract state, and following everything to, at least, to ether scan, and then hopefully to, like, blockchain data. Yeah, I don't know. There's another question. You do a lot of deep research. How long is the team doing it?

Because it's a lot of work. Sorry? How large is the team doing it? Because it's a lot of work to do that. How is the team doing it?

How large is the team? How many people are you? Twenty-three, four. Twenty-three, that's a good number. Something like this, yes.

Then there's also, we have two more minutes, the question, what L2 deserves the most praise? The most praise? Yeah, the most praise. Oh my goodness, this is such a, so I said credibly neutral, now I, like, criticized some, and now I have to say who's the best. That's, like, not credibly neutral.

Yeah, true. So I also, like, don't ask the question that was asked here, what's the worst. But you can ask me privately, because I have an opinion on that, personally. Okay, we do that privately. There's a lot of, like, the social mix afterwards, or debates afterwards.

Yeah, then discuss it here. Who could win an Oscar right now? An Oscar? Ah, okay. I don't know, like, I'm not into movies that much.

Okay. You can add some questions with the, I think we are through the ones here, with the QR code, we have three more minutes. Or do you have anything else to say that we forgot? The revenue model of L2B is asked. Is that a bad question, or?

I don't, yeah, okay. The revenue model, what's the revenue model? Well, like any fully halal, perfect company, we only live from grants, so grants and donations. And grants can, of course, come from, like, maybe some dystopian entities, but we will never do what someone forces us to do. So the grants, of course, get, like, can maybe not just in a way, but grants are usually like in research.

We want to solve a problem, then we look for someone that can maybe fund it, and then we do it. And that's the funding model. There's no other, like, there's no, we're not providing services. Oh, yeah, security counsels also pay money, for example, but that's not significant for, like, that doesn't pay our salary. When L3B?

Already there. Already there, but you don't do that. No, we do that. We track L3s just as we do for L2s. Okay, but you don't make it special.

Nice. I don't see any more questions, to be honest. Do you see more? You saw more? But I don't see, I think.

No, I think you saw all.